AI Can Access Your ERP Data. That Doesn't Mean It Understands It.

A lot of the excitement around AI and business data starts with access.

Connect the AI to the ERP. Give it an MCP server. Point it at the database. Let it read the spreadsheets. Once it can get to everything, the thinking goes, the magic should happen.

That sounds reasonable.

It's also missing a pretty important piece.

In a conversation with longtime BI practitioner Ryan Goodman, Tim Rodman kept coming back to a more basic question: How is the AI supposed to know what the data actually means?

Goodman had a pretty convincing example because he had just lived it.

He had left a client meeting where the team was working through a complicated churn-related problem. On the drive back, stuck in San Diego traffic for roughly an hour and a half, he opened a voice conversation with Claude. The AI already had context from several weeks of work and access to agents connected to multiple semantic layers.

During the drive, Goodman and Claude worked through roughly 15 to 20 different queries and cuts of the data. They did cohort analysis. They did what-if analysis. They looked at profitability and risk. Goodman asked questions by voice and listened to the results through Bluetooth while driving.

By the time he arrived, he had worked the problem far enough to send the CEO a summary of what he thought they should do next. That analysis then became part of a more formal recommendation document, again with the AI helping while Goodman continued checking the numbers and the underlying queries.

That sounds like one of those AI demos that makes everything feel a little magical.

But Goodman’s point was almost the opposite.

The experience worked because a lot of decidedly unmagical work had already happened underneath it.

The data had been prepared. The important metrics had been identified. The business definitions had been captured. The AI had a narrow objective. And when the AI asked for something that already existed in a trusted semantic layer, Goodman had more confidence in the answer than when it wandered off and started writing new SQL on its own.

That is where semantic models start to matter.

“Semantics” Is Really Just Meaning

The term semantic model can sound more complicated than it needs to.

Rodman kept trying to pull it back to simple language during the discussion, and the word that finally stuck was meaning.

A database already has tables and columns. An ERP consultant looking at Acumatica might recognize something like GLTran and know it relates to the general ledger. A column might be called something like DebitAmt. Those names have meaning to a knowledgeable person.

But they do not necessarily tell the whole story.

Goodman used an even better example: billing state versus shipping state.

Imagine a customer table containing both fields. If someone asks the AI to show the geographic distribution of customers, which state should it use?

A person inside the company may already know the answer. Maybe every sales report, board report, territory analysis, and market penetration calculation uses billing state. Nobody even thinks about it anymore because that convention has been passed from person to person for years.

The raw data doesn't know that.

And an AI pointed at the table does not magically know it either.

That's a semantic problem.

The company needs some way to encode the meaning: billing state is not merely the state where the bill goes. It is also the field the company has chosen to represent customer geography for a particular class of analysis.

That description could be a sentence. It could be a paragraph. For AI, Goodman generally leans toward providing more context rather than less because the model can consume it and the extra detail reduces ambiguity.

The important part is not the particular technology used to store the definition.

The important part is that the definition exists.

A Semantic Model Is More Than Column Descriptions

This was one of Rodman’s own light-bulb moments in the conversation.

Coming from the ERP and database world, it's easy to picture a semantic layer as a nicer data dictionary: take the raw database columns, right-click them somehow, add a good description, and call it a day.

That helps, but it's not the whole thing.

A useful semantic layer also captures the derived meaning that sits above the raw transactions.

Nobody wants an AI to read millions of general ledger rows every time someone asks for total sales. The business probably already has a definition of sales. It may have a definition of gross profit. It may have a definition of churn, customer acquisition, activation, retention, utilization, or any number of other metrics.

Those metrics have formulas. They have aggregation rules. They often have a time dimension. And they frequently depend on other metrics underneath them.

That starts to look less like a dictionary attached to raw data and more like a stack of reusable business logic.

Rodman described it as a pyramid.

At the bottom is raw data. Above that are useful aggregations and calculations. Above those are derived metrics that can reuse the work underneath them.

For example, raw invoice lines contain revenue and cost information. Revenue and Cost of Goods Sold can be calculated or aggregated from those lines. Profit can then be calculated from revenue minus Cost of Goods Sold and other ratios or KPIs can build on top of those numbers.

Once that work has been done and defined properly, the AI doesn't have to rediscover the business from scratch every time somebody asks a question.

That's a BIG difference.

The Excel Version Makes This Much Easier to Understand

The conversation got much simpler when Goodman stripped away Snowflake, Databricks, Microsoft Fabric, Agents, and all the other technology names and simply went back to Excel.

That's probably the easiest mental model for a Mid-Market ERP like Rodman.

Picture one Excel workbook.

The first sheet contains raw Accounts Receivable Invoice Lines.

The next sheet contains a customer-level view with useful metrics: when the customer first bought, how old the relationship is, how much the customer buys, where the customer is located, whether the customer is growing or shrinking, and whatever else matters for the problem being analyzed.

Then add another sheet that acts as a dictionary or glossary. Each metric gets a name and a description explaining what it means.

That's already starting to look like a semantic layer.

Goodman pushed the example even further. Many companies already have enormous Excel workbooks with dozens or even a hundred tabs. Ninety of those tabs might be hidden, but they still feed formulas and pivots that eventually produce the ten tabs people actually look at.

The workbook is doing layers of transformation.

Raw data becomes a pivot. The pivot gets more formulas. That becomes another summary. Eventually something lands in a report or PowerPoint deck and becomes the version that the business people discuss in a meeting.

The sophisticated semantic platforms are doing a much more formal version of the same general idea: building reusable abstractions of meaning on top of raw or processed data.

Thinking about it that way removes a lot of mystery.

The Objective Function Comes First

There was one phrase Goodman repeated throughout the discussion: objective function.

It sounds a little academic, but the idea is simple.

What are you actually trying to accomplish?

Without that, semantic modeling can turn into an endless documentation project. A company could theoretically define every field, every event, every process, every ratio, and every possible relationship in the business.

Why?

Goodman’s view is much more pragmatic. Start with a problem that hurts or an outcome that matters.

Suppose a $10 million manufacturer wants to grow to $15 million.

That is still too broad, so narrow it again. Assume production capacity is fine. The company needs more buyers.

Now the questions become more useful:

• How many new buyers are being added?
• Where are those buyers coming from?
• Which customers are growing?
• Which customers are decaying?
• How old are the customer relationships?
• Which customers are actually profitable?
• What's happening month over month?

Those questions tell the team which data and which metrics deserve attention.

This matters because revenue growth by itself can be misleading. A company can increase orders and revenue while adding customers who are not profitable. So the semantic model may also need cost of goods sold, profit, margin, and whatever other levers help evaluate the real objective.

The objective determines the questions.

The questions determine the metrics.

The metrics determine what data needs to be prepared and explained.

Pretty simple when it's framed that way.

Time Is One of the Biggest Sources of Semantic Confusion

One of the more important technical points in the conversation involved time.

Goodman described time as one of the most important dimensions to get right because two people can use the same underlying data and still produce radically different answers simply by using different definitions of time.

That shows up everywhere.

Is revenue based on invoice date, ship date, order date, posting period, or something else?

Does “last quarter” mean calendar quarter or fiscal quarter?

Was the report pulled at 8:00 a.m. or 4:00 p.m. after another batch of transactions posted?

Two people can walk into the same meeting with the same report and both believe they are right.

Sometimes both ARE right, within the definitions they used.

That's the semantic disconnect.

The discussion of cohorts made the same point from another angle. A cohort is basically a segment tied to a specific period of time. Customers acquired in 2025 can be treated as one cohort, and the business can then watch what happened to that group afterward: how many stayed, how many left, how profitable they became, and how their behavior changed.

The time boundary is part of the meaning.

If AI is going to perform that analysis reliably, the time logic cannot stay trapped in somebody’s head.

Business Process and Reporting Are Two Sides of the Same Coin

Rodman connected the semantic-model discussion to something he had noticed years earlier in ERP consulting: business process and reporting are two sides of the same coin.

A process moves information forward through the business.

Reporting looks back at what happened and tries to determine whether the process produced the desired result.

Focusing on only one side creates weird outcomes.

A process-improvement person can obsess over shaving a few seconds off a machine operation without being able to explain whether that improvement actually matters to revenue, profitability, risk, delivery, or some other meaningful outcome.

On the other side, an analyst can produce piles of reports without having any ability to change the process that drives the numbers.

The useful loop connects the two.

Goodman described many metrics as reflections of events that occurred inside processes. A business process might contain 50 steps, but the company may only need two or three metrics to know if the thing worked.

Did the event happen?

How often did it happen?

Who did it work for?

Who did it not work for?

What happened to revenue, profit, or risk as a result?

That is where ERP consultants may have a natural opening in the AI world. They already spend their time understanding how transactions flow through a business and why data lands where it lands.

Semantic modeling asks a related question in the other direction: once the data is there, what does it mean, how should it roll up, and which parts matter enough to steer the business?

An MCP Server Is Not the Same Thing as a Semantic Model

This distinction is going to matter for ERP consultants.

MCP can solve an important problem: giving an AI system controlled access to tools or data.

That is useful.

But access and understanding are not the same thing.

Goodman’s blunt description was that if an MCP server simply exposes transactional data, it's mostly just removing the user interface. Instead of clicking through five screens and mentally stitching the information together, a person can ask the AI to retrieve it.

That can save real time, especially for laborious navigation or data entry.

But the MCP connection does not automatically define the company’s metrics.

It does not automatically know which version of revenue the executive team uses.

It does not automatically know that billing state, not shipping state, is the accepted geography field for market analysis.

It does not automatically know the difference between a trusted, established KPI, and a calculation somebody made up five minutes ago.

So an ERP MCP server may be valuable without delivering the full “ask anything about the business” experience people imagine.

The missing piece is often semantic thinking.

And that semantic layer does not have to begin as some giant enterprise technology project. Goodman expects plenty of organizations to build their own practical versions using CSV files, Markdown files, glossaries, dictionaries, or other simple assets that add company-specific meaning on top of whatever baseline definitions the ERP vendor provides.

The format is not the point.

The meaning is the point.

Data Semantics and Business Semantics Are Related, but They Are Not the Same

One of the more useful distinctions Goodman made was between data semantics and business semantics.

Data semantics live closer to the technical layer.

They answer questions such as where a metric comes from, how it's calculated, which source fields feed it, what time dimension applies, how it aggregates, and what data lineage leads back to the source.

That work needs precision. At some point, a technical system needs a specific definition it can calculate consistently.

Business semantics are messier.

Two departments can use the same word—revenue, for example—and mean slightly different things. The definitions may even be represented differently in separate systems.

The natural technical instinct is to reconcile everything down to one perfect definition.

Goodman is less interested in forcing that reconciliation at the business layer than in making the differences visible.

Where does the semantic disconnect happen?

Why does sales mean one thing by revenue while finance means another?

Which definition is being used in this meeting, report, or decision?

That is a knowledge problem as much as a data problem.

It is also one reason simply throwing every document, process map, report, and database table into one giant AI “vat” is not a great strategy. Context still matters. The objective still matters. Different collections of knowledge have different jobs.

Business process documentation can be extremely valuable when the objective is improving how the business operates. A metrics glossary can be more important when the objective is understanding how the business is managed. They can be connected, but merging everything into one enormous pile can just create more noise.

The Analyst Job Is Moving From Dashboards to Reusable Intelligence

Goodman has lived through several generations of BI, starting with Excel, moving into Business Objects and Xcelsius/SAP Dashboards, and spending years teaching, implementing, and troubleshooting analytics in large enterprises.

His view of the analyst role is changing pretty dramatically.

Historically, an analyst might build a query, attach it to a dashboard, publish the dashboard, and hope people use it.

Maybe the team would track report launches if they were being unusually diligent.

Now the interface can be a conversation.

Instead of building a dashboard for every possible question, the analyst can build reusable semantic assets and agents that know how to answer classes of questions.

But that does not make the analyst less important.

It changes the work.

Goodman described regularly reviewing the logs from his AI interactions. Which agent answered the question? Which queries ran? Did the system return something wrong? Did an executive notice that it was wrong? What topics are users asking about? Where is the agent being forced to write new SQL because the trusted semantic layer does not yet contain what the user needs?

That last signal is especially useful.

In Goodman’s setup, Claude can first ask a more narrowly scoped semantic agent for an answer. That agent has access to curated semantic layers and predefined queries for common questions.

If the answer comes from there, confidence is higher because somebody has already done the work to define and test the logic.

If Claude starts writing SQL against lower-level data, the answer deserves more skepticism. Maybe the data is missing. Maybe the wrong table was chosen. Maybe the date logic is wrong. Maybe the model simply misunderstood the question.

The point is not that SQL is bad.

The point is that the path to the answer tells you something about how much trust to put in it.

That's a much more interesting job than just building another dashboard.

AI Makes Monitoring More Important, Not Less

A semantic layer is not finished when it gets published.

The business changes.

A company adds a product. It acquires another company. A metric changes. A new customer segment appears. Someone updates a report. A field gets repurposed. A definition that was correct six months ago quietly becomes wrong.

Goodman compared this to other probabilistic systems such as machine-learning models: they need monitoring because performance can decay over time.

AI agents are similar.

They need to be watched, evaluated, and improved.

This is also where conversational interfaces create a new kind of data that dashboards never provided very well: the why behind the usage.

A dashboard can tell you that 15 people opened a report.

It cannot necessarily tell you why 15 people opened it.

A conversation log can.

Goodman is already analyzing AI interactions to identify topics and trends. That can reveal what executives are trying to understand, what questions keep coming up, and where the semantic layer is missing something important.

Useful? Absolutely.

A little creepy? Also yes.

Which leads directly to trust.

The Hard Part Is Still Trust and Governance

For all the new technology in the conversation, some of the hardest problems sounded very familiar to anyone who has implemented an ERP or CRM system.

People have to trust the data.

They have to trust the people who entered the data.

They have to trust the definitions.

They have to trust who can see what.

And now they also have to decide how much they trust the AI providers and the AI’s answers.

Goodman is cautious here. Even though he uses tools such as Claude every day, he does not treat the companies behind the major LLMs as inherently trustworthy just because a data protection agreement exists. His practical rule is to tread carefully with sensitive information and avoid putting information into those systems that would create a serious problem if it were exposed.

But the more interesting trust problem may be internal.

If employees know that every AI conversation can be logged, scored, and reviewed, will they use the system honestly?

If executives use AI as a way to expose what everyone is thinking and then punish people for asking the “wrong” questions, adoption is going to slow to a crawl.

On the other hand, if leadership treats AI as a way to raise the capability of the whole workforce, accepts that mistakes will happen, and is transparent about how the system is monitored, then the same technology looks very different.

That's not really an AI problem.

It's an organizational trust problem amplified by AI.

The same thing has happened with ERP and CRM systems for decades. A CRM only works if salespeople trust the organization enough to put their knowledge into it. An ERP only works if users trust that other people are entering and maintaining data correctly.

The technology is the glue.

People supply the meaning.

And yes, governance is still part of the deal. Goodman boiled it down to three practical questions:

• Is the data secure
• Is it available to the right people
• Is it correct?

Governance can absolutely become red tape. A company can secure itself to the point where nobody can get anything done.

But pretending governance does not matter is not much of a strategy either.

Same old problem. Much more powerful tools.

DataTools Pro Came Out of the Semantic-Disconnect Problem

Goodman’s work on DataTools Pro grew out of this exact problem.

The original goal was to shorten the reconnaissance work that happens when a consultant enters a new organization.

A good consultant can ask executives what hurts, what they are trying to accomplish, and how they will know if the problem gets fixed.

But then comes the detective work.

What metrics does the company already track?

Which reports and dashboards are actually used?

Where do those metrics come from?

How many versions of “revenue” exist?

Which systems contain the data?

In a large enterprise, Goodman said that discovery can take weeks, months, or historically even quarters.

DataTools Pro was designed to accelerate some of that work by examining existing CRM reports and dashboards, determining what's actually in use, and reverse-engineering the metrics that the organization already relies on.

That lets the consultant walk into a meeting with more of the company’s vocabulary already understood.

Instead of discovering during the meeting that the organization has 20 flavors of revenue, the consultant can already know that the dashboard on one side of the company uses a different flavor from the dashboard on the other side.

That matters because semantic disconnects are often where the pain actually happens.

The first version of DataTools Pro was released around 2023. Goodman later stopped shipping updates for a period while he rethought the direction. The earlier approach had gone more bottom-up, from metrics toward underlying technical data. His more recent work has moved the other way: start with the business pain, initiative, strategic impact, and metrics that matter, then connect downward as needed.

He currently thinks of the product more as a metrics glossary and business-semantics tool than as a complete data semantic layer.

That distinction is intentional.

A technical semantic model can only describe the data that exists.

A business glossary can also capture something the company cares about even when the supporting data is missing or incomplete.

That gap is useful information too.

Mid-Market ERP Consultants May Be Better Positioned for This Than They Think

A lot of ERP consultants are understandably wondering what AI does to their jobs.

Rodman’s view in the conversation was more optimistic, especially for people who understand business processes and business data.

The opportunity is not necessarily to become an AI researcher or build the next foundation model.

It may be much closer to the work that ERP consultants already do.

They know how orders, invoices, inventory movements, projects, labor, purchases, payments, and general ledger transactions flow through a system.

They know where users make exceptions.

They know which fields look redundant but are not.

They know that two reports with the word “sales” in the title can still answer different questions.

They know that the executive asking for “revenue” may not mean the same thing as the accountant asking for “revenue.”

That knowledge is exactly what an AI system does not get merely because somebody connected it to a database.

So the job starts to look less like giving AI access and more like teaching AI the business.

Not teaching AI everything about the business.

Teaching AI the part required to solve a useful problem.

That distinction is probably the most important takeaway from the entire discussion.

Start With Pain, Then Build Meaning Around It

The temptation with AI is to start broad.

Connect everything. Index everything. Document everything. Give the model every table, every file, every process map, every report, and every email, then ask it to figure the company out.

Maybe someday that works exactly the way people imagine.

But Goodman is not building around that assumption today.

His approach is narrower and a lot more practical. Find a painful problem with meaningful business impact, define the objective, and identify the few metrics and events that actually matter. Then prepare the data, capture the meaning, give the AI a constrained path to trusted answers, and monitor what it does as people use it.

The semantic model is not the flashy part of AI.

It's the part that turns access to data into something closer to understanding.

For ERP consultants, accountants, analysts, and anyone else who has spent years figuring out what business data actually means, that may be very good news.