Data needs to move between SAP and EPM platforms — planning processes, consolidation, reporting, none of it lives entirely within the EPM system, and SAP is where much of the underlying transactional data sits. But moving the data is only half the question. Before it can be used for consolidation, it needs to be transformed – mapped, restructured into the shape the target system expects. This post looks at where that transformation can happen.
By transformation I mean the work of turning raw SAP transactions into the shape a consolidation system needs — mapping accounts to a group chart of accounts, assigning intercompany partners to intercompany transactions, analysing account movements for cashflow reporting, and enriching dimension values for supplementary reporting such as geographical sales. That work has to happen somewhere. It can happen inside SAP, before the data leaves. Or it can happen afterwards — in the EPM system itself, in a staging layer, or in middleware sitting between the two.
Both approaches are used successfully across the industry, and the right answer depends on an organisation’s SAP maturity, team structure, and how much of the group reports from non-SAP systems. But the advantages of transforming inside SAP are, in my experience, underappreciated, and worth setting out clearly — alongside a fair account of why many finance teams choose the alternative.
The case for transforming in the EPM system.
It’s worth starting with the alternative, because it has genuine merit. Many finance teams prefer transformation logic to live inside the consolidation system itself. It keeps mapping rules visible to the people who own the consolidation process, without depending on an SAP developer or a change request to make an adjustment. It works uniformly across entities regardless of source system, which matters for diversified groups with a meaningful share of non-SAP subsidiaries. And it keeps that logic within the finance function’s own tooling rather than adding to the complexity of the SAP landscape.
For groups where SAP is only a small part of the picture, these advantages will often outweigh the case below.
Why transforming in SAP deserves consideration.
For organisations that are substantially SAP-based, however, doing the transformation before data leaves SAP has a number of advantages that are easy to overlook.
Full access, not a predetermined extract.
Transforming outside SAP usually means deciding in advance which data to extract, and at what level of granularity — because building that decision into an extract routine is itself a piece of design work. Transforming inside SAP removes that upfront constraint: the full dataset is already there, so the decision about what’s needed can be made, and changed, without redesigning an extraction process.
Look-ups without a separate extraction step.
Consolidation logic often depends on attributes that sit on a different SAP object to the transaction itself — the country on the customer master, for example, rather than in the accounting document line. Inside SAP, that value can simply be looked up at the point of transformation. Outside SAP, it has to be extracted, maintained and kept in step separately, which is an additional integration in its own right.
Combining data held at different levels of granularity.
SAP data isn’t always structured the way a consolidation model would like. A real example of this arose with investment accounts. The investment security identifier was held at the document item level, not in the summarised trial balance data, while the investment category needed for consolidation existed only on the security master. Being able to judiciously replace summarised trial balance data with document-item detail for specific G/L accounts and then look up the investment category from the master record in the same extract, meant one reconciled dataset could be created at the point of transformation — something that would otherwise have required extracting and joining two separate datasets.
Handling organisational change without redesigning the extract.
Divestitures, acquisitions and internal restructuring change which entities, cost centres or profit centres exist and how they relate to one another. Transformation logic built inside SAP can draw on the current organisational structure as it stands, rather than on a fixed extract definition that has to be revisited and rebuilt every time the organisation changes shape.
Drill-down to the transaction, not just the extract.
Where transformation happens inside SAP, it’s possible to drill down not just to an extract record but to the individual SAP transaction line itself, viewed side by side with the target consolidation dimensions. That’s a materially different experience for a controller trying to understand a number than tracing it back through a transformation layer that sits outside SAP.
Supplemental analysis without manual enrichment.
Because the full granularity of SAP data is available, supplemental analysis that would otherwise need manual enrichment — fixed asset movements, geographical sales splits, debtor days — can be generated directly from SAP as part of the same process, rather than assembled afterwards from separate reports.
Validation against consolidation rules throughout the period.
Much of the validation logic of EPM systems is built into their metadata. Where this metadata is made available inside SAP, the transformation logic built inside SAP can validate data against the same rules the EPM system will apply, before the data is sent. That means issues are visible throughout the period, rather than surfacing only when data is loaded and checked at the consolidation system end. In addition, where an EPM system supports test loads that return an error log, those loads can be called directly from and evaluated in SAP against transformed live data at any point during the period.
Staying in sync without manual journals.
Because transformation works on live SAP data and can refresh the EPM system on demand, there’s no need for manual journals to catch up with late postings in SAP — the two stay in sync, supporting a more continuous approach to accounting rather than a period-end scramble.
One extractor, not many.
When SAP carries out the transformation and presents data to the EPM system already in its target format, only one extractor needs to be built and maintained on the EPM side — regardless of how many SAP sources feed it. Whether the underlying data comes from CO-PA, the new General Ledger, open items or controlling data, the EPM system sees a single, consistent source: data already in its own format. Where transformation happens downstream instead, each SAP source typically needs its own extractor, multiplying the development and maintenance effort.
Two further points worth adding
Two related advantages don’t appear explicitly above but follow from the same underlying principle — that transformation happens where the data already lives.
Consolidation metadata can be brought into SAP and used to validate entries as they’re configured — account codes, entities and other dimensions selectable from standard SAP dropdowns rather than typed against a specification document. That turns transformation logic from something written and maintained as code into something configured and checked in a familiar SAP interface, which matters for who can realistically own and change it over time.
Where a platform supports it, data can also be verified as it lands — a record count and checksum calculated before sending and re-checked once loaded, so a partial or corrupted transfer is caught automatically rather than discovered later during reconciliation. This isn’t universal across every EPM platform, but where it’s available it adds a further layer of confidence to data transformed and validated inside SAP.
The trade-offs — and why they’re smaller than they look
The obvious objection to everything above is that transforming inside SAP means development, owned by IT, sitting behind SAP’s own change and transport process — the opposite of the accessibility finance teams get by keeping mapping rules inside the EPM system itself. That’s a fair concern in principle. But it depends entirely on how the transformation is built, not on the fact that it happens in SAP.
Where transformation logic is hard-coded in custom ABAP, the objection holds: every change to a mapping rule really is a development task, requiring the same transport process as any other SAP code change. But where transformation is driven by metadata rather than code — mapping rules held as configurable data, maintained through a screen rather than written into a program — the picture changes. The business team can own the mapping directly, in much the same way they would in middleware or in the EPM system itself. It becomes part of day-to-day application maintenance rather than something that has to go through the SAP transport system. This is how it works in practice for EPM FastTrack customers, and it’s the detail that makes the rest of this post’s case actually usable rather than theoretical.
The same metadata-driven approach also addresses the other main concern about transforming in SAP — trust in the result. Because consolidation metadata is held in SAP alongside the mapping rules, a test load can be run and the transformed data checked directly against that metadata before anything is sent to the EPM system. That closes much of the gap between changing a mapping rule and being confident the output is correct: the validation happens in SAP, as part of making the change, rather than as a separate reconciliation exercise once the data has already landed elsewhere.
What doesn’t change is that mapping still needs to be controlled — but at the same level of control it would need in middleware or inside the EPM system itself, not a heavier one because SAP happens to be where it lives. And it remains true that entities running outside SAP will need their transformation handled elsewhere, regardless of how well SAP-side transformation works for the SAP entities in a group.
For organisations that are substantially SAP-based, then, transforming at source doesn’t have to mean adding an IT dependency to the consolidation process. With metadata-driven mapping and the ability to validate directly in SAP, ownership can sit with the business team already closest to the data — worth serious consideration alongside the more familiar pattern of transforming after the data has already left.
