Entering supplier invoices with AI

How the bot works

Nine steps. Eight of them are arithmetic, matching and rules — ordinary code that costs almost nothing to run. The model is only asked to read the document.

1. Everything arrives in one place. An AP mailbox, a scan folder, an SFTP drop, a shared drive. One intake, so nobody is keying out of their own inbox and no invoice exists only in somebody's phone.

2. It reads the header and the lines. Supplier, invoice number, invoice date, due date or terms, your account number, the currency, and every line with its description, quantity, unit price and amount — not just the three fields a capture tool pulls.

3. It proves the arithmetic. Quantity times unit price per line, lines summing to the subtotal, tax at the rate on the document, subtotal plus tax matching the stated total. A document whose own numbers disagree is an exception, not a bill — and this check is plain code, so it is right every time.

4. It matches the supplier to a record you already have. By tax id, remit-to details, account number and name, in that order. A supplier it cannot match is never created on the fly — it goes to a person, because a new payee is exactly where invoice fraud gets in.

5. It catches the same invoice arriving three ways. Supplier plus invoice number first, then the harder cases: a PDF that was also forwarded and also scanned, a credit memo keyed as a bill, two invoices with the same amount and date from the same supplier. A probable duplicate is held and shown next to the one it matched.

6. It matches the purchase order and the receipt. Where you use them. Line to line against the order and against what was actually received, inside the price and quantity tolerance you set. A short delivery, a price that moved, or a line nobody ordered comes back named rather than absorbed.

7. It codes the bill from your rules. Account, class, job, department, tax treatment — from the rules you wrote and what this supplier was coded to last time, with the rule it used recorded on the line. A rule you can read and edit, not a model asked the same question twice.

8. Anything uncertain waits, with the original beside it. A low-confidence field, a failed check, a new supplier, a changed bank detail, a line it cannot code. The reviewer sees the extracted value, the page it came from and the exact question — which is a far smaller job than keying the invoice was.

9. It posts the bill and writes one row. The bill lands in your accounting system, ready for your existing approval and payment run, with the PDF attached. The record holds every extracted field with its confidence, every check with its result, the coding rule, the reviewer if there was one, and the posting reference.

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 chart of accounts and coding rules

Which accounts, classes, jobs or departments a supplier's lines land in, how tax is treated, and what to do with a line that matches nothing.

Your tolerances

How much a unit price may move before it is an exception, how much short delivery is acceptable, and the rounding you allow on tax. Per supplier if a supplier needs its own.

Your duplicate policy

What counts as the same invoice, how close is close enough, and whether a probable duplicate is held, flagged or rejected outright.

Your purchase order policy

Which spend requires an order, whether a receipt is matched too, and what happens to an invoice that arrives without one.

Your supplier rules

Per-supplier layouts worth learning once, the remit-to details on file, and which suppliers may never be created or changed by anything but a person.

Your confidence thresholds

What posts on the checks alone, what gets a glance, and what nobody sees until a person opens the document. Per field, not one global number.

Your approval routing

Where an exception lands and who owns it — email, Slack, Microsoft Teams, or the queue in your accounting system your team already works out of.

Your systems and your files

Which system the bill is written to, whether by API or an import your team runs, where the original PDF is stored, how long it is kept and who can open it.

The words it uses

The wording of the question that goes back to a supplier or a buyer, and the versioned prompts behind the reading — 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 field carries a confidence and the part of the page it was read from, and every check records its result. You can see that the tax tied out to the cent and that the coding came from your own rule before you approve the bill.

Versioned prompts you can tune yourself

The prompts behind the reading are yours to read and yours to tune. A change is a reviewable diff, replayed against invoices you have already keyed by hand so you can see exactly what it would have done differently, and rolled back the same way.

A human in the loop wherever judgment actually matters

Arithmetic and matching are automatic. A new supplier, a changed bank detail, a failed check or a line nobody ordered is a person's decision — 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 invoice: every extracted field with its confidence, every check with its result, the coding rule and version, the reviewer, the posting reference — plus token usage and cost for that run.

It can be configured to run in any business. The accounts and the tolerances are yours: your chart of accounts, your coding rules, your purchase order policy, 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 accounting system you already pay for. We're not replacing your ledger or your payment process.

• QuickBooks Online
• Xero
• NetSuite
• Sage Intacct
• SAP Business One
• Acumatica
• Bill or a similar AP tool
• An AP mailbox
• A scan folder or SFTP
• Email, Slack or Microsoft Teams

Works well for

• Manufacturers — Raw material invoices arrive against orders and receipts, and the three rarely agree line for line.
• Accounting and bookkeeping firms — Every client sends a different pile of supplier invoices, and somebody has to key all of them.
• Restaurant groups — Food and beverage invoices land daily per location, with line prices that move every week.
• Healthcare clinics — Supply and service invoices come from dozens of vendors against standing orders nobody rechecks.
• Nonprofits — Every invoice has to be coded to the right program or grant before it can be paid.

How a rollout works

Nothing posts on day one. A dry run over invoices you have already keyed comes first, and it is where your own numbers come from.

1. 01Discovery

   The quote call, then a working session. We read your chart of accounts, your coding rules, a stack of real invoices from your most awkward suppliers, your purchase order policy and what access your accounting system allows. You get the check design, the exception classes and a written scope.

2. 02Dry run

   The bot runs over invoices your team has already keyed. Nothing is written anywhere. It produces the extracted fields, the check results and the proposed coding, and we compare them line by line against what was actually posted. Every disagreement is either a rule to fix or a miss worth knowing about — and this is where your own accuracy numbers come from, on your own invoices.

3. 03Assisted mode

   Live. The bot reads, checks, matches and codes; a person reviews each bill before it posts, with the original beside it. The keying stops being keying and becomes checking. The control doesn't change.

4. 04Optional posting by exception

   Optional, and per supplier. Where a supplier's invoices have come through clean for a while and they are matched to an order and a receipt, those can post straight through with every hard stop in force and the kill switch. 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 extraction-accuracy figure, no percentage of invoices touchless, no “close in half the time”. We haven't run this on your invoices. The dry run 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 doesn't fix a bad document. A scan with a thumb over the total, a supplier whose invoice has no invoice number, a photo taken in a dark truck — it reads what it can, names what it cannot, and asks. The honest output is a question, not a value.
• It isn't an AP department or a spend-control program, and it does not decide whether a cost was a good idea. It gets the document into the ledger correctly; what you buy and what you pay is still yours.
• Fully autonomous posting isn't on offer. The design assumes a person reviews, and that exceptions always do. That's deliberate, and it's why the boundary is written down.

Questions people ask

Can AI do our supplier invoice data entry?

Yes - and the honest version is that the reading is the easy half. An AI agent can pull the supplier, the invoice number, the dates, the terms and every line with its quantity and price off an emailed PDF, a scan or a photo. What makes it safe to use is everything around that: proving the document's own arithmetic, matching the supplier to a record you already have, catching the same invoice arriving three different ways, matching the purchase order, and holding anything that does not tie out with the original beside it. Extraction is rarely the problem. Skipping the checks is.

How accurate is the extraction?

We will not give you a number, because any number we gave you would be about somebody else's invoices. What we can tell you is how the design behaves when it is wrong: every field carries a confidence and the part of the page it came from, the arithmetic has to prove out in plain code before anything posts, and a field below your threshold is a question rather than a value. The dry run over invoices you have already keyed is where your accuracy number comes from, and it is yours.

What stops the same invoice being entered twice?

Three layers. Supplier plus invoice number catches the obvious case. A content match catches the one that arrived as an attachment, got forwarded by a manager and then got scanned by the office - the usual way a duplicate gets in. And a same-supplier, same-amount, same-date check catches the ones with no usable invoice number at all. A probable duplicate is held and shown next to the invoice it matched, so a person decides in a few seconds rather than finding it at month end.

Does it pay the invoices?

No. It holds no banking credential and no payment rail. It writes a bill into your accounting system, with the original attached, and your existing approval and payment run happens exactly as it does today. Releasing money is a person's decision, every time, and there is no configuration in which the bot makes it.

What if the invoice says the supplier's bank details have changed?

It stops. A remit-to or bank detail that differs from the one on file is held, flagged as a change, and shown beside the details you already have, because an invoice that quietly redirects payment is one of the most expensive things that can go through an AP inbox. The bot cannot create a supplier or edit a supplier record under any configuration - a person does that, after they have verified it in the way your policy says.

Can it handle scans, photos and handwritten invoices?

Scans and photos, yes - that is most of the work, and a per-supplier layout is worth learning once. Handwriting is where honesty matters: a handwritten total is a hard stop rather than a confident guess, and the invoice goes to a person with the image beside it. The same goes for a document whose own numbers do not add up, which gets named rather than quietly corrected.

Can it code the bill to the right account, job or program?

Yes, from rules you write plus what this supplier was coded to last time, and the rule it used is recorded on the line so you can audit it. Where your coding depends on something the invoice does not say - which job, which grant, which department - the bot asks the person who knows rather than picking the account that is usually right. That question is a few seconds of work; a year of miscoded bills is not.

Does it work with QuickBooks Online, Xero or NetSuite?

Yes - by API where the system has one, or as an import your own team runs where it does not, alongside Sage Intacct, SAP Business One, Acumatica and AP tools like Bill. If your system is not one of those, the question is only whether it can accept a bill by API or import and whether we can read your supplier list. A dry run needs neither, because it writes nothing. Naming a system means we can read or write it, not that we are partnered with it.

Is there a record of what it did to each invoice?

Yes, and it is designed for whoever has to explain a posted bill six months later. One immutable row per invoice records the file it came from, every extracted field with its confidence and the region of the page it was read from, every check with its result, the coding rule and its version, the model and prompt version, the reviewer if there was one, the posting reference and UTC timestamps. The whole batch is scoped to a run id so it can be reversed as a unit.