Research / Operations
How to Use AI to Surface Finance Exceptions
Use AI to investigate invoice mismatches, possible duplicate payments, and missing approvals, with fixed checks, source evidence, and clear review ownership.

Use fixed checks to identify known finance exceptions, then test AI on the work of gathering evidence and explaining the case. An accounts-payable team can use that approach to investigate invoice mismatches, find possible duplicates, and route missing approvals. Keep payment authority and resolution in the approved finance workflow, with a named person responsible for each open case.
Start with the exception queue
An invoice exception needs an investigation or decision before the team can continue through its normal process. The invoice may disagree with a purchase order, have no recorded receipt, resemble an earlier invoice, or lack the required approval. Map those conditions in your existing system before buying another detection tool.
Take a defined period of invoices and trace what happened after each exception appeared. Record its reason, assigned owner, time waiting, and outcome. Keep the population tied to a legal entity and invoice type so a shift in the mix doesn't masquerade as an improvement.
A August 2026 accounting discussion asks who handles failed three-way matches, how teams contact receiving or procurement, and what causes delays. It points to a practical question for this workflow: after an alert, what evidence and response let staff move the case forward? The comments aren't a measured benchmark of processing performance.
Distinguish the time spent detecting a case from the time spent resolving it. If your ERP already flags a missing receipt immediately, another alert doesn't record the receipt. The next intervention may be a better evidence packet and a request to the right receiving team.
Give each case a stable identifier and a current status. Let several signals attach to the same case rather than making staff resolve separate alerts for the same invoice. Keep the reason for closure so “resolved” means a documented decision, not merely a notification that somebody dismissed.
Choose fixed checks and model assistance by task
Fixed checks apply explicit rules to structured records. They fit calculations, configured tolerances, and required workflow states. AI may help interpret varied document text or summarise an investigation, but you need evidence that it reduces the work for your invoice population.
| Exception | Fixed check | AI assistance to test |
|---|---|---|
| A price mismatch. | Compare approved line values and configured tolerances using code or the ERP. | Locate a relevant amendment and draft an explanation with its source reference. |
| A quantity or receipt mismatch. | Compare invoiced quantities with the relevant ordered and recorded received quantities. | Find delivery correspondence and prepare a question for receiving to confirm. |
| A possible duplicate. | Check approved identifiers and payment history, retaining each document's original values. | Compare candidate documents and explain why they may concern the same obligation. |
| A missing approval. | Read required approval state and valid approver assignment from the authorised workflow. | Summarise the pending case and draft a follow-up for the assigned owner. |
The model's role in this table is a proposal to evaluate. Don't assume it can find every amendment or infer the correct invoice relationship. A missing document should produce a visible evidence gap. Let a reviewer inspect the underlying records before acting on the explanation.
Keep the approved arithmetic outside generated prose. Store amounts with their currencies and quantities with their units, and use the finance system's rounding rules. A fluent explanation of a difference doesn't establish that the subtraction or currency comparison is correct.
Read the existing configuration before recreating controls. Microsoft's Dynamics 365 Finance matching documentation describes invoice, purchase-order, and receipt comparisons against tolerances, including price and quantity checks. Those are existing product controls, and their behaviour depends on your configured matching policy. Your team needs to establish what its installed system already checks.
Investigate invoice mismatches with source records
For a mismatch, collect the invoice line, linked purchase-order line, and relevant receipt or service acceptance. Show their identifiers, values, and dates together. Check that the links refer to the same legal entity and obligation before treating a difference as an exception.
A missing receipt needs a different investigation from a wrong price. Ask receiving whether the goods arrived and whether staff recorded the receipt against the correct order. A delivery email can support that enquiry, but the email doesn't itself create the authorised receipt record.
For a price difference, inspect the approved purchase terms and any amendment. Keep the effective date visible. A supplier's email requesting a higher price doesn't prove that procurement accepted it. The application should state whether it found approved evidence or only a claim requiring confirmation.
Microsoft's May 2026 guidance on totals discrepancies describes reviewing the differences and resolving them through actions such as agreeing a price difference or obtaining a corrected invoice. It also notes that configuration can require approval before posting a discrepancy. Your resolution path should follow your organisation's actual policy and system settings.
Don't raise a tolerance simply to make the queue shorter. The finance control owner needs to approve policy changes and understand which cases they stop flagging. Measure alert quality separately from whether staff can clear a hold.
Show stale or incomplete evidence explicitly. If the connector read yesterday's receipt export, the case may miss today's update. Before closure, check the current source state through the permitted interface. Our guide to scoped AI access to legacy systems explains how to keep that lookup within the task's permissions.
Separate possible duplicates from confirmed duplicates
A repeated invoice reference is a detection signal that needs context. A monthly invoice can share an amount with the previous month. A credit and rebill can concern the same purchase without creating two valid liabilities. Decide what constitutes a duplicate obligation with the accounts-payable owner.
Start with your system's duplicate checks and inspect the cases they actually cover. Preserve the original supplier reference while creating any approved normalised comparison field. Removing punctuation or leading zeros can help find candidates, but it can also merge references that the supplier considers distinct.
Use several sources to investigate a candidate. Compare supplier identity, invoice type, currency, service period, and line details. Check cancellation and credit links alongside posting and payment state. An invoice register and a payment record answer different questions: whether you recorded an obligation and whether you settled it.
A model can draft a comparison of two differently formatted documents. Require it to show the fields that support the match and any fields that disagree. Label the result “possible duplicate” until the authorised reviewer establishes the relationship. A similarity score doesn't justify cancelling a legitimate invoice.
Keep supplier aliases and legal entities under control. If the same supplier appears under several records, investigate the master-data issue. Cross-entity comparisons may need a shared-services reviewer with explicit access. Don't give every local accounts-payable user access to all portfolio-company records to improve candidate matching.
If a reviewer confirms a duplicate before payment, follow the approved cancellation or hold process. If both items already have payments, route the case to the finance owner responsible for investigation and recovery. Record actual recovered or prevented amounts separately, and don't count every alert's face value as savings.
Route missing approvals through the actual authority
Read the invoice's required workflow state and assignment from the source system. A comment saying “looks fine” isn't a recorded approval unless your approved process makes it so. Check whether the invoice needs approval, who currently owns the task, and whether the workflow encountered an error.
Oracle's approval-history documentation shows records including the approver, reviewed amount, comments, and action history. This is evidence your team can inspect in the finance workflow. Don't infer approval solely from the presence of an approving phrase in retrieved correspondence.
Use the current delegation and authority rules when routing a case. If the assigned manager has left, send it through the approved reassignment route. An old invoice that the former manager approved doesn't establish who can approve a new request today.
Keep matching and approval states distinct. An invoice can pass a numerical check while awaiting a business approval. It can also have an approval record while a separate hold blocks payment. Oracle's 26B guidance on invoice holds states that holds prevent payment and that some require correcting the exception before release. Build your case view around the actual states your system maintains.
AI can draft a concise follow-up: identify the invoice, why it needs attention, and the permitted source link. The assigned staff member reviews any external message before sending it. The assistant mustn't invent an approver, force approval, or release a hold to meet a payment deadline.
Give unresolved workflow errors an operator. A reminder to an approver won't repair a failed notification or a broken rule. Log the error separately from business waiting time so the process owner can tell which intervention the case needs.
Build a case a reviewer can resolve
Consider an illustrative invoice for 120 parts at AUD 25 each, excluding tax. The approved purchase-order line has the same quantity and price, but the ERP records receipt of 90 parts. The invoice line totals AUD 3,000, and the recorded received quantity corresponds to AUD 2,250 at that price. The quantity gap is 30 parts.
The fixed check identifies the difference under the company's matching policy. It doesn't decide that the supplier made an error. The remaining goods might be in transit, staff might have missed a receipt, or the invoice might include a quantity the supplier hasn't delivered.
The case packet shows the three source records and their cutoff times. An assistant finds a permitted delivery email describing a split shipment and drafts a question for receiving. It identifies the email as correspondence requiring confirmation, with a link to the specific message.
The receiving owner confirms the actual delivery state and follows the approved receipt-maintenance process. If the goods haven't arrived, procurement and accounts payable decide the response under existing terms. The assistant leaves the exception open until the owner records the appropriate source correction or reviewed disposition.
Now consider a second PDF with a similar invoice reference and the same line total. The application attaches it as a possible duplicate signal to the case. The reviewer checks whether it is a resent copy, a different delivery, or a corrected invoice. The queue doesn't create a second independent instruction to pay.
A workable case view has the reason, supporting records, outstanding question, owner, and next review time. It separates the model's proposed explanation from confirmed facts. Record the final decision and source reference so another reviewer can understand the outcome without reconstructing the entire email thread.
Measure missed cases and review effort
Compare the proposed workflow with the current rules on the same held-out invoice population. Include ordinary invoices as well as confirmed exceptions. Keep development cases separate, and have finance reviewers label cases using their permitted source evidence. Record ambiguous outcomes rather than forcing every case into a convenient label.
For each exception type, measure the share of flagged cases that reviewers confirm and the share of known exceptions that the workflow finds. The first describes alert precision; the second describes recall within that labelled population. Sampling only alerts can't show how many cases the workflow missed.
Report counts alongside percentages. In an illustrative evaluation with 100 alerts and 40 confirmed exceptions, precision is 40%. That result leaves 60 alerts needing a different disposition. Measure the time reviewers spend on them before claiming that a higher detection count improves operations.
Compare fixed checks alone with fixed checks plus AI on the cases each handles. Record evidence-finding accuracy, wrong routing, and review minutes per resolved case. Evaluate document extraction separately so a misread amount doesn't appear to be a business mismatch.
Track waiting time by owner and cause. If the new packet reduces preparation time but the supplier takes the same time to respond, total case age may change little. Measure the oldest unresolved cases and reopenings so rapid closure doesn't hide poor resolutions.
Test severe failures separately from average performance. Include a wrong legal entity, a credit mistaken for an invoice, unavailable evidence, and changed approval state after the packet was prepared. Agree the release criteria with the controller, and retain the existing process when the evidence is insufficient.
Release a bounded workflow and measure its cost
Start with a defined invoice queue and a read-only evidence view. Run it alongside the existing process while staff review its findings. Keep the ERP's current holds and approval controls active. A queue assistant doesn't need the permission to change supplier bank details or execute payments.
Assign the ongoing work before rollout. Accounts payable owns the case queue, receiving or procurement supplies relevant evidence, and the finance control owner approves policy changes. The application operator handles failed connectors and extraction issues. Our guide to ownership after an AI workflow launches explains how to make those responsibilities operational.
Allow staff to correct a case explanation without altering the underlying source record. Route source corrections through their existing owners. Store only the permitted diagnostic material, and test that invoice attachments and cached answers follow the same access rules as the case itself.
Include integration maintenance and reviewer time in the cost comparison. Deduct the work created by false alerts and failed extraction from the preparation time the tool saves. Use the full workflow cost and an agreed baseline to decide whether the next exception type merits expansion.
For a private equity operating team, compare results within each portfolio company's invoice population before combining them. Differences in procurement policy or invoice mix can change the workload substantially. For an SME, a simpler queue with a responsible reviewer may fit better than a shared platform that requires ongoing specialist support.
Expand when staff can resolve the supported cases with less total effort and the control owner accepts the evidence. If the pilot mainly produces more alerts or shifts work to another department, fix that part of the process first. A good release gives the reviewer a clearer decision and preserves the authority needed to make it.
