How Epicor Kinetic derives every GL account from GL Control Types and GL Control Codes attached to master and transactional records, how the resolution precedence works, and how each GL Control family maps onto D365's distributed posting-profile surfaces — including a fully traced purchase-receipt-to-invoice example.
What you will be able to do
Explain how GL Control Types define categories of account determination and GL Control Codes hold the resolved values
Describe the attachment precedence — how GL Controls on parts, part classes, product groups, customers, suppliers, sites, and transaction contexts resolve to a posted account
Map each GL Control Type family to its D365 posting-profile surface
Trace a purchase receipt through Epicor GL Control resolution and through D365 posting-profile resolution side by side
Explain the subledger-journal architecture and how D365 bridges operational documents to the general ledger
Design a GL Control crosswalk that a senior Epicor consultant and a D365 financial architect can jointly author
Introduction
Epicor Kinetic derives every GL account from two constructs: a GL Control Type that defines the category of account determination (what kind of posting event this is), and a GL Control Code that holds the actual account values for that category.
GL Control Types and GL Control Codes
A GL Control Type is a named category of account determination. Each type answers one question: "for this kind of posting event, how do I find the accounts?" Typical GL Control Types in an Epicor implementation include:
Attachment and resolution precedence
GL Controls attach at multiple levels of the master-data hierarchy. When a transaction posts, the runtime resolves which GL Control Code applies by walking from the most specific attachment to the least specific:
Mapping GL Control Types to D365 posting-profile surfaces
Each GL Control Type family maps to a specific D365 posting-profile surface. The table below provides the crosswalk:
The subledger-journal architecture
In Epicor, the GL Control resolution and the ledger posting happen as part of the same transactional operation — when a receipt posts, the GL entries are generated and committed (or batched for later posting, depending on configuration).
Worked example: purchase receipt to vendor invoice
The table below traces a single purchase order receipt of 500 units of a raw material at standard cost 8.00 per unit, followed by the vendor invoice, through both systems:
The reconciliation test
The reconciliation test for posting-profile design is: given the same operational transaction, does the D365 posting produce the same net GL effect as the Epicor posting? The test should run for at least one representative transaction from each GL Control Type family:
Knowledge check
Summary
Epicor Kinetic concentrates account determination into GL Control Types and GL Control Codes attached to master and transactional records; D365 distributes the same responsibility across a dozen purpose-built posting-profile surfaces.