The number
Eventually updated
ARR Change History
ARR is not just a number. It is a history.
Most finance teams can get to an ARR number.
The harder part is explaining how it changed, what evidence supports it, and what the business believed before the number moved.
HarborOS was built for that layer.
Contract-anchoredSnapshot historyMovement explained
ARR History · Belknap & HartReconciled to contract · Mar 14, 2026
CurrentARR position
$486K
+ $54K since Q4 snapshot
Movement history
+ $42K
+ $12K
held
− $18K
The Problem
The number eventually gets updated. The story has to be rebuilt.
ARR changes for a lot of reasons. Each one lands in a different place, on a different day, with the reason living somewhere other than the number.
A forecast changed three weeks ago, but the reason lives in a Slack thread or a spreadsheet comment. By the time someone asks “what changed?”, the evidence has scattered.
A customer renews lateStatus drifts
An expansion is signed mid-termBuried in an order form
A contraction is buried in an amendmentEasy to miss
A renewal is assumed until someone marks it churnedNo explicit signal
A forecast changed — the reason lives in a Slack threadOff-record
The story
Rebuilt from scratch
Why the stack doesn't cover it
CRM is good at intent. ERP is good at accounting history.
Neither one is built to preserve the full operating position of a contract over time. That leaves finance with the spreadsheet in the middle.
CRM
Good at intent.
Tracks the deal and the relationship — but not the contract's operating position once it's live, renewed, expanded, or contracted.
ERP
Good at accounting history.
Records what was invoiced and recognized — but not the renewal assumptions, churn treatment, or forecast version behind the movement.
The spreadsheet
It becomes the place where ARR, renewals, churn, expansion, assumptions, and board reporting get manually stitched together. That can work for a while. It gets harder when someone asks, “what changed?”
What HarborOS preserves
The ARR position and the evidence behind it, kept together.
So when ARR moves, finance is not starting from a blank reconciliation. The record already knows what changed.
Contract RecordLIVE · SNAPSHOTTED
Current ARR position
$486,000 · live
Contract source & terms
Master agreement + 3 amendments
Renewal status
Renewed · 12-mo term
Expansion & contraction history
4 movements tracked
Churn treatment
Explicitly marked, not assumed
Forecast assumptions
Per-snapshot, with rationale
Snapshot history
Q4 → W1 → W2
Movement explanations
Tied to contract evidence
The Operating Question
For every ARR movement, finance should be able to answer.
If the answer requires rebuilding the bridge from several files, the issue is not effort. It is architecture.
01What changed?
02When did we know?
03What contract evidence supports it?
04Was it included in the prior forecast?
05Did the board deck inherit the right version?
Built from the finance seat
The number was right, but the path to it was fragile.
I built HarborOS while running finance at a B2B SaaS company because I kept running into the same problem. The contract was the source of truth, but the ARR story lived everywhere else.
That meant every board cycle, renewal review, and reforecast carried the same risk: the number was right, but the path to the number was fragile.
HarborOS exists to make that path durable.
Jim Arkin
Founder, HarborOS
Who this is for
SaaS finance teams that own the revenue number — and need to explain it clearly.
✓
ARR is tracked across contracts, CRM, billing, and spreadsheets
✓
Renewal assumptions affect the forecast
✓
Expansion and contraction need to be separated cleanly
✓
Board reporting depends on manual bridges
✓
Prior forecast versions are hard to reconstruct
✓
Finance is the last line of defense before the number leaves the building
Try it free
See how an ARR movement ties back to the contract.
I can walk through the workflow using a contract record, prior snapshot, and movement history.