# Accounts Payable Automation: How It Works > How accounts payable automation digitizes invoice capture, coding, matching, approval, and payment, and where EDI 810 and 824 fit the flow. Accounts payable automation digitizes the invoice-to-pay flow: capturing invoices with OCR, extracting data, coding to the general ledger, matching against the purchase order and receipt, routing for approval, and paying with electronic remittance. It removes manual keying so AP teams handle more invoices with fewer errors, faster cycle times, and captured early-payment discounts. **Accounts payable automation replaces the manual keying, paper routing, and email chasing that slow the invoice-to-pay cycle with a connected pipeline that captures, codes, matches, approves, and pays supplier invoices.** Most AP teams do not have a payment problem. They have a data problem. Invoices arrive as PDFs, paper, EDI files, and email attachments, and someone keys each one into the ERP by hand. Every keystroke is a chance for a wrong amount, a miscoded GL account, or a duplicate payment. This guide walks through how AP automation actually works, step by step, and where electronic documents like the EDI 810 invoice and EDI 824 application advice fit in. ## What Accounts Payable Automation Does **AP automation digitizes every stage between receiving a supplier invoice and sending payment, so invoices flow through validation and approval without manual data entry.** Rather than a single feature, it is a chain of connected steps that each remove a manual handoff. The core stages look like this: 1. **Capture** the invoice through OCR or intelligent document processing, or receive it as structured EDI. 2. **Extract** header and line data: supplier, invoice number, PO number, amounts, tax, line items. 3. **Code** the invoice to the right general ledger accounts and cost centers. 4. **Match** it against the purchase order and the goods receipt. 5. **Route** it for approval based on amount, department, and policy. 6. **Pay** the supplier and send electronic remittance. The prize is "touchless" invoice processing, where an invoice moves from capture to payment approval without anyone keying or clicking. Not every invoice qualifies, but the ones that do free your team to work the exceptions that actually need judgment. On cost, manual invoice processing is commonly cited in the $10 to $15 per-invoice range once labor, rework, and exception chasing are counted, while automated processing lands closer to $2 to $4. Treat those as directional ranges rather than precise figures; for quartile data by industry and revenue band, [APQC's process benchmarking](https://www.apqc.org/process-frameworks) is the standard source. The gap between the two columns below is almost entirely manual effort and rework: | Measure | Manual AP | Automated AP | |---|---|---| | Cost per invoice | Commonly cited $10 to $15 | Commonly cited $2 to $4 | | Cycle time | Weeks from receipt to approval | Days, often same-day for clean PO-backed invoices | | Touchless rate | Near zero | A meaningful share of matched invoices clears with no touches | | Exception handling | Mixed into the queue with everything else | Isolated and routed to a reviewer with full context | ## The Invoice-to-Pay Flow, Step by Step **Each stage of AP automation hands clean, validated data to the next, which is what makes straight-through processing possible.** Here is what each step does. ### Capture and Data Extraction Paper and PDF invoices go through OCR or intelligent document processing, which reads the document and pulls structured fields. Good extraction handles the messy reality of supplier invoices: different layouts, line items that wrap, tax lines, and freight charges. This is the same document-extraction problem OrderSync solves on the sell side with [AI-powered order automation](/ai-order-automation), applied to inbound invoices. For trading partners set up on EDI, the invoice arrives as an [EDI 810 invoice](/guides/edi/810-invoice), already structured. No OCR needed. You can check the segments in any 810 with the [free EDI Inspector](/edi-inspector) before it hits your ERP. ### GL Coding Once data is extracted, the invoice needs to be coded to the correct general ledger accounts, cost centers, and tax codes. Automation applies rules and learns from history: this supplier's invoices usually code to this account, this PO carries this cost center. Non-PO invoices, like utilities or subscriptions, lean hardest on coding rules because there is no PO to match against. ### Matching This is the control that stops overpayment. A PO-based invoice gets matched against the purchase order and the goods receipt, a [three-way match](/blog/three-way-match) that confirms you were billed for what you ordered and what you actually received. When the invoice, PO, and receipt agree within tolerance, the invoice clears for payment automatically. Matching depends on receiving data being captured accurately, which is why the [goods receipt process](/blog/goods-receipt-process) is the quiet middle leg that most AP problems trace back to. No receipt, no match, stuck invoice. Some buyer-supplier pairs skip the supplier invoice entirely: under [self-billing and ERS](/blog/self-billing-ers-explained), the buyer generates the invoice from the PO and receipt and simply pays it, which removes the third leg instead of matching it. ### Approval Routing Matched invoices still need sign-off. Automated routing sends each invoice to the right approver based on amount thresholds, department, and budget, with escalation for larger spend. This mirrors the [purchase order approval workflow](/blog/purchase-order-approval-workflow) on the buying side, and the same segregation-of-duties rules apply: the person who approves the invoice should not be the person who cut the PO. ### Payment and Remittance Approved invoices move to payment: ACH, virtual card, check, or wire. For EDI trading partners, payment and remittance travel as an [EDI 820 payment order](/guides/edi/820-payment-order), so the supplier's AR team can auto-apply the cash. Clean remittance data is what lets both sides reconcile without a phone call. ## Where EDI Fits Accounts Payable **On the AP side, EDI carries two distinct signals: the supplier's invoice (810) and your business-rule response to it (824), and confusing the 824 with the 997 is a common mistake.** The 997 functional acknowledgment only confirms that a file arrived and was syntactically valid. It says nothing about whether the invoice passed your business rules. The [EDI 824 application advice](/guides/edi/824-application-advice) is different. It reports application-level acceptance or rejection: the invoice referenced a PO you do not recognize, the price does not match the contract, the quantity exceeds what was received. A 997 means "we got your file." An 824 means "we read your invoice and here is what our system thinks of it." Here is how the pieces line up on a PO-based purchase: | Document | Direction | What it carries | |---|---|---| | EDI 850 | You to supplier | The purchase order | | EDI 856 | Supplier to you | Ship notice (ASN) for the shipment | | EDI 810 | Supplier to you | The invoice | | EDI 824 | You to supplier | Business-rule accept or reject of the invoice | | EDI 820 | You to supplier | Payment order and remittance | Getting these right is the difference between a clean [procure-to-pay process](/blog/procure-to-pay-process) and an AP inbox full of exceptions. Wiring these documents into your ERP through [ERP integration](/erp-integration) is what keeps the 810-to-payment flow touchless. SAP's invoice verification documentation walks through how logistics invoice verification blocks an invoice when price or quantity falls outside tolerance ([SAP logistics invoice verification](https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE)), which is the ERP-side mirror of the 824 you send back. ## What Changes When You Automate **The measurable wins from AP automation are lower cost per invoice, shorter cycle time, fewer duplicate payments, and more captured early-payment discounts.** Manual AP loses discounts because invoices sit in approval limbo past the discount window; automated routing surfaces the 2/10 Net 30 invoices in time to actually take the 2%. Duplicate payments drop because the system flags a second invoice with the same number before it gets cut, not after. And every capture, code, match, and approval is timestamped, which is the audit trail email-based AP can never produce. For the capture-and-match core specifically, see [invoice processing automation](/blog/invoice-processing-automation), and compare tools in our guide to [invoice automation software](/blog/invoice-automation-software). ## Frequently Asked Questions ### What is touchless invoice processing? Touchless invoice processing means an invoice moves from capture through to payment approval without a person keying or manually reviewing it. The invoice is captured, extracted, coded, matched against the PO and receipt, and approved by rules. Only invoices that fail matching or exceed thresholds get routed to a human, which is exception handling rather than routine processing. ### What is the difference between an EDI 824 and a 997? The EDI 997 functional acknowledgment is syntactic. It confirms a file was received and structurally valid, nothing more. The EDI 824 application advice is a business-rule response: it reports whether the invoice passed application-level checks like PO matching, pricing, and quantity. You can receive a 997 accepting the file and still send back an 824 rejecting the invoice's contents. ### Do I need EDI to automate accounts payable? No. AP automation works for PDF, paper, and email invoices through OCR and intelligent document processing. EDI 810 invoices simply arrive already structured, so they skip the capture-and-extract step. Most mid-market AP teams run a mix: EDI with their largest suppliers and document extraction for the long tail of smaller vendors. ### How does three-way match fit into AP automation? Three-way match is the core validation control in PO-based AP. The system compares the invoice against the purchase order and the goods receipt. When all three agree within tolerance, the invoice clears for payment automatically. When they disagree, the invoice is blocked and routed for review. Accurate goods receipt data is what makes automated matching possible. ### What is the first step to automating accounts payable? Start with invoice capture and matching, because that is where the manual keying and the duplicate-payment risk live. Get invoices into structured data, whether through EDI 810 or document extraction, then match them against POs and receipts. Payment automation and remittance come next once the front of the pipeline is clean.