purebill.com

Stephen Jones writing on billing and application migration

subscribe to purebill link
. Home . About . Archive . Links . Billing . Reference . Subscribe . Search . .
. The Billing Notes Index . Reporting / Business Support .

Note 63: Reporting / Business Support

Posted: 04 January 2010

Reports are point-in-time historical views of the billing databases. They can describe transactions performed, highlight important customer statuses, show the results of business analysis, list transactions exhaustively, or highlight specific activities (whether good or bad) that require further investigation. Reports layouts may be generated in a format for human use, or in files suitable for automated processing.

The important steps in the reporting process are:

  • Use selection criteria to target specific transactions (e.g. charges, customers, exceptions)
  • Extract details about the selected transactions
  • Sort the transaction details into a preferred order (optional)
  • Total and/or aggregate transactions (optional)
  • Format the results for manual review, into an interface file, or format for database storage
  • Distribute the results to the intended audience(s)
  • Store the results for reference, and possible archiving (optional)

Billers may use specialised reporting systems to perform some or all of these steps. Multiple reports may be extracted and generated at once, and/or separate processes may generate individual reports.

Auditing Reports

Auditing reports list all the transactions performed within a specific domain. By their nature, these reports can be substantial and may not be reviewed in detail by the biller's staff. When a problem occurs, staff may use these reports to investigate transactions of a certain type. Due to their volume, these reports are more likely to be viewed electronically than printed on paper.

Financial reports: These reports justify the biller's financial performance to external groups such as the tax department, stock exchange, auditors and shareholders. Financial reports allow billed details to be traced to summarised financial postings, and each summarised financial posting to be traceable back to its constituent sources.

Details may be aggregated for some report / files where the individual customer details are not required. Aggregated reports and files are faster to process, easier to understand and can be distributed more easily. Examples of financial reports include:

General Ledger: The daily postings of every financial transaction performed in billing including details of new bills generated by the billing cycle, adjustments performed against historical bills and debt written off as uncollectable. These reports will describe both the biller's debt, financial liabilities (e.g. amounts billed in advance) and its revenue.

End-of-Month: Aggregated financial totals calculated during end-of-month processing including a biller's outstanding liabilities, billed revenue, accrued revenue (e.g. charges incurred (phone calls) but not yet billed), and outstanding debt (nett of new bills, adjustments and payments).

Aged Debt: - An analysis of customer debt (credit) broken up into time buckets (e.g. credit balance, not yet overdue (current), 30 / 60 / 90 / 120 / 120+ days overdue). This report identifies and quantifies 'old' debt that can be pursued for payment.

Tax: Tax amounts will be calculated for billed transactions and these amounts may be totaled by tax type, currency, taxed products and services, and taxable jurisdictions. The results of these reports can be used to remit the correct tax amounts.

Interface file generation: All records fulfilling specific criteria may be formed into interface files passed to internal business systems or external groups for further processing. Examples of such files are:

Content settlement: The revenue from billed content may be shared with a biller's business partners. The specific settlement arrangements between the biller and each content provider is combined with the billed transaction data to determine the financial settlements paid. Chapter 28 discusses this topic in further detail.

Customer reports: To win their business, billers may offer their larger customers additional benefits that include reporting. Customer-specific reports need to be handled carefully to ensure that each customer receives only their own reports. Secure report distribution is also required to retain confidentiality. Customisation of customers' reporting increases the running and maintenance costs of billing, but this may be offset by increased revenue and customer lock-in.

Regulatory reporting: Industry or competition regulators may monitor billers by requiring the supply of transaction pricing, service provisioning and service restoration details. These reports may generate industry-wide statistics, monitor code-of-conduct compliance, and/or confirm that a biller's pricing is in accordance with competition policy. Access restrictions may be required to avoid exposing private customer details (if included) and a biller's competitive intelligence.

Exception Reports

Exception reports identify small subsets of transactions, customers or situations that need closer, individual review. Their transaction volumes are intended to be smaller than auditing reports (i.e. exceptional) and targeted at situations 'of interest'. Whilst these reports can highlight positive situations, they are more likely to be used defensively to highlight negative situations. The biller's staff can then focus their (finite) attention on these negative situations that would otherwise be difficult to detect. Billers with customer bases numbering in the millions can only use an exception-based approach since manual inspection is not a cost-effective option.

Depending on each report's purpose, some transactions will be reviewed as acceptable requiring no further action. For the remainder, the biller's staff can initiate an appropriate business process to correct or terminate the identified negative situation (or alternatively reward the positive circumstance).

If too many records are selected for review and subsequently turn out to require no action (i.e. false positives), the selection criteria can be adjusted to better target a more appropriate subset. Examples of exception reports include:

Unpaid accounts: Customers may receive a courtesy phone call, email or SMS to remind them of their outstanding debt and ask for payment. The 'days outstanding' selection criteria may differ by customer segment, or the report may identify the biller's premium customers only.

Unusual high spending: Customers that incur charges beyond a credit limit or above their normal spending pattern may be contacted or monitored. The biller can make the customer aware of their increased spending and evaluate whether fraud is involved to minimise uncollectable debt.

Business accounts to be disconnected: The disconnection process can differ by customer segment to reflect the business impact of incorrect actions. Disconnection of business accounts may be initiated by report to place a 'speed bump' of a manual review before any action is performed. For example, the disconnection of a residential customer may inconvenience one family with relatively modest spending, but the automated disconnection of a major corporation could lose the biller substantial revenue, incur legal fees and compensation claims, and be difficult to reverse manually. A single home service can be reconnected in minutes, but a corporation's 10,000 services would take much longer.

Fraud: Specific criteria may be used to identify activity suspected as fraudulent. These situations can be sent to a specialised group for timely review and actioning. Customers the biller suspects of fraud may have continuous monitoring by report.

Accounts unbilled for longer than X days: This report may be used to ensure that all accounts are billed every (say) quarter. If accounts have been excluded from billing, this report will draw them to the biller's attention to ensure that the cause of billing delay is determined and promptly removed.

Adhoc Reports

The majority of reporting will be performed on a scheduled basis using a static selection of criteria, formatting and distribution. In addition to this base workload, the biller may require the capability to generate additional one-time or short-term reports on an adhoc basis. Often, these adhoc reports will extract information on transactions, totals or customers that cannot be obtained easily using online screens (especially in bulk).

Report proliferation and retention are two of the dangers inherent in adhoc reporting. Proliferation can result when user groups and individuals each generate customised reports that almost, but don't quite, align. Localisation of a common corporate policy can be a source of adhoc reporting used to support the (now) different reporting needs. The biller's business must support the additional operational costs and the confusion of misaligned totals. Unintended report development occurs when adhoc reports intended for the short term are extended in scope and duration until they are retained permanently as long-term reports.

Billers can address each of these dangers by developing processes that either curtail the execution of an adhoc report or moves it to the biller's scheduled reporting suite (along with its purpose, supporting documentation, operational costs, identified business use and ongoing support). Examples of adhoc reports include:

Problem investigation: Reports used to scope problems found within IT systems or processes. Once a problem's cause has been fixed, adhoc reports may be used to monitor the remaining errors as they are fixed and confirm that the solution was correct (i.e. no new examples of the problem are found).

Revenue Assurance: Reports on individual customers may be used to confirm a biller's conformance to its contract terms. This confirmation may be performed after new contracts have been provisioned, when major changes are made in product or service definitions, or when customers raise complaints. The pricing of products and services across all customers may be confirmed through a similar process that compares the prices billed to customers against market offering definitions. Chapter 36 discusses this topic in more detail.

Tags: , , , ,

[ Share with others ]

Post this page to a social bookmarking site:

delicious logo delicious diggit logo Digg it furl logo Furl google logo Google
reddit logo reddit stumbleupon logo StumbleUpon technorati logo Technorati yahoo myweb logo Yahoo MyWeb

 

Links to other Notes

Previous - Note 62: Maintenance Lifecycle

Next - Note 64: Reporting Distribution Access

Recent Updates

Sign up to receive a brief text email when new purebill postings are published.

JUMP TO TOP go to top of page
.
Comments welcome: stephenjones(at)purebill.com Stephen Jones © 2004-2010 - Copyright and reprint rules | Sitemap .