By KYN AI Advisory Team — AI implementation specialists, Singapore
An AI agent can run nine checks on every bill before it is paid: five for duplicates and four for changed vendor details. The checks are rules, not judgement, so each one has a right answer you can test. The agent flags and holds. A named person releases the payment. Most of the value comes from the vendor bank-detail check, because a changed account number is the pattern behind most invoice-redirection fraud.
Why check bills before payment, and not after?
A payment sent to the wrong account or paid twice is a recovery problem. You ask a bank to recall funds, or you ask a supplier for a credit note. Both take time and neither is certain. A check before the payment run costs seconds.
A bill passes through four points in a small finance team: it arrives (usually by email), it is keyed or extracted, it is approved, and it is paid. Duplicates enter at the first two points. Vendor-detail changes enter at the first and are acted on at the last. An agent that sits between "extracted" and "approved" sees every bill with the full history of that vendor beside it, which a person processing bills one at a time does not.
The agent is not a fraud detector. It cannot know whether a supplier really changed banks. It can know that the account on this bill differs from the last twelve, and it can stop the bill until someone confirms the change by a channel the bill did not come from.
Which duplicate checks should an agent run?
Run these in order, cheapest first. Each check compares the new bill with bills already in the ledger for the same legal entity.
- Exact match. Same vendor, same invoice number, same amount. Block as a duplicate.
- Number variants. Same vendor and amount, invoice numbers that differ only by case, spaces, dashes or padding zeros ("INV-0042" and "inv 42"). Hold for review.
- Same amount, near date. Same vendor, same amount, invoice dates within a set window (for example 14 days), different numbers. Hold for review. This catches re-issued invoices and credit-and-rebill cases.
- Same document, different file. The attachment hash or the extracted text matches an earlier file. A forwarded email and its original produce this.
- Already paid. The bill matches a payment in the bank ledger by amount and payee even though no bill is marked paid. This catches the case where a supplier is paid by card or by a manual transfer outside the normal run.
Checks 1 and 4 are exact and can block. Checks 2, 3 and 5 are fuzzy and should only hold. A hold puts the bill in a queue with both records side by side. A person decides in under a minute, and the decision is logged.
Set the window and the tolerance per vendor type. A monthly retainer has the same amount every month by design, so check 3 should compare invoice period as well as invoice date. If the agent flags every retainer, people stop reading flags.
Which vendor-change checks matter most?
Four checks cover the changes that cost money.
| Check | What the agent compares | Action | |---|---|---| | Bank account changed | Account number and bank on this bill against the vendor master and the last paid bill | Hold payment, route to call-back | | New payee name | Name on the bill against the vendor master, with a similarity score | Hold if below a threshold | | Contact changed | Sender domain, reply-to address or phone on the bill against the vendor record | Flag, and hold if the bank also changed | | New vendor with a bank account already used | A new vendor record whose account number matches another vendor | Hold, route to a manager |
The bank-account check is the one to build first. The common pattern is business email compromise: a fraudster poses as a supplier and sends new bank details. The defence that works is procedural: confirm any bank change by a call to a number you already held, not one printed on the new invoice. An agent cannot make that call. It can make sure nobody pays before the call happens.
The second and fourth checks protect against two other cases: a lookalike company name and an insider creating a fictitious vendor that shares a bank account with a real one.
What should the agent hold, and what should it block?
Use three outcomes and keep them distinct.
- Pass. No rule fired. The bill moves to approval as normal.
- Hold. A fuzzy rule fired or a vendor detail changed. The bill cannot enter a payment run until a named person clears it.
- Block. An exact duplicate. The bill is marked duplicate and linked to the original. A person can reverse it, with a reason.
Never let the agent change the vendor master. It reads the master and proposes a change. The change is applied by a person, and the person who approves a bank change should not be the person who approves the payment. That separation of duties is the control. Software enforces it by checking that the two actors differ.
For the same reason, the agent should not release a hold on its own because a second email arrived saying "please ignore the earlier message". An email is the channel the fraud used. Release needs a confirmation that came through a different channel, entered by a person.
How do you test these checks before relying on them?
Build a test set from your own history, not from a vendor demo.
- Pull the last 12 months of paid bills.
- Insert known cases: a copied bill, a bill with a reformatted number, a bill with an altered account number, a vendor with a lookalike name.
- Run the checks. Count what was caught and what was missed.
- Count false holds on clean bills. A hold rate above what a reviewer can clear in a normal day will be ignored.
Then run in shadow mode for one or two payment cycles: the agent flags, people keep paying as before, and you compare. Only then let holds gate the payment run.
Keep the rules versioned. When you change a threshold, record who changed it and when, so a missed duplicate can be traced to the rule that was live at the time. See the companion piece on what a finance agent should log: audit trail for finance agents.
What does this cost to run?
The checks are database queries. They cost close to nothing per bill. The model cost is in reading the bill (extracting vendor, number, amount and bank details from a PDF or email), and in writing a one-line reason for each hold. On KYN's own books, reading bills from Gmail and matching them to a ledger runs on cents per document. The larger cost is review time, and the main lever on it is keeping false holds low. For the full cost picture, see finance agent costs per 100 bills.
Where KYN fits
KYN builds finance agents that run in your own cloud account, with rules like these written to your approval policy. On a manufacturer's ledger we reconciled 3,309 rows with zero duplicates, and on KYN's own books bills arrive from Gmail into a register where receivables are chased at 3, 14 and 30 days. Money movement, filings and deletions wait for a named person. Every action is logged with the actor, and agents run on their own restricted accounts.
The first 14 days are a review of your stack and interviews with your team. A full build ships in under 90 days. See finance systems and security.
Frequently asked questions
Can an AI agent stop a payment on its own?
It can hold a bill so it cannot enter a payment run. It should not send, cancel or recall a payment. Money movement stays with a named person, and the hold is the agent's only lever.
Will the agent catch a fraudster who has a real supplier's email account?
Not from the email alone, because the message looks genuine. It will catch the changed bank account, which is what the fraud needs, and it will hold the bill until a person confirms the change by a known phone number or another channel the bill did not use.
Do I need a new accounting system for this?
No. The agent reads bills and the ledger from the system you already use, such as Xero, and keeps its own record of flags and decisions. See integrations for how that connection is built.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
