Invoice approval software: the checks your payment run needs

This is written for finance teams at companies of 50 to 500 people who release one or two supplier payment runs a month, and who have already found a duplicate, an undeducted credit note or a changed bank account after the file reached the bank.

Invoice approval software is a tool that captures supplier invoices, validates them against purchase orders and goods receipts, and routes them to the right approver before payment. It works one invoice at a time. The payment run is a second and separate control point, where approved invoices are grouped into a batch and a different class of error becomes a real payment: the same invoice approved twice through two channels, a supplier bank account changed since the last run, a credit note that was never deducted, an invoice due next month pulled into this month's file. Approval asks whether an invoice is correct. The payment run asks whether a correct invoice should be paid, now, to that account. Most approval tools never ask the second question.

What invoice approval software controls, and what it leaves open

Strip the category down and every product in it does four things. It captures the invoice, whether it arrives by email, portal or scan. It extracts the header and the line items. It matches what it extracted against a purchase order and a goods receipt, the check commonly known as three-way matching. Then it routes the document to whoever is allowed to say yes, according to rules based on department, supplier or amount.

That chain is genuinely useful. It replaces the email thread, it ends the manual data entry, and it leaves an audit trail showing who approved what and when. Where approval routing is properly configured, the invoice that reaches the accounting system has been seen by a human with the authority to commit the spend.

But look at what the chain is shaped around. Every one of those four steps takes a single invoice as its unit of work. Data capture reads one document. Matching compares one invoice to one order. Routing sends one item to one approver. The approval process ends the moment that item is stamped, and the item then leaves the tool.

Nothing in that design ever looks at two invoices side by side. Nothing compares this month's file to last month's. Nothing asks what happens when eleven hundred approved invoices are assembled into a single transfer file on the twenty-fifth of the month.

Approval is not a payment decision

An approval says: this invoice is arithmetically correct, it matches an order we placed, and someone with authority agrees we owe it. That is a statement about the document.

A payment decision says something else entirely: of everything we owe, this subset gets paid in this run, in this amount, to this bank account, on this date. That is a statement about a batch, and it depends on facts the approver never had in front of them. The approver could not know whether the same invoice had already been settled in the previous run under a different reference. They could not know that the supplier's bank details were changed in the master file three days ago. They could not know that a credit note for a returned delivery arrived after their approval and has not been applied.

This is not a subtle gap, and it is a strikingly unwritten one. Across the three editorial pages ranking on the first page of Google for invoice approval software, scraped on 20 September 2026 and totalling 7,682 words, the expressions payment run, payment batch, payment proposal, payment file and duplicate payment appear zero times. IBAN appears zero times. Credit note appears zero times. Due date appears once. The word payment itself is everywhere, but always as payment execution, payment scheduling or payment posting: the batch is described as something that happens, never as something that is checked.

Reading that table, the honest conclusion is that most finance teams have automated the first column and left the second to whoever eyeballs the payment proposal before clicking send. That is the job an agent that checks every invoice before it is released for payment is built to take over, and it is the reason the control has to sit between approval and the bank file rather than before either.

The four controls that belong to the payment run

These four are not additional approval rules. Each one needs information that exists only when the batch is assembled, which is why adding them to an approval workflow does not work.

The same invoice, approved twice

Duplicates are not a data entry problem, they are an arrival problem. One invoice reaches you as a PDF attached to an email, then again through the supplier portal, then a third time on the monthly statement chased by a collections agent. Each copy looks legitimate. Each can be approved by a different person on a different day, because neither approver sees the other's queue.

The failure mode is well documented by the people who live it. A thread in the r/Accounting community titled "My company is firing our intern after he paid the same invoice 7 times" is instructive less for the incident than for the response it attracted: the highest-rated reply describes exactly the missing control, requiring the invoice number, checking it against previously approved invoices, and flagging when multiple payments go to the same supplier. Seven payments cleared because nothing compared the batch to what had already been settled.

The control is a match, not a rule. It compares each line of the proposed run against invoices already paid, on supplier, amount, invoice number and date, and it has to tolerate the fact that the same invoice often carries three different reference formats across three systems. An exact-match query finds the easy duplicates and misses the expensive ones.

A supplier bank account that changed since the last run

Bank detail changes are the single highest-value error in the batch, because they are not errors at all when they are fraud. The pattern is consistent: an email arrives from a real supplier address or a close imitation of one, announcing new bank details for future payments. The master file is updated. The next run pays a genuine, correctly approved, three-way matched invoice into an account controlled by someone else.

Practitioners describe both the near miss and the hit. One r/smallbusiness thread is titled "Almost sent payment to the wrong bank account because the invoice...", and the advice underneath is to verify any change directly with the vendor. A thread in r/sysadmin records the version where nobody checked.

The control is diffing, not verifying. Before the file is generated, compare the bank details on every line of the run against the details used the last time that supplier was paid. Any difference is held. The point is that it holds automatically, on every run, including the runs where nobody is suspicious, which are the runs that matter. This is the specific job of spotting changed or fraudulent supplier bank details, and it only works if it runs against the batch rather than against the invoice.

A credit note that was never deducted

Credit notes arrive late by nature. The delivery is short, the goods are returned, the price was wrong: all of these are discovered after the invoice was approved, often after it was posted. The credit note lands in the same inbox as everything else and sits there as an unmatched document while the original invoice moves toward payment at full value.

Nothing in the approval chain connects the two. The invoice was approved before the credit note existed, so no approval rule can catch it. The control has to run at the batch, netting open credit notes against the lines of the proposed run, supplier by supplier, before the amounts are fixed. The money recovered here is real and recurring, and unlike a duplicate it is never refunded spontaneously, because the supplier has no reason to raise it.

A due date that does not belong to this run

The last control is the least discussed and the easiest to measure. Across those same 7,682 words of first-page editorial content, due date appears once and cash position not at all. Yet the composition of a run is a cash decision before it is an accounting one.

Two errors live here. Invoices that are not yet due get pulled into the current run because they happen to be approved, which costs working capital for no benefit. Invoices that are due are left out because nobody sorted the queue by date, which costs late payment penalties and supplier goodwill. Both are invisible if the run is assembled from everything approved since the last one, which is how most runs are in fact assembled.

The control sorts the batch by exigibility, flags anything outside the window, and surfaces the total against available cash before the file is built rather than after the treasurer sees the balance move.

What processing an invoice actually costs

Any article recommending better controls has to be honest about the economics, and the economics of accounts payable are routinely misstated by the people selling into it.

Two of the pages currently ranking on the first page for this query give different numbers, both attributed to a source. Yooz states that manual invoice processing costs 12 to 15 dollars per invoice, citing the Institute of Finance and Management. Stampli states that invoices can cost in excess of 20 dollars to process, citing its own survey report. Those two claims differ by more than a third, and neither matches the benchmark that both are approximating.

APQC runs the Open Standards Benchmarking database that finance functions actually submit to. Its published measure, total cost to perform the process "process accounts payable" per invoice processed, gives a median of $6.00 on a sample of 5,846 organisations. Reporting on the same database, CFO.com puts the median at $5.83 across 1,485 organisations and notes that the bottom quartile spends $10 or more per invoice.

Both vendor figures sit above the worst-performing quartile of the real benchmark and are presented as the average. If you are budgeting a project on a 15 dollar baseline, you are almost certainly overstating the saving available from processing cost alone.

Which is the argument for moving the business case where the money actually is. Shaving two dollars off a six dollar unit cost on eleven hundred invoices a month saves around twenty-six thousand dollars a year. One duplicate payment of thirty thousand euros, one invoice paid into a fraudulent account, one quarter of undeducted credit notes: each of those is the same order of magnitude or larger, and each is a single event rather than a programme.

What a controlled payment run looks like in production

The pattern that works is not more approvers, it is exhaustive checking with human review reserved for exceptions.

At Astotel, an 18-hotel group in Paris, supplier price controls used to run by sampling, which is what every team does when volume outgrows attention. Checking every invoice line against negotiated prices surfaced around 400 euros of billing errors a month on a single supplier, close to 5,000 euros a year, on top of roughly two hours a day returned to the purchasing team.

"I save up to two days a month, and I spot errors I would never have seen on my own."

Valerie, Purchasing Director, Astotel

The important word in that sentence is never. Those errors were not hiding. They were ordinary-looking lines on ordinary-looking invoices, each individually plausible, which is precisely the category that sampling is structurally unable to find. The same logic applies line by line inside a payment batch.

Scale changes the arithmetic but not the principle. How Smartbox reconciles payments against invoices is a useful reference point for volume: the European gift box leader, operating in 14 countries with around 800 employees, multiplied reconciliation productivity by four, with each use case operational within six weeks.

"Phacet operates as an extension of our teams."

Mourad Meraou, Operations Director, Smartbox

At the other end of the size range, La Nouvelle Garde, a group of ten brasseries, recovered two days a week across the finance team and deferred planned hires. The common thread across all three is not the technology, it is the shift from reviewing a sample to reviewing exceptions, with the machine covering the full population and a human deciding only where something is flagged.

Choosing invoice approval software when the payment run matters

If the batch is where your exposure sits, the buying criteria change. Six questions separate tools that route approvals from tools that also control what gets paid. None of the six appears in the vendor material currently ranking for this query, which is worth knowing before you build a comparison grid from those pages: across the 7,682 words scraped on 20 September 2026, duplicate payment, IBAN and credit note each appear zero times.

• Does it see beyond the current invoice? Ask whether the tool can compare a proposed payment against invoices already settled in previous periods, not just flag duplicates within a single import.
• Does it detect a bank detail change, automatically, on every run? A field-level audit log is not the same thing as a blocking check.
• Can it net open credit notes against the batch before the file is generated? Many tools store credit notes correctly and still never apply them.
• Does it sort by due date and show the total against cash? Composition of the run is a treasury decision that most approval tools decline to take a view on.
• Does it explain why it flagged something? A held line with no reasoning gets released by whoever is under time pressure, which is everyone on payment day.
• Does it cover 100% of lines or a sample? This is the question that decides whether the other five matter, because a control that runs on 10% of the batch is a reporting feature.

Note what is not on that list. Automated invoice capture, approval routing, mobile sign-off and ERP sync are now commodity features present in every serious product in the category, and finance teams should assume them rather than evaluate them.

Frequently asked questions

How to approve an invoice?

Check the invoice against the purchase order and the goods receipt, confirm the prices match what was negotiated, verify the tax treatment and the payment terms, then record the approval against a named person with authority for that amount. Log it with a timestamp so the decision can be evidenced in an audit or a supplier dispute.

What is the best software for invoice processing?

There is no single best tool, because the category splits by what you need controlled. Products built around approval routing suit teams whose problem is slow sign-off. Products built around matching and anomaly detection suit teams exposed to error and fraud. Decide which failure costs you more before comparing feature lists.

Does QuickBooks have approval workflows?

QuickBooks offers approval capabilities that vary by plan and region, and many teams extend it with a dedicated tool for multi-step routing. Either way, approval routing inside an accounting system controls the invoice, not the payment batch. Duplicate detection against settled history and bank detail changes need a control layer above it.

What is invoice approval workflow?

An invoice approval workflow is the defined sequence an incoming supplier invoice follows from receipt to authorisation: capture, data extraction, matching against the order and receipt, routing to an approver based on rules, and recording of the decision. It ends at authorisation. The payment run that follows is a separate step with its own controls.

Approval and payment are two decisions, not one

The reason this gap persists is that both steps feel like the same event. An invoice gets approved, then it gets paid, and the second looks like the mechanical consequence of the first. It is not. Between the two sit a supplier master file that can change, a set of prior payments nobody re-reads, a pile of credit notes waiting to be matched and a calendar that nobody sorted.

The fix is not another approver in the chain. Adding a signature to a decision that was already correct changes nothing, and it slows a process that is measured on speed. The fix is a control that runs once, on the assembled batch, on every line, immediately before the file leaves for the bank, and that holds only what it can justify holding.

The teams that get there do it one job at a time rather than as a programme, which is why the accounts payable agent catalogue is organised by job rather than by module. Start with whichever of the four controls has already cost you money this year. You will know which one it is.