AI invoice reconciliation
AI invoice reconciliation: every discrepancy qualified, resolved and closed, with its trail
AI invoice reconciliation starts where matching stops: a discrepancy has been found between the invoice, the order, the receipt or the contract, and it has to be resolved. Zylio’s Exception agent identifies the cause, gathers the evidence, proposes an outcome (accept, correct, request a credit note, dispute) and submits it for your decision.
The problem
Finding the discrepancy is half the work. The other half is called an exception.
Matching does its job: it flags that an invoice does not correspond. What happens next is described in no process. The invoice leaves the flow, someone picks it up, writes to the buyer to ask whether the quantity is right, writes to the receiving clerk to ask whether the backorder arrived, waits, chases, and ends up deciding with whatever they have. An exception is not a complicated invoice. It is three people, two emails and four days.
Multiplied by the number of invoices in anomaly, this mechanism produces a queue. It grows at month end, it grows when a supplier changes system, it grows when a contract is renegotiated and prices move. And since the oldest cases are also the hardest to document, the queue empties from the bottom: you pay what you can no longer dispute.
AI invoice reconciliation takes on that queue. Not to decide in your place, but so that every case reaches the right person already investigated: what diverges, why, what it costs, and what can be done about it.
What lands in reconciliation
Six discrepancies that come out of matching and await a decision
The residual price gap
Quantity and receipt compliant, but the unit price diverges from the contract. The question is no longer “is there a gap” but “who is right, and what do we do with the difference”.
The quantity gap outside tolerance
Invoiced more than received, beyond the accepted threshold. Backorder on its way, keying error, or delivery never made: the cause changes the outcome.
The exact or disguised duplicate
The same invoice submitted twice, or the same service invoiced under two different numbers, sometimes by two entities of the same supplier.
The expected credit note never applied
A dispute was settled by a promised credit note; the next invoice does not deduct it. Nobody remembers, except the file.
The invoice without an order, or with several
Nothing to match, or too much: the agent finds the original commitment, or establishes that there is none, and says so.
Diverging bank details
An IBAN different from the one in the supplier master, an address that changes: presented as such before any payment, never settled alone.
The mechanism
How the Exception agent reconciles a discrepancy
- 01
Qualify the cause
Which document is at fault: the invoice, the order, the receipt, the contract? The agent rereads all four, retrieves the history of the supplier and the item, and names the most likely cause with its confidence level.
- 02
Quantify and gather the evidence
The amount at stake, the line concerned, the clause or document that is authoritative, the credit note already promised if there is one. Each value stays linked to the place in the document where it was read.
- 03
Propose an outcome
Accept within tolerance, correct the allocation, request a credit note, dispute the line, wait for receipt. A proposal, argued, never an action.
- 04
Submit, then close with the trail
The case is presented to the authorised person. Their decision is recorded (who, what, how much, when) and the case is closed. Whatever matches no rule is raised with its reason.
The pillar: what the Exception agent takes on and what it never decides.
The decision stays human
What the agent proposes, and what only you decide
The agent produces an argued proposal: here is the gap, here is its probable cause, here is what we suggest doing about it. It does not block the payment in your ERP, does not generate a credit note, does not write to the supplier. Those three actions remain yours, and they are faster because the file is complete before you open it.
That limit is not commercial caution; it is a design rule. A reconciliation that settles on its own ends up accepting gaps to empty the queue. A reconciliation that investigates and submits keeps the queue short without ever taking the decision away from you. The same case produces the same proposal today as in six months, and every past decision remains available with the rule that applied.
No discrepancy is dismissed silently. Whatever matches no rule is raised, with its reason.
What it changes
What changes when the exception queue stops growing
The queue stops growing, first. Cases arrive qualified and leave decided; the oldest ones are no longer the ones paid for want of documentation. On the scopes analysed, 15 to 45% of time handed back to teams, per FTE, depending on the scope and the maturity of the data: the time returned is investigation time, not decision time.
Then, every supplier has a file. Resolved gaps, credit notes obtained, open disputes, recurring causes: all tied to the original invoice. A renegotiation, an audit or a change of contact at the supplier no longer starts from scratch. On the scope analysed, between 1 and 7% of margin recovered: recovered because documented, then claimed by your teams.
Finally, the close stops being an inventory. Invoices in anomaly are known, quantified and can be accrued, with their resolution status. The statutory auditor asking for the trail of an invoice gets, for each decision, who took it, on what basis and on what date.
The use case: the credit note promised, the credit note received and the invoice that should have deducted it.
Where this page sits
Matching, reconciliation, accounting reconciliation: three moments
Invoice matching compares the invoice with the order and the receipt, and finds the gap: that is the Matching agent’s work, described on its page. AI invoice reconciliation, this page, takes the gap found and carries it through to a decision and a closure. Accounting reconciliation, finally, happens on the accounts payable side: tying invoices, credit notes and payments to ledger entries, and clearing them. Three moments, three pages, one thread: the invoice line and its evidence.
The moment before: order, receipt and invoice matched at line level.
Exception
Invoices without a purchase order, multi-order invoices, duplicates: handled.
Takes on what fits into no standard workflow, instead of sending it back to the team.
The queue of blocked cases stops growing.
What Exception detects
- Invoices without a purchase order
- Several purchase orders on one invoice, one purchase order across several invoices
- Exact and disguised duplicates
- Credit notes missing or never applied
- Off-contract spend
- Cost allocation entered as free text
- IBAN invalid or diverging from the reference data
Nothing is lost. Everything can be checked, everything can be proven.
- The contract clause and the invoice line, highlighted side by side.
- Every extracted value stays linked to the exact place in the document where it was read.
- The same case produces the same decision, today as in six months: the rules are applied deterministically.
- No discrepancy is set aside in silence. Anything that matches no rule is raised, with its reason.
- The agent records what it did, in the order it did it: who, what, how much, when.
Frequently asked questions
What is the difference between invoice matching and invoice reconciliation?
Matching compares the documents and establishes a gap. Reconciliation resolves that gap: it identifies the cause, quantifies the amount, proposes an outcome and submits it for decision. The first is run by the Matching agent, the second by the Exception agent; both leave the decision to your teams.
Can the agent accept a small gap on its own?
Only if you have set a tolerance that provides for it, per supplier, category or amount, and that acceptance remains traced with the rule applied. Outside tolerance, the agent proposes and a person decides. No implicit rule: whatever matches nothing is raised with its reason.
How does the agent find a credit note promised six months ago?
Because the original dispute, its resolution and the expected credit note are tied to the supplier and the line concerned in the file. When the next invoice arrives without the deduction, the agent matches it to the expected credit note and flags it, with the original dispute one click away.
Can Zylio stop a risky payment?
No. Zylio writes nothing into your ERP and does not intervene in the payment run. It flags the case (duplicate, diverging IBAN, gap outside tolerance) before the due date, with the evidence, and your team decides whether to hold or pay in its own tool.
Measurable impact in every environment
More than 5 million procurement documents analysed
Between 1 and 7% of margin recovered
on the scope analysed
From 15 to 45% of time given back to teams, per FTE
depending on the scope and on data maturity
Zylio fits into your existing ecosystem.
The ERP runs the process. Zylio handles the exception and recovers the value that escapes it: invoices without a purchase order, line-by-line price discrepancies, duplicates and overbilling, off-contract spend.
Your data under high security.
Zylio meets the most demanding standards, and nothing is committed without your approval.
- Certifications
- Hosting
- Encryption
- Access
Going further
- ERP exception managementThe pillar: invoices without orders, duplicates, credit notes, off-contract purchases.
- Invoice matchingThe moment before: finding the gap between order, receipt and invoice.
- Dispute a supplier invoiceThe use case: the claim, with the evidence, carried out by your teams.
- The 3-week diagnosticMeasure on your data what unresolved discrepancies cost.
See what this looks like on your own data
Twenty minutes, on a spend category of your choosing. We show you what the agents detect, with the evidence behind it.
- No commitment, on your own data
- Result in 3 weeks
- 20 minutes, no sales pitch
- Your data stays hosted in France
- No change of tool or process