A deep look at how M3 derives accounting from operational events through FAM functions and CO/CR codes, why this is the highest-error area in any M3 migration, and how to translate the full CO/CR estate into D365's posting profile surfaces — with a worked end-to-end example.
Every M3 operational event that has accounting consequences — an invoice confirmed in OIS, a goods receipt confirmed in PPS, a production order closed in MFS, an inventory adjustment posted in MWS — reaches the general ledger through the same two-layer indirection: a CO code on master data and a CR code on the event, resolved by a FAM…
A FAM Function (Financial Account Method function) is a configured account-derivation template in M3, defined per CONO. Each FAM function is associated with one or more accounting event types — the operational triggers that invoke it.
D365 F&O distributes account derivation across module-specific posting profile constructs rather than centralising it in a single FAM function. The main surfaces are:
The correct approach to CO/CR translation is empirical, not theoretical. The team must extract the actual (CO, CR, FAM function, resolved GL account, resolved dimension combination) tuples from the FGLEDG and FGLEDX posting history — covering at least three fiscal years — and use those tuples as the design input for the D365 posting…
This example traces one operational event — despatching and invoicing a customer order — through both systems. It is deliberately the full event rather than a single line, because the most common account-mapping error is to design the receivable side and forget that the same event also moves inventory.
The M3 voucher model and the D365 voucher model are close enough to compare stage by stage, but not close enough to migrate by name alone. In M3, an accounting-impacting event invokes a FAM function, resolves the CO/CR matrix, writes balanced FGLEDG rows and locks the voucher. In D365, an operational event creates a subledger journal;
For migrated vouchers, the engine should materialise three explanatory records even if the D365 ledger itself only needs the posted result:
M3's posting engine — FAM functions resolving (CO, CR) pairs through a multi-dimensional account-derivation matrix — is the most technically dense part of any M3 migration. The D365 posting profile framework achieves the same accounting outcome through a distributed set of module-specific configuration tables. Neither is a deficiency;