Reverse-engineering the posting engine when no account-determination reference exists
Why Plex's silence on account determination is structurally unusual, what other systems publish for comparison, the full D365 posting-profile model, and a rigorous reverse-engineering method for deriving posting rules from a GL export when no lookup table exists to translate.
What you will be able to do
Explain what account determination is and why every ERP needs a systematic mechanism for it
Contrast Plex's undocumented approach with the published mechanisms of SAP, JD Edwards, and Epicor
Describe every D365 posting-profile surface and the resolution pattern each follows
Execute a reverse-engineering method that derives account-determination rules from a Plex GL export
Validate the derived rules by replaying a period and reconciling account-level totals
Identify the risks of a reverse-engineered posting design and the mitigations each requires
Introduction
Every ERP needs a systematic answer to one question: when an operational transaction occurs — a purchase receipt, a customer invoice, a depreciation run, a production completion — which general-ledger accounts does the system debit and credit? The mechanism that answers this question is the account-determination engine, and it is, in…
What account determination is and why every ERP needs it
Account determination is the bridge between operational activity and financial reporting. An operational user posts a purchase receipt; they should never need to know or type the inventory account number. The system determines it from the transaction type, the item classification, and the configuration rules someone designed in advance.
What other systems publish — and why Plex's silence is unusual
To calibrate how unusual Plex's documentation gap is, consider what three other source systems expose:
The D365 posting-profile model in full
D365 distributes account determination across purpose-built surfaces, each owning one subledger or transaction family. The pattern repeats: a posting type (the kind of accounting event) combined with a relation (the classification of the entity or item involved) resolves to a main account and optional default financial dimensions.
The reverse-engineering method
When no published account-determination reference exists, the posting design must be derived from evidence. The method below is the structured approach this path requires.
The risk register for a reverse-engineered design
A posting design derived from evidence rather than documentation carries specific risks that a documentation-based design does not:
When the GL export is unavailable or incomplete
In some engagements, the Plex application owner cannot produce a GL export at transaction-line grain — whether due to system limitations, data-governance restrictions, or the data-extraction constraints documented in GAP-PLEX-004.
Knowledge check
Summary
Plex's posting-engine chapter is structurally different from every other chapter on this site because the source system publishes no account-determination reference. Where other paths translate a known mechanism (OBYC, F0012, GL Control Types) into D365 posting profiles, this path teaches a method for deriving the mechanism from evidence.