Keeping the SAP environment available for historical look-ups is one way to preserve its financial history. The other is to extract the history and hold it in a platform built for archival access. The second approach succeeds or fails on one question that is easy to underestimate: whether the relationships that give each posting its meaning survive the move.
Why can't SAP data be archived as flat exports?
A posting in SAP has context. It belongs to an accounting document and a company code; it falls in a fiscal year and period; it hits a general ledger account; it may carry a cost centre, a profit centre, an internal order, a customer or a vendor. Remove those links and the organisation still has the rows, but a reviewer can no longer say what a line represents or why it was posted.
A set of CSV files exported table by table keeps the values and drops the joins. Rebuilding them later means knowing SAP's table structure and writing the queries by hand, usually after the people who knew the system have moved on. That is why the archive is built around the relationships rather than around the files.
What has to be agreed before anything is mapped?
The scope comes first, because the archive can only hold what the scoping agreed. The questions are practical:
- Which company codes are being retired, and which fiscal years must stay available?
- Which ledgers, and which financial and controlling objects, does the business still report on?
- Which custom tables hold information the standard reports never showed?
- Are documents attached in SAP needed alongside the postings?
- Which financial reports must be reproducible after SAP is gone?
Each engagement is scoped at the start, so custom tables, attachments and further data areas are brought in when the business depends on them. The extract packages are then produced from SAP's own reporting and table exports, with your SAP team and under credentials you control.
SAP's own dimensions, kept as SAP named them
A good archive does not force SAP data into another ERP's vocabulary. Depending on the source system and the scope, the archive keeps:
- the company code, fiscal year and posting period of every line;
- the general ledger account, with the chart of accounts and the account master by company code;
- the accounting document and its lines;
- cost centres, profit centres and internal orders;
- open customer and vendor items, and the customer and vendor master data behind them;
- asset master records, depreciation rules, asset values and posted depreciation;
- currency, where the extract carries it.
On S/4HANA systems, SAP holds financial and management accounting postings together in the Universal Journal; the release, ECC or S/4HANA, decides which reports and tables the extract packages come from. It does not change what the archive has to preserve.
From SAP structures to archive records
Mapping does not change the financial meaning of the data. It defines how each SAP object and each link between objects is represented in the archive, so that the same questions can be asked of it:
- a company code resolves to its postings, its accounts and its fiscal years;
- an accounting document resolves to its lines, and each line to its account and period;
- a posting resolves to its cost centre or profit centre;
- a customer or vendor resolves to its open items and related postings;
- a custom table in scope becomes a record type of its own, next to the standard objects.
The result is an archive shaped around what the organisation must be able to retrieve and explain, not a reproduction of every SAP function.
Reconciliation before sign-off
Loading SAP records into another database does not prove the archive is financially correct. We reconcile it in layers, and the layers are the point: row counts per table against the extract packages show that the rows arrived; accounting documents netting to zero show that no lines went missing inside a document; the trial balance tied to your own balances per company code shows that the values are right. Where postings continued after the first package, a closing package taken after the last close replaces the earlier load and the reconciliation is repeated on it.
Then your team works the archive against real questions during a validation period, and signs off only when what they raise is cleared. The archive may become the organisation's main source for those years, so this is the step not to shorten.
The reports that run on the archived ledger
Once the data is mapped and reconciled, the financial statements run inside the platform against the archived ledger, per company code and fiscal year, and each figure leads back to the postings behind it:
- Financial statements: cumulative, consolidated and fiscal-year trial balance, balance sheet, income statement, general ledger, account activity and transaction detail.
- Management and multi-currency: profit and loss by cost centre, profit centre and company code; trial balance by currency and FX analysis where the extract carries the currencies.
- Audit: transaction journal, period comparison, account type summary and the reversals report.
Which reports are available depends on the dimensions the extract carries, so the reports you rely on are confirmed during scoping and tested during validation.
Same platform, different source ERP
DBVault is the platform for ERP and business data archival and reporting; DBVault for SAP and DBVault for NetSuite are its flavours. Oracle NetSuite is where most of our engagements have been and where our tooling runs deepest. SAP organises its financial data differently, which is exactly why the archive has to understand the source: once the data has been extracted, mapped and reconciled, the same search, access controls, logging and reporting sit in front of it.
What it does not do is also worth stating. The archive is read-only and cloud-hosted; it does not load data into S/4HANA or another ERP, and records leave it as CSV for a team doing a load. If you are planning an SAP retirement, the useful test is whether someone can still reconcile and report from the history years after SAP is gone. See how DBVault for SAP holds and reports on that history.