SoF Standard Definitions v1.0

The register

Every assumption applied and every anomaly found is logged, so a reader can argue with a premise instead of discovering it later.

Also Assumptions register · Exceptions register · Assumptions and exceptions log

The standard

Every gap in the data produces a logged, visible, reviewable entry. Assumptions record where a default was applied; exceptions record where the data was anomalous. The register accompanies every report. A report without its register is not complete under this standard.

At a glance
Formula
entries = assumptions (a default was applied) + exceptions (the data was anomalous), each keyed, with a severity of info, warn or blocking
Unit
entries by severity
Bounded
n/a
Defaults
every threshold feeds a finding · blocking stops the computation · reviews append-only
Biggest lever
Completeness — a register that omits inconvenient entries is worse than none
Appears in
Data room · Quality-of-earnings working papers · Restatements

What it measures

The register measures the distance between the data the company has and the data the metrics assume.

Every real revenue file has gaps: rows with no revenue type, currencies with no rate, customers with billing holes, duplicates, negative amounts with no explanation, contracts absent for prepaid billings. Something must be done with each. The alternatives are to guess silently, to stop entirely, or to apply a stated default and record it. The first destroys trust the moment it is discovered; the second makes the analysis impossible, since no file is ever clean.

The register is the third path, and it carries a claim that the rest of the report depends on: these are the assumptions, all of them, and here is what each one did to the numbers. An assumption a reader can see is a premise they can argue with. An assumption they cannot see is a defect waiting to be found by the party least sympathetic to the company.

How it is computed

Two kinds of entry, both stable-keyed so they can be reviewed, tracked, and compared across restatements.

Assumptions — a default was applied where the data was silent:

  • the declared amount basis and period grain of each file
  • revenue-type fallbacks, and per-product type rules
  • pause holds, naming the customer, the gap, and the held amount
  • FX fallbacks, naming currency and month
  • trailing-gap policy applications
  • coercions performed during parsing
  • label variants differing only by case or spacing, treated as distinct
  • multi-sheet workbooks, naming the sheet read and those unread

Each carries what was applied, the alternatives, and whether it is an automatic default or a decision confirmed by a person.

Exceptions — the data itself was anomalous: duplicate rows, billing gaps, negative amounts, proration anomalies, orphan entities, missing rates, unknown revenue types, suspected related parties, indeterminate churn at the cutoff, ambiguous grain, parse failures. Each carries a severity — info, warn, or blocking — and its scope.

Blocking is real. Some conditions stop the computation rather than degrading it: hybrid revenue with no type column, an amount basis that cannot be determined. The standard refuses to produce a number over an input that requires a guess about what the numbers mean.

Review. Each entry can be marked by a reviewer as accepted (understood, stands as logged), disputed (the logged item looks wrong), or resolved (fixed at the source), with a note. Reviews are append-only and travel with the report, so the register is a working paper — the record of a conversation between the people who know the data and the people who must rely on it — rather than a static list of complaints.

Worked example

A register entry from an ordinary file:

Assumption · pause_hold:ent_acme:2024-04 · category pause_hold · status auto Description: Acme Corp: no revenue for 2 month(s) from 2024-04, resuming within the 3-month reactivation window — treated as a pause; MRR held at 5,000 per the SoF reactivation-window rule. Default applied: MRR held through gap; no churn/reactivation recorded. Alternatives: Treat as churn + reactivation (shorten window).

A reader who disagrees knows exactly what to change, which customer is affected, and what the alternative produces. Compare that to the same decision made silently inside a spreadsheet formula, where the only way to find it is to already suspect it.

The choices that change the number

The register does not change any number — it describes the changes other choices made. That is precisely its function: it is the audit trail for every configurable decision documented in the other sixteen entries.

The one genuine choice here is completeness. A register that omits inconvenient entries is worse than no register, because it carries an implicit claim of exhaustiveness. Under this standard the register cannot be edited or filtered — only reviewed.

How it is misread

Read as a defect list. A long register does not mean bad data; it usually means thorough disclosure. A suspiciously short one on a real-world file means the checks were not run.

Counts read without severity. Forty info entries and one blocking entry are not comparable, and the summary counts exist to be read by category.

Treated as optional in a summary report. The register is precisely what makes the summary credible; removing it for brevity removes the reason to believe the rest.

Reviewed once and forgotten. Restating with new data regenerates entries. Reviews attach to stable keys so prior decisions persist, but new entries need new attention.

What it cannot tell you

The register records what the computation encountered. It cannot record what is absent from the file entirely — a business line never exported, a subsidiary excluded from the extract, revenue booked outside the operational system. That class of gap is only visible by comparison against the financial statements, which is why tie-out is a separate and mandatory check.

A report under this standard vouches for the computation over disclosed inputs. It does not vouch that the inputs are the whole truth — no analysis of a file can do that, and any claim otherwise should be treated as the strongest reason to distrust it.

How to state it

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

Register: {n} assumptions · {m} exceptions ({b} blocking) (SoF Standard v1.0: complete, unfiltered, reviews append-only)

Before you quote it

  • Every assumption named with customer, amount and alternative?
  • Severity counts shown?
  • Blocking conditions resolved before numbers are quoted?
  • Register delivered with the report?

Related questions

What is the register?
The log of every assumption applied where the data was silent and every exception where the data was anomalous, each with a stable key, a severity and a scope, delivered with the report. It measures the distance between the data the company has and the data the metrics assume.
What problems does a customer revenue file usually contain?
Rows with no revenue type, currencies with no rate, billing holes, duplicates, negative amounts without explanation, prepaid billings with no contract, labels that differ only by spacing, workbooks with unread sheets. Each gets a stated default and an entry, or stops the computation when a guess about meaning would be required.
Is a long register a sign of bad data?
Usually of thorough disclosure. A suspiciously short register on a real-world file means the checks were not run. Read the counts by severity: forty informational entries and one blocking entry are not comparable.
How should a restatement be disclosed?
Through the register. Entries carry stable keys, so reviews persist across restatements and new data regenerates entries rather than editing old ones. A closed period never changes silently; the change and its cause are entries.
Cite this definition

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