Why Finance teams should care about semantic models in the AI era

The term semantic model was not in my vernacular until recently. It’s not a familiar term for most Finance executives. It’s a Microsoft-esque technical term understood mostly by BI practitioners.

Here’s why the semantic layer is perhaps the most important consideration when it comes to your performance management tech stack.

Many organizations are adopting AI for engineering and workflow automation but are struggling to use it effectively for decision-making. Despite more tools releasing their own MCPs and connectors, executives still struggle to pull the right information across systems to make key decisions, resorting to traditional modes of communication.

Context is king when it comes to making AI agents work, and the sole purpose of semantic models is to add context on top of raw structured data. Putting an agent directly on top of your raw data won’t work. Putting an agent on top of your raw data with generic context won’t work. You need an agent, raw data, and context to make it all work together. What provides the context? You guessed it — the semantic model.

Semantic models provide three critical types of context:

Measures

First, it defines measures. When an agent is asked for “revenue,” it could mean many things — GAAP or non-GAAP? Annualized or monthly? Cohort or in-period? Subscription or product? A semantic model encodes these definitions once, so an agent, executive, or analyst exploring the data can understand these nuances and accurately address the user’s question. Measures are more than just formulas — they include formatting, descriptions, data lineage, and more. And it’s tremendously beneficial to have KPIs defined in a consistent manner. Nobody wants to spend time arguing over whose definition of MQL-SQL conversion is correct.

Security

Second, it applies security. This is one of the biggest blockers for Finance teams that work with highly sensitive data. One of our most AI-forward clients built an entire internal AI platform with everything except their financial data due to security concerns. They were finally able to make the financial data available to executives thanks to row-level security applied in the semantic model. Semantic models determine exactly who has access to what, and with Fabric it’s managed through the same Microsoft login by default.

Relationships

Third, it defines relationships. Real decisions require joining data from systems across all functions — CRM, HRIS, ERP, ATS. The semantic model maps them into one coherent structure so an agent can reason across the business in a more predictable way. Semantic models provide the ability to map data in many ways depending on the circumstances and plug gaps without adding noise to the systems of record. The agent can try to MCP into each system and pull and join in real time, but that interaction is slower, less predictable, and harder to reproduce.

The model matters more than the visualization. We chose Microsoft Fabric as the backbone of our Agentic Performance Management (APM) approach because we wanted to bring Finance teams closer to the data instead of continuing to try to pull all the data into one place, which feels more like a fruitless struggle.

We didn’t know it at the time, but we were intuitively searching for a unified semantic layer. Power BI is the brand name, but that’s not actually the differentiator — what actually mattered was the unified semantic layer that undergirds it — something the alternatives like Salesforce Data Cloud, NetSuite Analytics Warehouse, and even Snowflake tend to treat as an add-on rather than the core competency.

With visualization being disrupted by LLMs that can spin up interfaces in seconds, what matters now is the semantic layer spine.

A modular approach beats an integrated one. Specialized EPM tools historically bundled multiple roles into one solution: the data warehouse, the modeling layer, the semantic model, and the visualization layer. Before AI, that integration was a feature. With AI, it becomes more problematic — you are locked into one vendor’s data structure, context, and roadmap for how AI gets applied to your numbers. Instead of an EPM tool doing all four inside a closed box, we increasingly see Excel + Claude/OpenAI/Copilot + Fabric as a more powerful, more portable, and more cost-effective combination that keeps ownership on the client side.

Meeting at one semantic layer also allows the business, finance, and IT to play on the same field. The old pattern is painfully familiar: IT lives in the warehouse, finance buys an EPM tool, and the business buys point solutions. The result is siloing, duplicated spend, and three teams arguing over whose number is right. A shared semantic layer gives all three a single place to collaborate — one definition of the business that everyone builds on and no one owns exclusively.

It also keeps costs down as you scale. An answer an agent composes by writing one query against the semantic model can be rerun for pennies and audited line by line. Fetching that same answer through live API calls across every source, every time it’s asked, can cost orders of magnitude more — and leaves no reproducible trail (hallucination risk!). At one query the difference is trivial; across an organization asking hundreds of questions a day, it compounds into a real line item.

The takeaway. As agents become the primary way decision-makers reach their data, the semantic model becomes a primary knowledge source those agents draw from. Its design — how you define measures, enforce security, and map relationships — will increasingly determine whether AI actually reaches executives with something they can trust, or whether it stalls in a proof of concept.

So ask one question of your own stack: when an executive asks for a number, is there a semantic model between the agent and the raw data — or is the agent left to guess?