Anreicherung und Kategorisierung von Banktransaktionen & Buchungsvorschläge (Kontierung)

Kontoauszüge enthalten kryptische Texte wie „SEPA-LASTSCHRIFT AMZN MKTP DE*1A2B3 LUX“. Buchhalterinnen, Buchhalter und Steuerberatende entscheiden noch immer Zeile für Zeile, welches Sachkonto, welcher Steuerschlüssel und welche Kostenstelle gilt. Die KI normalisiert die Gegenpartei, klassifiziert die Transaktion und schlägt die Buchung vor, basierend darauf, wie dieselbe Gegenpartei zuvor gebucht wurde. Der Mensch bestätigt oder korrigiert; jede Korrektur verbessert den nächsten Vorschlag. Dieselbe Engine bedient Apps für private Finanzen und Analysen auf Bankseite.

Problem & Nutzen

• Heute: KMU-Inhaber und Steuerkanzleien exportieren Bankdaten, gleichen sie manuell mit Belegen ab und weisen Konten zu (Kontierung) in DATEV, Lexware, sevDesk und ähnlichen Werkzeugen. In der Praxis ist das repetitiv: Die meisten Zeilen wiederholen bereits gebuchte Gegenparteien (Miete, Telekommunikation, Kraftstoff, SaaS, Versicherungen).
• KI-Nutzen: Regel- und historienbasierte Vorschläge erledigen den repetitiven Hauptteil; ML/LLM deckt neue oder mehrdeutige Gegenparteien ab; Menschen bearbeiten Ausnahmen. Vorteile sind weniger Erfassungszeit und einheitlichere Konten. Die Abgrenzungsnotiz zu diesem Anwendungsfall (research/sweep_results.json) nennt DATEV, lexoffice/sevDesk, Ntropy, Tink und Bud als Belege; von Anbietern veröffentlichte Genauigkeits- oder Zeitersparnisangaben konnte ich in dieser Sitzung nicht unabhängig überprüfen, daher werden hier keine zitiert. Ntropy bewirbt auf seiner Startseite „human-like accuracy in milliseconds“ ohne veröffentlichte Kennzahlen [1] – behandeln Sie solche Aussagen als ungeprüft und messen Sie an Ihren eigenen Daten.
• Seite von Banken/Fintechs: Angereicherte, kategorisierte Transaktionsdaten speisen Apps für private Finanzen, Liquiditäts- prognosen und Tragfähigkeitsprüfungen (siehe Regulierung: Letztere können zum Hochrisiko werden).

Varianten

• KMU-Buchhaltung (Kontierung): Vorschlag von SKR03/SKR04-Konto, Steuerschlüssel und Kostenstelle; DATEV-Export. (Aufgenommene Variante des gestrichenen AGENT-034.)
• Massenbuchhaltung in der Steuerberatung: ein Modell bzw. Regelwerk je Mandant plus gemeinsame mandantenübergreifende Vorannahmen; Prüfwarteschlange nach Konfidenz sortiert.
• Zuordnung zu Belegen: Transaktion mit Rechnung/Quittung verknüpfen (siehe DOC-001, DOC-002, AGENT-006 Abstimmung).
• Anreicherungs-API für Banken / Fintech: Händlernormalisierung, Logos, Kategorien, Wiederkehr für Apps und Merkmale zur Risikobewertung.
• Private Finanzen: Budgetkategorien und Abonnement-Erkennung in Budget-Apps (PERS-001).
• Öffentliche Hand / Treasury im Unternehmen: Kategorisierung in Haushaltstitel oder Liquiditätskategorien für die Liquiditätsplanung (PRED-016).

So funktioniert es

1. Transaktions-Feed (PSD2-AIS-API | CAMT.053 / MT940 | CSV)
2. Bereinigung (Referenzrauschen entfernen, SEPA-Verwendungszweck normalisieren, IBAN/BIC und Währung erkennen)
3. Auflösung der Gegenpartei (exakter IBAN-Treffer
4. unscharfer Namensabgleich
5. Händlerdatenbank / LLM)
6. Klassifizierung (zuerst Regeln, dann ML-Klassifikator / Embeddings + nächstliegende frühere Buchungen, dann LLM für den Long Tail)
7. Buchungsvorschlag (Sachkonto, Steuerschlüssel, Kostenstelle; Belegzuordnung)
8. Konfidenz-Routing (Automatikübernahme oberhalb der Schwelle je Gegenpartei | Prüfwarteschlange darunter)
9. Export (DATEV/ERP/API) + Prüfprotokoll von Vorschlag und endgültiger Buchung

• Geschichtetes Design: Deterministische Regeln und ein IBAN-basiertes Gedächtnis lösen den großen Teil günstig; ein kleiner Textklassifikator oder Embedding-Retrieval über historische Buchungen behandelt Varianten; ein LLM mit abgerufenen Beispielen (Few-Shot aus den eigenen Buchungen des Mandanten) und dem Kontenrahmen als Randbedingung behandelt den Long Tail. Beschränken Sie die Ausgabe auf gültige Kontonummern aus dem Kontenrahmen (strukturierte Ausgaben / Enum), damit keine Konten erfunden werden.
• Mensch-in-der-Schleife (Human-in-the-Loop): Akzeptierte/korrigierte Buchungen werden zu Trainings- und Abrufdaten; neue Gegenparteien, Beträge über einer Schwelle, steuerrelevante Schlüssel und alles, was die Umsatzsteuer berührt, erfordern eine Prüfung. Die steuerliche Verantwortung bleibt bei der Buchhaltung.

Datenaufbereitung

Benötigte Daten: Bank- und Kartentransaktionen (CAMT, MT940, CSV oder PSD2-Bankschnittstellen), der Kontenrahmen (SKR03/04), die Buchungshistorie aus dem Buchhaltungssystem oder ERP, Lieferanten- und Kundenstammdaten, Kostenstellen sowie Belege oder Rechnungen im DMS oder Postfach. Typische Lücken sind kryptische Buchungstexte, uneinheitliche historische Buchungen, nicht mit Transaktionen verknüpfte Belege, Papierbelege, doppelte Lieferanten und falsche frühere Steuerschlüssel, die als Wahrheit gelernt würden.

Aufbereitungsschritte: - Buchungen und Transaktionen aus dem Buchhaltungssystem exportieren (PREP-005) und in einer Tabelle ordnen (PREP-011). - Labels aus früheren korrekten Buchungen gewinnen und zweifelhafte Zeiträume ausschließen (PREP-020). - Lieferantenstammdaten bereinigen und ein Kategorien- und Kontenschema festlegen (PREP-019). - Belege scannen und per OCR erfassen, um sie Transaktionen zuzuordnen (PREP-006, DOC-014). - Einen Testdatensatz geprüfter Buchungen erstellen (PREP-018), vor externen APIs pseudonymisieren (PREP-022).

Werkzeuge: Export der Buchhaltungssoftware, Paperless-ngx für Belege, ein einfaches Tabellenmodell oder Embeddings. Der Datenaufwand liegt bei etwa 25 bis 35 Prozent. Siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A, weil Buchhaltungs- und Bankingsoftware mit Bankanbindung und lernenden Buchungsvorschlägen (auch EU-gehostete DATEV-kompatible Produkte) ausgereift ist und der Prozess Standard ist.
• Unternehmen: Weg B, weil Finanzteams die Integration mit eigenem ERP, Kontenrahmen und Kostenstellen brauchen und das Volumen die API-Kosten günstiger macht als Lizenzen je Arbeitsplatz.
• Entwickler: Weg C, weil ein kleiner Klassifikator oder ein lokales LLM auf HW1 plus Embeddings genügt und die Finanzdaten im Haus bleiben.
• Privat: Weg A, weil Budget-Apps und die Kategorisierung in Banking-Apps keine Einrichtung brauchen; lokale Werkzeuge passen zu datenschutzbewussten Nutzern.

Weg A — Kaufen (Standardsoftware) (für die meisten KMU empfohlen)

• Buchhaltungssoftware mit Vorschlägen: DATEV Unternehmen online (Austausch von Belegen und Daten zwischen Unternehmen und Steuerberatung [2]), Lexware Office, sevDesk, Buchhaltungsbutler, Candis, Xero, QuickBooks – prüfen Sie, welche aus Ihrer eigenen Historie lernen und welche sauber in das DATEV Ihrer Steuerberatung exportieren.
• Anreicherungs-APIs für Fintechs/Banken: Ntropy (Transaktionsanreicherung, Kategorisierung, Entitätserkennung, Wiederkehr; SOC 2 Type 2 laut seiner Website [1]), Tink (Visa), finAPI (deutscher, BaFin-lizenzierter AIS-Anbieter), Bud, Plaid. EU/Deutschland: finAPI, Tink (Schweden), Funktionen von Neobanken im Stil von Kontist/Qonto.
• A wählen, wenn: Sie Standard-Kontenrahmen SKR und ein gängiges Buchhaltungswerkzeug nutzen; prüfen Sie EU-Hosting und den Auftragsverarbeitungsvertrag (AVV).

Weg B — Auf Cloud-KI-Diensten aufbauen

• Anbindung über einen PSD2-AIS-Aggregator (finAPI, Tink, GoCardless Bank Account Data) oder Dateiimport.
• Klassifizierung über ein LLM mit strukturierter Ausgabe (z. B. Claude, Gemini, GPT, Mistral – EU-Region/-Anbieter, wo personenbezogene Daten vorliegen), Few-Shot-Beispiele aus der Historie des Mandanten abgerufen (Embedding-Modell + Vektordatenbank), Kontenrahmen als Enum.
• Orchestrierung mit n8n/Power Automate; Export über DATEV-Schnittstellen oder die API des Buchhaltungswerkzeugs.
• B wählen, wenn: ein eigener Kontenrahmen, Logik für mehrere Gesellschaften oder ein eigenes Produkt nötig ist. Namen/IBANs von Privatpersonen vor dem Senden nach Möglichkeit pseudonymisieren.

Weg C — Selbst betreiben (Open Source)

• Modelle: kleine offene LLMs (Qwen, Llama, Mistral-Klasse, Gemma), betrieben mit vLLM, das strukturierte Ausgaben unterstützt [3]; mehrsprachige Encoder der BERT-Klasse (z. B. XLM-R/German BERT) als Klassifikatoren feingetunt; Sentence-Transformer-Embeddings mit pgvector/Qdrant.
• Klassisches ML: Gradient Boosting oder lineare Modelle auf TF-IDF/Zeichen-n-Grammen – für kurze Banktexte oft konkurrenzfähig und auf CPU lauffähig.
• Parsing: Docling (MIT-Lizenz [4]) für PDF-Kontoauszüge, falls kein strukturierter Feed existiert.
• Hardware: HW1 (CPU/kleiner Server) genügt für Klassifikator + Embeddings; HW2 nur, wenn ein LLM für den Long Tail selbst betrieben wird. Der Betriebsaufwand ist gering; das Schwierige ist die Datenaufbereitung.

Weg D — Eigenes Training

Lohnt sich für Steuerkanzleien oder Banken mit großen Volumina: einen Encoder-Klassifikator auf historischen Buchungen feintunen (zehntausende gelabelte Zeilen je Kontenrahmen). Erfordert bereinigte, deduplizierte Historie mit dem endgültigen (korrigierten) Konto, nicht dem ursprünglichen Vorschlag; zeitlich aufteilen, um Drift zu messen. Modelle je Mandant sind selten nötig; ein gemeinsames Modell plus Retrieval je Mandant genügt meist.

Stand der Technik (2026)

• Geschichtete Hybride gewinnen: Regeln/IBAN-Gedächtnis + Retrieval über die eigenen Buchungen eines Mandanten + LLM als Rückfall. Reine Zero-Shot-LLM-Kategorisierung ist bequem, aber zwischen Durchläufen uneinheitlich und bei mandantenspezifischen Konten schwächer als historienbasierte Ansätze.
• Händleranreicherung hat sich von regulären Ausdrücken zu gelernter Entitätsauflösung mit Händlerdatenbanken (Ntropy, Tink, Bud) entwickelt und liefert Kategorie, Wiederkehr und Logo.
• Strukturierte Ausgaben und Enum-beschränktes Decoding beseitigen ungültige Kontonummern [3].
• Grenzen und Fehlerbilder: mehrdeutige Zahlungen (z. B. „Amazon“ kann Bürobedarf, Anlagegut oder Privatnutzung sein), Sammelbuchungen (eine Zahlung, mehrere Rechnungen), Vermischung von Privatem und Geschäftlichem bei Einzelunternehmern, Steuerschlüsselfehler (Reverse Charge, Vorsteuerabzug), Konzeptdrift bei Namensänderungen von Lieferanten und stille Überzuversicht. Öffentliche Benchmarks für die deutsche Kontierung gibt es nicht; bewerten Sie an Ihrer eigenen gelabelten Historie.

Gemeinsame Bausteine & Kombinationen

• Gemeinsame Bausteine: text-classifier + embedding-text + vector-db (Buchungsgedächtnis), llm-general/llm-small mit strukturierten Ausgaben, workflow-automation und der Kontenrahmen als Vokabular. Ein CPU-/HW1-Rechner oder eine einzelne HW2-GPU kann alle Anwendungsfälle mit kleinen Modellen gleichzeitig bedienen; der Vektorindex vergangener Buchungen ist wiederverwendbar.
• Vorgelagert: DOC-001 (Rechnungen), DOC-002 (Quittungen), DOC-017 (Auswertung von Kontoauszügen für die Kreditvergabe) liefern die Dokumente und ausgewerteten Auszüge.
• Nachgelagert / kombiniert: AGENT-006 (Abstimmung und Abschluss: Transaktionen offenen Posten zuordnen), AGENT-002 (Workflow-Plattform), ANOM-006 (Anomalieerkennung bei Buchungssätzen auf den entstandenen Buchungen), ANOM-001/ANOM-002 (Betrug/Geldwäsche nutzen dieselben angereicherten Daten, sind aber getrennte, regulierte Anwendungsfälle), PRED-016 (Liquiditätsprognose aus kategorisierten Zahlungsströmen), PERS-001 (private Budgetplanung), LANG-012 (allgemeine Textklassifizierung).

Aufwand, Kosten & Kennzahlen

• Weg A: Stunden bis Tage; Preise je Arbeitsplatz oder je Beleg innerhalb von Buchhaltungswerkzeugen; Anreicherungs-APIs meist je Transaktion bepreist.
• Weg B: 1–2 Monate einschließlich Exportschnittstelle und Prüfoberfläche; die LLM-Kosten sind gering, wenn Regeln/Retrieval die meisten Zeilen erledigen und das LLM nur den Long Tail.
• Weg C/D: 2–4 Monate; der Aufwand wird von Datenbereinigung und Bewertung bestimmt, nicht von Hardware.
• Kennzahlen: Anteil der ohne Änderung akzeptierten Zeilen (Akzeptanzrate) je Gegenparteiklasse, Genauigkeit auf Kontoebene an einem zurückgehaltenen Zeitabschnitt, Prüfminuten je 100 Zeilen, in Prüfungen/Betriebsprüfung gefundene Steuerschlüssel-Fehlerquote, Anteil der einem Beleg zugeordneten Zeilen, Drift im Zeitverlauf.

Menschen & Veränderung

Beziehen Sie die Geschäftsleitung (Budget, Haftung für die Buchführung), die Leitung Finanzen als Prozessverantwortliche, die Buchhaltenden als tägliche Nutzer, die IT für Bankschnittstellen und die Datenverantwortlichen der Buchhaltungsdaten ein. Führt eine Steuerberatung die Bücher, beziehen Sie sie von Anfang an ein; sie bleibt für die endgültige Buchung verantwortlich. Die oder der Datenschutzbeauftragte sollte den Aufbau prüfen, weil Transaktionen personenbezogene Daten von Kunden, Lieferanten und Beschäftigten enthalten (Gehälter, Spesenabrechnungen); mit jedem Anbieter ist ein AVV (Art. 28 DSGVO) erforderlich, und eine Datenschutz-Folgenabschätzung (DSFA) ist selten nötig, sollte aber geprüft werden (GUIDE-005).

Betriebsrat: meist nein, da das Werkzeug Transaktionen klassifiziert und kein Verhalten von Beschäftigten bewertet (§87 Abs. 1 Nr. 6 BetrVG). Protokolliert es, welche Person Vorschläge annimmt oder ändert, und wertet dies aus, kann Mitbestimmung entstehen; informieren Sie den Betriebsrat daher früh nach §90 Abs. 1 Nr. 3 und vereinbaren Sie, dass Protokolle nicht zur Leistungskontrolle genutzt werden (GUIDE-004). Öffentliche Stellen informieren den Personalrat.

KI-Kompetenz: Unterstützen Sie die Buchhaltenden mit einer kurzen Schulung dazu, wie Vorschläge entstehen, zu Konfidenzschwellen und typischen Fehlern (GUIDE-006). Beginnen Sie mit einem Bankkonto oder einem Mandanten, lassen Sie zunächst Menschen jede Buchung freigeben und automatisieren Sie erst nach einer Go/No-Go-Entscheidung nur wiederkehrende Positionen mit hoher Konfidenz (GUIDE-009). Typische Sorge: Arbeitsplatzverlust; begegnen Sie ihr, indem Sie Zeit auf Prüfung und Analyse verlagern (GUIDE-008).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): reine Buchhaltungskategorisierung ist minimales Risiko (KI-Kompetenz, Art. 4). Sie wird hochriskant, wenn die Ausgabe zur Bewertung der Kreditwürdigkeit natürlicher Personen oder zur Ermittlung ihres Kredit-Scores genutzt wird (Anhang III Nr. 5 Buchst. b; KI zur Aufdeckung von Finanzbetrug ist ausgenommen [5]) – etwa angereicherte Kategorien als Merkmale zur Risikobewertung bei Verbraucherkrediten. Halten Sie den Anwendungsfall vom Scoring getrennt oder stufen Sie das nachgelagerte System entsprechend ein. Nutzen Sie Kategorien nicht, um geschützte Merkmale abzuleiten (z. B. Gesundheit, Religion aus Zahlungsempfängern) – siehe DSGVO.
• DSGVO: Transaktionen sind personenbezogene Daten (Namen, IBANs und sensible Rückschlüsse wie Spenden, medizinische Zahlungsempfänger, Gewerkschaftsbeiträge = potenziell besondere Datenkategorien). Erforderlich sind eine Rechtsgrundlage, ein Auftragsverarbeitungsvertrag (AVV), EU-Hosting, Datenminimierung und Aufbewahrungsfristen. Art. 22 begrenzt Entscheidungen, die ausschließlich auf automatisierter Verarbeitung beruhen und erhebliche Wirkung haben [6]; von einer Person geprüfte Buchungsvorschläge sind nicht betroffen, vollständig automatisierte Entscheidungen über Einzelpersonen (Kredit, Kontokündigung) wären es.
• PSD2: Kontozugriff über lizenzierte AIS-Anbieter mit Einwilligung der Kundschaft; kein Scraping von Bank-Logins.
• Buchführungsrecht: Die GoBD verlangen nachvollziehbare, unveränderbare Verarbeitung und eine Verfahrensdokumentation; dokumentieren Sie, dass Vorschläge automatisiert erfolgen und wer sie freigibt, und bewahren Sie das Protokoll von Vorschlag und endgültiger Buchung auf. Die Steuerberatung bzw. das Unternehmen bleibt für die Richtigkeit verantwortlich (Umsatzsteuer, Vorsteuerabzug).
• Gegenmaßnahmen: Schwellen je Kontoklasse, Vier-Augen-Prinzip bei steuerrelevanten Schlüsseln, verpflichtende Prüfung neuer Gegenparteien, Drift-Überwachung, keine automatische Buchung von Daten von Privatpersonen ohne Prüfung.

Erste Schritte

1. 12 Monate Bankzeilen mit den endgültig gebuchten Konten exportieren; berechnen, wie viele wiederkehrende Gegenparteien es gibt (das sagt die erreichbare Automatisierung voraus).
2. Prüfen, was Ihr vorhandenes Werkzeug (DATEV, Lexware, sevDesk usw.) bereits vorschlägt; vor einem Kauf die Akzeptanz an einer Stichprobe von 500 Zeilen messen.
3. Einen geschichteten Prototyp bauen oder testen: IBAN-Gedächtnis + Embedding-Retrieval + LLM-Rückfall mit Kontonummern als Enum.
4. Konfidenzschwellen, Klassen mit Prüfpflicht (Steuerschlüssel, neue Gegenparteien) und den Export zu DATEV/ERP festlegen.
5. Vorschlag und endgültige Buchung vom ersten Tag an protokollieren; Kennzahlen monatlich prüfen und Retrieval-Daten nachtrainieren oder aktualisieren.

Quellen

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