From Fixed Posting Rules to Context-Sensitive Recommendations
Invoice coding determines where an expense is recorded in the financial system. An invoice or invoice line item is assigned a general ledger account and relevant dimensions, such as cost center, department, project, or business unit. Amounts can be distributed across multiple combinations.
Coding is different from recognizing document data. OCR and Intelligent Document Processing, for example, can extract the supplier, description, amounts, and invoice line items. Invoice coding then translates that data into the organization’s own accounting structure.
For invoices that are correctly linked to a purchase order, the financial destination should, in principle, be derived from the order line. After all, the account, cost center, or project was already specified when the obligation was created. The specific use case for intelligent coding therefore primarily involves invoices and invoice lines without a purchase order, or costs not covered by the original order coding.
Where Traditional Automation Falls Short
Traditional automation relies on defaults, posting templates, and decision rules. For example, a specific supplier is linked by default to a single cost account, while dimensions are derived from the supplier, the item, the invoice header, or a fixed allocation key. For recurring and predictable expenses, this approach is verifiable and efficient.
The margin for error increases when the supplier does not provide sufficient information about the nature or destination of the costs. A broad-service provider may invoice consulting, software, training, and travel expenses on separate lines. Furthermore, the same expense may be incurred for different departments, projects, or legal entities. A default account at the supplier level may be automatic, but it is not necessarily accurate.
Invoice descriptions are also rarely fully standardized. Abbreviations, contract names, time periods, and free-form text can all refer to the same cost type without matching exactly. Sometimes, it is information outside the description that determines the posting: who issued the order, which location benefited, or for what purpose the costs were incurred.
In traditional automation, this leads to increasingly granular rules: by supplier, entity, cost type, amount, department, and exception. Such rules can overlap and must be adjusted whenever the chart of accounts, the organization, or purchasing behavior changes. As a result, a technically valid combination of account dimensions may still be substantively incorrect.
How Intelligent Automation Can Improve Things
Intelligent automation can treat invoice coding as a classification problem. Based on previously approved journal entries, it searches for patterns between invoice lines and the accounts and dimensions used. In doing so, factors such as supplier, line description, amount, entity, known cost center, and previous posting combinations can be considered collectively.
The result is not a new accounting fact, but a probable coding suggestion. This suggestion can be made on a segment-by-segment basis. For example, the general ledger account can be identified with sufficient certainty, while the project remains unknown. An uncertain component does not need to be filled in. Research into automated invoice coding shows that the predictability of an account and that of a cost center can vary significantly.
This method can also identify variations that are not programmed as separate lines. Similar descriptions and posting patterns may point to the same cost type. For a supplier offering various services, the content of the invoice line item may therefore carry more weight than just the supplier default. Known data, such as a cost center that has already been defined, can also help determine the remaining coding more accurately.
Probabilities should not replace administrative rules. The proposal must be checked against the current chart of accounts, valid dimension values, permitted account-dimension combinations, and tax or organizational requirements. A model must not use an obsolete account, select a project outside the relevant entity, or infer a VAT treatment when a hard rule or additional information is required for that purpose.
Historical entries are also not automatically accurate. They may contain errors, temporary workarounds, and choices that have since been changed. Corrections can improve future proposals, but only when the final, approved coding is taken as the starting point and changes to the chart of accounts or organization are managed separately.
Intelligent automation thus adds context to the coding step, while traditional controls limit the outcome:
Fixed rules determine which journal entries are permitted; intelligent automation helps predict which permitted accounts and dimensions best match the invoice.