Most middle-market ERP automation projects do not fail because the AI model made a wrong prediction. They fail because the environment the model is deployed into was already fragile, and the integration work that was supposed to be finished before the first API call was never done.
This is not an argument against AI in ERP. It is an argument for checking the plumbing before turning on the tap.
What fails in ERP automation before the model is involved
A typical mid-market ERP setup is three or four systems connected by ETL scripts and manual entry. The accounting module does not talk directly to inventory. Inventory does not talk directly to procurement. A script pulls data from one system each night, transforms it, and pushes it into another. Someone fills in the gaps on Monday morning.
Three structural problems appear in nearly every engagement of this kind, and none of them require AI to create.
The first is interface mismatch. The module you are integrating with has a documented schema from its installation. The actual data coming out of it today does not match that schema. Field names have drifted. A required field is sometimes null. A vendor code that was three characters is occasionally four. The documentation was not updated after the last migration. This is normal in any ERP environment that has been live for more than three years, and it is invisible until something tries to read the data programmatically.
The second is the absent data contract. Nobody in the business owns the mapping between modules. Not the CFO, not IT, not the implementation partner from the original build. There is no document that says vendor_id in the accounting module is the same field as supplier_code in procurement, and that accounting is the canonical source of truth. When a vendor is renamed in one module, nobody knows which others need updating. The integration works until it does not, and when it stops, the diagnostic starts from zero.
The third is the missing test path. The integration was validated against a sample export from the staging environment. It has never been run against real production traffic without the engineer who built it. When something fails in production, the first question is always the same: has this happened before, and nobody noticed?
Each of these is enough to stop an automation. Custom LLM Integration covers the same failure surface: the model is rarely the problem. The interface contract and the data ownership almost always are.
The concrete version: AP invoice processing. An invoice arrives, a script pushes it to inventory for PO match, then to accounting for payment approval. Each module uses a different field name for vendor ID. The script picks one. It works until a vendor ID changes in accounting but not in procurement. Three invoices route to a payment queue pointing at a vendor ID that no longer exists on the accounting side. The ETL script does not log mismatches; it drops the record silently. The invoices surface three weeks later when an accounts payable clerk notices the vendor has not been paid. No AI involved. A data-contract failure.
What the model adds to an already fragile stack
Once the baseline integration problems are present, deploying AI introduces two failure modes that do not appear in standard ERP troubleshooting guides.
The first is non-determinism. A model parsing an invoice and assigning an account code does not look up a rule in a table. It applies a learned mapping from training examples. For common documents it is nearly always right. For uncommon ones it assigns confidently and silently. There is no error code, no failed record, no exception log. There is a transaction in an account it does not belong to, and it will pass every automated validation the ERP applies, because the field is populated and the format is correct. The error is only visible to a human who knows enough about the chart of accounts to notice the assignment is wrong.
When AI Agents Break covers what this looks like in practice: formally correct output that is semantically wrong, and why the standard monitoring stack does not catch it.
The second is cost drift. ERP documents are not uniform in size. A standard purchase order is short. A vendor contract amendment can be long. A multi-line invoice with partial shipment notes and price adjustments is longer still. A model processes each document and the cost scales with length. Standard ERP transaction logs have no field for token consumption. A business that automates invoice processing in September may not notice until January that the Q4 documents it processes are longer on average, and the model's monthly operating cost changed accordingly. The monitoring that ERP administrators read does not surface this without explicit instrumentation.
Both problems sit on top of the structural three. They do not substitute for them. Back-Office Automation with AI covers the full taxonomy: the same three classic integration failures plus these two AI-specific ones, and how to work through the diagnostic in order.
What "working" means for an ERP integration with AI
Five properties separate a working ERP automation with AI from one that works in demo but fails in production.
The data contract between modules is documented and versioned. Not in a vendor's installation guide from the original build, but in a document the current team owns: which system is canonical for each shared field, what version of the mapping is in production today, and who is responsible for updating it when a module changes. Building MCP Servers covers what a versioned, documented data contract looks like in practice, in the context of structured system interfaces.
The downstream error path is defined. When the model processes a document and assigns it incorrectly, the record goes to a visible human review queue, not to an approved-but-wrong state. The queue is monitored. Someone owns it.
Token consumption at the ERP boundary is instrumented alongside transaction volume. The dashboard that an operations manager or finance team reads has a line for API cost per document type. Without it, there is no way to surface cost drift before it becomes a billing surprise.
There is a test path on real ERP traffic that a member of the team can run without the original engineer present. Not a test against sample data. A documented procedure that runs against the actual system, produces a result any reviewer can read, and does not require context that lives only in the builder's head.
Exceptions are visible. The system fails loudly, not silently. A dropped record is a logged event. A low-confidence assignment is flagged for human review, not processed. In an ERP context, a missed invoice in a review queue is visible and fixable at any point. A wrong account code that passed silently is found at year-end, after the period is closed.
Five questions to ask before you hire anyone to build this
One: can you show me the data contract between the modules you are integrating, and who will maintain it after you leave. A vendor who cannot show this has not done the diagnostic work. Writing the contract is the first deliverable, not a prerequisite the business is expected to supply.
Two: when the model assigns a document to the wrong account, where does the record go, and who in the business reviews it. The answer should name a queue, a role, and a monitoring frequency. "The model is accurate enough that this rarely matters" is not an answer. It will matter.
Three: where will token consumption per document type appear in the monitoring dashboard my team already uses. A system that processes documents with a model but cannot show cost per document type is not ready for production. It is ready for a demo.
Four: which member of my staff, by name and role, can run the ERP test path after you are gone. A named person, not "your IT team". If nobody in the business can run the test, the business does not own the system. That means a documented, maintainable integration that any competent developer can verify and service, without the original engineer on call.
Five: what is the smallest scope you will accept for the first phase. If the answer involves more than one module boundary, a custom model, or a new data layer, the vendor is scoping an enterprise engagement. That may be the right answer, but it is worth knowing before the discovery call ends.
One senior engineer, your ERP codebase, a working integration in about a week. You own every line of code.
