The ARR bridge writes itself. From the same data, every week.
Most SaaS finance teams produce three different ARR numbers in any given week. One comes out of Salesforce. One comes out of NetSuite. One comes out of the board model. They disagree by a few hundred thousand dollars and nobody is sure which is correct. The CFO picks the one that defends best. By the time the board sees it, the underlying contracts have already moved.
HarborOS produces one ARR number, derived from the contract base in Contracts. The ARR bridge is the diff between two locked snapshots. GRR, NRR, and customer retention come off the same query. The footnote is the contract list — not "ask the analyst."
It is the reporting layer PE firms have asked for since the term sheet, and the one every operator has assembled by hand until now.
ARR is supposed to be a single number. In most companies it is at least three.
The CRM reports a "closed-won ARR" that includes the implementation fee on a multi-year deal — booking value, not run-rate value. The ERP reports an invoice run-rate that lags the contract by a billing cycle, treats partial-period billings as full periods, and consolidates currencies against last quarter's FX. The board model reports whatever the analyst landed on last Friday. None of these are wrong. They are answering different questions. The board does not know that.
When PE asks for the bridge — starting ARR, plus new, plus expansion, less contraction, less churn, ending ARR — the analyst rebuilds it from scratch. The lanes are populated from memory, cross-referenced against the renewal sheet, reconciled against the CRM, and adjusted for the contracts that moved between the two reporting periods. It takes a week. The result balances to within a rounding error of the headline. The footnote is "ask the analyst."
The retention metrics — GRR, NRR, customer count, cohort retention, NDR by ARR band — are computed in separate models. They share inputs in principle, but the inputs have been transformed differently along the way. The retention deck and the ARR deck arrive at the board in the same email and quietly disagree about how many customers churned last quarter.
The methodology drifts every time someone new owns the report. The decision tree about how to treat a contraction with a co-terminous expansion is rebuilt from scratch, and the answer is not always the same one the company gave six months ago. PE notices. The board pretends not to.
One dataset. One ruleset. One bridge.
HarborOS treats ARR as a property of the contract base, not the invoice run rate. The bridge is the diff between two locked snapshots. The retention metrics are different views of the same dataset. The methodology is captured in Lighthouse and survives every personnel change.
ARR derives from the contract base — not the invoice run rate. Every active contract contributes to the base according to the rules in Lighthouse. Walk-in run rate is excluded. Implementation fees are excluded. Multi-year contracts contribute at the rate you defined — not at the ramp, not at the booking value, unless you say so. The base is a defined object, not a SUMIF.
The bridge is the diff. New, expansion, contraction, churn, and FX are lanes populated by the contracts that moved between two snapshots. The total reconciles by construction — starting ARR plus the lanes equals ending ARR. There is no truing-up, no plug, no rounding tab. The bridge balances because it is the diff, not because the analyst made it balance.
GRR, NRR, and customer counts come out of the same query. Gross Retention is the lane sum. Net Retention is the same denominator with expansion folded in. Customer count is the contract count. The retention metric and the ARR number agree because they were computed together — not because two analysts compared notes on a Thursday.
Multi-entity, multi-currency is solved at the contract. Each contract carries its own currency and the FX rate you chose to report at. Compass consolidates to a single ARR figure with a defensible per-region bridge underneath. UK contracts can be frozen at 1.25 GBP/USD for the board pack and live for the operating view — both, simultaneously, from the same source.
What changes when ARR is derived, not assembled.
| Before HarborOSThree numbers. One pick. | With HarborOSOne number. One source. |
|---|---|
| Three ARR numbers — Salesforce, NetSuite, board model. They disagree by $200K+ and nobody is sure which is right. | One ARR number, derived from the contract base. The CRM and ERP reconcile to it — not the other way around. |
| ARR bridge built manually every quarter. The lanes are populated from memory and reconciled by truing-up. | The bridge writes itself from the snapshot diff. The lanes are the contracts that moved. The total balances by construction. |
| GRR and NRR are computed in separate models. They share inputs in principle and disagree in practice. | GRR, NRR, and ARR come from the same query. Different views of the same dataset. |
| Multi-currency consolidated via VLOOKUPs against a static FX sheet. Last quarter's rate is buried in row 412. | FX is set on the contract record. The bridge respects it. Frozen or live, at the rate the CFO chose. |
| The footnote on the ARR slide is "ask the analyst." The methodology is undocumented. | The footnote is the contract list. Click a lane in the bridge and see the contracts that moved it. |
| Methodology drifts every time someone new owns the report. Co-terminous expansion is handled differently each quarter. | The methodology lives in Lighthouse. It is written down. It survives turnover. |
GRR, NRR, and the views PE actually asks for.
Every retention metric reads off the same locked snapshot. The definitions are documented, the computations are derived, and the views the board pushes for arrive without a two-week project. Cohort retention by signing quarter and net dollar retention by ARR band are not custom builds — they are Compass views.
Computed per cohort, per entity, per ARR band. Reported in the bridge as the lane sum. The denominator is the starting snapshot — not a moving average.
Same cohort, same denominator. Tied to the same dollar of churn that GRR is tied to. The two metrics cannot disagree by construction.
Logo count, not dollars. Read off the contract count at snapshot lock. The customer definition is whatever Lighthouse says it is — one row, not two reads.
The growth-efficiency tile the board asks for, computed off the same four lanes that build the bridge. A reading above 4× is healthy. A reading below 2× tells a story.
The cohort table PE always asks for, rendered on demand. Click a cell, see the contracts. No separate model. No two-week build.
The view PE pushes for at every board. The big-customer story and the long-tail story, on the same axis, in the same query.
One ARR number. One bridge. One source.
The contract is the source.
The bridge is the diff.
The retention metric agrees with the bridge.
Versioned every week. Locked every Friday.