The gap is the problem, not the people
In almost every operations audit I have done, the slowest part of the process is not the ERP, not the warehouse management system, not the field technician. It is the twelve seconds a person spends copying a number from one screen into another, multiplied by four hundred transactions a day, multiplied by the fact that one in every eighty keystrokes is wrong.
That is where throughput dies. Not in a dramatic failure. In a quiet, daily grind of re-keying that nobody has ever formally measured because it has always just been part of the job.
I want to be direct about what I mean by a handoff. Any moment where data leaves one system and a human being is the transport layer before it arrives in the next system is a handoff. PDF invoice to ERP line item. Supplier portal confirmation to internal spreadsheet. Field inspection report to maintenance work order. Each one is a bottleneck in waiting, and the wait always arrives eventually, usually at month end or during a peak season when you can least afford it.
What the re-keying pattern actually looks like in practice
In a distribution business I worked with, the accounts payable team was receiving somewhere in the range of three hundred invoices a day across email, a supplier portal, and a legacy EDI feed that only covered about a third of their vendor base. The other two thirds arrived as PDFs. Each PDF had to be opened, the line items read, and the values typed into the ERP. The team was good at it. They had shortcuts, they had muscle memory, they had informal checks. They were also spending roughly a third of their working day on pure transcription.
The problem was not that the team was slow. The problem was that transcription is not a skill that compounds. You do not get strategically better at typing numbers from PDFs. The work just accumulates.
I see the same pattern in manufacturing, where shift supervisors copy production counts from a floor terminal into a planning spreadsheet because the terminal cannot talk directly to the planning tool. I see it in field operations, where a technician fills out a paper or PDF inspection form and someone back at the office re-enters the findings into the asset management system. I see it in financial services, where loan officers pull data from a credit bureau report and manually populate an underwriting model. The surface details differ. The structural problem is identical.
Why the gap persists even when everyone knows it is there
Operations leaders are not naive. They know the gap exists. The reason it persists is usually one of three things.
First, the two systems at either end of the gap were never designed to talk to each other, and a formal integration project has been estimated, scoped, deprioritized, and re-estimated so many times that it has become organizational folklore.
Second, the volume of exceptions is high enough that a simple rule-based connector would fail constantly. Supplier invoices do not all look the same. Field reports have free-text fields. The data is messy enough that a brittle script feels worse than a human who can handle ambiguity.
Third, and this one is underappreciated, nobody owns the gap. The ERP is owned by finance. The portal is owned by procurement. The spreadsheet lives on someone's desktop. The gap between them is nobody's responsibility, so it becomes everybody's workaround.
All three of these are real constraints. None of them are permanent.
The pattern for closing each gap with checked, reversible automation
When I build an automation for a handoff, I follow a pattern that I have found works across sectors. It has four steps and none of them are optional.
- Extract and normalize. The agent reads the source, whether that is a PDF, a portal screen, a form submission, or an email, and produces a structured representation of what it found. This output is always human-readable and always logged. The agent does not write anything to the destination system yet.
- Check against known rules and flag exceptions. Before anything touches the ERP or the target system, the structured output is validated. Does the invoice total match the line items? Does the field code in the inspection report correspond to a valid asset ID? Is the quantity within a plausible range for this supplier? Anything that fails a check goes to a human review queue, not to the destination. This is the step most teams want to skip. Do not skip it.
- Write with a reversible transaction. When the data passes validation, the agent writes to the destination system in a way that can be undone. In practice this means staging records rather than posting them, or writing to a draft state that requires a single human confirmation before it commits. The confirmation step does not have to be slow. In a well-designed flow it takes a few seconds. But it exists, and it matters, because language models make mistakes and document quality varies and no automated system is infallible.
- Reconcile and surface drift. After the transaction commits, the agent compares what it wrote against what the source said and logs any discrepancy. Over time this log tells you where your documents are most ambiguous, which suppliers have the messiest invoice formats, which field technicians write notes that the extraction step struggles with. That is your continuous improvement signal.
This pattern removes the manual work from the routine case while keeping a human in the loop for the exception case and the final commit. It is not the fastest possible design. It is the one that holds up in production when document quality drops, when a supplier changes their invoice template, or when a field technician writes something unexpected in a free-text field.
What this looks like applied to a real sector pattern
In a manufacturing context I have seen this applied to the shift handover problem. A night shift supervisor fills out a production summary, typically a PDF or a structured form, that needs to land in the planning system before the day shift starts. The gap between the form and the planning system is usually bridged by whoever arrives first in the morning.
With the pattern above, an agent reads the completed form as soon as it is submitted, extracts production counts, downtime events, and quality flags, validates them against the expected ranges for that line and that shift, and stages a draft record in the planning system. The day shift supervisor sees the draft on arrival, reviews it in under a minute, and confirms. If anything looks wrong, they edit before confirming. The original form is always preserved and linked to the record.
The rough outcome in patterns I have seen is that the planning system is populated before the day shift starts rather than an hour or two into it, and the error rate on the records drops substantially because the validation step catches transposition errors that a tired human at six in the morning would miss. I will not give you a precise percentage because I do not think precise percentages from anonymous engagements are useful. The directional result is consistent and the mechanism is straightforward.
In a financial services context I have seen the same pattern applied to credit memo processing, where the agent reads incoming credit notes from suppliers, matches them to open purchase orders, flags any that do not match within a tolerance, and stages the matched ones for a single-click approval. The work that remains for the AP team is judgment work, not transcription work.
The limits you should plan for before you start
I want to be honest about where this pattern struggles, because overselling automation is how you end up with a failed project and a team that does not trust the next one.
Document quality is the biggest variable. If your suppliers send clean, consistent PDFs with machine-readable text, extraction is reliable. If they send scanned images of handwritten forms, or PDFs that were generated by printing a web page and then scanning it, extraction quality drops and your exception queue grows. You need to measure this before you set expectations.
Exception volume is the second variable. If thirty percent of your invoices have some kind of mismatch, your human review queue is not a safety net, it is a second job. The automation only delivers speed if the exception rate is low enough that the review queue is genuinely light. Getting the exception rate down often requires working with your suppliers or field teams on document quality before you automate the handoff.
System access is the third variable. Writing to an ERP or an asset management system in a reversible, auditable way requires API access or a supported integration method. If the only way into your target system is a screen that a human clicks through, you are in a more complicated situation and the risk profile of the automation is higher.
None of these are reasons not to automate. They are reasons to scope the first deployment conservatively, prove the pattern on a high-volume low-exception document type, and expand from there.
The practical takeaway
Find the three handoffs in your operation where a person is the transport layer between two systems. Measure roughly how many transactions move through each one per day and what the error rate looks like when you check a sample. Rank them by volume times error rate times business impact if something goes wrong.
Start with the one at the top of that list. Build the extraction, the validation, the reversible write, and the reconciliation log. Run it in parallel with the manual process for long enough to trust it. Then remove the manual step.
Do not try to automate all three at once. The pattern is straightforward but the implementation details are specific to your documents, your systems, and your exception types. One gap closed properly is worth more than three gaps half-closed.
The goal is not a system that never needs a human. The goal is a system where humans spend their time on decisions that require judgment, not on moving numbers from one box to another.