Every SaaS board pack contains two revenue numbers that disagree. ARR says one thing. The statutory P&L says another. Both are correct, and the gap between them is one of the more common sources of confusion in a growth-stage finance function.
The problem is not the difference. It is being unable to explain it on demand.
ARR is a forward-looking run rate: the annualised value of committed recurring contracts at a point in time. It is a management metric with no accounting standard behind it.
Recognised revenue is backward-looking and governed by AASB 15: what you actually earned during a period by satisfying performance obligations.
A customer who signs a $120,000 annual contract on 20 June adds $120,000 to ARR on that date, and roughly $3,300 to revenue for the June year. Nothing is wrong. They are answering different questions.
A defensible ARR-to-revenue bridge usually has to account for:
Most ARR disputes are not calculation errors. They are definitional gaps nobody closed.
Does ARR include a customer on a month-to-month contract? A twelve-month deal with a three-month out clause? A pilot that has converted verbally but not on paper? A reseller arrangement where you recognise net?
If three people in the business answer differently, you will eventually produce two board decks with different numbers, and the credibility cost lands on finance regardless of who was right.
The fix is unglamorous: write the definition down, get the CFO to approve it, publish it in the board pack, and configure reporting against it. Then the number is reproducible rather than assembled.
Three tests:
The bridge is a standing report, not a project. Opening ARR, new, expansion, contraction, churn, closing ARR — then the reconciling items to statutory revenue. Produced monthly, from the system.
Both numbers come from the same source. If ARR comes from the CRM and revenue comes from the ledger, they will drift, because the CRM records intent and the ledger records obligations. Deriving both from the contract record removes an entire class of disagreement.
Anyone can reproduce it. If only one analyst can rebuild the bridge, you have a key-person risk that becomes acute during due diligence.
Two moments raise the stakes sharply.
The first serious audit, where the deferred revenue balance is tested against the contract population. The second is due diligence, where a buyer or lead investor will rebuild your ARR from raw contracts and ask about every difference. Neither is a good time to discover that the definitions were never agreed.
We build this bridge as part of implementation rather than leaving it as an afterthought — agreeing the definitions, configuring the reporting, and making sure ARR and revenue derive from the same contract data.
If you are heading into an audit or a raise and the two numbers currently live in different systems, that is worth sorting out before someone else asks.