The night before our board meeting, the ARR report didn’t tie out.

An ARR report that does not tie is not a reporting inconvenience.

It is a trust problem.

And in SaaS, it usually exposes something deeper than one broken formula.

CRM says one thing. Billing says another. The general ledger recognizes revenue on its own schedule. A spreadsheet sits between them trying to make everyone behave.

Then somebody asks, “What is ARR?”

Finance should be able to answer without choosing a favorite system.

ARR needs a definition before it needs a dashboard

Annual recurring revenue sounds obvious until a company starts growing.

Do we include contracted revenue that has not started? Usage? One-time implementation? Month-to-month customers? Discounts? Currency movements? Paused subscriptions?

I want the definition written before I reconcile the systems.

Otherwise each system may be “right” according to a different rule.

A reconciliation cannot repair a definition nobody agreed on.

CRM and accounting answer different questions

CRM is usually designed around selling.

Accounting is designed around financial records.

Billing is designed around invoicing and collections.

I do not expect those systems to contain identical representations of the customer relationship.

I do expect Finance to understand the bridge.

A closed-won opportunity is not automatically recognized revenue. A contract value is not automatically ARR. An invoice schedule is not the same as revenue recognition.

The differences are legitimate until they become unexplained.

I would build the bridge at the customer or contract level

When totals disagree, staring at totals is not very productive.

I want the underlying population.

Customer ID. Contract or subscription. Start and end dates. Recurring amount. Billing frequency. Product. Status. Renewal. Cancellation.

The exact fields depend on the business.

The point is traceability.

Can I take the ARR total and explain how each material component connects to the commercial record?

If not, the dashboard is summarizing uncertainty.

Stable identifiers matter more than company names

Names change.

Customers have subsidiaries. CRM users type abbreviations. Billing may use a legal entity while Sales uses a brand.

If the systems share a stable customer or contract identifier, reconciliation becomes much easier.

If they do not, Finance ends up maintaining mapping logic.

That can work, but I treat the mapping as controlled data, not an analyst’s personal collection of VLOOKUP exceptions.

Bookings, billings, revenue and ARR should not be forced to match

This is where a lot of SaaS reporting gets into trouble.

These measures describe different economic events.

Bookings can represent a commercial commitment. Billings represent invoices. Revenue follows recognition rules. ARR is a management metric representing recurring run-rate value under a defined methodology.

If they always match, I get suspicious.

The objective is not equality.

It is a bridge that explains timing and classification.

Deferred revenue is part of the story, not the ARR definition

Deferred revenue can help explain the relationship between billing and recognized revenue.

It does not by itself tell me ARR.

A customer can prepay annually, bill monthly, or have a contract with implementation components that affect accounting differently.

I want the revenue-recognition schedule reconciled to Accounting and the recurring commercial metric reconciled to the subscription population.

Then Finance can explain how the two relate.

Renewals are where data quality gets exposed

New business tends to get attention.

Renewals often reveal whether the operating data model is mature.

Did the old contract terminate? Did the new contract replace it or stack on top? Was an expansion recorded separately? Did a downgrade change quantity, price or product?

If those events are not represented consistently, ARR bridges develop unexplained “adjustments.”

I do not like recurring adjustments that nobody can define.

That is usually a process asking to be fixed.

I want a beginning-to-ending ARR bridge

Beginning ARR plus new business plus expansion minus contraction minus churn, with any other category explicitly defined, should explain ending ARR.

The categories should be mutually understandable and reconcilable.

If an account expands and churns different products, decide how the bridge represents it.

If currency affects reported ARR, decide whether that is operating movement or FX.

The bridge is valuable because it turns a static KPI into a story of change.

Every adjustment needs an owner and a reason

Manual adjustments are not automatically bad.

Sometimes a system cannot represent a legitimate business event cleanly.

But an adjustment should have documentation, an owner and a plan if it recurs.

“Miscellaneous ARR adjustment” is not a category I want growing quarter after quarter.

That is where reporting debt accumulates.

Reconciliation should happen before the board deck

This sounds obvious.

Yet teams often discover metric disagreements while preparing executive materials because that is the first moment all the numbers appear together.

I prefer a recurring reconciliation process.

CRM population to billing population. ARR bridge to approved definition. Revenue-related balances to Accounting. Material exceptions reviewed before reporting production begins.

The board deck should consume trusted metrics.

It should not be the control that discovers whether they are trusted.

I would track exceptions, not just totals

A total can tie while individual records are wrong in offsetting directions.

I want exception reports.

Contracts in CRM with no billing record. Billing customers with no mapped CRM account. Active subscriptions past their end date. Negative recurring values. Duplicate subscription IDs. Material ARR changes without an identified movement category.

Those checks make the process scalable because Finance reviews what is unusual instead of manually rebuilding everything.

Ownership should follow the source

Sales Operations may own CRM hygiene. Billing or Accounting may own invoice setup. Finance may own the ARR definition and management bridge.

I like clear ownership because reconciliation issues otherwise become “Finance data problems.”

Finance can coordinate the truth.

It should not become permanent janitorial staff for every upstream process.

The model can be right while the data is wrong

This is one of the more dangerous states because the workbook behaves beautifully.

Every formula works. Every chart refreshes. Every total adds.

The source population contains duplicates, stale statuses or missing changes.

That is why model QA and data QA are separate disciplines.

A correct formula applied to incorrect data is still a wrong report.

I care about lineage

When someone asks where ARR came from, I want a short answer.

Here is the definition. Here is the source population. Here are the movement rules. Here is the reconciliation. Here are the current exceptions.

That is considerably more confidence-inspiring than “the dashboard pulls it automatically.”

Automation is useful.

Lineage is what makes automation trustworthy.

The real objective is not a number that ties once

I want a process that keeps tying as the company changes.

New products. New billing terms. Acquisitions. International expansion. Pricing changes. Contract amendments.

Each can stress the definition and the data model.

Finance should review whether the metric architecture still represents the business rather than adding another adjustment every time reality invents something new.

Trust is built before the meeting

A board should be able to challenge the business implications of ARR without spending the meeting debating which ARR is real.

That is the standard I care about.

Not a dashboard with perfect formatting.

A metric with a definition, a bridge, a source and enough controls that Finance can explain every material difference.

Peace of mind is not believing errors never happen.

It is knowing the process will surface them before they become the story.

ARR concentration should reconcile to the same population

Once I trust the ARR population, I want other SaaS metrics to derive from the same controlled data where practical.

Customer concentration, product mix, renewal schedules and cohort analysis should not each begin with a different export.

That is how a company ends up with three versions of its top ten customers.

A governed recurring-revenue dataset can support multiple management views while preserving one underlying population.

The presentation changes.

The customers should not.

Contract amendments need explicit treatment

Real contracts do not always wait politely for renewal.

Customers add products midterm, reduce seats, extend terms, receive credits or renegotiate pricing.

The ARR methodology needs rules for those events.

When does the change enter ARR? How is contraction separated from churn? Does an early renewal create a new contract record or modify the old one?

I want those rules decided before the unusual transaction arrives in a board quarter.

Otherwise policy gets invented while everyone is staring at the number.

Acquisitions make weak metric architecture obvious

Combine two SaaS companies and suddenly “ARR” may mean two different things.

One includes certain usage revenue. The other does not. One measures at month-end. The other uses daily values. Product hierarchies differ. Customer identifiers collide.

Finance has to decide whether to harmonize history, preserve legacy definitions temporarily or present a bridge.

There is no magic answer.

There is a requirement to be explicit.

Adding two numbers with the same label does not guarantee they measure the same thing.

Foreign currency needs a policy too

For international SaaS businesses, reported ARR can move because exchange rates move even when no customer changes behavior.

I like separating constant-currency operating movement from FX when the effect is material.

Otherwise the ARR bridge can imply expansion or contraction that did not occur commercially.

Again, the right methodology depends on what management is trying to understand.

The important thing is consistency and a clear bridge to reported figures.

Metric governance should survive employee turnover

If the only person who understands the ARR logic leaves, the company should not have to rediscover its recurring revenue.

I want definitions, movement rules, source ownership, key mappings and reconciliation procedures documented enough that another capable finance person can reproduce the result.

This is not documentation for documentation’s sake.

It is protection against institutional memory walking out the door.

Important KPIs deserve the same respect we give important financial processes.

Auditability becomes more important as the company scales

At 40 customers, someone can inspect every account.

At 4,000, the process has to become exception-based.

That means stronger data rules, automated checks, clear movement categories and thresholds for review.

Scale should reduce the amount of manual touching, not the amount of evidence.

I want Finance reviewing exceptions because the system proves the ordinary population behaved as expected.

The ARR forecast should start from the reconciled base

This sounds basic and is surprisingly powerful.

If the opening ARR balance in the forecast does not reconcile to the management metric, every future period inherits the disagreement.

Before modeling new business, churn and expansion, I want the starting population tied.

Then forecast assumptions can operate on something real.

A sophisticated retention model built on an unreliable opening base is still a sophisticated rumor.

The metric should help management make a decision

I do not want ARR governance to become a finance hobby.

The purpose is to help management understand recurring growth, retention, concentration and future revenue capacity.

If the definition is so complicated that nobody outside Finance can understand movement, we may have overengineered it.

A strong metric is rigorous enough to be trusted and simple enough to be used.

That balance is harder than it sounds.

When ARR does not tie, I would resist the quick plug

There is always pressure to make the deck work.

A manual adjustment can get the number over the finish line.

Sometimes that is necessary.

But I would preserve the exception and investigate it after the deadline.

The dangerous moment is when the plug becomes part of the recurring process and nobody remembers what it represents.

Temporary fixes need expiration dates.

Finance has enough permanent temporary solutions already.

A clean ARR process makes the forecast conversation better

Once the opening metric is trusted, management can spend its time on the uncertain part.

What do we expect from renewals? Where is expansion changing? Which cohorts are weakening? How much new business is realistic?

Those are legitimate forecast disagreements.

They are much more useful than spending the first fifteen minutes deciding whether beginning ARR is $48.2 million or $49.1 million.

History should be the stable part of the conversation.

The future gives us enough to argue about already.

That is why I treat metric reconciliation as decision infrastructure, not reporting housekeeping.