ARR Is Not ARR: Why Company KPIs Are Harder to Compare Than They Look

The normalization trap

Most financial-data systems are built to solve a familiar problem: different companies use different labels for economically similar concepts.

That works reasonably well for many accounting lines. Sales, Net sales, and Revenue can often be mapped into a common revenue concept while preserving the original label and source.

Company KPIs are harder because the same label can hide different calculations.

With ARR, the dangerous normalization is not:

different words
      ↓
same concept

It is:

same words
      ↓
assumed same concept

The database may look cleaner after the mapping while the economics become less faithful.

That is why KPI normalization needs two outputs at once:

CANONICAL FAMILY
What broad question does this metric answer?

            +

DEFINITION ATTRIBUTES
How did this company actually calculate it?

The first enables discovery and screening.

The second determines whether a comparison is valid.

ARR is a family of metrics, not one standardized field

ARR is especially useful for demonstrating the problem because the acronym sounds precise.

"Annual recurring revenue" appears to describe a single thing.

In practice, companies use it to answer related but different questions:

What is the annualized value
of the recurring business today?

But "today" can be constructed from very different inputs.

One company can answer with contract value.

Another with current-month revenue.

Another with recent consumption.

Another with active contract billings.

They all belong to the same broad analytical family: an annualized view of recurring business at a point in time.

But they are not interchangeable measurements, because they do not react the same way when the underlying business changes.

Consider a customer whose usage suddenly spikes.

A one-month run-rate metric can move immediately.

A 90-day usage metric moves more slowly.

A contract-value metric may not move at all.

Likewise, a customer approaching contract expiration can remain inside one company's ARR even when renewal is uncertain, while another company's measure may depend primarily on realized usage.

That means two companies can experience the same economic event and report different ARR behavior purely because their definitions differ.

CrowdStrike: ARR with an explicit renewal assumption

CrowdStrike's latest Q2 FY2027 10-Q defines ARR as the annualized value of its customer subscription contracts.

The important part is what happens around expiration.

CrowdStrike assumes that subscription contracts expiring during the following 12 months renew on existing terms.

And if a contract has already expired but renewal discussions are still active, the company continues including it in ARR until the customer says it will not renew.

Conceptually:

ACTIVE SUBSCRIPTION CONTRACT
        │
        ▼
ANNUALIZED CONTRACT VALUE
        │
        ├── expires within 12 months?
        │       assume renewal on existing terms
        │
        └── already expired?
                keep in ARR while renewal talks remain active

That makes CrowdStrike ARR partly a contract-state metric and partly a renewal-assumption metric.

The distinction matters.

Suppose a large customer reaches expiration on June 30 and renewal negotiations continue for another month.

Under CrowdStrike's disclosed methodology, that customer can remain in ARR during the negotiation period.

So ARR does not simply represent contracts with unquestionably committed future revenue.

It represents the annualized recurring subscription base under the company's stated renewal convention.

CrowdStrike reported ARR of $5.841 billion at July 31, 2026, compared with $4.657 billion one year earlier, an increase of 25%.

Its FY2026 annual filing reported ARR of $5.253 billion at January 31, 2026, compared with $4.242 billion a year earlier.

The methodology appears materially consistent in the filings reviewed from 2023 through 2026.

The important analytical point is not that CrowdStrike's approach is wrong.

It is that:

Primary sources:

• CrowdStrike Q2 FY2027 Form 10-Q, filed August 27, 2026
  SEC primary source ↗

• CrowdStrike FY2026 Form 10-K
  SEC primary source ↗

Datadog: one month of revenue and usage, annualized

Datadog's ARR construction is fundamentally different.

Its Q2 2026 filing defines ARR as annual run-rate revenue from subscription agreements.

The company calculates it by taking monthly run-rate revenue and multiplying by 12.

Monthly run-rate revenue includes:

• committed contractual amounts;
• additional usage;
• usage delivered under subscriptions with committed usage;
• and monthly subscriptions.

So the rough structure is:

CURRENT MONTH

Committed contractual amount
        +
Additional usage
        +
Usage delivered under committed-usage subscriptions
        +
Monthly subscriptions
        │
        ▼
MONTHLY RUN-RATE REVENUE
        │
       ×12
        │
        ▼
ARR

This has a very different response function from CrowdStrike's methodology.

If customer usage rises sharply in the current month, Datadog's annualized metric can reflect that usage immediately.

The company explicitly cautions that ARR and monthly run-rate revenue are not GAAP revenue and are not forecasts of future revenue.

That qualification is important.

A current-month usage spike can be annualized mathematically without implying the customer will repeat that usage for the next 12 months.

In other words:

Datadog's definition is also useful because the company does not report a single aggregate ARR value in the filing text reviewed.

Instead, ARR appears in secondary metrics such as customer thresholds.

At June 30, 2026, Datadog reported approximately 4,720 customers with ARR of $100,000 or more, representing 91% of total ARR.

A year earlier it reported approximately 3,850 such customers representing 89% of ARR.

That is analytically useful.

But it is not a substitute for a directly disclosed aggregate ARR value.

Primary source:

• Datadog Q2 2026 Form 10-Q, filed August 6, 2026
  SEC primary source ↗

MongoDB: commitments plus two different usage windows

MongoDB introduces another construction.

Its Q2 FY2027 filing says ARR combines:

1. expected revenue over the next 12 months based on contractual commitments; and
2. annualized actual Atlas usage.

For direct-sales Atlas customers, actual usage is annualized using the prior 90 days.

For other self-serve products, actual usage is annualized using the prior 30 days.

Professional services are excluded.

Conceptually:

MONGODB ARR

Contractual commitments
        +
        ├── Direct-sales Atlas
        │      prior 90 days of actual usage
        │      annualized
        │
        └── Other self-serve products
               prior 30 days of actual usage
               annualized

Professional services excluded

This is important because MongoDB is not merely blending contract and usage data.

It is using different usage windows for different populations.

That changes how quickly the KPI responds to business activity.

Imagine usage jumps sharply in July.

A 30-day measure can reflect most of that change immediately.

A 90-day measure dilutes July's increase with May and June.

Datadog's current-month annualization can react even faster.

So three companies can all experience identical underlying usage growth and still report different changes in "ARR" because the smoothing windows differ.

MongoDB's filing says the usage calculations assume no increases or reductions in usage or subscriptions.

That makes the metric a snapshot of the present run rate under a flat-usage assumption—not a forecast of expansion.

MongoDB does not report an aggregate ARR value in the filing text reviewed.

It does, however, disclose ARR-linked metrics.

At July 31, 2026, MongoDB reported:

• 2,999 customers above $100,000 ARR, versus 2,564 a year earlier;
• net ARR expansion rate of 122%, versus approximately 119% a year earlier.

Again, those are useful KPI observations.

They should not be mistaken for a disclosed total ARR series.

Primary source:

• MongoDB Q2 FY2027 Form 10-Q, filed September 1, 2026
  SEC primary source ↗

Progress Software: ARR that behaves more like a contract-and-billings measure

Progress Software is the most revealing example because it stretches the intuitive meaning of ARR.

Its Q2 FY2026 filing defines ARR using annualized revenue from active, contractually binding term-based contracts.

The included activity spans:

• maintenance;
• software upgrade rights;
• public cloud;
• on-premises subscriptions;
• managed services.

For annual and multi-year contracts, Progress annualizes contract value by dividing total contract value by the term in months and multiplying by 12.

It applies the same annualization logic to contracts shorter than one year.

That can produce ARR above the total value of the short contract.

For example:

6-month contract
Total value = $60

$60 ÷ 6 × 12
        =
ARR = $120

That is mathematically coherent as an annualized run rate.

But it highlights why ARR should not be mistaken for contracted revenue, recognized revenue, or cash.

The most unusual part: upfront-recognized license economics

For term-based licenses and on-premises subscription arrangements, Progress says the ARR calculation includes consideration allocated to the software license—even though that portion can be recognized upfront under ASC 606.

So one economic arrangement can simultaneously produce:

GAAP accounting
Software-license consideration recognized upfront

                and

ARR treatment
Contract consideration annualized across the contract term

Progress says its ARR generally aligns more closely with billings than with GAAP revenue.

That makes it fundamentally different from a monthly usage run-rate metric.

Why the SEC correspondence matters

In 2024, the SEC asked Progress how the metric worked.

The staff questioned:

• how committed amounts and additional usage were calculated;
• whether software-license value recognized upfront was included;
• how ARR differed from GAAP revenue;
• and how short-term contracts renewed.

Progress's responses clarified the methodology and said additional usage represented less than 0.1% of total ARR at the time discussed.

Subsequent filings use the name "Annualized Recurring Revenue" rather than "Annual Recurring Revenue."

The acronym remains ARR.

The later disclosure is more explicit about what the metric actually represents.

That makes Progress an unusually good example of why the definition vintage can matter alongside the metric value.

A historical-value caveat

Progress's FY2023 filing reported ARR of $574 million at November 30, 2023.

Its FY2024 filing later showed $578 million for that same date.

The reviewed disclosure does not explain the $4 million difference.

The safe conclusion is:

It would be unsafe to call that a restatement or infer the cause without additional evidence.

Progress later reported ARR of $842 million at November 30, 2024, up sharply from the prior year, with the company attributing much of the increase to the ShareFile acquisition.

That is another reminder that reported ARR growth is not automatically organic growth.

Primary sources:

• Progress Software Q2 FY2026 Form 10-Q, filed June 30, 2026
  SEC primary source ↗

• SEC comment letter, March 13, 2024
  SEC primary source ↗

• Progress Software response, April 15, 2024
  SEC primary source ↗

• Progress Software response, May 28, 2024
  SEC primary source ↗

The same operating change can move four ARR measures differently

The cleanest way to understand the differences is to ask how the same operating change would flow through four measurement systems.

Suppose a hypothetical customer has:

Annual contract value:          $120,000
Current monthly committed:       $10,000
Current-month extra usage:        $5,000
90-day average monthly usage:    $12,000
30-day average monthly usage:    $15,000
Contract expires next month
Renewal not yet signed

This is only an illustration.

It is not a claim that the four companies would report identical customer economics or that every detail above maps perfectly into each company's contract structure.

The point is to show how definition design changes sensitivity.

CrowdStrike-style construction

The metric would focus on the annualized subscription-contract value and, if the contract falls within the next 12 months, apply the disclosed renewal assumption.

The usage spike itself would not automatically redefine the contract value.

Datadog-style construction

Current monthly run rate can include:

$10,000 committed
+
$5,000 additional usage
=
$15,000 monthly run rate

× 12
=
$180,000 annualized run rate

The current usage spike can therefore have an immediate effect.

MongoDB-style construction

The result depends on the customer population.

A 90-day usage window would smooth the current spike.

A 30-day self-serve window would react more quickly.

Progress-style construction

The metric centers on active contract value and contract term rather than a trailing usage window.

A short contract can be annualized beyond its total nominal value.

And for some term-based license arrangements, contract economics can remain in ARR even when the associated license consideration has already been recognized upfront under GAAP.

The point is not to manufacture a precise four-company counterfactual. The filings do not provide enough information for that.

The point is sensitivity:

Comparability is not binary

The evidence above suggests a more useful way to think about KPI comparison.

Comparability is a ladder.

1. Same company, same methodology

This is usually the strongest case.

CrowdStrike's ARR methodology appears materially stable across the filings reviewed from 2023 through 2026. That makes its own ARR trend far more interpretable than a cross-company comparison with a usage-based metric.

Likewise, MongoDB's 90-day/30-day structure appears stable across the filings reviewed from 2023 through 2026.

same company
+ same definition
+ same population
+ same measurement rule
        =
strongest comparability

That does not eliminate other analytical issues—acquisitions, pricing changes, mix shifts, and business-model evolution can still matter—but at least the measurement rule is stable.

2. Same company, different definition vintage

This is weaker.

Progress's disclosure history shows why. The ARR acronym persisted while the company clarified the name and methodology, and a later filing showed a different value for the same November 30, 2023 observation than the earlier filing.

A time series that simply joins the numbers without preserving the filing vintage can hide that discontinuity.

3. Different companies, similar construction

Cross-company comparison can still be useful when the methods are sufficiently aligned.

But the burden of proof is higher.

The analyst needs to compare:

• calculation basis;
• inclusion rules;
• usage window;
• renewal assumptions;
• customer population;
• FX treatment;
• and definition vintage.

The correct result may be:

comparable enough for directional analysis

rather than:

identical variables

4. Different companies, different construction

This is where false precision becomes most dangerous.

CrowdStrike's contract-and-renewal ARR, Datadog's one-month run rate, MongoDB's mixed commitment/consumption measure, and Progress's contract/billings-oriented ARR belong to the same family, but the level values should not be treated as one standardized series.

This gives a practical hierarchy:

The right way to normalize ARR

A financial-data system should still normalize these metrics.

But it should normalize them hierarchically.

Layer 1 — reported identity

Preserve exactly what the company calls the metric.

reported_metric_name
reported_label
reported_definition

Layer 2 — canonical family

Map the metric into a broader analytical family.

For these examples:

metric_family:
    recurring_revenue_run_rate

This tells the analyst:

It does not say:

Layer 3 — calculation attributes

Store the actual methodology.

For example:

calculation_basis:
    contract_value
    monthly_run_rate
    contract_plus_usage
    active_contract_value

Then preserve attributes such as:

renewal_assumption
usage_included
usage_lookback_days
professional_services_included
maintenance_included
on_prem_license_included
upfront_license_value_included
short_contract_annualization
fx_method
customer_population

Layer 4 — definition vintage

A KPI definition belongs to a filing version.

It should therefore have:

effective_filing
filing_date
accession
definition_text
definition_hash / lineage

That matters when methodology or terminology changes.

Layer 5 — comparability state

Instead of forcing a single boolean such as:

comparable = true

the system can distinguish:

HIGH COMPARABILITY
same economic concept and closely aligned methodology

PARTIAL COMPARABILITY
same analytical family, but meaningful construction differences

FAMILY-LEVEL ONLY
related economic question, but level values should not be treated as interchangeable

That is a better model of reality.

When two ARR values should not be compared directly

A same-name metric can fail comparability for several reasons.

This leads to a more useful analytical question.

Instead of:

Ask:

Often the answer differs by use case. A metric can be highly useful for tracking one company through time while remaining unsuitable for a direct cross-sectional ranking.

Even "$100K ARR customers" is not standardized

The definition problem gets worse when one KPI is used inside another.

Consider:

Customers with ARR > $100,000

This appears highly comparable.

There are actually at least two separate definition problems:

CUSTOMER
What counts as one customer?

        ×

ARR
What counts toward ARR?

Datadog defines a customer around an account with a unique account identifier and an active subscription.

A single organization is generally one customer.

But divisions or subsidiaries can count separately when billing terms are separate.

At June 30, 2026, Datadog reported approximately 4,720 customers above $100,000 ARR, representing 91% of ARR.

MongoDB reported 2,999 customers above $100,000 ARR at July 31, 2026.

Those numbers can be analytically useful.

But the available MongoDB ARR passage does not establish customer-counting rules directly comparable to Datadog's subsidiary/division treatment.

So even before comparing 4,720 with 2,999, an analyst should ask:

Are we counting organizations?
Accounts?
Billing relationships?
Subsidiaries?
Business units?

And then:

Is the ARR threshold built from
monthly usage,
90-day usage,
contract commitments,
or something else?

Net retention inherits the definition problem

Net retention looks even more standardized because the output is a percentage.

A company might report:

NRR = 122%

Another:

DBNRR = low 120%s

The temptation is to rank them immediately.

But retention depends on at least four things:

1. the definition of the underlying recurring-revenue metric;
2. the cohort;
3. the measurement window;
4. what is included or excluded.

CrowdStrike's dollar-based net retention rate uses the prior-year subscription-customer cohort, includes expansion and contraction/churn, excludes new subscription customers, and specifically excludes incident-response and proactive-services revenue.

Datadog compares the ARR of the same customer cohort across a year, including expansion and net contraction or attrition while excluding new customers.

MongoDB's net ARR expansion rate uses ARR from customers present at both measurement dates in the numerator and the base-period ARR population in the denominator, including customers that later churned or contracted.

The percentage is therefore only the outer shell.

Underneath it sits:

retention KPI
      │
      ├── underlying ARR definition
      ├── cohort construction
      ├── churn treatment
      ├── expansion treatment
      ├── excluded revenue
      └── measurement window

This is why the right normalization target is again not merely:

metric = NRR

It is the full methodology.

Definition vintage matters too

A KPI definition is not timeless.

Progress demonstrates this particularly well.

The 2024 SEC correspondence prompted the company to explain the metric in much greater detail:

• what the metric includes;
• how short contracts are annualized;
• how usage enters the metric;
• how software-license consideration recognized upfront is treated;
• and why ARR differs from GAAP revenue.

The metric name later shifted from:

Annual Recurring Revenue

to:

Annualized Recurring Revenue

while retaining the same ARR acronym.

The name change alone does not prove that the underlying methodology changed.

But it does matter for interpretation. "Recurring" can invite a reader to focus on persistence, while "annualized" more clearly signals that the reported amount is a mathematical run-rate construction. The surrounding methodology—not the label by itself—determines whether there is a true definition change.

The same issue appears whenever a company changes:

• inclusion rules;
• customer scope;
• lookback windows;
• FX treatment;
• contract treatment;
• or naming.

A historical KPI series should therefore preserve the definition that existed at each point in time.

Otherwise the database risks creating a false continuous series across a methodology break.

How SourceState approaches company KPIs

The useful representation of a company KPI is not:

ARR = $5.8bn

It is closer to:

METRIC
ARR

REPORTED NAME
Annual Recurring Revenue

CANONICAL FAMILY
Recurring revenue run rate

VALUE
$5.841bn

DATE
2026-07-31

CALCULATION BASIS
Annualized subscription-contract value

RENEWAL ASSUMPTION
Contracts expiring within next 12 months assumed to renew

EXPIRED CONTRACT TREATMENT
Remain included during active renewal discussions

USAGE INPUT
Not specified in ARR definition

DEFINITION VINTAGE
Q2 FY2027 10-Q

SOURCE
Accession 0001535527-26-000031
MD&A — Key Metrics

For Datadog:

METRIC
ARR

CANONICAL FAMILY
Recurring revenue run rate

CALCULATION BASIS
Monthly run-rate revenue × 12

USAGE INPUT
Current-month additional usage
and usage under committed-usage subscriptions

AGGREGATE VALUE
Not disclosed in filing text checked

SOURCE
Q2 2026 10-Q

For MongoDB:

CALCULATION BASIS
Contractual commitments + annualized usage

USAGE WINDOWS
90 days — direct Atlas
30 days — other self-serve

PROFESSIONAL SERVICES
Excluded

For Progress:

CALCULATION BASIS
Active contract value ÷ term × 12

INCLUDES
Maintenance
Upgrade rights
Public cloud
On-prem subscriptions
Managed services

UPFRONT LICENSE VALUE
Included for specified term/on-prem arrangements

ECONOMIC CHARACTER
Generally aligns to billings, per company disclosure

This structure lets the system do something far more useful than flattening every ARR into one field.

It can tell an analyst:

What SourceState can reconstruct today

The current four-company dataset supports meaningful KPI analysis, but important limitations remain.

There are also coverage limits.

Datadog's newest 10-K has XBRL data in the local store but no extracted section text; the latest 10-Q does contain the ARR definition.

Some older filings were unavailable because of SEC retrieval failures.

Those gaps should remain explicit.

The purpose of normalization is not to conceal uncertainty.

It is to encode enough structure that uncertainty is visible.

The simplest way to think about KPI normalization

Traditional financial normalization asks:

Company KPI normalization asks a harder question:

That requires a different architecture.

REPORTED KPI
"ARR"
   │
   ▼
CANONICAL FAMILY
Recurring-revenue run rate
   │
   ▼
DEFINITION ATTRIBUTES
Contract / usage / hybrid
Annualization window
Renewal assumption
Customer population
Exclusions
FX
   │
   ▼
DEFINITION VINTAGE
Which filing supplied the rules?
   │
   ▼
COMPARABILITY DECISION
Same-company strong?
Cross-company usable with caveats?
Family-level only?

The crucial step is the last one.

A weak normalization system says:

ARR = ARR

A stronger one says:

These are all ARR-family metrics.
Here is exactly how each one is constructed.

And a genuinely useful analytical system can go further:

For this particular question,
these observations are strongly comparable.

These are useful only with explicit methodology caveats.

These belong to the same family,
but their level values should not be ranked directly.

That is the difference between creating a clean-looking dataset and creating a trustworthy one.

For company KPIs, that is the entire game.