The Semantic Layer Is Back. This Time, Finance AI Depends on It.

Ask five finance teams for “revenue” and there is a decent chance you will get more than one number.

One report may use booked revenue. Another uses recognized revenue. A sales dashboard may include intercompany transactions that consolidation removes. A regional view may convert currencies at a different rate. An analyst’s SQL may quietly exclude a business unit that was added last quarter.

For years, companies tried to solve this with BI governance: certified dashboards, shared data models and carefully maintained metric definitions.

Generative AI has made the problem harder.

A human analyst can notice that two dashboards disagree and ask which one is authoritative. An AI agent asked “Why did gross margin fall in Europe?” needs to decide which revenue, cost, region and period definitions to use before it can even begin the analysis.

In 2026, the major data platforms are responding by making semantics a first-class product.

Snowflake now recommends semantic views as the business abstraction layer for new implementations. Databricks has built Unity Catalog semantics around metric views, business context and governance. Both are trying to make business definitions reusable by dashboards, SQL users and AI agents.

The semantic layer is back. This time, it may determine whether finance AI is trustworthy.

Why the warehouse was never enough

Modern finance data architectures solved an important problem: they put more data in one place.

They did not automatically make that data mean the same thing to everyone.

A warehouse can contain every invoice, journal, customer record and sales transaction and still produce conflicting KPIs.

The reason is simple. Metrics are business logic.

“Active customer” is not a field in nature. Someone defines the period, qualifying activity, exclusions and hierarchy. “Gross margin” requires decisions about which costs belong in the numerator and which revenue definition belongs in the denominator.

Those definitions often live downstream—in Power BI measures, Tableau workbooks, spreadsheet formulas, SQL queries or analyst knowledge.

AI makes that fragmentation visible because the user no longer chooses the dashboard first.

The user asks the question first. The system has to find the correct meaning.

Snowflake is turning semantics into a governed database object

Snowflake’s semantic views are schema-level objects that define logical tables, relationships, facts, dimensions and metrics over physical data.

The important architectural point is that the definition lives in Snowflake rather than being trapped inside one BI tool.

In March 2026, Snowflake made standard SQL querying of semantic views generally available. In April, it added verified queries that can guide Cortex Analyst toward trusted question-to-SQL patterns. In May, entity-level filters became generally available and object tagging arrived. June added variables, SQL queries as logical tables and sample values that help the AI interpret fields.

By late August, Snowflake was recommending customers transition natural-language analytics from standalone Cortex Analyst to Cortex Agents. The semantic views remain intact: Cortex Agents uses the same semantic layer while adding orchestration, unstructured search, tool calling and conversational context.

Then, on September 2, Snowflake added lineage showing which data a Cortex Agent can reach through its tools—including the path from source table through semantic view to agent.

That sequence matters.

The semantic layer is evolving from a modeling convenience into AI control infrastructure.

Databricks is converging on the same problem

Databricks is taking a similar path through Unity Catalog.

Its metric views define measures separately from the dimensions used to group and filter them. A metric such as revenue per customer can be defined once and then queried across different dimensions at runtime.

By July, Databricks documentation described metric views as the core implementation of Unity Catalog business semantics. They can be consumed from SQL, notebooks, dashboards, Genie and external BI tools including Power BI, Tableau and Sigma.

The platform also supports agent metadata: synonyms, display names and formatting rules designed to help AI tools interpret business terminology correctly.

In August, Databricks expanded the semantic concept further. Unity Catalog semantics documentation described business-aligned domains, governed Pages for authoritative concepts, and certification/deprecation signals that steer Genie toward trusted assets.

The message from both vendors is remarkably similar.

AI does not eliminate the need to model the business. It increases it.

Finance should care because metrics are controls

Data teams often describe semantic layers as a way to improve consistency.

Finance should use stronger language.

A material KPI definition is a control.

If adjusted EBITDA excludes one category in the board pack but not in the AI assistant, that is not merely a data-quality issue. It can change a management decision.

If an agent calculates DSO using a different receivables scope than the treasury dashboard, it can generate a plausible but operationally wrong recommendation.

Finance therefore needs ownership of financial semantics even when data engineering owns the platform.

The controller should know which definitions reconcile to the ledger. FP&A should own management metrics and planning dimensions. Commercial finance should define customer and product economics. Data teams should encode and govern those definitions.

The semantic layer becomes the interface between accounting truth and analytical meaning.

Verified queries are more important than they sound

One of Snowflake’s most interesting features is the verified-query repository.

A verified query pairs a natural-language question with SQL that has been reviewed as correct. Cortex Analyst can use relevant examples when answering similar questions.

This is essentially a way to teach the analytical system using approved finance logic.

For a CFO team, the opportunity is obvious.

Instead of starting with hundreds of generic questions, identify the 20 or 30 questions that management repeatedly asks: revenue versus plan, gross-margin bridge, customer concentration, working-capital movement, cash conversion, headcount versus budget.

Finance can verify the expected logic and use those examples as anchors.

That does not guarantee every future answer will be correct. It creates a testable reference set.

The semantic layer does not fix bad source data

There is a danger in treating semantics as a cure-all.

A beautifully defined “net revenue” metric cannot repair duplicate invoices. A certified customer hierarchy cannot resolve an ERP master-data error unless the source is corrected. A semantic model cannot make a late subsidiary close current.

The architecture has layers.

Source quality determines whether the facts are right. The semantic layer determines whether the facts are interpreted consistently. The agent determines how the question is translated into analysis.

Finance needs all three.

This is why semantic governance should not become another technology program disconnected from data ownership.

Portability is the buyer question nobody should ignore

The new semantic layers also create strategic risk.

If a company defines hundreds of critical metrics in one data platform’s proprietary objects, how portable is that business logic?

Snowflake semantic views and Databricks metric views solve similar problems but are not interchangeable objects.

That means the semantic layer can become a new form of platform gravity.

CFOs and CIOs should therefore distinguish between the business definition and its technical implementation.

The definition of gross margin should exist in controlled documentation independent of the platform. Ownership, calculation logic, exclusions, source systems and reconciliation rules should be exportable.

The platform can execute the metric. It should not become the only place the organization remembers what the metric means.

BI tools are not disappearing

Another mistake would be to interpret platform semantics as the end of Power BI, Tableau or finance dashboards.

Databricks explicitly supports querying metric views from external BI tools. Snowflake positions semantic views as reusable across BI, SQL and AI.

That is the point.

The semantic layer is moving below the interface.

A CFO can still consume a board dashboard. An analyst can still work in SQL. A business partner can ask an agent. All three can potentially use the same governed metric definition.

That is much more valuable than replacing one visualization tool with another.

Finance needs a metric registry, not a metric graveyard

Centralizing definitions can create a different failure mode: hundreds of metrics nobody understands or owns.

A serious finance semantic program should begin small.

For every material metric, record the name, business owner, technical owner, formula, grain, allowed dimensions, source, reconciliation target, refresh expectation and status.

Then classify it.

Is it statutory, management, operational or experimental? Is it certified for board reporting? Can AI agents use it? Is it deprecated?

Databricks’ certification and deprecation signals point in this direction. Snowflake’s object tags and lineage provide another set of governance primitives.

The technology is increasingly capable of carrying the metadata. Finance has to supply the accountability.

AI changes the economics of semantic work

Semantic modeling has always been valuable. It was also easy to postpone.

If only a handful of analysts used the warehouse directly, organizations could tolerate some metric logic living in dashboards and some living in people’s heads.

AI changes the economics because it expands the number of analytical users.

A natural-language interface can put complex data access in front of hundreds or thousands of employees who will never read the SQL.

That makes consistent definitions more valuable—and inconsistent definitions more dangerous.

The cost of semantic debt scales with access.

The new analytics stack starts with meaning

For a decade, data-platform strategy focused heavily on where data should live: warehouse, lake, lakehouse, cloud.

The next layer of competition is about what the data means.

Snowflake and Databricks are both building semantic systems because AI cannot reliably operate on table names and schemas alone. It needs business context, trusted definitions and explicit relationships.

Finance is unusually well positioned to shape that layer.

The function already owns many of the company’s most consequential definitions: revenue, margin, expense, cash, working capital, forecast, plan and return.

The CFO’s data strategy should therefore ask a new question.

Not just: “Do we have the data?”

But: “Does every human and every agent calculate the same answer when we ask what it means?”

Product capabilities cited were publicly documented on or before September 6, 2026, and are attributed to vendor documentation. Snowflake semantic views and Databricks metric views address similar problems but are not portable or interchangeable objects. The four-layer semantic stack is a The Finance Observer editorial framework, not benchmark data. No quotes or performance statistics are invented.