A Maker–Checker workflow for an ISP finance team. Now being built out as a public ERP for other businesses.
Month-end closing was only a few hours away.
An accountant finished posting a supplier invoice worth ₦18.7 million. Everything looked correct. The transaction was saved.
Moments later, someone noticed the invoice had been posted to the wrong expense account. Another payment had been duplicated because the same invoice had already been entered earlier that morning. A third transaction contained an extra zero that no one spotted until reconciliation.
None of these mistakes were intentional. One person could create, approve, and post into the General Ledger with no second review.
Fixing it wasn't as simple as deleting a record. Journal reversals. Vendor balances off. Reports wrong. The finance team spent hours on mistakes that should never have reached the books.
The problem wasn't accounting knowledge. There were no financial controls. That's what I set out to fix.
Two-step control so transactions are accurate and auditable before they hit the General Ledger.
Lock editing for maker
Notify checker
Lock record
Create posting entry
Lock record permanently
Available for reporting and audit
Every financial transaction in an ERP eventually hits the General Ledger. That's not a UI detail. Post once, and the error shows up everywhere.
These transaction types all share the same downstream risk:
Once posted, they affect:
Errors don't stay local. They compound. A wrong GL account on a ₦18.7M invoice doesn't just look bad on one screen. It skews the reports leadership actually uses.
I didn't run a survey and call it research. I shadowed people in the system during month-end, when the pressure is highest and controls matter most.
Patterns kept repeating:
Every red step in the before flow costs money. Reversals, reposts, reconciliation. All preventable if the error never reaches the GL.
Finance didn't need a faster posting screen. It needed to trust that only validated transactions reached the General Ledger.
That reframe changed the work. The problem wasn't form layout or button placement. It was building controls into the workflow: separate roles, drafts that don't touch reports, and a record of who approved what.
Two roles. One gate before the GL. No shortcuts.
After posting, the record locks. Corrections need a formal reversal, not a quiet edit. That friction is intentional. It protects every downstream report.
Makers cannot approve their own transactions, even when their role technically included post permission. Finance managers said segregation of duties mattered more than speed.
Drafts do not affect financial reports. Only approved transactions generate accounting entries. Trial balance, P&L, and vendor balances stay clean until a Checker confirms.
Supporting documents required before submission. Cut down incomplete postings during month-end when AP teams were moving fastest.
Approval history can't be edited. Every action logged: user, timestamp, comments, changes requested. Finance teams wanted trust more than flexibility.
INV-2847 · Apex Telecom Ltd
I didn't use AI to design the workflow or generate screens. I used it early to explore approval models and stress-test assumptions before meeting finance stakeholders.
I wanted to understand the trade-offs different financial systems make between speed, control, and auditability before picking a direction.
Before designing the workflow, I asked AI to compare how enterprise finance systems handle transaction approvals.
AI summarized four common approaches:
I started leaning toward flexible multi-level approval because it looked like it covered more scenarios.
Finance managers pushed back. Not because they hated flexibility. They needed predictability during month-end close. Everyone had to know who approves next.
We went with a two-step Maker–Checker workflow plus amount-based escalation for high-value transactions. Stronger controls without slowing everyday work.
Once I had a draft workflow, I used AI to identify failure points before validating it with users.
AI highlighted several scenarios I hadn't fully considered, including:
Not everything became a feature, but the exercise helped before user validation.
The final design added several safeguards:
AI didn't make these calls. Finance managers and treasury officers did, after walking me through what posting mistakes cost during reconciliation and month-end.
AI helped me explore options. It couldn't tell me which workflow fit this business.
It didn't know finance officers were skipping review because Instant Post had become the default. It couldn't say which mistakes happened most or how approvals actually worked under month-end pressure.
That came from shadowing users, reading reversal journals, and testing the workflow with stakeholders.
AI sped up exploration. The final calls came from the people who keep the books accurate.
I started out framing this as preventing user mistakes. Research showed the real job was protecting financial integrity.
People will make mistakes. Good financial systems plan for that and build recovery and approval into the workflow.
Maker–Checker isn't new. What mattered was drafts never touching the GL, Checkers not skippable for speed, and every approval leaving a record finance could trust during audit season.
If you're evaluating this work, don't look for a prettier invoice form. Look at where the system stops being fast and starts being safe.
Workspace started as an internal ERP for an internet service provider: finance, operations, and reporting in one place. The Maker–Checker work in this case study shipped inside that environment. We're now building toward a public release so other ERP teams can use the same controls. The walkthrough here is production UI from that rollout.