Migrating SAP ECC FI Extraction to dbt: Rebuilding the Finance Data Foundation in Financial Services
Every SAP ECC estate has the same quiet dependency: a nightly FI extraction that feeds the finance data mart, written years ago, reconciled monthly, and understood by fewer people each year. In a bank or insurer that mart is also where statutory reporting, board packs and regulatory submissions are built — which raises the stakes considerably. This scenario walks through rebuilding that foundation on dbt, with the FI-specific rules that make or break it and the reconciliation evidence that keeps auditors, Compliance and Finance calm.
1. The scenario
A UK financial services group runs SAP ECC 6.0 as its finance system of record — alongside a core banking platform it has no plans to touch. Every night, an extraction job pulls financial documents — headers from BKPF, line items from BSEG — through custom ABAP and a legacy ETL tool into staging tables. From there, a chain of handwritten SQL builds the finance mart that statutory reporting, regulatory submissions, board packs and cost-centre analysis all read.
The group is moving its reporting platform to a cloud warehouse with dbt as the transformation layer. The ECC system is not changing yet — but the reporting foundation has to move, because the people who maintain the current chain are not replaceable, and the evidence for every reported figure currently lives in their heads.
2. Why FI data is the dangerous kind
FI is not generic transactional data. The rules that make it correct are SAP conventions that no amount of general SQL knowledge replaces:
- Header versus line items:
BKPFcarries one header per document;BSEGcarries many line items. Join them wrong and figures multiply. - Fiscal year variants: company codes with non-calendar fiscal years need period mapping, not
MONTH(posting_date). - Special periods 13–16: year-end adjustment postings live outside the normal calendar periods — silently dropping them shifts annual figures, and annual figures are what get filed.
- Reversal documents:
reversed_by/reversal_reasonlinks mean some rows count negatively — or not at all — depending on the report. - Currencies: transaction, local and group currencies coexist per line; choosing the wrong one for a report is a classic, invisible error — and in a multi-entity FS group, group currency is the number the board sees.
- Custom fields: the ubiquitous
ZZ*fields carry real business meaning and are usually documented nowhere.
3. The three wrong ways to do it
The lift-and-shift. Keep the ABAP extracts and old staging tables, point dbt at them. This works for a quarter, then becomes the same undocumented chain with a new front door — and the same single point of failure in one engineer's head.
The big-bang rebuild. Rewrite the whole mart in dbt from a specification document. The specification will be wrong in the FI-specific places, and you will discover that in a reconciliation meeting — or an audit fieldwork session.
The S/4 delay. “We will fix reporting when we move to S/4HANA.” Coupling two programmes turns each delay into a multiplier. The reporting foundation can move now, and survive the S/4 migration later.
4. The safe path
Understand the FI data model
Document document types, fiscal year variants, special periods, reversal handling and the meaning of every ZZ* field — with an FI-literate reviewer, before designing anything.
- Rules written down
- FI reviewer engaged early
Extract once, well
Replace the ABAP chain with a clean extraction (ODP extractors, CDC or vendor connector) into raw staging — one company code at a time, with row counts and checksums recorded as baseline evidence.
- One trusted extraction
- Baseline evidence captured
Build dbt staging with tests
Model BKPF/BSEG relationships with referential integrity tests, accepted values for document types and company codes, and not-null guards on amounts.
- Bad data fails loudly
- Rules encoded, not remembered
Reconcile to the general ledger
Sum both legacy and dbt marts by company code, fiscal year and period — including special periods — and diff them. Keep the reconciliation as a standing dbt job, not a one-off exercise: it is your answer to audit and Compliance, available on demand.
- Finance-grade evidence
- Diffs surfaced in days, not months
Cut over by company code
Move one company code at a time, run both marts in parallel for a full close cycle, and roll back per company code until reconciliation holds. Entity-by-entity rollback is what makes this safe in a regulated group.
- Risk contained per slice
- Auditors see evidence on demand
5. Where LogicLift fits
The mechanical middle — reading the legacy extraction and transformation logic, regenerating it as documented dbt models, and generating the reconciliation tests alongside — is what LogicLift automates. The FI rules still need your FI-literate reviewer; the transcription, they do not. The outcome is a finance mart where every rule is a test that runs on demand, and the monthly reconciliation becomes a query instead of a project — with the evidence trail a regulated FS group needs already built in.
Rebuilding a finance data foundation?
Book a free 30-minute migration assessment. We will review your FI extraction chain and map the safest path to dbt — with reconciliation evidence your auditors will accept.
Frequently asked questions
Do we need SAP FI specialists to do this migration?
For review, yes — for transcription, no. The data model rules (fiscal year variants, special periods, reversal logic) need someone who understands FI to validate the dbt models. But the extraction and transformation work itself is standard data engineering, and the reconciliation tests encode the FI rules so they run on demand.
Should we migrate to dbt before or after our S/4HANA move?
Usually before, and decoupled from it. Building the finance mart on documented dbt models means the S/4 migration later changes the extraction layer only — the reporting logic survives. Coupling both programmes at once is how 24-month timelines happen.
How do we prove the new mart matches SAP?
Reconcile at the level Finance already trusts: company code, fiscal year and period, document type. Sum BSEG by those dimensions from both the legacy extract and the dbt mart, diff them, and keep the results as standing evidence — the same evidence external audit and Compliance will ask for.
Can dbt handle SAP hierarchies and custom fields?
Yes. Hierarchies (cost centres, profit centres, segments) become seed files or dimension models version-controlled with the project; custom fields (ZZ* fields) are first-class columns in staging with tests, not afterthoughts in SQL strings.