Re-architecting order-to-cash so the books reconcile

Context

A project-based business ran invoicing (tax basis), revenue recognition (percentage-of-completion basis) and receivables through a single conflated view. They never tied out. Month-end was a recurring firefight, and no one could cleanly explain the gap between what was invoiced, what was earned, and what was owed.

Challenge

Five failure vectors at once — people, process, system, customers, and no alignment between commercial, technical and finance teams on what "billing" even meant. There was no single source of truth, so every reconciliation was a negotiation rather than a check.

What I built

I traced the root cause: three legally and financially distinct registers were being treated as one. I designed a three-register architecture, each with its own owner, trigger, and a formal reconciliation to the next:

• Invoice Register — every invoice on a tax / IRN basis; governs statutory invoicing.
• Revenue Register — revenue recognised by journal each period on a POC / IND AS 115 basis; governs the P&L.
• AR Ledger — split into trade debtors, contract asset (unbilled), and contract liability (advances); governs the balance sheet.

I delivered it as a two-layer rollout: a structured tracker to run the model immediately, with the ERP project-system module as the eventual system-of-record. To make the rules stick, I wrote the corrected SOP, an edge-case addendum (terminations and refunds, POC-below-billing, and similar), and — the catalogue artifact — an interactive decision-tree tool that walks any contract scenario to the correct treatment and shows the journal entries at each node, so every analyst applies the rules the same way.

Outcome

A model where invoicing, revenue and receivables reconcile by construction, not by heroics. Month-end was de-risked; the invoiced-vs-earned-vs-owed gap became explainable on demand. The design was specific enough that the ERP team could implement it directly.