AI-based account assignment
AI-based account assignment is the automatic mapping of business transactions to general ledger accounts, cost centres and tax codes by a learning model. It is trained on the company's own posting history. For recurring transactions the hit rate is high; special cases have to be routed out for manual review by rules.
Where a posting proposal comes from
The model learns from the company's posting history: which supplier has been posted to which account so far, with which cost centre and which tax code? Added to that are features of the document – amount, text, line items, recurrence signals. The proposal is therefore company-specific: a model trained on someone else's data knows neither the chart of accounts nor the conventions of the house.
Where the mapping is reliable
For recurring transactions with a stable pattern: rent, software subscriptions, telecommunications, vehicle costs, insurance, recurring services. After a handful of documents from the same supplier the proposal is as a rule correct – and usually better than that of a newly trained assistant, because it takes the entire history into account rather than a memory.
Where it is confidently wrong
This is the critical point: a model also outputs a high-confidence proposal when the case is new. Affected above all are:
- documents that have to be split between capital expenditure and running cost,
- invoices with mixed VAT rates,
- expenses relating to another period and accruals across the year end,
- intra-community supplies and services,
- reverse charge and construction services,
- pass-through items and disbursements,
- advance payments and partial performance.
For these groups a confidently wrong proposal is more dangerous than no proposal, because it is adopted unchecked. They need a rule that recognises them by a feature – supplier country, tax code, amount threshold, keyword in the document text – and routes them out for review without exception.
What a durable set-up looks like
Three tiers have proven themselves. First, fixed rules for unambiguous repeat cases – these need no model. Second, the model for the variable remainder, with a threshold above which a proposal is adopted without a query. Third, an exception list for the special cases above, which are always reviewed regardless of the model's confidence.
What the GoBD require
Automatically generated postings are permitted but must be traceable: who or what posted, on what basis, when, and how it was subsequently corrected. The evidence belongs in the process documentation. Responsibility for the correctness of the books remains unchanged with management – a model does not take it on.