Bank transaction enrichment, categorisation & booking suggestions (Kontierung)

Bank statements contain cryptic strings such as "SEPA-LASTSCHRIFT AMZN MKTP DE*1A2B3 LUX". Bookkeepers and accountants still decide, line by line, which G/L account, tax key and cost centre applies. AI normalises the counterparty, classifies the transaction and proposes the booking based on how the same counterparty was booked before. The human confirms or corrects; every correction improves the next proposal. The same engine serves personal finance apps and bank-side analytics.

Problem & value

• Today: SMB owners and tax-advisory firms export bank data, match it manually against receipts and assign accounts (Kontierung) in DATEV, Lexware, sevDesk and similar tools. In practice this is repetitive: most lines repeat counterparties already booked (rent, telecom, fuel, SaaS, insurance).
• AI value: rule- and history-based suggestions handle the repetitive bulk; ML/LLM covers new or ambiguous counterparties; humans handle exceptions. Benefits are less keying time and more consistent accounts. The scope note for this use case (research/sweep_results.json) names DATEV, lexoffice/sevDesk, Ntropy, Tink and Bud as evidence; I could not independently verify vendor-published accuracy or time-saving figures this session, so none are quoted here. Ntropy markets "human-like accuracy in milliseconds" without published metrics on its homepage [1] — treat such claims as unverified and measure on your own data.
• Bank/fintech side: enriched, categorised transaction data feeds personal-finance apps, cash-flow forecasts and affordability checks (see regulation: the latter can become high-risk).

Variants

• SMB bookkeeping (Kontierung): suggestion of SKR03/SKR04 account, tax key (Steuerschlüssel) and cost centre; DATEV export. (Absorbed variant of the dropped AGENT-034.)
• Tax-adviser mass bookkeeping: one model/rule base per client plus shared cross-client priors; reviewer queue sorted by confidence.
• Matching to documents: link transaction to invoice/receipt (see DOC-001, DOC-002, AGENT-006 reconciliation).
• Banking / fintech enrichment API: merchant normalisation, logos, categories, recurrence for apps and underwriting features.
• Private finance: budget categories and subscription detection in budgeting apps (PERS-001).
• Public sector / enterprise treasury: categorisation into budget lines or cash-flow categories for liquidity planning (PRED-016).

How it works

1. transaction feed (PSD2 AIS API | CAMT.053 / MT940 | CSV)
2. cleaning (strip reference noise, normalise SEPA purpose text, detect IBAN/BIC, currency)
3. counterparty resolution (exact IBAN match
4. fuzzy name match
5. merchant database / LLM)
6. classification (rules first, then ML classifier / embeddings + nearest past bookings, then LLM for the long tail)
7. booking proposal (G/L account, tax key, cost centre; document match)
8. confidence routing (auto-accept above threshold per counterparty | review queue below)
9. export (DATEV/ERP/API) + audit log of suggestion vs. final booking

• Layered design: deterministic rules and IBAN-based memory solve the large majority cheaply; a small text classifier or embedding retrieval over historical bookings handles variants; an LLM with retrieved examples (few-shot from the client's own bookings) and the chart of accounts as constraint handles the tail. Constrain the output to valid account numbers from the chart (structured outputs / enum) so it cannot invent accounts.
• Human-in-the-loop: accepted/corrected bookings become training and retrieval data; new counterparties, amounts above a threshold, tax-relevant keys and anything touching VAT require review. Tax responsibility stays with the bookkeeper.

Data preparation

Needed data: bank and card transactions (CAMT, MT940, CSV or PSD2 bank interfaces), the chart of accounts (SKR03/04), the booking history from the accounting system or ERP, supplier and customer master data, cost centres, and receipts or invoices in the DMS or mail. Typical gaps are cryptic booking texts, inconsistent historical bookings, receipts not linked to transactions, paper receipts, duplicate suppliers, and wrong past tax keys which would be learned as truth.

Preparation steps: - Export bookings and transactions from the accounting system (PREP-005) and tidy them into one table (PREP-011). - Harvest labels from past correct bookings and exclude doubtful periods (PREP-020). - Clean supplier master data and define a category and account scheme (PREP-019). - Scan and OCR receipts to match them with transactions (PREP-006, DOC-014). - Create a test set of reviewed bookings (PREP-018), pseudonymise before external APIs (PREP-022).

Tools: accounting software export, Paperless-ngx for receipts, a simple tabular model or embeddings. Data effort is about 25 to 35 percent. See GUIDE-003.

Implementation paths

Which path for whom

• SMB: Path A, because accounting and banking software with bank feeds and learning booking suggestions (including EU-hosted DATEV-compatible products) is mature and the process is standard.
• Enterprise: Path B, because finance teams need integration with own ERP, chart of accounts and cost centres, and the volume makes API costs cheaper than seat licences.
• Developer: Path C, because a small classifier or local LLM on HW1 plus embeddings is enough, and financial data stays in-house.
• Private: Path A, because budgeting apps and bank-app categorisation need no setup; local tools suit privacy-minded users.

Path A — Buy (recommended for most SMBs)

• Accounting/bookkeeping software with suggestions: DATEV Unternehmen online (exchange of receipts and data between company and tax adviser [2]), Lexware Office, sevDesk, Buchhaltungsbutler, Candis, Xero, QuickBooks — check which learn from your own history and which export cleanly to your tax adviser's DATEV.
• Enrichment APIs for fintech/banks: Ntropy (transaction enrichment, categorisation, entity identification, recurrence; SOC 2 Type 2 per its site [1]), Tink (Visa), finAPI (German, BaFin-licensed AIS provider), Bud, Plaid. EU/German: finAPI, Tink (Sweden), Kontist/Qonto-style neobank features.
• Choose A when: you use standard SKR charts and a mainstream bookkeeping tool; verify EU hosting and data processing agreement.

Path B — Build on cloud APIs

• Ingest via PSD2 AIS aggregator (finAPI, Tink, GoCardless Bank Account Data) or file import.
• Classification via an LLM with structured output (e.g. Claude, Gemini, GPT, Mistral — EU region/provider where personal data is present), few-shot examples retrieved from the client's history (embedding model + vector DB), chart of accounts as enum.
• Orchestrate with n8n/Power Automate; export through DATEV interfaces or the accounting tool's API.
• Choose B when: custom chart, multi-entity logic or an own product is needed. Pseudonymise names/IBANs of private persons before sending where feasible.

Path C — Self-host (open source)

• Models: small open-weight LLMs (Qwen, Llama, Mistral-class, Gemma) served with vLLM, which supports structured outputs [3]; multilingual BERT-class encoders (e.g. XLM-R/German BERT) fine-tuned as classifiers; sentence-transformer embeddings with pgvector/Qdrant.
• Classic ML: gradient boosting or linear models on TF-IDF/character n-grams — often competitive for short bank texts and runs on CPU.
• Parsing: Docling (MIT licence [4]) for PDF statements if no structured feed exists.
• Hardware: HW1 (CPU/small server) is enough for classifier + embeddings; HW2 only if an LLM tail is self-hosted. Ops effort is low; the hard part is data preparation.

Path D — Custom training

Worth it for tax-adviser firms or banks with large volumes: fine-tune an encoder classifier on historical bookings (tens of thousands of labelled lines per chart). Needs cleaned, de-duplicated history with the final (corrected) account, not the original suggestion; split by time to measure drift. Per-client models are rarely needed; a shared model plus per-client retrieval is usually enough.

State of the art (2026)

• Layered hybrids win: rules/IBAN memory + retrieval over a client's own bookings + LLM fallback. Pure zero-shot LLM categorisation is convenient but inconsistent between runs and weaker than history-based approaches on client-specific accounts.
• Merchant enrichment has moved from regex to learned entity resolution with merchant databases (Ntropy, Tink, Bud) and returns category, recurrence and logo.
• Structured outputs and enum-constrained decoding remove invalid account numbers [3].
• Limits and failure modes: ambiguous payments (e.g. "Amazon" can be office supplies, assets or private use), mixed bookings (one payment, several invoices), private/business mixing for sole traders, tax-key mistakes (reverse charge, input tax deduction), concept drift when suppliers change names, and silent over-confidence. Public benchmarks for German Kontierung do not exist; evaluate on your own labelled history.

Shared resources & combinations

• Shared building blocks: text-classifier + embedding-text + vector-db (booking memory), llm-general/llm-small with structured outputs, workflow-automation, and the chart of accounts as a vocabulary. A CPU/HW1 box or a single HW2 GPU can serve all small-model use cases at once; the vector index of past bookings is reusable.
• Upstream: DOC-001 (invoices), DOC-002 (receipts), DOC-017 (bank statement parsing for lending) supply the documents and parsed statements.
• Downstream / combined: AGENT-006 (reconciliation and close: match transactions to open items), AGENT-002 (workflow platform), ANOM-006 (journal-entry anomaly detection on resulting bookings), ANOM-001/ANOM-002 (fraud/AML use the same enriched data but are separate, regulated use cases), PRED-016 (cash-flow forecast from categorised flows), PERS-001 (private budgeting), LANG-012 (generic text classification).

Effort, cost & KPIs

• Path A: hours to days; per-seat or per-document pricing inside bookkeeping tools; enrichment APIs usually priced per transaction.
• Path B: 1–2 months including export interface and review UI; LLM cost is small if rules/retrieval handle most lines and the LLM only the tail.
• Path C/D: 2–4 months; effort dominated by data cleaning and evaluation, not hardware.
• KPIs: share of lines accepted without change (acceptance rate) by counterparty class, account-level accuracy on a held-out time slice, review minutes per 100 lines, tax-key error rate found in audits/Betriebsprüfung, share of lines matched to a document, drift over time.

People & change

Involve management (budget, liability for bookkeeping), the head of finance as process owner, the bookkeepers as daily users, IT for bank interfaces, and the data owners of accounting data. If a tax adviser keeps the books, include them from the start; they stay responsible for the final booking. The data protection officer should check the setup because transactions contain personal data of customers, suppliers and employees (salaries, expense claims); an AVV (Art. 28 GDPR) is required with every vendor and a DPIA is rarely necessary but should be assessed (GUIDE-005).

Works council: usually no, as the tool classifies transactions and does not evaluate employee behaviour (§87(1) no. 6 BetrVG). If it logs which person accepts or changes suggestions and reports it, co-determination can arise, so inform the council early under §90(1) no. 3 and agree that logs are not used for performance control (GUIDE-004). Public bodies inform the staff council.

AI literacy: support bookkeepers with short training on how suggestions are produced, confidence thresholds and typical mistakes (GUIDE-006). Start with one bank account or one client, let humans approve every booking at first, and automate only high-confidence recurring items after a go/no-go (GUIDE-009). Typical concern: job loss; address it by shifting time to review and analysis (GUIDE-008).

Risks, regulation & compliance

• EU AI Act: pure bookkeeping categorisation is minimal risk (AI literacy, Art. 4). It becomes high-risk if the output is used to evaluate the creditworthiness of natural persons or establish their credit score (Annex III, point 5(b); AI for detecting financial fraud is excepted [5]) — e.g. enriched categories used as underwriting features for consumer credit. Keep the use case separate from scoring or classify the downstream system accordingly. Do not use categories to infer protected traits (e.g. health, religion from payees) — see GDPR.
• GDPR: transactions are personal data (names, IBANs, and sensitive inferences such as donations, medical payees, union fees = potentially special category data). Need a legal basis, data processing agreement, EU hosting, data minimisation and retention limits. Art. 22 limits decisions based solely on automated processing with significant effects [6]; bookkeeping suggestions reviewed by a person are not affected, fully automated decisions about individuals (credit, account termination) would be.
• PSD2: account access via licensed AIS providers with customer consent; do not scrape bank logins.
• Bookkeeping law: GoBD requires traceable, unalterable processing and procedural documentation (Verfahrensdokumentation); document that suggestions are automated, who approves, and keep the log of suggestion vs. final booking. The tax adviser/company remains responsible for correctness (VAT, input-tax deduction).
• Mitigations: thresholds per account class, four-eyes for tax-relevant keys, mandatory review for new counterparties, monitoring of drift, no auto-posting of private-person data without review.

Getting started

1. Export 12 months of bank lines with the final booked accounts; compute how many repeat counterparties exist (this predicts achievable automation).
2. Check what your existing tool (DATEV, Lexware, sevDesk, etc.) already suggests; measure acceptance on a 500-line sample before buying anything.
3. Build or test a layered prototype: IBAN memory + embedding retrieval + LLM fallback with account numbers as enum.
4. Define confidence thresholds, mandatory-review classes (tax keys, new counterparties) and the export to DATEV/ERP.
5. Log suggestion vs. final booking from day one; review KPIs monthly and retrain or update retrieval data.

Sources

1. Ntropy — transaction enrichment, categorisation, entities, recurrence (vendor homepage) — https://ntropy.com
2. DATEV — Unternehmen online (exchange of receipts and data between company and tax adviser) — https://www.datev.de/web/de/mydatev/datev-cloud-anwendungen/datev-unternehmen-online/
3. vLLM project — serving engine with structured outputs — https://github.com/vllm-project/vllm
4. Docling project (MIT licence) — https://github.com/docling-project/docling
5. EU AI Act, Annex III (high-risk systems), point 5(b) creditworthiness and fraud-detection exception — https://artificialintelligenceact.eu/annex/3/
6. GDPR Art. 22 — automated individual decision-making — https://www.gdpr-info.eu/art-22-gdpr/
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj