Where Extraction-Only IDP Tools Stop and Artificio Keeps Going: The Last Mile Into SAP That CSV Exports Never Solve

There is a moment in almost every document automation project where the demo stops being impressive.

It happens about six weeks after go-live. The extraction engine is performing beautifully. Ninety-four percent field accuracy on supplier invoices. Header data, line items, tax lines, PO references, all pulled cleanly off scanned PDFs that used to take an AP clerk four minutes each. The vendor dashboard shows a green wall of successful extractions. Someone in procurement forwards the accuracy report to the CFO.

And then the AP manager walks over to the project lead and asks the question that unravels everything. "So where do these go?"

The answer, on most extraction-only platforms, is a folder. Or an SFTP drop. Or an API endpoint that returns beautifully structured JSON. Or, most commonly, a CSV file with one row per invoice and a second CSV with one row per line item, joined on a document ID that means nothing to anyone in SAP.

The extraction was never the hard part. Getting a validated business document to become a posted, audit-traceable object inside SAP is the hard part. That gap between "we read the document correctly" and "the document is now a parked FI invoice in company code 1000 with the right cost center, the right tax code, the right GR reference, and a fully reconstructed audit trail" is the last mile. Extraction-only tools do not cross it. They were never built to.

This post is about what actually lives inside that last mile, why CSV exports structurally cannot solve it, and what a platform has to do differently to finish the job.

The comfortable lie of the accuracy metric

Document AI vendors compete on extraction accuracy because it is measurable, demoable, and flattering. You can put two engines side by side, run the same 200-invoice test set through both, and produce a chart. Buyers love charts.

The problem is that field-level accuracy has a weak relationship with straight-through processing rate, and straight-through processing rate is the only number that shows up in a finance budget.

Consider a supplier invoice extracted at 96 percent field accuracy. Sounds excellent. Now count the fields on a typical three-way-match invoice with eight line items. Vendor name, vendor tax ID, remit-to address, invoice number, invoice date, currency, gross amount, net amount, tax amount, PO number, payment terms, plus eight lines each carrying material description, quantity, unit of measure, unit price, line total, and tax code. That is roughly sixty extractable values.

At 96 percent per-field accuracy, the probability that a single invoice comes through with zero errors is around nine percent. Ninety-one out of a hundred invoices contain at least one wrong value somewhere.

Extraction-only vendors handle this by showing you a confidence score and a validation screen. A human looks at the flagged fields, corrects them, clicks approve, and the record moves to the export queue. The vendor counts that as a success. Their metric is satisfied.

But the AP team is still doing work. They are still touching every document. The touch is shorter, and that is genuinely valuable, but the promise was straight-through processing and what got delivered was faster manual processing.

Then comes the second cost, the one nobody budgeted. The corrected data still has to reach SAP.

What the export queue actually hands you

Picture the CSV that comes out of an extraction-only platform. It has clean columns. Vendor name, invoice number, date, amount, PO reference, line items in a child file. Everything the document said, faithfully represented.

Now open MIRO and look at what SAP wants.

SAP does not want a vendor name. SAP wants a vendor master record number, resolved against LFA1, disambiguated across multiple company codes, correct for the specific purchasing organization involved, and matched even though the invoice says "Acme Industrial Supply Co" while the master record says "ACME IND SUPPLIES INC" because someone created it in 2009.

SAP does not want a PO number as text. SAP wants a purchase order that exists, is not blocked, is not fully invoiced already, belongs to the right company code, and has open goods receipt quantity available against the specific line the invoice is claiming.

SAP does not want a tax amount. SAP wants a tax code, jurisdiction-aware, that when applied to the net amount produces the tax amount the supplier printed. If those two numbers disagree by four cents because of rounding on a multi-line invoice, the posting fails.

SAP does not want line items in document order. SAP wants line items matched to PO schedule lines, which may be in a completely different order, may be partially received, may be split across multiple deliveries, and may reference materials the supplier described using their own catalog names.

The CSV contains none of this. It cannot. The CSV is a representation of what the document said. SAP requires a representation of what the business system believes. Between those two representations sits a translation layer, and that translation layer is where document automation projects go to die.

The seven problems hiding in the last mile

When teams try to bridge the gap themselves, usually with a middleware layer or a set of ABAP programs written by whoever is available, they discover the same seven problems in roughly the same order.

Master data resolution. Supplier names on documents almost never match vendor master records exactly. Legal entity suffixes vary. Trading names differ from registered names. Subsidiaries invoice under parent branding. A single global supplier might have eleven vendor records across six company codes, and the correct one depends on the purchasing organization on the PO, not on anything printed on the invoice. Fuzzy string matching gets you to about seventy percent. The remaining thirty percent requires reasoning across bank details, tax IDs, remit-to addresses, and historical posting patterns.

Reference document reconciliation. The invoice says PO 4500098231. SAP has that PO. Good. Now check whether the goods receipt exists, whether the received quantity covers the invoiced quantity, whether the price on the PO matches the price on the invoice within tolerance, and whether a previous invoice already consumed part of that receipt. Every one of those checks requires a live read against SAP tables, and the answer changes minute to minute as the warehouse posts receipts.

Tax determination. Extracting the tax amount is trivial. Deriving the tax code that SAP will accept is not. It depends on the ship-from country, the ship-to country, the material or service type, the supplier tax registration status, reverse charge rules, and the company code tax configuration. A single European supplier invoicing a US entity for services triggers entirely different logic than the same supplier invoicing a German entity for goods.

Account assignment. Non-PO invoices need GL accounts. They also need cost centers, internal orders, WBS elements, or profit centers depending on what was purchased and who bought it. This information usually is not on the document at all. It lives in coding rules, historical patterns, requester identity, and approval hierarchies.

Posting mechanics. SAP offers several routes in, and they behave differently. BAPI_INCOMINGINVOICE_CREATE for logistics invoice verification. BAPI_ACC_DOCUMENT_POST for direct FI postings. OData services in S/4HANA with different field sets and different validation behavior. IDoc INVOIC02 for high-volume batch. Choosing wrong means rebuilding integration work six months in.

Error handling. SAP returns messages, not exceptions. A posting attempt comes back with a message table containing warnings, information messages, and errors mixed together. Message E 06 048 means something specific and actionable. Message W 06 205 usually means proceed. Interpreting that table, deciding whether to retry, whether to route to a human, or whether to reduce the posting to a parked document, is domain logic that no generic middleware ships with.

Audit traceability. Auditors want to open a posted document in SAP and trace back to the original PDF, see who touched what, see what the AI extracted versus what a human corrected, and see the confidence score at the moment of posting. That linkage has to be created at posting time and stored somewhere durable, attached to the SAP document number that only exists after the posting succeeds.

None of these seven problems are extraction problems. All seven of them are between you and a posted document. And a CSV export hands you all seven at once, on day one, with no tooling.

Why the integration team quote arrives late and large

Here is the pattern that repeats across almost every extraction-only deployment.

The IDP tool is selected by finance or shared services, often through a procurement process that never involved the SAP basis or ABAP team. The business case is built on extraction accuracy and clerk hours saved. The pilot goes well because pilots read documents and produce output files, and the tool is genuinely good at that.

Then integration scoping starts. The SAP team looks at the CSV specification and asks for the field mapping to vendor master, the tax determination logic, the error handling requirements, the reprocessing design, and the archive linkage approach. None of that exists yet, because the IDP vendor considers it out of scope. Their documentation says "export to your ERP" as though that were a single step.

Someone estimates the integration. The estimate is frequently larger than the software license. It is almost always longer than the timeline the business committed to. And it produces a custom-built artifact that one systems integrator understands, that breaks on the next S/4HANA upgrade, and that nobody wants to own.

The frustrating part is that this work is not novel. Every organization implementing an extraction-only tool builds essentially the same bridge, badly, independently, at full cost, and then maintains it forever.

What crossing the last mile actually requires

Artificio approaches this differently because AP Studio was built as an SAP-native processing platform first and a document extraction engine second. The extraction is necessary but it is not the product. The product is a document arriving as a posted, referenced, audit-linked object inside SAP without a human touching it.

That requires four things extraction-only tools structurally cannot provide.

A live, bidirectional SAP connection rather than a file drop. Artificio reads SAP during processing, not after it. When an invoice arrives, the platform pulls the vendor master candidates, the open PO lines, the goods receipt status, the tax configuration, and the payment terms while the document is still being interpreted. Extraction and validation happen against live ERP truth, not against a static ruleset. That single architectural difference eliminates most of the exception volume, because the system knows before it decides whether a decision will post cleanly.

The connection runs through RFC and BAPI calls for ECC landscapes and through OData services for S/4HANA, including private cloud and RISE deployments. The routing decision is made per operation rather than per project, so a single deployment can read master data through one channel and post through another where that produces better behavior.

Resolution logic that reasons rather than maps. Matching "Acme Industrial Supply Co" on a PDF to vendor 0001004432 is not a lookup table problem. Artificio scores candidates across name similarity, tax registration number, bank account on file, remit-to address history, and the purchasing organization implied by the referenced PO. When the score is decisive, it resolves silently. When two candidates are genuinely ambiguous, it escalates with both options and the evidence for each, so a human decision takes eight seconds rather than eight minutes of SAP navigation.

The same reasoning applies to PO line matching, where supplier line descriptions rarely resemble material master descriptions, and quantities may need conversion between the supplier unit of measure and the SAP base unit.

Posting with real error interpretation. Artificio posts through the appropriate BAPI or OData service, captures the full return message table, and interprets it. Known error patterns map to known remediations. Tolerance exceedances route to the configured approver rather than failing. Missing goods receipts trigger a hold-and-retry cycle instead of a permanent exception. Genuinely unresolvable postings become parked documents in SAP so that the AP team works inside their own system rather than inside a vendor portal.

Every attempt is idempotent and logged, so a retry never produces a duplicate posting, which is the failure mode that quietly destroys trust in automated AP faster than any accuracy problem.

Audit linkage created at posting time. When the posting succeeds, SAP returns a document number. Artificio writes the original document, the extraction output, the human corrections, the confidence scores, the decision path, and the timestamp against that number and attaches the source file through ArchiveLink or the configured DMS. An auditor opening the FI document three years later sees the PDF, the trail, and the reasoning. No reconciliation exercise across two systems required.

The exception path is the product

There is a counterintuitive truth in enterprise document automation. The value of a platform is determined almost entirely by what happens to the documents that do not process cleanly.

Extraction-only tools have a single exception path. Low confidence, send to human. That is the whole design. It works because their responsibility ends at the export file, so any document that produces an export file is a success regardless of what happens downstream.

Once a platform takes responsibility for posting, the exception taxonomy expands enormously, and each type needs different handling.

An invoice referencing a PO with no goods receipt yet is not an error. It is a timing issue. The correct behavior is to hold it and retry against SAP on a schedule, because the warehouse will post the receipt within a day or two, and the invoice will then process automatically with zero human involvement. Treating that as an exception generates thousands of pointless queue items per year.

A price variance inside tolerance should post. A price variance outside tolerance should route to the buyer, not to AP, because AP cannot resolve it. A quantity variance where the invoice exceeds receipt should hold. A quantity variance where the invoice is under receipt should post as a partial.

A duplicate invoice number from the same vendor should block. A duplicate invoice number from the same vendor where the previous document was cancelled should proceed. A near-duplicate with a different amount should escalate with both documents displayed side by side.

An invoice from an unknown vendor should not fail. It should route through the one-time vendor path or trigger vendor creation workflow, depending on configuration.

Each of these behaviors requires knowing the SAP state, not just the document content. And each of them, correctly handled, converts what would have been a manual touch into a straight-through post. The straight-through rate on a well-configured Artificio deployment is not driven by better OCR. It is driven by having thirty distinct exception behaviors instead of one.

Where the difference shows up in numbers

An extraction-only tool that reaches 96 percent field accuracy and hands you a CSV typically produces a straight-through rate of zero, because nothing is going through to anywhere. What it produces is a reduction in keying time, roughly forty to sixty percent per document, offset by an integration project that consumes the first year of savings.

The realistic comparison looks like this. On a 60,000 invoice per year AP operation, an extraction tool plus a custom bridge might land at seventy percent of documents posting without a human touch after eighteen months of tuning, with a maintained integration layer that requires attention at every SAP patch cycle and a dedicated resource who understands it.

The same volume on an SAP-native platform typically reaches eighty-five to ninety-two percent straight-through within the first quarter, because the exception behaviors ship as configuration rather than as code, and because reading SAP during processing prevents most exceptions from being created in the first place. The remaining eight to fifteen percent lands in a review queue where the reviewer sees the document, the SAP state, and the recommended action together, which is a two-minute task rather than a fifteen-minute investigation across three screens.

The number that matters most, though, is not the automation rate. It is how many people need to understand the integration. A custom bridge is understood by one or two people, and the organization becomes quietly dependent on them. Configuration-driven SAP posting is understood by whoever configured it and readable by whoever comes next.

The same gap exists everywhere, not just AP

Supplier invoices are the clearest example because the volume is highest and the SAP posting requirements are strictest. The pattern repeats across every document type that touches an ERP.

Sales orders arriving as PDF purchase orders from customers need customer master resolution, material determination against customer part numbers, pricing condition validation, credit check awareness, and creation through the sales order BAPI or OData service. Extracting the customer PO is fifteen percent of the work.

Goods receipts against advance shipping notices need delivery matching, batch and serial number handling, storage location determination, and quality inspection lot triggering. Reading the packing list is the easy part.

Quality certificates and certificates of analysis need to attach to the right inspection lot, populate the right characteristic results, and drive the usage decision. Extracting values from a COA does nothing on its own.

Maintenance work orders, project milestone documents, customs declarations, employee onboarding paperwork, remittance advices, supplier statements. Every one of them has an extraction layer that generic tools handle adequately and a posting layer that they do not touch at all.

That posting layer is where the operating cost actually lives. It is where compliance risk lives. And it is where the difference between a document AI vendor and an enterprise automation platform becomes visible.

What to ask before you sign

If you are evaluating document automation for an SAP landscape, a short set of questions will separate extraction vendors from platforms that finish the job.

Ask what the system does the moment after extraction is complete and validated. If the answer involves a file, a queue, or an endpoint your team consumes, you are buying half a solution and quoting the other half later.

Ask whether the platform reads SAP during processing or only writes after it. Read-during is the architectural marker that separates the two categories.

Ask what happens when a posting fails. Specifically, ask to see the SAP return message table handling. If the demo cannot show you a real BAPI error being interpreted and routed, that logic does not exist.

Ask how a posted document links back to the source PDF, and confirm that link is created inside SAP rather than in a vendor database.

Ask what percentage of exceptions are resolved without leaving SAP.

Ask whether the exception behaviors are configuration or custom development, and ask what happens to them during an S/4HANA upgrade.

The answers will tell you very quickly whether you are looking at a tool that reads documents or a platform that finishes work.

Finishing the job

Extraction has become a commodity. Multiple vendors, including several very good ones, can pull structured data off a supplier invoice with accuracy that would have seemed impossible five years ago. Competing on that number no longer separates anyone.

What still separates platforms is whether the structured data becomes a business fact inside the system of record. That transition, from validated extraction to posted SAP document with a full audit trail, involves master data reasoning, live reference reconciliation, tax and account determination, posting mechanics, error interpretation, and archive linkage. It is genuinely hard, it is specific to SAP, and it is invisible in a demo that ends with a JSON payload.

Artificio built AP Studio around that transition because the transition is the work. The extraction engine exists to serve it. Everything the platform does after a document is read is oriented toward one outcome, which is a document number in SAP that nobody had to type.

If your current tool stops at the export, the last mile is still on your roadmap. It is worth finding out what it costs before it becomes a line item.

To see how Artificio posts directly into your SAP landscape, reach the team at support@artificio.ai or visit artificio.ai.