SaaS metrics for finance teams: ARR, NRR and burn multiple from the books

SaaS metrics such as ARR, net revenue retention (NRR) and burn multiple describe how a subscription business grows and how efficiently it spends. They are only useful if they reconcile to the accounts. ARR should be built from signed contracts, NRR from the same customer list over time, and burn multiple from the cash that actually left the bank, all traceable to the general ledger.

In many startups, the metrics come from the billing tool and the revenue comes from the tax advisor, and the two never meet. That works until an investor asks why ARR grew 40 percent while revenue in the annual accounts grew 15. This guide is about closing that gap, for companies that report under German commercial law (HGB).

---

Why do SaaS metrics and the books disagree?

Because they answer different questions from different systems. The billing tool knows subscriptions, prices and payment status. The ledger knows booked revenue, deferred revenue and costs. A spreadsheet in between tries to join them, usually by customer name, and breaks the first time a customer changes its legal entity or moves from monthly to annual billing.

The typical differences are predictable:

• Annual invoices. A customer pays 24,000 euros for a year in advance in March. ARR goes up by 24,000. Revenue for March, correctly booked, goes up by 2,000.
• One-off fees. Implementation, training or setup fees are revenue but not recurring revenue. If the billing tool counts them as part of the subscription, ARR is overstated.
• Consumption-based charges. Consumption revenue may be recurring in practice but variable in amount. Whether it belongs in ARR is a policy choice that has to be written down once.
• Credit notes and discounts. A discount given in a side email may never reach the billing tool, while the credit note reaches the ledger.

None of these is an error on its own. The problem is that nobody can explain the difference when asked.

How should you define ARR so it reconciles to revenue?

Define ARR as the annualised value of recurring contract revenue active on a given date, and write down what is excluded. A practical definition:

1. Take every active subscription contract on the reporting date.
2. Convert each to a monthly recurring amount, after agreed discounts, and multiply by twelve.
3. Exclude one-off fees and, unless your policy says otherwise, variable consumption above any committed minimum.
4. Count signed contracts that have not started yet separately, as contracted but not live.

Then build the bridge to revenue. Under HGB, payments received before the balance sheet date for a later period go into deferred income (passive Rechnungsabgrenzung, § 250 (2) HGB). For a subscription business, that means the revenue line in the profit and loss account shows the part of each contract that falls into the period, while the rest sits on the balance sheet. ARR divided by twelve should be close to monthly recurring revenue in the ledger. If it is not, the difference should break down into a few explainable items: new contracts mid-month, one-off fees, consumption charges, credit notes. If you also report under IFRS, the same logic applies with more detail on contract terms, which we cover in revenue recognition under IFRS 15 and HGB.

How do you calculate NRR and GRR without a spreadsheet?

Net revenue retention compares the recurring revenue from a fixed group of customers today with what the same customers paid twelve months ago. It includes expansion, contraction and churn. Gross revenue retention (GRR) uses the same group but ignores expansion, so it can never exceed 100 percent.

Both formulas are simple. The data behind them is not. You need to know, for each customer, the recurring amount at two points in time, and you need the customer to be the same customer at both points. That is where spreadsheets fail: a customer that signs a second contract under a subsidiary appears as a new logo, an upgrade booked as a new subscription looks like a new customer, and a downgrade combined with a price increase looks like no change at all.

The fix is to calculate retention from contracts linked to one customer record, the same record that receives invoices and payments. Then expansion is a contract change, churn is a contract end, and the cohort is defined once.

What does burn multiple tell you, and where do its inputs come from?

Burn multiple is net burn divided by net new ARR over the same period. If you burned 1.2 million euros in a quarter and added 600,000 euros of net new ARR, your burn multiple is 2. The lower the number, the less cash you spend for each euro of new recurring revenue.

It is a useful metric because it connects the growth story to the bank account. It is also easy to get wrong, because its two inputs come from different places. Net burn should be the actual change in cash from operations, taken from bank movements and the ledger, not the operating loss. Annual prepayments, VAT refunds and delayed supplier payments can all move cash in a way the profit and loss account does not show. Net new ARR comes from contracts. If either input is estimated in a spreadsheet, the ratio inherits the error. For the cash side, a 13-week cash flow forecast uses the same bank-based view of burn.

Why does the BWA show a different revenue from your SaaS metrics dashboard?

The BWA (the monthly management report from your tax advisor) shows what has been booked. Many tax advisors book outgoing invoices as revenue when they are issued and defer annual contracts only at year-end, in the annual accounts. In that case, a month with many annual renewals shows a revenue spike in the BWA, followed by months that look weak, while ARR stays smooth.

There are two ways to deal with it. Ask your tax advisor (Steuerberater) to book deferred revenue monthly, so the BWA follows the contracts. Or book the deferrals yourself in the system that holds the contracts and send the result to the tax advisor. Either way, agree on one revenue figure before it reaches the board, and show ARR next to it with the bridge, not instead of it. Our guide to board reporting covers how to present both, and financial KPIs for a growing company lists the metrics that sit alongside them.

How does Agent F calculate SaaS metrics from the ledger?

In Agent F, contracts, invoices, payments and the general ledger share one data model. The subscription that defines ARR is the same record that creates the invoice, the revenue booking and the deferral.

Revenue automation handles subscription, consumption-based and hybrid contracts. When a contract is signed or changed, Agent F creates the billing schedule and the recognition schedule under HGB or IFRS 15, and books deferred revenue monthly. ARR, NRR, GRR and churn are calculated from those contracts on live data, and the bridge to booked revenue is available at any date, without a CSV export from the billing tool. Burn comes from the connected bank accounts and the ledger. You can ask in plain language, for example why NRR fell last quarter, and get the customers and contract changes behind the number, as described in real-time financial reporting.

Every booking the system suggests carries a confidence score and waits for approval, and every change is recorded in the immutable audit trail. The DATEV export gives your tax advisor the same revenue figures your board sees.

To start, write your ARR definition on one page, including exclusions. Take last quarter's ARR and booked revenue and try to explain the difference in five lines or fewer. Then check whether your retention cohort uses the same customer list as your invoicing. If any of the three takes more than an afternoon, the metrics are not yet coming from the books.

Learn how Agent F works, or see it on your own contracts and revenue at agent-f.ai/demo.