What it means
A payment can be wrong because someone mistypes an account number, approves a fake invoice or changes a supplier record without checking, so maker-checker introduces a separate review before a sensitive action takes effect. The maker enters the proposed action, the checker examines it and approves or rejects it, and a system should record who did each step.
NIST's security-control framework discusses separation of duties to reduce misuse of authority, and the University of Pennsylvania's internal-controls guide explains how authorisation and separation of roles help prevent errors and misuse. These are principles, not proof that any particular bank workflow is safe, so the control must be designed around the actual transaction.
For a supplier payment, the maker may assemble the invoice, purchase order and receiving evidence, and the checker confirms the beneficiary, amount, purpose and approvals against reliable records. An approval button is not a review, because if the checker merely trusts the maker's note the second step adds little protection.
Supplier bank-detail changes deserve special attention, since a fraudulent email can appear to request a new account. The checker should use an independently verified contact method from existing records rather than simply replying to the message containing the change, and the process should preserve the original and new details with an audit trail.
Roles must be technically separate where possible, with each person having an individual account and appropriate permission level. Sharing passwords or asking the maker to approve through the checker's login destroys the control, and even if a platform permits self-approval, policy should prohibit it for covered transactions.
Set thresholds and scope based on risk, since a small routine reimbursement may use a simpler process than a large international transfer or a new beneficiary. Some firms require two approvers above a monetary threshold, and exceptions, emergency procedures and who can authorise them should be documented, because an urgent deadline should not erase every independent check.
The checker needs context, not just an amount: for a payment, show the invoice, vendor identity, bank account and prior approvals, and for a system change show the old value, new value and reason, because if these are hidden across separate screens reviewers may approve blindly. Good interface design supports effective control.
A checker should challenge discrepancies, pausing and investigating if invoice numbers repeat, prices differ from the purchase order or a bank account has changed, and rejection is a normal outcome of the workflow, not evidence of failure, so the reason and any resubmission should be recorded. A two-person process does not guarantee that fraud cannot happen, because the maker and checker could collude, both could misunderstand the same data, or a compromised administrator could bypass the workflow, so privileged access should be monitored, bank statements reconciled and audit logs reviewed.
Small firms may struggle to separate every duty, so the owner may check and approve payments prepared by a bookkeeper while someone independent reviews bank reconciliations, but a staffing gap should not be solved by using two accounts owned by one person. For illustration, if 12 of 1,000 proposed payments are rejected, the simple rejection rate is 1.2%, which does not say whether the other 988 were valid or whether a rejected payment was a harmless typo or attempted fraud, so maker-checker is useful when the second person has independent information and time to use it, and the process should be tested with actual errors and exceptions.
In practice
Real-world examples.
Example
One employee prepares a payment and another verifies its details before bank release. The checker compares the invoice, purchase order and receiving note with the beneficiary account before approving.
Example
A checker independently confirms a supplier's bank change using a known phone number. The number comes from the existing vendor record, not from the email asking for the change, and the call is noted in the audit trail.
Example
An approver rejects a duplicate invoice and records why it was returned. The maker can then correct the batch, and the rejection reason is later used to improve the invoice-matching routine.
Formula
Calculation
Illustrative rejection rate = Rejected submissions / All submissions x 100. Example: 12 / 1,000 x 100 = 1.2%. The rate alone does not measure control quality or fraud prevented.
Worked example of value protected. Suppose the 12 rejected payments were reviewed, and 9 were typing errors worth $2,000 each while 3 were duplicate invoices worth $15,000 each.
- Error value stopped = 9 x $2,000 = $18,000.
- Duplicate value stopped = 3 x $15,000 = $45,000.
- Total value stopped before release = $18,000 + $45,000 = $63,000, so the average per rejection is $63,000 / 12 = $5,250.
These figures show the cost of errors avoided, but they do not prove how many losses would have occurred without the control.Case study
Seen in the real world.
This illustrative and entirely fictional case follows Palm Freight, an invented logistics firm. A bookkeeper receives an email requesting a supplier bank change and enters it for review. The checker calls the supplier using a number already in the vendor record, discovers the request is false and rejects the change. The case illustrates independent verification, not a promise that the control prevents every attack.
Watch out
Common mistakes.
- Approving a payment without reviewing the beneficiary, evidence and amount.
- Sharing login details so the same person can act as maker and checker.
- Treating urgent transactions as a reason to bypass all independent checks.
Questions
People also ask.
What is maker-checker?
A process where one person prepares a transaction and another independently reviews and authorises it.
Where is it used?
Often payments, supplier bank changes and sensitive system updates.
Why use it?
It can catch errors and discourage misuse, though it cannot eliminate all fraud or collusion.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%