Subscription billing is the practice of charging a customer on a recurring cadence — monthly, quarterly, annually — for something they keep using rather than something they bought once. The invoice isn't a one-off event; it's the output of a live plan that keeps producing invoices on schedule until the contract ends or changes.
That plan is the part most people skip past. A subscription billing system isn't really "recurring invoices" — it's whatever object sits behind them and decides what the next invoice should say.
The models a real contract mixes together
Textbook subscription billing is one flat fee, same amount, same day, every month. Real B2B contracts rarely stay that simple:
| Model | What it charges for | Where it gets complicated |
|---|---|---|
| Flat recurring | A fixed fee per cycle | Ramps: price changes at a known future date |
| Seat-based | Per active user or license | Seats change mid-cycle; snapshots vs deltas |
| Usage-based | Metered consumption | Volume tiers, minimums, prepaid drawdown |
| One-time + recurring | A setup fee plus the ongoing plan | The one-time fee sometimes has to be paid before the subscription starts at all |
Most contracts aren't one of these — they're two or three of them on the same agreement, with different start dates, different proration rules, and a renewal clause that changes the price a year from now. A billing tool built around "a plan and some add-ons" starts inventing workarounds the moment a contract does anything else.
The billing schedule is the actual product
The object that has to hold all of this is a billing schedule — a live plan with phases, each phase with its own products, dates, and cadence, that produces invoices on its own rather than requiring someone to remember to raise one.
A schedule needs to answer, correctly, every time:
- What's the invoice period for this cycle, and does it align to the customer's contract start or the 1st of the month?
- If the subscription started mid-cycle, is this a stub period, and how much of the recurring fee does that stub actually owe?
- Did anything change — an upgrade, a seat count, a usage tier — that needs proration instead of the flat rate?
- Is there a gate — an unpaid setup fee, a signature step — that should hold the whole schedule until it clears?
Most billing pain in subscription businesses traces back to one of those four questions being answered wrong, quietly, for months, before anyone notices the invoice total doesn't match the contract.
Where flat-plan tools break
Plan-and-add-on billing tools are built around a product catalog: you configure a plan, attach add-ons, and the tool bills against that configuration. That model works well until the contract itself has terms the catalog can't express — a price that steps up in month 7, a fee that only starts once a deposit clears, three different discount tiers layered on the same line.
At that point, teams end up doing one of two things: typing the contract into the catalog as a series of workarounds (manual overrides, a second "phase 2" plan swapped in on the right date), or keeping a parallel spreadsheet that tracks what the contract actually says versus what the billing tool is configured to do. The second one is how a company ends up with two different numbers for the same customer's ARR.
Proration is where the errors hide
The most common silent bug in subscription billing is prorating a mid-cycle change by days elapsed / days in period against a monthly rate — which quietly disagrees with the quoted price the moment a month isn't 30 days. A contract quoted at a fixed monthly amount should prorate by calendar units (days, weeks, months of the actual billing basis), not a day-ratio of an arbitrary period length. It's a small distinction that shows up as a real dollar discrepancy on every partial month, every upgrade, and every activation that doesn't start on the first of a cycle.
What to check before trusting a subscription billing setup
- Can it read a signed contract and produce the schedule from it, or does someone re-type the terms into a catalog first?
- Does it support ramps — a price or product set that changes at a known future date — without a manual "swap the plan" step?
- Can one invoice mix a flat fee, seats, and usage correctly, or does usage always need a separate tool bolted on?
- What happens to an issued invoice if the schedule changes after it's sent — does history quietly rewrite, or does a correction become its own document?
- Is there a concept of a payment gate — an amount that has to clear before the subscription term itself begins?
Sonic AI's schedule starts from the signed PDF rather than a blank catalog, handles ramps, seats, usage, and payment gates on one record, and treats an issued invoice as frozen — a later change is a new invoice or credit note, never a silent edit. See how the schedule works, or the deeper mechanics on payment-gated subscription activation, upgrade and downgrade proration, and what a signed PDF actually contains.
Related terms: billing schedule, subscription activation, schedule phase, calendar-unit proration.