The Accounts Payable Process: What Actually Happens Between an Invoice and a Payment

An invoice for $18,400 arrives on a Tuesday in a sales rep's inbox, because that's who the supplier happened to email. The rep forwards it to their manager eleven days later. The manager forwards it to finance. Finance can't find a purchase order, so they email procurement, who says the order was verbal. By the time anyone confirms the goods arrived, the invoice is 34 days old, the terms were net 30, and the supplier has put the account on hold.

Nothing in that accounts payable process involved fraud, incompetence, or a system outage. Every person did something reasonable.

The process just had no defined entry point.

That's the thing worth understanding about the accounts payable process. It looks like a finance function, and the ledger entries certainly are. But most of what determines whether it works happens before finance sees anything, in places finance doesn't own and often can't see: a rep's inbox, a verbal purchase order, a manager's holiday.

The clock was running the whole time.

The accounts payable process in six stages

Strip out the software and the org chart, and the accounts payable process is the same six things happening to every invoice, in the same order, at every company.

What differs is which of them anybody owns.

Intake. The invoice arrives. Email, portal, post, or attached to a Slack message. This is the stage most companies leave undefined, and it is the one that generates the aging problem above. A single address that everybody uses beats a sophisticated capture tool that half the company routes around.

Capture and coding. Someone reads the document and turns it into structured data: supplier, invoice number, date, amount, tax, currency, general ledger account, cost centre. Manual keying is where transposition errors enter, and they're expensive later because a wrong invoice number defeats duplicate detection.

Matching. The invoice is checked against what was ordered and what arrived. More on this below, because it's the step people misunderstand most.

Approval. A human with authority agrees the company owes this money. The rules for who that is, and at what amount, are among the most useful things a finance team can write down.

Payment. The approved invoice joins a payment run, a rail is chosen, and money moves.

Archive. The invoice, the approval trail, the remittance advice, and the proof of payment are stored together, in a form that survives an auditor asking about a transaction from nineteen months ago.

Six stages, and the interesting part is the distribution of effort. Capture and matching absorb most of the manual hours, which is why accounts payable automation is usually sold on those two stages first. Intake and approval cause most of the delays, and they're barely a software problem at all: they're two decisions somebody has to make once and write down. Payment causes almost all of the losses.

The effort and the risk sit in different places.

Where the process actually breaks

Failures cluster. Once you name them, most stop being investigations and start being categories.

Look at what those have in common.

Almost none is an accounting error. Nobody debited the wrong account or misread a number. They're process gaps, and the distinction matters because the two have opposite remedies: an accounting error is fixed by being more careful, and a process gap is fixed by deciding something once and then never thinking about it again. Teams that treat the second kind as the first kind end up running training sessions about attention to detail, which changes nothing, and then running them again next year.

Three way matching, and the tolerances nobody writes down

The textbook version: match the purchase order, the goods receipt, and the invoice. If all three agree, pay.

The textbook version is also why matching has a reputation for being slow, because in practice all three almost never agree exactly. The supplier ships 98 units of the 100 ordered. Freight was added after the PO. The unit price moved by two cents because of a currency conversion.

A strict match rejects all three. A human then approves all three, every month, forever.

What separates a working AP function from a stuck one is that the working one has written its tolerances down.

Two-way matching, PO against invoice with no goods receipt, is the right choice for services, where there is nothing to receive. Using three-way matching on a consulting invoice produces a receipt document that somebody creates purely to satisfy the system.

That is worse than not having the control at all. A control everybody knows is theatre teaches people that controls are theatre.

There's a related on-chain version of the same idea. When a payment settles as a transaction hash rather than a bank line, the third leg of the match becomes the chain record, and the practical mechanics of that are covered in crypto reconciliation.

The invoice approval workflow is a document, not a feeling

Ask a finance lead who can approve a $50,000 invoice and you'll usually get a confident answer. Ask who can approve it when that person is on holiday and the answer takes longer. Ask what happens at $50,001 and the answer often reveals that the threshold was never written down at all.

An invoice approval workflow that works needs four things stated explicitly:

Who approves at each amount band. Not job titles that have drifted, but named roles that currently exist.

What happens on absence. A named delegate, with the delegation logged, and a time limit on it.

Which categories bypass the bands. Payroll taxes and rent don't benefit from a discretionary approval, and forcing them through one trains people to approve without reading.

Who can never approve their own request. This is the control that does most of the work against internal loss, and it's covered properly in payment fraud prevention.

The approval failure that recurs most often in practice is not a rejection. It is silence.

An invoice sent for approval and never actioned produces no alert in most systems, because from the system's point of view nothing happened, and systems raise alerts about events. Aging reports catch it eventually, which in practice means at the close, which in practice means after the due date. A rule that escalates after a set number of days catches it on day three.

Choosing a rail for each payment

The payment run is where AP stops being a document process and becomes a treasury one. Most teams have four or five options and use one out of habit.

Same Day ACH carries a per-payment limit of $1,000,000, in force since 18 March 2022. Nacha has approved an increase to $10,000,000 taking effect on 17 September 2027, so until that date a payment that has to go today and exceeds a million still needs a wire.

The comparison that matters for most AP teams is the domestic one, and it's laid out in wire transfer vs ACH. The wider map of what each rail is for sits in payment rails. If the supplier is abroad, the delay and the deductions have a specific cause, explained in correspondent banking.

Duplicate payments are a data problem before they're a control problem

A duplicate payment doesn't usually mean somebody paid twice on purpose. It means the system couldn't tell that two records were the same invoice.

The classic sequence: a supplier emails an invoice, then emails a statement listing the same invoice, then a chaser with the invoice attached again. Three documents, one obligation.

If the invoice number was keyed as INV-4471 the first time and INV4471 the second, no duplicate check will fire. The system is working exactly as designed.

The fixes are unglamorous and they work. Normalise the invoice number on entry by stripping spaces, dashes, and case. Block on the combination of supplier, amount, and invoice date, not on invoice number alone. Flag credit notes separately so a refund doesn't look like a duplicate. And check for duplicates at the point of payment as well as at entry, because an invoice can be entered twice under two supplier records for the same company.

What you need from a supplier before the first payment

Onboarding is part of the AP process, even though it usually sits with a different team. Getting it wrong doesn't show up until January.

For a US supplier: a completed Form W-9, bank details confirmed through a channel other than the one that sent them, and a decision about whether payments to this supplier are reportable. Nonemployee compensation goes on Form 1099-NEC, and the reporting threshold is now $2,000 for tax years beginning after 2025, raised from $600. The IRS says it may be adjusted for inflation from calendar year 2027. The filing date is 31 January.

For a supplier outside the US, the documentation and the withholding analysis are different, and they're set out in 1099 for foreign contractors and paying international contractors.

The operational point: collect the tax form before the first payment, not before the first filing deadline.

A supplier who's already been paid has no particular reason to return paperwork, and whatever bargaining position you had has gone with the money. Chasing thirty of them in the third week of January, while also closing December and preparing the filing, is how a small onboarding shortcut turns into the worst week of the finance year.

Where the accounts payable process hands over to the close

AP doesn't finish when the money leaves. The close needs the payable to be recorded in the right period, the accrual to be raised for goods received but not invoiced, and the subledger to agree with the control account.

The handover point causes a specific recurring argument: an invoice dated the 29th, received on the 3rd, for goods delivered on the 27th. It belongs in the earlier period because the goods arrived there, and the accrual exists precisely so that a slow supplier doesn't move your cost base. Teams that leave this to judgement each month get a different answer each month. The full sequence, including who owns which step and where the cutoff sits, is in month-end close.

One metric is worth tracking and most teams don't, and it is the honest measure of whether accounts payable automation has done anything: the proportion of invoices that clear without any human touch. Not cycle time, not cost per invoice, both of which are easy to game. Touchless rate tells you whether the tolerances, the PO discipline, and the approval bands are doing their job, and it drops immediately when any of them stops working.

When a supplier asks to be paid in stablecoins

It's now a routine request from suppliers in countries where receiving dollars through a bank is slow or unreliable, and it changes three things in the process above.

Matching is unaffected. Approval is unaffected.

Payment changes, because the settlement record is a transaction hash rather than a bank reference, and the archive has to hold that hash against the invoice, at the moment of sending rather than reconstructed later from a screenshot. The legal side, meaning when the obligation is actually discharged and what to write into the contract, is a separate question addressed in B2B crypto payments.

Practically, the requirement is that the payment run can produce the same evidence the bank run produces: who was paid, against which invoice, with what fee, at what rate, with a reference that survives. Tools built for this, VaultNow among them, handle payouts from a CSV or an address book with an address book and screening attached, which is the part that maps onto the supplier master you already keep.

Frequently asked questions

What are the stages of the accounts payable process?

Intake, capture and coding, matching, approval, payment, and archive. Intake and approval cause most delays, capture and matching absorb most of the manual work, and the payment stage is where nearly all of the financial loss happens.

What is three-way matching in accounts payable?

Checking the purchase order, the goods receipt, and the supplier invoice against each other before payment. It confirms that the company ordered the item, received it, and is being billed the agreed amount. For services, where nothing is physically received, two-way matching against the purchase order is the appropriate control.

What tolerance should be set for invoice matching?

We found no published standard figure. The approach that works in practice is to set a small percentage and a small absolute cap and apply whichever is lower, so that a small percentage variance on a very large order still gets reviewed. Over-deliveries and tax differences shouldn't be auto-accepted at any tolerance.

How do you stop the same invoice being paid twice?

The fix is in the data rather than in extra checking. Normalise invoice numbers as they are entered so that INV-4471 and INV4471 collide, match on supplier plus amount plus invoice date instead of relying on the number by itself, and keep one supplier record per legal entity so the same company cannot be paid under two identities.

What is the difference between accounts payable and procurement?

Procurement decides what to buy and agrees the price and terms. Accounts payable verifies that what was agreed is what was delivered and billed, then pays it. The purchase order is the document that passes from one to the other, which is why AP problems so often turn out to be missing purchase orders.

How long should an invoice take to approve?

Long enough to check it and no longer, which for a matched invoice within tolerance means it shouldn't need a human at all. The number worth watching is the share of invoices that clear without manual intervention, because it responds immediately when PO discipline or approval routing breaks down.

When does an invoice belong to the earlier period?

When the goods or services were received in that period, regardless of the invoice date or the date it reached you. That's what the accrual is for, and applying it consistently is what stops a supplier's invoicing speed from moving your reported costs.

What documents do you need from a supplier before paying them?

Bank details verified through a separate channel, and the relevant tax documentation. In the US that means a Form W-9 for domestic suppliers, collected before the first payment rather than before the filing deadline.

Most problems in the accounts payable process are decisions that were never made: where invoices arrive, what variance is acceptable, who approves at what amount, and what happens when that person is away. Each one is an afternoon's work to settle and a permanent source of delay while it stays open.

If part of your supplier base is being paid in stablecoins, the same discipline applies, and the evidence requirements are stricter rather than looser. VaultNow keeps payouts, invoicing, address screening, and team permissions in one place, so the payment stage produces the same audit trail your bank run does.

General information, current as at 31 August 2026. Not tax or legal advice. Thresholds and rail limits change, and the ones cited here carry their effective dates.