AI-Based Account Assignment per Invoice Line Item: A Practical Test

An invoice from the IT vendor, with five line items: a laptop for 749 euros, a monitor, a docking station, a software subscription for ten users, and a server maintenance contract. When posting such invoices, you don’t post them to a single account, but to four: low-value assets, small equipment, licenses, and maintenance.

To read the bill, via OCR for invoices and extraction is the easier part. Automatically assigning an account code to each individual line item is the harder part.

That's exactly what we tested. A language model reads the invoice and suggests a general ledger account from the chart of accounts for each line item, along with a brief explanation.

The test runs on a completely synthetic dataset: 12 fictitious invoices with 37 line items, two fictitious companies, 30 fictitious suppliers, and 30 accounts from the DATEV chart of accounts SKR 03. The figures below are from three complete runs.

The most Important in a Nutshell

• For each invoice line item, a language model suggests a general ledger account from SKR 03 and justifies the selection based on the document.
• In the synthetic test involving 12 invoices and 37 line items, 37 out of 37 suggestions were plausible in all three runs; none were incorrect.
• The only questionable justification was flagged by an audit rule; the entry will not be posted until it has been approved by the accounting department.

What is AI-based account assignment, and how does it differ from extraction?

Extraction and account assignment are two different tasks, even though they occur in the same step. The extraction process reads the information on the invoice: invoice number, vendor, VAT ID number, amounts, and the line items with quantity and price. You can verify whether the result is correct by checking the document.

The account assignment is not listed on the invoice. It is a reasoned estimate of where an item should be posted. It depends on the description, the amount, and which company receives the invoice. That is why we require the model to provide a justification for each account based on the invoice. This turns an estimate into a suggestion that the accounting department can quickly review.

Pre-assignment itself is not a new idea: In the past, it was indicated by an account assignment stamp on the paper document. Posting suggestions from the posting history require previous documents from the same supplier. A language model does not need this background information. It classifies each line item based on its description, even for the first document from a new supplier.

How the Test Is Structured

The invoices are from fictitious suppliers such as „IT-Handel Muster GmbH“ and are addressed to „Beispiel Maschinenbau GmbH“ or „Beispiel Service GmbH.“.

The items are deliberately mixed: sheet metal and maintenance of a CNC milling machine for mechanical engineering; coffee and reference books for the office; a hotel and parking on a business trip; a client dinner and an internal team breakfast on the same catering bill.

The extractor in Konfuzio takes three things into account:

• Fields: 13 in total, ranging from the invoice number to the line item table, which includes the “G/L Account” and “Description” columns.
• Chart of Accounts: 30 accounts from the DATEV SKR 03, valid for 2026, each with a number, a description, and a statement indicating the purpose of the account. Only two accounts are permitted for mechanical engineering, such as the goods receipt account 3200.
• Vendor Master Data: 30 vendors with vendor numbers, names, and VAT ID numbers. Eight of them do not have a VAT ID number on file, as is the case with real master data.

In addition, there are eight validation rules, formulated as yes/no questions: Does the sum of the line items match the net amount? Is the account valid for the receiving company? Is each line item in account 0480 between 250 and 800 euros net? A separate model call answers these questions after extraction and flags any rule that is not met. Each value read remains linked to its location on the document: Clicking on a field highlights it in the document.

For each item, we have predefined the expected account and, where the assignment is a matter of discretion, the permissible alternatives. The monitor, priced at 229 euros, is classified as a small appliance; it is perfectly acceptable to record it as “other operating expenses.” These classifications are our assumptions for the purposes of this test—they do not constitute tax advice. In your own business, the accounting department or tax firm will determine the appropriate classification.

What the measurement shows

The reading was error-free in all three runs: 132 out of 132 header records and 148 out of 148 values in the fields were correct. This is to be expected with properly formatted PDF invoices and is not an indicator of skewed scans.

The vendor number was correct twelve times in each run: it was found nine times and left blank three times because the master data does not contain a VAT ID number for these vendors.

The account assignment is more interesting. The model correctly identified the expected account in 33 to 34 out of 37 entries. The remaining suggestions were valid alternatives, such as “outsourced services” instead of “goods received” for the cutting of sheet steel. This meant that 37 out of 37 accounts were plausible in every run; none were incorrect.

The justifications make all the difference in the review. Regarding the laptop, the model states: „A laptop is a standalone device with a net price of 749.00 EUR and falls within the minor asset range of 250 to 800 EUR.“ The 800-euro threshold applies to immediate deduction under § 6(2) of the Income Tax Act (EStG).

In the case of smartphone installment payments, however, the justification does not hold up. In two transactions, the model posted the installments to 0480. The description read „25.00 EUR per installment in the GWG range.“ However, an installment of 25 euros is well below the lower limit specified by our chart of accounts for this account.

That is exactly what the validation rules are for. The rule „For every line item with general ledger account 0480, is the unit price between 250 and 800 euros net?“ triggered an error in both runs, with the explanation that the unit price was only 25.00 euros.

In total, the validation rules flagged 11 out of 288 checks across all three runs. Each flag was justified: three times per run, a supplier without a VAT ID number in the master data; twice, the smartphone rate. There were no false positives.

Between the three rounds, 4 out of 403 values changed, not counting the freely worded explanations. All four were general ledger accounts—specifically, the very items where someone in accounting would weigh the options between two accounts: monitor, docking station, smartphone plan, and the learning platform.

Three Practical Challenges

Before we built the synthetic test, we ran the same setup as a proof of concept using actual incoming invoices. We’re not publishing the figures from that test, but we are sharing three lessons learned:

• Leave blank if unsure: The instruction „Leave the field blank if you’re not sure“ in the account column sounds cautious. Combined with the rule to leave unprinted table values blank, it cleared most accounts in real invoices. In a single run using this instruction on our clean, synthetic invoices, however, only one of 37 accounts remained empty. This is a hint, not a clean comparison. A better approach is to have an account with a justification and a validation rule that flags uncertain cases.
• Master Data Without a VAT ID: Vendor reconciliation using the VAT ID is unambiguous, but fails for any vendor for whom the VAT ID is not stored in the master data. Matching by name is not a good workaround because company names on invoices are spelled differently than in the master data. Even in the test data set, the invoice says „Papierhaus Muster KG,“ while the master data says „Papierhaus Muster Kommanditgesellschaft.“.
• Variation between runs: The same calculation doesn't always yield the same result. Therefore, when comparing two configurations, you need to run multiple simulations for each variant. This is similar to the differing assessments of two accounting staff members.

E-Invoicing and GoBD: Why the Justification Matters

As of January 1, 2025, companies in Germany must be able to receive e-invoices; after the transition periods, e-invoicing will be mandatory between domestic companies, as the Federal Ministry of Finance in its FAQs on e-billing explained. The e-invoice provides the line items in a machine-readable format. This makes reading the invoice easier, but not the account assignment: As a rule, an XRechnung does not specify which account a line item should be posted to.

An old principle applies to accounting in this regard. The GoBD of the Federal Ministry of Finance state in paragraph 63: „Commercial or business letters received or sent do not serve as accounting documents until they have been marked with an account assignment and posted.“ According to paragraph 64, for electronic documents, a link to a data record containing the account assignment is sufficient.

An AI suggestion—complete with a rationale and documented approval—can provide exactly this data set if the account and approval are stored linked to the document. Ultimately, however, a human should still post the entry, as part of the Digital Invoice Review and Approval, which comes before every payment anyway. Our overview of the AI in Accounting.

Conclusion

AI-based account assignment for each invoice line item works when three conditions are met: a chart of accounts with descriptions rather than just numbers, a rationale for each suggestion, and validation rules that flag uncertain cases. In the synthetic test, 37 out of 37 suggestions were plausible in each of the three runs, and the only questionable justification was flagged by a validation rule in both affected runs. A human still handles the approval process but checks justifications instead of manually entering source documents.

If you want to use AI to post invoices to the appropriate accounts and test this with your own data, you don’t need much: 20 typical incoming invoices, your own chart of accounts, and your vendor master data. We can provide the synthetic dataset, the configuration, and the analysis from this test upon request. Please contact us if you’d like to repeat the test using your own invoices.