The books rebuilt after the system failed

What was broken

A multi-outlet retail chain lost access to a large part of its accounting data after an ERP migration failed mid-way, leaving corrupted ledgers and gaps across several months. With statutory filing and audit deadlines approaching, the company had no reliable books to work from.

What we did

CapEasy reconstructed the affected periods from external and transactional sources — bank feeds, tax returns, point-of-sale and vendor data — rebuilding the ledgers and reconciling them against control totals. The recovered data was validated, the gaps closed, and the accounting process stabilised on a reliable footing before the deadlines.

Where it landed

The company recovered a complete, reconciled set of records in time to meet its filing and audit obligations. The reconstruction also surfaced process weaknesses, which were addressed to reduce the risk of future data loss.

What the ATO actually requires when a system fails

Australian businesses are legally required to keep records of transactions relating to their tax, superannuation and registration affairs — not as a courtesy to an accountant, but as a standing obligation that survives whatever software you were using when the data was created. The general rule is five years: most records need to be kept for five years from when you prepared or obtained them, or from when the transaction they relate to was completed, whichever is later. Some records — capital gains cost bases, records behind a choice or election, records for an asset still held — need to be kept for longer than five years, so a system failure that touches older history can put more at risk than the current financial year alone.

The format rule is just as concrete: records must be in English, or in a form that is readily accessible and convertible to English. An ERP failure that leaves data trapped in a corrupted export, a proprietary backup format, or a system nobody can log into any more is not a defence against that requirement — the obligation is on the business to hold records it can actually produce, not records that once existed somewhere. That is precisely the gap this kind of engagement closes: the ledger a failed migration destroyed is rebuilt into something readable, reconciled and producible again.

Rebuilding into Xero or MYOB: pick an anchor and work outward

A rebuild does not start by re-entering everything from memory or from whatever fragments survived in the broken system. It starts by finding an anchor — a period you can independently verify against a source outside the failed system entirely. A lodged BAS, a bank statement, a superannuation clearing-house report, or the ATO integrated client account balance for a given date all work as anchors, because they exist independently of whatever corrupted the ledger.

From that anchor, the rebuild works forward and backward the same way the engagement did: bank feeds reconstruct the cash side transaction by transaction, point-of-sale exports reconstruct daily takings and GST on sales, and vendor statements reconstruct the purchase side and the GST credits claimed against it. Each source is reconciled against a control total before it goes into the new Xero or MYOB file — the bank feed against the statement balance, the sales data against banked takings, the purchase data against vendor statements — so gaps and duplicates surface before the rebuilt period is treated as finished, not after a BAS has been lodged against it.

What makes a rebuilt file lodgment-ready

A rebuilt file is not lodgment-ready because the numbers look plausible. It is ready when every reconciled period ties to its control total, every GST amount claimed or reported can point to the tax invoice or record behind it, and the file has no orphan entries — transactions with no source document, or source documents with no matching entry. The ATO's guidance on GST records is specific on this point: records need to show the income and expenses used to calculate what is reported and claimed, and if the records don't adequately support a claim, the claim can be adjusted or denied — which makes the reconciliation step, not the data entry, the part of a rebuild that actually protects the business.

Once a period is reconciled and the supporting records are attached or filed against it, the file is handed over in the state a registered BAS or tax agent needs to review and lodge — every figure traceable, nothing resting on a promise that the number is correct. CapEasy's part in a rebuild is exactly that: the reconstruction, the reconciliation, and the file prepared to that standard. Lodgment itself, and any position taken on a return, is for your registered BAS or tax agent to review and sign off.