Payroll validation & anomaly detection before payroll runs

Payroll errors (wrong tariff step, missing allowance, duplicate payment, wrong social-security code) are usually found after money has left the account, then corrected through costly retroactive runs. AI-assisted pre-run validation combines deterministic rules with statistical anomaly detection and an LLM that explains each finding. Clerks review a short ranked list instead of sampling thousands of lines. It is mostly about errors, less about fraud, and is especially relevant for SMBs and payroll bureaus.

Problem & value

• Today: clerks compare the preliminary register to last month in spreadsheets, check a sample, and rely on the payroll system's built-in plausibility checks. Errors surface through employee complaints, social-security or tax audits (Betriebsprüfung), or year-end reconciliation. Bureaus serving many clients with different collective agreements (Tarifverträge) have the largest checking burden.
• AI value: (1) rules catch known error classes deterministically; (2) statistical models catch unknown deviations (a bonus that appears twice, a pay line that vanished, a new bank account shared by two employees); (3) an LLM turns a numeric flag into "Allowance X was paid last 11 months but is missing; contract clause 4.2 still applies" with a link to evidence.
• Evidence: vendor and practitioner material describes this pattern [1][2][3]. A US patent filing notes that auditing a run is labour-intensive, with about 20 items to examine per paycheck on average [4]. Headline accuracy or savings figures are vendor-reported; measure your own baseline before relying on them.
• Difference to neighbours: ANOM-006 covers ledger journal entries, ANOM-009 expenses and procurement. Payroll has its own data model (gross-to-net, collective-agreement rules, time data) and its main loss is correctable error, not intentional fraud.

Variants

• Payroll bureau / Steuerberater: many small clients, per-client baselines, standardised checks.
• SMB in-house payroll: a plug-in or add-on to the payroll product, 10-500 employees.
• Enterprise / multi-country: shared-service centre, local statutory rule packs, cross-country variance view.
• Public sector: TV-L/TVöD tariff grading and allowances; high rule density, low fraud.
• Post-run audit: same checks run after the fact to find recoverable overpayments.
• Ghost-employee / bank-detail control: subset focused on fraud; see ANOM-009 and ANOM-019 for analogous patterns.

How it works

1. payroll prep (HR changes + time data frozen)
2. preliminary run in payroll engine (SAP, DATEV, Workday, ADP, Personio ...)
3. data extract: pay lines + master data + prior periods + contracts/tariff tables
4. layer 1: deterministic rules (tariff step vs. years of service, allowance entitlement, contribution group/person-group key vs. employment type, min-wage check, duplicates)
5. layer 2: statistical anomaly scoring (per-employee and peer-group deviation, missing/new pay components, bank-account reuse, outliers vs. median of last N periods)
6. layer 3: LLM explanation + evidence retrieval (contract clause, tariff table, time record)
7. ranked review queue for payroll clerk (accept / correct / dismiss with reason)
8. corrections in the source system, final run, audit log

• Rules stay deterministic. Gross-to-net, tax and contribution calculation remain in the certified payroll engine. AI never calculates net pay; it checks inputs and results [2].
• Anomaly models: per-employee baselines on pay components (robust z-score, isolation forest or gradient boosting on tabular features); "missing expected line" detection from the last N periods; percentage-deviation thresholds (one vendor documents a +30% default versus historical median [1]).
• LLM role: explanation, mapping a flag to the contract/agreement clause (RAG over contracts and tariff texts), drafting a question to HR or the employee. It does not decide.
• Human in the loop: the clerk releases the run. Four-eyes principle for bank-detail and rate changes. Feedback (dismissed vs. confirmed) tunes thresholds per client.

Data preparation

Data needed: preliminary payroll registers, six to twelve previous periods, contracts and tariff tables, time and absence data, HR master data changes and statutory parameters. In an SMB these sit in the payroll system (often DATEV or a bureau), the time-recording tool, the HR file (partly paper) and e-mail with change notices.

Typical gaps: contract terms only as scanned PDFs, tariff tables kept in spreadsheets, master data changes without date or reason, inconsistent pay-component codes across years, time data in another system with no common employee ID, and strict access rights on HR data.

Preparation steps: - Export registers and time data and join them on a pseudonymised employee key (PREP-005, PREP-022). - Turn tariff and contract rules into tidy tables (PREP-011); digitise paper contracts (PREP-006, DOC-014). - Standardise pay-component codes (PREP-012, PREP-019). - Collect past corrections as labelled errors (PREP-020) and a test set of known payroll mistakes (PREP-018). - Restrict access to payroll staff and check purpose and legal basis (PREP-025).

Rough share of effort: about 30-40 percent, mainly tariff and contract rules. Check readiness with GUIDE-003.

Implementation paths

Which path for whom

• SMB (A): payroll software and bureau services (for example from DATEV or Lexware) increasingly include plausibility checks, so a standard product covers the common errors without own data work.
• Enterprise (C): payroll data is highly sensitive and the process is core; rules plus anomaly models run on HW1 on-premises, and tariff logic is company-specific.
• Developer (B): payroll vendors integrate via exports and APIs; a rules and LLM-explanation layer on EU cloud APIs (with pseudonymised data) is quick to build for bureaus.

Path A — Buy (recommended for most SMBs and bureaus)

• Payroll suites with built-in checks/AI: Workday (payroll controls with tolerances and AI anomaly detection, Workday Illuminate) [3], ADP (ADP Assist, pre-run variance checks), SAP SuccessFactors Employee Central Payroll, DATEV Lohn und Gehalt (EU, plausibility checks; verify current AI features with DATEV), Personio (EU), Visma (EU), Sage, Lucca (EU).
• Specialist validation layers: Mercans (Enhanced Payroll Validation, rule engine plus AI, pre- and post-run) [1], Zalaris (EU/Norway-based, payroll anomaly review layer) [2], Papaya Global.
• Choose A when: one mainstream payroll product, no unusual agreements. Test with your own past runs containing known errors and measure recall and false-alert rate.

Path B — Build on cloud APIs

• Export register and master data to an EU-region data platform; scoring with scikit-learn/XGBoost, then an LLM via an EU endpoint (Mistral, Azure OpenAI EU Data Zone, Claude on EU-region cloud, Gemini EU) with structured outputs for explanations.
• Pseudonymise before sending to any LLM: employee ID instead of name, no IBAN or tax ID in prompts. The statistical layer needs no LLM at all.
• Orchestration with n8n, Power Automate or Airflow; write flags back via the payroll API.
• Choose B when: custom collective agreements or a bureau wants one cross-client product.

Path C — Self-host (open source)

• Tabular: scikit-learn, XGBoost/LightGBM, PyOD, Great Expectations or Pandera for data checks.
• Rules: Python or a rules engine (e.g. Drools, Open Policy Agent); contracts/tariffs indexed with pgvector or Qdrant and an embedding model (e.g. bge-m3, multilingual).
• LLM for explanations: Mistral Small, Qwen3 or Llama-class 7-30B models via vLLM/Ollama.
• Hardware: statistics run on CPU (HW1); a quantised 8B model for explanations fits HW1-HW2. Payroll data never leaves your infrastructure.

Path D — Custom training

Usually unnecessary. Worth it for bureaus with many years of labelled corrections (confirmed error / false alarm per client): a supervised model on tabular features ranks alerts better than unsupervised scores. Needs hundreds to thousands of confirmed errors; start with unsupervised scoring and collect labels.

State of the art (2026)

• The proven pattern is a hybrid: deterministic rules plus statistical baselines plus LLM explanation, not an LLM judging raw payroll tables [1][2].
• Vendors have moved from post-run reports to pre-run checks integrated in the payroll workflow, and from alert lists to explained, evidence-linked alerts.
• Limits: false positives in volatile pay (shift work, commissions, seasonal staff); new employees or clients lack baselines; collective-agreement texts are ambiguous and change mid-year; LLMs may cite the wrong clause, so every explanation must link to the source; benchmarks are mostly vendor-reported.
• A change in rates or tax rules produces mass deviations; statutory parameter updates must be loaded before scoring, or the model floods clerks with alerts.

Shared resources & combinations

• Same tabular/anomaly stack: ANOM-006 (journal entries), ANOM-009 (expense and procurement), ANOM-033.
• Document intake: DOC-001 style parsing for contracts and amendments, ANOM-017 for forged payslips and tampered documents.
• Time data: AGENT-030 for time capture feeding the checks.
• Close process: AGENT-006 for reconciliation of payroll postings to the ledger.
• A single feature store of per-employee pay history can feed several of these.

Effort, cost & KPIs

• Path A: weeks to enable; typically per-employee or per-run licence.
• Path B/C: 2-4 months including data extraction, rule modelling for agreements and clerk feedback loop. Main cost is rule and agreement modelling, not compute.
• KPIs: errors caught before the run versus found afterwards, share of retro-corrections, alert precision (confirmed / flagged), clerk review time per run, overpayments recovered, audit findings.

People & change

Involve early: management and the payroll lead (process owner) first, then HR, the DPO and the works council before any pilot, then IT and the payroll bureau or software vendor. Payroll clerks are the daily users and know the typical errors, so involve them in defining rules.

Works council: yes. The system processes every employee's pay data and logs clerk decisions; under §87(1) no. 6 BetrVG objective suitability for monitoring is enough. Inform it under §90(1) no. 3, consider an expert under §80(3) and agree on a works agreement: purpose limited to error prevention, no performance or behaviour scoring of employees, retention. Public bodies: staff council.

Data protection: employee data requires a legal basis (§26 BDSG, Art. 88 GDPR), an AVV with vendors and a bureau, DPO involvement and a DPIA in case of systematic evaluation (Art. 35 GDPR).

AI literacy: train clerks to check flags instead of trusting or ignoring them (AI Act Art. 4: support measures).

Pilot and concerns: run one payroll cycle in parallel with the usual checks. Clerks fear replacement and employees fear surveillance: the tool flags lines, clerks decide, and nothing is paid or changed automatically.

Guides: GUIDE-004, GUIDE-005, GUIDE-008.

Risks, regulation & compliance

• EU AI Act: typically minimal risk. Checking pay lines for calculation errors is not an Annex III category. It becomes high-risk (Annex III point 4, employment and workers management) if the system is used to make or support decisions on terms of work, task allocation based on behaviour, or to monitor and evaluate individual workers' performance [5]. Keep scope to pay correctness; do not reuse scores for performance or disciplinary decisions. Art. 5: emotion inference at the workplace is prohibited, so never add sentiment or emotion analysis of employee messages to this pipeline. AI literacy (Art. 4) applies.
• GDPR: payroll data is employee personal data, partly special category (church tax, health or sickness data, union fees). Employment context: Art. 88 GDPR and national law (in Germany §26 BDSG), works council co-determination (§87 BetrVG) for technical monitoring. DPIA likely; processor agreement and EU hosting for vendors; Art. 22 GDPR applies if flags automatically trigger adverse decisions, so keep the clerk as decision maker.
• Fraud and security: ghost-employee and bank-detail changes need segregation of duties; restrict access to the flag queue because it reveals salary data.
• Mitigations: pseudonymised LLM calls, evidence-linked explanations, audit log of AI suggestions and final decisions, retention aligned with tax and social-security law.

Getting started

1. Collect 6-12 past payroll runs and the list of errors that were corrected afterwards; this is your test set.
2. Write the top 10 deterministic checks first (duplicates, missing recurring allowances, tariff step vs. service years, contribution group vs. contract type, bank-detail changes).
3. Add per-employee and peer-group deviation scoring; replay old runs and count recall and false alarms.
4. Add LLM explanations with mandatory source links; involve the works council and DPO early.
5. Pilot in parallel with manual checks for 2-3 runs, then tune thresholds from clerk feedback.

Sources

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