Maker-Checker for Vendor Payments: How Small Finance Teams Can Separate Preparer and Approver

Maker-checker is an internal-control principle: the person who prepares a payment (the maker) and the person who approves it (the checker) must be different people. In a small finance team you can still apply it by separating roles by stage rather than by headcount, and the checker can sit outside finance, such as an ops lead or the founder.

In short:

• Separate roles by stage (prepare, approve, release funds), not by how many people are on the team.
• The checker can come from outside finance, especially for large amounts. Set thresholds so small payments do not queue up.
• If there is no second person, use compensating controls: low limits, notifications, and a regular review.

Want to see how invoices and vendor approvals can run in one flow? Take a look at the Monit Account Payable page.

Why Do Vendor Payments Need Maker-Checker?

Illustrative example: Dina is the only finance person at a 25-person startup. Every week she receives vendor invoices, enters them into a spreadsheet, prepares the transfer, and presses pay herself. The founder trusts her, and so far nothing has gone wrong.

Then one day an email arrives that looks like it came from a regular vendor: "Please send the next payment to our new bank account." Dina is racing to close the month, the email looks perfectly normal, and nobody else sees it before the transfer goes out.

A story like this does not have to end badly, but it shows the gap: there is no second pair of eyes between the decision and the money leaving. It is not about Dina being careless. Anyone working alone under deadline pressure can miss something like this. Maker-checker exists to close that gap. How to verify a bank-account change is covered in this guide to vendor bank account verification (in Indonesian).

If you want the same role separation for employee claims, see our guide to employee expense reports.

Wondering whether Monit's approval flow can follow your team's structure? Talk to the Monit team.

What Are a Maker, a Checker, and a Releaser?

• Maker: the person who creates or prepares the transaction, for example by entering the invoice and drafting the payment instruction.
• Checker: the person who reviews and approves the maker's work. The most basic requirement is that this is not the same person as the maker.
• Releaser: the person who executes the payment once it is approved. In small teams this role is often combined with the checker or the maker, and you should be aware of the risk that creates.
• Segregation of duties (SoD): the internal-control principle that no single person should hold every sensitive stage of one transaction.
• Threshold: the amount limit that decides the approval route. A Rp1,500,000 payment does not need the same route as Rp150,000,000.
• Compensating control: an alternative control you put in place when ideal separation of duties is not possible, such as a weekly review by the business owner.

Which Maker-Checker Pattern Fits a Small Team?

Before choosing a pattern, settle these four criteria, because they decide how strict the route needs to be:

1. Who has access to the bank account or the pay button? The fewer people, the more important extra controls become.
2. How large is each transaction and the monthly total? Large amounts call for an authorized checker, not just a peer.
3. How often do vendors change or vendor data get edited? Data changes are a weak point.
4. How quickly must payments usually go out? If it is always urgent, design the exception route up front instead of letting it become a shortcut.

Based on these criteria, the four patterns below are a starting point. The amounts and roles in the table are examples only; adjust them to your company's risk profile.

The first pattern is the one most startups and SMEs need. The founder does not have to understand accounting detail. They are only asked to check three things: who the money is going to, how much it is, and whether there is evidence the work was done.

How Do You Run Maker-Checker for Vendor Payments?

Here is a practical flow you can write down as a one-page SOP.

1. The maker prepares the payment package

• Owner: AP or finance staff.
• Trigger: a vendor invoice arrives.
• What happens: enter the invoice, attach the PO or contract and proof that the goods or services were received, then draft the payment instruction with the amount, destination account, and due date.
• Evidence: the invoice and attachments are linked to a single payment record.

2. The system or the SOP sets the route by threshold

• Owner: the finance lead and the business owner (set once, review each quarter).
• Illustrative example: up to Rp5 million needs one checker from finance or ops; Rp5 million to Rp50 million needs the finance lead as checker; above Rp50 million adds approval from a director or founder. These numbers are examples only and must be adjusted to your company's scale.

3. The checker reviews with a checklist

• Owner: the designated checker.
• What to check: whether the invoice matches the PO or contract and the receipt of goods (see this three-way matching checklist, in Indonesian); whether the destination account matches the one on record or has changed; whether the amount and due date make sense; whether the vendor has already been paid for the same invoice; and whether any tax question needs to go to your tax team.
• Evidence: the checker leaves a short comment or ticks the checklist, not just a click on approve.
• Exception: the vendor's bank account has changed. Verify through a contact you already know before approving.

4. The releaser executes the payment

• Owner: whoever is authorized to release funds. Ideally not the maker.
• What happens: confirm that the payment executed matches the one that was approved, then keep the transfer proof.

5. Recording and reconciliation

• Owner: the accountant or finance.
• What happens: match outgoing payments against invoices in the books. Differences are flagged and followed up.

6. Periodic review

• Owner: the finance lead and the business owner.
• What happens: each month, sample about 10 payments and check whether any maker also acted as checker, whether any vendor bank account changed without verification, and whether any approval was given too fast to be credible.

Exceptions to design in from the start:

• An urgent payment and the checker is unavailable. Name a written delegate (who, up to what amount, until when). Every payment that goes through this route is reviewed afterwards, no later than the next working day.
• The checker is on leave. The delegation applies for the leave period, is recorded, and ends automatically afterwards.
• The maker and the checker turn out to be the same person. Treat the transaction as not yet approved. Do not release it because "it is already late".

How Do You Stop the Checker From Just Clicking Approve?

This is the most common failure of maker-checker: there are two people, but the checker only presses a button because they trust the maker. A few ways to reduce it without slowing the team down:

• Summarize what needs to be seen. The approval screen shows the vendor, amount, destination account, bank-account change status, and attachments. If the checker has to hunt for documents, they will skip them.
• Ask for one comment in specific cases. For example, require a comment when the amount is above the threshold or vendor data has changed.
• Look at timing patterns. Approvals that always arrive within seconds are worth sampling.
• Rotate roles where possible. Do not let the same maker and checker pair approve each other forever.

How Does Monit Help?

Based on the monitpay.com product pages, these features are relevant to this flow:

• Invoices and attachments in one place: Account payable receives invoices by email or upload, with OCR that fills in the form.
• Payments that go through approval: customizable approval workflows, with real-time invoice status (including invoices waiting for approval).
• Small recurring spend without manual approval queues: corporate cards, virtual or physical, with weekly or monthly limits per card and merchant lock.
• Compensating controls for very small teams: card transactions appear in real time (who, where, which card), and cards can be frozen from the app.
• Employee spend: expense management with customizable approval workflows.
• Posting to the books: accounting integration; the product page mentions Xero, QuickBooks, Jurnal, and Accurate.

How to use it: keep large vendor payments on the invoice and approval route, and move small recurring costs (subscriptions, supplies) to cards with limits so that not everything waits for a checker. That way the checker's attention goes to the payments that are genuinely high risk.

Limits to know about:

• The product pages show an example approval chain with several approvers, but they do not detail whether the system can enforce that maker and checker are different people, set routes by amount, or restrict access by role. Confirm these in a demo before you make them a requirement of your internal controls.
• Monit does not replace your internal policy. Role assignments and thresholds are still yours to define.
• Monit is a technology company, not a bank. Business accounts are provided by partner banks that are LPS members, and payment services are provided by Bank Indonesia-licensed operators.
• The impact figures on marketing pages come without methodology, so do not use them as internal performance targets.

FAQ

Is maker-checker legally required?

There is no single answer. Maker-checker is a common internal-control practice, and some industries, auditors, investors, or banking partners may require it. If your company has specific obligations, confirm them with your auditor or your Legal/Compliance team, then write the rule into your SOP so everyone knows when role separation has to be applied.

What if the founder is busy and often approves late?

Set a threshold so the founder is only involved in large amounts, and prepare a written delegation for specific periods, such as when they travel. Do not solve it by sharing login credentials with someone else. A recorded delegation still preserves role separation, while a shared account erases the trail of who approved what.

Does the checker need to review every small invoice?

Not necessarily. For small amounts with regular vendors, rely on card limits and a monthly sample review. The checker's time is better spent on large amounts, new vendors, and data changes such as bank accounts. Agree the amount cut-off with the business owner and revisit it each quarter against your actual payment patterns.

Should issuing cards or changing limits also go through maker-checker?

Ideally yes. For cards, the main control is the limit and merchant lock set up front, so a limit change is where separation of duties matters most. One person proposes the change, another approves it, and the reason is recorded so it can be traced during the monthly review.

What if the team is only two people and both are always busy?

Start with the highest-risk items: vendor bank-account changes and payments above the threshold. Use compensating controls for the rest for now, such as low limits, real-time notifications to the business owner, and a weekly review. Once the habit forms, tighten gradually while watching whether approval queues start delaying payments that are due.

Conclusion: Start With One Role Separation

Start small: write down who is the maker, checker, and releaser for vendor payments in your company today. If any transaction has all three roles held by one person, that is where the first control should go. For a wider view of approval flows, see this guide to employee expense approval flow (in Indonesian).

If you would like to see how invoices, approvals, and bookkeeping run in one flow, open the Account Payable page or start a conversation with the Monit team to confirm a setup that fits your team structure.