Erkennung von Spesen- und Beschaffungsbetrug

Unternehmen verlieren Geld durch überhöhte oder erfundene Spesenabrechnungen, doppelte und gesplittete Rechnungen, Scheinlieferanten und Absprachen zwischen Einkäufern und Lieferanten, prüfen aber meist nur eine kleine Stichprobe. KI prüft jede Abrechnung und jede Rechnung, liest den Beleg selbst, vergleicht ihn mit Richtlinie, Historie und Vergleichsgruppen und gibt nur die wenigen auffälligen Fälle an einen Menschen weiter. Dieselben Werkzeuge finden auch ehrliche Fehler und schleichende Abweichungen von der Richtlinie, die oft den größeren Teil der Einsparungen ausmachen.

Problem & Nutzen

• Heute: Spesenabrechnungen prüfen Vorgesetzte, die sie in Sekunden freigeben, und die Finanzabteilung prüft eine zufällige Stichprobe. Die Beschaffungskontrolle stützt sich auf Freigabegrenzen und den Drei-Wege-Abgleich. Doppelzahlungen, Bestellungen, die knapp unter Freigabeschwellen aufgeteilt werden, private Ausgaben auf Firmenkarten und Lieferantenbetrug fallen spät oder durch Hinweise auf.
• Warum es wichtig ist: Die Studie der ACFE zu Wirtschaftsstraftaten im Unternehmen (2.402 Fälle, 143 Länder, Befragung Juli bis September 2025) bringt proaktive Datenüberwachung und -analyse mit geringeren Schäden und schnellerer Entdeckung in Verbindung. Sie nennt „ungewöhnlich enge Beziehungen zu einem Lieferanten oder Kunden“ als Warnsignal, das mit einem mittleren Schaden von 300.000 USD verbunden ist [1]. Hinweise bleiben ein wichtiger Entdeckungsweg; Analysen ergänzen deshalb einen Hinweisgeberkanal (EU-Richtlinie 2019/1937), ersetzen ihn aber nicht.
• KI-Nutzen: 100 % Abdeckung statt Stichprobe, Prüfungen auf Beleg-Ebene (Händler, Datum, Betrag, MwSt., Einzelpositionen) mit Dokumenten-KI, Erkennung von Dubletten und Beinahe-Dubletten, Vergleiche mit Vergleichsgruppen und Historie sowie Netzwerkanalyse von Lieferanten, Bankkonten und Mitarbeitern. Anbieter nennen hohe Automatisierungs- und Einsparzahlen; AppZen etwa nennt 100 % geprüfte Transaktionen und einen Kundenfall mit 774.000 GBP verhinderten Doppelrechnungen, doch diese Angaben stammen von den Anbietern selbst und sind nicht überprüft [2].
• Abgrenzung: Zahlungs- und Kartenbetrug durch Außenstehende ist ANOM-001; Auffälligkeiten bei Buchungssätzen im Hauptbuch sind ANOM-006; gefälschte Dokumente allgemein ANOM-017; Lohnabrechnung ANOM-037; Absprachen bei öffentlichen Ausschreibungen ANOM-020.

Varianten

• Prüfung von Mitarbeiterspesen und Reisekosten: Belege gegen geltend gemachte Beträge, Kilometer, Tagespauschalen, Alkohol/private Posten, Dubletten über Abrechnungen und Karten hinweg, Ausgaben an Wochenenden und Feiertagen, wiederholt Beträge knapp unter der Grenze.
• Überwachung von Firmen- und virtuellen Karten: nicht passende Händlerkategorien, gesplittete Transaktionen, nicht richtlinienkonforme Händler.
• Procure-to-Pay (P2P) und Kreditorenbetrug: doppelte Rechnungen, Rechnungssplitting, erfundene oder Scheinlieferanten, Änderungen von Lieferantenbankverbindungen, ungewöhnliche Beziehungen zwischen Lieferant und Freigeber, Überfakturierung gegenüber Vertragspreisen. Überschneidung mit dem Rechnungseingang in DOC-001.
• Beschaffungsintegrität (Schmiergelder, gelenkte Vergaben): Vergaben an nur einen Anbieter, immer gleiche Gewinner, zugeschnittene Leistungsbeschreibungen, Überschneidungen in den Stammdaten von Lieferanten und Mitarbeitern (gleiche Adresse, IBAN, Telefonnummer).
• Öffentlicher Sektor: gleiche Muster bei Beschaffung und Dienstreisen; die Risikoprüfung von Ausschreibungen gehört zu ANOM-020.
• KMU: regelbasierte Prüfungen im Spesen- oder Buchhaltungswerkzeug plus ein monatlicher Bericht zu Dubletten und Ausreißern.
• Privatnutzung: nicht anwendbar; die Erfassung privater Belege ist DOC-002.

So funktioniert es

1. Quellen: Spesentool / Kartenfeed / Reisebuchung / ERP (Bestellung, Wareneingang, Rechnung, Lieferantenstamm)
2. Einlesen + Entitätsauflösung (Mitarbeiter, Lieferant, Händler, Bankkonto, Adresse)
3. Beleg-/Rechnungslesen (OCR + VLM
4. strukturierte Felder, Hinweise aus Bildforensik)
5. Regelebene (Richtliniengrenzen, Dubletten, Schwellen, Wochenende/Feiertag, MCC-Prüfungen)
6. statistische Ebene (Benford-artige Zifferntests, Ausreißer in Vergleichsgruppen, Isolation Forest, überwachtes GBM)
7. Graph-Ebene (Verbindungen Lieferant-Mitarbeiter-Bankkonto, Konzentration bei Freigebern)
8. LLM-Ebene (Beleg mit Abrechnungstext vergleichen, Belege zusammenfassen, Begründungscodes erklären)
9. Risikowert
10. automatisch freigeben / Mitarbeiter fragen / an Prüfer weiterleiten
11. Fallmanagement + Rückmeldungen als Labels für das Nachtrainieren

• Regeln plus unüberwachte plus überwachte Verfahren: Bestätigte Betrugsfälle als Labels sind selten. Daher starten die meisten Einführungen mit Regeln und Anomalieerkennung und ergänzen ein überwachtes Modell (Gradient Boosting), sobald Ermittler einige hundert Ergebnisse markiert haben.
• Beleg- und Dokumenten-KI: Vorgefertigte Modelle wie das Belegmodell von Azure AI Document Intelligence lesen Händler, Datum, Steuer, Summen und Einzelpositionen als JSON aus [3]; VLMs lesen ungewöhnliche Layouts und handschriftliche Belege. Da generative Bildwerkzeuge inzwischen überzeugende gefälschte Belege erzeugen können, muss die Extraktion mit Plausibilitätsprüfungen gekoppelt werden (Händler existiert, MwSt.-Satz und Rechnung stimmen, Zeit und Ort passen zusammen, doppelte Bild-Hashes, Metadaten) und bei höherem Risiko mit forensischer Erkennung (siehe ANOM-017, ANOM-015).
• LLMs lesen Richtlinientexte, gleichen freie Begründungen mit den Belegen ab, erklären eine Markierung und entwerfen die Rückfrage an den Mitarbeiter. Sie sollten nicht allein über einen Risikowert entscheiden.
• Mensch-in-der-Schleife (Human-in-the-Loop): Eine Markierung ist ein Anlass zum Hinsehen, kein Befund. Prüfer sowie Personal/Compliance entscheiden; Mitarbeiter erhalten vor jeder Konsequenz Gelegenheit zur Stellungnahme.

Datenaufbereitung

Benötigt werden Spesenabrechnungen und Belege (Fotos, PDFs), Karten- und Reisetransaktionen, Lieferantenrechnungen, Bestellungen, Wareneingänge, Freigabeprotokolle, Lieferanten- und Mitarbeiterstammdaten sowie die schriftliche Reise- und Einkaufsrichtlinie. In einem KMU liegen diese im ERP- oder Buchhaltungssystem, in einem Spesentool, in E-Mail-Postfächern, auf Dateiablagen und manchmal in Papierordnern. Typische Lücken: Belege als schlechte Handyfotos oder Scans, doppelte oder uneinheitliche Lieferantenstammsätze (dieselbe IBAN unter mehreren Namen), fehlende Bestellverknüpfungen, keine Labels zu früheren bestätigten Betrugsfällen, Richtlinien, die nur als PDF existieren, und weitreichende Zugriffsrechte auf Finanzdaten.

Aufbereitungsschritte: Transaktionen und Stammdaten über die ERP-Schnittstelle exportieren (PREP-005); OCR auf Belege und Rechnungen anwenden (DOC-014); Lieferantensätze bereinigen und Dubletten entfernen; Labels aus früheren Prüfungsfeststellungen und abgelehnten Abrechnungen gewinnen (PREP-020); Mitarbeiterdaten für die Modellentwicklung pseudonymisieren (PREP-022); den Zugriff auf die Falldaten beschränken. Werkzeuge: Paperless-ngx oder die OCR des Spesentools, pandas/SQL und der eigene Export des ERP. Rechnen Sie mit etwa 30–40 % des Projektaufwands für die Datenarbeit, vor allem für die Bereinigung der Lieferantenstammdaten und die Historie der markierten Fälle. Siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A, weil ausgereifte, in der EU gehostete Produkte für Ausgabenmanagement und Kreditorenautomatisierung Betrugs- und Dublettenprüfungen für einen Standardprozess zu KMU-Preisen enthalten.
• Großunternehmen: Weg B, weil ERP-/P2P-Daten, Lieferanten-Graphen und eigene Richtlinien zum Kern des Kontrollsystems gehören und selten von einem Produkt out of the box abgedeckt werden.
• Entwickler: Weg C, weil Open-Source-Anomalieerkennung und OCR auf eigener Hardware volle Kontrolle über sensible Mitarbeiter- und Lieferantendaten geben.
• Öffentlicher Sektor: Weg C, weil Vergaberegeln und Souveränitätsanforderungen selbst betriebene oder souveräne Cloud-Umgebungen mit prüfbarer Logik begünstigen.

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

• Spesen- und Ausgabenplattformen mit integrierten Prüf-/Betrugskontrollen: Yokoy (Schweiz, jetzt Teil von Emburse), Spendesk und Payhawk (EU), Pleo (Dänemark), Moss (Deutschland), Circula (Deutschland), Navan, SAP Concur (mit Concur Detect by Oversight), Emburse, Expensify. Prüfen Sie vor dem Kauf auf den aktuellen Funktionsseiten des Anbieters, wie weit Betrugs-, Dubletten- und Belegprüfung reichen.
• KI-Prüfspezialisten: AppZen (autonome Spesenprüfung, Kartenprüfung, autonome Kreditorenbuchhaltung; nennt 90 % ohne Eingriff und 100 % geprüfte Transaktionen als Plattformangaben) [2], Oversight, Basware und Coupa (Ausgabenkontrolle/P2P), Medius, Esker. Prüf- und Analysesuiten wie ACL/Diligent HighBond, MindBridge und CaseWare IDEA dienen den breiteren Hauptbuchtests (ANOM-006).
• Wählen Sie A, wenn: Sie bereits ein Spesen- oder P2P-Werkzeug nutzen, die Mengen überschaubar sind und Sie Ergebnisse in Wochen wollen. Prüfen Sie EU-Datenhaltung, AVV, Betriebsratstauglichkeit und wie Risikowerte erklärt werden.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Extraktion: Azure AI Document Intelligence (Beleg- und Rechnungsmodelle, EU-Regionen) [3], Google Document AI (EU-Standort), AWS Textract AnalyzeExpense (Frankfurt), Mistral OCR (EU-Anbieter) oder ein multimodales Spitzenmodell mit JSON-Schema.
• Analytik: Ihr Data Warehouse (Snowflake, BigQuery EU, Azure Synapse/Fabric) mit scikit-learn, XGBoost/LightGBM und PyOD [5]; vom Anbieter verwaltete Anomalie-Dienste, wo verfügbar.
• LLM-Ebene: In der EU gehostete Modelle (Mistral, Azure OpenAI oder Anthropic Claude über EU-Regionen von Bedrock/Vertex) für den Abgleich von Richtlinie und Abrechnung sowie für Erklärungen. Orchestrieren Sie mit n8n, Power Automate oder einem kleinen Dienst; schreiben Sie Markierungen ins Spesen-/ERP-System zurück.
• Wählen Sie B, wenn: Sie eigene Regeln, mehrere Quellsysteme oder ein eigenes Risikomodell brauchen, aber keine On-Premises-Vorgabe haben.

Weg C — Selbst betreiben (Open Source)

• Parsing: Docling (MIT) [6], Unstructured (Apache-2.0) [7], PaddleOCR, olmOCR; offene VLMs wie die Qwen-VL-Familie über vLLM oder Ollama.
• Erkennung: PyOD (61 Detektoren in einer API) [5], scikit-learn, XGBoost/LightGBM, NetworkX oder Neo4j / Memgraph für Lieferanten-Mitarbeiter-Graphen, DuckDB/Postgres als Feature-Speicher.
• Workflow und Fälle: n8n oder Camunda; Fallmanagement in einem vorhandenen Ticket- bzw. GRC-Werkzeug.
• Hardware: HW2 reicht reichlich; die tabellarische und die Graph-Analytik laufen auf der CPU, die GPU wird nur für das Belesen per VLM gebraucht. Selbst betreiben ist attraktiv bei betriebsratssensiblen Mitarbeiterdaten und für öffentliche Stellen.

Weg D — Eigenes Training

Lohnt sich für große Organisationen mit tausenden markierten, untersuchten Fällen: ein überwachtes Gradient-Boosting- oder Graph-Modell je Ausgabenkategorie, abgestimmt auf Ihre Richtlinien und Ihren Lieferantenstamm, sowie ein feingetuntes kleines VLM für unternehmensspezifische Belegarten. Labels stammen aus Prüfergebnissen, zurückgeholten Beträgen und Klarstellungen von Mitarbeitern. Achten Sie auf Label-Verzerrung: Nur bereits markierte Fälle werden untersucht. Behalten Sie daher eine zufällige Prüfstichprobe, um die tatsächliche Trefferquote (Recall) zu messen.

Stand der Technik (2026)

• Von der Stichprobe zur vollen Abdeckung: Spezialisierte Plattformen werben mit der Prüfung jeder Transaktion bei automatischer Freigabe risikoarmer Vorgänge [2]; das Unterscheidungsmerkmal im Wettbewerb sind Erklärbarkeit und wenige Fehlalarme, nicht die Erkennung allein.
• Dokumenten-KI ist für gedruckte Belege weitgehend gelöst, mit vorgefertigten Modellen, die in Azure inzwischen als v4.0 GA vorliegen [3]; schwierig bleiben zerknitterte oder handschriftliche Belege, mehrsprachige Hotelrechnungen und Tabellen mit Einzelpositionen.
• Synthetische Belege sind die neue Bedrohung. Generative Bildmodelle können plausible Belege erzeugen. Bildforensik, Herkunftsmetadaten und Abgleiche mit Kartenfeeds und Händlerdaten zählen daher mehr als die Sichtprüfung. Es ist ein Wettrüsten ohne verlässlichen Einzeldetektor.
• Unüberwachte Werkzeugkästen sind ausgereift: PyOD bietet 61 Detektoren für verschiedene Datentypen, und ADBench vergleicht 30 Algorithmen auf 57 tabellarischen Datensätzen. Es zeigt, dass kein einzelner Algorithmus überall gewinnt; Ensembles und fachliche Merkmale zählen mehr [5].
• Agentische Prüfung: Agenten fragen den Mitarbeiter nach einem fehlenden Beleg, sammeln die Buchungsnachweise und schreiben die Fallzusammenfassung; die Entscheidung bleibt bei einem Menschen.
• Grenzen: hohe Fehlalarmquoten bei legitimen Sonderfällen (Kundenbewirtung, Reisestörungen); wenige bestätigte Labels; Konzeptdrift bei Richtlinienänderungen; Täter passen sich an (Beträge knapp unter Schwellen); Absprachen zwischen Freigebern sind allein in Transaktionsdaten schwer zu erkennen. Risikowerte dürfen nicht als Beweis dargestellt werden.

Gemeinsame Bausteine & Kombinationen

• Gleiche Bausteine (ocr-docparse + vlm): DOC-001 Rechnungsverarbeitung und DOC-002 Belegerfassung speisen diesen Anwendungsfall direkt; ein Dokumenten-KI-/VLM-Server (HW2) bedient alle drei.
• Anomalie- und Graph-Stack (tabular-ml, anomaly-detection, graph-ml): gemeinsam mit ANOM-001 (Transaktionsbetrug), ANOM-006 (Hauptbuchanomalien), ANOM-037 (Lohnprüfung), ANOM-033 (Retourenbetrug im Handel) und ANOM-020 (Absprachen bei öffentlicher Beschaffung). Ein gemeinsamer Feature-Speicher und eine gemeinsame Entitätsauflösung (Lieferanten, Bankkonten, Adressen) zahlen sich in allen aus.
• Dokumentenfälschung: ANOM-017 und ANOM-015 für bearbeitete oder KI-erzeugte Belege und Rechnungen.
• Nachgelagert: AGENT-006 (Abstimmung und Abschluss) und die Workflow-Engine für Freigaben; Fallmanagement gemeinsam mit Compliance- und Hinweisgeberprozessen.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis wenige Wochen bis zur Aktivierung; Abonnement pro Nutzer oder Dokument, oft in Spesentools enthalten.
• Weg B: 2–4 Monate für Anbindung, Regeln, Modell und Fall-Workflow; Kostentreiber sind Datenintegration und Feinabstimmung, die API-Kosten je Beleg sind gering.
• Weg C: 3–6 Monate plus ein GPU-Server für das VLM, Analytik auf Standardhardware; laufender Abstimmungsaufwand.
• Weg D: 6+ Monate und ein Data Scientist, nur mit genügend markierten Fällen gerechtfertigt.
• Kennzahlen: Anteil der abgedeckten Ausgaben/Abrechnungen, Präzision der Markierungen (bestätigt oder korrigiert / markiert), Recall gemessen an zufälligen Prüfstichproben, zurückgeholte oder vermiedene Beträge, entdeckte Doppelzahlungen, Zeit je Prüffall, Quote automatischer Freigaben, Beschwerdequote der Mitarbeiter.

Menschen & Veränderung

Binden Sie zuerst die Geschäftsführung für das Mandat und die Regel ein, dass Befunde Hinweise und keine Urteile sind. Die Abteilungsleitung (Finanzen, Einkauf) legt Richtlinien und Schwellen fest; die IT bindet ERP und Spesentools an; die/der Datenschutzbeauftragte wird früh gebraucht, weil Mitarbeiterdaten systematisch verarbeitet werden. Eine Datenschutz-Folgenabschätzung (DSFA, Art. 35 DSGVO) ist daher wahrscheinlich, dazu ein AVV (Art. 28 DSGVO) mit jedem Anbieter. Recht bzw. Compliance legen den Fallprozess und die Sanktionen fest.

Betriebsrat: ja in Unternehmen, die einen haben. Ein System, das das Spesenverhalten namentlich bekannter Mitarbeiter auswertet, ist objektiv zur Überwachung von Leistung und Verhalten geeignet (§ 87 Abs. 1 Nr. 6 BetrVG), und § 90 Abs. 1 Nr. 3 verlangt frühzeitige Information. Eine Betriebsvereinbarung sollte die Zwecke begrenzen, automatische Sanktionen verbieten und die Aufbewahrung festlegen. Im öffentlichen Dienst gilt der Personalrat.

KI-Kompetenz: Schulen Sie Mitarbeitende in der Finanzabteilung und Freigeber kurz dazu, was Risikowerte bedeuten und wo Fehlalarme entstehen (Art. 4 KI-Verordnung). Kommunizieren Sie offen: Ehrliche Mitarbeiter fürchten Überwachung. Erklären Sie daher, dass die Prüfungen alle Abrechnungen einheitlich erfassen und dass ein Mensch jeden Fall entscheidet. Starten Sie mit einem Pilot in einer Gesellschaft oder Kostenkategorie, laufen Sie zuerst im Schattenmodus und verfolgen Sie die Belastung durch Fehlalarme. Lehnen Sie nie automatisch ab und sanktionieren Sie nie automatisch. Leitfäden: GUIDE-004, GUIDE-005, GUIDE-008.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): hängt von der Nutzung ab. Reine Finanzkontroll-Analytik zu Rechnungen und Lieferanten ist in der Regel minimales Risiko (KI-Kompetenz, Art. 4). Kreditwürdigkeitsprüfungen sind nach Anhang III 5(b) Hochrisiko-Systeme, Betrugserkennung ist dort jedoch ausgenommen [4]. Der entscheidende Punkt ist Anhang III 4(b): KI zur Überwachung und Bewertung von Leistung und Verhalten von Beschäftigten ist Hochrisiko [4]. Ein System, das das Verhalten einzelner Mitarbeiter profiliert und Disziplinarmaßnahmen auslöst, kann darunter fallen. Gestalten Sie es daher als Erkennung von Ausgabenanomalien mit menschlichen Entscheidungen, dokumentieren Sie den Verwendungszweck und lassen Sie es rechtlich bewerten. Emotionserkennung oder Verhaltensprofilierung von Beschäftigten ist nicht Teil dieses Anwendungsfalls (Grenzen nach Art. 5).
• DSGVO: Mitarbeiterspesen, Reisedaten und Daten von Einzelunternehmern als Lieferanten sind personenbezogene Daten. Nötig sind eine Rechtsgrundlage (Art. 6 Abs. 1 lit. f berechtigtes Interesse, Interessenabwägung), eine DSFA, Transparenz gegenüber den Beschäftigten, Datenminimierung und Löschfristen. Art. 22: keine ausschließlich automatisierten Entscheidungen mit erheblicher Wirkung, etwa Kündigung oder Verweigerung einer Erstattung, ohne menschliche Prüfung. In Deutschland gilt die Mitbestimmung des Betriebsrats (§ 87 Abs. 1 Nr. 6 BetrVG) für technische Systeme, die Beschäftigte überwachen können, und § 26 BDSG regelt den Beschäftigtendatenschutz.
• Branchenregeln: GoBD für nachvollziehbare, unveränderbare Buchführung und Archivierung; Rechnungsanforderungen nach § 14 UStG; Pflichten zur Betrugsprävention im Rahmen interner Kontrollsysteme (und das Lieferkettensorgfaltspflichtengesetz, LkSG, für die Sorgfalt gegenüber Lieferanten); öffentliche Stellen folgen Vergaberecht und Haushaltsrecht.
• Risiken und Gegenmaßnahmen: falsche Beschuldigungen (Markierungen erklären, Mitarbeiter antworten lassen, menschliche Entscheidung), Benachteiligung von Gruppen oder Rollen (Markierungsquoten nach Gruppen testen), Modelldrift (überwachen und nachtrainieren), Datenabfluss an Cloud-LLMs (EU-Region, AVV, Mitarbeiternamen vor LLM-Aufrufen pseudonymisieren), Schutz der Identität von Hinweisgebern.

Erste Schritte

1. Holen Sie zuerst die Zustimmung von Recht, Datenschutz und Betriebsrat ein; legen Sie Zweck, Datenumfang und den menschlichen Entscheidungsprozess schriftlich fest.
2. Erstellen Sie eine Ausgangsbasis: doppelte Rechnungen, Käufe, die unter Freigabegrenzen aufgeteilt wurden, und die größten Ausreißer je Kategorie auf Daten von 12–24 Monaten, mit einfachen Regeln und PyOD.
3. Ergänzen Sie das Belesen (Werkzeug aus Weg A oder Pipeline mit Azure/Docling) und vergleichen Sie die ausgelesenen Beträge und Daten mit Abrechnungen und Kartenfeeds.
4. Bauen Sie eine Prüfung der Lieferantenstammdaten (gleiche IBAN, Adresse, Steuernummer bei Lieferanten und Mitarbeitern; Änderungen von Bankverbindungen) als ertragreichste Beschaffungskontrolle.
5. Pilotieren Sie eine Prüfwarteschlange über 2–3 Monate, protokollieren Sie die Ergebnisse der Analysten als Labels, behalten Sie eine zufällige Prüfstichprobe und entscheiden Sie dann, ob ein überwachtes Modell dazukommt.

Quellen

1. ACFE — Report to the Nations / Occupational Fraud 2026 (landing page, 2,402 cases, red-flag medians) — https://www.acfe.com/fraud-resources/report-to-the-nations
2. AppZen — platform and product overview (expense audit, card audit, autonomous AP; vendor-reported figures) — https://www.appzen.com/
3. Microsoft — Azure AI Document Intelligence receipt model — https://learn.microsoft.com/azure/ai-services/document-intelligence/prebuilt/receipt
4. AI Act — Annex III high-risk systems (point 4 employment, point 5 creditworthiness excluding fraud detection) — https://artificialintelligenceact.eu/annex/3/
5. PyOD — Python library for outlier detection (61 detectors, ADBench, PyOD 2) — https://pyod.readthedocs.io/en/latest/
6. Docling — open-source document parsing (MIT) — https://github.com/docling-project/docling
7. Unstructured — open-source document partitioning (Apache-2.0) — https://github.com/Unstructured-IO/unstructured
8. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj