Use caseDocument AIWorkflow automation
Supplier invoices from inbox to ledger, with the checks a good controller would do
Supplier invoices read from the AP inbox, checked for VAT errors, duplicates and changed bank details, matched to POs and posted to Xero, DATEV or your ERP.
A blueprint, not a client story. The business described is illustrative; the architecture, integrations and trade-offs are real, and this is how I would build it. By Ergini, .
The short version
An invoice pipeline for AP teams that still key supplier invoices by hand. It reads each invoice from the AP inbox, extracts supplier, VAT ID, IBAN, lines and totals, checks the arithmetic, duplicates and supplier master, matches the invoice to the purchase order and goods receipt, and proposes GL coding with a reason. Approvals happen in Slack or Teams, posting goes to your accounting system or ERP, and every mismatch or changed bank detail goes to a person.
- Best for
- Companies keying a thousand or more supplier invoices a month into an ERP or accounting system, most of them against purchase orders.
- Connects to
- Outlook (Microsoft 365), Xero, QuickBooks Online, DATEV, NetSuite, SAP Business One, Slack or Microsoft Teams
- The AI does
- Reads invoices of any layout, pairs free-text invoice lines with PO lines, and proposes GL accounts and cost centers with the reason for each.
- People do
- Clear the exceptions queue, approve invoices above their limits, verify every bank detail change by phone, and release the payment run.
- Built as
- AI Workflow Automation, usually $15K - $30K
Fifteen hundred invoices, two clerks, one shared mailbox
Take a manufacturer with 150 people and about 1,500 supplier invoices a month. They arrive in a shared Outlook mailbox as PDFs, as scans from the post room and, since Germany made receiving e-invoices mandatory in 2025, as a growing share of XRechnung and ZUGFeRD files. Two AP clerks key them into SAP Business One, where the purchase orders and goods receipts live.
The mix is what makes it slow. Steel and castings against purchase orders, freight invoices that never quite match the quote, maintenance contractors with no PO at all, a monthly statement from the tooling supplier that is not an invoice, and payment reminders for invoices nobody received. Each needs a different check, and the clerks carry those checks in their heads.
The leaks are familiar. Approvals wait for plant managers who are on the shop floor, so the 2% early-payment discount lapses. The same invoice arrives by post and by email and gets paid twice. And once or twice a year an email announces new bank details, which is the one mistake that cannot be undone.
Ardent Partners' 2026 survey of 194 AP leaders put slow approvals and high exception rates joint first among AP problems, at 48% each, and found 58% of AP teams already using or piloting AI. Most of that AI reads documents. The checks around the reading are what this page is about.
The path of one invoice today
Watch a clerk handle a single purchase-order invoice and the steps are nearly always these.
- Open the email, save the PDF to the network drive and rename it so it can be found later.
- Find the supplier in the ERP. When the name on the invoice does not match the master record, search again by VAT ID or postcode.
- Find the PO number on the invoice, if the supplier printed one, then open the purchase order and the goods receipt.
- Compare quantities and prices line by line, and phone the warehouse when the receipt has not been booked.
- Type the header and every line, and pick the GL account and cost center from memory for invoices without a PO.
- Email the budget owner for approval, and chase after a week.
- Post, then file the PDF where the auditor will look for it.
No single step is hard. Together they make approvals the bottleneck, and they make the checks that matter most, duplicates and bank details, the ones that get skipped on a busy Friday.
The pipeline, check by check
The model is used twice: to read the document and to propose coding. Matching, tolerances, approval limits and the bank-detail rule are ordinary code, because they decide whether money leaves the company.
01 Trigger · Microsoft Graph
An invoice reaches the AP mailbox
A change notification fires for the shared mailbox. The app is restricted to that one mailbox, so it cannot read anyone else's email. Each attachment is stored unchanged with a hash, which doubles as the archived original.
02 Plain code
Take the e-invoices out first
An XRechnung file or a ZUGFeRD PDF with embedded XML is parsed directly. The data is already structured, so those invoices skip the model entirely and go straight to the checks (how e-invoice intake works).
03 AI model · Structured output
Read everything else
A vision-capable model classifies the document (invoice, credit note, reminder, statement, delivery note) and extracts header fields, lines, totals, payment terms and IBAN into a strict schema, with the page each value came from.
04 Plain code · VIES
Check it the way a controller would
Lines must add up to the net total, VAT must match the rate, and the invoice must carry the fields § 14 UStG requires for input tax deduction. EU VAT IDs are checked in VIES. The supplier is matched by VAT ID, then IBAN, then name, and the normalized invoice number is compared with everything that supplier sent before.
05 Decision
Anything to stop for?
Rules in code, in this order. The bank-detail check runs on every invoice, including the ones that look perfect.
- The IBAN is not the one in the supplier master then payment hold and a call task for the AP lead; nothing else moves
- A likely duplicate, a failed VAT or field check, or an unknown supplier then exceptions queue, with the reason written on the item
- Everything passes then on to matching
06 System · SAP Business One Service Layer, NetSuite REST
Match to the PO and goods receipt
Goods invoices get a three-way match, services a two-way match, with tolerances per category. Where the supplier's line text and your item numbers differ, the model proposes which lines pair up, and code then checks quantity and price on every pair.
07 AI model
Propose the coding
For invoices without a PO, the model proposes GL account, cost center and tax code from the line text and the supplier's history, with a one-line reason and the past invoices it relied on.
08 Person · Slack or Teams
Approve where people already are
The approval matrix in code picks the approver. A Slack or Teams card shows supplier, amount, match result, proposed coding, the reason and the PDF, with the discount deadline on top. Silence triggers a reminder, then the deputy.
09 Result
Post, archive, log
The bill is created in the accounting system or ERP with the PDF attached, keyed on supplier and invoice number so a retry can never post it twice. Every check, proposal and approval is written to the invoice's audit trail.
An invoice that passes every check but one
Business email compromise rarely looks suspicious. In this example the invoice is genuine, the goods arrived, and the email came from the supplier's own domain. Only the bank account changed.
AP mailbox, Thursday 10:12
- Email from the steel supplier's usual accounts address, subject 'Rechnung 2026-4471', one PDF attached.
- classify(file: "Rechnung_2026-4471.pdf")supplier invoice / 2 pages / German / no embedded XML
- extract_invoice(file: "Rechnung_2026-4471.pdf")no. 2026-4471 / 3 Sep 2026 / PO 4500001182 / 3 lines / net EUR 18,420.00 / VAT 19% EUR 3,499.80 / gross EUR 21,919.80 / IBAN ending 7731 / 2% discount within 10 days
- validate(invoice: "2026-4471")lines equal net / VAT correct / § 14 UStG fields present / VAT ID valid in VIES
- find_duplicates(creditor: "70412", number: "20264471")no match on number, amount or date
- match_supplier(vat_id: "DE27...")creditor 70412 / IBAN on file ends 0298 / no change request on record
- three_way_match(po: "4500001182")3 of 3 lines / 12.4 t received 2 Sep / prices within tolerance
- hold_payment(creditor: "70412", reason: "iban_mismatch")held / call task for AP lead / discount deadline 13 Sep
Invoice pipeline · Teams
Invoice 2026-4471 from creditor 70412 (EUR 21,919.80) matches the PO and the goods receipt, but it asks for payment to an IBAN ending 7731. The account on file ends 0298, and no bank change has been requested through the supplier master. Please call the accounts contact on the number stored in the master record, not a number from this email or invoice. Payment is on hold. The 2% discount runs until 13 September.
- A check on the sender would have passed this email. The comparison with the supplier master is what stopped it.
Six invoices that break naive automation
Clean invoices were never the problem. These decide whether the clerks still trust the queue after the first month.
One invoice, two copies
The supplier sends a ZUGFeRD file to the AP mailbox and a PDF to the buyer, who forwards it. The duplicate check keys on supplier and a normalized invoice number (spaces, leading zeros and prefixes such as 'RE-' removed), with amount and date as a second net. The structured copy wins; the PDF is filed against it.
Credit notes
A credit note is recognized by its title and sign, must name the invoice it corrects, and is set against that open item. It never enters the approval flow as something to pay. A credit note that references no invoice goes to the queue.
Multi-page invoices
Lines run across pages, and page two often opens with a carried-forward subtotal. Extraction reads the whole document at once, and because the lines must add up to the net total, a subtotal read as a line fails the arithmetic check instead of reaching the ledger.
Foreign currency and reverse charge
A dollar invoice from an Asian supplier carries no German VAT, and neither does an EU supplier's invoice under reverse charge, which must show both VAT IDs and the reverse-charge note instead. The rules branch on supplier country and tax treatment. The exchange rate comes from the accounting system, never from the model.
Partial deliveries
A PO for 400 pieces, 250 received, an invoice for 400. The match accepts 250, flags 150 with the receipt attached, and leaves the PO open for the rest. The clerk decides whether to wait for the delivery or ask for a corrected invoice.
Bank details that really did change
Suppliers do change banks. The change goes through the supplier master, never through AP: a call to a contact already on file, a second person approving the master data, and the first payment to the new account flagged. Verification of Payee, which euro-area banks have had to offer since October 2025, is a second net at payment time, not a replacement. The wider pattern is on the document fraud page.
Model, code or clerk: who owns each decision
The AI model
Read PDFs and scans into fields
Every supplier has its own layout, and a model reads them without a template per supplier. The approach is in the document extraction guide.
Pair free-text invoice lines with PO lines
'Hydr. hose DN10 1 m' and 'Schlauch 10 mm x 1000' are the same part. Code then checks the quantity and price of each pair.
Propose GL account, cost center and tax code
Proposals arrive with a reason and the past invoices behind them, so a clerk accepts or corrects in seconds.
Plain code
Arithmetic, VAT and mandatory-field checks
They have exactly one right answer, and the schema is enforced with structured outputs.
Duplicate and supplier master checks
Deterministic keys, logged, identical on every run.
Match tolerances and approval routing
Limits live in configuration the controller owns, not in a prompt someone could talk around.
A person
Bank detail changes
A call to a known contact and a second approver. The system only detects and holds.
Exceptions and approvals
Price disputes, missing receipts, unknown suppliers and anything above an approver's limit.
Releasing the payment run
The system never pays anyone. It hands the ERP an approved, posted bill.
From shadow run to touchless, one supplier at a time
Nothing posts on its own at first. Each stage runs on the real invoice stream and has to earn the next, following the human-in-the-loop patterns I use elsewhere.
| Stage | What happens | Moves on when |
|---|---|---|
| Shadow | The pipeline reads, checks and codes every invoice alongside the clerks, who work as before. Differences are logged. | Field accuracy and coding agreement are known per supplier, and every exception it raised was a real one. |
| Prefilled queue | Clerks open each invoice with fields filled in and coding proposed, and correct instead of typing. | A supplier's invoices go through unedited for a run the controller agrees is long enough. |
| Touchless for matched POs | Invoices that pass every check and match PO and receipt within tolerance post without a clerk. | Granted per supplier. One correction after posting moves that supplier back a stage. |
| Invoices without a PO | Coding proposals go to the budget owner in Slack or Teams, who approves or corrects them. | Never fully automatic. The approval is the control. |
Is a capture tool enough, or does this need your ERP?
For a company with few purchase orders, buy. Dext and Hubdoc (which comes with Xero) capture invoices into Xero and QuickBooks; Candis, Moss, Pleo and Yokoy add approval flows and work well with DATEV in German-speaking markets; NetSuite and most accounting systems now have capture built in. If your invoices are mostly utilities, subscriptions and services approved by one person, one of these costs less than any build, and I will tell you so.
A custom build wins when matching needs data those tools cannot see: purchase orders and goods receipts in SAP Business One or an industry ERP, several legal entities sharing one AP inbox, approval rules that depend on plant, project or cost center, or a supplier base where half the invoices are e-invoices and half are scans. Mid-market AP suites such as Medius, Tipalti and Vic.ai do cover PO matching, but they are scoped for larger AP teams and usually mean moving the approval process into their product.
The hybrid is common. Keep the capture tool or the accounting system's own inbox for simple invoices, and build only the part that needs your ERP: the PO and goods receipt matching, the exceptions queue and the approval routing.
How you would know it is working
A blueprint has no results to report, so here is what I would measure from the first week instead, on your own data.
- Touchless rate by supplier
- Share of invoices posted with no field corrected, tracked per supplier, because an average hides the suppliers that always fail.
- Field correction rate
- Which fields clerks change in the queue (IBAN, net total, PO number). It shows where extraction or the supplier master is weak.
- Approval cycle time and discounts captured
- Receipt to final approval, alongside the share of early-payment discounts taken. In a German company with a works council, agree first what is reported per approver, since § 87(1) no. 6 BetrVG covers systems that can monitor performance.
- Exceptions by reason
- Price variance, missing goods receipt, unknown supplier, duplicate, bank detail change. Each reason has an owner outside AP, and the counts show who that is.
- Holds that were real
- Every duplicate and bank-detail hold, and whether it turned out to be genuine, so the checks stay trusted and nobody switches them off as noise.
What a build like this costs
This is built as AI Workflow Automation, which runs $3.5K - $60K overall. A build like this one usually lands in the multi-step workflow tier: $15K - $30K, 3-5 weeks. The first working version runs on your real data well before the end of that window.
What it costs to run
Reading a scanned invoice with a vision-capable model costs a few cents, more for long multi-page invoices, and e-invoices cost almost nothing because they skip the model. At 1,500 invoices a month, model usage is usually well below the cost of hosting and support. VIES lookups are free.
What moves the price
- Which system holds the purchase orders and goods receipts, and how open it is: the SAP Business One Service Layer and NetSuite REST are straightforward, an on-premise industry ERP may need a database connector
- How many legal entities, currencies and charts of accounts share the AP inbox
- The approval matrix: one limit per person, or rules by plant, cost center, project and category, with deputies
- How many invoices arrive without a PO and need coding proposals rather than matching
- Whether bank-detail verification should also cover supplier master changes made outside AP
Who this is for
- Manufacturers and distributors keying more than a thousand supplier invoices a month against purchase orders and goods receipts
- Companies on SAP Business One, NetSuite or an industry ERP whose capture tool cannot see the purchase order
- German companies whose bookkeeping ends up in DATEV, now receiving a mix of XRechnung, ZUGFeRD and scanned PDFs
- Bookkeeping firms processing supplier invoices for many clients, each with its own ledger and approval rules
- Finance leads who have had a bank-detail fraud attempt, or a near miss, and want the check to be systematic
Questions people ask about this
Can AI read supplier invoices accurately enough to post them?
Yes for the reading, as long as checks surround it. A vision-capable model extracts header fields and lines from almost any layout, but its output is never trusted on its own: every invoice passes arithmetic, VAT and duplicate checks in code and is compared with the purchase order and goods receipt. Posting without a person is switched on per supplier, only after its invoices have gone through the queue unedited for weeks.
How do I automate the accounts payable process without losing control?
Automate the reading, checking and routing, and keep the decisions. In this build the model extracts and proposes, code applies the tolerances and approval limits you set, and people approve, clear exceptions and release payments. Every check and approval is logged against the invoice, which gives an auditor more evidence than the manual process ever did.
What is three-way matching, and can it be automated?
Three-way matching compares the invoice with the purchase order and the goods receipt, so you pay only for what was ordered and actually arrived. It automates well because it is mostly rules: quantities against the receipt, prices against the PO, within tolerances you choose. The model's only job is pairing lines when the supplier's descriptions and your item numbers differ.
How does it stop fake bank details on invoices?
By comparing the IBAN on every invoice with the supplier master, not by judging how the email reads. Any difference holds the payment and creates a task to call the supplier on a number already on file, never one from the email or the invoice. The master record changes only after that call and a second person's approval.
Does it work with DATEV?
Yes. Where the bookkeeping runs through a tax adviser, approved invoices go to DATEV Unternehmen online with the document image and a booking proposal, so the adviser books from structured data instead of retyping. XRechnung and ZUGFeRD invoices keep their original XML, which GoBD requires you to archive unchanged.
What does invoice processing automation cost?
Expect the middle workflow automation tier in the cost section rather than the entry one, because matching against purchase orders is where the work is. The price moves with the system that holds your purchase orders, the number of entities sharing the inbox and the complexity of the approval rules. Running costs are small: a few cents of model usage per scanned invoice, and close to nothing for e-invoices.
Sources