Accounts Payable Workflow Automation From PO to Payment

Most accounts payable advice assumes you buy stock. You raise a purchase order, goods arrive, someone receipts them, the invoice matches, done. That model breaks the moment a large share of your spend is maintenance and subcontract, because there is no box to count on the loading dock. A chiller service, a month of security manpower, a milestone on a fit-out contract: none of them produce a delivery note. This is how I design the flow from PO to payment for that kind of operator, and where I put the effort so invoices actually move.

The shape of the flow

The end-to-end path is the same six stages for every invoice: capture, match, receipt confirmation, exception routing, accrual, and payment. What changes in a maintenance-heavy business is the balance of work. In a stock-heavy retailer, capture and match are the hard part and receipting is trivial. In an operator whose spend is labour and subcontract, capture is easy, matching is easy on paper, and the receipt confirmation is where everything stalls. Design for that, not for the textbook.

The four actors that touch an invoice are accounts payable, the budget holder who owns the cost, procurement who owns the PO and the vendor relationship, and treasury who owns the cash. A clean flow keeps each one in their lane and only pulls a human in when a machine rule cannot decide. The diagram below is the routing I aim for.

Invoice capture

Capture is the least interesting stage and the one vendors demo the hardest. The goal is simple: get every invoice into the system in a structured form, with a header, lines, tax, and a PO reference if one exists, before a human touches it. Suppliers send PDFs by email, paper by post, and, if you are lucky, structured files through a portal. I push as much as possible to a single inbound channel, usually a dedicated AP mailbox that feeds an OCR or e-invoicing engine, so nothing arrives on someone's personal email and dies there.

The OCR does not need to be perfect. It needs to be honest about confidence. A good capture layer flags low-confidence fields for a quick human check rather than guessing and passing a wrong tax code downstream. What matters for the rest of the flow is that the PO number and the vendor are read reliably, because those two fields decide almost every routing rule that follows.

PO matching

With a PO reference in hand, the system attempts a match against the order and any receipt. For stock, that is a three-way match of PO, goods receipt, and invoice. I have written separately about the mechanics of that in three-way matching of PO, GRN and invoice, so I will not repeat the tolerance maths here. The point for AP design is that matching is a gate, not the destination. When an invoice matches within tolerance and has a valid receipt, it should post and accrue with no human involvement at all. Everything human happens on the fail path.

The PO itself has to exist and be correct before any of this works. If requisitions and orders are raised late or approved by the wrong person, the invoice arrives before the PO does and the match fails for reasons that have nothing to do with AP. That is why I treat purchase requisition and approval automation as upstream of AP, not separate from it. A clean AP flow starts with a clean commitment.

Service entry and GRN for labour-based invoices

This is the section that decides throughput, and it is the one most AP automation projects underinvest in. When you buy a pump, someone receipts a pump and the invoice has something to match against. When you buy a month of HVAC maintenance or a security guard roster, nothing physical arrives. There is no goods receipt note because there are no goods. If you leave those invoices with nothing to match, they all fail and land in a human queue, and your touchless rate collapses no matter how good the OCR is.

The fix is a service entry sheet: a receipt for work rather than for goods. On a service PO, the site supervisor or budget holder records that the work for a period, or a defined milestone, was performed and to what value. That service entry becomes the receiptable line the invoice matches against, exactly as a GRN does for stock. For a recurring contract, the entry is a monthly confirmation against the contract value. For a project, it is milestone-based receipting: the fit-out contractor bills against completed stages, and the entry is signed off stage by stage rather than as one lump at the end.

Two rules make service entry work in practice. First, the person confirming the entry must be the person who can see the work, which is the site supervisor or budget holder, not AP. AP cannot know whether the guards actually turned up. Second, the entry must be raised close to when the work happens, not when the invoice arrives, otherwise period-end accrual guesses in the dark. Get those two right and a large share of maintenance invoices become as touchless as a stock invoice.

Exception routing

Everything that fails the match is an exception, and the discipline is to route each type to exactly one owner with a defined rule, rather than dumping all failures into a shared queue that AP triages by hand. There are, in my experience, eight reasons an invoice fails to match, and each one has a natural owner. The table below is the taxonomy I build the routing rules around.

The value of a fixed taxonomy is that routing becomes a rule engine rather than a judgement call. A tool like Microsoft Power Automate or the workflow layer inside a spend platform such as Coupa can classify most exceptions from the fields already captured and send them straight to the right owner. The owner assignment itself should follow the same authority table your approvals use, which is why I keep exception routing aligned with approval limits and delegation of authority rather than inventing a second hierarchy for AP.

Accrual at period end

Accrual is where the service-entry discipline pays off a second time. At month end, finance needs to book the cost of work performed but not yet invoiced. In a stock business the receipts tell you what to accrue. In a service business, without service entries, accrual becomes a spreadsheet of guesses that the auditor rightly distrusts.

If your service entries are raised when work happens, the accrual is close to automatic: everything received and not invoiced is your accrual, by line, with an owner attached. That converts period-end from a scramble into a report. Where entries are missing, you are estimating, and estimates should be flagged as such so they can be reversed and trued up next period rather than quietly carried.

The payment run

Only posted, approved, non-duplicate invoices reach the payment run, and treasury owns it. The run groups approved invoices by due date and payment method, applies any early-payment discount logic, and produces the bank file plus remittance advice. The design principle is that payment selection is mechanical: if an invoice is fully matched, approved and within terms, it pays on schedule without anyone chasing it. Human attention at this stage should be reserved for the payment proposal review, not for re-checking invoices that already cleared matching.

Two things stay manual by choice. Someone reviews the payment proposal before the bank file is released, and someone with the authority to move cash approves the release. Those are control points, not throughput problems, and I cover why in the controls section.

The one metric worth reporting weekly

If I can report only one AP number every week, it is the touchless-processing rate: the share of invoices that go from capture to posted without a human touching them. Everything else, invoices per FTE, average cycle time, cost per invoice, is downstream of it. A high touchless rate makes all of them good automatically. A low one cannot be fixed by working the queue harder.

Instrument it precisely. The numerator is invoices posted with zero human intervention between capture and posting. The denominator is all invoices captured in the period. Do not let anyone quietly exclude non-PO invoices or exceptions to flatter the number, because those are exactly the invoices you are trying to reduce. Measure it end to end, weekly, and trend it.

On realistic targets, ignore the vendor claims of ninety-plus percent, which almost always describe a stock-heavy, PO-backed environment. In a mixed operator with meaningful maintenance and subcontract spend, a mature flow lands somewhere around 55 to 70 percent touchless, and getting there is genuinely good work. Push the service-entry model well and the ceiling rises, but a business with heavy non-PO or emergency spend will sit lower and that is honest, not a failure. Report the real number and the trend, not the aspiration.

The controls an auditor will test

Automation is where fraud enters if you build the flow around the controls instead of through them. An external auditor will test a small, predictable set of things, and every one of them must survive automation intact.

• Segregation of duties. The person who sets up a vendor cannot approve its invoices or release its payments. The person who confirms a service entry cannot also approve the payment. Automation must preserve these separations in the role model, not collapse them for convenience.
• Duplicate-invoice detection. A machine check on vendor, amount, invoice number and date should hard-stop suspected duplicates before payment, and the block must be one a human cannot silently override without a logged reason. This is the single highest-value control in the whole flow.
• Bank-detail change control. A change to a vendor's bank account is the classic payment-diversion vector. Any change must be verified out of band, made by someone who cannot also release payments, and logged with who changed what and when. Never let a bank-detail change ride in on an emailed invoice.

The test I apply to any AP automation is simple: could this control be bypassed by one person acting alone? If yes, it is not a control, it is a suggestion. Build the automation so the answer is always no, and the auditor's visit becomes a formality rather than a discovery.

A note on independence

I have no reseller, referral or affiliate arrangement with any of the tools mentioned here. Power Automate and Coupa appear because they are representative of the categories, not because I am paid to name them. Any product will do the job if your service-entry model and controls are sound, and none will save you if they are not.