Revenue reconciliation for SaaS: closing the billing-to-books gap
Your billing system says a customer paid $1,000. Your processor settled $970. Your ledger recognized $1,050. None of those three numbers is wrong on its own.
Your billing system says a customer paid $1,000 this month. Your payment processor settled $970 after fees and a mid-cycle downgrade. Your general ledger has $1,050 recognized, because the invoice included a proration credit that never made it back to the accounting system. None of these three numbers is wrong on its own. They just describe the same transaction from three different vantage points, and nobody has sat down to make them agree.
That gap is what revenue reconciliation closes. For a subscription business, it is not a once-a-year accounting chore. It is the ongoing discipline of proving that what you billed, what you collected, and what you recognized as revenue all describe the same underlying set of transactions.
Quick answer
Revenue reconciliation for SaaS is the process of comparing three separate records of the same revenue event, billed amounts from your subscription/billing system, collected cash from your payment processor and bank, and recognized revenue in your general ledger, to confirm they tie out. It matters more for subscription businesses than one-time-sale businesses because proration, mid-cycle plan changes, retried failed payments, refunds, and multi-year deferred revenue schedules create timing gaps between the three records that don't exist in a simple one-time purchase.
What revenue reconciliation actually means for a subscription business
Revenue reconciliation is often confused with revenue recognition, but they answer different questions. Revenue recognition is the accounting rule that decides when revenue can be recorded, spread evenly across a subscription term under ASC 606 rather than booked all at once when cash arrives. Revenue reconciliation is the operational check that confirms your records actually reflect what the recognition rule says they should. One is a policy. The other is a proof.
For a subscription SaaS business, that proof runs across three separate ledgers:
- Billed revenue: what your billing or subscription platform says a customer owes, based on their plan, usage, and any mid-cycle changes.
- Collected revenue: what your payment processor actually settled into your bank account, net of processing fees, currency conversion, and failed-then-retried charges.
- Recognized revenue: what your books say you earned in a given period, spread across the subscription term according to ASC 606.
When all three agree, your close is clean and your MRR and ARR dashboards can be trusted. When they don't, you have a reconciliation problem, and it's worth being specific about that distinction: this is different from the more general question of where revenue leaks out of a subscription business in the first place. Reconciliation is what catches the leak. It doesn't cause it.
Why this is harder for subscription businesses than one-time sales
A retail business sells a product, collects payment, and the transaction closes. A subscription business never really closes a transaction; it just keeps adjusting one. That creates several sources of mismatch that don't exist in simpler businesses.
Proration on mid-cycle plan changes
When a customer upgrades or downgrades mid-cycle, the invoice reflects a prorated credit or charge for the partial period. If that proration logic lives only in the billing system and doesn't sync cleanly to the general ledger, the recognized-revenue schedule and the billed amount drift apart immediately.
Retried failed payments
A card decline doesn't mean the invoice goes away. Most billing systems retry the charge over several days under a dunning schedule. Until the retry succeeds (or the subscription is canceled), you have a billed amount with no matching collected amount, and if your reconciliation process only runs monthly, that gap can sit unexplained for weeks.
Multi-currency settlement
A customer in the EU pays in euros. Your processor converts to your home currency at its own rate, nets out its fee, and settles a figure that will never exactly match what your billing system recorded at invoice time. Multiply that across every non-domestic customer and the discrepancies compound.
Deferred revenue schedules
Annual contracts paid upfront create a deferred revenue balance that has to be recognized ratably over the contract term, a process covered in more detail in how deferred revenue works under ASC 606. If a contract is modified mid-term (a seat expansion, a plan change), the recognition schedule has to be rebuilt, and if that rebuild doesn't happen consistently, recognized revenue quietly stops matching either the original invoice or the amended one.
Refunds and credits
A refund needs to flow backward through all three ledgers: the billing system, the processor, and the books. Because each system processes the reversal on a different timeline, a refund issued today can show up as a temporary mismatch for several days before it resolves itself, and a process that isn't built to expect that will flag it as an error every time.
The three-ledger reconciliation process
A workable reconciliation process treats billed, collected, and recognized revenue as three inputs that need to be actively matched, not three reports that happen to exist.
1. Start from one subscription record. Every invoice, every proration event, and every plan change should trace back to a single subscription record rather than being re-entered separately into billing, CRM, and accounting tools. This is the single biggest lever for reducing mismatches, because most reconciliation problems start as data-entry problems between disconnected systems rather than genuine cash discrepancies.
2. Match billed to collected on a defined cadence, not just at month-end. Compare what was invoiced against what actually settled, accounting for processing fees, FX differences, and retry timing. Ordway Labs' breakdown of why SaaS payments don't match invoices lays out eight distinct causes, from partial payments to settlement timing gaps, and notes that the operational cost isn't just the reconciliation work itself but the wasted AR cycles chasing down each one.[1]
3. Match collected to recognized on the same cadence. This is where deferred revenue balances and ASC 606 schedules have to line up against what actually hit the bank. A payment that settles in a different accounting period than it was invoiced doesn't break recognition on its own, but it's exactly the kind of timing gap that makes a close take longer than it should.[2]
4. Investigate every exception, not just the large ones. Small, unexplained mismatches are rarely random. According to Optimus's breakdown of billing reconciliation at scale, a 1 percent mismatch rate across 1 million transactions produces 10,000 individual errors, and a 2 percent mismatch on $10 million in monthly revenue works out to a $200,000 reporting gap.[3] Neither starts as a $200,000 problem. Both start as a handful of unexplained differences that nobody chased down.
5. Run it continuously, not annually. Dodo Payments' guide to SaaS payment reconciliation frames daily reconciliation as the standard to aim for, because catching a mismatch within 24 hours is a five-minute fix, while catching it during a year-end audit means reconstructing months of records from memory.[4]
Signs your reconciliation process is already broken
A few patterns are reliable warning signs, even before anyone has run a formal audit:
- Your finance team spends more time each close explaining why MRR moved than confirming that it moved correctly.
- Failed-payment retries and dunning outcomes live in the billing system but never make it into the revenue reports finance actually uses.
- Deferred revenue balances are tracked in a spreadsheet that gets rebuilt by hand every time a contract is modified.
- Nobody can say, without pulling three separate exports, whether this month's collected cash matches this month's recognized revenue.
- Audit prep for revenue always turns into a multi-week reconstruction project rather than a documentation exercise.
Where a unified revenue platform closes the gap
Most of the reconciliation problems above trace back to the same root cause: billing, payments, and revenue reporting live in separate systems that were never designed to agree with each other. A subscription business running Stripe for payments, a separate billing tool for invoicing, a CRM for customer records, and spreadsheets to stitch it all together for the close is reconciling by hand, whether or not anyone calls it that. This is the same fragmented-stack problem covered in what actually belongs in a unified revenue stack.
Revvly addresses this by keeping subscription, billing, and revenue data in one system rather than three. Automated proration on mid-cycle plan changes means the billed amount and the recognition schedule update together instead of drifting apart. Automated invoicing ties every charge back to a single subscription record, so a retried failed payment is visible against the same invoice rather than appearing as an orphaned transaction. Accounts receivable tracking surfaces unresolved partial payments and failed charges as they happen rather than at month-end, and real-time MRR, ARR, and NRR dashboards are built from the same underlying data your invoices and payment records already agree on, rather than from a separate spreadsheet reconciliation. When it's time to hand records to an auditor or a board, CSV and Excel export gives finance a clean, matchable trail without a manual export-and-stitch exercise across three tools.
None of this replaces the judgment calls that reconciliation still requires, refund policy decisions, dispute resolution, or how to treat a disputed usage charge. What it removes is the structural cause of most mismatches: the same subscription event getting recorded slightly differently in three places that don't talk to each other.
Frequently asked questions
What is revenue reconciliation in SaaS? It's the process of comparing billed revenue (from your subscription/billing system), collected revenue (from your payment processor and bank), and recognized revenue (from your general ledger) to confirm all three describe the same transactions accurately. When they disagree, reconciliation is how you find out why.
How is revenue reconciliation different from revenue recognition? Revenue recognition is the accounting rule for when revenue can be recorded, typically spread over a subscription term under ASC 606. Revenue reconciliation is the operational process that verifies your actual records match what that rule says they should show. Recognition is policy; reconciliation is proof.
What causes revenue reconciliation mismatches in subscription businesses? The most common causes are proration from mid-cycle plan changes, retried failed payments, currency conversion differences on international payments, processing fees netted out before settlement, and refunds or credits that move through billing, payment, and accounting systems on different timelines.[1][3]
How often should a SaaS company reconcile revenue? Daily or weekly reconciliation catches discrepancies while the context is still fresh and easy to investigate. Monthly reconciliation is the most common default but means a mismatch that happened three weeks ago has to be reconstructed rather than simply explained.[4]
Can Stripe alone handle revenue reconciliation for a subscription business? Stripe accurately reports what it processed, but it only sees its own side of the transaction. It doesn't know what your billing system invoiced, how a proration credit should flow into your recognition schedule, or what your general ledger booked. Reconciliation requires comparing Stripe's settlement data against those other two records, not just reading Stripe's dashboard.
What's the difference between billed, collected, and recognized revenue? Billed revenue is what an invoice says a customer owes. Collected revenue is what actually settled into your bank account, net of fees and currency conversion. Recognized revenue is what your books report as earned in a given period under your accounting policy. A healthy reconciliation process keeps all three explainable against each other, even when they aren't identical in any given month.
How long does it take to build a reliable revenue reconciliation process? For a company already running subscription data through one unified system, most of the work is defining a matching cadence and an exception-review habit, which can be running within a few weeks. For a company reconciling manually across three or more disconnected tools, the first pass typically takes longer because it involves untangling how far the existing records have already drifted before a repeatable process can be layered on top.
Sources
- Ordway Labs, "Why Payments Don't Match Invoices in SaaS: Causes, Examples, and Fixes," 2026. https://ordwaylabs.com/blog/reasons-payments-dont-match-invoices-causes-examples-and-fixes/
- Orb, "The SaaS Founder's Guide to Revenue Reconciliation," by Alvaro Morales, 2026. https://www.withorb.com/blog/saas-revenue-reconciliation
- Optimus, "How Billing Reconciliation Impacts Revenue Accuracy and Financial Reporting," by Amrit Mohanty, May 4, 2026. https://optimus.tech/blog/billing-reconciliation-for-revenue-accuracy-and-financial-reporting
- Dodo Payments, "Payment Reconciliation for SaaS: Automate Your Financial Operations," by Ayush Agarwal, April 13, 2026. https://dodopayments.com/blogs/payment-reconciliation-saas
Frequently asked questions
What is revenue reconciliation in SaaS?
It's the process of comparing billed revenue from your subscription or billing system, collected revenue from your payment processor and bank, and recognized revenue from your general ledger to confirm all three describe the same transactions accurately.
How is revenue reconciliation different from revenue recognition?
Revenue recognition is the accounting rule for when revenue can be recorded, typically spread over a subscription term under ASC 606. Revenue reconciliation is the operational process that verifies your actual records match what that rule says they should show.
What causes revenue reconciliation mismatches in subscription businesses?
The most common causes are proration from mid-cycle plan changes, retried failed payments, currency conversion differences on international payments, processing fees netted out before settlement, and refunds or credits moving through systems on different timelines.
How often should a SaaS company reconcile revenue?
Daily or weekly reconciliation catches discrepancies while the context is still fresh. Monthly reconciliation is the most common default, but it means a mismatch from three weeks ago has to be reconstructed rather than simply explained.
Can Stripe alone handle revenue reconciliation for a subscription business?
Stripe accurately reports what it processed, but it only sees its own side of the transaction. Reconciliation requires comparing Stripe's settlement data against what your billing system invoiced and what your general ledger recognized.
What's the difference between billed, collected, and recognized revenue?
Billed revenue is what an invoice says a customer owes. Collected revenue is what actually settled into your bank account, net of fees and currency conversion. Recognized revenue is what your books report as earned in a given period under your accounting policy.
How long does it take to build a reliable revenue reconciliation process?
For a company already running subscription data through one unified system, most of the work is defining a matching cadence and an exception-review habit, which can be running within a few weeks. For a company reconciling manually across three or more disconnected tools, the first pass typically takes longer because it involves untangling how far the existing records have already drifted before a repeatable process can be layered on top.
Alain spent a decade building and scaling subscription businesses before founding Revvly. He writes about the infrastructure gap between what SaaS companies report and what they actually earn.