The ERP Reporting Agent

Your ERP holds the answer and a queue stands between the question and it. A natural-language reporting agent over Dynamics 365 or SAP — built through supported surfaces, so it survives the next upgrade.

Every organisation running a serious ERP has the same bottleneck. The data is in there. Getting a question answered means either knowing the reporting tool well enough to build it yourself, or joining a queue behind everyone else who does not.

So people stop asking. Decisions get made on the report that already exists rather than the one that would actually inform the decision, and a stale extract circulates by email because someone needed something once and kept it.

A natural-language reporting layer is the obvious answer, and it is also where a lot of teams have been burned — because the naive version produces confident, wrong numbers.

Why "just let it write SQL" fails

Point a capable model at an ERP database and ask a business question, and you will get a query. It may even run. Whether it is correct is another matter, for reasons that have nothing to do with model quality.

The schema is not self-describing. ERP data models are enormous, historically accreted, and full of tables whose names do not indicate their purpose. Dynamics and SAP both carry decades of naming decisions. A model reading raw schema is guessing at semantics.

Business definitions are not in the database. "Revenue" means something specific in your organisation — which transaction types, which company codes, gross or net of what, recognised when. Two people in the same finance team may mean different things. That definition exists in a policy document or in someone's head, and no amount of schema inspection recovers it.

Security is row-level and real. A sales manager can see their region. A model with a service-account connection can see everything. Getting that wrong is a data breach that will be discovered by the person who suddenly sees a colleague's numbers.

Wrong looks exactly like right. A number is a number. There is no visible seam between a correct figure and one produced by a query that quietly dropped a join condition, which is what makes this failure mode so corrosive.

How we build it instead

The agent generates against a reviewed semantic layer, never raw ERP tables, and executes in the user's own security context so row-level permissions apply exactly as they do everywhere else.

A semantic layer comes first. Before any natural-language interface, we build an explicit model of the business concepts: entities, measures, dimensions, and how each is defined and calculated. This is a real artefact, authored and reviewed with the client's finance and operations people, and it is where a definition of revenue actually lives.

The agent generates against the semantic layer, not against raw tables. It is a smaller, well-described surface with the ambiguity already resolved by humans who had the authority to resolve it. This single decision accounts for most of the difference between a reporting agent that gets trusted and one that gets switched off.

Queries run as the user. The agent executes through the platform's own security context, so row-level and field-level permissions apply exactly as they do everywhere else. If a user cannot see a region in the ERP, they cannot see it through the agent. We do not build a privileged pipe and try to re-implement authorisation on top of it.

Every answer shows its work. The result comes with the interpretation the agent made, the definitions it used, the filters applied, and the ability to see the generated query and drill to the underlying records. Users learn quickly where the agent is reliable, which is exactly what you want.

Ambiguity is a question, not a guess. "Show me last quarter's revenue by region" has at least three ambiguities in most organisations — fiscal or calendar quarter, which revenue definition, which region hierarchy. The agent asks rather than picking. Users find this mildly annoying for a week and then rely on it.

Building inside Dynamics 365 and SAP without regretting it

The constraint that shapes these projects is the platform itself.

We build through supported extension surfaces — for Dynamics, the platform's own extensibility and connector model; for SAP, its published integration interfaces — rather than reaching into internal tables or bolting on modifications that the next upgrade will break. It is occasionally slower and it is the difference between a solution that persists and one that becomes a blocker at the next version.

Where the answer needs data the ERP does not hold — CRM activity, warehouse data, an external source — we integrate rather than replicate, and we are explicit about which system is authoritative for what. The ERP is usually the system of record everything else must agree with, and that has to stay true.

What we measure

Answer accuracy against analyst-verified results on a benchmark question set — built with the client, covering their actual questions, and re-run on every change. Clarification rate, which should be healthy rather than zero. Semantic coverage: the share of real questions the layer can express at all, which tells you where to extend next. Time to answer versus the old queue. And adoption, which in practice is the metric that reveals whether people trust it.

What it does not do

It does not replace the data team; it removes their interrupt queue and points them at modelling work. It does not write back to the ERP — this is a reporting agent, and mixing read and write in one surface is how you get an incident. And it does not answer questions the semantic layer cannot express. It says so, and that gap becomes the backlog.

ERP and CRM platforms — Dynamics 365, SAP and the systems around them — are one of the domains we build agentic workflows in. Describe your estate in the console or run /estimate.