Originally published on daata.cz.
Three Numbers for One Revenue: Why Your BI (and AI) Needs a Semantic Layer
Monday management meeting. Sales reports October revenue of 4.2 million. Finance has 3.9 in its report. The marketing dashboard shows 4.6.
All three pull from the same data warehouse. And all three are "right": sales counts orders minus cancellations, finance counts invoices net of VAT, marketing counts everything including credit notes.
What follows is a half-hour argument about whose number is correct — and the decision the meeting was called for gets postponed.
This has a name: metric sprawl. And it's exactly what a semantic layer fixes.
What a semantic layer actually is
A semantic layer sits between your data warehouse and everything that reads from it — BI dashboards, Excel, notebooks, AI chatbots. It holds a single, central definition of your business metrics and dimensions: what "revenue" means, how "margin" is calculated, who counts as an "active customer."
It's a translator. The business asks for "revenue by region for Q3," and the semantic layer turns that into the right SQL over the right tables — the same way every time, no matter which tool is asking.
How metric sprawl creeps in
Nobody sets out to create chaos. It accumulates quietly:
- An analyst builds a dashboard with their own SQL definition of revenue.
- A colleague copies it and "slightly" tweaks the definition.
- A manager exports to Excel and calculates their own way.
- The company adopts a second BI tool — and every definition is recreated, differently.
The result: same question, different answers. Trust in the numbers erodes, and analysts burn hours reconciling instead of analyzing.
Metrics as code
Modern semantic layers define metrics as version-controlled text files, not click-through settings locked in a BI tool. A definition change becomes a pull request and a code review; you get full history and CI testing before anything reaches users. Here's the shape of it in dbt's Semantic Layer:
metrics:
- name: revenue
label: "Revenue"
type: simple
type_params:
measure: revenue # sum of amount, net of VAT and cancellations
Define it once, and every tool — dashboard, Excel, AI agent — consumes the identical calculation.
The tools, briefly
| Tool | Best when |
|---|---|
| dbt Semantic Layer (MetricFlow) | You already use dbt and want metrics next to your transformations |
| Cube | Customer-facing analytics in an app, or AI agents querying over MCP |
| LookML (Looker) | You're standardized on Looker / Google's ecosystem |
| Snowflake Semantic Views | Your data is in Snowflake and you want AI self-service fast |
| Power BI semantic model | A smaller shop reporting exclusively in Power BI |
Why AI makes this urgent
An AI agent's problem isn't writing SQL — it's writing the right SQL, the same way every time, without surfacing numbers a user shouldn't see. Without a semantic layer, the agent invents its own "revenue" — and you're back to three numbers in one meeting, just faster. Through MCP, the agent asks for named metrics instead of composing raw SQL, so the calculation is consistent and access rules apply to AI too.
When you don't need one (yet)
If you have one BI tool, a handful of reports, and one person defining metrics, the built-in layer of Power BI or Metabase is enough. Don't adopt a semantic layer for a problem you don't have yet. It starts to pay off when the same numbers are consumed by multiple tools or departments — or the moment you put an AI chatbot on your data.
The full version — with all four tools compared in depth, three real-world scenarios, best practices, and an FAQ — is on the Daata blog: The Semantic Layer: Why Your BI (and AI) Needs One.
Daata helps mid-sized companies get more out of their data — data platforms, reporting, and automation that make everyday processes simpler. Get in touch.
Top comments (0)