Why an SAP migration is a re-projection of one abstraction model onto another, not a table-to-table translation — and what that means for every decision that follows.
What you will be able to do
Explain why field-level mapping produces a ledger that loads but does not balance
Describe the event → intent → voucher → ledger pipeline in both systems
Name SAP's defining accounting primitive and its D365 counterpart
Recognise the three abstraction gaps that dominate SAP programme effort
Introduction
Every ERP system answers the same question: how do we turn operational reality — a goods receipt, a supplier invoice, a payroll run — into compliant, audit-ready accounting? SAP ECC and Dynamics 365 Finance & Operations both answer that question completely, and both answer it well.
Why field-level mapping fails
The intuitive approach to migration is to line up the tables. BKPF becomes the journal header. BSEG becomes the journal lines. KNA1 becomes the customer. MARA becomes the released product. Each of those statements is true, and a migration built on them will load.
The pipeline both systems share
Underneath the differences, both systems run the same four-step pipeline. Naming it explicitly gives the team a shared frame for every subsequent conversation.
What this means for the programme
Account determination is a workstream, not a task. Extracting, classifying and translating the OBYC and VKOA estate — plus the substitution and validation rules layered on top — routinely takes longer than the entire data-loading effort. It has to start early, it needs finance ownership, and it needs its own test harness.
Knowledge check
Summary
SAP and D365 F&O both produce audit-ready, reconcilable accounting. They do it through different abstraction choices, and a migration is the work of re-projecting one set of choices onto the other.