ARR that cannot be reproduced
The figure comes from a finance spreadsheet with manual adjustments, so restating a prior period or explaining a movement requires archaeology.
Technology
Reproducible ARR and retention, with product usage joined to revenue at account grain.
Every SaaS company reports ARR, and remarkably few can reproduce last quarter's figure exactly. Mid-term upgrades, multi-currency contracts, usage overages, partial churn and contracts signed on the last day of the quarter each need a rule, and the rules have to be the same ones used in the board pack a year ago.
- ARR and retention figures reproducible for any historical date
- Product engagement joined to revenue at account grain
- Churn signals early enough for the customer team to act
- A board pack that survives diligence without rework
We build the revenue model that makes that reproducible: contract-level subscription facts with effective dating, movement analysis that decomposes growth into new, expansion, contraction and churn, and currency handling with a stated rate policy.
Then we join product usage to it, which is where the interesting questions live: which behaviours in the first thirty days predict renewal, which features correlate with expansion, and which accounts are quietly disengaging before they churn.
What goes wrong
Recurring failure modes in technology
Product analytics isolated from revenue
Usage data in a product analytics tool with no account-level join to contracts, so engagement cannot be related to money.
Churn defined inconsistently
Logo churn, revenue churn and gross versus net retention used interchangeably in the same deck, which makes external reporting indefensible.
Multi-currency contracts distorting growth
Contracts in several currencies translated at inconsistent rate dates, so reported growth includes an unlabelled FX effect.
Metrics
Metrics and their definition errors
Each metric with its definition and the error that most often distorts it. If our reading is wrong for your business, that disagreement is a productive starting point.
| Metric | Definition | The trap |
|---|---|---|
| Annual recurring revenue | Annualised value of committed recurring subscriptions at the measurement date. | Decide explicitly whether usage overages and one-off services are included, and never change it silently. |
| Net revenue retention | Revenue from a cohort at period end over the same cohort at period start, excluding new customers. | Cohort definition and treatment of downgrades then re-upgrades within the window change the figure materially. |
| Gross revenue retention | As net retention but excluding expansion, so it cannot exceed 100 per cent. | Must be reported alongside net retention; net alone hides a weak base. |
| CAC payback | Fully loaded acquisition cost over new gross margin per month. | Which sales and marketing costs are loaded in, and whether expansion counts as acquisition, must be fixed and documented. |
| Product-qualified engagement | Composite score of usage depth, breadth and recency at account level. | Needs to be validated against actual renewal outcomes or it is a vanity index. |
Use cases
What we typically build
Revenue and ARR model
Contract-level subscription facts with effective dating, full movement analysis, and a stated FX policy, reproducible for any historical date.
Cohort retention analytics
Logo and revenue retention by signup cohort, segment and plan, with survival curves rather than single-period rates.
Product usage warehouse
Event data landed and modelled at account and user grain, joined to contracts, so engagement and revenue sit in one model.
Churn and expansion prediction
Models on usage, support and billing signals, with precision and recall reported honestly and a defined action for each score band.
Board and investor reporting
A reporting pack with metric definitions attached, reproducible figures and a prior-period restatement log, the thing diligence actually asks for.
Pricing and packaging analysis
Plan migration, feature adoption and willingness-to-pay signals to inform packaging changes, with the revenue impact modelled before launch.
Integration
Source systems we connect to
- Billing and subscription platforms (Stripe, Chargebee, Zuora)
- CRM (Salesforce, Dynamics 365, HubSpot)
- Product event streams and analytics tools
- Support platforms (Zendesk, Intercom)
- Finance systems and the general ledger
- Marketing automation and ad platforms
- Cloud cost and telemetry data
Regulatory context
Regulatory context by market
- UK and EU GDPR for product telemetry and marketing analytics, including lawful basis for behavioural tracking
- EU: ePrivacy consent requirements for analytics cookies and SDKs
- Switzerland: revFADP for processing Swiss user data
- Financial reporting: IFRS 15 revenue recognition alignment between ARR reporting and statutory accounts
- Security assurance: SOC 2 and ISO 27001 evidence where analytics touches customer data
- EU AI Act transparency obligations where product features use AI models
Questions
Technology: common questions
A product analytics tool is excellent for behavioural questions inside the product and poor at anything requiring revenue, contract or support context. If your questions are all product-internal, keep the tool. The moment the question becomes "which behaviour predicts expansion revenue", you need the join, which means a warehouse.
By modelling contracts as effective-dated facts rather than storing a current-state snapshot, keeping a movement fact that decomposes each change, and fixing the FX rate policy, typically a monthly closing or budget rate, stated on the report. You can then compute ARR as at any date and explain every movement between two dates.
Yes. Where a dbt project exists we extend it rather than replace it, and focus on the semantic layer and definitions, which is usually where the inconsistency lives. We are not interested in re-platforming something that works.
As a separate, labelled component: committed recurring revenue and variable usage revenue reported both separately and combined, with the combined figure clearly marked. Folding volatile usage into ARR makes the metric unstable and gets challenged in diligence.
Services that apply here
Next step
Analytics work in technology
A 45-minute working session with an engineer rather than a sales call. You describe the problem; we set out what we would build, in what order, and what it is likely to cost.
Answered within one working day, by the engineer who would do the work