How the coding block you already use becomes a main account plus named financial dimensions, how account structures decide which combinations are legal, and what a D365 ledger holds — currencies, calendars, posting layers and the close.
Almost every general-purpose ERP stores the coding block as one string with meaningful positions. Characters one to four are the account. Five to seven are the cost centre. Eight and nine are the department. Ten to thirteen are the project.
A main account in D365 is the account and nothing else: bank current account, trade debtors, raw material stock, salaries, freight in, sales of finished goods. The list of these is the chart of accounts, which is a shared object in the environment — created once and assigned to the ledger of each legal entity that uses it.
A financial dimension is a named attribute with a set of values, attached to ledger entries and to transactions throughout the system. Cost centre, department, project, brand, region, channel, funding source, campaign, customer group — anything the business needs to see balances by.
If dimensions describe what can be recorded, the account structure describes what may be recorded.
Each legal entity has exactly one ledger. The ledger is where the finance configuration comes together:
Manual and semi-automated entries come in through journals, and each type of journal is configured as a journal name — a template that specifies:
Three finance capabilities matter for almost every implementation, even simple ones.
The financial period close workspace turns the month-end checklist into a tracked process: tasks with owners, dependencies, due dates and status, visible across legal entities. For a group closing several ledgers this replaces the spreadsheet that traditionally holds the whole thing together.
Here is the exercise in full, using a coding block of the kind most mid-market systems carry.
Finance modelling in D365 is the decomposition of a string into named objects, and everything downstream depends on doing it properly.