How NetSuite's per-Item-record posting logic — Income, Asset and COGS accounts on every item — maps to D365 Item Group posting profiles, and how to run the cluster-and-map exercise that converts tens of thousands of scattered account fields into a manageable, maintainable profile set.
If the orientation module explains why NetSuite's posting logic is different from D365's, this module explains how to move one to the other — in detail, with arithmetic. The posting engine is the conceptual heart of a NetSuite migration, and it is the workstream most often underestimated by project plans that treat it as a data task…
When a NetSuite transaction posts, the system computes the GL Impact by a three-step rule.
D365 F&O computes equivalent GL impact through posting profiles — small, reusable configuration tables keyed by group combinations.
The procedure for translating NetSuite per-Item accounts into D365 posting profiles is called the cluster-and-map exercise. It must be completed before any data wave runs.
This example traces a single sales transaction through both posting engines. The transaction: 10 units of Item WIDGET-001 are fulfilled from Warehouse-East and invoiced to Customer ACME-CORP at USD 25 each. The item's cost at the time of shipment is USD 18 per unit.
The cluster table proves that D365 can choose the right accounts. The transaction-lifecycle map proves that D365 chooses them at the right business event. NetSuite's unified Transaction record covers more than thirty built-in types plus Custom Transaction Types; D365 represents the same lifecycle as linked documents.
The posting engine translation is the programme's most important technical workstream. It is not fast, it cannot be automated end-to-end, and it requires controller sign-off at each step.