Why Your ARR and Your Financials Disagree

Why Your ARR and Your Financials Disagree

Short answer: ARR measures contracted recurring revenue at a point in time. Your income statement measures revenue earned in a period under accrual accounting. They are different questions, so they will never match exactly. The problem is when the gap is unexplained, because that is what turns a routine diligence question into a two-week fire drill.

The two numbers are answering different questions

ARR is a forward-looking run rate. It annualises what is currently contracted. It ignores when cash arrives, ignores when the service is delivered, and usually ignores anything non-recurring.

GAAP revenue is backward-looking and earned. It recognises revenue as the service is delivered, regardless of when the customer paid or what they are contracted for going forward.

An annual plan sold on 1 January for $12,000 is $12,000 of ARR immediately. It is $1,000 of revenue in January and $11,000 sitting on the balance sheet as deferred revenue. Both statements are correct.

The trouble starts when nobody can reconcile the two, because then neither number is trusted.

The four places the gap usually comes from

Deferred revenue. The big one. Cash arrives up front, revenue is earned over the term. If your accounting follows the cash, you have recognised a year of revenue in one month and your income statement is fiction.

Non-recurring revenue. Implementation fees, onboarding, professional services, one-off overages. These are real revenue and correctly excluded from ARR. A company with meaningful services revenue will always show GAAP revenue above the ARR run rate, and that is fine as long as it is explained.

Timing of starts and churn. ARR is a snapshot on the last day of the period. A customer who churned on the 28th is out of ARR entirely but contributed nearly a full month of revenue. A customer who started on the 29th is fully in ARR and contributed almost nothing.

Discounts and credits. ARR is frequently tracked at list or at contracted value while revenue is recognised net of credits, refunds and concessions. Every credit issued widens the gap.

None of these are errors. All of them need to be identifiable.

Where it actually bites

This does not usually surface as an accounting problem. It surfaces in one of three moments.

Diligence. An investor or acquirer asks you to bridge ARR to GAAP revenue. If you cannot produce that bridge quickly, the question stops being about the number and starts being about whether your reporting is reliable. That is a much worse conversation and it is hard to recover from.

A board meeting. You present ARR growth, someone opens the P&L, the two do not move together, and the next twenty minutes are spent explaining accounting instead of discussing the business.

Your own decisions. If you are pricing or planning headcount off ARR while your actual earned revenue is materially different, you are running the company on the wrong number.

Build the bridge before someone asks for it

The bridge is a short reconciliation, and having it standing takes the drama out of the question permanently. It runs roughly like this:

Start with opening ARR. Add new ARR from new customers, add expansion, subtract contraction, subtract churn, and you have closing ARR.

Then reconcile closing ARR to the period's recognised revenue: take the ARR run rate, divide to a monthly equivalent, then adjust for timing (partial months from starts and churn), add non-recurring revenue, and subtract credits and concessions. What remains should be your recognised revenue.

If it does not reconcile, the difference is the thing worth investigating, and it is usually one of three things: revenue being recognised on cash rather than delivery, deferred revenue not being released on the right schedule, or ARR being tracked at a value that does not match what was contracted.

The deferred revenue schedule is the control

Most of the discipline lives in one place: a deferred revenue schedule that ties to the balance sheet.

For each contract it carries the total contracted value, the term, the amount recognised to date, and the remaining balance. The sum of the remaining balances must equal the deferred revenue account on the balance sheet, every month, without adjustment.

If that never gets checked, deferred revenue becomes a plug account, and plug accounts always surface at the worst possible time.

Three checks worth running monthly:

1. Does the schedule total tie to the balance sheet account exactly?
2. Does the revenue released this month match the schedule's expected release?
3. Is there anything on the schedule with a term that has ended and a balance remaining?

The third one catches more errors than the other two combined.

The mid-term change problem

Upgrades, downgrades and mid-term cancellations are where most schedules break.

A customer on a $12,000 annual plan who upgrades to $24,000 in month seven is not simply a new $24,000 contract. The remaining deferred balance from the original contract has to be dealt with, the new arrangement recognised over its own term, and the ARR movement split correctly between expansion and new.

Handled poorly, this shows up as ARR growing faster than revenue with no explanation, which is exactly the pattern that makes an investor start asking harder questions.

What good looks like

• ARR is defined in writing, and everyone uses the same definition. Whether trials, discounts and non-recurring revenue are included is stated rather than assumed.
• A deferred revenue schedule exists and ties to the balance sheet monthly.
• An ARR-to-revenue bridge is produced as part of close, not built on request.
• Non-recurring revenue is tracked separately rather than mixed into the recurring line.
• One person can explain the gap in two minutes.

That last one is the real test. If the answer to "why is ARR $2.4 million and revenue $1.9 million" takes a week to assemble, the problem is not the gap.

Common questions

Is a difference between ARR and revenue a red flag? No. A difference is expected and normal. An unexplained difference is the red flag.

Does Stripe handle this for me? Stripe handles billing and can handle collection schedules. It does not decide your revenue recognition policy or maintain a deferred revenue schedule that ties to your balance sheet. Those are accounting judgments.

When should we start doing this properly? Before you need it. The cost of building the discipline is a few hours a month. The cost of reconstructing two years of it during diligence, under time pressure, is considerably higher and it happens at the moment you have least attention to spare.

We are pre-revenue on services, do we still need a deferred revenue schedule? If you bill anything in advance, yes. The size of the balance does not determine whether the control is needed.

Who should own this, the controller or the CFO? The controller owns the schedule and the accuracy. The CFO owns the definition and how it gets presented. If the same person does both, keep the two hats visibly separate, because the definition should not be able to move to make a number look better.

---

FynScale builds accounting operations for B2B software companies, including revenue recognition and the reporting that has to survive diligence. If your ARR and your financials do not currently reconcile, that is usually a fixable few weeks of work.