Payment Controls for Accounts Payable: A Bookkeeper's Checklist

Payment controls are where a clean set of books meets real money. A ledger can reconcile perfectly and still be paying the wrong vendor, twice, or to the wrong bank account. This is our checklist for payment controls in accounts payable, written from the ledger side rather than the software side.

What payment controls are actually protecting

The threat is rarely dramatic. It is a duplicate invoice paid in a busy week, a vendor whose bank details were changed by email, or a payment run approved by the same person who keyed it. Each of these posts a perfectly valid-looking journal.

The ledger will not flag any of them. Controls have to catch what the double entry cannot, because the books stay balanced either way.

Start with segregation of duties

The core rule: the person who keys a vendor invoice should not be the person who approves it, and neither should release the payment. In a small practice that is hard, so compress it rather than skip it.

A workable minimum is two people: one keys and reconciles, one approves and pays. Where only one bookkeeper exists, the owner reviews the payment run before release, and the bank reconciliation is reviewed by someone else monthly. Document who does what, even in a two-person firm.

Approval limits and the payment run

Set a monetary threshold above which a second approval is required. The threshold depends on the business; what matters is that it exists, is written down, and is enforced by the system rather than by memory.

Run payments on a fixed schedule, not ad hoc. A weekly or fortnightly run gives you a natural checkpoint: a single list, reviewed against open payables, approved once, released once. Off-cycle payments should be rare and require a stated reason.

Verify vendor bank details before first payment

Verify bank details on a known phone number, not one supplied in the same email that requested the change. This single habit stops most payment fraud. Log the verification in the vendor record with a date and initials.

Treat any change of bank details as a red-flag event. Confirm it independently, and consider a small test payment for new vendors. If a change request arrives by email alone, it is unverified, whatever the letterhead looks like.

Keep the audit trail inside the ledger

Every control should leave evidence in the books: who keyed the invoice, who approved it, who released the payment, and when. If your accounting package supports approval workflows and user-level permissions, use them; if not, keep a signed payment run sheet filed with the month's working papers.

The audit trail is also what makes the close faster. When a payment is questioned later, you answer from the ledger and the working papers, not from memory.

What this does for the reconciliation

Good payment controls shrink the bank reconciliation. Duplicate payments and unapproved disbursements are the items that turn a reconciliation into an investigation. With controls upstream, the reconciliation becomes what it should be: a routine match of ledger to bank.

It also protects the opening balances. A payment made in error and later recovered still has to be tracked through a suspense or debtor account until the money returns. Controls prevent the mess; the ledger only records it.

Review the controls themselves

Once a year, review the vendor master for dormant accounts, check that approval limits still match the business, and confirm that no single user has accumulated keying, approval, and payment rights. Access creep is quiet and common after staff changes.

Payment controls are not a software feature. They are a procedure the software helps enforce, and the working papers should show that the procedure ran every month.