In many finance teams, the ERP is not where invoice processing happens. It is where invoices go when the processing is finished. The work itself still lives in inboxes, shared folders and informal approval chains: a PDF arrives, someone keys the header into a spreadsheet, someone else checks it against a purchase order, a manager replies “ok” to an email, and only then is a complete record created in the system of record.
That gap between receipt and posting is where time is lost, errors enter and visibility disappears. This guide describes how to redesign invoice processing as a single flow from inbox to ledger, with automation handling the mechanical steps and people handling the exceptions that actually need judgment.
See the current path clearly
Start with a sample of recently paid invoices, not with a process diagram. For each one, reconstruct what actually happened: how it arrived, who touched it, which systems were opened, how long it waited and what caused any delay. Ten invoices is enough to reveal the pattern. Fifty is better if volume is high.
You will usually find that the official process and the real one differ. The official process may say “invoices are matched to purchase orders and approved in the ERP.” The real one may say “invoices sit in a shared mailbox until someone has time, are entered into a tracker, are forwarded to a budget owner who is travelling, and are posted in a batch at month-end.” The second description is the one you design around.
- Channel: email, supplier portal, electronic invoice or paper scan.
- Capture: who extracts supplier, amount, date, PO number and cost center.
- Match: how the invoice is checked against a PO, receipt or contract.
- Approve: who decides, on what basis, and how the decision is recorded.
- Post: when the ledger entry is created and by whom.
Separate straight-through from exception
A useful design treats invoices as two populations. Straight-through invoices can be captured, matched and posted with little or no human intervention. Exceptions need a person. The aim is not to automate every invoice. It is to make the straight-through path wide enough that people spend their time on the cases that deserve it.
Typical criteria for a straight-through invoice are straightforward: known supplier, valid purchase order, amount within an agreed tolerance, goods or services received, and a complete cost center. If all of those hold, there is little reason for a person to re-check what the systems already know. If any of them fail, the invoice should go to a named exception queue with the reason attached.
If a person is opening an invoice only to confirm what the purchase order already says, the process is using them as a system of record.
Tolerance matters more than many teams expect. A rule that requires an exact match will send almost everything to exception. A rule that allows a small variance on tax or freight, with a clear audit trail, will keep the straight-through path usable. Set the tolerance with finance, not with the software vendor, and review it after the first month of live data.
Capture once, close to the source
Capture is the step most teams underestimate. If supplier name, invoice number, amount and PO reference are typed by hand, every later control is built on uncertain data. Optical character recognition and structured e-invoices reduce this, but they only help if someone owns the exceptions: unreadable PDFs, missing PO numbers, suppliers who send statements instead of invoices.
The better design captures the invoice as close to the supplier as possible. A portal or e-invoice feed that requires a PO number before submission prevents a large class of exceptions from entering the process at all. Where email remains necessary, route it into a single capture service rather than into personal inboxes, so nothing depends on one person being at their desk.
Make approval a recorded decision
Email approval is convenient and almost impossible to audit. A recorded decision needs three things: who approved, what they approved, and why the case was sent to them. Automated routing can send invoices under a threshold to the budget owner, invoices over it to a second approver, and invoices without a PO to a designated reviewer. The rule should be readable by the finance team, not only by the person who configured it.
When an approver returns an invoice, the reason should re-enter the flow. “Wrong cost center” and “goods not received” are different exceptions and should go to different owners. A generic “rejected” status hides the work that still needs to happen and makes the bottleneck look like a black box.
Posting should not wait for month-end
If invoices are posted in a batch at month-end, the ledger is always behind the operation. Accruals grow, supplier queries increase and no one can answer a simple question about open liabilities without opening a spreadsheet. Straight-through invoices can be posted as they clear. Exceptions can be posted as soon as they are resolved. Month-end then becomes a control review, not a data-entry exercise.
This change is as much about ownership as about software. Someone has to monitor the exception queue daily, not weekly. Someone has to keep supplier master data clean. Someone has to adjust routing when a new cost center or entity is added. Without that ownership, the automated path will shrink and the inbox will grow back.
Where to start
Take a month of invoices and split them into matched, unmatched and exception. Estimate the time spent on each group. Write the straight-through criteria with the people who currently check invoices, then test those criteria against the sample: how many would have passed, and which failures are genuine. Automate capture and matching for the pass group first. Leave judgment-heavy exceptions with people, but give them a queue, a reason code and a deadline.
The result you want is not a quieter mailbox. It is a ledger that reflects invoices as they are processed, a queue that shows where work is stuck, and a finance team that spends its time on the invoices that actually require a decision.