Almost everything written about e-invoicing is written from the issuing side, which is odd, because the receiving side is where the obligation usually arrives first and where the process change is larger.
Larger, and of a different kind. On the issuing side a mandate adds requirements: new fields, a new channel, a validation gate. On the receiving side it removes work. Capture stops. Keying stops. Much of the validation that a person was performing by eye is done before the document arrives.
That sounds unambiguously good and it contains a trap, which is the subject of this piece.
What actually changes
| Step | Before | After | What has to happen to the control |
|---|---|---|---|
| Receipt | Email, post, portal, several inboxes | A single channel, with a delivery record | Monitoring moves from an inbox to a queue somebody owns |
| Capture | Scanning and character recognition, with a correction pass | Nothing to capture; the data is the document | The correction pass was catching more than typos; that check is now unowned |
| Keying and coding | Manual entry, with a person reading the document | Fields arrive populated | The coding judgement has to become configuration or stay a manual step |
| Format and completeness check | Implicit, done by eye | Explicit, done by validation before arrival | Genuinely replaced, and better than it was |
| Supplier identification | Matching a name to an account | Identifier-based, unambiguous | Improved, provided the master data supports it |
| Matching to order and receipt | Semi-automatic, with manual fallback | Automatic where identifiers are present | The fallback still exists, and is now the whole job |
| Approval | Workflow, after capture | Workflow, sooner | Unchanged, but the timetable is exposed |
| Posting | After a person has seen it | Potentially without anyone seeing it | This is where the removed control has to be reinstated |
Read the last row carefully, because it is the honest summary and it is not what business cases say. The volume of work falls. The difficulty of the remaining work rises, because everything easy has been automated and what is left is the cases that needed a decision.
The control that disappears with the keying
Here is the trap, stated plainly.
When a person keyed an invoice, they looked at it. Not as a control — nobody wrote "review the document for anything odd" in a process map — but they saw the supplier, the amount, the description and the reference, and a proportion of the time something did not look right and they asked. That was a control. It was undocumented, unmeasured and genuinely effective, and it was a by-product of a task that has now been deleted.
Delete the task and the by-product goes with it. An invoice that arrives structured, validates, matches within tolerance and posts automatically has been seen by nobody. If it is fraudulent, or duplicated, or from a supplier whose bank details changed last week, nothing in the new process notices.
The answer is not to reintroduce manual review. It is to decide, explicitly, which checks the person was performing and to implement those as controls with owners: duplicate detection, bank detail change monitoring, tolerance rules that are set deliberately rather than inherited, and sampling of documents that posted without intervention. Each of those is straightforward. The failure is not implementing them, it is not realising they were needed, because the thing being removed was never on the process map.
This is also why the audit trail linking invoice to supply has to be re-described after an automation project. The trail still exists, and it now runs through different steps than the description written three years ago.
Two channels for a long time
A practical point that projects underestimate.
A mandate phases in. During the phase-in, some suppliers send structured documents and others send PDFs, and the ones still sending PDFs include the small suppliers who are hardest to move and the foreign suppliers the mandate does not catch. So the function runs two processes in parallel — for years, not months.
That means the capture capability cannot be decommissioned on the go-live date, and it means the team needs to be able to do both. It also means the metrics get confusing: touchless rates computed across both channels tell you about the supplier mix rather than about the process, which is a good way to declare success while the manual half quietly grows.
The segmentation that determines how long this lasts is a supplier population question, and doing it early is the difference between a plan and a hope. It is treated in onboarding suppliers at scale.
Exceptions are the job now
Once capture and keying are gone, what a team does all day is exceptions: documents that did not match, documents rejected for a reason that turns out to be your data rather than theirs, documents that arrived twice, documents that arrived for something nobody ordered.
That is a different skill set from the one the function was hired for, and it is a different capacity model. Exception volume is not proportional to invoice volume in any stable way — it spikes when a supplier changes system, when a profile version changes, when a new entity goes live. A team sized to the average is a team that fails during exactly the weeks that matter.
Designing that properly, including the ageing report that shows whether anything is being worked at all, is the week three problem, and it is the single most common reason a technically successful implementation becomes an operational failure.
When an outbound document is wrong you control the fix. When an inbound one is wrong you do not: the supplier has to issue a correction, on their timetable, through the same channel. That makes the correction mechanisms and what each one asserts an accounts payable concern rather than a receivables one, and it makes disputes slower rather than faster — because there is no longer a version of the document you can quietly amend at your end.
Approval was never the bottleneck
One genuinely useful side effect. When capture takes four days, an approval cycle of six days looks like the problem. When capture takes zero days, it becomes visible that approval was six days of waiting for a person to look at a queue.
Structured invoicing does not fix that and it does expose it, which is an opportunity most projects fail to take because the scope was written as a compliance project. The invoice now arrives on the day it is issued. Whether anything happens to it that week is a question about delegation thresholds and workload, and it is answerable independently of any mandate.
What to design before go-live
Four things, none of which are technology.
Which controls the deleted steps were performing, and where each one now lives. What the tolerance rules are, set deliberately rather than carried over from a system that had different information available. Who owns the exception queue, with a capacity assumption written down and an ageing report that somebody reads. And what happens to documents that are not invoices in the legal sense but still arrive and still need paying, because the mandate does not catch them and the process has to.
The last one is the recurring surprise. A mandate defines invoices. Accounts payable receives everything, and the design that only handles what the mandate defines leaves a category of documents with no route at all — discovered, invariably, on the first day of live running by somebody who needs to pay one. Establishing that inventory is part of the readiness assessment, and it is cheap there and expensive anywhere else.
