SAP already contains a complete payables process. It has invoice verification, tolerance checks, payment blocks, workflow and a payment run, all built by people who thought hard about controls. What SAP does not have is a way to turn an arbitrary supplier PDF into a posting proposal with the right vendor, company code, purchase order reference and tax code. Automation on SAP is therefore almost entirely about the front end: producing a clean, correctly referenced document that SAP's own logic can then verify and post.
Reads digital PDFs, scans and phone photos. Exports to Excel, CSV and JSON.
Compare the extracted fields and line items against your own document.
Upload your invoices
Drop files here or click to upload
Up to 50 files
Uploading...
The core payables mechanics are more stable across releases than the marketing suggests. Invoice verification still runs through the MIRO transaction, three-way matching still compares the invoice against the purchase order and the goods receipt, and tolerance keys still decide what blocks.
What differs is the data model and the integration surface. S/4HANA consolidated vendor and customer master data into Business Partner, so the vendor you resolve against is a BP with an FI vendor role rather than a standalone LFA1 record maintained through XK01. The Universal Journal changed how postings are stored, though this matters more for reporting than for the act of posting an invoice.
The integration surface is the bigger practical difference. S/4HANA exposes OData services and offers cleaner API-based options, whereas ECC estates typically rely on IDoc and BAPI. Both work. The choice usually follows what your Basis team already supports rather than what is technically newest.
The first structural question is which door an invoice comes through, because SAP treats the two paths quite differently and an automation project that ignores the distinction will produce postings finance has to reverse.
PO-based invoices go through MM logistics invoice verification, the MIRO path. The invoice is entered against a purchase order, SAP matches it to the order and the goods receipt, applies tolerances, and posts to the GR/IR clearing account rather than direct to expense. The account assignment came from the purchase order at the time it was raised, so the invoice does not need coding at all. Which is precisely why PO discipline matters more than any capture technology.
Non-PO invoices post directly in FI, through FB60 or its equivalent. Here there is no order to match against and no account assignment waiting, so the invoice needs a G/L account, cost center or internal order, and a tax code, all decided by you rather than read off the document.
In most SAP estates both paths exist, and the split is worth measuring before anything else. A company where 85% of invoices are PO-based has a matching problem. One where 60% are non-PO has a coding and approval problem, which is a different project with a different cost.
SAP vendor master is segmented, general data, company code data and purchasing organization data, and an invoice can only post against a vendor that is properly extended to the company code in question. A Business Partner that exists but lacks the FI vendor role for that company code will fail at posting, which is a confusing error to debug from the outside.
Resolution from document to vendor should use the strongest identifiers available rather than the printed name. VAT or tax registration number is the best single signal in most countries, because it is stable, unique and printed on compliant invoices. Bank details from the remittance block are a strong secondary signal, and prior invoices from the same supplier settle most of the remainder.
Bank detail changes deserve special treatment. An invoice from a known supplier carrying bank details that differ from the vendor master is the classic payment-diversion fraud pattern. It should always raise an exception, never silently update the master record, and never be actioned on the strength of the document alone.
Tolerance keys are SAP's formalization of "how wrong can this be before a human looks at it", configured per company code with absolute and percentage limits, upper and lower.
They are one of the strongest arguments for keeping verification inside SAP rather than replicating it outside. The rules are already configured, already audited, and already consistent with how manually entered invoices are treated. An external system that applies its own tolerances and then posts a clean document to SAP has quietly bypassed a control.
The practical work is therefore not to reimplement tolerances but to reduce the blocks they generate. A blocked invoice sits in the payment block until someone resolves it in MRBR, and the common causes are mundane and fixable upstream.
If one intervention improves an SAP payables process more than any other, it is making sure the purchase order number reaches the invoice and is read correctly. Everything downstream depends on it: matching, account assignment, GR/IR clearing and the tolerance check.
Suppliers are inconsistent about it. The number appears in the header on one invoice, in a line-item column on another, prefixed on a third and quoted as a requisition or a contact name's reference on a fourth. Some send one invoice covering several purchase orders, which needs splitting into lines that reference the right order each.
Capture should therefore look for PO references across the whole document rather than one expected position, validate the candidate against open purchase orders in SAP rather than accepting anything that matches the number format, and hold the invoice as an exception when no valid order is found. Guessing a PO number is worse than not finding one.
There are three well-trodden routes into SAP for supplier invoices, and the right one depends on your landscape and who maintains it more than on technical merit.
IDoc is the classic asynchronous path. INVOIC02 is the standard inbound invoice message type, processed through the usual IDoc machinery, with errors landing in the IDoc monitor where support teams already know to look. It is well understood, robust and asynchronous. Which means the sender does not learn immediately whether the posting succeeded.
BAPIs give synchronous posting with an immediate result: BAPI_INCOMINGINVOICE_CREATE for logistics invoice verification, and the accounting document BAPIs for direct FI postings. You get the document number or the error message in the response, which makes exception handling considerably more direct.
OData services, in S/4HANA, offer the most modern route and fit cleanly with token-based authentication and cloud middleware. Where an estate already runs SAP Integration Suite or another middleware layer, the sensible answer is usually to hand documents to it and let it own the SAP conversation, because that keeps one integration governance model instead of two.
The defensible boundary in an SAP estate is narrower than in a small-business ledger, and that is a feature rather than a limitation.
Automation should own intake, capture, PO reference identification, vendor resolution, arithmetic and duplicate validation, coding proposals for non-PO invoices, and pre-posting approval where you want the document visible to a budget holder without an SAP login. SAP should keep invoice verification, tolerance checks, tax determination, the payment block, the payment run and the audit trail.
Systems that try to replace SAP's verification logic tend to be unwound within a year, usually after an audit finding. Systems that deliver clean, correctly referenced documents into MIRO or FI, and leave the controls where they were configured, tend to survive.
Yes, though the integration path differs. S/4HANA estates typically use OData services or BAPIs and resolve vendors as Business Partners with the FI vendor role. ECC estates more often use IDoc INVOIC02 or BAPI calls against classic vendor master. The capture and validation work in front is identical either way.
By the presence of a valid purchase order reference. Invoices that resolve to an open PO go through logistics invoice verification, where account assignment comes from the order and SAP performs the match. Invoices with no PO post as direct FI documents and need a G/L account, cost object and tax code, which is where coding rules and approval routing apply.
No, and it should not. A block is a control decision made by your tolerance configuration, and releasing it in MRBR is a judgement about whether a variance is acceptable. What automation can do is reduce how many blocks occur, by catching missing PO references, bad quantities and duplicates before the invoice is posted at all.
Tax determination stays in SAP, where it is configured per country and company code. Capture reads the tax amounts and rates stated on the invoice so they can be validated against what SAP calculates, and a mismatch becomes an exception rather than a silent override of your tax configuration.
Not necessarily. If your SAP workflow works and your approvers have access, keep it and let automation deliver clean documents into it. External approval is worth considering mainly when budget holders lack SAP licences or when approvers need to see the invoice document rather than a set of fields.
One-time vendor accounts carry the supplier details on the document rather than in master data, so capture needs to populate name, address and bank details on the posting itself. It is worth reviewing how much volume goes through one-time accounts, because a high share usually indicates master data that should be extended instead.
Accounts payable automation that reads every supplier invoice, matches it to your purchase orders, routes it for approval and posts it to your ledger. See how AP automation works end to end.
AP automation for NetSuite: creating vendor bill records, handling subsidiaries and multi-book accounting, deciding whether approvals live inside NetSuite, and three-way matching against NetSuite purchase orders.
Design an accounts payable approval workflow that clears invoices instead of stalling them: routing rules, thresholds, delegation, escalation and a defensible audit trail.
Invoice processing software for teams handling steady invoice volume: automatic capture, validation rules, exception queues and clean export to your accounting system.
An invoice OCR and data extraction API for developers: asynchronous job model, webhook and polling, JSON response shape, idempotency, error handling, rate limits and a sandbox environment.
Upload a few of your least tidy supplier invoices and compare the extracted fields against the documents. That tells you more than any feature list.
