Chapter 17 — Invoicing, PAYG & Hybrids: Beyond Subscriptions

It's the end of MelodyBox's first month offering an enterprise tier. Sarah Chen, the CFO, opens the billing dashboard and stares at the first invoice for Meridian Corp — MelodyBox for Teams' inaugural enterprise customer.

The invoice has four line items:

1. Base subscription: S$500.00 (MelodyBox for Teams, 50 seats)
2. API usage: S$284.74 (14,237 API calls × S$0.02 each)
3. Mid-month upgrade proration: S$193.55 (upgraded from 50-seat to 80-seat plan on the 17th)
4. Singapore GST (9%): S$88.05

Total: S$1,066.34

Sarah frowns. Four line items, but behind them are three completely different calculation engines. The base subscription came from the plan catalog. The API usage came from the metering system, which counted every call Meridian's developers made over 30 days. The proration came from a mid-cycle plan change that required calculating the unused portion of the old plan and the remaining-days cost of the new one. And the tax came from a rules engine that had to determine whether Meridian's Singapore office qualified for GST and at what rate.

One invoice. Three systems. And if any of them got it wrong, MelodyBox either undercharges (losing revenue) or overcharges (losing trust).

"Why is billing so hard?" Sarah asks her engineering lead.

The answer is that billing isn't one problem — it's several, and they compound. In Chapter 16, we learned how to store the permission to charge a customer's card. Now we tackle the harder question: how do you figure out what to charge?

Subscription vs Usage-Based vs Hybrid Billing

Billing models differ significantly, and understanding the differences matters because each model puts different demands on your billing engine.

Subscription Billing

The simplest model: charge a fixed amount on a fixed schedule. Alex Chen's S$9.99/month MelodyBox consumer plan is a textbook subscription. The price doesn't change (unless MelodyBox raises it), the billing date is predictable, and the calculation is trivial — charge S$9.99 on the first of every month.

But even "simple" subscriptions get complicated fast. What happens when a customer upgrades mid-cycle? Downgrades? Adds seats? Cancels with 12 days left in their billing period? Each of these events requires proration — calculating the fair charge for partial periods. We'll dig into proration mechanics later in this chapter, but for now, know that it turns a "simple" billing model into one that requires date math, plan comparison logic, and careful handling of credits.

Subscription billing gives the business high revenue predictability. You know roughly what next month looks like. The trade-off is that the customer pays the same whether they use the product heavily or barely at all — which can feel misaligned if usage varies significantly.

Usage-Based Billing (Pay-As-You-Go)

At the opposite end of the spectrum: charge based on what the customer actually consumed. MelodyBox's developer API charges S$0.02 per call. Meridian Corp made 14,237 calls this month, so they owe S$284.74. Next month, if they make 50,000 calls, they'll owe S$1,000.

Usage-based billing — sometimes called pay-as-you-go (PAYG) — aligns cost directly with value. Customers love it when they're small ("I only pay for what I use"), and it scales naturally with growth. Cloud providers like AWS, API platforms like Twilio, and infrastructure services like Snowflake have built enormous businesses on this model.

But usage-based billing introduces a fundamentally harder engineering problem: metering. You need to reliably count every billable event (API call, GB stored, minute streamed), attribute it to the correct customer and billing period, handle late-arriving or out-of-order events, and ensure the count is deterministic — if you run the calculation twice, you get the same answer.

Revenue predictability drops. The business can't easily forecast next month's revenue because it depends on customer behavior. And customers sometimes get bill shock — an unexpectedly high invoice because they didn't realize how much they were consuming.

Hybrid Billing

Increasingly, the answer is "both." MelodyBox for Teams charges a base subscription (S$500/month for 50 seats) plus usage-based charges for API calls above the included allotment. This is hybrid billing — a base commitment with a variable component.

Hybrid models are becoming the norm in B2B SaaS because they balance the interests of both sides. The business gets a predictable base revenue floor. The customer gets alignment between cost and value for the variable portion. And the pricing structure can include commitments, tiers, and overages that create natural upsell paths.

The trade-off? Hybrid billing is the most complex model to implement. Your billing engine needs to handle subscription logic (plan management, proration), usage logic (metering, rating, tiers), and the interaction between them (what counts as "included" usage vs. overage?).

Table 3: Billing Model Comparison. Each model places different demands on your billing engine. Most B2B products end up with a hybrid model.

The Billing Pipeline: Metering, Rating, Invoicing

Behind every invoice is a pipeline — a series of stages that transform raw activity into a number the customer owes. Understanding this pipeline is crucial because the stages need to be cleanly separated. Mix them up, and you'll build a system where a pricing change breaks your usage records, or a tax rule change requires reprocessing three months of metering data.

The billing pipeline has three core stages: metering, rating, and invoicing.

Stage 1: Metering — Counting What Happened

Metering is the process of reliably measuring customer activity. For MelodyBox's API, this means counting every API call Meridian Corp made, attributing each call to the correct customer account, and aggregating the count by billing period.

This sounds simple until you consider the edge cases. What happens when an API call arrives out of order — timestamped at 11:59 PM on the last day of the billing period, but delivered to the metering system at 12:03 AM the next day? What if the same event is delivered twice because of a network retry? What if the metering system goes down for 10 minutes — are those calls lost?

Good metering systems are idempotent (processing the same event twice produces the same result) and tolerant of late arrivals (events that arrive after the billing period closes can be attributed to the correct period or handled as adjustments). They use unique event IDs to deduplicate and store raw events separately from aggregated counts, so you can always recompute if something goes wrong.

For MelodyBox, the metering system ingests API call events from the product backend, deduplicates them by event ID, attributes each to a customer and billing period, and outputs a count: Meridian Corp made 14,237 API calls in January 2026.

Stage 2: Rating — Putting a Price on It

Rating converts metered usage into money. The rating engine takes the metered count (14,237 calls) and applies the customer's price plan to produce a dollar amount.

For a simple per-unit price (S$0.02/call), rating is multiplication: 14,237 × S$0.02 = S$284.74. But pricing is rarely that simple. Common pricing structures include:

Tiered pricing: The first 10,000 calls cost S$0.02 each, the next 10,000 cost S$0.015, and everything above 20,000 costs S$0.01. Meridian's 14,237 calls would be rated as (10,000 × S$0.02) + (4,237 × S$0.015) = S$200.00 + S$63.56 = S$263.56.

Volume pricing: The total volume determines the rate for all units. If Meridian's 14,237 calls fall in the 10,001–20,000 tier at S$0.015/call, the total is 14,237 × S$0.015 = S$213.56. Same usage, different answer than tiered pricing.

Committed usage with overage: Meridian's plan includes 10,000 API calls. Anything beyond that is overage at S$0.02/call. The first 10,000 are "free" (covered by the base subscription). The remaining 4,237 are charged: 4,237 × S$0.02 = S$84.74.

The critical design principle: rating must be separated from metering. Metering counts events. Rating prices them. If MelodyBox changes their API pricing next month, the raw event counts shouldn't change — only the rating output does. This separation also means you can backtest new pricing models against historical usage without reprocessing metering data.

Stage 3: Invoicing — Assembling the Bill

Invoicing takes the rated amounts, adds any recurring charges (the S$500 base subscription), applies adjustments (the proration from the mid-month upgrade), calculates tax, and produces the final invoice.

For Meridian's January invoice, the invoicing stage assembles four line items: the base subscription, the rated API usage, the proration adjustment, and Singapore GST. Each line item has its own source system — the plan catalog, the rating engine, the proration calculator, and the tax engine — but they all converge into a single invoice document.

Invoicing isn't just about generating a PDF. It's a workflow with states, rules, and downstream consequences. We'll cover the invoice lifecycle in the next section.

Diagram 3: The billing pipeline. Raw product events flow through metering (count), rating (price), and invoicing (bill) before reaching collection. A failed payment triggers the dunning loop from Chapter 15.

Invoice Lifecycle: It's a Workflow, Not a PDF

An invoice isn't a static document. It's a state machine — a workflow with defined states, transitions, and rules about what can happen at each stage. Understanding this is important because each state transition triggers downstream consequences: accounting entries, customer notifications, collection actions, and revenue recognition events.

Here are the states every billing system needs:

Draft. The billing team is still assembling the invoice. They can add, remove, or modify line items. Prices can change, tax can be recalculated, and nothing is locked yet. The customer doesn't see this invoice, and no accounting entries exist. Think of it as a working document on the billing team's desk.

Open. The billing system finalizes the invoice and sends it to the customer. This is the moment of truth: prices, tax rates, and line items lock. The system assigns an invoice number, generates the PDF, and delivers it (via email, dashboard, or API). Downstream systems kick in — the accounting system records a receivable, and the collection system schedules a payment attempt.

Finalization matters because everything after this point is auditable. You can't quietly change a line item on an open invoice. If something needs to change, you issue a credit note.

Paid. The customer (or their stored credential) has paid the full amount. The accounting system records the payment, the receivable is cleared, and a receipt is generated.

Void. You issued the invoice in error and need to cancel it entirely. Voiding creates a reversal entry in the accounting system. The original invoice number stays on the books for audit trail purposes, but the amount zeros out.

Uncollectible. The dunning process (Chapter 15) has exhausted all retry attempts, and the business decides to write off the amount. The accounting system records a bad debt expense.

Credit Notes and Adjustments

Credit notes are how you reduce the amount on an open or paid invoice without voiding the original. This is crucial for auditability — you need to show that an invoice was issued for S$1,066.34, and then a credit note reduced it by S$100, rather than pretending the invoice was always S$966.34.

Credit notes come up constantly in practice: you overcharged a customer, applied a promotional discount retroactively, or owe an SLA credit for a service outage. Each credit note references the original invoice and carries its own document number.

Account-level credits work differently. Instead of adjusting a specific invoice, they create a balance on the customer's account that's automatically applied to future invoices. MelodyBox might issue Meridian Corp a S$50 account credit for a service disruption, which reduces the next month's invoice by S$50.

Diagram 4: Invoice state machine. An invoice moves from Draft to Open (finalized), then to Paid, Void, or Uncollectible. Credit notes can adjust the balance at any point after finalization.

Tax: The First Thing That Breaks DIY Billing

If you're building a billing system and you think you can handle tax yourself, you're about to learn an expensive lesson. Tax calculation for digital services is one of the most complex problems in billing — and it's the number one reason teams abandon their homegrown billing systems for commercial platforms.

The core principle is deceptively simple. The OECD's destination principle says that tax on services should be levied where final consumption occurs — not where the seller is located. So when MelodyBox (headquartered in Singapore) sells a subscription to Meridian Corp (also in Singapore), Singapore GST applies. But when MelodyBox sells to a customer in Germany, German VAT applies. When they sell to a customer in Texas, Texas sales tax applies.

Simple in theory. Nightmarish in practice.

The first problem is place of supply — determining where the customer actually is. For digital services sold remotely, you can't just check a shipping address (there's nothing to ship). Instead, tax authorities accept proxies: the customer's billing address, their IP address at the time of purchase, the BIN (Bank Identification Number) of their payment card, or their declared country of residence. Singapore's IRAS (Inland Revenue Authority of Singapore) guidance for overseas vendors explicitly lists these proxies as acceptable evidence for determining whether a customer is in Singapore.

The second problem is rates and rules. Singapore's GST is a relatively simple 9% on most digital services. But the EU has 27 member states, each with its own VAT rate (ranging from 17% in Luxembourg to 27% in Hungary), plus reduced rates for certain categories. The US has over 13,000 tax jurisdictions with different sales tax rules. Some states tax digital services, some don't. Some cities add surcharges. It changes quarterly.

The third problem is registration thresholds. In many jurisdictions, you only need to collect and remit tax once you exceed a revenue threshold in that jurisdiction. Tracking which thresholds you've crossed, in which jurisdictions, and when — that's a compliance tracking problem on top of the calculation problem.

The practical takeaway: treat tax as a first-class line item with its own evidence trail and effective-date handling. Integrate a dedicated tax engine (Avalara, TaxJar, Stripe Tax, or your billing platform's built-in tax module) rather than hardcoding rates. And store the evidence used to determine the tax jurisdiction (IP address, billing address, card BIN) alongside each invoice — you'll need it if you're ever audited.

Proration, Credits, and Refunds

Proration is not an edge case. It's a core product behavior that happens every time a customer changes their plan mid-cycle.

Let's say Meridian Corp is on MelodyBox for Teams at S$500/month, billed on the 1st. On January 17th, they upgrade to the 80-seat plan at S$800/month. What do they owe?

Time-Based Pro-Rata

The most common approach: calculate the unused portion of the old plan and credit it, then charge for the remaining days on the new plan.

January has 31 days. Meridian used the S$500 plan for 16 days (Jan 1–16) and the S$800 plan for 15 days (Jan 17–31).

• Credit for unused old plan: S$500 × (15/31) = S$241.94
• Charge for remaining new plan: S$800 × (15/31) = S$387.10
• Net proration charge: S$387.10 − S$241.94 = S$145.16

This S$145.16 appears as a proration line item on the next invoice (or is charged immediately, depending on the billing engine's configuration). The S$193.55 on Meridian's actual invoice includes a slightly different calculation because their upgrade also changed the seat count, adding per-seat charges to the proration math.

Credits vs Refunds

When proration results in a credit (the customer downgraded, or the unused portion of the old plan exceeds the new plan charge), the billing engine has two options:

Account credit: The billing system holds the surplus as a balance on the customer's account and automatically applies it to the next invoice. No money moves back to the customer's payment method. This is simpler operationally and keeps the cash in the business.

Refund: You return the surplus to the customer's original payment method — crediting their card or initiating a bank transfer. This requires a reverse transaction through the payment system and has different accounting treatment (it reduces revenue rather than creating a liability).

Most billing platforms default to account credits for mid-cycle changes and reserve refunds for cancellations or explicit customer requests. The choice has accounting implications — a credit is a liability on your balance sheet until it's used, while a refund is a revenue reduction — so your finance team should weigh in on the default behavior.

Dunning as a Billing Engine Concern

In Chapter 15, we covered dunning as a payment recovery system — the retry logic, the customer notifications, the escalation sequences that kick in when a charge fails. But there's a perspective shift that matters as you think about your billing architecture: dunning isn't just a payment concern. It's a billing engine concern.

Consider what happens when Meridian Corp's monthly charge fails. The payment layer handles the retry — trying the card again after 24 hours, then 72 hours, then a week. But the billing engine controls the product experience: when to send the "payment failed" email, when to show a warning banner in the app, when to downgrade the account from 80 seats to read-only mode, and when to suspend service entirely.

These are business decisions, not payment decisions. The retry timing might be dictated by card network rules (as we covered in Chapter 15), but the customer communication, the grace period, and the service actions are billing engine controls. And they need to connect to the invoice lifecycle we covered earlier: a failed payment on an Open invoice might trigger a dunning sequence, while a failed payment on an invoice that's already been marked Uncollectible should not.

The practical architecture looks like this: Chapter 15's dunning state machine (Active → At Risk → Past Due → Recovered → Canceled) plugs into this chapter's invoice state machine (Draft → Open → Paid / Void / Uncollectible). A failed collection attempt on an Open invoice triggers the dunning state machine. If dunning succeeds (payment recovered), the invoice moves to Paid. If dunning exhausts all attempts, the invoice moves to Uncollectible, and the billing engine decides what happens to the customer's account.

The key insight: your billing engine and your dunning system need to be tightly integrated, not bolted together as an afterthought.

Operating Models: Build vs Buy, Single vs Multi-Gateway

MelodyBox's billing team is at a crossroads. They've been running consumer subscriptions on Stripe Billing, and it's worked well for S$9.99/month charges. But MelodyBox for Teams needs invoiced billing, usage-based charges, proration, and potentially multi-currency support for international expansion. Does the team keep building on Stripe, migrate to a dedicated billing platform, or build their own?

This decision — and the surrounding architectural choices — shapes the entire billing stack.

On-Us vs Off-Us

Some companies, particularly larger ones, maintain an internal ledger — an "on-us" system where customer balances, credits, and transactions are tracked on the company's own books before any external payment is involved. In an on-us model, MelodyBox could debit Meridian Corp's internal balance for the monthly charge and only reach out to the external payment system when the balance needs replenishment.

On-us gives you more control: you define the retry semantics, you own the reversal logic, and you can offer instant refunds (as credits) without waiting for payment network processing. The trade-off is engineering complexity and the regulatory obligations that come with holding customer balances in some jurisdictions.

Most companies operate off-us — every charge goes through an external payment processor. You inherit the processor's decline codes, settlement timelines, and scheme rules. It's simpler to start with, and for most businesses, it's the right default.

Single Acquirer vs Multi-Gateway

Running all payments through a single processor (Stripe, Adyen, or Braintree) is the simplest architecture. One integration, one dashboard, one set of decline codes to understand. But it concentrates risk: if your single processor has an outage, all your billing stops. And in a global business, a single processor might have stronger acceptance rates in the US but weaker performance in Southeast Asia or Latin America.

Multi-gateway architectures route transactions across multiple processors, either for redundancy (if Stripe is down, fall back to Adyen) or for optimization (route EU transactions through the processor with the best EU acceptance rates). This is where payment orchestration platforms enter the picture — tools like Spreedly, Primer, or built-in orchestration layers from larger PSPs that centralize multiple gateways into one control plane.

The boundary question is important: your billing engine owns pricing, plan management, and invoice state. Your orchestration layer owns payment routing, failover, and retry. Your token vault strategy must align with both — if you're using PSP-specific vault tokens, switching processors means re-collecting cards (as we discussed in Chapter 16). Network tokens (MPANs) are portable across processors, making multi-gateway architectures much cleaner.

Build vs Buy

The build-vs-buy decision comes down to two questions: Is your pricing logic a competitive differentiator? and Do you need a unified internal ledger?

If the answer to either is yes — if your pricing model is genuinely novel and can't be expressed in a standard billing platform's configuration, or if you need precise control over customer balances and inter-company settlement — building a bespoke billing engine may be justified. Companies like Uber, Airbnb, and Shopify have built custom billing systems because their marketplace economics demanded it.

For most companies, the answer is no. Commercial billing platforms (Stripe Billing, Chargebee, Recurly, Zuora) handle subscription management, usage-based billing, proration, tax integration, and dunning out of the box. They externalize compliance updates (tax rate changes, scheme rule changes) and offer battle-tested invoice workflows. Building from scratch means rebuilding all of this — and maintaining it perpetually.

MelodyBox's billing team evaluates the options and decides to stay on Stripe Billing for consumer subscriptions (it works, and migration risk isn't worth it) while adding Chargebee for the enterprise invoicing and usage-based billing needs. They accept the operational overhead of two billing systems in exchange for using the right tool for each use case.

Vendor Landscape

The billing and payments vendor landscape is crowded, and the terminology is confusing. The most important distinction: a billing engine (which manages plans, prices, invoices, and billing logic) is not the same as a payment processor (which moves money). They're complementary, and many vendors blur the line by offering both.

Here's a simplified landscape to orient MelodyBox's team — and yours.

Table 4: Billing and Payments Vendor Comparison. Pricing and features change frequently — treat this as directional guidance and verify current capabilities during evaluation.

The key takeaway isn't which vendor to choose — it's understanding what layer of the stack each one covers. If you need strong billing logic (proration, usage rating, invoice workflows), a dedicated billing engine like Chargebee or Zuora will serve you better than relying on your payment processor's basic subscription features. If you need broad payment method coverage and global acquiring, a payments platform like Adyen or Stripe will serve you better than a billing engine that only supports cards.

Building a Billing System That Lasts

After walking through the full billing pipeline, here's what separates billing systems that scale from those that break under their own weight.

The foundation is idempotent event ingestion. Every usage event should carry a unique ID, and your metering system should handle duplicates gracefully. Network retries, queue replays, and system restarts will all cause events to arrive more than once. If your metering layer counts them twice, your invoices will be wrong — and wrong invoices erode customer trust faster than almost anything else. Build deduplication into the ingestion layer from day one, not as a patch after your first billing dispute.

Separate metering from rating so that pricing changes don't corrupt your usage data. Raw usage records should be immutable — "Meridian Corp made 14,237 API calls in January" is a fact that doesn't change regardless of what you charge per call. When MelodyBox decides to change their API pricing from S$0.02 to S$0.015 per call, the rating engine should apply the new price to future periods while the historical metering data remains untouched. This separation also lets you backtest new pricing models against real usage data without reprocessing anything.

Treat tax as a first-class concern, not an afterthought. Store the evidence used to determine the customer's tax jurisdiction (billing address, IP address, card BIN) alongside each invoice. Maintain effective dates for tax rates so you can correctly calculate tax for invoices that span a rate change. And integrate a dedicated tax engine early — the cost of retrofitting tax handling into a billing system that assumed a single rate is far higher than doing it right from the start.

Design dunning as a state machine with explicit product hooks. Don't just retry the payment and hope. Define clear states (at risk, past due, recovered, canceled), attach customer communications to each state transition, and connect the dunning workflow to your invoice lifecycle. A customer whose invoice moves from Open to Uncollectible should experience a predictable, well-communicated journey — not a sudden service cutoff.

Finally, plan your token strategy for portability. If you're using a single payment processor today but might add a second one tomorrow (for redundancy, regional optimization, or cost), network tokens (MPANs) will save you from re-collecting every customer's card details. As we covered in Chapter 16, PSP-specific vault tokens are simpler to start with but lock you in. The migration cost of switching processors with non-portable tokens can be significant — in the worst case, it means emailing every customer and asking them to re-enter their card, and watching a slice of them never come back.

What's Next

We've now covered the full machinery of recurring and complex billing — from the billing pipeline (metering, rating, invoicing) through invoice lifecycles, tax calculation, proration, dunning integration, and the operating model decisions that shape your billing architecture.

Combined with Chapter 16's coverage of stored credentials, mandates, and card lifecycle management, you now understand both sides of the recurring payments equation: how to get permission to charge and how to figure out what to charge.

But everything we've discussed in Part IV has assumed — mostly — that the customer is paying with a card. Cards are the dominant rail for online recurring payments, but they're far from the only option. In much of the world, bank transfers, QR codes, digital wallets, and direct debits power a significant share of commerce. Each of these payment methods has its own rules, its own settlement mechanics, and its own billing engine implications.

In Part V, we'll explore these alternative payment methods — starting in Chapter 18 with bank transfers, real-time payments, and virtual accounts — and understand why "alternative" is a misnomer in markets where they're the primary way people pay.

Sources

• OECD International VAT/GST Guidelines (2017) — destination principle and place of supply for digital services
• IRAS (Inland Revenue Authority of Singapore) — GST overseas vendor registration guidance and customer location proxies
• Stripe Billing documentation — subscription lifecycle, usage-based billing, proration, and invoice management
• Chargebee documentation — subscription operations, credit notes, multi-gateway support
• Zuora documentation — billing pipeline architecture and enterprise billing models
• Recurly documentation — subscription management and dunning optimization
• PCI SSC Tokenization Guidelines — token portability and vault security requirements
• EMVCo Payment Tokenisation Specification — network token lifecycle and merchant-scoped tokens