Financial Reconciliation Case Study: Reviving Dormant Books
When a company goes quiet — no active projects, no new invoices, no reason to touch the books — it’s easy to assume the financials are simply on pause. In practice, dormancy is often when the real damage happens. Nobody’s watching the ledger, nobody’s catching the small errors. The business eventually needs to become active again — a sale, a partnership, a new contract. That’s when what looked like a pause turns out to have been quiet decay.
We recently worked through exactly this with Globex International Group. It’s a mid-sized construction contracting company that had gone dormant for over a year. The owner wanted the business back in a sellable, partnership-ready, trustworthy state. That meant rebuilding years of financial history from scratch inside a proper ERP system. Here’s what we found, and how UniERP solved it.
The starting point
Globex had a real operating history: government and private infrastructure projects, subcontracted works, equipment costs, and multiple concurrent project sites. A small web of related parties investors, informal lenders, and long-time subcontractors threaded through years of transactions. None of it lived in a single system. Some of it was in spreadsheets, some in an old accountant’s handwritten registers, some existed only as memory.
We had to reconstruct almost 5,000 individual transactions and import them into a clean, structured ERP instance. Along the way, we ran into a set of problems that are extremely common for any company trying to formalize years of informal or fragmented bookkeeping. Construction or otherwise, these problems tend to look the same.
Five problems, and how each one was actually solved
No real chart of accounts
Globex had “accounts” in the loose sense categories someone used once and never standardized. There was no cost center structure. There was no way to answer a basic question like “how much did Project X actually cost us in labor versus materials?” We built a proper chart of accounts from the ground up. It has around 60 accounts covering assets, liabilities, equity, income, and expense categories specific to a construction business. We paired it with a cost center tree of over 30 centers mapped to real projects and departments, then reclassified every historical transaction against this structure instead of dumping it in as-is.
Party records that didn’t fit the system’s rules
ERP systems enforce logic that real-world bookkeeping often ignores. A receivable account, for example, might only link to a customer or an employee, not a supplier. Years of informal reporting had blurred these lines. We individually reviewed and reclassified every affected party to match how it actually functioned in the business, before import. This one step resolved dozens of import failures and made every future receivable and payable report accurate.
Postings landing on the wrong level of the account tree
Group accounts should work as summary containers they shouldn’t absorb direct postings. A hand-maintained spreadsheet system doesn’t stop someone from posting straight to a top-level category, though, because it’s faster than creating the right sub-account. We audited every group account that had been receiving direct postings and created proper leaf-level child accounts underneath each one. Then we remapped historical entries down to the correct level. It’s a small technical fix with a big payoff. It’s the difference between a chart of accounts that looks organized and one that actually rolls up correctly for reporting.
Vague descriptions corrupting the data
Someone had imported transactions with generic source descriptions “cash,” “misc,” “adjustment” in ways that caused accounts to reference themselves. That distorted every downstream balance. We traced each vague entry back to its most likely real source and reclassified it. We deliberately held back a small set of genuinely unresolved transactions from import rather than guessing. Better to flag a gap than quietly introduce bad data into a clean system.
Related-party money that didn’t reconcile
Here’s the most sensitive finding: one set of records showed money paid to a related party. That payment never appeared anywhere in that party’s own books. This kind of gap is common in dormant, multi-stakeholder companies. Informal financing and personal guarantees rarely get the same documentation rigor as customer invoices. Rather than absorbing the discrepancy silently, we flagged it as a dedicated audit item. We tracked it, quantified it, and set it aside until we could formally confirm or write it off.
The result
Globex started with a scattered, dormant, largely undocumented set of financial history. Today, that history is a structured, queryable, audit-ready ledger inside UniERP. It comes complete with a proper chart of accounts, cost center tracking, reconciled party records, and a clearly flagged list of items still needing resolution, rather than hidden ones.
The lesson underneath the case study
For any business sitting on years of informal records whether dormant, growing fast, or simply never formalized the lesson is the same. The goal isn’t to make the data look clean. It’s to build a structure where clean data is the only kind the system will accept.
Considering bringing your own company’s financial history into a real ERP system? UniERP handles exactly this kind of reconstruction, from chart-of-accounts design to transaction-level reconciliation. It won’t force your real business through someone else’s rigid template. Talk to us or try a free demo.
Considering bringing your own company’s financial history into a real ERP system? UniERP is built to handle exactly this kind of reconstruction from chart-of-accounts design to transaction-level reconciliation without forcing your real business through someone else’s rigid template. Talk to us or try a free demo.
