The problem
Revenue journals were posting as zero across the entire system. The trial balance could not be relied on, month-end close required manual reconstruction from booking records, and the base currency (GBP) no longer matched how the business actually transacted (SAR).
What we built
Traced the root cause to a missing database column silently failing the journal write. Corrected the schema, backfilled affected journals, then re-based the entire chart of accounts and historical entries from GBP to SAR without data loss. Rebuilt agent ledger, invoice currency rendering and journal display on the corrected foundation.
Fixing a broken ledger is not a reporting exercise. If the journal write itself is failing, every downstream number is wrong and no amount of dashboard work will surface it – the totals will simply be consistent with each other and wrong together.
We started from the raw database rather than the reports, reproduced the failing write, and found a schema mismatch that was silently discarding the revenue leg of each entry. Once the write was corrected we backfilled historical journals from the source booking records, reconciled the result against bank and supplier statements, and only then rebuilt the reporting layer.
The currency re-basing ran as a separate, reversible migration with a full backup and a verification pass comparing pre- and post-migration balances at account level.
The difference between a real double-entry ledger and a report over transaction tables only becomes visible during an audit.