How to translate LN's financial coding block — ledger accounts, its five dimension types, currency systems, and fiscal period structures — into D365 main accounts, financial dimensions, account structures, and the D365 ledger model.
Finance modelling is where the precision of the migration is ultimately judged. A goods receipt that posts to the wrong account, a project cost that misses a mandatory dimension, a foreign-currency revaluation that uses the wrong rate type — all of these failures are finance failures, even if they originate in an inventory or production…
Each LN Financial Company maintains its own chart of accounts — a set of ledger accounts (in the tfgld\ table family)* each with a natural account number, a description, a type (balance-sheet or P&L), and a currency behaviour flag.
Each LN Financial Company operates with a home currency — the functional and statutory base for all accounting. All ledger balances are maintained in the home currency. LN also supports a secondary currency that allows each transaction to be simultaneously expressed in a second currency, enabling dual reporting without separate postings.
LN supports financial consolidation through two mechanisms. The first is the Group Company — a Financial Company configured as a consolidation entity that aggregates balances from subsidiary Financial Companies.
Designing D365 account structures is necessary but not sufficient. D365 account structures enforce which dimension combinations are valid; they do not supply dimension values. The dimension defaulting strategy — which master records carry which default dimensions — must be designed alongside the account structures.
LN's financial coding block is rich and precise. Translating it to D365 requires working through each element systematically — accounts, dimensions, currencies, periods, and consolidation — and making an explicit design decision for each.