Financial Reporting From Archived ERP Data, After the ERP Is Gone

After the migration, finance, audit, tax and compliance teams still need the old system's history, often for many years. The question is whether historical reporting should depend on keeping that system running. For most organisations it does not have to, provided the history is extracted with its accounting structure intact and reconciled before the source goes.

Is the ERP application the same thing as its financial data?

No, and the difference decides the approach. The application is the interface a business uses to operate. Behind it is data: the chart of accounts, journal entries and general ledger postings, accounting periods, customers and vendors, receivables and payables, entities, departments, cost centres and profit centres, subsidiaries or company codes, currencies, transaction lines and the documents attached to them.

Different ERP systems organise that data differently, but accounting has recognisable structures. A debit remains a debit. An account belongs to a chart of accounts. A transaction falls in an accounting period. Ledger entries add up to balances. Those structures are what make reporting outside the original application possible.

How archived ERP data becomes something finance can report from

DBVault is our platform for ERP and business data archival and reporting. Each archive holds its source system's records in their own schema, with the relationships and the general ledger detail the source kept. The work to get there has a fixed order:

1. Identify the financial structures. How the source represents accounts, periods, entities, transactions and ledger postings.
2. Agree the scope and extract. The records the organisation must keep, extracted by a method suited to that system: for NetSuite, from the account under a login you provide and can revoke; for SAP, from extract packages your SAP team produces with SAP's own reporting and table exports. Each engagement is scoped at the start.
3. Preserve the relationships. A journal line stays with its document, a posting with its account, a transaction with its business context.
4. Keep the source's own dimensions. One system uses subsidiaries, departments and classes; another uses company codes, cost centres and profit centres. The archive keeps each system's dimensions as they were and makes them available to reporting, rather than renaming everything until every ERP looks alike.
5. Reconcile. Row counts against the source show that the records arrived; the trial balance per entity and period, tied to the source system's own reports, shows that the values are right. If the source reports a balance for a defined period and scope, the archived ledger must match it before sign-off.
6. Report from the archive. Once the ledger is mapped and reconciled, the statements run inside the platform against it.

Which reports survive an ERP migration?

Where the extracted data supports them, the financial statements an audit or a statutory filing is built from: trial balance and consolidated trial balance, balance sheet, income statement, general ledger, account activity, transaction detail and period comparison. Management reporting follows the dimensions the source actually held, such as subsidiary or company code, department or cost centre, class or profit centre, location, customer, vendor and currency.

What is available depends on what the source system contains and what the archive's scope included. A report someone built by hand in the old system is not reproduced automatically; the reports the team relies on are confirmed during scoping and tested during validation.

What this looks like when the auditor asks

A common request shows the difference. After a consolidation, the group's auditor asks for the trial balance of an acquired entity for the year before it moved onto the group ERP, and for the invoices behind two of its balances. The new ERP holds that entity's opening balances and nothing earlier, and the person who knew the old chart of accounts has moved on.

If the history was archived with its ledger detail and reconciled, the controller runs the trial balance for that entity and period from the archive, opens the account activity behind each balance and exports what the auditor asked for, without asking IT to restore the old system. If it was kept as exported files, someone has to rebuild the ledger before the question can be answered.

Why archival belongs in the ERP replacement plan

A migration concentrates on the future: the new system has to go live, integrations have to work, opening balances have to be right and users have to be trained. Historical data is easily treated as a secondary issue, and then an auditor, a regulator or a controller needs something that was left in the retired system. Treating archival as its own workstream, with its own owner, keeps the two jobs apart: the migration moves the organisation forward, and the archive keeps the history it may still have to explain.

One platform, a flavour per source system

Oracle NetSuite is where most of our engagements have been and where our tooling runs deepest, through DBVault for NetSuite. SAP archives are held on DBVault for SAP, per company code and fiscal year. The platform itself is source-agnostic: an archive is built from an ERP extraction or from business data loaded as CSV into archive objects. Another system is named on this site only once an archive of it has been delivered, and whether yours fits depends on how its data can be read and verified, which is settled in scoping.

The test for any of it is the same: whether your finance team can still understand, reconcile and report from that data five or ten years from now. If you are consolidating or retiring an ERP, bring the entities, periods and reports that matter, and see how the DBVault platform holds and reports on archived ERP data.