Analyse von Kontoauszügen und Gehaltsabrechnungen für die Kreditvergabe

Kreditunterlagen treffen noch immer als Stapel aus PDFs, Scans und Handyfotos ein: drei Monate Kontoauszüge, Gehaltsabrechnungen, ein Steuerbescheid. Dokumenten-KI macht daraus strukturierte, geprüfte Daten — Transaktionen, Salden, Gehaltseingänge, feste Verpflichtungen —, sodass die Kreditentscheidung in Minuten vorbereitet ist, statt von Hand abgetippt zu werden. Das Auslesen selbst ist risikoarm; sobald das Ergebnis aber in eine Bonitätsentscheidung über eine natürliche Person einfließt, greifen die EU-Regeln für Hochrisiko-KI, das Verbraucherkreditrecht und Art. 22 DSGVO.

Problem & Nutzen

• Heute: Vermittler, Banken, Leasinggesellschaften und Fintechs sammeln Einkommens- und Kontounterlagen; anschließend tippen Sachbearbeiter die Transaktionen in Tabellen ab, ordnen Gehalt, Miete und Kreditraten Kategorien zu und vergleichen die Gehaltsabrechnung mit dem Gehaltseingang. Das ist langsam, fehleranfällig und ein typischer Engpass bei Verbraucher-, Immobilien- und KMU-Krediten.
• KI-Nutzen: vorlagenfreies Auslesen beliebiger Bank-Layouts, automatischer Abgleich (Anfangssaldo + Transaktionen = Endsaldo), Erkennung wiederkehrender Einnahmen und Verpflichtungen sowie erste Konsistenzprüfungen. Mitarbeitende bearbeiten Ausnahmen und treffen Entscheidungen.
• Alternativer Datenweg: In der EU liefern PSD2-Kontoinformationsdienste (AIS) Transaktionen mit Einwilligung des Kunden direkt von der Bank, z. B. über finAPI (Deutschland; von der BaFin registrierter AISP, bietet Kategorisierung und Cashflow-/Risikoberichte) [5]. PDFs bleiben nötig, wenn der Kunde keinen Online-Zugang hat, bei ausländischen oder kleinen Instituten, für Gehaltsabrechnungen und als Rückfallebene.
• Allgemeine, unabhängig geprüfte Genauigkeits- oder Zeitersparnis-Zahlen werden hier nicht genannt; Herstellerangaben sollten an den eigenen Dokumenten getestet werden (siehe Erste Schritte).

Varianten

• Verbraucherkredit / BNPL / Autofinanzierung: 3 Monate Kontoauszüge plus Gehaltsabrechnungen; hohes Volumen, schnelle Entscheidung.
• Baufinanzierung und Immobilienfinanzierung: längere Historien, Selbstständigkeit (Steuerbescheid, BWA) → Überschneidung mit DOC-012; Vermittlerplattformen bündeln die Unterlagen.
• KMU und Leasing: Geschäftskontoauszüge, Cashflow-Analyse und Saisonalität; speist die Erstellung der Kreditvorlage (AGENT-028).
• Mieter- und Vermieterprüfung: Einkommensnachweis bei Mietbewerbungen (Datenminimierung ist hier entscheidend).
• Versicherer / Kreditversicherer, Marktplätze, Anbieter von Gehaltsvorschüssen: gleiche Extraktion, andere Entscheidungslogik.
• Öffentlicher Sektor: Leistungs- und Förderanträge, die einen Einkommensnachweis erfordern → DOC-003.

So funktioniert es

1. Eingang (Portal-Upload / E-Mail / Vermittlerplattform / PSD2 AIS)
2. Klassifizierung der Dokumentart (Kontoauszug | Gehaltsabrechnung | Steuerbescheid | sonstiges) [Muster DOC-008]
3. Echtheits-Vorprüfung (PDF-Metadaten, Schriftarten, Ersteller, Bearbeitungsspuren) [-> ANOM-017]
4. OCR + Layout-Analyse, Tabellenrekonstruktion über mehrere Seiten
5. Feldextraktion gegen ein Schema (VLM / Dokumentenmodell)
6. Validierung (Saldenkette, Datumsfolge, IBAN-Prüfsumme, Arithmetik brutto-netto-Abzüge)
7. Kategorisierung der Transaktionen (Gehalt, Miete, Kredit, Versicherung, Glücksspiel, Umbuchungen zwischen eigenen Konten)
8. Einkommensprüfung (Netto laut Gehaltsabrechnung vs. Gehaltseingang; kumuliert vs. Monate)
9. Zusammenfassung + Hinweise
10. Prüfung durch den Kreditsachbearbeiter (Quelle markiert)
11. Entscheidungslogik (Richtlinienregeln / Scorecard, separates System)
12. Entscheidung mit menschlicher Aufsicht

• Extraktion: Ein Dokumenten-Parsing-Modell oder VLM liefert JSON gegen ein festes Schema; deterministischer Code prüft die Arithmetik. Mehrseitige Tabellen, laufende Salden und umgebrochene Zeilen sind der schwierige Teil.
• Kategorisierung: Textklassifikator oder LLM mit Regeln für Gegenpartei und Verwendungszweck (siehe LANG-033 für die gemeinsame Komponente zur Transaktionskategorisierung).
• Mensch-in-der-Schleife (Human-in-the-Loop): Felder mit niedriger Konfidenz, Brüche in der Saldenkette und Manipulationshinweise gehen zur Prüfung; die Entscheidung über einen Kreditantrag bleibt bei einer geschulten Person oder einem dokumentierten, anfechtbaren Entscheidungsprozess.

Datenaufbereitung

Die Eingaben sind Kontoauszüge und Gehaltsabrechnungen, die als PDFs, Scans oder Handyfotos per E-Mail, Kundenportal oder Vermittlerplattform eintreffen und im DMS, im Kreditvergabesystem oder auf Dateiablagen landen. Wo PSD2-Kontodaten verfügbar sind, entfällt die OCR ganz. Typische Lücken sind schief fotografierte Dokumente, Layouts vieler Banken, passwortgeschützte PDFs, fehlende Seiten, Duplikate desselben Kontoauszugs und Antragsdaten, die nicht mit den Dokumenten verknüpft sind. Historische Daten werden kaum benötigt, weil moderne Dokumentenmodelle ohne Training funktionieren.

Aufbereitungsschritte: - Einen sauberen Eingang festlegen: ein Upload-Kanal, Dokumentart und Antragsteller-ID als Pflichtangaben, unleserliche Dateien schon am Eingang zurückweisen. - 50-100 reale, repräsentative Dokumente (mit Einwilligung oder pseudonymisiert, siehe PREP-022) mit den korrekten Werten als Testdatensatz sammeln, siehe PREP-018. - Parameter der Kreditrichtlinie (Einkommensvielfache, Verpflichtungen) aus dem Kreditsystem exportieren, siehe PREP-005. - Aufbewahrung und Zugriffsrechte für gespeicherte Kontoauszüge festlegen, siehe PREP-025.

Grober Aufwandsanteil: etwa 15-20 Prozent, vor allem Eingang und Testdatensatz. Werkzeuge: die eigene Vorverarbeitung des Herstellers oder Docling/Tesseract für selbst gebaute Pipelines. Siehe auch DOC-018 und GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU (Vermittler, kleine Kreditgeber): Weg A, weil ausgereifte, in der EU hostbare OCR-Produkte für Kontoauszüge und Gehaltsabrechnungen zu KMU-tauglichen Preisen existieren und der Prozess standardisiert ist.
• Großunternehmen (Banken, Versicherer): Weg B, weil die Extraktion in das eigene Kreditvergabesystem und die Kreditpolitik eingebunden werden muss und die Volumina eine maßgeschneiderte Pipeline rechtfertigen.
• Entwickler: Weg B, weil Dokumenten-KI-Schnittstellen plus ein LLM-Validierungsschritt der schnellste Weg sind, den Dienst zu bauen und einzubetten.

Weg A — Kaufen (Standardsoftware)

• Anbieter für Dokumenten-KI / OCR: Mindee (Paris; OCR-Schnittstellen für Kontoauszüge und Gehaltsabrechnungen, Hosting in EU oder USA wählbar) [4], Doxis AI Solutions (früher Klippa; Niederlande; Anwendungsfälle Einkommensnachweis, Abgleich von Kontoauszügen und Bearbeitung von Baufinanzierungen) [3], dazu ABBYY Vantage, Rossum, Hypatos (München) sowie DMS/ECM-Suiten wie DocuWare oder d.velop. Prüfen: deutsche/europäische Kontoauszugs-Layouts, Genauigkeit auf Zeilenebene (Transaktionen), EU-Hosting, Aufbewahrungseinstellungen, Betrugs- und Manipulationsprüfungen.
• Open Banking und Datenintelligenz (EU): finAPI (Deutschland) [5]; auch andere PSD2-Aggregatoren wie Tink oder GoCardless Bank Account Data werden genutzt — vor Vertragsabschluss Lizenzstatus und aktuelles Angebot prüfen.
• Kreditplattformen: Kreditvergabesysteme und Vermittlerplattformen binden die Kontoauszugsanalyse zunehmend ein; fragen Sie, welches Modell und welche Unterauftragsverarbeiter genutzt werden.
• Weg A wählen, wenn: die Volumina moderat sind, Sie keine Modell-Pipeline betreiben wollen und der Anbieter vertraglich als Auftragsverarbeiter gebunden ist (Art. 28 DSGVO).

Weg B — Auf Cloud-KI-Diensten aufbauen

• Spezialisierte Dokumentenmodelle: Azure AI Document Intelligence bietet vorgefertigte Modelle für Kontoauszüge und Gehaltsabrechnungen (prebuilt-bankStatement.us, prebuilt-payStub.us), die Dokumentation nennt jedoch nur das Gebietsschema en-us; deutsche oder andere EU-Layouts werden also nicht von Haus aus abgedeckt [1][2]. Für EU-Dokumente nutzen Sie die Layout-/Read-Modelle plus ein eigenes Extraktionsmodell oder einen LLM-Schritt. AWS Textract hat mit Analyze Lending eine Funktion für Kreditunterlagen (Klassifizierung und Extraktion von Einkommens- und Bankdokumenten), die auf US-Dokumenttypen ausgerichtet ist; prüfen Sie Regionsverfügbarkeit und EU-Tauglichkeit, bevor Sie sich darauf verlassen.
• Allgemeine VLM-Extraktion: Seitenbilder und ein JSON-Schema an ein multimodales Modell (Claude, Gemini, GPT, Mistral) senden, mit strukturierten Ausgaben und Datenhaltung in der EU; alle Summen im Code neu berechnen.
• Orchestrierung: n8n / Power Automate / eigener Dienst; Warteschlange und Prüfoberfläche; Audit-Protokoll mit ausgelesenen vs. korrigierten Werten.
• Weg B wählen, wenn: Sie eigene Schemata brauchen (z. B. bestimmte Richtlinienkennzahlen) und keine harte On-Premises-Vorgabe besteht.

Weg C — Selbst betreiben (Open Source)

• Parsing: Docling (MIT) mit Granite-Docling (258 Mio. Parameter, Apache 2.0) für Layout, Tabellen und OCR [6][7]; Alternativen PaddleOCR-VL, MinerU, olmOCR.
• Extraktion: Qwen3-VL (Apache 2.0; dichte Varianten von 2B bis 32B sowie MoE-Varianten 30B-A3B / 235B-A22B, OCR in 32 Sprachen), betrieben über vLLM, mit eingeschränkter JSON-Ausgabe [8].
• Workflow: n8n oder Camunda; Protokollierung mit Schutz personenbezogener Daten; verschlüsselte Speicherung mit Löschjobs.
• Hardware: HW2 (eine GPU mit 24–32 GB) für ein quantisiertes VLM der Klasse 8B–32B; HW3 für höheren Durchsatz. Typisch, wenn eine Bank oder ein Kreditgeber Kontoauszüge nicht an Dritte senden darf.

Weg D — Eigenes Training

Lohnt sich nur bei hohem Volumen mit wiederkehrenden ungewöhnlichen Layouts (kleine Regionalbanken, ausländische Kontoauszüge, schlechte Scans). Ein kleines VLM oder Layout-Modell mit einigen Hundert bis einigen Tausend annotierten Seiten pro Layout-Familie feintunen; Korrekturen der Prüfer sind die Trainingsdaten. Trainieren Sie nie mit Echtdaten von Antragstellern ohne klare Rechtsgrundlage und Löschregel.

Stand der Technik (2026)

• Vorlagenfreies VLM-Parsing ist der Standard; Kopfdaten und saubere Tabellen sind weitgehend gelöst, während lange mehrseitige Transaktionstabellen, verbundene/umgebrochene Zeilen, fotografierte Kontoauszüge, Screenshots im Dunkelmodus und gemischte Sprachen weiterhin stille Fehler erzeugen. Deterministische Prüfungen (Saldenkette, Summen) sind das wirksamste Sicherheitsnetz.
• Open Banking schlägt OCR, wo verfügbar, weil die Daten strukturiert und von der Bank signiert sind; die PDF-Analyse ist die Ergänzung. Der EU-Vorschlag zum Zugang zu Finanzdaten (Financial Data Access, FiDA) würde den Datenaustausch über Zahlungskonten hinaus ausweiten; seine endgültige Form und der Zeitplan sind zu prüfen.
• Dokumentenfälschung ist das Hauptproblem durch Angreifer: Bearbeitete PDFs und KI-generierte Kontoauszüge sind ein bekanntes Problem für Kreditgeber; Echtheitsprüfungen (Metadaten, Schriftkonsistenz, Abgleich mit PSD2-Daten oder Gehaltsabrechnung) gehören in die Pipeline (ANOM-017).
• Grenzen: Das Extraktionsmodell ist kein Kreditmodell; die Kategorisierung mehrdeutiger Überweisungen (Umbuchungen zwischen eigenen Konten, private Darlehen von Familienmitgliedern) ist fehleranfällig; Modelle können für unleserliche Zellen plausible Werte erfinden — verlangen Sie „unleserlich" als zulässige Ausgabe.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (ocr-docparse + vlm + llm-general): DOC-001 Rechnungen, DOC-003 Formulare, DOC-004 Ausweisdokumente, DOC-012 Jahresabschlüsse — ein selbst betriebener VLM-Server (HW2/HW3) bedient sie alle.
• Vor- und nachgelagert: DOC-004 und AGENT-015 (Onboarding & KYC), ANOM-017 (Dokumentenmanipulation), ANOM-037 (Plausibilität von Gehaltsdaten), PRED-009 (Scorecard / Ausfallprognose), AGENT-028 (Agent für Kreditvorlagen), LANG-033 (Transaktionskategorisierung).
• Datenschutz-Werkzeuge: DOC-018 zum Schwärzen von Daten, die für die Entscheidung nicht benötigt werden (z. B. Namen Dritter, gesundheitsbezogene Überweisungen), vor Speicherung oder Weitergabe.
• Gemeinsame Bausteine: Dokumentklassifizierung, schemagebundene Extraktion, Prüfoberfläche mit Quellenmarkierung, Audit-Protokoll, datenschutzgerechte Speicherung.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen; Preis pro Dokument oder pro Antrag.
• Weg B: 1–3 Monate inkl. Prüfoberfläche, Integration in das Kreditsystem und Tests mit echten Dokumenten.
• Weg C: 2–5 Monate; GPU-Server, Sicherheitshärtung und laufende Evaluierung.
• Kennzahlen: Genauigkeit auf Feld- und Transaktionsebene, Anteil der Akten ohne manuelle Korrektur, Bestehensquote der Saldenkettenprüfung, Zeit von der vollständigen Akte bis zur entscheidungsreifen Zusammenfassung, erkannte Fälschungen, Übersteuerungsquote durch Kreditsachbearbeiter, Beschwerden/Anfechtungen, Bias-Überwachung der nachgelagerten Entscheidungen.

Menschen & Veränderung

Beziehen Sie zuerst die Geschäftsleitung (Budget, Risikobereitschaft) und die Abteilungsleitung Kreditbearbeitung ein, dann die IT (Integration, Konten), den/die Datenschutzbeauftragte(n) und Legal/Compliance vor jedem Pilotbetrieb, denn Kontoauszüge und Gehaltsabrechnungen sind personenbezogene Finanzdaten: Eine Datenschutz-Folgenabschätzung (DSFA) ist wahrscheinlich, und mit jedem Anbieter ist ein Auftragsverarbeitungsvertrag (AVV, Art. 28 DSGVO) nötig. Kreditsachbearbeiter und Vermittler sind die Endanwender und sollten die Prüfmaske von Anfang an mitgestalten.

Betriebsrat: abhängig vom Einzelfall. Das System richtet sich an Antragsunterlagen, nicht an Beschäftigte; protokolliert es jedoch, welche Sachbearbeiterin oder welcher Sachbearbeiter was korrigiert oder freigibt, ist es objektiv zur Leistungsüberwachung geeignet, und § 87 Abs. 1 Nr. 6 BetrVG greift (BAG); § 90 Abs. 1 Nr. 3 verlangt zusätzlich die rechtzeitige Unterrichtung über KI in Arbeitsabläufen. Eine kurze Betriebsvereinbarung regelt dies frühzeitig.

Fördern Sie die KI-Kompetenz (Art. 4 KI-Verordnung) mit einer kurzen Schulung zum Lesen von Konfidenzwerten und zu typischen OCR-Fehlern. Kommunizieren Sie, dass das Werkzeug Zahlen aufbereitet, die Entscheidung aber der Kreditsachbearbeiter trifft; führen Sie einen Pilotbetrieb mit einem Team und 2-3 Wochen Parallelarbeit durch. Typische Sorgen sind Arbeitsplatzverlust und Schuldzuweisung bei KI-Fehlern: Begegnen Sie beiden, indem Sie den menschlichen Freigabeschritt beibehalten und die gesparte Zeit für mehr Beratung messen. Datenschutz: Informieren Sie Antragsteller über die Verarbeitung. Leitfäden: GUIDE-005, GUIDE-004, GUIDE-008.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Das bloße Auslesen (ein PDF lesen) ist selbst nicht aufgeführt. Anhang III Nr. 5 Buchst. b stuft KI-Systeme, die zur Bewertung der Kreditwürdigkeit natürlicher Personen oder zur Erstellung ihres Kredit-Scorings verwendet werden, als Hochrisiko ein, mit einer Ausnahme für die Aufdeckung von Finanzbetrug [9][10]. Eine Pipeline, deren Einkommens-/Kapitaldienst-Ergebnis in die Kreditbewertung eines Verbrauchers einfließt, fällt daher wahrscheinlich in den Anwendungsbereich; ein rein verwaltungstechnisches OCR-Werkzeug für Firmenkunden oder eine interne Betrugsprüfung möglicherweise nicht. Ordnen Sie je Einsatz ein (daher depends). Pflichten für Hochrisiko-Systeme: Risikomanagement, Daten-Governance, Protokollierung, menschliche Aufsicht, Genauigkeit und Dokumentation; die Pflichten nach Anhang III gelten ab dem 2. Dez. 2027 (Digital Omnibus on AI, Verordnung (EU) 2026/1744).
• Verbraucherkreditrichtlinie (EU) 2023/2225: Kreditwürdigkeitsprüfungen müssen auf relevanten und zutreffenden Informationen beruhen; Verbraucher haben Rechte bei automatisierter Verarbeitung (menschliches Eingreifen, Erläuterung, Anfechtung). Die nationalen Regeln der Mitgliedstaaten gelten ab November 2026 — mit der nationalen Umsetzung abgleichen [11].
• DSGVO: Kontoauszüge offenbaren hochsensible Details (Gesundheit, Religion, Gewerkschaftsbeiträge, politische Haltung über Überweisungen). Datenminimierung, Zweckbindung, DSFA, Auftragsverarbeitungsverträge, Hosting in der EU. Art. 22 beschränkt ausschließlich automatisierte Entscheidungen; das SCHUFA-Urteil des EuGH (C-634/21) behandelt einen Score, der die Entscheidung eines Kreditgebers maßgeblich prägt, selbst als automatisierte Entscheidung. Nutzen Sie keine Rückschlüsse auf besondere Kategorien personenbezogener Daten.
• Bankenaufsicht: Die EBA-Leitlinien zur Kreditvergabe und Überwachung verlangen eine solide, dokumentierte Kreditwürdigkeitsprüfung und Datenverifizierung [12]; DORA für IKT-Drittparteirisiken bei Finanzunternehmen; in Deutschland die BaFin-MaRisk.
• PSD2: Zugriff über zugelassene AISPs mit ausdrücklicher Einwilligung; kein Screen Scraping mit Zugangsdaten des Kunden.
• Gegenmaßnahmen: deterministische Prüfungen, menschliche Prüfung von Ablehnungen, dokumentierte Entscheidungsregeln, Bias-Tests, Löschung nach Ablauf der Aufbewahrungsfrist, Audit-Protokoll von KI-Ausgabe vs. endgültiger Entscheidung.

Erste Schritte

1. 100–200 reale (mit Einwilligung oder anonymisierte) Kontoauszüge und Gehaltsabrechnungen Ihrer zehn wichtigsten Banken und Arbeitgeber sammeln, einschließlich schlechter Scans, und das Zielschema sowie die Referenzwerte (Ground Truth) festlegen.
2. Entscheiden, ob PSD2-Kontodaten einen Teil der PDFs ersetzen können; falls ja, diese zuerst integrieren.
3. 2–3 Anbieter für Weg A und einen VLM-Ansatz anhand dieses Datensatzes vergleichen; Genauigkeit auf Transaktionsebene und Bestehensquote der Saldenkette messen.
4. Das System nach KI-Verordnung Anhang III Nr. 5 Buchst. b und DSGVO (DSFA) einordnen; menschliche Aufsicht und Anfechtungsverfahren festlegen.
5. Pilotbetrieb mit Prüfmaske, Korrekturen protokollieren, dann den Umfang erweitern und Echtheitsprüfungen ergänzen.

Quellen

1. Microsoft Learn — Document Intelligence bank statement model (en-us only) — https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/bank-statement
2. Microsoft Learn — Document Intelligence payStub model — https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/pay-stub
3. Doxis AI Solutions (formerly Klippa) — https://www.klippa.com/en/
4. Mindee — bank statement and payslip OCR — https://www.mindee.com/
5. finAPI — open finance APIs (Germany) — https://www.finapi.io/en/
6. Docling project — https://github.com/docling-project/docling
7. IBM — Granite-Docling announcement — https://www.ibm.com/new/announcements/granite-docling-end-to-end-document-conversion
8. QwenLM — Qwen3-VL — https://github.com/QwenLM/Qwen3-VL
9. AI Act Annex III (point 5(b), creditworthiness) — https://artificialintelligenceact.eu/annex/3/
10. AI Act Recital 58 — https://artificialintelligenceact.eu/recital/58/
11. Directive (EU) 2023/2225 on credit agreements for consumers — https://eur-lex.europa.eu/eli/dir/2023/2225/oj
12. EBA — Guidelines on loan origination and monitoring — https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/credit-risk/guidelines-loan-origination-and-monitoring