Every subscription business is two systems wearing one logo. There is the billing system that decides what to charge, and there is the ledger that records what happened. When those two drift, you do not find out from a dashboard. You find out from an auditor, a customer who was double-charged on an upgrade, or a representment packet that cannot explain why the disputed amount differs from the plan price.
Billing architecture is the discipline of keeping the charge and the record in lockstep through the three operations that most often break them: proration, trials, and usage. Get this wrong and the damage is quiet and compounding. Module 1 covered the recurring-revenue P&L this ledger feeds, and module 6 covers defending the disputes that a clean ledger makes winnable.
Proration is a credit-and-debit event, not a new price
When a customer upgrades mid-cycle, the instinct is to charge the new plan and move on. That corrupts the ledger. The correct model treats a mid-cycle change as two ledger events: a credit for the unused portion of the old plan and a debit for the proportional cost of the new plan over the remaining period.
Stripe, for example, calculates proration down to the second from the billing period's start timestamp to the moment of the change. It issues a credit equal to the fraction of the period remaining times the old price, then a debit of that same fraction times the new price. The customer pays the net. Crucially, the two line items remain distinct, and on flexible billing each credit carries a reference to the original charge it offsets, so you can reconcile a credit against the debit that produced it.
That linkage is what makes proration auditable. If your system collapses an upgrade into a single net charge with no record of the credit and debit legs, you have lost the ability to answer "why this amount" later. That question gets asked in disputes.
Worked example
A customer is on a $40 per month plan, billed on the first. On day 15 of a 30-day cycle they upgrade to $100 per month. Roughly half the period remains.
The ledger should record a credit of about $20 (the unused half of the old plan) and a debit of about $50 (half the new plan), for a net charge near $30 now, with the full $100 billing at the next renewal. Recognize the credit and debit in the period they occur. Do not net them into one $30 line with no provenance. When this customer later disputes "an unexpected $30 charge," the two legs are your entire defense.
Trials must not pre-create revenue
A free trial is a marketing instrument and an accounting non-event. The failure mode is treating the trial as a $0 invoice that establishes a subscription state your ledger then has to unwind. Better to model the trial as a deferred start: no charge, no recognized revenue, no deferred-revenue liability until the first real billing fires.
The hazard sits at conversion. When the trial ends and the first charge lands, that is the moment the contract begins for accounting purposes. If your trial logic silently rolls into a paid plan without an explicit, logged conversion event, you get two problems at once. You cannot prove consent at the point of first charge, and your revenue start date is ambiguous.
Both problems surface in disputes. "I forgot I was in a trial" is one of the most common recurring-charge complaints, and the only durable answer is a logged conversion event tying the first charge to the date the customer was told billing would begin.
Usage billing splits delivery from invoicing
Usage-based pricing breaks the comfortable assumption that the amount billed equals the amount earned in a period. Under ASC 606, the US GAAP revenue standard the FASB issued in 2014, revenue follows delivery, not invoicing. For metered products, that usually means recognizing revenue in the period the usage occurs, even though you invoice it in arrears at month-end.
This creates a gap your architecture has to name explicitly. Usage that has been metered and rated but not yet invoiced is unbilled revenue, an asset that sits on the balance sheet until you issue the invoice. Confusing it with deferred revenue, which is a liability for service not yet delivered, is a classic cutoff error. They point in opposite directions.
The practical requirement is a rated-usage record that is independent of the invoice. You meter raw events, rate them into currency amounts as they occur, accrue the unbilled balance through the period, then convert it to a billed invoice at cycle close. Each stage is a separate, reconcilable record. When usage is metered late or rated against the wrong price, the error should be catchable at the rating stage, before it ever reaches an invoice or a customer.
Worked example
An API customer consumes 1.2 million calls across a month at $0.001 per call. You rate that as roughly $1,200 of unbilled revenue accruing through the period, recognized as the calls happen. At month-end you invoice the $1,200, moving it from unbilled asset to billed receivable.
If 200,000 of those calls arrived on the last day but were not metered until the first of the next month, that $200 belongs in the period the usage occurred, not the period you noticed it. A clean architecture catches the cutoff at rating. A corrupted one ships a $1,000 invoice and quietly understates revenue, then overstates it next month.
The non-corruption rules
Three constraints keep the ledger trustworthy across all three operations.
First, append, never overwrite. Every charge, credit, and adjustment is a new immutable line. You correct an error by posting a reversing entry, not by editing history. An auditor and a chargeback both need the full sequence.
Second, separate the rated amount from the invoiced amount. Rating is when you decide what something costs; invoicing is when you ask for it. Keeping them distinct is what lets usage, proration, and trial conversions reconcile.
Third, recognition follows delivery, not cash. Billing cadence is a collections decision. What you recognize is governed by when you delivered the service, which is why prepaid annual plans sit in deferred revenue and metered usage accrues as unbilled.
Closing takeaway
The ledger is not back-office plumbing you can paper over with a billing provider. It is the source of truth that revenue recognition, financial audits, and dispute representment all read from, and they all read the same rows. Build proration as paired credit and debit legs, build trials as deferred starts with a logged conversion, and build usage as rated-then-invoiced with an explicit unbilled balance. Do that, and every charge you make can answer the only question that matters when it is challenged: why this amount, on this date, for this customer.