Why JD Edwards' Ledger Types — AA, AU, BA, CA and an open set of user-defined codes, all coexisting in the same F0902/F0911 tables — have nothing shaped like them in D365, how each one re-homes onto a different D365 mechanism, and a decision tree plus worked multi-country example for choosing the right one.
If Business Unit.Object.Subsidiary is the hardest habit to unlearn in JD Edwards' chart of accounts, Ledger Types are the hardest concept to re-home in its ledger regime — and, arguably, the single most distinctive financial idea in the whole JDE platform.
A Ledger Type is a two-character code, validated against UDC 09/LT, that JDE attaches to every row in F0902 (Account Balances) and F0911 (Account Ledger) to say which parallel "view" of the account that row represents. The common ones ship as part of the base application:
Because the axis itself has no D365 counterpart, the practical task is routing each ledger type in use to wherever its actual purpose belongs:
A D365 ledger belongs to exactly one legal entity and combines a chart of accounts, a fiscal calendar, an accounting currency, and optionally one or more reporting currencies.
D365 posting layers — Current, Operations, Tax and seven Custom layers (ten in all) — let a transaction post an adjustment on top of the Current layer without altering it, all within the same ledger, sharing its calendar, currency and chart of accounts.
JDE typically carries a foreign-currency view of a transaction either through domestic and foreign companion amount fields on the same record, or, in the ledger-balance tables, through a paired CA ledger-type row alongside the corresponding AA row — with the currency itself identified through the CRCD (currency code) data item wherever…
Many JDE sites never invest in formal consolidation processing at all. Instead, group numbers are produced by rolling up Business Units and companies through the F0006 hierarchy into a summarised report, with intercompany balances netted manually, often in a spreadsheet, rather than through any defined elimination logic.
Every "we need another ledger type" requirement reduces, in D365, to one of seven questions. Test them in order and stop at the first one that genuinely fits:
Take a three-country group migrating off one JDE environment: a US parent (AA, BA budget, and a user-defined "WI" what-if ledger type for a rolling forecast, all in USD, calendar-year fiscal year), a Mexican subsidiary (AA, a CA companion row for USD-equivalent reporting, and a user-defined "X1" tax ledger carrying an alternate statutory…
JD Edwards' Ledger Types are the most distinctive financial concept in this whole migration path, and D365 genuinely has nothing shaped like the mechanism as a whole: an open, user-extensible axis letting unlimited parallel views coexist permanently in the same tables.