Use case: invoice exception handling
In accounts payable, procedures have to be followed exactly, and the invoices that do not match their purchase order take most of the time. With Floxar, the exception procedure is a flow: an AI agent does the comparison and applies the policy, a rules service decides what is within tolerance, and a specialist decides the rest, with every item's handling recorded.
The parts involved
| Layer | In this case |
|---|---|
| Trigger | An invoice that fails automatic matching in your finance system |
| Agent | An agent that investigates the exception |
| Process (Floxar) | The exception flow: compare, classify, apply tolerance, approve or escalate, close |
| Systems | The finance system with the invoice, purchase order and goods receipt |
| Rules | A tolerance check that returns within or outside tolerance, run as code, not judged by the model |
| People | The accounts payable specialist |
How a run goes
- The exception starts a trail. Your agent or integration starts the exception flow when an invoice fails matching, recording the invoice on the first step.
- The agent compares the documents. It retrieves the invoice, the purchase order and the receipt, and records each difference it finds: price, quantity, missing receipt.
- The rules decide tolerance. The next step tells the agent to run the tolerance check and record its result. Within tolerance, the flow takes the approval path; outside it, the escalation path. The model never decides the amount on its own.
- Within tolerance: approve. The agent carries out the approval steps and closes the run with the reason "approved within tolerance".
- Outside tolerance: the specialist decides. The agent writes a note with the differences it found and transfers the trail to accounts payable. The specialist reviews, decides, and closes the run with a closing reason.
What you get from the record
Every item has a trail showing how it was handled: the differences found, the tolerance result, the path taken and who decided. That is the evidence a control needs. Across many exceptions, the closing reasons and analytics show recurring causes, such as one supplier's pricing or one site's missing receipts, so the cause can be fixed rather than the symptom handled again and again.
For keeping exact decisions out of the model, see Designing AI workloads with Floxar.
Last reviewed: 2026-10-06