A semantic layer so AI speaks your finance metrics

A semantic layer is a governed catalog that sits between your raw tables and everything that queries them, holding one canonical definition of each metric and dimension. When a dashboard, a notebook, or an AI agent asks for net revenue, each request resolves to the same query, with the same filters and currency handling underneath. The definition lives in one place instead of being re-derived by whoever happens to ask.

The problem it solves is boringly common. Finance asks the data warehouse for revenue and gets one number. Someone pulls the same period from the billing system and gets another. Both are defensible, because each encodes a slightly different rule about credits, refunds, deferred amounts, and the exact moment revenue is recognized. Multiply that by every metric a company reports and you get a permanent low-grade argument about whose figure is right. Put an AI agent into that environment and the argument gets faster, not settled. The model will happily generate a confident sentence containing whichever revenue figure it happened to query.

Why AI makes the metrics problem urgent

For years the industry lived with definition drift because a human sat between the query and the decision. An analyst who saw revenue come back 8% low knew to check whether refunds were being netted, and would quietly fix the query. That human is a filter, and it is expensive, and it does not scale to hundreds of ad hoc questions a day.

When you let a language model write SQL against physical tables, you remove the filter and keep the ambiguity. The model has no idea that amount_usd in the invoices table already excludes tax while the orders table includes it. It sees two plausible columns and picks one. There is no malice and no obvious error to catch. The output is grammatical, formatted, and wrong by the amount of the tax line.

• A model asked for churn will guess at the denominator: logos, seats, or dollars, and at whether to count downgrades.
• A model asked for gross margin will guess which cost buckets belong above the line.
• A model asked for revenue will guess the recognition rule, the currency date, and whether intercompany eliminations apply.

Each guess is individually reasonable and collectively unauditable. The semantic layer removes the guessing. The model no longer writes SELECT SUM(amount); it requests the metric named net_revenue for a time grain and a set of dimensions, and the layer compiles that request into the one query your finance team has signed off on.

What actually lives in the layer

A useful semantic layer is more than a dictionary of column aliases. It holds the parts of a metric that people usually leave implicit and then disagree about later.

• The measure and its aggregation. Not just “revenue” but the exact expression, the grain it is valid at, and whether it sums, averages, or requires a distinct count.
• Join paths and entity resolution. How a customer in billing maps to a customer in the CRM to an entity in the general ledger, so a metric sliced by customer means the same customer everywhere.
• Time semantics. Which date drives the metric (booking, invoice, recognition, cash), and how it handles point-in-time correctness so a restated prior period does not silently rewrite last quarter’s reported figure.
• Filters baked into the definition. Test accounts excluded, intercompany eliminated, a specific set of statuses that count as active. These are the rules that never make it into a dashboard title and cause the most drift.
• Currency and unit handling. The conversion rate source and the date it is applied, so a EUR contract reported in USD is not off by a month of FX movement.
• Lineage and ownership. Which physical tables feed the metric, who owns the definition, and when it last changed. This is what turns an AI-generated number into something with an audit trail behind it.

The last point matters more in finance than almost anywhere else. When a number lands in a board deck or a regulatory filing, someone has to be able to trace it back to source. A metric defined in the semantic layer carries that lineage by construction. A metric that a model reconstructed from raw SQL carries nothing but the model’s confidence.

Governance is the hard part, not the query engine

The engineering to compile named metrics into SQL is well-trodden. Several open-source and commercial engines do it. The work that decides whether the layer succeeds is organizational, and it is where most projects underinvest.

Someone has to own each definition, and changes have to go through review the way code does. A pull request that alters how churn is calculated should be visible, discussed, and versioned, because it changes every downstream number the moment it merges. We treat metric definitions as code: they live in the repository, they have tests, and a proposed change runs against a set of known periods to show exactly how the reported figures move before anyone approves it.

That test harness is worth building early. For each metric, keep a small set of periods with a hand-verified expected value, the way you would keep an eval set for a model. When someone edits the definition, the harness recomputes those periods and flags any that changed. Most edits should change nothing; the ones that do are the ones that need a human to sign off. This is how you catch the well-meaning refactor that quietly moved a cost bucket above the margin line.

Reconciliation belongs in the same place. The semantic layer’s revenue metric should tie out to the general ledger on a schedule, and a break should raise an alert rather than wait for quarter-end to surface. Once that tie-out is automated, the layer stops being a convenience for analysts and becomes the thing you can point an agent at without holding your breath. The model asks for a metric, gets a number that already reconciles to the books, and cites a definition that a person owns. That is the difference between AI that drafts a plausible figure and AI you can put in front of an auditor.