The Document-to-ERP Pipeline: What Breaks After Extraction
Getting fields out of a document is now the easy part. Getting them into an ERP correctly is where these projects stall: on permissions, on schema mapping and on the three-way match. Here is what we would do differently.
The problem looks solved until you run it on real data
Document AI has matured fast. Modern extraction models handle scanned PDFs, multi-column layouts, handwritten annotations, and non-English text with accuracy that was impossible three years ago. If your benchmark is a clean invoice in a controlled environment, the problem is essentially solved.
Enterprise data is not a benchmark. It is 15 years of inconsistently formatted supplier invoices, purchase orders with handwritten amendments, delivery notes that reference PO numbers from a system that was retired in 2018, and accounts payable clerks who have been manually correcting the same categories of errors for so long they do not even notice them anymore. The AI gets you most of the way. The rest is where projects stall, and it has almost nothing to do with extraction quality.
Lesson 1: Authentication is the actual bottleneck
The first thing people underestimate is authentication, and we mean the ERP's, not the AI pipeline's. Enterprise ERPs have layered permission models: module-level permissions, record-level permissions, field-level permissions, and in some cases session-based permissions that expire at different intervals for different user roles.
A pipeline that works perfectly in a test environment, where you are using a superuser account, will fail silently in production when it hits a field that the service account does not have write permission for. The ERP often does not return an error. It just does not write the field. Your data is wrong and you do not know.
What we do now: map every field the pipeline writes to its permission requirements before build starts. Test with a minimal-privilege service account from day one. Treat OAuth and permission failures as real pipeline errors from the start. They are not environment issues to tidy up later.
Watch out
Lesson 2: Schema mapping is a business problem
Every ERP implementation has a custom schema. The out-of-the-box Odoo invoice model and the invoice model at a company that has been running Odoo for 6 years are different objects. Custom fields, renamed modules, disabled features, and years of workarounds mean there is no standard mapping between a supplier invoice and an ERP record.
A typical case: the GL code mapping comes out wrong and everyone blames extraction. The extraction is fine. The ERP has three different "GL code" fields depending on which accounting period the transaction falls in, and the rule for choosing between them lives in the CFO's head.
What we do now: treat API schema mapping as discovery work. Before any build starts, we sit with the finance team and document every field, edge case and informal rule. We put this in a mapping document that gets signed off before any code is written. The AI implements the mapping. Humans own the business logic.
Lesson 3: The three-way match is a compliance control
The three-way match checks that a purchase order, a delivery receipt and a supplier invoice agree before payment is approved. It is standard in enterprise AP. It is also the step where automated pipelines most often fail silently, because a "match" in a rules engine and a "match" in real life are different things.
A real example: a supplier invoices for 100 units. The PO is for 100 units. The delivery note says 98 units. A naive three-way match fails and the invoice goes to a manual queue. An experienced AP clerk knows that for this supplier, a 2% delivery variance is within contract tolerance and approves it. That knowledge is in nobody's system. It sits with the clerk.
What we do now: three-way match logic is always codified explicitly with the finance and procurement teams before automation. Tolerance rules, exception categories and escalation paths go into the pipeline configuration as written business rules, so the AI never has to infer them. A failed match shows a specific reason the reviewer can act on instead of a generic "requires review" flag.
We would spend the first two weeks of any document pipeline project mapping business rules with the finance team and building nothing. Every rule skipped there comes back after go-live, when it costs far more to fix.
Lesson 4: What we would do differently from day one
Use structured extraction from the start
Do not use a general-purpose LLM for document extraction in production. Use a model fine-tuned or prompted specifically for structured output: JSON with explicit field names, types and confidence scores. It is slower to set up but faster to validate and maintain.
Build the audit trail before the pipeline
Every document that enters the pipeline, every field extracted, every validation result, every ERP write should be logged with timestamps and actor IDs before you run a single document in production. Retrofitting audit logging is painful. Regulators do not care that it was hard.
Make human review a first-class state
Every pipeline needs a well-designed human review interface, not just an exception queue. The review interface determines whether humans catch errors quickly or approve them without reading. In a badly designed exception queue, approving is the path of least resistance, which defeats the purpose.
Test with your ugliest data first
Find the 50 documents in the archive that gave people the most trouble and test against those before you test against clean samples. If the pipeline handles the worst cases acceptably, the clean cases will be fine. If you test only clean cases, you will be surprised in production.
Related reading