Billing Architecture

I’m a subject matter expert in the field of high-volume usage and recurring billing, with experience in internet, telephony, streaming, infrastructure, and other billing domains.

I design and build billing platforms that not only scale, but reduce or eliminate errors, improve customer satisfaction, and reduce the billing support burden. This is achieved primarily by:

Consistency: The overall behaviour of a billing system should be determined by policy, not by the underlying technology; the outcome of billing operations should be consistent with the expectations of end-users. For example, a monthly charge should be raised exactly once per month, on the same day of the month; charges should be able to start and stop at any time; and charges should be pro-rated where necessary. All of this should be automatic, with no operator intervention.
Accuracy: usage billing needs to deal with a very large number of very small values, accurately aggregating not only the primary charges, but also eliminating rounding effects on tax and other surcharges. Pro-rating must be accurate to millisecond precision or beyond, taking into account timezones, daylight savings, and other calendar changes.
Reversibility: changes to the billing configuration for an account or subscription (such as a change of plan) must be reflected automatically in the billing output - for example, a back-dated change to a cheaper plan must result in a credit, rather than a charge (debit). The interesting challenge is to make billing reversible in every possible use case, without requiring intervention.
Performance: any billing implementation should be shardable, operate in real-time, and be capable of handling tens of millions of subscriptions on relatively modest hardware.

I’m available for consulting, design and engineering leadership for billing and related systems. Contact me for more information about how I can help with your scaleable billing needs.

Command Query Billing Architecture

A complete billing architecture consists of a surprisingly large number of moving parts, many of which - usage billing, payments, notifications, usage policies and more - are themselves complex, decomposable subsystems.

I’ve put together the following high-level model billing architecture to illustrate the complexity of billing at scale. Feel free to contact me if you would like to discuss this model, including details I’ve omitted here.

Billing

Billing is the process that determines what a customer should pay for the services you will, or have provided. The billing process includes:

Usage Billing: Usage billing is the complex process of converting resource usage records into billable events. This may involve multiple steps, including: raw data collection and storage, mediation (transformation), guidance (allocating usage to a user), aggregation, tagging (assigning a type to the usage), and rating (determining how much to charge). In some integrations, it’s necessary to be able to deal with incomplete (partial) usage charges, and to be able to modify usage on demand.

Recurring Billing: Recurring billing is the process of raising charges on a regular basis over an interval of time. Accurate recurring billing is much harder than it seems: not only is our calendar system complicated (months have a variable number of days!), but we have to allow for time zones, daylight savings time (days have a variable number of hours!), pro-rata calculations (starting or ending billing mid-cycle) - and the ability to reverse a charge and issue a credit if the configuration changes (eg, cancellation).

One-Time Charges: One-time charges are single charges that are applied to an account. These can be complicated by policy rules further up the stack (for example: never charge a membership fee more than once), but in general are straightforward.

Stored Value: A complex part of the billing process is the management of stored value; things like prepaid usage, allowances, gift cards, and so on. Stored value is common in mobile phone networks. One concern with these systems is that they are treated as a financial liability (essentially, money you owe to your customers), adding a layer of complexity to an already complex system. In general, a billing architecture works best if processes stored value before getting to the invoicing stage.

Assurance: an often overlooked aspect of billing, assurance is the process by which we check that billing - especially usage billing - is accurate. This can be as simple as manual reconciliation, re-rating inbound usage charges, or even deploying a second assurance-specific rating engine. Assurance is particularly important when you are receiving billing from independent, remote platforms, or from upstream vendors who may be required to conform to contractual or other requirements that need to be checked and enforced.

Invoicing

Collation: Billing events (ie, recurring, usage and one-time charges) are aggregated into invoice line items. Invoice item collation can be very complex for usage charges at scale, because we need to store and display a correct summary of the charges while maintaining the ability to reconcile those charges directly back to the original usage records - of which there may be many million. Usage collation is therefore a serious and complex undertaking, which can easily result in serious performance issues if not implemented correctly.

Review: An important aspect of invoicing at scale is the ability to review invoices prior to release. This process can include both automatic review (eg, checking that an invoice is similar to previous invoices) and manual review, either through random sampling, policies, or some combination. Of course, it also needs to be possible to skip the review.

Release: Invoice release or approval is the process of adding the final, reviewed invoice to the customer’s debtor ledger, which changes their account balance. Of course, charges can also be reversed - meaning that we might be talking about a credit, rather than an invoice, being added to the ledger.

Receivables and Payments

Debtor Ledger: The debtors ledger is the list of people who owe you money, or to whom you owe money. The ledger consists of transactions: credits, which reduces the amount that a customer owes you, and debits - including invoices - which increases the amount that a customer owes you. In a well-designed system, the debtors ledger only cares about credits and debits - it doesn’t care how they were computed.

Payments: Payment processing requires the integration of the debtors ledger with one or more electronic payment providers. Typically, payment requests are controlled by a policy, which is triggered some time after an invoice is raised. Integration with payment providers can be surprisingly complex: the quality of payment provider APIs generally varies from bad to terrible. Because of this, and due to the critical nature of the payments function, we generally need to build bespoke integrations which are complex, robust, and able to deal with the idiosyncrasies of the target platform.

Collections: Collections is the set of digital policies setting out what you will do if a customer doesn’t pay for a specific period. A collection policy can be as simple as sending a reminder notice, or as complex as reducing the service level or removing access to a service. Collection actions are triggered at the account level, so a policy may affect tens, hundreds or even thousands of services. For this reason, we separate collections policy from policy enforcement.

Notifications: Sending notices to your customers can be surprisingly complex. A sophisticated notification system needs to deal with many different kinds of transaction (invoices, credits, debits, usage, payments, and more), different transaction formats (original invoices, copies, reminders, demands) and many different communication channels (in-app, SMS, email, PDF, third party) - some of which have their own policies (eg, only send SMS during the day). As with payments, there are many integrations required, although the API quality, in my experience, tends to be a bit better on average. But the upshot is that there is literally nothing simple about billing notifications.

Product Management

Product Catalog: A product catalog is the definition of products offered for sale to customers. From the billing perspective, the product catalog generally specifies the rate card for usage billing, the recurring charges (along with things like product combos), and one-time billing policies. In general, a product catalog sits above the billing platform, and defines attributes of the products beyond just billing, such as eligibility, decomposition (sub-services), and more.

Subscription: A subscription is the assignment of a specific product from the catalog to a specific account, for a period of time. Subscriptions are the glue that binds a particular product or service, for a particular billing configuration, to a debtor.

Fulfilment: Fulfilment is the process of delivering the product to the customer; it’s often a separate process, which sits above the billing platform and is used to assign a product to a subscription, and organise to have the product activated. Fulfilment can be complex - such as a BPMN or Node Red workflow - or it can be a simple API call. In either case, a billing architecture should consider fulfilment and billing to be separate but related functions.

Policy Management

In the context of billing, policies determine the configuration of services based on a variety of policy sources. A policy generally relates to concrete attributes of a service; for example, in data services there may be policies relating to upstream and downstream bandwidth and QOS; in a streaming service, a policy might apply to the available content; in infrastructure, to the amount of CPU or RAM allocated to a service.

Policy Source: policy sources are the inputs to policy resolution. In billing, sources can include, for example, the product catalog (policies about the level of service to be provided), subscriptions (eg, policy overrides), usage (usage restrictions, overuse limits), spending policies (how much total debt an account can sustain), and overdue policies (restricting use due to an old debt).

Policy Resolution: policy resolution is the process of combining the various policy sources, prioritising them, and determining a single target policy for each policy type in a given service. For example, a streaming service might allow 4 simultaneous users - but an account in arrears might allow zero. The resolution function determines that the overdue policy outweighs the product catalog policy, and applies the setting from the overdue policy.

Policy Enforcement: The policy enforcement function takes a resolved set of policies and applies them to a concrete service. Similarly to payments and notifications, this requires integration between the enforcement function and the target service; for example, a digital TV head-end is different from an internet BRAS; they speak different protocols and have different modes of operation.

Contact Me

Hi, I’m Mark. I’m a digital billing consultant based on the Sunshine Coast, near Brisbane, Australia..

I’m available for contract/permanent consulting and leadership roles in billing system design and engineering, and other technical roles.

Get in touch! Let’s discuss how I can help with your high-volume billing problems.