Invoice exceptions happen because the information needed to pay an invoice is spread across systems and people that do not fully agree with each other. The invoice is the last document in a long chain, and by the time it arrives the order, the receipt, the contract, and the supplier's own records have often drifted apart. The exception is where that drift surfaces.
Most causes fall into three groups: differences in the data, gaps in timing, and knowledge that was never written down.
Most exceptions involve no error at all
An automated check passes only when the documents it compares tell the same story. They frequently do not, and usually for reasons that involve no error by anyone. The order was cut before a price changed. The receipt was posted a day late. The supplier describes an item differently than the buyer does. Each of these is normal, and each one breaks a match.
Master data breaks more matches than mistakes do
Suppliers and buyers describe the same things in different ways. One vendor bills by the case, the other by the unit. A site is "Houston Yard 4" in one system and "HOU-Y4-001" in another. A supplier exists under three slightly different names in the vendor master. None of these is wrong, but each one breaks an automated match until someone maps the two sides together. Poor master data is one of the largest single sources of exceptions, because every downstream check depends on it.
Documents arrive out of order, and the match punishes it
Invoices, orders, and receipts do not arrive in a tidy sequence. A supplier that invoices ahead of shipment trips the quantity check every time, even though nothing is wrong. Purchase orders get amended after the fact. Receipts get posted late. Prices get renegotiated mid-contract and the order is never updated. The invoice lands in the gap between when something changed and when the systems caught up.
The resolution playbook lives in people's heads
A large share of exceptions are resolved using knowledge that was never written down: which suppliers are allowed a little extra tolerance, which plant codes behave differently, which contact at a vendor actually answers email, which charges are normal for a given service. This often lives in the head of one experienced analyst. When that person is out or leaves, the exception rate climbs and no one is quite sure why.
The rate holds because the tools fix the wrong step
Companies have spent two decades and several waves of software on this problem, and exception rates have not moved much. The reason is that the causes sit outside the tools that were bought to fix them. Better matching software does not fix bad master data, late receipts, or knowledge that lives in people. Until the resolution step can use the same context a person uses, the rate holds roughly where it is. Seat-based licensing points the same direction: the software earns more when more people work the queue. The benchmarks page looks at where that rate typically sits.
Fragment resolves the exceptions these root causes create by reading the context across your systems in place, without ripping out or replacing your existing systems. See how it works or request a demo.