AS | Ankit Sarawagi|Founder, CFOmatrix·July 2026·9 min read | Finance SOP |
- Maker-checker is two people, not five. One person uploads the payment batch (maker), another approves and releases it in the bank (checker). No one pays alone.
- The founder is usually the checker. In most startups the finance person is the maker and the founder releases payments in the bank, so two sets of eyes see every rupee.
- The #1 fraud is a vendor bank-detail change. Never change bank details on an email alone. Verify by a call-back to a number already on file, with founder approval.
- Never share banking passwords or tokens. Shared credentials destroy the whole control, because you can no longer tell who did what.
- Capture the approval. Keep it in the tool’s audit log; if you approve on email or WhatsApp for speed, save that message back into the record.
| 2 People on every payment: a maker and a checker | 1 call-back To verify a vendor bank-detail change, to a known number | 0 Shared banking passwords or tokens between people |
What Maker-Checker Payment Control Means
A maker-checker payment control splits every payment into two hands. One person, the maker, prepares and uploads the payment batch in the bank. A different person, the checker, reviews it and approves or releases it. The point is simple: no single person can both create a payment and send the money out. That one rule stops most payment errors and almost all internal payment fraud, and it costs you nothing except a second click.
This is the payments version of the wider principle in our Finance SOPs & Controls guide: two sets of eyes on anything that moves money, with the minimum number of approvers. Payments are where that principle matters most, because the bank is the one place a mistake becomes cash out the door in seconds.
“On payments we always run maker-checker. One person uploads the batch, that is the maker. Someone else approves and releases it in the bank, that is the checker. In most startups the founder is the checker who releases the payment, because the founder wants to see the money before it leaves.”
Ankit Sarawagi, from running finance for lean startupsThe Payment Run Flow
Batch your payments. Running a scheduled payment run (weekly for vendors, monthly for reimbursements with the payroll cycle) is calmer and safer than paying ad hoc through the week. Here is the flow, with who does each step.
Every payment gets checked. There is no auto-approve-below-a-number free pass, because small payments are exactly where a fake invoice slips through. The check is cheap; make it the default for all of them.
Who Releases, and the Audit Trail It Leaves
The person who prepares the payment must never be the person who releases it. In most startups that means finance is the maker and the founder is the checker who releases. Even a one-person finance team never self-releases: finance does the action, the founder approves. And a related rule from good separation of duties, whoever negotiated a vendor’s terms should not also be the one who onboarded that vendor’s bank account.
- Prepares and matches invoices
- Verifies beneficiary details
- Uploads the batch to the bank
- Cannot release payment
- Reviews amounts and payees
- Approves sensitive items
- Releases the payment in the bank
- Cannot prepare the batch
- Bank maker-checker log: who uploaded, who released, when
- Approved invoice in the accounting tool
- Verification note for any bank-detail change
The record lives in two places: the bank’s maker-checker log (who released each payment, timestamped) and the accounting tool where the invoice is marked paid. Between them you can prove every payment was seen by two people. Startups rarely get caught for doing the wrong thing; they get caught for doing the right thing and never recording it.
The #1 Fraud: A Changed Vendor Bank Account
The most common payment fraud against startups is not a hacked bank account. It is an email that looks like it came from a genuine vendor asking you to update their bank details before the next payment. You pay the invoice as usual, the money lands in the fraudster’s account, and the real vendor calls a month later asking where their payment is. Verifying beneficiary changes is the control that stops it.
Do not reply to the email to “confirm”, and do not call the number printed in that email. Both just reach the fraudster. Use a phone number or contact you had before the request arrived. If you cannot reach a known contact, the change waits.
“The one that catches startups is the bank-detail change on an email. We never change a vendor’s bank account on an email alone. We call the vendor back on a number we already have, and the founder has to approve the change. That single habit has saved real money.”
Ankit SarawagiCommon Payment Frauds and the Control That Stops Each
Most payment fraud in a small company is one of a handful of patterns. Each has a lightweight control that shuts it down. You do not need a fraud department; you need these five habits.
| The fraud | The control |
| Changed vendor bank account | Call-back to a known number plus founder approval before any change |
| Fake or duplicate invoice | Pay only against an approved invoice matched to a real vendor and order |
| One person pays themselves out | Maker-checker: the maker cannot release; the checker cannot prepare |
| Someone logs in as finance | No shared passwords or tokens; each person has their own login and device |
| Payment to a brand-new payee | Positive pay or beneficiary verification, and founder sign-off for new vendors |
Never share banking passwords
Shared credentials quietly destroy maker-checker. If two people know the same login, the bank’s log can no longer tell you who released a payment, and the “two sets of eyes” become one person clicking twice. Each person gets their own bank user, their own password and their own device or token. Nobody logs in on someone else’s behalf, ever, not even in a hurry.
Capturing the Approval Into the Record
The cleanest place for a payment approval is inside a tool that already carries an audit trail: the bank’s maker-checker log, and the accounting system where the invoice is approved and marked paid. Both timestamp who did what, which is exactly what an auditor or a diligence team wants to see.
Real startups also approve on email, Slack or WhatsApp when speed matters, and that is fine, as long as you capture it back into the record. Save the approving message against the invoice in the accounting tool, or forward it into the file for that payment. An approval that lives only in a chat thread is an approval that will not survive a year, a laptop change, or an audit. Capture it once and it becomes documentation for free.
Payment controls are the process; your payments and authorisation policy is the rules. Keep the two in step, and do not rewrite the policy inside the SOP. See the CFOmatrix policy library for the matching template.
Lean Version, and When to Add a Step
Keep it as light as your team. The lean version is genuinely two people. Add steps only as the numbers and the headcount grow, never before.
- Maker = finance, checker = founder
- Weekly payment run
- Founder approves new vendors, salary and bank-detail changes
- Call-back to verify any bank change
- Large payments: add a second checker or a board threshold set by your SHA
- Higher volume: add a department-head approver so the founder is not the only checker
- More vendors: formal beneficiary master with periodic review
As you scale, the founder should not stay the only checker forever; a head of department can approve everyday payments while the founder keeps the sensitive items and the large ones. The principle never changes: two people, minimum approvers, every payment seen. For how this fits the wider control system, read the Finance SOPs & Controls guide.
“Payment controls are not bureaucracy. Two people on every payment, and a phone call before you ever change a bank account, is the cheapest insurance a founder will ever buy.”
Ankit Sarawagi, CFOmatrixFrequently Asked Questions
What is maker-checker in payments?
Maker-checker is a two-person control where one person (the maker) prepares and uploads the payment batch in the bank, and a different person (the checker) reviews and approves or releases it. No single person can both create and release a payment. In a startup the finance person is usually the maker and the founder is the checker who releases payments in the bank. It is the simplest, cheapest control that stops most payment errors and fraud.
How do startups control payments?
A lean startup controls payments with three things: maker-checker on the bank (one person uploads, another approves and releases), a rule that every payment is checked against an approved invoice and a known beneficiary before release, and founder approval for sensitive changes like new vendors, salary changes and bank-detail changes. Keep the approval and the payment trail inside the tools you already use so the record survives an audit.
How do I verify a vendor bank-detail change?
Never change a vendor’s bank details on the strength of an email alone, even if the email looks genuine. Verify by calling the vendor back on a phone number you already have on file, not a number given in the new email, and confirm the change with a known contact. Require founder approval for the change, and keep the record of who verified it and how. Vendor bank-detail change is the single most common payment fraud against startups.
Who should release payments in a startup?
The person who prepares the payment should not be the person who releases it. In most startups the finance person prepares and uploads the batch as the maker, and the founder is the checker who reviews and releases it in the bank. Even a one-person finance team never self-releases: finance does the action and the founder or a department head approves. This keeps two sets of eyes on every rupee leaving the company.
How do I prevent payment fraud in a small company?
Use maker-checker so no one person can pay alone, verify every vendor bank-detail change by a call-back to a known number with founder approval, never share banking passwords or tokens between people, pay only against an approved invoice and a beneficiary already on file, and use your bank’s positive-pay or beneficiary-verification features. Most startup payment fraud is a changed bank account or a fake invoice, and these controls stop both.
Where is the payment approval recorded?
The approval should live inside the tool that carries an audit trail: the accounting system or the bank’s maker-checker log, which timestamps who approved and released each payment. If you approve on email, Slack or WhatsApp for speed, capture that message back into the record by saving it against the invoice in your accounting tool, so the approval stays audit-defensible. Auditors and diligence teams ask for exactly this trail.
This is general educational information for founders, current to mid-2026, drawing on the author’s experience running finance for lean startups, and is not legal, tax or audit advice. Bank features such as positive pay and beneficiary verification vary by bank; confirm what your bank offers and verify the current position before acting on a specific matter.
Accounts Payable: Invoice to Payment
Finance SOPs & Controls for Startups (Pillar Guide)
AS | Founder, CFOmatrix | Finance Strategy & Equity Compliance CFOmatrix is a knowledge platform focused on how finance actually works inside growing companies. This SOP draws on hands-on experience building right-sized finance controls for lean startups, from payments and approvals to the audit trail that survives diligence. |