Every implementation has a moment where it stops being a project and becomes an operation. It is rarely marked, it is usually about three weeks after go-live, and it is where most technically successful e-invoicing programmes quietly fail.
The mechanism is not mysterious. During the project, an exception is picked up within the hour by somebody who built the thing, understands the reason codes, and has no other work. After the project, the same exception lands in a queue belonging to a team that has a month-end, a holiday rota and a headcount set before any of this existed.
Nothing technical changed. The capacity did, and capacity is the variable nobody modelled.
The classes, and why they need separating
Lumping everything into "errors" is what makes the queue unworkable. There are four kinds and they have different owners, different clocks and different consequences.
| Class | What happened | How you find out | Who resolves it | Cost of letting it age |
|---|---|---|---|---|
| Validation rejection | The document failed a gate before reaching the receiver | An asynchronous rejection message | Whoever owns the underlying data, usually not IT | The invoice was never issued; the correction window may close |
| Delivery failure | The document was valid but could not be delivered | A failure notification, or nothing at all | Operations, with the counterparty | Cash flow, and a dispute about whether it was ever sent |
| Accepted but unmatched | The document arrived and does not correspond to an order or receipt | A queue in accounts payable | The buyer's team, with the supplier | Payment delay, supplier relationship, and accrual accuracy |
| Receiver-rule rejection | The document was fine and the buyer's own rule refused it | A rejection message written for their staff | Receivables, by asking the customer | Repeats on every document until the rule is understood |
The middle column is worth dwelling on. None of these arrive as an interruption. They arrive as messages into a channel, and a channel nobody has been told to watch is functionally silent. The commonest operational failure in this field is not mishandling an exception; it is never seeing it.
Silence is a state, and it is the dangerous one
A document has three possible outcomes: accepted, rejected, and nothing heard.
Systems handle the first two. The third is the one that costs money, because a business's own record says "sent" and there is no negative event to trigger anything. Nobody investigates the absence of a message.
That is why the reconciliation that matters operationally is not financial. It is a count: documents submitted against outcomes received. Anything submitted with no outcome after a defined period is an incident, and finding it requires deliberately looking for a gap rather than reacting to an error.
The general failure taxonomy — what can go wrong between "we sent it" and "they have it", and who carries the risk in each case — is worked through in when delivery fails. The operational point here is narrower: the state you have to engineer for is the one where nothing happened.
Two clocks
Exceptions are urgent for reasons that have nothing to do with how the queue is prioritised.
The first clock is the correction window. Where a regime allows a rejected document to be corrected and resubmitted while keeping its original date, that window is typically short. Miss it and the document takes a new date, which moves the tax into another period and turns an operational slip into a reporting difference somebody has to explain.
The second is the period boundary. A rejection in the middle of a period is a task. The same rejection three days before the close is a decision about which period the revenue lands in.
Neither clock is visible in a queue sorted by invoice value, which is how queues are sorted by default. Sorting by remaining window is a small change and it is the one that reduces the harm most.
The most common arrangement is matching runs automatically, exceptions accumulate, and somebody works them when the day allows. That is a control whose reliability is a function of workload: it holds in a quiet quarter and fails in a busy one, and the failure is invisible because nothing records how long items waited. It is also, as a matter of evidence, a control that cannot be demonstrated — which matters for the audit trail as much as for cash.
Sizing it honestly
Nobody can predict an exception rate for a business that has never issued a structured invoice. What can be done is to state the assumption openly and design to measure it.
Take expected document volume, apply an assumed rejection rate, apply an assumed handling time, and produce a weekly hours figure. Every input is a guess. The output is still useful, because it converts an abstract concern into a number somebody has to either resource or consciously accept — and because when the real rate arrives in week two, the model updates in a minute rather than being rebuilt.
What the exercise usually reveals is that the honest figure is an uncomfortable fraction of somebody's job rather than a rounding error. That figure belongs in the recurring column of the cost model, where it is the line most often left out entirely.
Preventing rather than processing
Most exceptions are not novel. They repeat, because their cause is a record or a configuration that is wrong in a stable way.
That makes the useful metric not throughput but the distribution: which reason codes account for most of the volume. In practice a small number of causes will dominate, and each of them is fixable upstream — a customer record, a mapping, a missing reference on an order type.
Working the queue treats symptoms and the queue refills. Fixing the top three causes empties it, and it is the only way the operating cost ever falls. This is also where most of the effort really belongs: the exceptions that repeat are almost always master data or a gap in what was tested before go-live, and both of those have owners who can eliminate them permanently.
What it needs to be a process
Four things, and they fit on a page.
A named owner, in the operating function, with authority to change the records that cause the exceptions rather than only to reprocess documents.
An ageing report that somebody reads weekly, showing the oldest item rather than the count. Volume tells you how busy it was; ageing tells you whether it is working.
A defined escalation with a threshold and a person, so that an exception nobody can resolve does not simply remain in the queue as a permanent resident.
And a monthly review of causes by reason code, feeding fixes upstream. Without that last one, the other three describe a well-run treadmill.
None of this is difficult and none of it is anybody's project deliverable, which is why it is normally designed in the middle of the first bad month by whoever is still answering their phone.
