AP Process Design: Approval, Matching, and Payment Runs

Executive summary

An accounts payable process earns its keep by doing four things: paying only what was ordered and received, paying it once, paying it on the due date, and telling the cash forecast what is coming. Every control in the process serves one of those four. Controls that serve none of them are friction.

The design choices are few: which invoices get a 2-way or 3-way match, who approves what and up to what amount, how often payments go out, how duplicates are caught before and after payment, and how receipts not yet invoiced are accrued. Each has a cash consequence you can size. For example, a weekly payment run on a business with $100,000 of daily payables pays invoices an average of three days early, tying up about $300,000.

The first move is to measure the current process: how many invoices fail matching, how long approval takes, how many payments were duplicates or errors, and how old your GRNI is.

When to use this

Use this guide when:

• Invoices are stuck waiting for approval and suppliers are calling.
• Month-end accruals are a scramble and surprises keep appearing after close.
• You have found a duplicate payment or an overpayment, or suspect there are more.
• Payment runs follow the calendar rather than due dates.
• The cash forecast misses on disbursements.
• You are changing ERP, adding an AP automation tool, or reorganizing the finance team.

Do not start with a tool selection. If the purchase order, receiving, and vendor master data are unreliable, automation will make the wrong payments faster.

AP building blocks: 2-way and 3-way match, approvals, payment runs

Matching: 2-way and 3-way

2-way match:  Invoice  =  Purchase order
3-way match:  Invoice  =  Purchase order  =  Goods receipt (or service acceptance)

A 3-way match confirms that the price and quantity on the invoice agree with the order, and that the goods or service were received. A 2-way match confirms only that an order exists and the invoice agrees with it. Use the stronger check where the risk is higher:

Define tolerances in advance. For example: an invoice price within 2% or $50 of the PO price (whichever is lower) posts automatically, and quantity must not exceed received quantity. Choose tolerances from your own variance history. The numbers here are examples, not recommendations.

Approval matrix

An approval matrix says who can approve an invoice, by type and by amount. It also separates duties so that no one person can create a vendor, enter an invoice, approve it, and release payment.

Principles that make a matrix work:

• Approve at the PO where there is one, then do not re-approve a matched invoice, only exceptions. Approving twice is the main reason AP backs up.
• Name a delegate for every approver. An approver on leave should not freeze payments.
• Set a service level for approval (for example, two business days) and escalate automatically when it lapses.
• Segregate duties: vendor master changes, invoice entry, approval, and payment release belong to different people. For small teams, add a compensating control, such as an independent review of vendor changes and the payment file.
• Bank detail changes require call-back verification to a known number, not to the number in the request.

Payment run cadence

A payment run selects approved invoices and pays them. The selection rule and the frequency determine how early you pay.

If a run pays every approved invoice due before the next run,
average days paid early = (Run interval in days − 1) ÷ 2
Cash tied up = Average days early × Daily payables

With payables of $36.5M a year ($100,000 per day):

The cost looks small next to the risks of getting AP wrong, so cadence is rarely the first priority. It becomes one when payables are large, or when you are paying early to hit a fixed run date and receiving nothing for it. Practical designs:

• Weekly run, selected by due date. Pay only invoices due before the next run, and release exceptions by name.
• Daily or twice-weekly runs for critical suppliers whose terms are tight.
• Separate run for early-pay discounts so the decision to pay early is deliberate, priced, and approved.
• A cut-off for new invoices (for example, approved by Tuesday noon for Thursday release) so the run list is final before payment.

Duplicate payment controls

Duplicates come from the same invoice entered twice, an invoice paid and then paid again from a statement or reminder, or credit memos never applied. Controls, in order of value:

1. Block at entry. Reject invoices that match on supplier plus normalized invoice number, or supplier plus amount plus date. Normalize before comparing: strip spaces, hyphens, leading zeros, and prefixes, and compare case-insensitively.
2. Require unique references. Do not allow blank invoice numbers. For suppliers who send none, generate a reference from date and amount, and flag it.
3. Check the payment file before release for same supplier, same amount, within a window you choose.
4. Pay from invoices, not statements. Use statements to reconcile, and never to initiate payment.
5. Run a post-payment scan monthly: same supplier and amount within 90 days, near-matching invoice numbers, and unapplied credits. Recover what you find, and write down the cause.

Example of why normalization matters. These three entries look different: INV-10442, 10442, inv 10442 . After removing prefix, spaces, and hyphens and lowering case, all become 10442. If each carries $18,450.00 for the same supplier, a plain exact-match rule passes all three, and a normalized rule flags the second and third.

Accruals and GRNI hygiene

GRNI means goods (or services) received, not yet invoiced. The receipt creates an obligation. If the invoice is not on hand at month-end, the cost and liability must be accrued, or the period is understated.

Rules for keeping GRNI clean:

• Receive promptly. Goods received on the dock but not booked until days later create unrecorded liabilities and failed matches.
• Review GRNI monthly by age. Old items are errors: a receipt booked against the wrong PO, a supplier that billed under a different reference, a short delivery that was never closed, or an invoice sitting in someone's inbox.
• Reconcile GRNI to the receiving log and to open POs, not just to the ledger balance.
• Accrue services from the budget owner's confirmation of work done, not from the PO total.
• Reverse and re-accrue under a documented routine so that accruals do not stack up.

Worked example (illustrative)

The numbers below are made up to show the method. They are not benchmarks.

Matching

PO for 1,000 units at $4.00 = $4,000. Receiving log shows 980 units. Invoice shows 1,000 units at $4.10 = $4,100.

• Quantity: invoiced 1,000 versus received 980. Fails; hold the 20 units until received or credited.
• Price: $4.10 versus $4.00 is $0.10 per unit. On 1,000 units that is $100, or 2.5% of the PO value. With a tolerance of 2% or $50 (whichever is lower), it fails.
• Payable on the evidence: 980 × $4.00 = $3,920, not $4,100. Pay-as-invoiced would overpay by $180 (4,100 − 3,920) on one invoice.

Both exceptions go to named owners: Receiving for the 20 units, Purchasing for the price.

GRNI aging

At month-end, the GRNI balance is $1.9M:

The 0 to 30 day bucket is normal timing: invoices are on their way. The $0.3M older than 60 days is where errors live. Review each line: is the invoice received but unmatched, was the receipt booked wrong, or was the delivery short? The review is worth doing because every item either becomes a payable, a correction, or a reversal.

Diagnostic questions

Answer these from the ERP and AP subledger. Most take under an hour each.

1. What percentage of invoices match automatically on the first pass, and what are the top three exception reasons?
2. What is the median and the 90th percentile of days from invoice receipt to approval?
3. Which invoices have no PO, and why?
4. Who can create or change a vendor, and who can release a payment? Are these the same person for any supplier?
5. How are bank detail changes verified?
6. When is the payment run, and is the selection rule by due date or by the calendar?
7. How many duplicate or erroneous payments were found in the last 12 months, and how were they found?
8. What is the GRNI balance, how old is it, and who reviews it?
9. How many invoices were entered after month-end that belong to the prior month?
10. Are goods received into the system on the day they arrive?
11. Does the AP subledger reconcile to the general ledger at month-end?
12. Does the 13-week cash forecast use AP detail, or a percentage of last period?

Reading answers: a low first-pass match rate points to PO and receiving quality. A long approval time points to the matrix. Duplicates found by suppliers rather than by you point to missing controls. Late-entered invoices point to GRNI and accrual gaps.

The framework: four questions every payment must pass

An invoice that passes all four is paid without a human touch. One that fails goes to an exception queue with a named owner and a time limit. The design goal is to move people's time from checking clean invoices to resolving the exceptions.

Step-by-step: a 60-day AP redesign

Weeks 1-2: Baseline

1. Reconcile the AP subledger to the GL. Owner: Controller.
2. Measure first-pass match rate, approval cycle time, exception reasons, and GRNI aging. Owner: AP lead. Output: one-page baseline.
3. Run a duplicate scan on the last 12 months of payments. Owner: Controller. Output: list of recoveries, with causes.
4. Review segregation of duties against the vendor master and payment release rights. Owner: Controller.

Weeks 3-4: Quick fixes

5. Turn on the entry-time duplicate block with normalization.
6. Set tolerances and route out-of-tolerance invoices to named owners with a two-day limit.
7. Add delegates to the approval matrix and an automatic escalation.
8. Require call-back verification for any change to bank details.

Weeks 5-8: Structure

9. Adopt the matrix in writing, approved by the CFO, and load it into the system.
10. Change the payment run to select by due date, with a cut-off and a separate early-pay run.
11. Start the monthly GRNI review and set an age threshold above which an item needs an explanation.
12. Feed the forecast (next section) from the approved-unpaid list.

Linking AP to the cash forecast

The 13-week cash flow forecast disbursements line is only as good as the AP detail behind it. Build it in layers, from most certain to least:

Example (illustrative): for the next four weeks, approved-and-due invoices are $0.9M in week 1 and $0.7M in week 2, a total of $1.6M. The forecast should show those as firm, apply your usual approval-to-payment lag to the matched queue, and move the exception queue out by the historical resolution time. GRNI older than 30 days that is not an error is future AP, and belongs in later weeks by expected invoice date plus terms.

Two disciplines make the link hold. First, do not change payment dates in the run without updating the forecast the same day. Second, compare the forecast to actual disbursements weekly and record why they differed (a held invoice, an early-pay decision, a late invoice). The causes tell you which part of the AP process is unreliable.

Templates

Invoice exception log (copy into a spreadsheet)

Payment run checklist

1. Selection rule applied (due before next run) and exceptions released by name.
2. Duplicate check on the payment file passed.
3. Bank detail changes in the last 30 days independently verified.
4. Run total agreed to the forecast and to approved-unpaid.
5. Release approved by a person who did not create the run.
6. Remittance advice sent to suppliers.

GRNI review sheet

Metrics and KPIs

Setting targets without invented benchmarks. Start from your own baseline and set targets as a share of your own exceptions you can remove. For example, if the top exception cause is "no PO," the target is set by the share of that spend you can bring onto POs. For external reference, use a named public source or a peer group you can identify, and otherwise leave the benchmark out.

Common mistakes

1. Matching everything the same way. Three-way matching low-value items costs more than the risk it removes, while two-way matching inventory misses short deliveries.
2. Re-approving matched invoices. If the PO was approved and the match passes, the invoice does not need a second sign-off. Exceptions do.
3. Tolerances set by feel. Too tight and the queue floods; too loose and overpayments pass. Set from the variance history.
4. No delegates. Approvals pile up whenever someone travels.
5. Exact-match duplicate checks. Suppliers' references vary in format, so normalize.
6. Paying from statements or emailed reminders. This is how an invoice gets paid twice.
7. Ignoring old GRNI. It looks like a timing item but usually hides errors that later surface as write-offs or surprises.
8. Forecasting disbursements from last month. The AP detail already tells you what is coming; use it.

AI prompt assistance

AI is useful for preparing analysis and drafting messages. It does not replace checking the numbers. Supply the data yourself and verify the output against the AP subledger before acting.

1. Scan payments for possible duplicates.

I will paste 12 months of paid invoices (supplier, invoice number, invoice date, amount, payment date). Normalize invoice numbers by removing spaces, hyphens, prefixes, and leading zeros, lowercased. List all pairs with the same supplier and same normalized number, and all pairs with the same supplier and amount within 90 days. Show the reason for each flag.

Check: open ten flagged pairs in the ERP and confirm they are true duplicates before requesting any refund.

2. Analyze exceptions.

Here is the invoice exception log with free-text notes. Tag each with one cause: price variance, quantity variance, no PO, no receipt, duplicate suspected, coding error, other. Return a count and dollar total by cause, and name the top two causes by dollars.

Check: spot-check ten rows and confirm cause with the owner before changing tolerances or policy.

3. Draft the approval matrix.

Using the spend categories and approval limits I list, draft an approval matrix with a delegate column and segregation-of-duties notes. Flag any combination where one person can create a vendor and release payment.

Check: the CFO and Controller approve the matrix, and your auditors review it where applicable.

Implementation guide

Governance: the CFO owns the approval matrix, the Controller owns process and controls, AP owns execution, Purchasing and Receiving own PO and receipt quality, and Treasury owns payment release. Report first-pass match rate, exceptions by cause, duplicate recoveries, and GRNI aging to the CEO monthly.

Downloadable assets

The exception log, payment run checklist, and GRNI review sheet above are designed to be copied into a spreadsheet.

Related resources

• Working capital: 3 levers that move your cash cycle: where payables sit in the cash cycle.
• The working capital playbook: the levers in one operating plan.
• How to reduce DSO: a 90-day collections plan: the receivables side.
• AR aging analysis and collections prioritization: aging method that also works for AP.
• Inventory optimization: turns, safety stock, and excess: where receipts and purchase orders originate.
• 13-week cash flow forecast template: the disbursements line.

Frequently asked questions

What is the difference between 2-way and 3-way matching?

A 2-way match compares the invoice to the purchase order; a 3-way match also compares it to the goods receipt or service acceptance. The third check confirms that what was billed was actually received. Use 3-way matching for inventory and materials, where receipt can differ from the order, and lighter matching for contract-based recurring items or low-value purchases.

What is an AP approval matrix?

An AP approval matrix defines who can approve an invoice, by spend type and amount. A good one approves at the purchase order and reviews only exceptions afterward, names a delegate for every approver, sets a time limit with automatic escalation, and separates vendor master changes, invoice entry, approval, and payment release so no single person controls the whole chain.

How do you prevent duplicate payments?

Block duplicates at invoice entry by matching on supplier plus a normalized invoice number, so variants like INV-10442 and 10442 are caught. Beyond that, forbid blank invoice numbers, check the payment file for same supplier and amount before release, pay from invoices rather than statements, and run a monthly post-payment scan to recover anything that slipped through.

How often should you run payments?

Run payments as often as the cost of paying early justifies. A run that pays everything due before the next run pays invoices early by about half the run interval, so a weekly run ties up roughly three days of payables. Weekly runs selected by due date suit most teams, with faster runs for critical suppliers and a separate, deliberate run for early-pay discounts.

What is GRNI and why does it matter?

GRNI means goods received, not invoiced: a receipt has created an obligation, but no invoice is booked. If it is not accrued at month-end, costs and liabilities are understated. Review GRNI monthly by age, reconcile it to the receiving log and open purchase orders, and investigate old items, because they usually indicate wrong receipts, short deliveries, or unmatched invoices.

How this works in a System of Performance

AP evidence lives in different places: the PO in purchasing, the receipt on the dock system, the invoice in the inbox, the approval in email, and the payment in the bank file. A Performis routine can take on a recurring job like this, with the scope and fit agreed with you: it works from the records your team supplies, prepares the work for your named reviewer, and keeps each approval on record. If you want to see where your payables process leaks cash, bring it to us as a launch partner.