An invoice exception is a signal that the available records do not yet support the normal path. The goods may be missing, the price may be wrong or an approval may be absent. Resolving the case requires enough evidence to determine the appropriate action.
AI can help assemble and interpret that evidence. The control design determines which actions the workflow may take, when it must stop and who can authorise the next step.
For finance, the useful objective is a resolved case with a defensible record. The route to that outcome should preserve the distinction between a plausible explanation and evidence that satisfies policy.
Keep the existing control logic explicit
Microsoft's AP documentation describes three-way matching across invoice, purchase order and receipt information, with discrepancies assessed against configured policies and tolerances. These checks provide a concrete foundation for exception handling. Microsoft Learn, invoice matching overview
Its worked process also shows how a configuration can require approval before posting invoices with discrepancies. That is a useful example of a control enforced through the transaction system. Microsoft Learn, matching against received quantity
An AI workflow should work within the organisation's agreed rules. An interpretation of a supplier email should not silently change a tolerance, create a receipt or confer approval authority.
Before implementation, identify the source of truth for each decision: receipt records for goods received, the approved order for agreed terms and the authorisation policy for who may accept a deviation. Where those sources conflict, define an escalation path.
Work through a partial delivery
Assume a purchase order covers 100 units at £20 each, excluding tax. The invoice is for £2,000, but the recorded receipt covers 80 units. The supplier says the remaining units were delivered the following morning.
The unmatched quantity represents £400. That number is easy to calculate. Establishing the correct treatment requires more information.
The workflow could retrieve the receipt history, find relevant delivery evidence and ask the receiving team to confirm whether the remaining goods arrived. It should preserve the original invoice and records. If the policy permits partial processing, an authorised person or an explicitly permitted rule can determine the treatment. The workflow should not create evidence of receipt from the supplier's assertion alone.
This example is fictional and simplified. It illustrates evidence handling, not an accounting treatment to apply irrespective of company policy or transaction terms.
The economic opportunity is often in reducing the time spent finding records and coordinating responses. Keeping the substantive approval with the right person can still allow a substantial share of the surrounding work to be automated.
Match each exception to a permitted action
| Exception | Useful automated preparation | Decision or control to preserve |
|---|---|---|
| Missing receipt | Gather order and delivery records; route a confirmation request | Receiving evidence must come from an authorised source |
| Price mismatch | Calculate the difference and assemble relevant agreed terms | Approval of an unagreed commercial change |
| Possible duplicate | Compare identifiers, amounts and transaction history | Prevent a second posting while ambiguity is resolved |
| Missing approval | Identify the required approver and attach the case evidence | Enforce authority limits and separation of responsibilities |
| Conflicting documents | Present the conflict and retain each source | Escalate rather than manufacture a single confident answer |
This is a recommended design framework. The precise actions need to be agreed for the client's system, policy and risk tolerance.
Treat document content as evidence, not instructions
Invoices and supplier emails are external inputs. Their text may be incomplete, misleading or deliberately crafted to influence an automated system. The workflow should extract relevant facts without allowing that content to redefine its permissions or operating policy.
NIST's Generative AI Profile identifies risks including confabulation and information security concerns. For an invoice workflow, the practical implication is to verify consequential claims against authorised records and constrain the actions available to the model. NIST, Generative AI Profile
A useful evidence packet shows the source record, relevant field or passage, time retrieved and any unresolved conflict. A fluent summary is helpful for the reviewer, but the underlying documents must remain available. Record the action approved and the transaction version to which it applied.
Design for retries and changed facts
Suppose a posting request reaches the ERP but the confirmation never returns. Repeating the request immediately may create another transaction. Recovery should first establish whether the original action completed, using a stable case or transaction identifier and the system's supported duplicate-prevention mechanisms.
The same discipline applies to delayed approvals. A case approved yesterday may have changed today because a credit note arrived or another colleague resolved it manually. Recheck material facts before executing the approved action. A changed amount or destination may require a new approval.
These controls should be demonstrated during testing. Include interruptions after each consequential step and verify that the process resumes without duplicating, skipping or concealing work.
Measure the safe outcome and the human burden
Report correct resolutions, incorrect actions, appropriate escalations and unnecessary escalations separately. A workflow that sends every case to a person may be safe but create little value. One that completes many cases while mishandling a small but material subset may fail the acceptance criteria.
Measure active handling time across the full case. For example, reducing 1,200 monthly exceptions from 12 to seven human minutes releases 100 hours a month. At an assumed £35 an hour, that represents £42,000 of annual capacity before automation costs. This is an illustrative calculation, not a forecast or a Curia result.
The proof should also assess aged cases and repeat causes. Faster handling is valuable; preventing the same mismatch from recurring may create additional improvement that should be measured in its own right.
What Curia should prove
Curia builds and tests the agreed workflow in the client's environment, with performance and controls agreed before launch. For exceptions, the acceptance exercise should demonstrate the evidence chain, permission boundaries, approval path and recovery behaviour alongside the economics.
That makes the service relevant where capable systems already exist but investigation and coordination still consume finance time. The opportunity is to redesign and operate that work while the team retains decisions and sign-off. The broader ERP controls guide sets out the questions to settle before granting access.
Bring Curia a representative set of invoice exceptions and the rules your team applies. We will assess which steps can be automated and what must be proven before launch. Assess invoice exception handling