AI-based account assignment

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 – as they come out of document capture. 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. This is also why a high automation rate is not on its own a sign of quality.

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. In the purchase-to-pay process the same tiering decides how much runs through untouched.

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. That requirement becomes harder where agent-based workflows choose their own route. 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. If that operational responsibility is temporarily unstaffed, interim accounting can bridge the gap.