Stephen Jones writing on Billing and Application Migration
The bill sent to the customer along with details of transactions performed by the customer, will have a summarised amount representing the bill’s new charges, aggregated from the bill’s individual charges. In addition to the charge details, there may be payments, adjustments, information and other sections on the bill. All of these bill details taken together represent the customer’s view of their bill against which they may make an inquiry.
These customer-facing bill details are separate from the bill production / formatting data used to generate bill reprints. Bill reproductions can require additional formatting information required for the generation of a paper bill or electronic PDF file, and may be stored in a pre-processed proprietary binary format (depending on the billing software’s invoicing mechanism).
External customer views of the bill’s line items will often include the charges’ descriptions and the line items calculated price, whilst internal views of the same data can include additional information about how prices were derived, and flag details of any disputes already raised against a bill’s line item.
Stored bill details are often a high volume data repository as bills generally list all the network transactions performed by a customer, as well as all one-time and recurring charges. This is in addition to any additional sections on the bill for summarisation, payments, disputes, adjustments and marketing messages. With such a high volume, and the generally short to medium term relevance of a bill, the bill detail data repository is a strong candidate for archiving to an alternate / offline repository.
Different industries and networks will generate different volumes of transactions that influence this decision. For example, a gas utility’s bill will have very few (say) quarterly consumption measurements, whilst a telecommunication company’s monthly bill may list details of every individual phone call made by the customer.
In addition to the viewable information stored against the line item, there are additional properties stored to support the processing performed against the line items, including:
The bill line items should be searchable so that specific transactions or network services can be easily found when reviewing a bill. The ability to search smaller bills with their few transactions and network services may not provide much of a benefit. Where the transaction numbers are large (e.g. telecommunications), or where there are many network services (e.g. corporate account), the usability benefits of search will provide a material benefit over the alternative of ‘paging’ through the details of the bill until the desired slice is found.
Post bill disputes capture bill details challenged by customers. Searching through a disputed bill’s line items enables specific charges to be highlighted and grouped into the ‘dispute’. A dispute might include only a single charge, but can also include a collection of network transactions, and related one-time and recurring charges. A dispute’s complexity is limited only by the functionality and capability of the biller’s billing application.
Details of the post bill dispute are separate from the bill details being disputed, and will be updated based upon a separate resolution timeline to the bill’s payment. The data volumes of the post bill dispute data will depend typically on the volume of network transactions involved (rather than one-time or recurring charges).
Capabilities that the post bill dispute data and related functionality would ideally support include:
The biller can use the post bill dispute data for reporting that highlights high-value disputes and their resolutions (e.g. for resolution confirmation / review, fraud prevention), and to highlight disputes that have been outstanding more than a defined period of days (to ensure all disputes are being resolved in a timely manner). Disputes that remain outstanding are not responsive to the customer, and may prevent the collection of the disputed amounts’ debt until they are resolved.
Originally posted by
Download the FREE Book Sample Now
Stephen Jones is a consultant who has focused specifically on Billing and related processes for over twenty years. Recent work has included relating a major telco's billing with inbound call centre logs for Call Centre Analytics.
I contributed an essay on testing design assumptions in the O'Reilly book 97 Things Every Software Architect Should Know. This book was written in an 'open source' style with more than four dozen authors. The original essays of the axioms / koans / advice can be viewed on the project's wiki.
Enter your email address to follow changes and receive notifications of new posts by email.
You will be returned back to this page, and a confirmation email will be sent.