Approval workflows the maker-checker way — fee waivers, voucher posting, leave
A school we worked with had a fee-waiver request go through. The clerk meant ₹1,200. They typed ₹12,000. The principal initialled it on a paper slip without reading the number. The waiver was applied, the parent paid the new "balance", and nobody noticed for 4 months.
When the auditor noticed, the school had no record of who approved it. The clerk said the principal approved. The principal said they approved a ₹1,200 waiver. The slip said ₹12,000. Three stories, one number, no resolution.
This is what maker-checker is for. Not bureaucracy — accountability with attribution.
The pattern
Maker — the person who creates the request. Doesn't apply.
Checker — the person who approves it. Sees what the maker entered, with the actual amount, before applying.
Same person can't do both. Hard rule, enforced by the system.
Three guarantees:
- Two-eye review before the change takes effect.
- Audit trail — who made, who approved, when, with what value.
- No same-user shortcut — even if the maker is "the principal", they can't approve their own.
Where it applies in a school
Every operation that changes money, status, or attendance benefits from it:
| Operation | Maker | Checker |
|---|---|---|
| Fee waiver | Accounts clerk | Principal / Bursar |
| Fee refund | Accounts clerk | Principal / Bursar |
| Voucher posting | Accounts clerk | Finance head |
| Period close | Accounts clerk | Auditor / Finance head |
| Student promotion | Class teacher | Section head |
| Student detention | Class teacher | Principal |
| Staff leave > 3 days | Staff member | HR head |
| Salary advance | HR clerk | HR head + Finance head (2 stages) |
| Faculty appointment | HR clerk | Principal / VC |
| Vendor PO > ₹50k | Procurement clerk | Procurement head + Finance |
The seven decisions
When designing a maker-checker workflow, seven choices to make:
1. What triggers it?
Every fee waiver? Or only waivers above ₹1,000? Most schools start with "every", get tired of the ceremony, and switch to "above a threshold". Both are fine — pick deliberately.
2. How many stages?
For a fee waiver: maker → principal (one stage). For a faculty appointment: maker → HR head → Finance head → Principal (three stages). More stages = more friction but more eyes. We've found 1-2 stages for routine operations, 3-4 for major HR / financial decisions.
3. What about emergencies?
Bus accident at 11 PM, need to call all parents. The communication needs maker-checker on the broadcast? No. Emergency-override is a real need. Pattern: emergency category bypasses one stage but requires a post-hoc justification within 24 hours.
4. What does the checker actually see?
Not just "approve / reject" — the full context: amount, student details, original document, similar past decisions. We've seen poorly-designed maker-checker UI where the checker has 200 requests to approve in a day and gives up reading. The UI must make the read-and-decide faster than the type-and-submit.
5. What about delegation?
Principal is on leave. Vice-principal can approve in their absence? Yes, but explicitly delegated, not "anyone with access". Our Approval Workflow engine has a AwDelegate table — principal delegates to VP for date range D1 to D2, system routes there automatically, audit trail shows both names.
6. What about SLAs?
A fee waiver sitting unapproved for 3 weeks is itself a problem (the parent is waiting). Each stage gets a soft SLA — escalate if not actioned in X hours. Our engine has AwSlaEscalationJob running every 30 min that flips the request's stage owner if SLA breached.
7. What about the audit log?
The whole point is the audit log. So: WHO made, WHEN, WITH WHAT VALUE; WHO approved (or rejected), WHEN, WITH WHAT REASON. Soft-deletes never erase the audit row. Reports that aggregate across approvers help spot anomalies (one approver approving 40% of all waivers without reading?).
What we shipped
The Approval Workflow engine in School Console — AwWorkflow, AwStage, AwRule, AwRequest, AwAction, AwDelegate — does all seven. It's used by:
- Fee Module (waivers, refunds)
- Finance Module (voucher posting, period close)
- Payroll Module (loans, advances)
- HR Module (leave > N days, appointments)
- Procurement Module (PO above threshold, vendor onboarding)
- Admission Module (waitlist decisions, sibling-auto-reject overrides)
- LMS Module (faculty grade overrides above threshold)
One engine, every module. Stage rules are amount-bracket + school + department scoped. Same-user-can't-approve is a hard guard. Idempotent on (SourceModule, SourceTable, SourceId, WorkflowCode) so duplicate submissions don't create duplicate approvals.
The ₹12,000 fee waiver
After the school went on School Console with maker-checker on fee waivers: the same kind of typo (a clerk meant ₹500, typed ₹5,000) was caught on the principal's approval screen the next morning. Approval rejected, original request edited, re-submitted at ₹500. No money moved.
The principal didn't catch it because they're more careful. They caught it because the system showed them the number, the student name, and the historical concession pattern for that student — before asking for approval.
That's the whole thing. Request a demo — we'll walk through the approval inbox on placeholder data.