Note 48: Other Bill Cycle Extraction

Posted: 26 March 2008

Information not extracted to the Billing Cycle

Circumstances exist where charges are intentionally not extracted. Examples where this approach can be applied include:

Events never billed: Calls to emergency services may be processed from the network through to billing, but remain omitted from the call types sent to the bill.
Details too old: Regulators, or a customer's contract, may define time limits after which a charge cannot be billed (e.g. calls older than 180 days). These limits may vary by product offering to account for uncontrollable variations. For example, less sophisticated international telephone networks may delay forwarding international reverse-charge calls performed from their networks.

Future dated charges: Specific charges may be future dated and not fall within the extract dates of the customer's current bill. When the charge's date falls within a subsequent billing cycle, these charges will be billed. The danger to the biller is that charges may be placed so far into the future (i.e. months or years) that they are contested by the customer when eventually billed, or that the customer's billing arrangement ends before the future-dated charge becomes eligible for extraction.
Products with processing errors: The biller may identify defects in their billing process for specific products and choose to defer their billing rather than generate errors visible to the customer. Other errors may be invisible to the customer but generated erroneous financial or database entries. When these operational problems are resolved, the products can be released for billing on the customer's next bill. The biller may be motivated to resolve these problems promptly to avoid delays so long that the deferred charges become unbillable. This can include situations where the customer's relationship no longer exists.
Products that are not billable (yet): To be first to market, billers may choose to release products on their network that cannot yet be billed (at the release date). Two approaches can be applied in this circumstance - the biller can market the product as 'free' for a defined period (by which time they expect their billing to be ready), or they can withhold the charges from customers until the billing platform is ready.

Cross-system Extraction

Some billers consolidate billing's major functions in one centralised application, but many others distribute their customer and charge information across multiple platforms. Information may be distributed across many platforms because the biller has begun, but not completed, a consolidation to a single billing system, or new rating systems may be used to improve the rating capabilities whilst retaining the existing billing platform. Whatever the reason, distributed information requires a coordinated extraction process that gathers all the customer's information together for billing.

Two solutions that support cross-system extraction are the passive approach that relies on a timetable of processing, or an active approach that actively requests the required information as and when the billing cycle runs.

The passive approach uses a published billing timetable to schedule upstream processing. The timetable is agreed to and published internally (and possibly externally to a biller's billing partners). Upstream processing uses the published timetable to ensure that charges for a specific billing cycle, commencing on (say) the 10th of a month, are passed to the billing platform in sufficient time. Using the timetable, a biller's external partners can perform their charge extractions in time to meet a customer's bill. The exact timing of when upstream systems pass their extracts to the central billing system is flexible and provides the upstream systems some leeway to accommodate their other processing needs.

Using this approach, upstream systems do not have explicit knowledge of who is billing in each billing cycle. All they may know is that specific customers 'usually' bill in the cycle starting on the 10th of the month. If a customer's billing is delayed, or an interim bill is requested, the upstream systems will not know to change their processing.

If an upstream extract is delayed, the biller can decide whether to wait and include the charges in the (delayed) billing cycle, or commence on time and consciously omit the charges. Based on the arrival, or delay, of upstream extracts, the biller will know which charges were included in each billing cycle.

The active approach uses information generated by the billing cycle to request the necessary charge data from the biller's upstream systems. A specific list of the customers in the billing cycle are passed to the external or upstream systems, and they respond promptly with the information, charges and/or customer data within their domain. Once all systems have supplied their details, the billing cycle can continue to its completion. Whilst the upstream systems may be aware of the billing timetable, they do not have to actively manage the supply of information into the billing cycle.

One problem with the active approach is that the upstream system may receive the billing cycle's request at an inconvenient time when the upstream system's resources are unavailable or have limited capacity to respond to the request. The delays that this can introduce may be reflected into the billing cycle as it waits for all extraction requests to complete.

Whether an active or passive is appropriate depends on factors such as:

Transaction volumes: High volumes may cause processing loads that interfere with an upstream system's other operations. The data connections between systems may be insufficient to accommodate the data volumes within the required timeframe. High-volume billing is more likely to locate its customer and charge data repositories in 'close proximity' to the billing application to minimise the level of data movement.
Basic System Architectures: The system architectures of the upstream applications may not accommodate an active approach to data extraction. The billing system may not have been designed to process data held externally.
External connectivity: The technology linkages with external partners may not be robust enough to support active requests for data. The infrastructure to supply data based on a known timetable can be implemented more easily than an inter-company, real-time, high-volume connection with all its security, availability and operational issues.

Billing systems can include both extraction approaches, and the mix between them may change over time as systems are replaced. Consolidating most billing data in the one location reduces the need to depend on external parties, but this may not conform with the biller's system architecture.

Storing charge data in multiple locations can have impacts in other areas. For example, the biller's financial exposure to a customer may be difficult to assess if their charges are distributed across multiple systems. Charges held by external parties will also be difficult to include in any credit management assessment.

Tags: Billing, Extract, Cross System