Why Three Departments Got Three Different Revenue Numbers—and How to Fix It

The $10 Million Question That Got Three Answers

Ask a simple question—"What was net revenue in East China last month?"—and you'd expect a simple answer. But in many companies, the finance, operations, and sales teams will each produce a different number. Not because anyone is sloppy, but because they're all using the same word to mean different things.

Here's a typical scenario. The CFO's report says $8 million. Operations says $10 million. Sales says $12 million. All three teams can defend their logic. Finance counts recognized revenue per accounting rules. Operations counts what customers actually paid, minus refunds. Sales counts signed contracts, even if the cash hasn't landed yet.

So which number is right? All of them—if you define your terms. The real issue isn't arithmetic. It's that "revenue" means three different things, and nobody wrote down which one they meant.

Data Storage Isn't Business Definition

Look at a raw database record. It might have fields like order_id, amount, status, and created_at. Technically, the database knows that amount is a number and status is an integer. But that doesn't tell you what amount represents. Is it the contract value? The amount the customer actually paid? The net after refunds? Does it include tax?

Field names give hints, not definitions. A column labeled revenue could mean anything. And a real business metric rarely maps to a single column anyway. You might need to join orders, payments, and refunds, then apply filters for region and time. The database doesn't know which rules are the ones your company trusts.

Even if you've built a data warehouse that unifies all your source data, the problem persists. A warehouse gives you one place to query, but it can't force finance and sales to use the same filters and formulas. Without shared definitions, each team ends up writing its own SQL, its own reports, and its own version of the truth.

When BI Tools Make It Worse

Self-service BI and analytics tools are supposed to democratize data. But they also let people reinvent metrics on the fly. If the business rules aren't centrally managed, every new dashboard becomes a fresh interpretation. The problem isn't the number of reports—it's that the rules live in people's heads, not in a shared system.

AI analytics amplifies this. An AI assistant that pulls from scattered SQL queries will confidently give you an answer, but it might be using the wrong definition. Before you add AI to your stack, you need to answer a more basic question: what exactly are we trying to measure?

You Can't Automate Governance

A semantic layer won't magically decide whether $8 million, $10 million, or $12 million is correct. Those numbers serve different purposes. Sales needs contract value. Operations needs cash flow. Finance needs recognized revenue. Forcing them into one number would be wrong.

What you actually need is a governance process. Sit down with stakeholders and define each concept clearly. Give them distinct names. Document the calculation rules, the source data, and the filters. Assign an owner and a reviewer. Track changes and versions. This is a business exercise, not a technical one.

Once you have a set of agreed definitions, you still have to make them executable. If they're stuck in a meeting minutes document or an analyst's spreadsheet, they're not doing you any good. You need to translate them into something machines can follow.

Enter the Semantic Layer

A semantic layer sits between business users and raw data. It maps business terms like "net payment amount" to the underlying tables and fields. But it's more than a dictionary. It defines which measures make up a metric, which fields serve as filters, and at what granularity the data should be aggregated.

For example, "platform net payment" might be defined as: successful payments in the period, minus successful refunds in the same period. The semantic layer knows that "successful payment" means payment_status = 'completed', and that "period" defaults to the last calendar month in Asia/Shanghai timezone.

Some semantic layers can also enforce row-level security. A regional manager might only see data for their own region. But access control isn't always the semantic layer's job—it often works with the warehouse, BI tool, or application to enforce those rules.

From Business Question to Query Result

Let's say a user asks again: "What was net revenue in East China last month?" Because "net revenue" could refer to multiple metrics, the system shouldn't guess. It should ask: "Do you mean contract value, platform net payment, or recognized revenue?" Once the user clarifies, the query engine generates the right SQL, the database executes it, and the result comes back with context.

The response should include more than just a number. It should show the metric name, region, time range, timezone, data refresh timestamp, and the user's permission scope. That way, anyone looking at the result can trace exactly what was calculated and why.

Make Business Definitions Reusable

The payoff is that you define a metric once, and everyone—sales, finance, operations, and even AI assistants—uses the same definition. No more duplicate SQL, no more conflicting reports, no more depending on one analyst's memory.

In practice, this means your company can finally have a single source of truth for its key numbers. Not because you forced everyone to agree on one revenue figure, but because you gave each concept a clear name and a machine-readable definition.

The next time someone asks "What's our revenue?" you can answer with confidence—and with the context to prove it.