How to get every report to show the same number: the metric "number book"

The board pack says revenue grew 11%. The sales dashboard says 13%. Both are "right", because each one defines revenue its own way. The fix isn't a better dashboard. It's writing each definition down once and making everything read from it.

Why reports disagree

When two reports show different numbers for the same metric, it's almost never an arithmetic error. It's one of these:

• Different source. One reads the GL, the other reads the billing system or the CRM.
• Different filters. One excludes intercompany, credit notes or a test entity; the other doesn't.
• Different grain or timing. Invoice date versus service date; month-end snapshot versus daily.
• Different refresh. One was pulled after the final close adjustments, the other on day 2.

Each of these is a definition that lives inside a report, a spreadsheet formula or someone's head. The number book moves all of them into one place.

What goes in each definition

Every metric gets the same fields. If a field can't be filled in, the metric isn't ready to report.

• Name and a one-line plain-English meaning.
• Formula, written precisely enough that two people would build the same query.
• Source: system and table (or GL account range).
• Owner: the role that decides what the definition is and approves changes.
• Grain: the level it's calculated at (entity, month, customer).
• Filters: what's in and what's out.
• Refresh: when the source is read, and whether values lock after close.
• Tie-outs: what it must agree to, and the tolerance.

A sample definition table

Here are three entries from a typical book. The system names are illustrative; use yours.

Note that DSO uses Revenue from the book, not its own revenue query. Metrics built on other metrics reference them by name. That's how a change to the revenue definition flows everywhere at once.

Automatic tie-outs between apps

A book of definitions stops disagreement in new reports. Tie-outs catch it in the ones you already have. Each tie-out is a rule that runs on every refresh:

• Revenue in the board pack equals revenue in the management accounts equals the TB.
• AR on the collections dashboard equals the AR control account.
• Headcount in the planning model equals payroll.
• Last month's locked values haven't changed, unless a restatement was logged.

A mature book carries hundreds of these, and they cost nothing to run once written. A failing tie-out shows the two values, the difference and which side moved. Every number on every report should also open its source: click it and see the rows behind it and when they were read.

How AI uses the number book

• Answering questions. "What was DSO in Q2?" resolves to the book's DSO entry, its source and its filters, so the answer matches the board pack.
• Writing commentary. Flux and board commentary cite metrics by their book name, and a reviewer can check each figure against the defined query.
• Building new tools. A new dashboard or report reads definitions from the book rather than inventing its own, so it agrees with everything else on day one.
• Drafting new definitions. AI can propose an entry for a new metric by reading how existing reports calculate it, including where they conflict. The owner approves it.

Common mistakes

• Defining in a wiki nobody reads. If reports don't read their logic from the book, it's documentation, not a source of truth. The book has to be what the queries run from.
• Allowing "Revenue (sales view)". Two definitions under one name is the original problem. If a variant is genuinely needed, give it its own name and its own entry.
• No owner. Without one role who approves changes, definitions drift back into reports within a quarter.
• Trying to define everything first. Start with the metrics in the board pack and flash. Migrate the rest as reports are rebuilt, and retire reports that nobody misses.

FAQ