Prüfungsanalytik: Anomalieerkennung bei Buchungssätzen und im Hauptbuch

Prüfer und Controller testen traditionell nur eine kleine Stichprobe von Buchungssätzen. Analysewerkzeuge lesen heute das gesamte Hauptbuch: Sie kombinieren feste Regeln (Wochenendbuchungen, runde Beträge, ungewöhnliche Benutzer), Statistik (Benfordsches Gesetz, Ausreißer) und unüberwachtes ML, um die wenigen Buchungen zu priorisieren, die menschliche Aufmerksamkeit verdienen; LLMs helfen, die Befunde zu erklären und zu dokumentieren. Das Ergebnis ist Vollerhebung und eine risikobasierte Prüfliste statt zufälliger Stichproben.

Problem & Nutzen

• Wer: externe Prüfer (Wirtschaftsprüfer, Prüfungsgesellschaften), interne Revision, Controlling und Konzern- rechnungswesen, Steuerberater sowie öffentliche Prüfer (Rechnungshöfe, kommunale Rechnungsprüfungsämter).
• Heute: Prüfungsstandards erwarten die Prüfung von Buchungssätzen und anderen Anpassungen als Reaktion auf das Risiko der Außerkraftsetzung von Kontrollen durch das Management (ISA 240; PCAOB AS 2401 in den USA). In der Praxis heißt das gefilterte Excel-/SQL-Abfragen und Stichproben. Betrügerische oder fehlerhafte manuelle Buchungen sind selten, Stichproben verfehlen sie deshalb oft.
• KI-Nutzen: die Gesamtheit testen, bewerten statt filtern, Fehlalarme durch gelernte „Normal“-Muster je Unternehmen senken und dokumentieren, warum eine Buchung markiert wurde. Begutachtete Arbeiten zeigen, dass tiefe Autoencoder auf realen Buchhaltungsdaten ungewöhnliche Buchungen mit weniger Fehlalarmen als Basisverfahren markieren können, die absoluten F1-Werte in dieser Studie waren aber bescheiden (etwa 17–33) – eine Erinnerung daran, dass Markierungen Hinweise sind, keine Urteile [3].
• Ausmaß des Problems: Der Bericht Occupational Fraud 2026 der ACFE analysiert 2.402 Fälle aus 143 Ländern und nennt proaktives Datenmonitoring/-analyse unter den Kontrollen, die mit geringeren Schäden und schnellerer Aufdeckung verbunden sind [4].
• Regulatorischer Sog: Die überarbeitete ISA 240 (veröffentlicht im Juli 2025) gilt für Zeiträume, die am oder nach dem 15. Dezember 2026 beginnen, und betont stärker die Betrugsperspektive bei der Risikobeurteilung [2].

Varianten

• Externe Prüfung (Jahresabschluss): einmaliger Import des Hauptbuchs; Tests an die Prüfungsakte gebunden.
• Kontinuierliche Kontrollüberwachung / interne Revision: monatliche oder tägliche Bewertung der Buchungen während des Abschlusses.
• Konzerncontrolling: konzernweiter Vergleich des Buchungsverhaltens, Abweichungen bei Intercompany-Buchungen.
• KMU / Steuerberater: Plausibilitätsprüfungen von Buchhaltungsexporten vor Jahresabschluss oder Betriebsprüfung (Betriebsprüfung) – Dubletten, fehlende Belegnummern, rückdatierte Buchungen.
• Öffentlicher Sektor: Rechnungsprüfungsämter, die kommunale Hauptbücher und Zuwendungsbuchungen prüfen.
• Außerhalb des Umfangs (Nachbarn): Spesen-/Beschaffungsbetrug (ANOM-009), Kartenzahlungen (ANOM-001), Geldwäsche-Prüfung bei Banken (ANOM-002). Die behördenseitige Steuerrisikobewertung externer Steuerpflichtiger ist ein eigener Fall (ANOM-018).

So funktioniert es

1. ERP/GL export (SAP, Dynamics, DATEV, Oracle…)
2. completeness check (reconcile to trial balance)
3. feature engineering (time, user, account pair, amount, text, manual/automatic, reversal)
4. layered tests: rules + statistics (Benford, duplicates, gaps) + unsupervised ML score
5. risk ranking with reason codes
6. LLM summary of why an entry looks unusual (optional)
7. auditor/controller review, follow-up to documents
8. conclusion log (workpaper)

• Erst die Vollständigkeit: Der wichtigste Schritt ist der Nachweis, dass der Export vollständig ist und mit der Saldenliste übereinstimmt; Anomalie-Scores auf unvollständigen Daten sind wertlos.
• Regeln und Statistik bleiben das Rückgrat: Wochenend-/Feiertagsbuchungen, Buchungen durch ungewöhnliche oder privilegierte Benutzer, runde Beträge, Beträge knapp unter der Freigabegrenze, seltene Soll-/Haben-Kontenkombinationen, rückdatierte Buchungen, Dubletten.
• Unüberwachtes ML: Isolation Forest, Local Outlier Factor, One-Class-SVM und kovarianzbasierte Verfahren sind Standard und in scikit-learn verfügbar [5]; die Bibliothek PyOD bündelt 60+ Detektoren unter einer API [6]. Autoencoder lernen typische Buchungsmuster und bewerten über den Rekonstruktionsfehler [3].
• Rolle des LLM: nicht der Detektor. LLMs lesen Buchungstexte, erklären eine Markierung in verständlicher Sprache, entwerfen die Rückfrage an den Buchungsverantwortlichen und den Arbeitspapier-Vermerk und beantworten Abfragen in natürlicher Sprache über Ergebnisse. Die Bewertung muss reproduzierbar bleiben.
• Mensch-in-der-Schleife (Human-in-the-Loop): Der Prüfer/Controller entscheidet über jede markierte Buchung; Schlussfolgerungen werden protokolliert.

Datenaufbereitung

Die Kerndaten sind der Export der Hauptbuch-Buchungssätze mit Kopf- und Zeilenebene, dazu Kontenplan, Benutzer- und Rollenstammdaten, Freigabeprotokolle und Vorjahres-Hauptbücher. Sie liegen typischerweise im ERP oder im Buchhaltungssystem (SAP, DATEV, Microsoft Dynamics); zugehörige Rechnungen und Verträge liegen in einem DMS, in E-Mails oder auf Papier. Da die Daten bereits strukturiert sind, ist der Aufwand mäßig.

Typische Lücken: Exporte ohne buchenden Benutzer, Buchungszeit oder Belegart; nicht abgestimmte Summen; zwischen den Jahren geänderter Kontenplan; Freitextfelder mit uneinheitlicher Formulierung; gescannte Belege; und Zugriffsrechte, da Hauptbücher Benutzerkennungen von Beschäftigten enthalten.

Schritte der Aufbereitung: - Kopf und Zeilen exportieren, mit der Saldenliste abstimmen und die Vollständigkeit prüfen, bevor analysiert wird. - Konten über die Jahre zuordnen und Benutzer- und Rollenstammdaten bereinigen. - Datums- und Betragsformate vereinheitlichen und tabellenbasierte Anpassungen aufräumen (PREP-011). - Die Tests und Schwellen mit dem Controller festlegen und Glossarbegriffe abstimmen (PREP-012). - Belege nur für markierte Buchungen digitalisieren und per OCR erfassen (PREP-006, DOC-014). - Benutzerkennungen für externe Werkzeuge pseudonymisieren (PREP-022).

Werkzeuge: Standard-ERP-Exporte, SQL, pandas, Importe von Prüfungsanalytik-Werkzeugen. Planen Sie etwa ein Drittel des Projektaufwands für die Aufbereitung ein; GUIDE-003 bietet einen Reifegrad-Check, PREP-005 behandelt die Extraktion aus dem ERP.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A, weil Prüfungsanalytik-Werkzeuge und die Hauptbuch-Test-Erweiterungen von Buchhaltungsanbietern ausgereift sind und die Buchungssatz-Tests Standard sind.
• Großunternehmen: Weg B, weil die Prüfung in das eigene ERP und die Freigabedaten integriert sein muss und Cloud-KI-Dienste ein firmenspezifisches Regelwerk um Erklärungen ergänzen.
• Entwickler: Weg C, weil Open-Source-Statistik und unüberwachte Verfahren auf einer HW1-Maschine genügen und die Hauptbuchdaten im Haus bleiben.
• Öffentlicher Sektor: Weg C, weil Hauptbuch- und Personaldaten öffentlicher Stellen auf souveräner oder On-Premises-Infrastruktur bleiben sollten, was auch die Beschaffung erleichtert.

Weg A — Kaufen (Standardsoftware)

• Spezialisierte Prüfungs-/Finanzaufsichtsplattformen: MindBridge (Buchungssatzanalyse, die Regeln, Statistik und unüberwachtes ML auf 100 % der Buchungen kombiniert; Produkte sind u. a. Financial Close Oversight und Augmented Assurance; Hosting-Regionen sind auf der öffentlichen Seite nicht genannt, EU-Datenhaltung daher prüfen) [1]; Caseware IDEA (Vollerhebungsanalytik, Ausreißer- und Dublettenerkennung, Importe aus 50+ Buchhaltungssystemen, zeitgesteuerte Routinen) [7]; Diligent ACL Analytics (kontinuierliche Überwachung) [8].
• Prüfungsplattformen der Big-Four-Gesellschaften (proprietäre Werkzeuge von Deloitte, KPMG, EY, PwC) werden von diesen Gesellschaften genutzt und in der Regel nicht als Produkte verkauft.
• Abschlussüberwachungs- und GRC-Werkzeuge in ERP-Ökosystemen (SAP, Oracle, Plattformen vom Typ Workiva) bieten einfachere Prüfungen.
• A wählen, wenn: Sie eine Prüfungsgesellschaft, ein Team der internen Revision oder eine mittelgroße Finanzabteilung sind und ein unterstütztes, prüfbares Werkzeug wollen. Prüfen Sie EU-Datenhaltung, AVV, Export der Arbeitspapiere und Erklärbarkeit des Modells.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Betreiben Sie Detektoren im eigenen Cloud-Mandanten (EU-Region) mit Python (scikit-learn, PyOD) auf einem Data-Warehouse- Export; nutzen Sie eine LLM-API mit Verarbeitung in der EU für Buchungstext-Analyse, Erklärungen und Entwürfe von Rückfragen. Senden Sie nach Möglichkeit aggregierte oder pseudonymisierte Daten (Benutzerkennungen gehasht).
• Orchestrieren Sie mit n8n oder Power Automate (AGENT-002) für monatliche Läufe, Ticketing und Freigaben.
• B wählen, wenn: Sie eigene Tests je Mandant oder Branche brauchen und einen Dateningenieur haben.

Weg C — Selbst betreiben (Open Source)

• Tabellarische Erkennung ist leichtgewichtig: scikit-learn, PyOD, DuckDB/Postgres, Jupyter, ein BI-Frontend. Ein CPU- Server (HW1) verarbeitet Millionen Zeilen; keine GPU nötig.
• Optional ein lokales LLM (HW2) für Erklärungen; halten Sie es vom Bewertungspfad fern.
• C wählen, wenn: Hauptbücher die Räumlichkeiten nicht verlassen dürfen (Vertraulichkeit, Mandantengeheimnis, öffentlicher Sektor).

Weg D — Eigenes Training

Trainieren Sie einen Autoencoder oder ein Sequenzmodell auf der eigenen Historie eines Unternehmens (mehrjährige Hauptbücher, idealerweise 100.000+ Buchungen), um unternehmensspezifisches Normalverhalten zu lernen [3]. Gelabelter Betrug ist fast nie verfügbar, daher ist das Training unüberwacht; die Entscheidungen der Prüfer zu Markierungen werden zu schwachen Labels für die Neupriorisierung. Lohnt sich für große Konzerne oder Prüfungsgesellschaften mit vielen ähnlichen Mandanten, nicht für ein einzelnes KMU.

Stand der Technik (2026)

• Der geschichtete Ansatz gewinnt: Regeln + Statistik + unüberwachtes ML + Prüfer-Rückmeldung; Anbieter nennen 100 % Abdeckung der Grundgesamtheit und Priorisierung nach Risiko [1][7].
• Deep Learning auf Buchungssätzen wird seit 2017 untersucht (Autoencoder) [3]; produktive Werkzeuge setzen weiter auf interpretierbare Verfahren, weil Prüfer jede Markierung begründen müssen.
• Agentisches Finanzwesen ist der neue Kontext: Anbieter diskutieren inzwischen die Überprüfung der Ergebnisse von KI-Agenten, die Buchungen erstellen sowie Abstimmungen und Abschluss durchführen (AGENT-006); damit wird die unabhängige Anomalie- Überwachung KI-erzeugter Buchungen ein wachsender Einsatz [1].
• Standards: überarbeitete ISA 240, gültig für Zeiträume ab dem 15. Dezember 2026 [2].
• Grenzen und Fehlerbilder: unvollständige oder falsch zugeordnete Exporte; „ungewöhnlich“ heißt nicht „falsch“ (Jahresabschluss und Einmalvorgänge fluten die Liste); keine Grundwahrheits-Labels, daher ist der Recall unbekannt; Anomalie- Scores driften nach ERP-Migrationen oder Änderungen des Kontenplans; Absprachen mit plausibel aussehenden Buchungen sind nicht erkennbar; LLM-Erklärungen können überzeugend klingen und trotzdem falsch sein.

Gemeinsame Bausteine & Kombinationen

• Gleiche Bausteine (anomaly-detection + tabular-ml): ANOM-009 (Spesen & Beschaffung), ANOM-001 (Zahlungen), ANOM-002 (Geldwäsche), ANOM-005 (Sensordaten) – gleicher Feature Store, gleiche Detektor-Bibliothek und gleiche Oberfläche zur Alarmprüfung; alle laufen auf HW1-CPU-Servern.
• Vorgelagerte Daten: DOC-001 (Rechnungsextraktion liefert die Buchungen und Dublettensignale), DOC-017 (Kontoauszüge), AGENT-006 (Abstimmungs- und Abschluss-Agent, dessen Buchungen Aufsicht brauchen).
• Nachgelagert/angrenzend: PRED-016 (Cashflow), DATA-001 (Abfragen in natürlicher Sprache über Ergebnisse), DATA-013 (Process Mining ergänzt die Ereignisprotokoll-Sicht darauf, wer was geändert hat).
• Gemeinsame Infrastruktur: ein Data Warehouse mit ERP-Extrakten, eine Alarm-Warteschlange mit Fallmanagement, ein LLM-Gateway mit Schwärzung personenbezogener Daten.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen bis zur Einführung; Lizenzierung typischerweise je Mandant/Auftrag oder je Gesellschaft.
• Weg B/C: 1–3 Monate für eine erste Version mit 10–20 Tests; überwiegend Datenengineering und Validierung der Tests mit Prüfern. Kostentreiber sind ERP-Extraktion, Datenzuordnung und Prüferzeit, nicht Rechenleistung.
• Kennzahlen: Abdeckung der Grundgesamtheit (%), Anteil der Markierungen, die als Fehler/Befunde bestätigt werden (Präzision der Prüfliste), Prüferminuten je Markierung, Zeit vom Abschluss bis zu den Befunden, gefundene Befunde, die eine Stichprobe übersehen hätte, Quote wiederholter Befunde.

Menschen & Veränderung

Beziehen Sie die Geschäftsführung für das Mandat ein, die Leitung Finanzen oder Controlling als Prozessverantwortliche sowie die interne Revision und den externen Prüfer früh, damit die Tests zu den Prüfungsstandards passen. IT und der Datenverantwortliche des ERP liefern die Exporte; die/der Datenschutzbeauftragte und Legal/Compliance prüfen die Nutzung von Buchungsdaten auf Benutzerebene. Endnutzer sind Controller und Buchhalter, die Markierungen nachverfolgen müssen.

Betriebsrat: abhängig vom Einzelfall. Die Analyse zielt auf Buchungen, verknüpft aber Buchungen mit namentlich bekannten Benutzern und kann individuelles Verhalten offenlegen; die objektive Eignung zur Überwachung nach §87 Abs. 1 Nr. 6 BetrVG ist daher wahrscheinlich, wenn Benutzerkennungen ausgewertet werden; pseudonymisierte, aggregierte Prüfung senkt das Risiko. §90 Abs. 1 Nr. 3 verlangt Information über KI-geplante Arbeitsverfahren. Öffentliche Stellen beziehen den Personalrat ein (GUIDE-004). Beschäftigtendaten bedeuten eine DSFA-Prüfung, einen AVV mit jedem Werkzeuganbieter und die Beteiligung der/des Datenschutzbeauftragten (GUIDE-005).

Fördern Sie die KI-Kompetenz der Finanzmitarbeitenden (Art. 4 KI-Verordnung, GUIDE-006). Pilotieren Sie an einer Gesellschaft oder einem Geschäftsjahr, vergleichen Sie Markierungen mit bekannten Befunden und kommunizieren Sie, dass das Werkzeug die Prüfung priorisiert und niemanden beschuldigt. Typische Sorge ist der Verdacht gegen Kollegen; begegnen Sie ihr mit klaren Regeln, wer welche Ergebnisse sieht. Jede markierte Buchung wird von einem Menschen beurteilt (GUIDE-008, GUIDE-009).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): typischerweise Minimalrisiko. Anhang III kennt keine Kategorie Prüfungsanalytik; der Eintrag zur Kreditwürdigkeitsprüfung in Nr. 5(b) nimmt Systeme zur Aufdeckung von Finanzbetrug ausdrücklich aus [9]. Sensibel wird es, wenn dieselben Scores zur Überwachung oder Bewertung einzelner Beschäftigter genutzt werden (Anhang III Nr. 4(b)) – dann sind Hochrisiko-Pflichten und die Mitbestimmung des Betriebsrats (§87 BetrVG) zu prüfen. KI-Kompetenz (Art. 4) gilt.
• DSGVO: Hauptbücher enthalten Benutzerkennungen, Namen von Beschäftigten in Texten und Einzelunternehmer als Gegenparteien. Nutzen Sie eine Rechtsgrundlage (berechtigtes Interesse / rechtliche Verpflichtung bei der gesetzlichen Abschlussprüfung), pseudonymisieren Sie Benutzer und vermeiden Sie Profiling von Personen; AVV mit Anbietern; Hosting in der EU.
• Berufs- und Steuerrecht: Prüfungsstandards (ISA 240, IDW PS 240 in Deutschland, PCAOB AS 2401); GoBD für Nachvollziehbarkeit und Aufbewahrung des Hauptbuchs; die Verschwiegenheit des Abschlussprüfers (§43 WPO) begrenzt die Cloud-Nutzung.
• Gegenmaßnahmen: Vollständigkeitsabstimmung, dokumentiertes Testdesign, keine automatisierten nachteiligen Entscheidungen, menschliche Schlussfolgerung je Markierung, versionierte Modelle und Protokolle.

Erste Schritte

1. Besorgen Sie einen vollständigen Hauptbuch-Export für eine Periode und stimmen Sie ihn mit der Saldenliste ab.
2. Setzen Sie 8–10 regelbasierte Tests um (Wochenendbuchungen, runde Beträge, Dubletten, seltene Kontenpaare).
3. Ergänzen Sie einen Isolation-Forest- oder LOF-Score und vergleichen Sie dessen Top 100 mit den Regeltreffern.
4. Lassen Sie einen Prüfer 50 Markierungen beurteilen; halten Sie die Ergebnisse fest, um Schwellen abzustimmen.
5. Entscheiden Sie nach dem Pilot zwischen Kaufen und Selbstbauen und klären Sie zuvor Betriebsrats- und Datenschutzfragen.

Quellen

1. MindBridge — journal entry and ledger analytics platform — https://www.mindbridge.ai/
2. IAASB — ISA 240 (Revised), auditor's responsibilities relating to fraud — https://www.iaasb.org/publications/isa-240-revised-auditor-s-responsibilities-relating-fraud-audit-financial-statements
3. Schreyer et al. — Detection of Anomalies in Large Scale Accounting Data using Deep Autoencoder Networks — https://arxiv.org/abs/1709.05254
4. ACFE — Occupational Fraud 2026: A Report to the Nations — https://www.acfe.com/fraud-resources/report-to-the-nations
5. scikit-learn — Novelty and outlier detection — https://scikit-learn.org/stable/modules/outlier_detection.html
6. PyOD — Python library for anomaly detection — https://github.com/yzhao062/pyod
7. Caseware IDEA — https://www.caseware.com/products/idea/
8. Diligent ACL Analytics — https://www.diligent.com/
9. EU AI Act, Annex III (high-risk systems) — https://artificialintelligenceact.eu/annex/3/