Expense & procurement fraud detection

Companies lose money through inflated or fictitious expense claims, duplicate and split invoices, fake vendors and collusion between buyers and suppliers, yet most only audit a small sample. AI reviews every claim and invoice, reads the receipt itself, compares it with policy, history and peers, and sends only the suspicious few to a human. The same tooling also catches honest mistakes and policy drift, which is often the bigger share of the savings.

Problem & value

• Today: expense reports are checked by managers who approve in seconds, and finance audits a random sample. Procurement control relies on approval limits and three-way match. Duplicate payments, split orders below approval thresholds, personal spend on cards and vendor fraud surface late or by tip.
• Why it matters: the ACFE occupational-fraud study (2,402 cases, 143 countries, survey July-September 2025) associates proactive data monitoring and analysis with lower losses and faster detection, and reports that "unusually close ties with a vendor or customer" is a red flag linked to a median loss of USD 300,000 [1]. Tips remain a major detection channel, so analytics complements, not replaces, a whistleblower channel (EU Directive 2019/1937).
• AI value: 100 % coverage instead of sampling, receipt-level checks (merchant, date, amount, VAT, line items) via document AI, duplicate and near-duplicate detection, peer and history baselines, and network analysis of vendors, bank accounts and employees. Vendors report large automation and savings figures, for example AppZen lists 100 % of transactions reviewed and a customer case of GBP 774K duplicate invoices prevented, but these are self-reported and unverified [2].
• Boundaries: payment/card transaction fraud by outsiders is ANOM-001; ledger-level journal anomalies are ANOM-006; forged documents in general are ANOM-017; payroll is ANOM-037; public tender collusion is ANOM-020.

Variants

• Employee expense and T&E audit: receipts vs. claimed amounts, mileage, per diem, alcohol/personal items, duplicates across reports and cards, weekend and holiday spend, repeated just-below-limit amounts.
• Corporate card and virtual-card monitoring: merchant category mismatches, split transactions, out-of-policy merchants.
• Procure-to-pay (P2P) and AP fraud: duplicate invoices, invoice splitting, fictitious or shell vendors, vendor bank-account changes, unusual vendor-approver relationships, over-billing against contract prices. Overlaps with invoice intake in DOC-001.
• Procurement integrity (kickbacks, bid steering): single-source awards, repeated winners, specification tailoring, vendor and employee master-data overlaps (shared address, IBAN, phone).
• Public sector: same patterns for Beschaffung and Dienstreisen; high-risk screening of tenders belongs to ANOM-020.
• SMB: rule-based checks inside the expense or accounting tool plus a monthly duplicate/outlier report.
• Private use: not applicable; personal receipt capture is DOC-002.

How it works

1. sources: expense tool / card feed / travel booking / ERP (PO, GR, invoice, vendor master)
2. ingestion + entity resolution (employee, vendor, merchant, bank account, address)
3. receipt/invoice reading (OCR + VLM
4. structured fields, image forensics hints)
5. rule layer (policy limits, duplicates, thresholds, weekend/holiday, MCC checks)
6. statistical layer (Benford-style digit tests, peer-group outliers, isolation forest, supervised GBM)
7. graph layer (vendor-employee-bank-account links, approver concentration)
8. LLM layer (compare receipt to claim text, summarise evidence, explain reason codes)
9. risk score
10. auto-approve / ask employee / route to auditor
11. case management + feedback labels for retraining

• Rules plus unsupervised plus supervised: confirmed fraud labels are rare, so most deployments start with rules and anomaly detection and add a supervised model (gradient boosting) once investigators have labelled a few hundred outcomes.
• Receipt and document AI: prebuilt models such as Azure AI Document Intelligence's receipt model extract merchant, date, tax, totals and line items into JSON [3]; VLMs read odd layouts and handwritten receipts. Because generative image tools can now produce convincing fake receipts, extraction must be paired with plausibility checks (merchant exists, VAT rate and arithmetic correct, time/location consistent, duplicate image hashes, metadata) and, for higher risk, forensic detection (see ANOM-017, ANOM-015).
• LLMs are used for reading policy text, matching free-text justification to the evidence, explaining a flag, and drafting the query to the employee. They should not be the sole decision-maker on a score.
• Human-in-the-loop: a flag is a reason to look, not a finding. Auditors and HR/compliance decide; employees get a chance to explain before any consequence.

Data preparation

Needed are expense reports and receipts (photos, PDFs), card and travel transactions, supplier invoices, purchase orders, goods receipts, approval logs, vendor and employee master data and the written travel and purchasing policy. In an SMB these live in the ERP or accounting system, an expense tool, e-mail inboxes, file shares and sometimes paper folders. Typical gaps: receipts as poor phone photos or scans, duplicate or inconsistent vendor master records (same IBAN under several names), missing purchase-order links, no labels for past confirmed fraud, policy rules that exist only as PDFs, and broad access rights to finance data.

Preparation steps: export transactions and master data via the ERP interface (PREP-005); run OCR on receipts and invoices (DOC-014); deduplicate vendor records; harvest labels from past audit findings and rejected claims (PREP-020); pseudonymise employee data for model development (PREP-022); restrict access to the case data. Tools: Paperless-ngx or the OCR of the expense tool, pandas/SQL, and the ERP's own export. Expect about 30-40 % of the project effort in data work, mostly vendor-master clean-up and the history of labelled cases. See GUIDE-003.

Implementation paths

Which path for whom

• SMB: Path A, because mature EU-hosted spend-management and AP-automation products include fraud and duplicate checks at SMB prices for a standard process.
• Enterprise: Path B, because ERP/P2P data, vendor-master graphs and own policies are core to the control framework and rarely fit a product out of the box.
• Developer: Path C, because open-source anomaly detection and OCR on own hardware gives full control over sensitive employee and supplier data.
• Public: Path C, because procurement rules and sovereignty requirements favour self-hosted or sovereign-cloud setups with auditable logic.

Path A — Buy (recommended for most organisations)

• Expense and spend platforms with built-in audit/fraud checks: Yokoy (Swiss, now part of Emburse), Spendesk and Payhawk (EU), Pleo (Denmark), Moss (Germany), Circula (Germany), Navan, SAP Concur (with Concur Detect by Oversight), Emburse, Expensify. Check the vendor's own current feature pages for fraud, duplicate and receipt-check depth before buying.
• AI audit specialists: AppZen (autonomous expense audit, card audit, autonomous AP; lists 90 % touchless and 100 % of transactions reviewed as platform claims) [2], Oversight, Basware and Coupa (spend control/P2P), Medius, Esker. Audit and analytics suites: ACL/Diligent HighBond, MindBridge, CaseWare IDEA are for broader ledger tests (ANOM-006).
• Choose A when: you already use an expense or P2P tool, volumes are modest, and you want results in weeks. Verify EU data residency, DPA, works-council readiness and how scores are explained.

Path B — Build on cloud APIs

• Extraction: Azure AI Document Intelligence (receipt and invoice models, EU regions) [3], Google Document AI (EU location), AWS Textract AnalyzeExpense (Frankfurt), Mistral OCR (EU provider), or a multimodal frontier model with a JSON schema.
• Analytics: your warehouse (Snowflake, BigQuery EU, Azure Synapse/Fabric) with scikit-learn, XGBoost/LightGBM and PyOD [5]; vendor-managed anomaly services where available.
• LLM layer: EU-hosted models (Mistral, Azure OpenAI or Anthropic Claude via EU regions of Bedrock/Vertex) for policy-vs-claim reasoning and explanations. Orchestrate with n8n, Power Automate or a small service; write flags back to the expense/ERP system.
• Choose B when: you need custom rules, several source systems or your own risk model, but have no on-prem constraint.

Path C — Self-host (open source)

• Parsing: Docling (MIT) [6], Unstructured (Apache-2.0) [7], PaddleOCR, olmOCR; open VLMs such as the Qwen-VL family via vLLM or Ollama.
• Detection: PyOD (61 detectors on one API) [5], scikit-learn, XGBoost/LightGBM, NetworkX or Neo4j / Memgraph for vendor-employee graphs, DuckDB/Postgres for the feature store.
• Workflow and cases: n8n or Camunda; case management in an existing ticketing/GRC tool.
• Hardware: HW2 is plenty; the tabular and graph analytics run on CPU, the GPU is only needed for VLM receipt reading. Self-hosting is attractive for works-council-sensitive employee data and public bodies.

Path D — Custom training

Worth it for large organisations with thousands of labelled investigated cases: a supervised gradient-boosted model or graph model per spend category, tuned to your policies and vendor base, and a fine-tuned small VLM for company-specific receipt types. Labels come from audit outcomes, recovered amounts and employee clarifications. Beware of label bias: only previously flagged cases get investigated, so keep a random audit sample to measure true recall.

State of the art (2026)

• From sampling to full coverage: specialised platforms advertise review of every transaction with automated approval of low-risk items [2]; the competitive differentiator is explainability and low false-positive rates, not detection alone.
• Document AI is largely solved for printed receipts, with prebuilt models now at v4.0 GA in Azure [3]; remaining difficulty: crumpled or handwritten receipts, multilingual hotel folios, line-item tables.
• Synthetic receipts are the new threat. Generative image models can produce plausible receipts, so image-level forensics, provenance metadata and cross-checks against card feeds and merchant data matter more than visual inspection. This is an arms race with no reliable single detector.
• Unsupervised toolkits are mature: PyOD offers 61 detectors across data types, and ADBench compares 30 algorithms on 57 tabular datasets, showing no single algorithm wins everywhere; ensembles and domain features matter more [5].
• Agentic audit: agents query the employee about a missing receipt, gather the booking evidence, and write the case summary; the decision stays with a human.
• Limits: high false-positive rates on legitimate edge cases (client entertainment, travel disruptions); few confirmed labels; concept drift when policies change; fraudsters adapt (keeping amounts just under thresholds); collusion across approvers is hard to see in transaction data alone. Scores must not be presented as proof.

Shared resources & combinations

• Same building blocks (ocr-docparse + vlm): DOC-001 invoice processing and DOC-002 receipt capture feed this use case directly; one document-AI/VLM server (HW2) serves all three.
• Anomaly and graph stack (tabular-ml, anomaly-detection, graph-ml): shared with ANOM-001 (transaction fraud), ANOM-006 (ledger anomalies), ANOM-037 (payroll validation), ANOM-033 (retail returns fraud) and ANOM-020 (public procurement collusion). A common feature store and entity-resolution layer (vendors, bank accounts, addresses) pays off across all.
• Document forgery: ANOM-017 and ANOM-015 for edited or AI-generated receipts and invoices.
• Downstream: AGENT-006 (reconciliation and close) and the workflow engine used for approvals; case management shared with compliance and whistleblowing processes.

Effort, cost & KPIs

• Path A: days to a few weeks to activate; subscription per user or per document, often bundled in expense tools.
• Path B: 2-4 months for ingestion, rules, model and case workflow; cost drivers are data integration and tuning, API cost per receipt is small.
• Path C: 3-6 months plus a GPU server for VLM, analytics on commodity hardware; ongoing tuning effort.
• Path D: 6+ months and a data scientist, justified only with sufficient labelled cases.
• KPIs: share of spend/claims covered, precision of flags (confirmed or corrected / flagged), recall measured on random audit samples, recovered or avoided amounts, duplicate payments caught, time per audit case, auto-approval rate, employee complaint rate.

People & change

Involve management first for the mandate and the rule that findings are indications, not verdicts. The department lead (finance, procurement) defines policies and thresholds; IT connects ERP and expense tools; the DPO is needed early because employee data is processed systematically, so a DPIA (Art. 35 GDPR) is likely, plus an AVV (Art. 28 GDPR) with every vendor. Legal or compliance defines the case process and sanctions.

Works council: yes in companies with one. A system that evaluates expense behaviour of named employees is objectively suited to monitor performance and behaviour (§87(1) no. 6 BetrVG), and §90(1) no. 3 requires early information. A works agreement should limit purposes, forbid automatic sanctions and set retention. In the public sector the Personalrat applies.

AI literacy: support staff in finance and approvers with short training on what scores mean and where false positives arise (Art. 4 AI Act). Communicate openly: honest employees fear surveillance, so explain that checks cover all claims uniformly and that a human decides every case. Start with a pilot in one entity or cost category, run in shadow mode first, and track false-positive burden. Never auto-reject or auto-sanction. Guides: GUIDE-004, GUIDE-005, GUIDE-008.

Risks, regulation & compliance

• EU AI Act: depends on use. Pure financial-control analytics on invoices and vendors is generally minimal risk (AI literacy, Art. 4). Credit-scoring systems are high-risk under Annex III 5(b) but fraud detection is excluded there [4]. The decisive point is Annex III 4(b): AI intended to monitor and evaluate the performance and behaviour of workers is high-risk [4]. A system that profiles individual employees' behaviour and drives disciplinary action may fall under it, so design as spend-anomaly detection with human decisions, document the intended purpose, and have it assessed legally. Emotion inference or behavioural profiling of staff is not part of this use case (Art. 5 limits apply).
• GDPR: employee expenses, travel and vendor sole-trader data are personal data. Need a legal basis (Art. 6(1)(f) legitimate interest, balancing test), DPIA, transparency to staff, data minimisation and retention limits. Art. 22: no solely automated decisions with significant effect, such as dismissal or withholding reimbursement, without human review. In Germany, works council co-determination (BetrVG section 87(1) no. 6) applies to technical systems that can monitor employees, and section 26 BDSG governs employee data.
• Sector rules: GoBD for traceable, unalterable bookkeeping and archiving; section 14 UStG invoice requirements; fraud-prevention duties under internal control systems (and the German Supply Chain Act, LkSG, for supplier due diligence); public bodies follow Vergaberecht and Haushaltsrecht.
• Risks and mitigations: false accusations (explain flags, let employees respond, human decision), bias against groups or roles (test flag rates by group), model drift (monitor and retrain), data leakage to cloud LLMs (EU region, DPA, pseudonymise employee names before LLM calls), whistleblower identity protection.

Getting started

1. Get legal, data-protection and works-council buy-in first; define purpose, data scope and the human decision process in writing.
2. Run a baseline: duplicate invoices, split purchases below approval limits, top-N outliers per category on 12-24 months of data, using simple rules and PyOD.
3. Add receipt reading (Path A tool or Azure/Docling pipeline) and compare extracted amounts and dates with claims and card feeds.
4. Build a vendor master-data check (shared IBAN, address, tax ID between vendors and employees; bank-detail changes) as the highest-yield procurement control.
5. Pilot a review queue for 2-3 months, log analyst outcomes as labels, keep a random audit sample, then decide whether to add a supervised model.

Sources

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