SoF Standard Definitions v1.0

Customer — the measured unit

A customer is the commercial relationship, resolved from its billing accounts, and only paying customers are counted.

Also Customer definition · Entity resolution · Resolved parent entity

The standard

Every customer metric is measured on the resolved parent entity — the commercial relationship — not on the billing identifier that happens to appear in the revenue file. Comped and 100%-free customers are excluded from revenue and logo metrics alike.

At a glance
Formula
customer = the resolved parent entity behind one or more billing identifiers
Unit
count (logos)
Bounded
n/a
Defaults
comped excluded (locked) · related-party flagged, not excluded
Biggest lever
Where the parent boundary is drawn — one relationship read as four accounts inflates logo churn and new business at once
Appears in
Logo counts · Data-room customer list · Concentration schedule
Switches
1 · 1 locked — see the choices

What it measures

Before any metric can be computed, one question must be answered: what is a customer? The revenue file answers a different question — it lists billing accounts, which is not the same thing and is rarely the thing anyone means.

A single commercial relationship routinely appears in a billing system as several identifiers. A customer signs a second contract for a second product and gets a second account id. A subsidiary is invoiced separately from its parent. A company is renamed after an acquisition and the old identifier is retired mid-life. An enterprise migrates from a legacy plan onto a new one and the migration is implemented as “cancel account A, create account B.”

Every one of these is invisible to arithmetic and catastrophic to interpretation. The migration case is the clearest: read at the billing-identifier level, that customer churned and a brand-new customer arrived in the same month. Logo churn rises, new business rises, retention falls, and none of it happened.

How it is computed

Entity resolution runs before the customer-month series is built, not after. A versioned resolution maps every raw customer_ref in the source data onto a resolved parent entity with a stable id and display name. All downstream measurement — MRR, movements, cohorts, retention, concentration — operates on the parent.

The resolution is a first-class, versioned object, not a preprocessing step buried in a script. It can be revised; revising it restates every metric that depends on it, which is the correct behavior and the reason it is versioned.

Two attributes attach at the entity level and change what the entity counts toward:

  • Comped — the customer pays nothing, or pays a nominal amount that does not represent commercial value. Under the locked default they are excluded from revenue and logo metrics. They remain visible in the data and in every supporting detail; they are excluded from totals, never deleted.
  • Related party — the customer is affiliated with the seller. Related-party revenue is not excluded by default, because whether it is arm’s-length is a judgment, not a computation. It is flagged so the judgment can be made.

Worked example

A file contains four billing identifiers:

IdentifierName in fileMRR
ACME-001Acme Corp7,000
ACME-EUAcme Corporation (EMEA)3,000
ACME-LEGAcme Corp (legacy plan)0
FRIEND-1Friendly Design Partner2,000 (comped)

Unresolved, this reads as four customers, one of which churned to zero, at an average of 3,000 each. Resolved, it reads as one paying customer at 10,000, a migration that never churned, and one comped relationship excluded from totals. Concentration, ARPA, logo counts, and retention all change — and only the resolved reading describes the business.

The choices that change the number

  • Where to draw the parent boundary. A subsidiary billed separately may be the same commercial relationship as its parent or a genuinely separate one. This is a judgment about the business; the standard requires only that it be made explicitly and versioned, not that it come out a particular way.
  • exclude_comped (LOCKED true). Including comped customers inflates logo counts and depresses ARPA, and — more subtly — makes retention look better, because a customer paying nothing cannot contract.
  • Related-party treatment. Not excluded by default. If the buyer will exclude it, the seller should know the number both ways before the meeting.

How it is misread

The most common error is not making a decision at all — computing at the billing-identifier level because that is what the export contained, and reporting the result as customer metrics. This systematically overstates logo churn, overstates new business, understates ARPA, and understates concentration. It flatters growth and flatters risk simultaneously, which is why it survives so long unchallenged.

The second error is resolving informally — by name-matching in a spreadsheet, unversioned. The metrics then depend on a transformation nobody can reproduce, which means the metrics cannot be reproduced.

What it cannot tell you

Entity resolution cannot tell you whether two identifiers should be one relationship. It records a decision; it does not make it. Fuzzy name matching proposes candidates, and a person accepts or rejects them — because the cost of a wrong merge (two real customers collapsed into one, hiding a churn) and the cost of a wrong split are both borne by the reader of the metric, not by the matcher.

How to state it

A disclosure that travels with the number. Replace the braces; keep the parenthesis.

{N} customers (SoF Standard v1.0: resolved parent entities · comped excluded · related-party flagged)

Before you quote it

  • Identifiers mapped to parents, and the mapping versioned?
  • Comped and $0 customers excluded from counts and revenue?
  • Related-party customers flagged?
  • The same customer count used in ARPA, concentration and churn?

Related questions

What counts as a customer in SaaS metrics?
The resolved parent entity: the commercial relationship, not the billing account. One company with three subscriptions, a subsidiary invoiced separately, or an account recreated after a plan migration is one customer. Under this standard entity resolution runs before anything is computed, and every downstream metric — MRR, movements, cohorts, retention, concentration — is measured on the parent.
Do free, freemium or trial users count as customers?
No. Comped and 100%-free customers are excluded from revenue and logo metrics under the locked default (exclude_comped). They stay visible in the data, never deleted, but they contribute no MRR and no logo. Including them inflates logo counts, depresses ARPA and flatters retention, because a customer paying nothing cannot contract.
Do paid pilots count as customers?
If the pilot is billed as a recurring subscription it counts while it bills. If it is a fixed-term fee with no renewal obligation it is one-time revenue and the relationship is not yet a recurring customer. What matters is the revenue type, not the label on the deal.
Are subsidiaries of the same parent one customer or several?
Whichever the entity resolution says, explicitly and versioned. The standard does not decide where the boundary sits; it requires that the decision be made, recorded and reproducible, because the answer moves concentration, ARPA, logo churn and retention at once. Resolving informally by name-matching in a spreadsheet is the failure mode.
Why do CRM, billing and finance report different customer counts?
Because they count different objects: leads or accounts in the CRM, billing identifiers in the subscription system, invoiced entities in finance. None of them is the resolved parent. A metrics report should state which count it uses and how identifiers were mapped to parents.
Is related-party revenue excluded?
Not by default. Whether an affiliate pays at arm's length is a judgment, not a computation, so the standard flags related-party customers rather than removing them. A buyer will often exclude them; the seller should know the numbers both ways before the meeting.
Cite this definition

Strategy of Finance. “Customer — the measured unit.” SoF Standard Definitions v1.0 (2026-09-18). https://www.strategyoffinance.com/standards/the-measured-unit/