Invoice processing automation is software doing the accounts payable work between a supplier invoice arriving and it being posted, approved and ready to pay. It captures the invoice from email or upload, reads the supplier, amounts and line items, checks them against the purchase order and the goods receipt, routes it to the right approver, and posts a bill to your accounting system or ERP. 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. This guide walks through each step, says where OCR, document AI and language models fit, sets out the controls finance teams need, and ends with a metrics table and a readiness checklist.
The AP invoice workflow, step by step
Every accounts payable team runs some version of the same eight steps, whether by hand or by software.
- Capture. Invoices arrive as PDF attachments to an AP inbox, uploads to a supplier portal, paper scans or e-invoices. Automation starts with one intake point: a dedicated mailbox or alias, with every file stored and given an ID before anything reads it.
- Extraction. The supplier, invoice number, dates, currency, totals, tax, PO number, bank details and line items are read from the document into structured fields.
- Validation. 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 matches the supplier's, and the invoice is not a duplicate.
- Matching. 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.
- Coding. 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.
- Approval routing. The invoice goes to the budget owner or PO requester, with thresholds that escalate larger amounts and a second approver above a limit.
- Posting. An approved bill is created in the accounting system or ERP, with the original PDF attached and a link back to the source.
- Exceptions. Anything that fails steps 2 to 6 goes to a queue with the reason attached: missing PO, price or quantity variance, unknown supplier, changed bank details, suspected duplicate. Payment runs and bank reconciliation follow, usually in the ERP's own tools.
| Step | What automates it | Where a person stays |
|---|---|---|
| Capture | Mailbox or alias, file storage, ID per document | Paper post, until suppliers move to email |
| Extraction | Document AI or a language model with a fixed output schema | Low-confidence fields |
| Validation | Rules in code against the vendor master and the ledger | Unknown suppliers, failed arithmetic |
| Matching | Rules: PO, receipt, tolerances | Variances above tolerance |
| Coding | Supplier history, then a model suggestion for new cases | First invoices from a new supplier |
| Approval | Routing rules and limits | Every approval above your auto-approve limit |
| Posting | The accounting system's API | Nobody, if the steps above passed |
| Exceptions | A queue with the reason and a suggested fix | The decision |
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 24 October 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 24 October 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 Partner; see our Odoo page.
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.
