Connecting SAP to AI Workers

Every serious SAP integration eventually stops being a technical problem. The interface works, the data flows, and then somebody asks what a field actually means — and discovers the answer lives in a person's memory rather than anywhere in the system.

A finance analyst is trying to explain why two subsidiaries in the same group report margin differently on what is supposedly the same product line. The extract is clean. The field names match. The numbers do not, and after a week of tracing she finds the reason: in one part of the business, a cost element that everyone assumes captures inbound freight also absorbs a category of handling charge, because during the original implementation — twelve years ago, under time pressure, with a consultant who has long since moved on — someone decided that was the least disruptive place to put it. Nothing about that decision is wrong. It was reasonable at the time, it has been consistently applied ever since, and roughly four people currently employed know about it. It is not in the data dictionary. It is not in the field description. It exists in the collective memory of a finance team, and it has been quietly shaping a number that flows into a board pack every quarter.

This is the shape of nearly every hard ERP integration problem, and it is almost never the shape discussed when a company decides to connect its ERP to something new. The conversation starts with interfaces and credentials and refresh cadence, all of which are real and all of which are solvable. Then it hits the thing connectivity cannot solve, which is that an enterprise resource planning system is not merely a database of business facts. It is a sedimentary record of thousands of local decisions about how this particular company chose to represent its business, and most of those decisions were never written down in a place a machine can read.

The interface is documented; the convention never is

Large ERP systems are, by design and by necessity, heavily configured to the organization that runs them. That is not a defect; it is the entire proposition. A system that runs manufacturing, distribution, finance, and procurement for a multinational cannot ship with one opinion about how a business should be structured, so it ships with a framework and a very large number of places where an implementation team makes choices — which organizational units map to which legal entities, what counts as a distinct material versus a variant of one, where a cost that could plausibly sit in three places actually sits, how a status field technically free to hold a dozen values is used in practice by the people who touch it daily. Over the life of an implementation these choices accumulate into something with the density of a legal code, and like a legal code, the written text is only half the story — the other half is the settled practice that grew up around it.

The result is that a company's ERP contains two layers of meaning, and only one of them is machine-readable. The first layer is the schema: tables, fields, types, relationships, all inspectable and perfectly honest about their structure. The second layer is convention: what this field is used for here, which of its values are load-bearing and which are vestigial, and which apparently identical fields in two parts of the business are quietly measuring different things. The schema tells you a field holds twelve characters of text; it does not tell you that in one region the first two characters encode a routing rule agreed verbally years ago and honored ever since. That convention is as operationally binding as anything in the schema, and it exists only in the heads of the people who work with it.

Anyone who has worked in enterprise data long enough recognizes the moment this becomes visible. A warehouse project stalls near the finish line, not on extraction but on reconciliation. A migration slips a quarter because nobody can agree on what "active" means across two divisions. A reporting layer produces a number that finance rejects on sight, and the ensuing archaeology turns up a convention that everyone in one building considered too obvious to document. In each case the technical work was finished and the project was nowhere near done, because the remaining work was interpretive and the interpretation had no owner.

Which means SAP integration is really an interpretation problem

Once you see the two layers, the framing of the whole exercise changes. "Connecting to the ERP" sounds like a plumbing task — establish the pipe, move the records, land them somewhere useful. But the pipe was rarely the hard part, and it has gotten easier every year as interoperability standards have matured. What is hard, and what has not gotten meaningfully easier, is deciding what the records mean once they arrive. A system that reads a purchase document and acts on it has to know whether the vendor number in front of it is the paying entity or the shipping entity, whether a blank field means "not applicable" or "nobody filled it in," whether a document type that behaves one way in one company code behaves the same way in another. These are not questions about the ERP as a product. They are questions about this company's history with it.

This matters more now than it did five years ago because the systems we connect to ERPs have started doing more than reading. A reporting tool that misinterprets a convention produces a wrong chart, and a human looking at the chart usually catches it, because people carry the local convention in their heads and feel the wrongness immediately. A system that reasons over the same data and then takes action — proposing a payment run, flagging an exception, reconciling an account, drafting a purchase decision — has no such instinct unless someone gives it one. It will apply a plausible general interpretation to a field that carries a specific local one, and it will do so consistently, at volume, with the confidence of something that has no idea it is guessing. The failure mode is not a system that breaks loudly. It is a system that works beautifully in the region where its assumption happens to hold and is subtly, systematically wrong in the region where it does not.

This is a large part of why enterprise autonomy projects stall in ways their sponsors did not anticipate. Gartner has predicted that more than 40 percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. In an ERP context, "inadequate risk controls" is often something more specific and more mundane than the phrase suggests: nobody could establish, to the satisfaction of the people accountable for the numbers, that the system understood what it was reading. The pilot produced impressive results on a clean slice of data. It could not survive contact with a second business unit that had made different choices a decade earlier, and it could not explain, when challenged, which choices it had assumed.

What a system acting on ERP data owes the people accountable for it

The obligation that follows from all this is narrower and more achievable than "build a system that understands your business." It is that any system operating on ERP data must be able to state, on demand and in plain language, which local convention it is relying on for a given conclusion. Not merely the source table and field — that is provenance, and provenance is the easy half. The harder and more valuable disclosure is interpretive: I treated this document type as an intercompany transfer because that is how it is used in this entity; I excluded these cost elements from the margin calculation because your team's convention places handling charges there; I am uncertain how this status field is used in the second division and have not applied the same rule. A system that can say those sentences is one a controller can argue with, correct, and eventually trust. A system that cannot is a black box asserting numbers, and no responsible finance organization should extend it authority over anything.

That requirement has practical consequences for how these systems are built. The local conventions have to live somewhere durable rather than baked invisibly into a prompt or a mapping file — treated as enterprise knowledge that a named person owns and updates as the business changes, so a shifting convention shifts the system's interpretation with it rather than leaving it to drift silently. The interpretive assumptions have to surface as observations attached to the work, visible before the output is used rather than reconstructable afterward under duress. And the authority to act has to be graduated according to how much interpretation the action depends on: reading and summarizing is low-stakes, proposing is medium, and anything that posts to a financial record stays under accountable human authority, with a named person approving it, because the entire point of a ledger is that a human being stands behind every entry in it. This is what the emerging discipline around the autonomous enterprise keeps arriving at from different directions — that autonomy is not the removal of human judgment but the relocation of it, from executing every step to owning the interpretation and the gates. It is the principle behind how platforms like StudioX structure enterprise integration work: connectivity through open protocols is treated as the commodity it has become, while the local semantics are treated as the asset, held explicitly, versioned, and always attributable to the humans who defined them.

The mental model worth carrying away is that an ERP is less like a database and more like a language with dialects. The vocabulary is shared across every company that runs the same system, which is why integration looks easy from the outside. The dialect is local — accent, idiom, a hundred small usages that only make sense if you know the history — and fluency in the vocabulary is not fluency in the dialect. When you evaluate anything that proposes to work against your ERP, the useful question is not how many objects it can read or how fast it can sync. It is whether it can tell you, without being asked twice, which dialect it thinks it is speaking, and what it will do when it encounters a sentence it has not heard before.