One definition of revenue for every report and every agent

The board meeting has three revenue figures for the same month. Sales brought one from the CRM: deals marked as won. Finance brought one from the ledger: invoices issued, less credit notes. Operations brought one from the warehouse system: orders shipped. Each is correct by its own definition, and the first twenty minutes of the meeting go on working out why they differ.

Now an agent is asked how revenue is tracking against plan. Which definition does it use? In practice, whichever table it finds first, and possibly a different one the next time it is asked.

The cause is that the definitions of business metrics live in the reporting layer: in each dashboard’s formulas, in each spreadsheet, in each analyst’s queries. Every consumer re-implements them, and the implementations drift one fix at a time. Agents make this worse, not because they are careless, but because there are more of them, they query data directly, and they produce answers faster than anyone can check the definition behind each one.

The established answer has a name in business intelligence: a semantic layer. It is a shared layer that defines business metrics and dimensions once, on top of the raw data, so that every tool asks for “revenue” by name instead of recomputing it. OLAP cubes did a version of this decades ago. The idea matters more now that the consumers include software that writes its own queries.

Where definitions drift

Formulas copied into reports. One copy gets a fix, the others do not, and the numbers part ways without anyone deciding they should.

One word, several meanings. Booked, invoiced and recognised revenue are all legitimate, and all different. Calling them all “revenue” guarantees an argument.

Silent filters. Intercompany sales excluded in one place and not another. Credit notes netted here and not there. A test customer that nobody removed from one data source.

Time. Order date, invoice date or delivery date: the same transaction falls into different months depending on which one a report uses.

Currency and rounding. Which exchange rate, taken on which day, and rounded where.

Agents choosing for themselves. A language model writing queries against raw tables will choose a plausible definition each time it is asked. Plausible is not the same as agreed, and it is not guaranteed to be the same twice.

Define it once, upstream

Name every variant. Booked revenue, invoiced revenue and recognised revenue each become a separate, named metric with an owner and a written definition. The goal is not one definition of revenue for the company; it is exactly one definition behind each name.

Define metrics on the business model, not on tables. Invoiced revenue is defined on invoices and credit notes as objects in the company’s ontology, with their states and relations, not on column names that change when a source system is upgraded.

Make everything ask the layer. Dashboards, spreadsheets, exports and agents all request the metric by name. Agents in particular should not be allowed to assemble a business metric from raw tables; they ask for it, and the answer comes with its definition.

Version the definitions, with effective dates. When a definition changes, last year’s numbers can still be reproduced as they were reported, and the change is visible as a change.

Show the definition with the number. Every answer states which metric, which filters, which period and as of when. A number without that is a rumour with decimal places.

In Hurukan’s design, metrics are defined on the objects of the Ontology layer and read from one data model in the Data layer, so a report and an agent asking the same question get the same answer for the same reason. Budget control in the Finance module (plan, committed, actual and forecast) is built on exactly such named measures. This is in build.

A test you can run today

Ask three people for last month’s revenue figure and how they arrived at it: someone in finance, someone in sales, and whoever prepares the board pack. Write down the three numbers and the three methods.

If your company already has an AI assistant connected to its data, ask it the same question twice, in two separate sessions, and note what it says and how.

If you have more than one number across those five answers, and you cannot name the reason for each difference, you need a shared definition before you need another report. The broader case for starting analytics from questions rather than dashboards is in the dashboard nobody opens.