SaaS revenue reconciliation

SaaS revenue reconciliation is the monthly, customer-level alignment of four sources: what was sold in the CRM, what billing invoices, what has been paid and what the accounts recognise as revenue. The aim is for every difference between those sources to have an explanation. Differences you can explain (timing, definitions) you leave in place. Differences you cannot explain are errors, and some of them are revenue you are missing.

Why don't SaaS figures reconcile by default?

A SaaS company has at least four numbers that are all called "revenue", and they are not supposed to be equal.

• Contracted ARR in the CRM: the annual value of what has been signed, often including contracts that have not started yet.
• Billed MRR or ARR in billing: what is currently running as a recurring subscription.
• Payments received: what has actually arrived in the bank.
• Recognised revenue in the accounts: what counts as income in this period under the reporting rules. An annual invoice paid in advance in January is recognised as revenue over twelve months. The rest sits on the balance sheet as deferred revenue.

So the question is not whether these numbers differ. They always do. The question is whether you can explain every difference. Reconciliation is the work that makes sure you can.

For the wider framework, in which CRM, billing and product usage are connected in SaaS, see Revenue Intelligence for SaaS.

Three kinds of difference

Every difference you find falls into one of three categories. It helps to label them that way from the start, because you handle them differently.

In the first month you reconcile, most differences are often definitional. That is not wasted time. Every definitional difference you resolve makes the next month faster, and finally makes your reports comparable. Which source should lead for which figure is covered in which data source leads for revenue.

The four reconciliations

1. CRM versus billing

Per customer: does the contracted value in the CRM match the subscription in billing? Look at unit price, quantity, discounts and term. This is the reconciliation where most revenue-costing errors sit, because the handover from deal to subscription is usually done by hand. How to approach this particular match is covered in detail in CRM-to-billing reconciliation explained.

Common findings:

• Closed deals without a subscription.
• Subscriptions without a matching deal (often older customers or manual renewals).
• Upsells recorded as a new deal in the CRM, but never applied as a change in billing.

2. Billing versus usage

Per customer: is product usage within what is being invoiced? With seat-based pricing you compare active users with billed seats. With usage-based pricing you compare the volume measured in the product with the volume on the invoice. Differences here are either untapped revenue (more usage than billed) or a signal of churn risk (much less usage than billed).

3. Billing versus payments

Per invoice: has it been paid, and does the amount paid equal the amount invoiced? Watch for partial payments, reversed direct debits and payments posted to the wrong account. An unpaid invoice on an active account is the most direct form of leakage: the customer uses the product and does not pay.

4. Billing versus the ledger

Per month: does the total invoiced reconcile with what has been booked as revenue and deferred revenue in the accounts (for example in Xero, NetSuite, Exact or AFAS)? This is where you find invoices created outside billing, credit notes that were never posted and differences in the period in which revenue is recognised.

The ARR bridge: one table that explains everything

A useful tool is the ARR bridge: a table that connects ARR at the start of the month with ARR at the end, through every movement in between.

Build this bridge twice: once from the CRM and once from billing. Where the lines differ, that is your work. If the CRM shows EUR 42,000 in expansion and billing EUR 28,000, then EUR 14,000 of upgrades has been sold that is not being invoiced, or there is a definitional difference in what counts as expansion. These are example amounts.

A monthly routine

This is a workable rhythm for a finance team doing it without specialist software.

1. Working days 1 to 3: export. Closed and changed deals from the CRM, all active subscriptions from billing, unpaid invoices, usage data per customer.
2. Working day 3: match. One row per customer, with the values from all sources side by side. This only works if you have a shared customer ID.
3. Working day 4: flag differences. Set thresholds. For example: every difference above EUR 50 per month per customer, or above 5 percent of the contract value.
4. Working days 4 and 5: label. Timing, definition or error. Only the errors go on to the next step.
5. Working day 5: assign an owner. Every error gets an owner and a deadline. Finance for invoice errors, sales for contract changes, customer success for usage above contract.
6. Working day 10: close. Which errors have been resolved, what amount has been recovered, what was the cause?
7. Every quarter: analyse causes. If the same kind of error comes back three months running, the problem is in the process, not in the execution.

Worked example: the first reconciliation

Suppose you have 350 customers and run a full reconciliation for the first time. You find 90 differences. These are example numbers, intended to illustrate the split.

• 45 are timing: contracts that started just before or after the month boundary.
• 25 are definitional: one-off fees included in ARR in the CRM.
• 20 are errors. Of those, 12 concern an invoice that is too low, on average EUR 180 a month, and 8 an invoice that is too high, on average EUR 90 a month.

The invoices that are too low together amount to 12 x EUR 180 x 12 = EUR 25,920 a year in revenue you will now invoice. The invoices that are too high together amount to 8 x EUR 90 x 12 = EUR 8,640 a year that you need to correct, and that you would rather find yourself than have the customer find. Both are gains: the first directly, the second in trust.

In the second month you find less, because the definitions are resolved and the old errors corrected. What remains are the new errors. That is the number you want to see fall.

Where does reconciliation get stuck?

No shared customer ID. If your CRM accounts cannot be matched one to one with billing customers, you spend most of your time matching on name. Solve this first, even if it feels like groundwork.

Too many differences without a threshold. A difference of EUR 0.40 due to rounding is not a finding. Without a threshold you drown in noise and the team gives up after two months.

No owner. A list of differences sitting in a shared folder does not get resolved. Every error has to land with a person.

Comparing only totals. If you only compare total ARR from the CRM and from billing, errors can cancel each other out. A customer paying too much and a customer paying too little offset each other in the total. Always reconcile per customer.

From manual work to continuous control

The monthly manual reconciliation is a good start, but it has a built-in delay: an error that arises on the second of the month is found a month later at the earliest. With recurring revenue, that is a month of leakage per error.

The next step is for the matching between sources to happen continuously, so that a discrepancy becomes visible on the day it arises. That can be done with your own data pipeline into a warehouse such as Snowflake, or with software that reads the systems directly. The logic stays the same as above: per customer, per source, with thresholds and an owner. Where most differences between billing and contract come from is covered in SaaS billing leakage. A similar approach for contract value in general is in how do you check contract value against realised revenue.

Frequently asked questions

What is the difference between revenue reconciliation and a bank reconciliation?

A bank reconciliation checks whether your accounts match your bank statement. Revenue reconciliation checks whether what was sold, invoiced, used and received line up, per customer. The first is about money that came in, the second also about money that should have come in.

How often should a SaaS company reconcile?

At least monthly, tied to the month-end close. Companies with a lot of usage-based pricing or many mid-term changes benefit from a higher frequency, because every week of delay is a week of leakage.

Should ARR in the CRM equal ARR in billing?

Not necessarily, but every difference must be explainable. The CRM may contain contracts that have not started yet. Billing may contain subscriptions that have been cancelled but are still running. As long as you can point to that per customer, the difference is fine.

Who owns revenue reconciliation?

Usually finance, because it ties in with the month-end close. But resolving the errors found often falls to sales or customer success. Agree in advance who resolves which kind of error, otherwise the list just sits there.