ERP systems are excellent at recording transactions. That is their job. The challenge begins when finance teams want to ask increasingly complex questions across multiple years, dimensions and reporting perspectives. Questions such as which customer groups have driven EBITDA over the last 104 weeks, how margin has changed by site and channel, which categories are consuming revenue, or what relationship exists between volume, sales and labour costs over time. These questions sound simple. The underlying calculations often are not.
ERP systems store transactions. Data warehouses store transactions at scale. AI agents can retrieve transactions. None of these automatically store meaning.
Meaning is the layer that explains what revenue really is, how margin is calculated, why EBITDA matters and which measures management trusts. For decades, that meaning has been encoded into semantic models, reporting hierarchies and business rules. AI does not remove the need for that layer. It may increase its importance.
The hidden challenge is that every time a user runs a report, workbook or saved search, the system must retrieve transactions, apply filters, join records, aggregate data, calculate formulas and return results. For operational reporting this works extremely well. For large-scale financial analysis it becomes increasingly expensive.
The challenge grows when users want multiple years of history, weekly granularity, multiple classifications, variance calculations, margin analysis and long-term trend reporting. The same financial relationships are often recalculated over and over again. The same answers may be derived thousands of times from the same underlying transactions.
In many ways, this is not a new problem.
Business Intelligence professionals have been wrestling with it for decades. Before a dashboard could be built, someone had to decide what constituted revenue, what constituted margin, how EBITDA should be calculated, which dimensions mattered and how calculations should behave over time. The resulting semantic models, measures, hierarchies and curated datasets became the foundation upon which reporting was built.
Most users never see this work. They simply consume the finished dashboard or report. Yet every experienced BI consultant understands that the value of a reporting solution often lies less in the visualisation and more in the business meaning embedded underneath it.
Many organisations attempt to address reporting challenges by moving data into platforms such as Snowflake, Fabric, Power BI, Azure SQL, Oracle Analytics or other data warehouse technologies. These platforms are enormously valuable and often solve genuine performance problems. However, they do not eliminate complexity. In many cases they simply relocate it.
The warehouse still contains transactions. The BI layer still needs to calculate answers. The semantic definitions still need to be created. The complexity has changed location. It has not disappeared. The arrival of AI introduces an interesting new assumption. Increasingly, there is a belief that if an AI agent can access the data, it can answer the question. Sometimes that is true.
Often it is not.
An AI agent can identify a revenue account. It cannot automatically know which adjustments should be excluded from a board-pack EBITDA calculation, how management defines manufacturing margin, or which revenue measures are trusted by the executive team. Those definitions still need to come from somewhere. AI may not eliminate semantic modelling. It may simply expand the number of consumers who depend upon it. Historically, semantic models existed to support dashboards, reports, cubes and scorecards. Today they may also need to support CFOs, finance teams, AI copilots and autonomous agents.
The underlying challenge remains the same. The audience simply becomes larger.
This leads to a second question.
If AI agents are going to query ERP systems directly, how will they handle aggregation at scale?
A common assumption is that future AI agents will retrieve raw transactions and derive whatever answers are required. For simple questions this may be perfectly reasonable. However, when organisations begin asking questions across millions of transactions, multiple years, multiple dimensions and complex financial definitions, a new challenge emerges. The cost is no longer just database performance. It is also computational context.
Imagine asking an AI agent to explain the change in EBITDA by customer group across the last 104 weeks and identify the major drivers. Before the AI can provide commentary, it may need to retrieve large transaction sets, aggregate data, calculate financial measures, apply business definitions and construct comparative datasets. Only then can it begin reasoning.
Every time that question is asked, the process consumes compute, latency, context window and tokens. AI is incredibly powerful at interpretation. It is often an expensive way to perform aggregation. Every time an AI agent rebuilds the same financial relationships from raw transactions, it is repeating work that may already have been done.
That observation led us to a simple question. What if we stopped storing only transactions?
What if we also stored meaning?

Not final answers, but curated financial facts. Pre-calculated measures that already understand concepts such as revenue, margin, cost of sales, EBITDA, variance, customer groups, sites, channels and time. Once calculated, those facts can be reused thousands of times.
The result was what we call SpeedLedger.
Rather than repeatedly deriving financial relationships from raw transactions, SpeedLedger creates a curated reporting layer designed specifically for analysis. The objective was not to replace NetSuite. NetSuite remains the system of record. The objective was to create a reusable financial knowledge layer optimised for trend analysis, dashboarding, variance reporting, management reporting and, increasingly, AI consumption.
As AI agents become more capable of querying ERP systems directly, access to data becomes less important. Meaning becomes more important.
An AI agent can retrieve transactions. That does not mean it understands concepts such as Net Sales, Manufacturing Margin, EBITDA or Revenue Consumption. These are business definitions, not accounting records.
A curated reporting layer provides the semantic scaffolding that allows both humans and AI to understand what the numbers mean.
The objective was never faster reports. Faster reports are simply a side effect. The real objective was creating a reusable financial knowledge layer capable of answering the same business questions consistently, whether they are being asked by a CFO, a management accountant, a board member, a dashboard or an AI agent.
As AI becomes increasingly capable of accessing enterprise data directly, the question may no longer be how we give AI access to our data.
The question may become how we ensure it understands what that data means.
Because access to data is becoming easier, meaning is becoming more valuable.
