Reconciling vendor statements with AI

How the bot works

Eight steps. The matching is ordinary code and costs almost nothing to run; the model is only asked the questions that actually need judgment.

1. It picks up the statement. From the mailbox suppliers already send to, a shared AP inbox, a scanned batch, or a supplier portal you download from. Suppliers don't have to change how they send, which is why coverage stops being limited to the top ten accounts.

2. It reads the statement into lines. Supplier, account, period, currency and their closing balance, then one record per line: document number, date, type, amount and what they say is still open. It also establishes that this is a statement and not an invoice, which is a mistake that costs real money when it goes the other way.

3. It matches line by line against your ledger. On document number, amount, date and payment history, inside the tolerances you set — so a prefix they add, a rounding difference or a date a day out doesn't become a false exception. Credit notes and part payments are matched as first-class things, not as negative invoices that confuse the totals.

4. It names the exception, never just a mismatch. Missing invoice. Missing on statement. Unclaimed credit. Amount differs. Misapplied payment. Duplicate. Timing difference. Every unmatched line lands in one of your classes with the evidence attached, because “does not reconcile” is not a finding anybody can act on.

5. It explains why each match was made, or wasn't. Every line records the rule that matched it and the fields that agreed, and every exception records what was compared and what differed. The point is that your AP clerk can disagree with the bot by reading one row, rather than redoing the work to find out whether it was right.

6. It flags the duplicate before the payment run. The same invoice sitting in your ledger twice — once from the original, once from a forwarded copy under a slightly different number — is caught on supplier, date, amount and line content, and raised against the scheduled run rather than after it. The bot does not hold or cancel the payment. It tells a person, in time.

7. It drafts the reply to the supplier. One message per supplier: what agrees, what you are querying and what you are asking them to resend, with the document numbers and amounts filled in. It is a draft. A person reads it and sends it.

8. It writes the reconciliation record. One immutable row per statement line: the supplier and period, the line as received, what it matched to, the rule and its version, the exception class if any, the model and prompt version, the person who actioned it, and UTC timestamps.

What you configure

It can be configured to run in any business. This is what that actually means — the list of things that are yours, not ours.

Your ledger

Which system is the record, which company and which accounts are in scope, and whether we read it through an API or a scheduled export.

Your tolerances

Rounding, how far a date can be out, how much of a document number has to agree, and whether a small difference is a match with a note or an exception.

Your exception list

The classes themselves. The six we start from are a starting point, not a fixed set — add “on hold pending goods receipt” or “disputed, see case” if that is how your team actually thinks.

Your routing

Who sees which class, what goes to the buyer instead of to AP, and what is escalated by value or by age.

Your suppliers

Statement format, cycle, contact and account mapping per supplier — including the ones who still send a scan, which is the whole reason coverage is usually partial.

Your periods

When a reconciliation runs, what it closes against, and how a timing difference across a cut-off is treated rather than reported as an error.

Your channels

Where the exception list and the draft replies land: email, Slack, Microsoft Teams, or a queue in your own system.

The words it uses

The tone and length of the query to the supplier, and the versioned prompts behind it — yours to read, yours to tune.

Transparent, and configurable by you

The dark band below is what the system will not do. This is what you can see and change — and it is how we build everything, not something invented for this page.

You see what it did, and why

Every matched line says which rule matched it and which fields agreed; every exception says what was compared and what differed, with the statement line and the ledger entry both attached. A bare “does not reconcile” is not an output this system can produce.

Versioned prompts you can tune yourself

The prompts behind the judgment calls are yours to read and yours to tune. A change is a reviewable diff, replayed against statements you have already reconciled so you can see what it would have classified differently, and rolled back the same way.

A human in the loop wherever judgment actually matters

Automation handles the lines that agree. Every exception is actioned by a person — the bot drafts the query to the supplier, it does not send it, and it has no path to the payment run at all. That boundary is a property of the system, not a promise about how carefully we'll use it.

Every run logged, along with what it cost

One row per statement line: the match, the rule and its version, the exception class, the evidence, who actioned it and when — plus token usage and cost for that run.

It can be configured to run in any business. The ledger and the rules are yours: your tolerances, your exception classes, your routing, your systems. The accounts-payable wiring on this page is one configuration of it, not the limit of it.

Works with your tools

This runs on top of the stack you already pay for. We're not replacing your accounting system.

• QuickBooks Online or Desktop
• Xero
• NetSuite
• Sage
• Microsoft Dynamics 365
• SAP Business One
• Bill or a similar AP tool
• A shared AP mailbox or scanned batch
• Supplier portal downloads
• Email, Slack or Microsoft Teams

Works well for

• Wholesale distributors — Supplier statements run to hundreds of lines a month, and return credits are the ones that go unclaimed.
• Specialty trade contractors — Supply houses bill by job and settle by statement, and the invoice you never received is the one that hurts.
• Restaurant groups — Food distributors deliver daily and credit short cases, and the statement is where those credits surface.
• Manufacturers — Material suppliers invoice per shipment, so the statement is the only place a short-paid line shows up.
• Property management companies — Vendors bill across many properties, and the same invoice can be posted against two of them.

How a rollout works

Nothing goes live on day one. A shadow run over statements you have already reconciled comes first, and it is where your own numbers come from.

1. 01Discovery

   The quote call, then a working session. We read a few months of real statements as they arrived, the reconciliations your team produced from them, your tolerances, and what access your ledger allows. You get the matching design, the exception classes and a written scope.

2. 02Shadow mode

   The bot runs over historic statements only. Nothing is sent. Nothing is actioned. Nobody's day changes. It produces a reconciliation per statement and we compare it, line by line, against what your team concluded. Every disagreement is either a tolerance to adjust or a miss worth knowing about — and this is where your own accuracy numbers come from, on your own statements.

3. 03Assisted mode

   Live statements. The bot reconciles, classifies and drafts the supplier queries; your AP team reviews, edits and sends. Coverage stops being limited to the accounts somebody had time for. The control doesn't change.

4. 04Optional standing runs

   Optional. Statements that arrive on a schedule in a stable format can be reconciled automatically and reported by exception only, with every hard stop in force and the kill switch. Even then it is still read-only, and a person still actions every exception. Plenty of teams stop at step 03, and that's a good place to stop.

What we don't claim

• No numbers we haven't earned. No match rate, no recovery figure, no hours saved, no “one in three statements contains an error”. We haven't run this on your statements. Shadow mode is where those numbers come from, and they'll be yours.
• No customer claims on this page. No names, no case studies, no logos.
• It isn't an audit, a recovery audit or a controls opinion, and it doesn't replace your controls, your accountant or your AP team's judgment.
• It can't reconcile what your ledger doesn't hold. If an invoice was never entered, the bot can tell you it is missing and show you the statement line — it cannot tell you whether you received the goods.
• Fully autonomous reconciliation isn't on offer. The design assumes a person actions every exception and sends every query. That's deliberate, and it's why the boundary is written down.

Questions people ask

Can AI reconcile vendor statements against our ledger?

Yes - and the useful version of the answer is that it does the matching and the classification, and a person decides what to do. An AI agent can read a supplier statement in whatever format it arrives, normalize it into lines, match each line against your purchase ledger within tolerances you set, and put every line that does not agree into a named exception class with the evidence attached. What it will not do is decide a dispute, or touch a payment.

Will it pay, hold or write anything off on its own?

No, and it has no credential that would let it. The system is read-only against your ledger: it reads, matches, classifies and drafts. It does not pay, hold, release, post, journal or write anything off, and it is not wired into your payment run at all. Where it finds a duplicate about to be paid twice, it raises that to a person in time for them to act, which is a different thing from acting itself.

What exceptions does it actually name?

The starting set is six, and they are deliberately specific: missing invoice - on their statement, nothing in your ledger; missing on statement - in your ledger, not on theirs; unclaimed credit - a credit note they issued that you never took; amount differs - same document, two numbers; misapplied payment - paid, but against the wrong invoice; and duplicate - the same invoice twice, often under two numbers. Timing differences across a period cut-off are handled as their own case rather than reported as errors. The classes are configuration, not a fixed list: if your team thinks in terms of "on hold pending goods receipt" or "disputed, see case", those become classes too.

Can it catch a duplicate before we pay it twice?

Yes, and raising it before the payment run rather than after is most of the value. Detection runs across the supplier's whole ledger history rather than the statement in front of it, on supplier, date, amount and line content - so the forwarded copy that was entered a second time under a slightly different number is caught. It is a deterministic check: no model judgment, no false confidence. The bot flags it against the scheduled run and a person decides.

Our suppliers send statements in a dozen different formats. Does that matter?

That is the normal case, and it is the reason most teams only reconcile their largest accounts. A clean PDF, a scan of a fax, a spreadsheet whose columns moved this month, a portal download with no export, nine lines pasted into an email - all of them are read into the same line structure, with a confidence on every field. A statement the bot genuinely cannot attribute to a supplier account is escalated rather than guessed at.

Does it work with QuickBooks, Xero, NetSuite or Sage?

Yes - by API or by scheduled export, alongside Microsoft Dynamics 365, SAP Business One and AP tools like Bill. What it needs from your ledger is open items, paid items and payment history for the suppliers in scope. If your system is not one of those, the question is only whether it offers an API or a scheduled export; most do, and an export is all shadow mode needs. Naming a system means we can read it, not that we are partnered with it.

Is there a record we can hand an auditor?

Yes, and it is designed for the person who has to test the control. One immutable row per statement line records the supplier and period, the line exactly as received, the ledger entry it was matched to, the rule and version that matched it, the exception class and the evidence behind it, the model and prompt version that produced the result, the person who actioned it and UTC timestamps. The intent is that someone who was not there can reconstruct any single line from that one row.

What stops a supplier's statement from telling it what to do?

Statement text, filenames, email bodies and line descriptions are treated as data and never as instructions. Every model call runs as structured output against a fixed schema, untrusted text is kept out of the instruction block, and anything that reads like an instruction is quarantined, flagged for a human and logged. A statement cannot mark itself reconciled. Separately, the matching tolerances and the hard stops sit outside the model entirely, so there is nothing there to talk around - and since the system is read-only, there is nothing to gain by trying.

How long does it take to get running?

The first milestone is shadow mode, and it needs three things: a few months of real supplier statements as they arrived, the reconciliations your team produced from them, and read access or a scheduled export of open items and payment history from your ledger. We will not quote you a timeline before we know which systems are involved and what access they allow - you get a real one in your quote, once Ozzie's call has gathered the details.