How SAP's leading/non-leading ledgers, the account and ledger approaches to parallel GAAP, multi-currency company codes and EC-CS-style consolidation map onto D365's one-ledger-per-legal-entity model — posting layers, reporting currency, fixed-asset books, separate legal entities and the Consolidations module — plus a decision tree for choosing the right mechanism, and an honest account of where no equivalent exists.
Part 1 of this domain reconciled SAP's chart of accounts and account-assignment model into a shared D365 chart of accounts and account structures, and gave the ledger question one paragraph: one ledger per legal entity, parallel accounting via posting layers and fixed-asset books.
A D365 ledger is a single configuration record — chart of accounts, currency (accounting currency plus an optional reporting currency), and fiscal calendar — attached to exactly one legal entity. General ledger parameters point every legal entity at its ledger;
Part 1's caution stands: no statement that "D365 has several ledgers per legal entity" is ever correct. What is worth adding here is exactly what a posting layer is, and exactly where its resemblance to a SAP non-leading ledger ends.
A D365 ledger carries exactly two live currencies: the accounting currency — the ledger's home currency, in which every main account balance is stored — and, optionally, a reporting currency, a second currency maintained in real time on every transaction line, not derived at period end.
A fiscal calendar can be shared across several legal entities — the calendar itself is just a sequence of period start and end dates. Attaching it to a specific ledger, though, creates a ledger calendar: a per-legal-entity copy of that shared calendar.
D365 offers four distinct ways to combine legal-entity balances, and choosing the right one for the right reporting requirement matters more than the mechanics of any single one:
D365's audit trail runs through the Voucher, not a document number: every subledger transaction links to the GL entry it produced through a shared voucher, and the Voucher transactions inquiry drills from any GL line to every subledger line that fed it, and back — the functional replacement for SAP's BKPF-AWTYP/AWKEY chain.
Every statutory or reporting requirement that would have been "another ledger" in SAP reduces, in D365, to one of six questions. Test them in order, top to bottom, and stop at the first one that genuinely fits — each option further down is more expensive than the one above it:
Take a four-country group migrating off one SAP client: a German parent (leading ledger IFRS, non-leading ledger for local GAAP, group currency EUR, no hard currency), a US subsidiary (single ledger, USD, July-to-June fiscal year for US tax reasons), a Brazilian subsidiary (single ledger, BRL, local statutory depreciation rules diverging…
D365 replaces SAP's leading-plus-non-leading-ledger model with exactly one ledger per legal entity, and meets every parallel-accounting requirement SAP solved with an extra ledger through a composition of narrower mechanisms instead: posting layers for same-calendar management or tax deltas, fixed-asset books for depreciation…