Posting Profiles Overview
Within our enterprise architecture, the term posting profiles delineates the configurations that dictate how subledger entities (such as customers, vendors, or inventory items) are dynamically resolved into explicit General Ledger (GL) main accounts during financial posting. For instance, they control the precise mapping of a customer invoice to the appropriate Accounts Receivable main account.
Numerous modules incorporate dedicated posting profile pages (e.g., Customer posting profile, Vendor posting profile, or Inventory posting profiles). These matrices ensure that operational subledgers and the General Ledger remain perfectly synchronised without requiring manual account entry by the user.
Prior to configuring any posting profiles, or indeed the Accounts for automatic transactions fallback, you must ensure that your Chart of Accounts is fully configured and activated for the relevant legal entity.
Posting Types
A posting type defines a rigid, systemic category for a debit or credit leg of a transaction. This category operates independently of the main account, serving as the architectural bridge between the subledger event and the GL.
A single transaction voucher will typically contain multiple posting types. For example, a standard vendor invoice voucher encompasses a posting type for the vendor balance (the liability) and corresponding posting types for the offset entries (e.g., procurement expense or inventory receipt). If the system attempts to process a posting type but cannot resolve it to a main account, it will halt the transaction and generate an exception, typically stating: "The account for [Posting type] can't be found."
The Resolution Hierarchy
When configuring posting profiles, the system employs a deterministic matching engine based on the Account code field. This dictates the specificity of the configuration line. The matching engine evaluates rules from the most specific to the least specific (Table → Group → All), ceasing its search upon the first successful match.
1. Table Value (Most Specific)
The Table value designates that the posting rule applies to a singular, specific master record (e.g., a specific customer or a specific item). When you select Table, you must explicitly declare the unique record ID in the adjacent relation field.
The system will unconditionally use a Table rule if one exists, superseding any Group or All configurations.
We strongly advise against utilising the Table value as your primary mechanism for mapping accounts. Maintaining a unique posting profile line for every individual master record is operationally unsustainable and introduces significant data quality risks. The Table value should be reserved strictly for managing rare, explicit exceptions.
2. Group Value (Balanced Specificity)
The Group value applies the posting rule to a predefined collection of master records. When you select Group, you must specify the relevant group ID (e.g., a Customer Group or Item Group) in the relation field.
If a Table level exception does not exist, the system seeks a Group match. This is the optimal, architecturally sound method for managing posting profiles. By segmenting your master data into logical groups, you achieve granular financial control without the administrative burden of individual record mapping.
Example Scenario:
Suppose you require three distinct Accounts Receivable control accounts for reporting purposes: Regular Customers, Employees, and Intercompany Entities. You would configure three Customer Groups (EXT, EMP, INT) and create three corresponding Group lines in your posting profile, mapping each to its respective main account.
3. All Value (Least Specific / Failsafe)
The All value signifies a universal default. When this value is selected, the rule applies to every record that does not match a more specific Table or Group rule. Consequently, the specific relation field becomes unavailable.
You should establish an All rule when your enterprise utilises a single main account for a specific posting type, or as an absolute failsafe to prevent systemic posting errors when new master records are created without a designated group.