Accounts payable and payment controls
What Is Maker-Checker? Payment Control Guide
Direct answer
Maker-checker is a control in which one authorised person prepares or changes a transaction and another independently reviews and approves it before release. In accounts payable, the maker may build a payment batch while the checker verifies the batch, beneficiary and supporting approvals. The control works only when roles, evidence, access and override handling preserve genuine independence.
Also known as: four-eyes control, dual approval control.
Key takeaways
- Maker-checker separates preparation from approval; two clicks by people sharing the same unchecked evidence do not create a strong control.
- The checker reviews risk-relevant facts and exceptions, not just the batch total.
- Approval thresholds, prohibited role combinations and emergency procedures are internal policy choices.
- Changes to beneficiary data and payment instructions should trigger renewed checks.
- After release, capture bank status and UTR data so approval evidence connects to reconciliation.
How maker-checker segregation works
The maker assembles data or initiates an instruction. The checker sees the source evidence, tests defined attributes and either approves, rejects or returns it. A payment authoriser may be the checker or a separate role, depending on system and policy. The maker must not approve the same transaction through another account or shared credential.
Operational guidance: apply the control where error or misuse could have material consequences, such as vendor creation, bank-detail change, invoice override and payment release. RBI has directed banks to use maker-checker or double scrutiny in specific NEFT branch-processing contexts. That official example illustrates the control concept; it does not impose this article’s corporate approval matrix on every business.
Maker-checker across a payment lifecycle
- AP selects due, approved liabilities and excludes blocked or disputed items.
- The maker creates the batch from system records without re-keying beneficiary data where practical.
- Automated checks flag duplicates, recent master changes, unusual values and unsupported overrides.
- The checker compares batch totals, sampled or risk-selected lines, beneficiary-change evidence and approval status.
- The authorised approver signs under the applicable value and risk threshold.
- The bank instruction is released through separate credentials and the result is captured.
- Failed, returned and edited payments re-enter approval rather than bypassing the control.
- Bank debits, statuses and UTR references are reconciled to the approved batch.
System-enforced state transitions are preferable to an informal message saying “approved,” because they preserve version and identity.
Example payment approval matrix
Illustrative internal policy, not a statutory threshold:
| Payment risk | Maker | Required checker or approver | Extra control |
|---|---|---|---|
| Up to ₹2 lakh; unchanged beneficiary | AP payment analyst | Treasury manager | Batch and exception review |
| Above ₹2 lakh to ₹10 lakh | AP payment analyst | Head of treasury | Line-level beneficiary and support review |
| Above ₹10 lakh | Treasury analyst | Head of treasury and CFO | Dual release under bank mandate |
| Any recent bank-detail change | Person independent of master-data maker | Head of treasury | Revalidation and cooling or enhanced review under policy |
| Emergency or manual payment | Designated treasury maker | CFO or documented delegate | Reason, evidence and next-day review |
Design thresholds around risk and authority. Do not split payments to fit a lower band.
Treasury payment-run example
Fictional example: Harborline Retail’s maker prepares a Friday run of 24 supplier payments totalling ₹38.6 lakh. The exception report shows one ₹6.4 lakh beneficiary changed two days earlier, one ₹1.8 lakh invoice released through a match override and two duplicate-reference warnings.
The checker clears the duplicate warnings after finding one cancelled draft and one legitimate invoice from a different supplier. The checker returns the ₹1.8 lakh line because override evidence lacks buyer approval. For the changed beneficiary, treasury rechecks the previously validated supplier contact and bank-displayed account name, then routes the ₹6.4 lakh line to the head of treasury under the matrix. The final approved batch contains 23 payments totalling ₹36.8 lakh. The rejected line is not manually added at the bank; it must re-enter the controlled workflow.
Failure modes that weaken maker-checker
- The maker and checker share credentials, devices or authentication tokens.
- The checker sees only a total and cannot inspect changed beneficiary or invoice evidence.
- A maker can edit the batch after approval without invalidating that approval.
- Urgent payments routinely bypass the workflow and are never reviewed afterward.
- Approvers accept payment splitting that avoids their threshold.
- Departed or transferred employees retain incompatible roles.
- The bank upload differs from the approved ERP batch and no hash or total comparison detects it.
- Rejected or returned payments are re-released without renewed approval.
Count control effectiveness by prevented or resolved exceptions, access reviews and traceable approvals-not by the number of approval clicks.
Evidence the checker should leave
| Evidence | Why it matters |
|---|---|
| Batch identifier, version, count and total | Defines exactly what was approved |
| Maker, checker and authoriser identities with timestamps | Demonstrates role separation |
| Exception report and resolutions | Shows review focused on risk |
| Beneficiary-change verification | Supports destination review |
| Bank release status and UTR | Connects approved instruction to execution |
| Rejected and returned lines | Prevents incomplete items disappearing |
Retention periods and audit sampling should follow the organisation’s legal, contractual and records requirements.
Frequently asked questions
Is maker-checker the same as dual authorisation?
They overlap, but maker-checker describes preparation plus independent review. Dual authorisation may require two approvers after preparation. Define each system role explicitly.
Can the checker be the maker’s manager?
Often yes if the manager has appropriate authority, access and time to review independently. Reporting seniority alone does not make an approval effective.
Does every payment need the same approval level?
No. A documented matrix can scale review by value, beneficiary change, payment type and exception risk, subject to company authority and bank mandates.
What happens when an approved batch changes?
Material edits should invalidate approval and create a new version for review. Otherwise the released instruction is not the transaction the checker approved.
Can automation replace the checker?
Automation can run deterministic checks and select exceptions. Accountability for releases, overrides and control design still needs authorised ownership under company policy.
Sources and further reading
- Reserve Bank of India: NEFT - Correct IFSC in funds-transfer transactionsVerified Jul 25, 2026
- Reserve Bank of India: Introduction of beneficiary bank account name look-up facility for RTGS and NEFTVerified Jul 25, 2026
Educational disclaimer: This material is general information, not legal, tax, or accounting advice. Check current official guidance and your facts with a qualified professional.
From definition to workflow
Apply this concept with connected finance operations
Finnoto connects source records, approvals, reconciliation evidence, and exception ownership so teams can move from knowing the rule to operating the control.
Explore accounts payable controls