How to build the D365 finance model from a QAD estate whose account-string design, calendars and currencies must be extracted from a tenant rather than read from documentation.
Finance design on this path has an unusual shape. The target side is fully documented — Microsoft publishes the ledger model, the account structure mechanics, the dimension framework and the period-close tooling at a level of detail nobody needs to guess about. The source side is not.
Four extracts, named in the adapter's finance notes as required discovery outputs. Everything in this module depends on them.
The central design act is deciding which parts of the QAD account string become the D365 main account and which become financial dimensions.
Prefer one shared chart of accounts across legal entities, with account structures and advanced rules governing which accounts and dimension combinations each entity may use. Divergent per-entity charts are supported but multiply every subsequent maintenance action and make consolidation harder to prove.
An account structure is the contract between a main account and the dimensions that may accompany it. Getting these right at design time is the difference between a chart that stays clean and one that degrades every period.
Three target facts govern the finance model, and it is worth stating them precisely because assumptions in this area cause expensive design errors.
Fiscal calendars are shareable across legal entities where the period structure matches, and separate where it does not. Neither is expensive. What matters is that the calendar reflects the entity's actual statutory year, including any short first period arising from the cutover date.
Order matters, and the playbook's target-landscape sequence is the one to follow.
The D365 finance model is fully knowable; the QAD side of it is not, and the gap is closed by extracts rather than by inference. Demand the four-part finance discovery package, split the account string on the "what happened" versus "where and who" test, prune dimension candidates against named consumers, and constrain account structures…