Lohnabrechnungsprüfung & Anomalieerkennung vor dem Abrechnungslauf

Fehler in der Lohnabrechnung (falsche Tarifstufe, fehlender Zuschlag, doppelte Zahlung, falscher Sozialversicherungsschlüssel) werden meist erst entdeckt, nachdem das Geld das Konto verlassen hat, und dann durch aufwendige rückwirkende Läufe korrigiert. KI-gestützte Prüfung vor dem Lauf verbindet deterministische Regeln mit statistischer Anomalieerkennung und einem LLM, das jeden Befund erklärt. Sachbearbeiter prüfen eine kurze, priorisierte Liste statt Tausende Zeilen stichprobenartig. Es geht überwiegend um Fehler, weniger um Betrug, und ist besonders für KMU und Abrechnungsbüros relevant.

Problem & Nutzen

• Heute: Sachbearbeiter vergleichen das vorläufige Journal in Tabellen mit dem Vormonat, prüfen eine Stichprobe und verlassen sich auf die eingebauten Plausibilitätsprüfungen des Abrechnungssystems. Fehler zeigen sich durch Beschwerden von Beschäftigten, durch Prüfungen von Sozialversicherung oder Finanzamt (Betriebsprüfung) oder beim Jahresabgleich. Büros, die viele Mandanten mit unterschiedlichen Tarifverträgen betreuen, tragen die größte Prüflast.
• KI-Nutzen: (1) Regeln fangen bekannte Fehlerklassen deterministisch ab; (2) statistische Modelle fangen unbekannte Abweichungen (ein Bonus, der doppelt erscheint, eine verschwundene Abrechnungszeile, ein neues Bankkonto, das zwei Beschäftigte teilen); (3) ein LLM macht aus einem numerischen Hinweis „Zuschlag X wurde in den letzten 11 Monaten gezahlt, fehlt aber; Vertragsklausel 4.2 gilt weiterhin“ mit einem Link zum Beleg.
• Belege: Material von Anbietern und Praktikern beschreibt dieses Muster [1][2][3]. Eine US-Patentanmeldung stellt fest, dass die Prüfung eines Laufs arbeitsintensiv ist, mit durchschnittlich etwa 20 zu prüfenden Punkten je Gehaltsabrechnung [4]. Genauigkeits- oder Einsparangaben in Schlagzeilen stammen von den Anbietern; messen Sie Ihre eigene Ausgangslage, bevor Sie sich darauf verlassen.
• Unterschied zu Nachbarfällen: ANOM-006 behandelt Buchungssätze im Hauptbuch, ANOM-009 Spesen und Beschaffung. Die Lohnabrechnung hat ein eigenes Datenmodell (Brutto-Netto, Tarifregeln, Zeitdaten), und ihr Hauptverlust ist korrigierbarer Fehler, nicht vorsätzlicher Betrug.

Varianten

• Abrechnungsbüro / Steuerberater: viele kleine Mandanten, Ausgangswerte je Mandant, standardisierte Prüfungen.
• Lohnabrechnung im KMU selbst: ein Plug-in oder Zusatzmodul zum Abrechnungsprodukt, 10-500 Beschäftigte.
• Großunternehmen / mehrere Länder: Shared-Service-Center, lokale gesetzliche Regelpakete, länderübergreifende Abweichungsansicht.
• Öffentlicher Dienst: Eingruppierung und Zulagen nach TV-L/TVöD; hohe Regeldichte, wenig Betrug.
• Prüfung nach dem Lauf: dieselben Prüfungen im Nachhinein, um erstattungsfähige Überzahlungen zu finden.
• Kontrolle auf Scheinbeschäftigte / Bankdaten: Teilmenge mit Fokus auf Betrug; zu analogen Mustern siehe ANOM-009 und ANOM-019.

So funktioniert es

1. Abrechnungsvorbereitung (Personaländerungen + Zeitdaten eingefroren)
2. Probelauf in der Abrechnungs-Engine (SAP, DATEV, Workday, ADP, Personio ...)
3. Datenextrakt: Abrechnungszeilen + Stammdaten + Vorperioden + Verträge/Tariftabellen
4. Ebene 1: deterministische Regeln (Tarifstufe vs. Dienstjahre, Zulagenanspruch, Beitragsgruppen-/Personengruppenschlüssel vs. Beschäftigungsart, Mindestlohnprüfung, Dubletten)
5. Ebene 2: statistische Anomalie-Bewertung (Abweichung je Beschäftigtem und Vergleichsgruppe, fehlende/neue Lohnbestandteile, mehrfach verwendete Bankverbindungen, Ausreißer vs. Median der letzten N Perioden)
6. Ebene 3: LLM-Erklärung + Belegabruf (Vertragsklausel, Tariftabelle, Zeitnachweis)
7. priorisierte Prüfliste für den Sachbearbeiter (bestätigen / korrigieren / mit Begründung verwerfen)
8. Korrekturen im Quellsystem, Echtlauf, Prüfprotokoll

• Regeln bleiben deterministisch. Brutto-Netto-, Steuer- und Beitragsberechnung bleiben im zertifizierten Abrechnungssystem. Die KI berechnet nie das Nettogehalt; sie prüft Eingaben und Ergebnisse [2].
• Anomaliemodelle: Ausgangswerte je Beschäftigtem für Lohnbestandteile (robuster Z-Wert, Isolation Forest oder Gradient Boosting auf Tabellenmerkmalen); Erkennung „erwartete Zeile fehlt“ aus den letzten N Perioden; Schwellen für prozentuale Abweichung (ein Anbieter dokumentiert +30 % gegenüber dem historischen Median als Standard [1]).
• Rolle des LLM: Erklärung, Zuordnung eines Hinweises zur Vertrags-/Tarifklausel (RAG über Verträge und Tariftexte), Entwurf einer Rückfrage an die Personalabteilung oder die/den Beschäftigte(n). Es entscheidet nicht.
• Mensch-in-der-Schleife (Human-in-the-Loop): Der Sachbearbeiter gibt den Lauf frei. Vier-Augen-Prinzip bei Änderungen von Bankdaten und Sätzen. Rückmeldungen (verworfen vs. bestätigt) stimmen die Schwellen je Mandant ab.

Datenaufbereitung

Benötigte Daten: vorläufige Abrechnungsjournale, sechs bis zwölf vorangegangene Perioden, Verträge und Tariftabellen, Zeit- und Abwesenheitsdaten, Änderungen der Personalstammdaten und gesetzliche Parameter. In einem KMU liegen diese im Abrechnungssystem (oft DATEV oder ein Büro), im Zeiterfassungswerkzeug, in der Personalakte (teils Papier) und in E-Mails mit Änderungsmitteilungen.

Typische Lücken: Vertragsbedingungen nur als gescannte PDFs, Tariftabellen in Tabellenkalkulationen, Stammdatenänderungen ohne Datum oder Grund, uneinheitliche Lohnart-Schlüssel über die Jahre, Zeitdaten in einem anderen System ohne gemeinsame Personalnummer und strenge Zugriffsrechte auf Personaldaten.

Aufbereitungsschritte: - Journale und Zeitdaten exportieren und über einen pseudonymisierten Beschäftigtenschlüssel verbinden (PREP-005, PREP-022). - Tarif- und Vertragsregeln in saubere Tabellen überführen (PREP-011); Papierverträge digitalisieren (PREP-006, DOC-014). - Lohnart-Schlüssel vereinheitlichen (PREP-012, PREP-019). - Frühere Korrekturen als gelabelte Fehler sammeln (PREP-020) sowie einen Testdatensatz bekannter Abrechnungsfehler (PREP-018). - Zugriff auf die Lohnbuchhaltung beschränken sowie Zweck und Rechtsgrundlage prüfen (PREP-025).

Grober Aufwandsanteil: etwa 30-40 Prozent, vor allem für Tarif- und Vertragsregeln. Die Bereitschaft prüfen Sie mit GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU (A): Abrechnungssoftware und Büro-Dienstleistungen (zum Beispiel von DATEV oder Lexware) enthalten zunehmend Plausibilitätsprüfungen, sodass ein Standardprodukt die häufigen Fehler ohne eigene Datenarbeit abdeckt.
• Großunternehmen (C): Abrechnungsdaten sind hochsensibel und der Prozess ist zentral; Regeln plus Anomaliemodelle laufen auf HW1 vor Ort, und die Tariflogik ist unternehmensspezifisch.
• Entwickler (B): Abrechnungsanbieter binden sich über Exporte und APIs an; eine Schicht aus Regeln und LLM-Erklärung auf EU-Cloud-APIs (mit pseudonymisierten Daten) ist für Büros schnell gebaut.

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

• Abrechnungssuiten mit eingebauten Prüfungen/KI: Workday (Abrechnungskontrollen mit Toleranzen und KI-Anomalieerkennung, Workday Illuminate) [3], ADP (ADP Assist, Abweichungsprüfungen vor dem Lauf), SAP SuccessFactors Employee Central Payroll, DATEV Lohn und Gehalt (EU, Plausibilitätsprüfungen; aktuelle KI-Funktionen bei DATEV erfragen), Personio (EU), Visma (EU), Sage, Lucca (EU).
• Spezialisierte Prüfschichten: Mercans (Enhanced Payroll Validation, Regelmaschine plus KI, vor und nach dem Lauf) [1], Zalaris (EU/Norwegen, Schicht zur Prüfung von Abrechnungsanomalien) [2], Papaya Global.
• Weg A wählen, wenn: ein gängiges Abrechnungsprodukt im Einsatz ist und keine ungewöhnlichen Vereinbarungen gelten. Mit eigenen früheren Läufen mit bekannten Fehlern testen und Trefferquote (Recall) sowie Fehlalarmquote messen.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Journal und Stammdaten in eine Datenplattform in einer EU-Region exportieren; Scoring mit scikit-learn/XGBoost, danach ein LLM über einen EU-Endpunkt (Mistral, Azure OpenAI EU Data Zone, Claude in einer Cloud-Region der EU, Gemini EU) mit strukturierten Ausgaben für die Erklärungen.
• Vor dem Senden an ein LLM pseudonymisieren: Personalnummer statt Name, keine IBAN und keine Steuer-ID in Prompts. Die statistische Schicht braucht überhaupt kein LLM.
• Orchestrierung mit n8n, Power Automate oder Airflow; Hinweise über die Abrechnungs-API zurückschreiben.
• Weg B wählen, wenn: individuelle Tarifverträge gelten oder ein Büro ein mandantenübergreifendes Produkt will.

Weg C — Selbst betreiben (Open Source)

• Tabellendaten: scikit-learn, XGBoost/LightGBM, PyOD, Great Expectations oder Pandera für Datenprüfungen.
• Regeln: Python oder eine Regelmaschine (z. B. Drools, Open Policy Agent); Verträge/Tarife indexiert mit pgvector oder Qdrant und einem Embedding-Modell (z. B. bge-m3, mehrsprachig).
• LLM für Erklärungen: Mistral Small, Qwen3 oder Modelle der Llama-Klasse mit 7-30 Mrd. Parametern über vLLM/Ollama.
• Hardware: Die Statistik läuft auf der CPU (HW1); ein quantisiertes 8B-Modell für Erklärungen passt auf HW1-HW2. Abrechnungsdaten verlassen Ihre Infrastruktur nie.

Weg D — Eigenes Training

Meist unnötig. Lohnt sich für Büros mit vielen Jahren gelabelter Korrekturen (bestätigter Fehler / Fehlalarm je Mandant): Ein überwachtes Modell auf Tabellenmerkmalen priorisiert Hinweise besser als unüberwachte Werte. Benötigt Hunderte bis Tausende bestätigte Fehler; mit unüberwachtem Scoring beginnen und Labels sammeln.

Stand der Technik (2026)

• Das bewährte Muster ist ein Hybrid: deterministische Regeln plus statistische Ausgangswerte plus LLM-Erklärung, nicht ein LLM, das rohe Abrechnungstabellen beurteilt [1][2].
• Anbieter sind von Berichten nach dem Lauf zu Prüfungen vor dem Lauf im Abrechnungsablauf übergegangen und von Hinweislisten zu erklärten, belegverknüpften Hinweisen.
• Grenzen: Fehlalarme bei schwankenden Bezügen (Schichtarbeit, Provisionen, Saisonkräfte); neue Beschäftigte oder Mandanten haben keine Ausgangswerte; Tarifvertragstexte sind mehrdeutig und ändern sich unterjährig; LLMs können die falsche Klausel zitieren, daher muss jede Erklärung auf die Quelle verlinken; Benchmarks stammen überwiegend von Anbietern.
• Eine Änderung von Sätzen oder Steuerregeln erzeugt Massenabweichungen; gesetzliche Parameter-Updates müssen vor dem Scoring geladen werden, sonst überschwemmt das Modell die Sachbearbeiter mit Hinweisen.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack für Tabellen/Anomalien: ANOM-006 (Buchungssätze), ANOM-009 (Spesen und Beschaffung), ANOM-033.
• Dokumenteneingang: Parsing im Stil von DOC-001 für Verträge und Nachträge, ANOM-017 für gefälschte Gehaltsabrechnungen und manipulierte Dokumente.
• Zeitdaten: AGENT-030 für die Zeiterfassung, die die Prüfungen speist.
• Abschlussprozess: AGENT-006 für den Abgleich der Lohnbuchungen mit dem Hauptbuch.
• Ein gemeinsamer Feature Store mit der Entgelthistorie je Beschäftigtem kann mehrere dieser Fälle bedienen.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen bis zur Aktivierung; üblicherweise Lizenz pro Beschäftigtem oder pro Lauf.
• Weg B/C: 2-4 Monate inklusive Datenextraktion, Regelmodellierung für Vereinbarungen und Rückkopplungsschleife mit den Sachbearbeitern. Haupt-Kostenfaktor ist die Modellierung von Regeln und Vereinbarungen, nicht Rechenleistung.
• Kennzahlen: vor dem Lauf abgefangene Fehler gegenüber nachträglich gefundenen, Anteil rückwirkender Korrekturen, Präzision der Hinweise (bestätigt / markiert), Prüfzeit der Sachbearbeiter je Lauf, zurückgeholte Überzahlungen, Prüfungsfeststellungen.

Menschen & Veränderung

Früh einbinden: zuerst die Geschäftsführung und die Leitung der Lohnbuchhaltung (Prozessverantwortliche), dann Personalabteilung, die/den Datenschutzbeauftragte(n) und den Betriebsrat vor jedem Pilot, danach IT und das Abrechnungsbüro oder den Softwareanbieter. Die Lohnbuchhalter sind die täglichen Nutzer und kennen die typischen Fehler; binden Sie sie in die Festlegung der Regeln ein.

Betriebsrat: ja. Das System verarbeitet die Entgeltdaten aller Beschäftigten und protokolliert Entscheidungen der Sachbearbeiter; nach §87 Abs. 1 Nr. 6 BetrVG genügt die objektive Eignung zur Überwachung. Nach §90 Abs. 1 Nr. 3 unterrichten, einen Sachverständigen nach §80 Abs. 3 erwägen und eine Betriebsvereinbarung abschließen: Zweck beschränkt auf Fehlervermeidung, kein Leistungs- oder Verhaltensscoring von Beschäftigten, Aufbewahrung. Öffentliche Stellen: Personalrat.

Datenschutz: Beschäftigtendaten erfordern eine Rechtsgrundlage (§26 BDSG, Art. 88 DSGVO), einen AVV mit Anbietern und dem Büro, die Einbindung der/des Datenschutzbeauftragten und eine DSFA bei systematischer Bewertung (Art. 35 DSGVO).

KI-Kompetenz: Sachbearbeiter schulen, Hinweise zu prüfen, statt ihnen blind zu vertrauen oder sie zu ignorieren (KI-Verordnung Art. 4: Fördermaßnahmen).

Pilot und Bedenken: Einen Abrechnungszyklus parallel zu den üblichen Prüfungen laufen lassen. Sachbearbeiter fürchten Ersatz und Beschäftigte Überwachung: Das Werkzeug markiert Zeilen, die Sachbearbeiter entscheiden, und nichts wird automatisch gezahlt oder geändert.

Leitfäden: GUIDE-004, GUIDE-005, GUIDE-008.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): typischerweise minimales Risiko. Die Prüfung von Abrechnungszeilen auf Rechenfehler ist keine Kategorie nach Anhang III. Sie wird hochriskant (Anhang III Nr. 4, Beschäftigung und Arbeitnehmerverwaltung), wenn das System genutzt wird, um Entscheidungen über Arbeitsbedingungen oder verhaltensbasierte Aufgabenverteilung zu treffen oder zu unterstützen oder um die Leistung einzelner Beschäftigter zu überwachen und zu bewerten [5]. Den Umfang auf die Richtigkeit der Abrechnung begrenzen; Werte nicht für Leistungs- oder Disziplinarentscheidungen weiterverwenden. Art. 5: Emotionsableitung am Arbeitsplatz ist verboten, daher nie eine Stimmungs- oder Emotionsanalyse von Nachrichten Beschäftigter zu dieser Pipeline hinzufügen. KI-Kompetenz (Art. 4) gilt.
• DSGVO: Abrechnungsdaten sind personenbezogene Beschäftigtendaten, teils besondere Kategorien (Kirchensteuer, Gesundheits- oder Krankheitsdaten, Gewerkschaftsbeiträge). Beschäftigungskontext: Art. 88 DSGVO und nationales Recht (in Deutschland §26 BDSG), Mitbestimmung des Betriebsrats (§87 BetrVG) bei technischer Überwachung. DSFA wahrscheinlich; Auftragsverarbeitungsvertrag und EU-Hosting bei Anbietern; Art. 22 DSGVO greift, wenn Hinweise automatisch nachteilige Entscheidungen auslösen, daher bleibt der Sachbearbeiter Entscheider.
• Betrug und Sicherheit: Scheinbeschäftigte und Änderungen von Bankdaten erfordern Funktionstrennung; den Zugriff auf die Hinweis-Warteschlange beschränken, da sie Gehaltsdaten offenlegt.
• Gegenmaßnahmen: pseudonymisierte LLM-Aufrufe, belegverknüpfte Erklärungen, Prüfprotokoll der KI-Vorschläge und endgültigen Entscheidungen, Aufbewahrung gemäß Steuer- und Sozialversicherungsrecht.

Erste Schritte

1. 6-12 frühere Abrechnungsläufe sowie die Liste der später korrigierten Fehler sammeln; das ist Ihr Testdatensatz.
2. Zuerst die 10 wichtigsten deterministischen Prüfungen schreiben (Duplikate, fehlende wiederkehrende Zuschläge, Tarifstufe vs. Dienstjahre, Beitragsgruppe vs. Vertragsart, Änderungen von Bankdaten).
3. Abweichungs-Scoring je Beschäftigtem und je Vergleichsgruppe ergänzen; alte Läufe erneut abspielen und Trefferquote und Fehlalarme zählen.
4. LLM-Erklärungen mit verpflichtenden Quellenlinks ergänzen; Betriebsrat und Datenschutzbeauftragte(n) früh einbinden.
5. 2-3 Läufe parallel zu den manuellen Prüfungen pilotieren, danach die Schwellen anhand der Rückmeldungen der Sachbearbeiter abstimmen.

Quellen

1. Mercans, AI-powered payroll validation (rule engine plus anomaly detection, default +30% threshold) — https://mercans.com/resources/company-news/the-worlds-first-ai-powered-payroll-validation
2. Zalaris, AI-powered payroll anomaly detection and safe implementation — https://zalaris.com/resources/blog/ai-powered-payroll-anomaly-detection-what-is-it-and-how-can-it-be-safely-implemented
3. PwC, Payroll Controls for Workday — https://www.pwc.com/us/en/technology/alliances/workday-implementation-partners/security-controls/confident-compliance-with-payroll-controls-workday.html
4. US patent application, Applied artificial intelligence technology for detecting anomalies in payroll data — https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/11494850
5. Regulation (EU) 2024/1689 (AI Act), Art. 5 and Annex III — https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689
6. AI Act Explorer — https://artificialintelligenceact.eu/ai-act-explorer/
7. Rework, AI Payroll Agent build blueprint (2026; practitioner source) — https://resources.rework.com/libraries/ai-agents/ai-payroll-agent