# Invoice Processing Automation Explained > How invoice processing automation captures, validates, matches, and codes invoices, plus where EDI 810 and straight-through processing fit. Invoice processing automation captures an invoice, extracts its data, validates and matches it against the purchase order and receipt, codes it to the general ledger, routes it for approval, and archives it. Invoices that pass every check flow straight through without manual keying, while exceptions get flagged for review, cutting cost and cycle time per invoice. **Invoice processing automation is the capture-and-match core of accounts payable: it turns a supplier invoice into validated, matched, coded data ready for payment, without anyone typing it into the ERP.** If accounts payable automation is the whole invoice-to-pay pipeline, invoice processing is the engine room. Get this part right and everything downstream, approval and payment, gets easier. The problem it solves is familiar. An invoice lands as a PDF. Someone opens it, reads the amount, finds the PO number, keys it into the ERP, and hopes they did not fat-finger a digit. Multiply that by a few thousand invoices a month and you have a full-time job that produces errors, not value. ## The Steps in Invoice Processing Automation **Automated invoice processing runs six steps, and each one hands clean data to the next so the invoice never has to be re-keyed.** Here is the sequence. 1. **Capture.** The invoice enters through OCR or intelligent document processing (IDP) for PDFs and paper, or arrives already structured as an [EDI 810 invoice](/guides/edi/810-invoice). 2. **Validation.** The system checks the extracted data for completeness and sanity: valid supplier, non-duplicate invoice number, totals that add up. 3. **Matching.** The invoice is compared against the purchase order and the goods receipt. 4. **Coding.** Header and line amounts are assigned to general ledger accounts, cost centers, and tax codes. 5. **Approval.** Invoices that need sign-off route to the right approver by amount and department. 6. **Archive.** The invoice and its full audit trail are stored, searchable, and retention-compliant. The first three steps are where automation earns its keep. Capture removes the keying. Validation catches the duplicates and the math errors. Matching stops the overpayments. ### Capture: OCR, IDP, and LLM Extraction OCR reads text off a document. Intelligent document processing goes further, using models to understand which number is the invoice total versus a line amount versus tax, even when suppliers use wildly different layouts. Newer LLM-based extraction improves on both for line items, because it can reason about a table it has never seen before instead of relying on a trained template. This is the same extraction challenge OrderSync handles for inbound sales documents in [multi-format order processing](/multi-format-orders), where a single pipeline reads PDFs, emails, and spreadsheets. The quality of capture sets the ceiling for everything else. Bad extraction means bad matching, which means manual rework, which defeats the point. ### Validation and Matching Validation is the cheap check: is this a real, non-duplicate invoice with totals that reconcile? Matching is the expensive-to-get-wrong check. A PO-based invoice runs a [three-way match](/blog/three-way-match) against the purchase order and the goods receipt. If the invoice bills for 100 units, the PO ordered 100, and the receipt confirms 100 arrived, it clears. If any leg disagrees beyond tolerance, it is flagged. Microsoft's Dynamics 365 documentation describes invoice matching as comparing the vendor invoice to the purchase order and product receipt, with matching policies that hold an invoice when variances exceed the allowed tolerance ([Microsoft Dynamics 365 invoice matching](https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/accounts-payable-invoice-matching)). That hold-on-variance behavior is the whole point: the system stops the payment before it goes out, not after. ## Extraction Confidence: When to Route to a Human **Every extracted field carries a confidence score, and the threshold you set on it decides which invoices flow through untouched and which stop for review.** A sensible setup holds amount fields to a high bar, say 95% or better, and tolerates lower confidence on free-text fields like item descriptions. An invoice where every critical field clears its threshold proceeds to matching. One where the total reads at 80% confidence stops in a review queue with the extracted value pre-filled, so the reviewer confirms rather than re-keys. Two design mistakes show up constantly. The first is routing the whole invoice to a human because one low-stakes field scored low, which throws away most of the automation. The second is trusting a high confidence score on a field that is internally inconsistent, a line quantity that does not multiply out to the line total. That is why arithmetic checks belong alongside confidence checks: confidence says the model is sure, reconciliation says the numbers are coherent, and you need both before an invoice moves forward. ## Line-Pairing Failures: Invoice Lines That Do Not Match PO Lines **Price variances are the easy failures; the hard ones are invoices whose lines do not map one-to-one to PO lines.** Header-level matching passes and the line level falls apart. The recurring cases: - **Substitutions.** The supplier ships an equivalent SKU and the invoice carries a part number the PO never mentioned. The value matches, the item does not. - **Partial shipments.** One PO line arrives across three shipments and three invoices, each billing a fraction. The matcher has to accumulate billed quantity across invoices instead of comparing line to line. - **Freight, fuel surcharges, and allowances.** Lines on the invoice with no PO line at all. They need their own tolerance rules, or they block every invoice that carries them. - **Pack-size differences.** The PO ordered 10 cases of 24 and the invoice bills 240 eaches. Quantity matching has to normalize units of measure before comparing. A matching engine that only does exact line pairing will flag all of these as exceptions, and your reviewers end up re-doing arithmetic the system should have handled. ## Header Totals, Line Totals, and the Multi-Invoice PDF **A cheap self-check catches most extraction misses: the extracted lines, plus tax and freight, must sum to the extracted header total.** When they do not, the usual culprit is a dropped line at a page break, not a supplier error. Run that reconciliation before matching, and extraction problems surface as a single clear exception instead of a confusing PO mismatch. Multi-page invoices are where this earns its keep, since line tables continue across pages and repeated headers confuse naive extraction. The uglier case is the multi-invoice PDF: a supplier emails one file containing a dozen statements and invoices. The pipeline has to split the document before extracting, or invoice two's lines get glued onto invoice one and both totals stop reconciling. ## What Touchless Rate Actually Measures **Touchless rate is the share of invoices that go from arrival to approved-for-payment with zero human interactions, and the definition is strict: one click of "confirm" makes an invoice touched.** Vendor marketing often counts "auto-captured but human-reviewed" invoices as touchless, which inflates the number. Measure it honestly or it stops being useful. Straight-through invoices are the matched, in-tolerance, known-supplier ones. Everything else, price mismatches, missing PO references, new vendors, duplicate suspicions, routes to a reviewer. The measure of a good system is not that it eliminates exceptions, it is that it isolates them so they do not clog the clean invoices behind them. If your touchless rate is low, the fix is usually upstream: cleaner PO data, accurate goods receipts, and better supplier onboarding, not more AP headcount. To see how your rate compares within your industry, [APQC's process benchmarking](https://www.apqc.org/process-frameworks) publishes quartile data on AP process performance; treat any single published number with suspicion until you know what it counted as a touch. ## Invoice Processing vs Broader AP Automation **Invoice processing automation is the capture-and-match core; accounts payable automation is the wider process that adds payment, remittance, supplier management, and cash forecasting on top.** People use the terms interchangeably, but the scope differs. Invoice processing stops when the invoice is validated, matched, coded, and approved. [Accounts payable automation](/blog/accounts-payable-automation) continues into payment execution, electronic remittance via [EDI 820](/guides/edi/820-payment-order), discount capture, and vendor spend analytics. Think of invoice processing as the necessary foundation and AP automation as the full house built on it. The order matters. You cannot automate payment reliably until invoice data is clean and matched. Start with processing. ## Where EDI Changes the Picture **For trading partners on EDI, the invoice arrives as a structured 810 that skips OCR entirely, and matching runs against the original 850 purchase order and the receipt.** The document exchange is tight: you send the [EDI 850 purchase order](/guides/edi/850-purchase-order), the supplier ships and sends an ASN, then bills with the 810. Because the 810 is already structured, extraction accuracy is not a concern. The work shifts to matching and business-rule validation: line pairing, unit-of-measure normalization, and tolerance checks still apply. When an 810 fails your rules, you respond with an application advice, not just a syntactic acknowledgment. Validate any 810's structure with the [free EDI Inspector](/edi-inspector) before it reaches your matching engine. For the long tail of suppliers who will never do EDI, document extraction handles the PDFs and emails through the same pipeline, so one matching engine sees every invoice regardless of how it arrived. ## Frequently Asked Questions ### What is straight-through invoice processing? Straight-through processing means an invoice passes every automated check, capture, validation, matching, and coding, and reaches payment approval without a person touching it. It applies to clean invoices with a matched purchase order and receipt, a known supplier, and amounts within tolerance. Invoices that fail any check are routed out as exceptions instead. ### How accurate is OCR for invoice capture? In practice, template-based OCR commonly hits 80 to 90 percent field accuracy on clean invoices and degrades sharply on skewed scans, unusual layouts, and line items. Modern LLM-based extraction improves line-item accuracy considerably but still needs confidence-threshold review on critical fields. This is why validation and matching sit right after capture: they catch the misses before the invoice moves forward, so accuracy problems surface as exceptions rather than wrong payments. ### Is invoice processing automation the same as AP automation? No. Invoice processing automation is the capture, validation, matching, and coding core. Accounts payable automation is broader, adding payment execution, electronic remittance, discount capture, supplier management, and reporting. Invoice processing is the foundation you build AP automation on, and you generally implement it first. ### Can invoice processing automation handle non-PO invoices? Yes. Non-PO invoices, like utilities, subscriptions, and professional services, skip PO matching and rely on coding rules and approval routing instead. The system codes them to the correct GL accounts based on supplier and history, then routes them for approval by amount and department. They are handled as a distinct flow from PO-based matching. ### What happens to an invoice that fails matching? It is blocked from payment and routed as an exception to a reviewer with the invoice, PO, and receipt data in one view. The reviewer resolves the variance, corrects a receipt, confirms a price change, or rejects the invoice. Once resolved, it re-enters the flow. The block-on-variance behavior is what prevents overpayment.