The Last Mile — Why 95% Recognition Accuracy Isn't Enough

Consider the economics. A company processes 10,000 invoices per month. At 80% straight-through processing, 2,000 invoices require manual intervention. Each manual touch takes 3-5 minutes of a trained employee's time. That is 100-170 hours of skilled labor every month — just to handle the exceptions. The automation project was supposed to eliminate that work, not redistribute it.

The root cause is what we call the "80% trap." Reaching 80% recognition accuracy is straightforward with modern OCR and machine learning. Pre-trained models handle standard layouts, clean scans, and well-structured documents without issue. But the remaining 20% is where real business documents live: faded faxes, handwritten annotations, invoices with non-standard line item tables, multi-page contracts where the relevant fields appear on page seven. These are the documents your employees spend the most time on manually — and they are exactly the ones that most IDP solutions fail on.

The cost of exceptions compounds quickly. Every document that falls out of automated processing requires a human to open it, read it, find the relevant fields, type them into the target system, and verify the result. This is more expensive per document than the original manual process because now the employee also has to check what the system already extracted — and decide whether to trust it or start over. Partial automation can actually be worse than no automation if the exception rate is too high.

IDP projects plateau because most vendors treat the last mile as someone else's problem. The pitch is "95% accuracy," but that number was measured on a curated test set. In production, with your actual documents, the number is often 70-85%. And improving from 85% to 95% requires fundamentally different techniques than reaching 85% in the first place. It requires confidence scoring, human-in-the-loop workflows, visual grounding, and continuous learning from corrections. It requires solving the last mile.

A confidence score is the model's own estimate of how likely a given extraction is correct. When the system extracts an invoice number and reports 98% confidence, it means the model has high certainty. When it reports 62% confidence on a date field, something is ambiguous — perhaps the scan quality is poor, the format is unusual, or two candidate values competed. Confidence scores are the bridge between full automation and human review. Without them, every document is either trusted blindly or reviewed manually. With them, you can route precisely.

Threshold setting is where confidence scores become actionable. A typical configuration uses two thresholds: an auto-accept threshold (e.g., 95%) above which extractions are processed without review, and a reject threshold (e.g., 40%) below which the system flags the field for manual entry. Everything between these thresholds goes to a human reviewer who sees the extracted value alongside the source document and confirms or corrects with a single click. The thresholds are tunable per field type and per document class — a supplier name might tolerate a lower threshold than a bank account number.

The distinction between field-level and document-level confidence matters. A document might have 15 extracted fields, 14 of which score above 95%. If you reject the entire document because one field scored 70%, you waste the work on the other 14 fields. Field-level confidence routing sends only the uncertain fields to review, while the rest flow through automatically. This is the difference between reviewing 2,000 documents per month and reviewing 300 individual fields. The time savings are enormous.

In practice, confidence calibration is critical. A confidence score is only useful if it actually reflects the probability of being correct. A model that reports 95% confidence but is wrong 20% of the time is worse than useless — it creates false trust. feld.ai calibrates confidence scores against actual correction rates, so a 95% confidence really means 95% accuracy. This calibration improves continuously as the system processes more of your documents and receives more corrections.

The quality of the human-in-the-loop interface determines whether your validation staff processes 20 documents per hour or 200. A poor validation interface shows a list of fields next to a document viewer, forcing the reviewer to scroll back and forth, mentally mapping each field to its source location. A good interface highlights the relevant region in the document when a field is selected, pre-fills the extracted value, and lets the reviewer confirm with a single keystroke or correct by typing over. The difference in throughput is a factor of ten.

One-click correction is the design principle. When the system extracts "2024-13-01" as a date (an obvious month/day swap), the reviewer should not have to clear the field, retype the value, navigate to the next field, and click save. Instead, the interface shows the extracted value with the source region highlighted, the reviewer clicks the correct value in the document or types the correction directly, and the system advances to the next uncertain field. For batch review scenarios, the interface groups similar corrections — all date format issues, all supplier name mismatches — so the reviewer builds pattern recognition and speed.

The correction feedback loop is what separates a static system from one that improves. Every correction a reviewer makes is not just fixing a single extraction — it is a training signal. When an operator corrects a supplier name from "Muller GmbH" to "Mueller GmbH," the system learns this mapping for all future documents from the same supplier. When a date format correction occurs repeatedly for a specific document type, the model adjusts its parsing rules. Over weeks and months, the number of fields requiring review decreases measurably. Your data trains only your model — corrections from your team improve your recognition rates, not those of other customers. This is tenant-isolated learning, and it is fundamental to the feld.ai architecture.

The workflow also matters beyond the individual correction. Validation tasks can be assigned to specific team members based on document type or expertise. Escalation paths route difficult cases to senior staff. Audit trails record who validated what and when — critical for compliance in regulated industries. The goal is not to eliminate humans from the process but to make their involvement as efficient and valuable as possible, so they focus on genuine edge cases rather than routine confirmation.

Visual grounding means that every extracted value is linked to its exact location in the source document. When the system extracts an invoice total of EUR 4,231.50, it also records that this value was found on page 2, in the bottom-right table cell, at specific pixel coordinates. This is fundamentally different from black-box extraction, where a model outputs a value but cannot explain where it came from. For auditors, compliance officers, and anyone who needs to verify results, visual grounding is not a nice-to-have — it is a requirement.

The difference is tangible in daily operations. Without visual grounding, a reviewer who questions an extracted value has to manually search the document to verify it. On a 30-page contract, finding the specific clause that contains the termination date can take several minutes. With visual grounding, the reviewer clicks the field and the system scrolls to the exact location, highlights the source text, and shows the extraction in context. Verification takes seconds instead of minutes. Multiply this by hundreds of documents per day, and visual grounding saves hours of review time.

feld.ai implements visual grounding at every level of the extraction pipeline. OCR results carry bounding boxes. Classification decisions reference the regions that triggered the document type assignment. Field extractions include source coordinates that map back to the original document rendering. This traceability chain is preserved through the entire processing pipeline, from ingestion to the correction UX to the final API output. When you export extracted data to your ERP or DMS, the source coordinates travel with it — so downstream systems can also provide "show me where this came from" functionality.

The path from 80% to 100% straight-through processing is not a single leap — it is a structured progression through distinct phases. The first phase, reaching 80-85%, is about core extraction capability: good OCR, reliable field detection, standard layout support. Most IDP vendors deliver this out of the box. The second phase, reaching 90-95%, requires domain adaptation: the system learns your specific document types, supplier formats, and field conventions. This is where confidence-based routing, human-in-the-loop correction, and initial model tuning come in. feld.ai customers typically reach this phase within 2-4 weeks of production use.

The third phase, pushing from 95% to 99%+, is where the last mile methodology proves itself. At this level, every remaining exception is a genuine edge case — a new supplier format the system has never seen, a document with unusual structure, or a scan so poor that even a human struggles. Handling these requires the combination of visual grounding (to understand why the extraction failed), efficient correction UX (to fix it quickly), and continuous learning (to ensure the same failure does not recur). Each correction eliminates a class of future errors, not just a single instance.

The monitoring dashboard is the control center for this progression. It shows real-time recognition rates by document type, confidence score distributions, exception volumes and categories, and trends over time. When a new supplier starts sending documents in a format the system has not seen before, the dashboard surfaces it immediately. When correction rates for a specific field type increase, you see it before it becomes a problem. The dashboard turns the last mile from a vague aspiration into a measurable, manageable process with clear KPIs and weekly improvement targets.

Dark processing — the idea that documents should be processed entirely without human involvement — is the stated goal of many IDP vendors, particularly the large platforms from SAP, Microsoft, and the hyperscalers. The pitch sounds compelling: upload your documents, the AI handles everything, no human touches needed. In practice, this approach fails for a predictable reason. Dark processing assumes that the model is already perfect for your documents. It is not. No model is. And without a mechanism to identify and correct errors, those errors flow silently into your ERP, your accounting, and your business decisions. The cost of undetected errors in financial documents — wrong amounts, mismatched suppliers, incorrect tax rates — far exceeds the cost of a well-designed review process.

The fundamental problem with dark processing is that it eliminates the feedback loop. If no human ever sees the extraction results, no one catches mistakes, and the model never learns from them. The system stays at whatever accuracy it started with — or degrades as document formats evolve and new suppliers appear. SAP Document Information Extraction and Microsoft Azure Form Recognizer promise dark processing, but their enterprise customers quietly build manual review workflows around them because the error rates in production are not acceptable for financial and legal documents.

The right approach is to start with human-in-the-loop and work toward progressively less human involvement. Begin with 100% review, use confidence scores to identify which fields and document types are reliable enough for auto-acceptance, and gradually expand the auto-acceptance zone as the model improves. This is not dark processing — it is evidence-based automation. You automate what is proven to work, and you keep humans in the loop for what is not yet reliable. The result is a system that reaches 99%+ straight-through processing within months, with auditable quality at every step of the journey. Every correction along the way improves only your model, trained exclusively on your data, in your isolated tenant.