The context problem: why exception resolution resists automation
The context problem is the reason invoice exception resolution resists automation: closing an exception means answering a question that usually isn't sitting in any single system, what the supplier actually agreed to, why a shipment split into two deliveries, whether this same mismatch already happened last quarter. Rule-based automation catches that something doesn't match; explaining why is a separate task, and why is what resolution actually requires.
The missing fact usually lives outside the ERP
The ERP holds the purchase order and the invoice. It rarely holds the email where a buyer approved a rush surcharge, the PDF of a signed contract amendment, the supplier portal note explaining a backorder, or the MES log showing a production delay that pushed a delivery date. Resolving an exception means pulling that context from wherever it actually sits, and most AP systems were never built to look outside their own database, which is a large part of why invoice exceptions happen in the first place.
Rules can catch a mismatch but not explain it
A tolerance rule can say a $312 invoice against a $300 PO is 4% over threshold. It cannot say whether that's a legitimate freight surcharge, a pricing error, or a duplicate line item, because the answer to that question lives in a document the rule was never given access to. AP departments carry an average invoice exception rate of 18.4 percent, according to Ardent Partners' 2026 benchmark research. Adding more matching rules on top of that doesn't shrink it, because more rules still can't answer a question the rule was never given the context to ask.
RPA breaks the moment the screen changes
Robotic process automation was built to repeat a fixed sequence of clicks inside one system. It has no way to reason across a contract PDF, a supplier email, and an ERP screen at the same time, and it breaks the moment a field moves or a portal updates its layout. That's why RPA can automate the ninety invoices that match cleanly and still leave the ten that need a real explanation exactly where they were.
An agent that reads across systems closes the gap
Closing the context problem means building something that can look at the ERP, the MES, the supplier portal, the inbox, and the spreadsheet a regional team still uses, and reason across all of them the way an analyst would when chasing down an answer. That requires no data migration and no forcing every system into one format first; the agent works with the data where it already lives. This is also where exception routing and autonomous exception resolution meet: an agent that can find the missing fact usually doesn't need to route the exception to a person at all.
Fragment's agents are built specifically to reason across a company's existing systems, no migration, no data standardization, nothing ripped out or replaced. See the workflows in detail or book a demo to see one resolve a real exception.