The AP invoice processing workflow is the path a supplier invoice takes from arriving in accounts payable to being paid and reconciled: receive, capture, validate, match, code and approve, handle exceptions, schedule and pay, then reconcile and archive. Invoice processing automation is software doing that work, so people only see the invoices that fail a check. Most of a working system is plain rules: matching, tolerances, approval limits and duplicate checks. Machine learning and language models earn their place at the reading step and in sorting out exceptions. Below are the eight steps, with what to automate and the control that keeps each one safe. After that: where OCR, document AI and language models fit, the controls finance teams need, what the e-invoicing mandates in Germany, Belgium and France change, and a metrics table and readiness checklist.
The AP invoice processing workflow, step by step
Every accounts payable team runs some version of the same eight steps, by hand or by software.
- Receive. Invoices arrive as PDF attachments to an AP inbox, uploads to a supplier portal, paper scans, or structured e-invoices over Peppol or email. Automation starts with one intake point: a dedicated mailbox or alias, plus a Peppol access point if you trade where e-invoices are mandatory.
- Capture. Every file is stored and given an ID, then read into fields: supplier, invoice number, dates, currency, totals, tax, PO number, bank details and line items. A structured e-invoice is parsed directly. A PDF or scan goes through document AI or a language model.
- Validate. The fields are checked on their own: the supplier exists in the vendor master, the lines add up to the subtotal, tax and total reconcile, the dates make sense, the currency and bank details match the supplier's record, and the invoice is not a duplicate.
- Match (two-way or three-way). For PO-backed invoices, the invoice is compared with the purchase order (two-way) or with the purchase order and the goods receipt (three-way), within tolerances your controller sets.
- Code and approve. Non-PO invoices, such as utilities, software subscriptions and professional fees, get a GL account, cost centre, project and tax code, usually from the supplier's history. The invoice goes to the budget owner or PO requester, with thresholds that escalate larger amounts and a second approver above a limit. Once approved, a bill is posted to the accounting system or ERP with the original file attached.
- Handle exceptions. Anything that fails a check goes to a queue with the reason attached: missing PO, price or quantity variance, unknown supplier, changed bank details, suspected duplicate. A person decides, and the system records the decision.
- Schedule and pay. Approved bills go into payment runs by due date and payment terms, taking early-payment discounts where they are worth it. Someone other than the approver releases the run, usually from the ERP or a payments tool.
- Reconcile and archive. Payments are matched to bank statement lines and the bill is closed. The original invoice, the extracted data, every check and every approval are kept together for the auditor, for as long as your tax rules require.
| Step | What happens | What to automate | The control that keeps it safe |
|---|---|---|---|
| Receive | Invoices arrive by email, portal, post or Peppol | One mailbox or alias, a Peppol access point, an ID per file | Every file is logged before anything reads it, so nothing is lost or read twice |
| Capture | Fields and line items become data | Parse e-invoice XML directly; document AI or a language model with a fixed schema for PDFs | Confidence thresholds per field; low-confidence fields go to a person |
| Validate | Fields are checked against the vendor master and the arithmetic | Rules in code for supplier, totals, tax, dates, currency and duplicates | Bank details that differ from the vendor master hold the invoice, whatever its confidence score |
| Match | Invoice is compared with the PO, and with the receipt for three-way | Rules with price and quantity tolerances | Tolerances set in writing by the controller; anything above them goes to the queue |
| Code and approve | GL coding, approval routing, posting the bill | Coding from supplier history, routing rules, posting through the ERP's API | Approval limits, a second approver above a set amount, idempotent writes so a retry cannot post twice |
| Exceptions | Failed checks wait for a decision | A queue with the reason and a suggested fix | A named owner; a person makes every decision and the reason is recorded |
| Schedule and pay | Approved bills go into payment runs | Runs by due date and terms, discount capture | The approver cannot release the payment; bank detail changes are verified by phone on a known number |
| Reconcile and archive | Payments are matched to the bank and records are kept | Bank feed matching; storing the file, data and audit trail together | Unmatched items reviewed before month-end close; any posted bill can be traced to the file it came from |
Two-way and three-way matching
Two-way matching compares the invoice with the purchase order: same supplier, same items, prices and quantities within tolerance. Three-way matching adds the goods receipt, so you only pay for what actually arrived. Tolerances are a policy choice, typically a percentage and an absolute amount on price and on quantity, and they belong to your controller, not to whoever builds the automation. Partial deliveries, back-orders and freight lines that never appeared on the PO are where most variances come from, so test those cases first.
Check what your system already does, and what it does not enforce. In Odoo's purchase documentation, turning on 3-way matching adds a Should Be Paid field to bills with the values Yes, No and Exception, and a bill whose draft is edited becomes Exception. Odoo says it notices the discrepancy but does not block the change or show an error, so your process has to decide what happens to an Exception before payment. In NetSuite, Oracle's Bill Capture page says 3-Way-Match, approval workflows and SuiteApprovals carry on as configured in the account and are not part of Bill Capture. Capture and matching are separate pieces, and both need to be set up.
OCR, document AI and language models: what each one does
These three get blurred in vendor copy. They do different jobs.
- OCR turns an image of a page into text. On its own it does not know which number is the total.
- Document AI (also sold as intelligent document processing, or IDP) adds models trained on invoices that return named fields. Amazon's Textract AnalyzeExpense returns standard fields such as vendor name, invoice ID, PO number, totals, tax and line items, each with a confidence score. Microsoft's Document Intelligence invoice model (prebuilt-invoice, v4.0 GA) covers invoices, utility bills, sales orders and purchase orders in 27 languages. Both checked on 10 November 2026.
- Language models read the document the way a person would. They cope better with unusual layouts, several invoices in one PDF, credit notes that look like invoices, and free-text notes such as "partial shipment, balance next week". They can also map a supplier's line descriptions to your own item codes and GL accounts, which fixed templates cannot.
A model told to return JSON in a fixed schema will usually do so. The Claude API's structured outputs, for example, constrain responses to a schema and say they comply in most cases, with refusals and token limits as the stated exceptions. A valid schema does not make the values right. A model can return a well-formed invoice total that is wrong, so every extracted value still goes through the checks in step 3.
Where rules still win: matching, tolerances, arithmetic, tax calculation, duplicate detection, approval limits and posting. They are deterministic, cheap, easy to audit and easy to explain to an auditor. A language model should never be the thing that decides whether an invoice gets paid. It reads, suggests and explains; code checks and people approve.
| Task | Best fit | Why |
|---|---|---|
| Reading standard invoices from regular suppliers | Document AI | Fast, cheap per page, field-level confidence |
| Reading messy, multi-invoice or unusual documents | Language model with a fixed schema | Handles layouts no template covers |
| Suggesting GL codes for non-PO invoices | Supplier history first, model for new cases | History is right most of the time and explainable |
| Matching to PO and receipt | Rules | Has to be exact and auditable |
| Explaining a variance to the approver | Language model | Turns three records into one sentence |
| Reading supplier emails about disputes or partial deliveries | Language model | Free text, no fixed format |
| Approving payment | A person, or a rule below a set limit | Accountability stays with finance |
If you want the general pattern behind this split, our guide to agentic workflows uses invoice extraction as its prompt-chaining example, and rules-based automation vs AI agents covers when each is the right tool.
Accuracy and controls
Automating AP moves the risk from typing errors to systematic errors, which repeat on every invoice until someone notices. These controls catch them.
Confidence thresholds and human review
Set thresholds per field, not one number for the whole invoice. A wrong description line costs little; a wrong total, invoice number or bank account costs a lot. To set them, run the extraction on a few hundred past invoices where you already know the right answer, measure field-level accuracy at different thresholds, and pick the point where errors that pass review are rare enough for your controller. Re-run that test whenever you change the model, prompt or supplier mix.
The review screen matters as much as the threshold. Show the original document next to the extracted fields, highlight the low-confidence ones, and record what the reviewer changed. Those corrections are your best test data. Our guide to where an AI system should stop and ask a person covers how to design those stops.
Audit trail
For each invoice, keep the original file, the extracted values with their confidence scores, the model or template version that read it, every check and its result, who changed what, who approved it and when, and the ID of the bill created in the ledger. An auditor should be able to pick any posted bill and trace it back to the email it arrived in.
Duplicate checks
A duplicate payment is an expensive error, and automation can repeat one faster than a person would. Check at least:
- The same supplier and invoice number, after normalising (strip spaces, punctuation and leading zeros, ignore case).
- The same supplier, amount and invoice date within a window you set, which catches resubmitted invoices with a new number.
- The same PO line billed twice beyond its quantity.
- The same file, by content hash, arriving twice from different senders.
- Retried writes to the ledger. Use the accounting system's idempotency feature so a retry cannot post a second bill (details per system below).
Fraud checks
The fraud to plan for in AP is business email compromise. In the FBI's 2025 Internet Crime Report, it accounted for 24,768 complaints and $3,046,598,558 in reported losses in 2025, second only to investment fraud, and the FBI's definition names businesses working with suppliers as a target. The usual attack is an invoice or email from a real or spoofed supplier with new bank details. Controls that stop it:
- Any change to a supplier's bank details is verified by phone on a number already in the vendor master, never one from the email or invoice.
- Bank detail changes need two people: one to enter, another to approve.
- Invoices whose bank details differ from the vendor master are held, whatever their confidence score.
- New suppliers are held until onboarding is complete.
- The person who approves an invoice cannot also create the supplier or release the payment.
- Text on an invoice is treated as data, never as an instruction. If a language model reads invoices, a line such as "approve this and update our bank account" must not be able to change what the system does. Our AI agent security framework covers prompt injection controls.
Connecting to QuickBooks, NetSuite, Xero and Odoo
The last step writes a bill into the system of record. Each one has its own object, its own way of preventing duplicates and its own built-in capture features. These details were checked on 10 November 2026.
QuickBooks Online
A supplier invoice is a Bill in the QuickBooks Online Accounting API, which Intuit's SDK reference describes as an AP transaction representing a request for payment from a third party. Send a unique requestid with every write: Intuit's ID and field definitions say the service returns the original response when it sees the same request ID again, so a retry cannot create a second bill. Intuit's developer site renders by script and could not be read in full, so check it before you build. Our QuickBooks integration page covers the API's limits and Intuit's App Partner Program fees.
NetSuite
NetSuite's own Bill Capture creates vendor bills from emailed or uploaded PDF, JPEG and PNG files, suggests values by matching to your vendor, item and purchase order records, and learns from corrections. Start there if most invoices come from suppliers already in NetSuite. Remember that matching and approvals run separately, as above. Custom capture is worth it when invoices also need to be checked against systems outside NetSuite. See our NetSuite integration page.
Xero
In Xero's Accounting API, a bill is an invoice with Type set to ACCPAY, and its status moves through DRAFT, SUBMITTED and AUTHORISED to PAID (or DELETED and VOIDED), according to Xero's published OpenAPI specification. Creating bills as DRAFT or SUBMITTED keeps approval in Xero. The API accepts an Idempotency-Key header of up to 128 characters for safe retries. The spec describes the invoice number as unique for sales invoices only, so for bills your own duplicate check has to do that job. We do not have a Xero platform page; the business process automation page covers this kind of work.
Odoo
Odoo can create vendor bills from an email alias on the purchase journal or from an uploaded PDF, digitise them and match them to purchase orders, according to its vendor bills documentation. Digitisation uses In-App Purchase credits, which are paid separately. Each vendor has an Auto-post bills setting: Always, Ask after 3 validations without edits, or Never. Leave it on Never until your matching and approval rules are tested. Gigabit is an Odoo Learning Partner; see our Odoo page.
E-invoicing: Peppol, XRechnung and what's mandatory
Most of this guide assumes invoices arrive as PDFs that something has to read. In a growing number of European countries, B2B invoices are now structured data by law, which changes the receive and capture steps. The dates below were checked on official sources on 10 November 2026. This is a summary, not tax advice: confirm what applies to each of your entities with your adviser.
What Peppol BIS Billing 3.0 is
Peppol is a network for sending business documents between registered access points, so a supplier's system can deliver an invoice straight into yours without email. Its invoice format, Peppol BIS Billing 3.0, describes itself as a Core Invoice Usage Specification (CIUS) of EN 16931, the European e-invoicing standard, and is written in UBL. The current documentation is the May 2026 release, and Peppol publishes Schematron validation rules alongside it, so a receiving system can check an invoice before it reaches the ledger.
Germany: receiving since 2025, issuing from 2027
Every business in Germany has had to be able to receive e-invoices from other domestic businesses since 1 January 2025. There is no transition period for receiving, and a PDF sent by email no longer counts as an e-invoice, according to the IHK Stuttgart's summary of the Federal Ministry of Finance guidance. Issuing is phased by section 27(38) of the VAT Act: paper and other formats are still allowed for supplies in 2025 and 2026; in 2027 only for businesses whose total turnover in the previous year was no more than €800,000, or for EDI with the recipient's agreement. From 1 January 2028 every domestic B2B invoice must be an e-invoice.
Section 14 of the VAT Act defines an e-invoice by its format, a structured format that follows EN 16931, not by how it is sent. Two formats cover most of what German suppliers send:
- XRechnung is Germany's CIUS of EN 16931, run by KoSIT on behalf of the IT-Planungsrat, in UBL or UN/CEFACT CII syntax. Version 3.0 is in force and stays valid until at least 31 July 2027; a 4.0 preview was published in September 2026 (XRechnung).
- ZUGFeRD is a hybrid: a PDF/A-3 file a person can read, with the structured invoice embedded as CII XML (FeRD). The current version is 2.5.2, and the ministry's guidance accepts ZUGFeRD from version 2.0.1. FeRD says the PDF and the XML must match and advises senders to check that they do. Your system should read the XML and check it too.
Belgium: mandatory since 1 January 2026
Since 1 January 2026, Belgian VAT-registered businesses have had to use structured electronic invoices with each other, exchanged over Peppol, and a PDF by email or through a platform is no longer enough, according to the government's e-invoicing site. Businesses that sell only to consumers still have to be able to receive them. A tolerance period covered January to March 2026: no penalties for businesses that showed they had acted in a timely and reasonable way, judged case by case and not a general postponement. That period is over.
France: receiving since 1 September 2026
France's reform started on 1 September 2026. Since then every business must be able to receive e-invoices, and large and mid-sized companies (grandes entreprises and ETIs) must issue them. Small and medium businesses and micro-businesses must issue from 1 September 2027, according to Service Public. Invoices are sent and received through a plateforme agréée, an operator registered by the tax administration that also passes invoice and payment data to it (impots.gouv.fr). The administration's notice of 28 September 2026 describes the first phase as in force.
What an automated AP workflow must do to accept structured invoices
- Receive on every channel your suppliers use. A Peppol access point, often supplied by your ERP or an e-invoicing provider; a plateforme agréée for French entities; and the existing mailbox for XRechnung and ZUGFeRD files sent by email.
- Detect the format before reading. Tell UBL, CII and hybrid PDFs apart, and pull the XML out of a ZUGFeRD file instead of sending the PDF to OCR.
- Validate the XML. Check it against the schema and the published business rules, such as Peppol's Schematron files, and record the result in the audit trail. A file that fails is not a valid e-invoice and goes back to the supplier with the reason.
- Map fields without a model in between. Supplier tax ID, order reference, line items and payment details arrive as named elements, so map them straight to the vendor master and the PO. Keep the language model for free-text notes.
- Keep the XML as the original. The structured data is what makes it an e-invoice, so archive the XML with the audit trail and give approvers a rendered view.
- Run every other check anyway. A well-formed XML invoice can still be a duplicate, priced wrong or carry new bank details from a fraudster. Validation, matching, duplicate and bank-detail controls apply unchanged.
- Report structured and PDF invoices separately in the metrics below. Structured invoices skip the reading step, so mixing them in flatters the touchless rate.
Build, buy or switch on what you have
There are four routes, and many teams combine two.
| Route | What it is | Fits when | Watch for |
|---|---|---|---|
| Built-in capture in your ERP or accounting system | NetSuite Bill Capture, Odoo digitisation, and whatever your QuickBooks or Xero plan includes | Most suppliers are already set up, volume is moderate, the rules are standard | Matching and approvals may need separate set-up; per-document credits |
| Dedicated AP automation software | Packaged products covering capture, approvals and often payments | You want a finished product with a supplier portal, and your rules fit its options | Per-invoice or per-user pricing, another login, how it posts to your ledger |
| Document AI services | Cloud extraction APIs such as Textract and Azure Document Intelligence | You have engineers and want the extraction step only | You still build validation, matching, review and posting |
| Custom workflow | Your own pipeline on n8n or code, with document AI or a language model for reading | Invoices must be checked against several systems, rules are unusual, or exceptions need a lot of reading | You own maintenance, monitoring and model changes |
Start with what you already pay for. If your ERP's capture handles most of your suppliers and your approvers live in the ERP, switch it on and fix the vendor master first. A custom build is worth it when the work crosses systems, for example invoices checked against a warehouse system and a project tracker, or exceptions that need someone to read supplier emails. No AP software prices are given here, because we did not read them on vendor pages for this guide.
Metrics: what to measure and how
Measure your own baseline for four weeks before you change anything. Published industry benchmarks are hard to compare because each survey defines "cost" and "touchless" differently, so this guide does not quote any.
| Metric | Definition | How to measure |
|---|---|---|
| Cost per invoice | AP staff time per invoice times loaded hourly cost, plus software and per-document fees, divided by invoices processed | Time a sample of invoices end to end, or divide AP hours in a month by invoices posted |
| Touchless rate | Share of invoices posted with no human edit or decision before approval | Count invoices with zero edits in the audit trail. Report PO and non-PO separately |
| Cycle time | Time from receipt to approved bill, and to payment | Timestamp at intake and at each status change; report median and 90th percentile |
| Exception rate by reason | Share of invoices sent to the queue, split by cause | Tag every exception with one reason code |
| First-pass match rate | Share of PO invoices that match within tolerance on the first try | Matching log |
| Field-level accuracy | Share of extracted fields that a reviewer did not change, for each important field | Compare extracted values with final posted values |
| Duplicates caught | Number of duplicate invoices stopped before posting, and any found after payment | Duplicate-check log, plus a quarterly search of paid bills |
| Early-payment discounts captured | Discounts taken against those offered | Supplier terms against payment dates |
Watch cycle time and exception reasons more than touchless rate. A high touchless rate with rising duplicates or late approvals is worse than a lower one that is clean.
Readiness checklist
Work through this before you buy or build. The process and data groups take the longest to put right, so start there.
Process - The AP process is written down, including who approves what, at which amount, and who can override. - Match tolerances for price and quantity are set by the controller, in writing. - There is a rule for every non-PO invoice type: utilities, subscriptions, contractors, expenses. - The team agrees what happens to each exception type, and who owns the queue. - Month-end cut-off rules for invoices received but not yet approved are written down.
Data - The vendor master is clean: no duplicate suppliers, current bank details, tax IDs and payment terms filled in. - Purchase orders are raised before the purchase, not after the invoice arrives. - Goods receipts are recorded in the system when goods arrive, if you want three-way matching. - You can export six to twelve months of past invoices with their final posted values, to use as a test set. - You know your monthly invoice volume, the share with a PO, and your top suppliers by count.
Systems - Invoices arrive at one inbox or alias, or can be redirected there. - Your accounting system or ERP has an API you can be given access to, with a user that has only the rights needed to create bills. - You have checked what bill capture your accounting system already includes. - There is a test or sandbox company to build against.
Controls - Bank detail changes are verified by phone on a known number and approved by a second person. - The duplicate checks listed above are defined. - Approvers cannot create suppliers or release payments. - The audit trail fields are agreed with your auditor or accountant. - Confidence thresholds will be set from a test on your own past invoices, not from a vendor's claim.
People - One person in finance owns the automation and signs off changes. - Reviewers have time set aside for the exception queue in the first months. - Suppliers will be told about the new intake address and asked to send PDFs, not photos.
Where Gigabit fits
Gigabit builds invoice and finance workflows as part of business process automation: capture into one intake, extraction with document AI or a language model, validation and matching in code, a review queue, and posting to QuickBooks, NetSuite, Xero or Odoo, with logging and retries. One workflow with up to three tool integrations is the AI Quick Win Sprint, $8,000 fixed over 3 weeks, with 30 days of support. An agent that works the exception queue, reads supplier emails and drafts the fix for a person to approve is a flat fee from $8,000 on our AI agents page. If you are not sure AP is the right place to start, the AI Transformation Sprint ($25,000, 2 weeks) ranks your workflows by payback and ends in a deployed pilot. Larger programmes run on an embedded team at $3,000–$7,500 per engineer per month, and monitoring after launch is Managed AI Operations at $3,000–$20,000 a month.
The closest published build is our e-commerce operations case: five automations for a $28M multi-channel retailer, including vendor follow-up that parses supplier reply emails into structured ship dates and tracking numbers, and an exception router that keeps a human approval in the loop. Weekly manual hours across the five fell from 32 to 4.5.
If your ERP's own capture covers your suppliers and your volume is modest, you do not need us. Switch it on, clean the vendor master and set the controls above.
