Note 53: Downstream Information Flows

Posted: 14 May 2008

Bill Validation

Once all calculations for a customer's bill have been completed, high-level automated validation can be performed to check the bill's 'reasonableness'. For example, residential customers are unlikely to ever receive bills over a certain value. If this situation occurs, the bill can be held for manual validation. The checks and the parameters can be set by market segment to reflect the larger purchases of business customers.

Validation will deliver the best results when the checks performed are tuned to hold only that small number of bills whose details are exceptional. If too many bills are held the workload for the biller's staff will be excessive, the bills that should be reviewed may be overlooked, and the biller's cashflow will be impacted by the bills not sent.

The biller may choose to hold specific customers' bills before they are sent out. This may be due to previous problems with the customer's products, the customer may be important or sensitive to errors (e.g. the biller's CEO, new customers, customers in legal dispute), recent changes against the customer may need to be checked (on the next bill), or the customer may be trialling a new product and the biller may wish to check the bill before it is sent out.

Once reviewed, a bill without errors may be released and sent to the customer (possibly with an updated due date). A bill with errors will need to have the errors corrected before it is reprocessed (rebilled) to pick up the corrected results.

A corrected bill may be held again to confirm that all errors have been removed. This process may be repeated until the bill's details are correct. Whilst bills are held for review they are considered to be 'in flight' (i.e. still in the process of billing). The customer's next bill will be deferred until the 'in flight' bill is completed and sent. This delay can cause cash flow impacts if bills are held for an extended period since the held bill and any subsequent bills for that customer (including interim and final bills) will not be sent to and paid by the customer.

Downstream Applications

Once the bill's information has been collected, the charges' final prices determined, and any taxation derived, the billing cycle's results must be conveyed to other areas within the biller's business to reflect what has happen. Other areas within the biller that require billing information include:

Bill Printing and Distribution (discussed in later notes)
Financial postings
Updates to Customer Information
Revenue Assurance

Financial Postings

Financial postings interest at least three constituencies within the biller: product managers (revenue), credit management (debt), and the biller's accountants/auditors (all postings).

The first constituency comprises the product managers who track how much of each product has been purchased by customers (revenue). This tracking may be broken down by market segment, customer, location, and/or purchasing channel. The captured transaction details and the customer's demographics provide the dimensions available for analysis of the purchases, and how the results can be apportioned to the appropriate internal product groups (from the biller's perspective). This constituency is interested in tracking how well or badly sales are going with a view to improving sales, and, depending on their compensation model, being paid for the results achieved.

Bundled charges present a challenge when dividing the revenue totals because products from different areas can be combined and priced in a different manner. The bundle may be billed at a flat rate without reference to its constituent parts, or the constituent parts may be priced differently (i.e. cheaper) within the bundle than when purchased 'a la carte'. From the customer's point-of-view, the bundle and 'a la carte' are just different purchase choices. Internally, the revenue for the two approaches may be divided quite differently.

For example, a group of four products that cost $10 per month when purchased separately (product A = $1/month, product B = $2/month, product C = $3/month, product D = $4/month) may be bundled and sold under a single charge of $8/month when purchased together. From the customer's perspective this may be marketed as '20% off' the normal price.

Internally within the biller, the revenue may be divided based on the original charges (i.e. all products reduced by 20%), or may be divided differently (e.g. product D may be reduced from $4 to $2 per month). This division can be hidden from the customer (under a consolidated charge), or the division may be reflected on the bill.

In general, the revenue attributed to each product within a bundle may be reduced uniformly by a percentage, by a fixed amount against specific products, or a combination of both. The revenue tracking from the billing process will be complicated to the degree that multiple approaches are taken and require the capture and maintenance of additional information about the products and bundles throughout the billing process.

The second constituency tracks the debt represented by the customer's current and previous bills. This group is interested in the timing of when (and if) customers make bill payments. Debt is an aggregated financial posting that is less concerned with the individual products purchased. An invoice's debt is usually represented by a single numeric value, but a small number of separate product group totals may also be stored.

Whilst the products included on their bills may differ, there are only minor differences between the debt postings for a low-value consumer and the largest corporate customer (though the numerical amounts may differ greatly). The debt postings generated by the billing cycle will be offset by subsequent customer payments and any adjustments made against the customer's account or their invoices.

The third constituency are the biller's auditors and accountants who ensure the biller's corporate General Ledger postings reflect the consolidated revenue and debt postings (stripped of customer-specific details). The biller's General Ledger includes not only the financial postings of the billing system (or multiple billing systems where they exist), but also the financial postings made by other areas of the biller's business (e.g. Accounts Payable, Payroll).

The biller will reconcile the revenue and debt totals stored in the (each) billing system with the aggregated values held centrally in the General Ledger. This reconciliation will confirm that the financial results used to run the biller's business align with the information captured by billing (and other business systems). Automated reconciliation's between these financial databases are likely to be reviewed by the biller's auditors.

Updates of Customer Information

Billing cycle updates reflect the results of billing back against the customer's database information. Customers can view these updates online (i.e. on the internet), biller staff can answer customer inquiries using the updated details, and subsequent bills can exclude previously billed charges.

After the customers' bills have been calculated and distributed, there are additional tasks that must be performed to complete the billing cycle. These tasks update the databases and systems from which data was extracted to reflect that billing has been completed successfully. These updates will ensure that the customer's next bill does not include charges that have been already billed, and allows transaction data to be deleted or archived (housekeeping) continuously freeing up storage for new transactions. Examples of the housekeeping tasks performed include:

Deleting (or archiving) usage and non-recurring charges when billed: Once usage and non-recurring charges have been billed, they must be flagged as billed to avoid them being extracted on subsequent bills. Three options are available: update a database entry to identify them as billed, delete the transactions from the database, or remove them from the active database, archiving them to a cheaper storage location.

Transactions may be physically flagged as billed (and considered deleted) before they are physically deleted and/or archived at a later time. This allows transactions to be removed from immediate consideration, and supports the use of more efficient utilities and techniques to physically move or remove the database entries.

Those billers processing high-volume transaction data must continue to remove data from their active databases to prevent the storage costs and additional hardware requirements from becoming excessive. Where transactions may be required for investigation, or later reprocessing (e.g. rerating), the transactions may be archived (stored) offline. Storing billed transactions separately from new and unbilled transactions allows both the billing process and the biller's staff to easily find, and concentrate on, unbilled charges.

Update recurring charges: Ongoing recurring charges are updated to reflect the date to which the customer has been billed. Recurring charges that have been terminated since the last bill will have their billing status end-dated to avoid them being extracted on subsequent bills.

Update resource totals / contract details / bill details: Subsequent billing processes may require details of what took place in the billing process. The distribution and storage of these details supports the processing that surrounds billing. For example, the dispute process can support richer interactions with customers when details of the bill are available in a similar format to that sent to the customer. Customer contracts that track network use or dollars spent over time may also require detail from the billing cycle to support customer rewards, financial penalties, or rate adjustments.

Signal the billing process as complete: At the commencement of the billing process, each customer billed will have been identified as having their billing 'in flight'. This is done to prevent some changes (e.g. modifications to extracted usage), identify which changes have not made the customer's current bill (i.e. because it is already being produced), delay interim bills (ensuring that data is consistently updated), or delay subsequent bills when a customer's bill is held for manual review.

Tags: Billing, Downstream, Interfaces, Bill Validation