SAP S/4HANA Historical Reporting — Without Keeping HANA Alive

SAP S/4HANA historical reporting is the ongoing requirement, after migration to Oracle Fusion or any other system, to answer 'what did the old SAP system say?' for closed periods. Finance needs to compare prior-year trial balances and aging schedules; tax authorities (Finanzamt under German AO, HMRC under UK rules, IRS for US) audit closed years; internal audit samples vendor invoices and journal documents; treasury reconciles historical bank statements; regulators (BaFin, FCA, MiFID II) demand evidence of historical transaction state. Without a queryable archive, the only options are keeping S/4HANA fully alive at HANA in-memory rates, or printing-to-PDF and losing query-ability. Syntra ETL's historical reporting layer is the third option: a queryable archive at cold-storage prices.

Two dimensions: cost and query-time. Keeping a closed-period-only S/4HANA alive typically costs £600K–£3M/year (HANA licence, RISE MSU, infrastructure, Basis support, patch cycles). It gives you familiar SAP GUI/Fiori query access but at full operational cost. Syntra ETL's historical reporting layer costs typically £30K–£150K/year all-in (cloud object storage + query engine + access management). It gives you SQL/REST query access at sub-second latency for typical lookups — better than SAP GUI, in fact, because the data is partitioned for analytical access rather than transactional access. Tax authorities and auditors care about data accuracy and access, not which UI delivers it.

Yes. The archive preserves ACDOCA universal journal entries with full account-assignment context (BUKRS company code, RYEAR/POPER fiscal period, KOSTL cost centre, PRCTR profit centre, RFAREA functional area, parallel-ledger context for IFRS vs local GAAP), so any S/4HANA financial statement that was computed from ACDOCA can be reproduced from the archive. Syntra ETL ships pre-built reports for the most common queries: trial balance per BUKRS per ledger per period, balance sheet, P&L, AP open-item aging, AR open-item aging by customer, fixed asset register per ANLA book, bank reconciliation. Customers can build additional reports in OTBI, Tableau, Power BI, or any SQL/JDBC-compatible tool against the archive.

Five user groups, each with different access needs. Finance ops: trial balance and aging lookups for prior-period comparison, monthly close support. Tax: corporate tax filing support, transfer-pricing analysis, VAT/sales-tax audit defence — typically annual heavy use. Internal audit: SOX testing on historical periods, journal-entry sampling, segregation-of-duties review of closed-period activity. External audit: independent verification of prior-year balances, in-scope only for the specific year(s) under audit. Regulators: tax authority queries (Finanzamt for German HGB, HMRC for UK, IRS for US), industry regulators (BaFin for German banking, MHRA/FDA for pharma manufacturing) — typically ad-hoc, response-time-critical.

Sub-second for typical operational queries (single period, single company code, single document or vendor lookup). 5–30 seconds for multi-period aggregations spanning a fiscal year of activity. 1–5 minutes for multi-year cross-company-code consolidation queries against billion-row history. Archive data is partitioned by fiscal year, period, and company code, and the query engine uses Parquet's column pruning and partition pruning to minimise scan. Customers planning heavy use during year-end audit pre-materialise auditor-facing dataset views (trial balance snapshots, AP aging snapshots) so audit queries always hit pre-computed results.

Yes. S/4HANA's multi-ledger model (leading ledger + non-leading ledgers, typically IFRS as leading with local-GAAP variants per country) is preserved natively in the archive via the ACDOCA RLDNR (ledger) field. Historical reports can be filtered by ledger to reproduce IFRS-basis or local-GAAP-basis financial statements as of any historical period. Multi-currency handling (RHCUR/RKCUR/ROCUR — local, group, and additional currency) is similarly preserved, so prior-period currency-translated balances are reproducible. For customers with parallel valuation areas (FI-AA depreciation areas, FI-AA group reporting), every depreciation area is archived independently.

Yes. German tax-authority audits under GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern) require: data immutability (Unveränderbarkeit), full audit trail of any changes, completeness, traceability, and machine-readable export in defined formats. Syntra ETL's archive is immutable by design (Parquet on versioned object storage with WORM lock available), maintains a hash-signed audit log of every read access, and supports GoBD-compliant data export to the IDEA-compatible file formats Finanzamt auditors use. Several customers have completed Finanzamt audits sourced entirely from the Syntra archive with no requirement to revive S/4HANA.

PII and sensitive fields (employee personal data in PA0001/PA0002, salary in PA0008, bank accounts in LFBK/KNBK, customer tax IDs in KNA1) are masked by default at the archive layer. Three masking modes: tokenised (irreversible hash, used when the field isn't needed for reporting), pseudonymised (deterministic mapping so analytics still work without PII, used for trend analysis), and unmasked-by-role (full data exposed only to roles with explicit need, e.g. tax-authority response, employee personal-data inquiry under GDPR Article 15). Every unmask operation is logged for audit. The masking layer is GDPR Article 25 ('data protection by design') compliant.