AP Approval and Payment Run Controls: The Matrix

The reason to fix accounts payable controls is not that you expect to be defrauded. It is that when a payment goes out that should not have, nobody can reconstruct who decided it should. That is a bad position with a bank, a worse one with an insurer, and an uncomfortable one at a review engagement where the practitioner asks who approves payments and the honest answer is “it depends”.

What follows is the control set we install. It is deliberately built to survive a company with three people in the finance office, because that is the usual case, and a control matrix that assumes six people is a matrix that gets abandoned in week two.

The four separable duties

Everything in this piece is an application of one idea. Paying a supplier is not one act, it is four, and the controls come from deciding which of the four the same person may hold.

Duty	What it actually is	Risk if combined with the next one
1. Set up the supplier	Creating or amending a vendor record, including the bank details payment will go to	Combined with 2: the person who invents a supplier can also invent its invoices
2. Approve the commitment	Agreeing the company will buy the thing, before it is bought	Combined with 3: the person who agrees to buy also confirms it arrived
3. Approve the invoice	Confirming the goods or services were received and the invoice matches	Combined with 4: the person who says an invoice is good also releases the cash
4. Release the payment	Authorising the actual movement of funds	Combined with 1: the payment can be redirected at source

The single highest risk combination in a small company is duty 1 with duty 4, and it is the one people worry about least, because setting up a supplier feels like administration rather than a financial act. It is not administration. The vendor master file is the only place in the system where a bank account number is stored, and a change to that field moves money without touching a single invoice.

Segregation by company size

The honest version. Nobody at this scale gets full segregation, so the matrix names which pairs to break first.

Company size	Realistic split	Non-negotiable separation	Accept and compensate
10 to 25 people, one bookkeeper	Bookkeeper holds 1 and 3. Owner holds 2 and 4.	Whoever changes vendor bank details never releases payments	Bookkeeper effectively holds invoice approval for small items. Compensate with a full transaction review at close.
25 to 50 people, bookkeeper plus office manager	Bookkeeper holds 3, office manager holds 1, budget holders hold 2, owner or controller holds 4	1 apart from 4, and 3 apart from 4	Budget holders approving their own department. Compensate with a variance review against budget by someone outside the department.
50 to 75 people, a small finance team	AP clerk holds 3, a separate person holds 1, budget holders hold 2, controller and owner jointly hold 4 above a threshold	All four separated for anything above the threshold	Emergency payments. Compensate with the exception log below.

The rule that survives every size is the same: the person who can change where money goes may never be the person who sends it. If you implement one thing from this piece, implement that.

The approval authority grid

This is the artifact a company can actually pin up. The values below are an example set to be calibrated to the business, not a recommendation. Calibrate them against the size of a transaction that would genuinely hurt if it were wrong, not against a round number that feels senior.

Transaction	Up to 2,500	2,501 to 15,000	15,001 to 75,000	Above 75,000
Purchase commitment, budgeted	Budget holder	Budget holder	Budget holder plus controller	Owner
Purchase commitment, unbudgeted	Budget holder plus controller	Controller	Controller plus owner	Owner, with a written note to the board or shareholders
Invoice approval, matched to a purchase order and receipt	AP, on the match	AP, on the match	AP, on the match, plus budget holder confirmation	AP plus controller
Invoice approval, no purchase order	Budget holder	Budget holder plus controller	Controller plus owner	Owner
New supplier setup	Independent of AP, always	Independent of AP, always	Independent of AP, plus controller	Independent of AP, plus controller and owner
Change to supplier bank details	Callback verification, always, at any amount	Callback verification, always	Callback verification, always	Callback verification, always
Payment release, scheduled run	Controller	Controller	Controller plus owner	Owner
Payment release, off cycle	Controller plus owner	Controller plus owner	Owner	Owner
Employee expense claim	Direct manager	Direct manager plus controller	Controller plus owner	Owner
Credit note or write off of a payable	Controller	Controller plus owner	Owner	Owner

Three notes on reading it.

Approval is per transaction, not per month. Splitting a 40,000 commitment into four 9,500 purchase orders to stay under a threshold is the most common way an authority grid is defeated, and it is usually done by someone acting in good faith who finds the process slow. Add a same-supplier aggregation review to the monthly close and the behaviour stops.

Approval means before, not after. An approval collected after the goods arrived is not an approval, it is a ratification, and it teaches everyone that the grid is advisory.

Bank detail changes have no threshold. That row is deliberately identical across all four columns. It is the only row in the grid where the amount is irrelevant, because the amount is not what is being authorised.

The vendor master file

Treat this as a controlled register rather than a list.

Control	Implementation	Evidence it happened
Setup requires a completed vendor form	Legal name, operating name, address, contact, bank details, sales tax registration numbers where applicable, and a signed statement of the banking information	The form, filed
Setup is performed by someone who cannot release payments	System role separation, not a promise	User access listing, reviewed quarterly
Bank detail changes trigger a callback	Call a number obtained from your own records, never a number in the email requesting the change	A dated note on the vendor record naming who was called and on what number
Duplicate detection before creation	Search on name, address and bank account before adding	The search, or a system that blocks duplicates
Dormant vendors are deactivated	Any vendor with no activity for a defined period is made inactive, not deleted	Quarterly dormancy report
Sales tax registration numbers are validated	Verified against the appropriate registry before the first input tax credit is claimed	A dated validation note. Confirm the correct verification route with your practitioner.
Employee and vendor address and bank overlap check	Compare vendor bank details and addresses against the payroll master	Quarterly exception report, signed off

The last row makes people uncomfortable and it should be run anyway. It is a five minute report, it finds legitimate matches far more often than illegitimate ones, and the fact that it runs at all is most of its value.

The weekly payment run

A scheduled run is a control in itself, because it converts every payment into either “in the run” or “an exception”, and exceptions can be counted.

Cut off. All approved invoices entered by a fixed time on a fixed day. Nothing entered after cut off goes in this week’s run.
Produce the proposed run. Filter on approved status and due date. Never on supplier pressure.
Three way match check. For anything with a purchase order, confirm the purchase order, the receipt and the invoice agree on quantity and price. Investigate mismatches, do not adjust them.
Duplicate scan. Same supplier, same amount, same invoice number, and separately same supplier and same amount within a short window. Duplicate payments are far more common than fraud and cost real money.
Reconcile the run to the cash forecast. The run total should appear in the disbursement row for that week. If it does not, one of the two is wrong and you want to know which before the money leaves.
Review and sequence. The controller reviews the proposed run against available headroom. If headroom is insufficient, sequence rather than skip: statutory remittances and payroll first, then suppliers whose terms carry a real consequence, then the rest with a note to the supplier.
Release. The authorised releaser opens the payment file, checks the total and the payee count against the reviewed proposal, and releases. A releaser who has not seen the reviewed proposal is a rubber stamp.
File the evidence. The proposed run, the reviewed run, the released confirmation and the bank confirmation, all in one place, dated.

Step 7 has a subtlety worth naming. The releaser should verify the count of payees as well as the total, because a run whose total is unchanged but whose payee count went up by one is exactly what an inserted payment looks like.

Exceptions, and the log that makes them visible

Off-cycle payments will happen. The control is not to forbid them, because forbidding them produces a workaround. The control is to make them visible and to count them.

Field in the log	Why it is there
Date and amount	Basic
Payee	To spot the same payee recurring off cycle
Who requested it	To spot the same requester recurring off cycle
Who approved it	To confirm the grid was followed
Reason it could not wait for the run	The reason is the data. “Supplier asked” is not a reason.
Whether it was a new payee	New payee plus off cycle plus urgency is the classic pattern and should require the owner every time

Review the log monthly and count the exceptions. A company running two or three exceptions a month has a working process. A company running fifteen does not have a payment run at all; it has a payment run and a parallel unofficial one, and the fix is usually to change the run frequency rather than to lecture people.

The payments that bypass all of this

Every company has them, and they are the reason a well designed AP process still misses spend.

Bypass channel	Control
Corporate credit cards	Statement reconciled monthly with a receipt for every line, approved by someone other than the cardholder. Card limits set to the smallest workable amount, and reviewed annually.
Pre-authorised debits	A register of every active debit authority, with the contract, reviewed quarterly. This register is almost never found to be complete on the first attempt.
Software and subscriptions on personal cards, reimbursed	Should not exist. Move them onto a company card or a supplier account before they become a continuity problem as well as a control one.
Payment processor fees netted from deposits	Reconciled gross, not net, so the fee is visible as an expense rather than buried in revenue
Owner payments made directly from the bank	Entered in the ledger the same week, with a note of what they were. The most common cause of an unexplained bank reconciliation item at year end.
Wire and instant transfer	Treat as off cycle by definition and log accordingly

Monthly control evidence

At close, the reviewer should be able to see all of the following without asking for anything.

The four payment runs for the month, each with its proposed, reviewed and released documents.
The exception log with a count and a monthly trend.
The vendor master change report for the month, with a callback note against every bank detail change.
The same-supplier aggregation review, listing any supplier whose total for the month crossed an authority threshold that no single transaction crossed.
The corporate card reconciliation, approved by someone who does not hold a card.
The AP aging tied to the general ledger control account.

If all six exist, the control set is running. If they exist for the first two months and then stop, the process was too heavy and needs cutting rather than enforcing.

What we do not do

We do not put in an approval step that nobody has time to perform, because an ignored control is worse than an absent one; it creates a documented expectation that is documented as unmet. We do not implement a purchase order system in a company that buys forty things a month. And we do not design a matrix around the assumption that a specific named person is trustworthy, because the matrix has to keep working after that person leaves, which is the only situation in which anyone ever reads it.

The AP Approval and Payment Run Control Matrix