The danger of 'price' in external interfaces

Summary

Fields containing price should only be placed in external billing interfaces when the transactions' 'final' values have been determined. Providing 'interim' price values in an external interface may satisfy short-term technical design / political needs, but is likely to end up reducing a biller's design and processing options in the future.

Forcing 'accurate' 'interim' prices in the interface to reconcile with the customer's (monthly) bill, reduces the biller's opportunity to discount based on overall spending, price and discount across product streams, and provision the biller's infrastructure based on average, rather than peak, processing loads.

An alternative approach would provide just the transactions' details (determinants) across the billing interface and delay the transactions' final price determination until the customer's scheduled bill processing. This approach preserves the maximum choice of when and how billable charges' final prices are calculated.

Price fields in billing interfaces

Billing interfaces containing a price field can be divided into two groups based on whether the price has an interim or final value. Interim prices may be recalculate, discounted against or ignored (bundled pricing), whilst final prices have finished their processing and contain the values the customer is expected to pay.

Interim prices are commonly passed between internal billing applications. The values in these interfaces remain a 'work in progress' and may be changed completely before the billing process completes. If transactions are distributed externally with 'interim' prices attached, the biller may be constrained in how their final prices can be determined. effectively locking the biller into making the 'interim' prices their 'final' prices.

A biller, unable to change their transactions' prices once sent across the interface, will be prevented from performing additional price modifications (e.g. discounts) in later processing. Interface timing (e.g. a daily 'priced' file sent by 8pm) may constrain how and when bill processing is performed, binding the biller to artificially tight timeframes (with correspondingly high processing loads), and leaving infrastructure idle for the majority of the processing 'day'.

For example, prices determined in network-specific rating applications (e.g. mobile calls, metered electricity usage) may be passed to a consolidated (convergent) billing application where they are merged with transactions from other networks (e.g. fixed-line phone calls, metered gas usage). Once consolidated, further discounting can be applied across the charges from different networks.

Distributing interim prices

Billers may choose to distribute (draft) 'interim' prices to customers, clearly stating that the final price may differ based on later processing, but the danger is that this approach will be compromised by:

Sales pressure: The principle that prices are 'interim' until scheduled billing, is compromised to win or retain a customer, possibly a 'small' one, forcing the biller's processing to now provide 'final' prices early in the billing process. Once provided to one customer, other customers may also be offered the same choice, locking in the new change of direction. Once entrenched, the biller may find it all but impossible to change the now 'default' approach of 'final' pricing back to 'interim' pricing to deliver additional pricing options. The original customer who initiated the change of approach may not be retained over the long-term, even though their impact will remain.
Ignorance: Over time, the design of the biller's bill processing may 'drift' from initially providing only 'interim' prices in external interfaces, to assume that 'final' prices are provided. Staff involved in the initial design will change and a design decision made in ignorance will restrict the biller's future choices. This drift may also occur when a new product can provide a final price easily (e.g. it may be charged using a standard value), and over time all products are conformed to this assumed accuracy requirement.
Expediency: Short-term management or design goals force a change in the existing interface approach to use 'final' price, overriding the long-term, 'interim' price design philosophy. The management responsible for the decision may move on to other duties and/or the product that drove the 'expedient' change may be dropped, but the now modified interface will live on to constrain future management and future products options.

Problematic billing interfaces

A large corporate customer may require the biller send a daily / weekly transaction feed (containing 'price') separate from the customer's scheduled bill processing. Since the customer is (probably) one of the biller's largest (i.e. justifying the development cost of the interface), the biller may provide the interface, later reusing the same infrastructure for their other large customers.

The customer may require the biller price the transactions 'accurately', turning the biller's 'interim' price (desirable) into a demand / requirement for 'final' prices (problematic). Questions the biller can ask their customers to better understand their needs include:

From the customer's perspective, what is the value of knowing the transaction's 'final' price at this preliminary stage?
What is the value of an 'interim' price (that the biller might change) over a 'final' price?
How is the customer's processing impacted if the 'interim' price changes to a 'final' price within the customer's scheduled billing?
Can transactions generated by the biller's scheduled billing with a 'final' price substitute for the 'interim' priced information?

The intent is to find a solution that meets the customer's business requirement for transaction details without requiring the biller supply a 'final' price in an preliminary, external interface.

The biller will retain future design and processing options if they can omit the price field in early, external interfaces, provide just the determinants of network transactions, and supply the customer with a data feed generated with their scheduled billing containing their transactions' final prices.

Acceptable uses of price in billing interfaces

Despite being a poor choice for interim prices, final prices (i.e. fully processed) can appear in external interfaces without triggering the problems outlined above. Two examples of these interfaces are inbound third party charges, and outbound 'post-billing' data feeds.

Inbound charges from a third party provider may be passed to the biller for inclusion on customers' consolidated bills. These prices are 'interim' to the biller, since the biller's end-customer has not yet billed, but are 'final' with respect to the third party provider who has calculated the end price to be charged to their customer. The biller's customer has incurred a defined charge with the third party provider and expects to be billed for that same amount on their consolidated bill. The customer has little expectation of further discounts or transaction repricing. Examples of such charges include parking meter charges included on a customer's mobile phone bill, and downloaded music charged against a customer's broadband bill.

A feed of billed data delivered to (larger) customers at the end of their billing is an example of an outbound interface using 'final' prices. Customers may perform their own data analysis to discover trends in their network use, or on-bill the charges to their own customers (e.g. network resellers, lawyers recovering costs). The price information in these interfaces has been finalised and, since it aligns with the biller's financial postings (GL), is not subject to change by the biller.

Tags: Billing, Pricing, Interfaces