What Is a Semantic Layer? Why Stripe, Your Books and Your Dashboard Show Three Different Revenue Numbers

The board meeting starts with revenue and immediately stalls. Stripe says one number, the accounts say another, the sales dashboard a third. Twenty minutes go on working out which is "right", and the answer is that all three are, by their own rules. The fix isn't a better dashboard. It's writing down, once, what "revenue" means, and making every report use that definition. That written-down layer of meaning is a semantic layer.

The short answer: a semantic layer is the part of a data setup that defines business terms, such as revenue, active customer or churn, as calculations on the underlying data, and makes every tool use those definitions. IBM puts it as "a piece of enterprise data architecture designed to simplify interactions between complex data storage systems and business users." It's how a company gets one version of the truth: change a definition once and every dashboard, report and AI assistant that uses it changes with it. Big data teams use dbt's MetricFlow, Cube, Looker, Power BI, Snowflake or Databricks for it. A small team needs the same idea, not necessarily a separate product.

Why your tools disagree on revenue

Each tool answers a slightly different question and calls it the same word.

An illustration with invented numbers: each tool is right by its own rules.

Stripe shows money moving through Stripe. Every transaction has a gross amount and a fee; in Stripe's docs, "You can calculate the net impact of a transaction on a balance by amount - fee". Refunds reduce revenue but not the fee: "Stripe’s processing fees from the original transaction aren’t returned." And payouts arrive in batches days later, so the money in your bank account in October isn't the same as October's charges. Stripe's own MRR is yet another figure: it includes subscriptions that are past_due, money not yet collected, and excludes tax.

Your accounts record revenue when it's earned, if you use accrual accounting. Stripe's own documentation explains the principle: "Generally accepted accounting principles (GAAP) state that you recognize revenue when you realize and earn it, which might be earlier or later than when you actually receive payments." A $1,200 annual plan paid in January is mostly deferred revenue in January. Tax comes out too: "if an invoice line item is for 90 USD with 10 USD in taxes, the total invoice is 100 USD, but the recognizable portion is only 90 USD." On cash accounting, QuickBooks records income "at the time you actually receive a payment", so the month the payout lands is the month it counts.

The dashboard someone built probably sums orders by order date, leaves out cancellations, and may or may not subtract refunds, depending on what the person who wrote the query decided two years ago.

None of these is wrong. The problem is that "revenue" in the meeting doesn't say which one you mean.

What a semantic layer does

A semantic layer sits between the raw tables and everything people look at. It holds:

• Metrics: the calculation behind each business number. Snowflake's documentation gives the classic example: "if net revenue within a company always means gross revenue after discounts, the semantic view can define it consistently as a metric with the correct aggregation: SUM(gross_revenue * (1 - discount))."
• Datasets and fields: which table holds orders, which column is the order date, what amt_ttl_pre_dsc actually means.
• Relationships: how tables join, so nobody has to remember that order_items.order_id links to orders.order_id.
• Rules: exclude test accounts, use the fiscal calendar, count revenue on the order date.

Tools then ask for "net revenue by month" instead of writing their own SQL, and get the same answer everywhere. As dbt's documentation puts it: "If a metric definition changes in dbt, it’s refreshed everywhere it’s invoked and creates consistency across all applications."

It isn't a new idea. Business Objects patented its "semantic layer" in 1996. What's new is that AI assistants now ask questions of your data too, and they need the definitions even more than people do.

Semantic layer vs data warehouse

They're different layers:

Some products now put both in one place, such as Snowflake's semantic views and Databricks' metric views, but the job is still separate: storage on one side, agreed definitions on the other.

How the main semantic layers work in 2026

• dbt Semantic Layer and MetricFlow. Metrics are defined in YAML in a dbt project, and MetricFlow writes the SQL and the joins. MetricFlow itself is now open source: "Version 0.209.0 and greater is covered by the Apache 2.0 license." The hosted Semantic Layer still needs a paid plan: "To define and query metrics with the dbt Semantic Layer, you must be on a dbt Starter or Enterprise-tier account." AI tools reach it through dbt's MCP server. Fivetran and dbt Labs completed their merger on 1 June 2026.
• Cube. An open-source semantic layer (Apache 2.0) that now presents itself as an agentic analytics platform. It "centralizes metric definitions, joins, access rules, and caching upstream of every BI tool, application, and AI agent that queries the data."
• Looker's LookML. "LookML, short for Looker Modeling Language, is the language that is used in Looker to create semantic data models." It's a strong semantic layer, tied to Looker.
• Power BI semantic models. The models that power Power BI reports, formerly called datasets. Microsoft now also lets AI agents query them through MCP; see our Power BI MCP server guide.
• Snowflake semantic views. Definitions stored in the database as a schema-level object, usable from SQL and from Snowflake's AI agents.
• Databricks metric views. "Metric views are the core implementation of Unity Catalog semantics in Unity Catalog." Define a metric once and group it by any field.

Apache Ossie: one format for definitions

Until recently, a metric defined in one of these tools was locked into it. In September 2025, Snowflake, Salesforce, dbt Labs and 14 other companies launched the Open Semantic Interchange (OSI), an open format for metric definitions. The specification went live under Apache 2.0 in January 2026, and in June 2026 the project joined the Apache Incubator as Apache Ossie. The coalition has grown from 17 launch partners to more than 50 organisations, including Databricks and Microsoft. Its home page sums up the point: "Stop redefining "Revenue" in every dashboard."

There's no official Apache release yet, but dbt can already read Ossie documents from version 1.12, and Snowflake and Databricks publish converters. Our Apache Ossie explainer covers the format in detail.

Why AI assistants need a semantic layer most

An AI assistant asked "what was revenue last month?" on a raw database has to guess which table, which status values and which date column you mean. In a widely cited 2023 benchmark, GPT-4 answered questions on enterprise SQL databases correctly 16% of the time from the schema alone, and 54% when the same questions went through a model that described the business. Snowflake's documentation says the same about its own assistant: "Generic AI solutions often struggle with text-to-SQL conversions when given only a database schema, as schemas lack critical knowledge like business process definitions and metrics handling."

That's why every major vendor now routes AI through definitions: dbt's MCP server, Snowflake's semantic views for Cortex, Databricks' Genie on Unity Catalog. An AI answer built from your definition of net revenue matches your dashboard; one built from a guess starts the same argument the board meeting had.

What a small team actually needs

You don't need a separate semantic-layer product to stop the revenue argument. You need four things:

1. Pick the definitions that cause arguments. Usually revenue, active customer, churn and margin. Write each one in a sentence: "Net revenue is paid orders minus refunds, before tax, counted on the order date."
2. Turn each sentence into one calculation. In SQL, against the tables you actually have.
3. Put it where every tool reads it. Not in a document people forget, but where dashboards, reports and your AI assistant pull the calculation from.
4. Label the exceptions. When finance needs recognised revenue for the accounts, call it that, so "revenue" on the dashboard and "recognised revenue" in the books are visibly different numbers.

Definitions in Fastero

In Fastero, definitions are part of the workspace your data is connected to. For each database you can save metrics as SQL expressions, datasets with field descriptions, relationships between tables and notes such as "exclude test accounts". Every save is versioned. Fastero's own assistant and Claude, through Fastero's connector, read them before writing SQL, so an answer about revenue uses your definition of revenue. The connector's own description says it plainly: "A metric's expression is the organisation's agreed wording for that number, so a query built from it agrees with the team's own reports."

Definitions for the sample orders data in a Fastero workspace: net revenue as one SQL expression, with the words people use for it. Sample data.

Definitions can be imported and exported in the Ossie format, so they aren't locked in. And when Claude settles what a number means with you in a conversation, it can save that definition for the rest of the team to use.

FAQ

What is a semantic layer in simple terms?

It's a shared dictionary for your company's numbers, written as calculations. Instead of each report working out revenue its own way, every report asks the semantic layer for "revenue" and gets the same calculation.

Is a semantic layer the same as a data warehouse?

No. A data warehouse stores the data. A semantic layer stores what business terms mean, as calculations on that data, and sits on top of it.

Why doesn't my Stripe revenue match QuickBooks?

They measure different things. Stripe shows charges, with fees and refunds on separate lines and payouts arriving days later; QuickBooks records revenue when it's earned (accrual) or when cash arrives (cash), and excludes tax. Decide which definition each report should use and label them differently.

Is MetricFlow open source?

Yes. MetricFlow is under the Apache 2.0 licence from version 0.209.0. The hosted dbt Semantic Layer, with its APIs and integrations, needs a paid dbt plan.

What is Apache Ossie?

The open format for metric definitions formerly called the Open Semantic Interchange (OSI), launched in 2025 and in the Apache Incubator since June 2026. It lets tools share definitions without retyping them.

Do AI assistants need a semantic layer?

They answer far more accurately with one. Without definitions an assistant guesses which tables and filters you mean; with them it uses your agreed calculation, so its answer matches your reports.

---

Related reading:

• Apache Ossie explained
• Best semantic layer tools
• How to define metrics as a single source of truth
• Self-service analytics without the data team queue
• Automated reporting

Sources: IBM: semantic layer, Wikipedia: semantic layer, Snowflake semantic views, dbt Semantic Layer, MetricFlow, About MetricFlow, Cube, LookML, Power BI semantic models, Databricks metric views, Open Semantic Interchange launch, Apache Ossie, Ossie in the Apache Incubator, Stripe balance transactions, Stripe refunds, Stripe subscription analytics, Stripe revenue recognition, QuickBooks cash vs accrual, Sequeda et al. benchmark, Snowflake Cortex Analyst, TechTarget on the Fivetran and dbt Labs merger. Checked 5 November 2026.

---

Try Fastero free — connect your data, write down what revenue means once, and every dashboard and AI answer uses it. No credit card required.