Revenue leakage is quiet. It doesn’t generate a support ticket or trigger an alert. It just reduces the number that lands in your bank account, month after month, until someone runs a reconciliation and asks why the math doesn’t work.
In B2B SaaS, billing errors cluster in predictable places. The root cause is almost never fraud. It’s process gaps — workflows that depend on human memory, spreadsheet coordination, or implicit assumptions about how systems stay in sync. Here are the five we encounter most.
1. Treating the Invoice as a Document, Not a Record
The invoice that goes out to a customer is a PDF. The invoice that lives in your system should be a structured data record — every field queryable, every line item traceable to its source.
Most early-stage billing stacks don’t make this distinction. Invoices are generated, emailed, and archived. When a customer disputes an amount, your finance team reconstructs the context from email threads, CRM notes, and the billing platform UI. When the board asks for average days-to-pay segmented by contract tier, someone builds a spreadsheet.
The fix is straightforward: treat the invoice object as a first-class entity in your data model. Every line item should trace to a subscription record, a usage event, or a manual adjustment entry. Every invoice state transition — issued, viewed, paid, disputed — should be logged with a timestamp. You cannot audit what you cannot query.
2. Metered Billing Drift
If any part of your pricing is usage-based, there is always a gap between what customers consumed and what ended up on the invoice. This gap compounds over time if you don’t actively close it.
The sources of drift are predictable:
- Usage events arrive late from your metering pipeline and miss the billing window
- Proration logic for mid-cycle upgrades or downgrades applies the wrong dates
- Trial-to-paid conversions don’t cleanly reset the usage ledger
- Idempotency failures in event processing create duplicate records that aggregation silently drops
None of these failures announce themselves. They sit in your metering data and billing records as a quiet discrepancy.
The correct countermeasure is a reconciliation job that runs on a defined cadence — weekly at minimum, daily if your contract volumes justify it. For each billing period that closed in the window, compare your usage database aggregate against the invoice line item. Flag variances above a defined threshold for review. Document the threshold and who resolves exceptions.
Reconciliation is not an audit task. It’s an operational task. Run it like you run payroll: on schedule, with a clear owner, and with escalation criteria defined in advance.
This is the kind of process that should be deterministic — same inputs produce the same output, every billing cycle, with a verifiable record that it ran.
3. Dunning That Isn’t Calibrated to Your Customer Base
Payment failures are recoverable. Most of the time, a failed charge is a card that expired, a bank that flagged an unusual transaction, or an accounts payable team that updated a payment method without telling anyone. Dunning — the sequence of retries and notifications that follows a failure — determines how much of that revenue you actually collect.
Out-of-the-box dunning sequences are built for high-volume, low-touch transactions. For B2B companies with enterprise contracts — where a single invoice can represent significant revenue and the billing contact often doesn’t have unilateral authority to release payment — that default serves you poorly.
A more effective sequence for B2B:
Day 0: Payment fails → in-app notification + email to billing contact
Day 3: Retry charge + reminder email
Day 7: Retry + escalation to account owner (not just billing contact)
Day 10: Final retry + link to update payment method
Day 14: Downgrade to read-only access
Day 21: Suspension + 30-day data retention holdTwo elements teams commonly skip: the in-app notification (finance inboxes are noisy; product UI is not) and the escalation to the account owner (the billing contact may not have authority to act on a payment issue quickly). Instrument both and measure what each one recovers for you.
Configure your dunning sequence once, then review it quarterly against your payment failure data. Which step precedes most recoveries? Where do customers fall through? These questions have answers — but only if you instrument the process.
4. Payment Method Decay
Cards expire. Banks re-issue cards after security events. Companies replace corporate cards when employees leave. All of this happens continuously, across your customer base, without any notification to your billing system.
The practical consequence: some share of your stored payment methods goes invalid every month without anyone telling you. Payment failures that look like customer intent are often just stale card data.
Network tokenization addresses this directly. When you store a card token through a processor that supports network tokenization, the card network keeps your token current as the underlying card changes. A renewal that would have failed on an expired card succeeds instead. For Stripe, the relevant feature is automatic card updates; most major processors offer an equivalent Account Updater service.
Enable this if you haven’t. Audit your processor settings to confirm it’s active. Verify by looking at how many payment failures your dunning workflow is seeing on cards that were previously successful — that number should decrease.
5. No Audit Trail on Contract Changes
Enterprise B2B deals change constantly. Seats are added mid-quarter. Credits are negotiated at renewal. Custom payment terms are granted on request. Each of these changes affects what appears on an invoice and, downstream, what ARR your finance team calculates.
If contract changes aren’t recorded systematically — with a timestamp, who authorized the change, what the previous value was, and what it changed to — you end up with invoices that nobody can fully explain and ARR figures that don’t reconcile to cash.
The pattern we see repeatedly: a sales rep promises a credit in a Slack message. Finance doesn’t know about it. The customer sees the invoice without the credit, disputes it, and a three-week thread follows. The dispute is eventually resolved in the customer’s favor. But the time cost, the trust cost, and the accounting adjustment all compound.
Every material contract modification should create an immutable audit event in your system of record. This doesn’t require a sophisticated platform — a timestamped append to a structured log satisfies the requirement. What matters is that the record exists, that it’s tied to the subscription, and that it’s accessible to both finance and customer success without a Slack search.
These five patterns aren’t edge cases. They’re the standard state of billing operations at companies that grew faster than their finance infrastructure. The good news: each one is solvable with a defined process and the right instrumentation to verify it’s running correctly. None of them require replacing your billing stack.
The test is simple: can you answer the question “why does this invoice say this amount?” in under five minutes, for any invoice your system has ever generated? If not, you have a billing operations problem — and it’s costing you money.