What is the accounts payable automation process, and how do you design it?
Short answer
The accounts payable automation process is the set of rules that moves each supplier invoice from arrival to payment, stops it only when a rule fails and sends each stop to its owner.
Key takeaways
- The accounts payable automation process is a chain of rules. Each step takes an input, applies a rule, and either passes the invoice on or stops it with a reason.
- Design the process by invoice type, not as one flow. A goods invoice on a purchase order, a service invoice, a non-PO utility bill and a credit note need different checks.
- Every stop needs an owner outside accounts payable where the cause sits: the buyer for a price, the receiver for a quantity, the supplier data team for bank details.
- Write every rule in one register, with its value, its owner, the date it was approved and the date it will be reviewed. A rule nobody owns is a control nobody runs.
- Test the process with invoices that should fail, not only with invoices that should pass: duplicates, prices over tolerance, invoices that arrive before the goods.
What is the accounts payable automation process?
The accounts payable automation process is the sequence of automatic steps that takes a supplier invoice from arrival to payment: intake, data capture, validation, matching, approval, payment and posting. At each step a rule decides. If the rule passes, the invoice moves on with no one touching it; if it fails, the invoice stops and goes to one named owner.
Take an invoice for 200 safety helmets that arrives before the warehouse has recorded the delivery. In a manual process, a clerk puts it on a pile and checks again next week. In a designed automated process, the invoice waits in a status called “awaiting receipt”, the system tries the match again when the receipt is recorded, and after a set number of days it asks the person who ordered the helmets to confirm the delivery.
This page is about designing that process: the decisions at each step, the routes, the exception owners, the rules and the tests. What accounts payable automation is, its technologies, benefits and measures are explained in accounts payable automation. The manual steps of handling an invoice are in invoice processing, tolerances in three-way match, and tool selection in accounts payable automation software.
What does each step of the automated process decide?
Each step of the automated accounts payable process answers one question about the invoice. The table gives the question, the data the step needs, the condition that stops the invoice and who receives it. Use it as a checklist when you map your own process.
| Step | Question the rule answers | Data the rule needs | Stops the invoice when | Stop goes to |
|---|---|---|---|---|
| Intake | Did the invoice arrive through an agreed channel, for one of our entities? | List of channels, entity names and tax numbers | Wrong entity, unreadable file, several invoices in one file | Accounts payable |
| Capture | Are the supplier, number, dates, amounts and lines read correctly? | Structured e-invoice, or a PDF read by capture software with a confidence level per field | A field is missing or read with low confidence | Accounts payable (data check) |
| Validation | Does the invoice carry the content the law and our policy require? | Supplier record, tax rules, mandatory invoice details | Missing tax number, wrong tax rate, inactive or blocked supplier | Accounts payable; supplier data team for blocked suppliers |
| Duplicate check | Have we already received this invoice? | Supplier, invoice number, date and amount of earlier invoices | Same supplier and amount on a close date, or a similar number | Accounts payable |
| Match | Do price and quantity agree with the purchase order and the receipt, within tolerance? | Purchase order lines, goods receipts, tolerances | Price or quantity outside tolerance, no receipt yet, no order number | Buyer (price), requester or receiver (quantity, receipt) |
| Coding | Which account and cost centre does a non-PO invoice go to? | Supplier history, contracts, chart of accounts | No coding proposal, or a proposal above a set amount | Budget holder |
| Approval | Has someone with authority approved the spend? | Delegation of authority, approval matrix, absences | Amount above the approver’s limit, approver absent with no delegate | Approver, then the next level |
| Payment proposal | When should this invoice be paid? | Due date, payment terms, discount terms, payment calendar | Bank details changed since the last payment, or payment block set | Supplier data team; treasury |
| Payment release | Is the payment run correct and released by a second person? | Payment run, bank file, release rights | Run not released by a second person | Treasury or finance manager |
| Posting and reconciliation | Is every paid invoice posted, and every open receipt explained? | Ledger, open receipts, bank statement | Payment not matched on the bank statement, receipt with no invoice at month end | Accounts payable; general ledger team |
Each stop has a reason and one owner. If a stop has no owner, or always goes back to accounts payable, the process is not designed yet.
The validation step uses the details an invoice must carry. In the EU, for example, a VAT invoice must show among other things the date, a sequential number, the VAT numbers of the supplier and, in many cases, the customer, the quantity and nature of the goods or services, the VAT rate and the VAT amount. A rule can check these fields; a person does not need to.
Which route does each type of invoice take?
An automated accounts payable process has several routes, one per type of invoice. A single flow for all invoices either stops too many good invoices or lets too many bad ones through. Most organisations need at least the five routes below.
| Invoice type | Checked against | Who confirms the goods or service | Can it pass with no one touching it? |
|---|---|---|---|
| Goods on a purchase order | Order price and receipt quantity (three-way match) | Receiver, through the goods receipt | Yes, if it matches within tolerance |
| Services on a purchase order | Order price; service confirmation or service entry instead of a goods receipt | Requester, who confirms the service was delivered | Yes, once the confirmation exists; often two-way match plus confirmation |
| Recurring invoice under a contract (rent, telecoms, subscriptions) | Contract amount or a standing order for the period | Contract owner | Yes, if the amount equals the expected amount |
| Non-PO invoice | Coding proposal and approval matrix | Budget holder | No: it always needs an approval |
| Credit note | The original invoice it corrects | Accounts payable | Yes, if it matches an open or paid invoice from the same supplier |
Decide the route from data on the invoice, such as an order number or a contract reference, so that the system can choose it without a person.
Two-way matching compares the invoice price with the order price; three-way matching also compares the invoice quantity with the quantity received. In Microsoft’s Dynamics 365 Finance documentation, both are matching policies, and the policy can be changed for a supplier, an item or a purchase order. That means a service supplier can be checked on two-way matching while a parts supplier is checked on three-way matching, in the same system.
How should exceptions be routed?
An exception should go straight to the person who can fix its cause, with the reason and a time limit. Accounts payable should not fix a price that the buyer agreed or a quantity that the warehouse recorded; it should see that the fix happens.
| Exception | Typical cause | Owner | What the owner does | While waiting |
|---|---|---|---|---|
| Price above tolerance | Price changed without an order change | Buyer | Changes the order, or asks the supplier for a credit note | Invoice blocked for payment |
| Quantity above receipt | Partial delivery, or receipt not yet recorded | Receiver or requester | Records the receipt, or confirms the shortage | System retries the match |
| No purchase order number | Order not raised, or not quoted by the supplier | Requester | Gives the order number, or explains the purchase | Invoice parked; supplier told how to quote the order |
| Possible duplicate | Same invoice sent by post and by email, or resent with a new reference | Accounts payable | Compares both documents and rejects one | Both invoices blocked |
| Supplier not active | New supplier not fully set up, or supplier blocked | Supplier data team | Completes or reviews the supplier record | Invoice parked |
| Bank details changed | Genuine change, or attempted fraud | Supplier data team | Calls the supplier on a number already on file | Payment blocked |
| Tax or legal content wrong | Supplier error | Accounts payable | Asks the supplier for a corrected invoice or a credit note | Invoice rejected or parked |
Set a time limit for each owner and a next level when it passes; otherwise exceptions wait until the supplier calls to ask for payment.
Some exceptions solve themselves if the system tries again. Microsoft’s documentation describes a background task, run hourly or daily, that matches posted product receipts to invoice lines; the administrator sets the maximum number of attempts before the match is marked as failed. In SAP S/4HANA, an invoice with one line outside tolerance can be posted but the whole invoice is blocked for payment until someone releases it. Decide how long your process waits before a person is asked.
The bank details rule needs special care. The UK National Crime Agency advises verifying a change by calling the supplier on a phone number used before, because emails can be intercepted, and asking a colleague to authorise high-value payments. Write this as a rule that no one can switch off, not as advice in a manual.
Disclosure: the author works as an Ivalua consultant. The ERP products named on this page are cited from their public documentation only, to show how a step works; this is not a comparison.
How do you design the automated process, step by step?
You design the accounts payable automation process by starting from real invoices, sorting them into routes, then writing the rules and owners for each route. The design comes before the software configuration; the same design can be set up in most tools.
- Take a sample of real invoices from one recent month, for example 100, and follow each one: how it arrived, whether it had an order number, whether it matched, who touched it and why.
- Sort the sample into routes (goods on PO, services on PO, recurring, non-PO, credit notes) and count each one. The counts tell you which route to design first.
- For each route, write the steps from the table above and mark where the invoice stopped in the sample and why.
- Give every stop reason an owner, a time limit and a next level. Agree them with the buyers, the receivers and the supplier data team, not only within finance.
- Write the rules in a rule register: tolerances, duplicate criteria, touchless conditions, approval limits, payment block conditions.
- Decide the conditions for a touchless invoice, the invoice that passes every step with no person. Start strict and widen them only on evidence.
- Build test cases for every rule, including invoices that should fail, and run them in a test environment.
- Start with one route and one entity, measure how many invoices stop and why, and fix the most frequent cause before adding the next route.
A concrete case: in the sample, 30 of 100 invoices stopped because the goods receipt was missing. That is not an accounts payable problem. The fix is a receiving rule, for example that deliveries are recorded on the day they arrive, and a reminder to the requester when an invoice waits for a receipt.
What goes in the rule register?
The rule register is the one list of every rule the automated process applies, with its value and its owner. When an invoice is approved by rule, the rule is the control, so auditors and finance need to see who set it, when, and when it will be reviewed.
| Rule | Value | Applies to | Owner | Approved | Next review |
|---|---|---|---|---|---|
| Unit price tolerance | +2% or €50 per line, whichever is lower | Goods on PO | Finance controller | 2026-09-15 | 2026-12-15 |
| Quantity tolerance | 0 above the quantity received | Goods on PO | Finance controller | 2026-09-15 | 2026-12-15 |
| Duplicate check | Same supplier, same amount, invoice dates within 30 days | All invoices | Accounts payable manager | 2026-09-15 | 2026-12-15 |
| Touchless condition | Structured invoice or capture confidence above threshold, all checks passed, amount under €25,000 | Goods on PO, recurring | Finance controller | 2026-09-15 | 2026-12-15 |
| Non-PO approval | Budget holder up to €5,000; head of department above | Non-PO invoices | Chief financial officer | 2026-09-15 | 2027-03-15 |
| Bank detail change | Payment blocked until a call-back is recorded by a second person | All suppliers | Supplier data manager | 2026-09-15 | 2027-03-15 |
| Receipt wait | Retry match daily; ask the requester after 5 working days | Goods on PO | Accounts payable manager | 2026-09-15 | 2026-12-15 |
Each value above is an example, not a recommendation. Your own values come from your invoice sample, your risk appetite and your approval policy.
Keep the register outside the software configuration, in a document that finance owns, and check every quarter that the configuration still matches it. Changes go through the same request and approval as any other control change. Separation of duties applies here too: the person who changes a rule in the system should not be the person who approved it. The US Government Accountability Office describes separation of duties in its internal control standards as making sure no one person controls all key parts of a transaction.
How do you test the automated process before go-live?
Test the automated accounts payable process with one invoice for each rule, and write the expected result before you run it. Most problems at go-live come from invoices that should have stopped and did not, not from good invoices.
| Test invoice | Expected result |
|---|---|
| Matches the order and the receipt line by line | Passes with no one touching it and is proposed for payment on the due date |
| Unit price 1% above the order (inside tolerance) | Passes; the difference is recorded |
| Unit price 10% above the order | Blocked for payment; task to the buyer with the reason |
| Invoice for 100 units, receipt for 60 | Waits; matches when the second receipt of 40 is recorded |
| Arrives before any receipt | Waits; after the set time, task to the requester |
| Same invoice resent as INV1001 instead of INV-1001 | Flagged as a possible duplicate; not paid twice |
| Credit note for a paid invoice | Linked to the original invoice; offset in the next payment run |
| Supplier whose bank details changed yesterday | Payment blocked until the call-back is recorded |
| Non-PO invoice above the budget holder’s limit | Goes to the next approval level |
| Approver on leave | Goes to the delegate, or to the next level after the time limit |
| Invoice addressed to the wrong entity | Rejected at intake, with a message to the supplier |
A test plan passes when every invoice that should stop does stop, with the right reason and the right owner.
Who owns what in the automated process?
In an automated accounts payable process, accounts payable runs the queue and the rules, but most fixes belong to other teams. Name them before go-live.
- Accounts payable watches the queue, handles capture errors, duplicates and supplier questions, and reports exceptions by cause each month.
- The finance controller sets and reviews tolerances, touchless conditions and the rule register.
- Buyers fix price differences and keep purchase orders up to date when terms change. How orders are run is covered in purchase order management.
- Requesters and receivers record receipts and confirm services on time.
- The supplier data team creates and changes supplier records and verifies bank details.
- Treasury releases payment runs, with a second person for high values.
- IT maintains the interfaces with the ERP and the user roles, so that no one has conflicting rights.
Suppliers have a part too: they send invoices through the agreed channel and quote the order number. How to set those instructions and answer supplier questions is explained in vendor invoice management.
Questions
What is the difference between the accounts payable process and the accounts payable automation process?
The accounts payable process is the work of receiving, checking, approving, paying and recording supplier invoices, whoever does it. The accounts payable automation process is the same work written as system rules: each step is done by software, and people act only when a rule stops an invoice. The steps are the same; who decides at each step changes.
Do we need to automate every invoice type at once?
No. Start with the route that has the most invoices and the best data, usually goods invoices on purchase orders from regular suppliers. Measure how many stop and why, fix the main causes, then add services, recurring invoices and non-PO invoices. Non-PO invoices always keep a human approval.
Should every exception go back to accounts payable?
No. An exception should go to the person who can fix its cause: the buyer for a price, the receiver for a missing receipt, the supplier data team for a blocked supplier or new bank details. Accounts payable follows the exception and its time limit. If every exception returns to accounts payable, the team becomes a manual relay and the process gains little.
Is a high touchless rate the goal of the process?
Only if the controls hold. A touchless rate rises when tolerances are widened, so it can look better while more wrong invoices pass. Track it together with what passed under each tolerance, duplicates found after payment and exceptions by cause. The goal is that good invoices pass alone and wrong ones stop.
Where do we document the automated process?
In three places: a process map with the routes and steps, the rule register with values and owners, and the test plan with expected results. Finance owns the rule register; IT keeps the system configuration aligned with it. Auditors usually ask for all three.
New guides on the procure‑to‑pay line
One short email when a guide on this line is added or revised. Nothing else.
Coming soon: sign-up opens with the first email.