Maker-Checker Workflows for Accounting Teams
Maker-checker, sometimes called the four-eyes principle, is the oldest control in accounting: the person who prepares an entry is not the person who authorises it. Banks run on it. Yet in many CA firms and seller back-offices, marketplace bookkeeping runs without it, one person downloads the reports, builds the sheets, and posts the vouchers, and the firm's only control is that this person is careful. This article makes the case for restoring the split, and shows how to implement it without slowing the team down.
What the split actually protects against
The value of maker-checker is often misunderstood as fraud prevention. In marketplace accounting, the more frequent saves are mundane:
- Systematic errors: a fee mapped to the wrong ledger, repeated across every voucher in a batch, is invisible to the person who created the mapping and obvious to a second reader.
- Stale-file errors: importing last month's settlement report, or the same file twice, produces plausible-looking books that a preparer has no reason to doubt.
- Judgement drift: a preparer resolving exceptions alone will quietly develop personal rules; a checker forces those rules into the open.
- Deadline shortcuts: knowing a checker will look is what keeps quality up in the last week of the month.
Fraud protection comes along for free, but the daily payoff is catching honest mistakes before they reach TallyPrime, where unwinding them means reversal entries and awkward client conversations.
Designing the workflow: three states, one gate
A workable maker-checker design for marketplace vouchers has three states: draft (generated from report files, editable, posts nowhere), in review (submitted by the maker, locked to further edits), and approved (released by the checker, eligible for posting). The single rule that makes the design real: nothing reaches the books except from the approved state, and the maker cannot move their own batch there. This is how TallySutra structures its pipeline, imported reports become draft vouchers, a reviewer approves batches in the CA workspace, and only approved batches post to TallyPrime through the desktop Gateway. What the checker should examine, batch totals first, sampled vouchers second, flagged exceptions always, is detailed in our reviewer's checklist.
Right-sizing the control for team size
| Team | Maker | Checker | Note |
|---|---|---|---|
| Solo practitioner | Self | Self, next day | A deliberate second pass beats none; automate flagging to assist it |
| Two to five people | Junior staff | Senior or partner | The classic split; approval takes minutes per client with batch review |
| Larger firms | Preparers per client group | Managers, partner on escalation | Add a second approval tier only for unusual batches |
The solo row deserves emphasis: the principle is a second look, and even a time-shifted self-review with system-flagged exceptions recovers much of the benefit. What does not work is nominal checking, an approval given without looking, which produces the record of a control with none of the protection.
The approval log as an asset
When approvals are recorded, who, when, which batch, the firm accumulates an internal-control log as a by-product of daily work. That log answers audit questions about how books are controlled, resolves who-posted-what disputes instantly, and demonstrates process maturity to prospective clients, particularly larger sellers who ask how their books will be protected from errors. Combined with preserved source files and voucher-to-row linkage, it forms the evidence trail discussed in evidence-backed accounting, and it complements the statutory edit-log requirement that applies to company clients.
Getting the team to adopt it
Resistance to maker-checker is usually about speed, and the answer is that the workflow should be fast by design: batch-level review rather than voucher-by-voucher reading, an exception queue that concentrates attention, standardised ledgers so checkers develop pattern recognition. Introduce it as protection for the maker, an approved batch is the firm's responsibility, not the junior's, and adoption tends to follow. Start with one client, measure the review time honestly, and expand once the team sees that the gate costs minutes and saves afternoons. A useful adoption metric is catch rate: how many batches per month the checker sends back, and why. Early on the number will be non-trivial as mappings get corrected and habits form; over time it should fall without ever reaching zero. A checker who never rejects anything is either reviewing a genuinely stable pipeline or not really looking, and the reasons logged against each rejection tell you which. Share those patterns with the team monthly; nothing teaches preparers faster than seeing what gets caught.
Frequently asked questions
Is maker-checker overkill for a small CA firm?
No. The control catches routine errors, wrong mappings, duplicate imports, stale files, that occur regardless of firm size. Even a solo practitioner benefits from a structured next-day self-review assisted by automated exception flagging.
Does the checker need to re-verify every voucher?
No. Effective checking works at batch level: counts, totals, fee ratios and period, then sampled vouchers and all flagged exceptions. That keeps approval to minutes per client while still catching systematic issues.
How does TallySutra enforce the maker-checker split?
Generated vouchers wait in a review state, and only batches approved by a reviewer post to TallyPrime via the desktop Gateway. Approvals are recorded, giving the firm an internal-control log alongside the books.
TallySutra turns Amazon, Flipkart and Meesho reports into reconciled, reviewed TallyPrime vouchers — duplicate-safe, with every rupee traceable to its source row.
Book a 30-minute demo