Friday’s AP inbox has a bill for two deliveries against one purchase order. The warehouse has entered only one receipt. Capturing the bill today and getting the missing delivery checked before anyone approves the unmatched amount is useful automation, even if a person still makes the payment decision.
Accounts payable automation covers the steps software can prepare, check, or carry out between the moment a bill arrives and the moment the bank debit is reconciled. When evaluating any of it, ask which step it handles, what evidence it uses, and who still decides.
The six handoffs a supplier bill goes through
| Stage | What software can prepare | What finance still checks |
|---|---|---|
| Intake | The original document and draft fields | Supplier, buying entity, invoice number, currency, and whether the bill already exists |
| Matching | The PO, receipt, and line-level differences | Whether the billed quantity is supported by receipts and by earlier bills against them |
| Approval | A review task with the invoice and proposed coding | Who can approve the expense or resolve the exception |
| Posting | An approved bill ready for the ledger | The saved bill agrees with the approval and lands in the right period |
| Payment | A proposed run with due dates and holds | Payment authority, beneficiary details, and whether any bill is already paid |
| Reconciliation | A link between the ledger payment and bank activity | Amount cleared, fees or differences, and which bills the payment covered |
Invoice capture gets the fields off the page. Matching asks whether the company agreed to buy the goods or services and whether the evidence is on file. Approval gives someone authority to accept the expense. Payment release moves money. When a vendor says their product “automates AP,” ask them to point to the exact stage their product controls.
Find where your bills actually wait
Before you buy anything, pull three late bills from the unpaid-bills report: one that took a long time to enter, one waiting for a receipt, and one already approved. They are all late, but a different person can move each of them.
Use the aging report to find each bill, then open the original document and the approval or hold history. Some systems keep those in separate places. Oracle Fusion, for example, lists unpaid invoices in its Payables Invoice Aging Report and shows matching holds and releases in a separate Matching Hold Detail Report (Oracle Fusion Payables predefined reports). Find the equivalent records in your own system.
For each bill, record when it arrived, when it became ready to approve, and when it posted. If it is still waiting, write down what needs to happen and who can do it. Include bills that never reached the ledger, because an aging report cannot show invoices still sitting in an inbox.
| What you find | First change to test |
|---|---|
| AP spends its time retyping bills | Draft bills with the source invoice visible beside the fields |
| AP waits for the warehouse | Send receiving the PO line and the exact quantity to confirm |
| Managers get the invoice but not the contract or coding | Attach those records to the approval request |
| Bills wait after approval | Check posting failures and payment scheduling separately |
| The same invoice arrives through more than one channel | Let AP find the earlier draft or posted bill before creating another |
A better PDF reader leaves a week-long receipt wait exactly where it was. Measure staff minutes and queue days separately so you know which one a change actually reduced.
Stage by stage: what to automate and what to keep
Intake and capture
Save the original attachment and let the reviewer jump from each proposed field to the place on the page it came from. Keep the text as printed alongside the value the system will use. An invoice date of 04/05 means different things depending on the supplier’s convention, and if the system cannot establish which applies, the field should stay open for review. Google’s Document AI documentation shows how an invoice parser returns line items with child fields and normalizes some extracted values (Google Cloud’s Document AI response guide).
Check what your accounting system already does here. NetSuite Bill Capture documentation describes templates that save selected fields for a specific vendor and subsidiary (Oracle’s Bill Capture template documentation). Sage Intacct documents creating draft bills from emailed or uploaded invoices with the source document attached (Sage Intacct AP Automation documentation). If either is enabled in your account, compare what your team can verify there before paying for another intake layer. A saved default spares AP a lookup, but test it on a routine-looking bill that belongs to a different entity or needs different coding.
Validation before anything posts
Before a draft bill posts, run these checks in order:
- Confirm the supplier and buying entity against the vendor record and the invoice address. If two records fit, show both to AP.
- Recalculate the invoice from its lines, including credits, tax, and freight. If the PDF shows a subtotal, a credit, and a final balance on different pages, show which number became the bill total and whether the lines add up to it.
- Compare the PO line, receipt, and earlier bills when the invoice calls for matching.
- Apply the approved coding and approval rules, and save reviewer changes with the invoice version they approved.
- Trace the approved draft to the saved ledger record. If the write times out, check whether the bill already exists before submitting again.
Judge the tool on whole bills that post correctly, not on field-level accuracy. A high field-level accuracy score can hide the single wrong entity that stops an entire invoice.
Matching
Two-way matching compares the invoice with the purchase order. Three-way adds the receipt. For items that also require inspection, Oracle’s four-way approval level checks the accepted quantity as well (Oracle’s match approval documentation). The three-way matching guide covers tolerances, unit conversions, and receipts already used by earlier bills.
The partial delivery is the case to test first. A check against the PO alone looks fine when the supplier bills the whole order after the first shipment. Adding the receipt makes the gap visible. Oracle’s NetSuite 3 Way Match Vendor Bill Approval workflow checks the bill against the PO and item receipt, and Oracle documents a limitation for partially received item receipts in that workflow (Oracle’s three-way match workflow documentation). Put one through your own setup before relying on the match.
Bills without a purchase order
A consultant invoices for last month’s work and there is no PO. Software can read the amount and supplier. Someone still has to confirm the agreed fee, who received the work, and which department pays.
| Invoice | What the approver needs to see |
|---|---|
| Recurring utility bill | Account, location, billing period, and any overlapping charge |
| Consulting bill | Agreement or statement of work, rate, and confirmation the work was done |
| Software renewal | Approved term, covered seats, and whether the charge already cleared on a card |
| Shared expense | Proposed split and the basis the departments agreed to use |
If the agreement is missing, assign someone to find it before asking for a decision. An approval request without the contract just comes back with a question.
Approval
Sage Intacct’s Accounts Payable documentation describes approval rules based on vendor, value, department, or user, and notes that automatic approval under one rule can still be followed by another (Sage Intacct bill approval documentation). Run the whole route on a shared expense and on a bill from a vendor with no designated approver. Verify who receives it and what happens when nobody can act. The invoice approval workflows guide covers delegation, escalation, and reapproval after edits.
Posting
The posting step is where duplicates are born. A write times out, someone retries, and the ledger now has two bills. Require the workflow to look for an existing bill by supplier, entity, invoice number, and amount before every retry. Keep a log with one row per input and the resulting bill ID, so a second ID on the same row stands out.
Payment and bank reconciliation
Keep payment release under the controls you already have. Trace an approved bill into a proposed payment run, then trace the test payment back from the bank to that bill. If one transfer pays several invoices, record the split. A balanced bank entry alone cannot show which supplier bills were settled.
Worked example: one bill from inbox to bank (illustrative)
Purchasing orders 200 brackets at $15.00, a PO value of $3,000. Delivery is in two installments of 100. The warehouse records the first 100. The supplier invoices all 200, $3,000, plus $120 freight, for a total of $3,120.
| Check | Result |
|---|---|
| Price: invoice $15.00 vs PO $15.00 | Agrees |
| Quantity: invoiced 200 vs received 100 | 100 units unsupported |
| Supported item amount | 100 × $15.00 = $1,500 |
| Unsupported item amount | 100 × $15.00 = $1,500 |
| Freight | $120, handled under your freight policy |
A total-only check against the $3,000 PO passes this bill if your tolerance allows for freight. The line check stops it. Receiving gets the PO line and the second delivery reference. If policy allows a partial bill, AP approves $1,500 plus freight, $1,620, and holds the rest. When the second receipt posts, the match runs again and the remaining $1,500 can advance.
At payment, one transfer of $4,840 settles the $1,620 portion of this bill plus two other bills for $2,340 and $880 ($1,620 + $2,340 + $880 = $4,840). The reconciliation record should show all three bill references against the single bank debit. If the bank shows a $15 wire fee as a separate line, record it as a fee, not as a short payment against one supplier.
What goes wrong
- A revised invoice after approval. The approval still points to the original amount. Put the old and new versions side by side, show what changed, and send the new version for reapproval under your policy. If the original already posted, AP decides between a credit, a correction, or a replacement and keeps the link between them.
- A forwarded copy. A department manager forwards an invoice the supplier already sent. Each channel creates its own draft. Test this explicitly, both before and after the first copy posts. The duplicate payments and vendor master guide goes further on detection.
- A held bill slips into a payment run. Check that a posted bill on hold is excluded from payment selection, not merely flagged.
- A bank-detail change arrives with an invoice. Route it through independent verification with the vendor-master owner. Never apply new payment instructions from the bill itself.
- One supplier name, two entities. If a supplier bills more than one company in your group, test whether the tool picks the entity from purchasing evidence or just reuses last month’s coding.
- An “exceptions” inbox. A single queue labeled exceptions still leaves AP to work out who can act. Route the exact question with the records needed to answer it.
How to compare tools on your own bills
Give each vendor the same redacted sample: a clean PO bill, a non-PO bill split between departments, a credit, the partial delivery, a forwarded duplicate, and a write that times out after submission. Have the person who works the queue judge the results.
If a vendor proposes AI-assisted coding, ask it to show which fields were read from the page and which were inferred from history, how staff correct a bad suggestion, and whether a correction can alter an already-approved bill. If you set up AP workflows a few years ago, give the older setup credit for what it already handles, and retest only the invoices people still fix by hand.
The AP automation implementation guide covers the pilot and cutover, and the AP pricing and ROI guide separates hours returned to the team from cash the company actually saves.
First steps on your own AP queue
- Pull ten late bills and record, for each, arrival date, ready-to-approve date, posting date, and who it is waiting on.
- Sort them by cause: entry, receipt, approval evidence, posting, or payment scheduling.
- Pick the cause with the most bills and one owner who can fix it.
- Build a test sample of six bills from that queue, including the partial delivery and the forwarded copy.
- Confirm which steps your ERP already performs before pricing a tool for them.
- Write down who pauses writes and who reconciles what is in flight if a live test goes wrong.