Turn a company-database chart of accounts, its segments, distribution rules and project codes into a governed main-account and financial-dimension design with account structures that hold.
Finance modelling on this path has an unusual property: it is simultaneously the least surprising and the most consequential workstream. The source material says as much — finance usually migrates with fewer semantic surprises than warehouse and production.
In SAP Business One, each company database holds its own chart of accounts. Nothing forced two databases to agree, and over time they will not have.
Where the client uses a segmented account format, the decomposition is the defining piece of work in this module, and the gap register rates it a high-impact structural gap: D365 separates main account and dimensions, so source segment meanings must be decomposed before migration.
Distribution rules — profit centres, cost centres and their allocation behaviour — are where finance modelling on this path gets genuinely interesting, and where the source package's confidence drops to medium because client usage varies so much.
Project codes appear in the finance conversation because they frequently function as an analytical dimension rather than as project delivery.
Currency design is where misconceptions about the target model do the most damage, so it is worth being precise.
Source close routines are a requirements statement, not a design to reproduce. Capture them properly, because they reveal controls that exist nowhere else:
The canonical wave order puts finance foundations first, and the playbook's recommended sequence follows the same logic:
Finance modelling produces the artefact everything else waits for: a signed chart, dimension set and account structure design.