Tax fraud & audit case selection for tax authorities (incl. VAT carousel fraud)

Tax administrations cannot audit everyone, so they must choose whom to look at. AI-supported risk management scores returns and transactions, links traders into networks and presents auditors with a ranked, explainable worklist, while a random sample keeps the system honest. The prize is a higher hit rate per audit hour and earlier detection of VAT carousel fraud. The pitfall, visible in the Dutch benefits scandal, is opaque or discriminatory profiling.

Problem & value

• Today: Rule-based filters, manual tips and experience select cases. Volumes of returns, e-invoices and cross-border VAT reports far exceed audit capacity. Missing-trader (MTIC) and carousel fraud moves goods and VAT across borders in cycles; one public summary cites Commission estimates of EUR 20 billion to over EUR 100 billion per year depending on method, and a 2018 European Parliament study averaging about EUR 50 billion per year [4]. Treat these as order-of-magnitude figures.
• AI value: better ranking of cases (more additional tax per audit), faster detection of short-lived fraud companies before the VAT refund is paid, and discovery of unknown typologies via anomaly and graph methods. Reported results are mostly self-reported by agencies; benchmark against your own random-audit baseline rather than trusting vendor claims.
• Scope boundary: this entry covers the authority side under fiscal law. A company checking its own ledger is ANOM-006; bank AML is ANOM-002; benefit fraud is ANOM-019; customs declaration scoring is ANOM-021.

Variants

• VAT / MTIC / carousel fraud: transaction network analysis on VAT returns and EC Sales Lists, shared among Member States through Eurofisc, the decentralised network for exchanging targeted VAT-fraud information [3]. Early warning on newly registered traders with high turnover and no substance.
• German risk management system (RMS), section 88(5) AO: automated systems may decide whether further investigation is needed. The law requires random selection of a sufficient number of cases for full manual review, human review of flagged cases, the option for officials to select cases themselves, and regular effectiveness checks; details need not be published if that would endanger equal taxation [1]. This is the legal template for the whole use case.
• Income / corporate tax audit selection: supervised models on prior audit outcomes (compare PRED-028 for generic risk-based inspection selection).
• Undeclared assets from imagery: French DGFiP's "Foncier innovant" detects unreported buildings and swimming pools in aerial images with computer vision and compares them with property tax records (per the research sweep for this catalogue; no figures verified here).
• E-invoicing / e-reporting data (ViDA, national mandates): near-real-time invoice data enables mismatch detection between supplier and buyer declarations.
• Tax and benefit linkage: the tax part belongs here, the benefit part to ANOM-019.

How it works

data sources (returns, VAT, e-invoices, registers, imagery) → data lake with tax-secrecy access control → feature and graph building (entity resolution, trader chains) → models (supervised scoring, anomaly detection, graph analytics) → risk list + reason codes → human case selection and audit → outcome labels → retraining with a parallel random sample → full audit → unbiased evaluation loop.

Key components: - Tabular ML (gradient boosting) trained on audit outcomes. Caveat: only audited cases have labels, so models inherit selection bias; random audits are the antidote and are mandated in the German RMS [1]. - Graph ML / knowledge graph: entity resolution over company, director, address, bank account and invoice relations; community detection and suspicious-cycle patterns for carousels. - Anomaly detection for unknown patterns (Benford-style tests, peer-group deviation). - Computer vision / remote sensing for undeclared assets. - LLM only as assistant: summarising a dossier, extracting facts from unstructured documents, explaining reason codes. It must not decide. - Human-in-the-loop: officials make every assessment, audit and sanction decision; the model proposes where to look. Section 88(1) AO also obliges authorities to consider circumstances favourable to the taxpayer [1], so scores cannot be the sole basis for an adverse act.

Data preparation

Data is the dominant effort here. Sources are the tax authority's assessment systems, VAT returns, EC Sales Lists, e-invoice and e-reporting feeds, register data and audit outcomes, spread across legacy procedures with different keys. For an enterprise screening its own supply chain the sources are ERP vendor master data, invoices, DMS and VAT-ID validation results. Typical gaps: no common taxpayer identifier across systems, duplicate and misspelt company names, audit results stored as free text or paper instead of usable labels, selection bias (past audits only covered what was already suspicious), and strict access rights between tax secrecy domains. Steps: (1) inventory and map data sources and owners, see PREP-001, PREP-002 and PREP-004; (2) extract data from legacy systems, see PREP-005; (3) harmonise entities and define KPI and field glossaries, see PREP-012; (4) harvest labels from audit outcomes and add a random control sample so the model is not trained only on biased selections, see PREP-020 and PREP-018; (5) pseudonymise for development environments, see PREP-022; (6) check purpose limitation, see PREP-025. Tools: ETL (Airbyte, dbt), entity resolution libraries, a graph database such as Neo4j. Expect 50 to 65 percent of the total effort in data preparation. Run the readiness check from GUIDE-003 before scoping the model.

Implementation paths

Which path for whom

• public (C): Tax data is highly sensitive and legally restricted, procurement favours sovereignty, and the core is tabular ML and graph analytics that open-source stacks on own HW2 infrastructure handle well.
• enterprise (B): Large companies (tax departments, Tax-CMS, VAT compliance) use the same methods to screen their own supplier chains and are better served by building on cloud APIs and own ERP data than by authority-grade tooling.
• developer (C): Building a risk-scoring and network-analysis product is done with open-source ML and graph libraries, giving full control over explainability.

Path A — Buy (off-the-shelf)

Fraud/analytics suites for tax and revenue agencies: SAS (tax and revenue analytics), Palantir Foundry (US vendor, sovereignty concerns), IBM, Oracle, plus graph platforms Neo4j and TigerGraph. EU system integrators: Capgemini, Sopra Steria, Atos/Eviden (all France). Germany's tax IT runs through the Länder joint programme (KONSENS), so a commercial product rarely replaces the national stack; it is right for smaller or non-federal administrations that lack a data science team. Verify tax-secrecy and data-localisation terms before any SaaS.

Path B — Build on cloud APIs

Only acceptable for non-personal or pseudonymised development and for the LLM assistant layer, using EU-region offerings (Azure OpenAI EU Data Zone, Mistral La Plateforme (France), Aleph Alpha-style sovereign hosting) under a public-sector contract. Taxpayer-identifiable data generally should not leave the administration's own or sovereign-cloud environment because of tax secrecy. Hence B is a secondary path here.

Path C — Self-host (open source)

Recommended default for authorities. Stack: PostgreSQL / Spark / Trino data lake, XGBoost / LightGBM / scikit-learn for scoring, PyTorch Geometric or NetworkX / Memgraph / Apache AGE for graphs, MLflow for lineage, SHAP for reason codes, Fairlearn for bias audits. For the LLM assistant use open-weight models (Mistral, Qwen, Llama families) via vLLM on in-house GPUs. Tabular and graph work needs a modest server (HW2 is enough); a GPU node is useful for imagery and LLM parts. Main effort is data engineering and governance, not compute.

Path D — Custom training

Core of the use case: the scoring and graph models are always custom-trained on the authority's own audit history. Needs several years of outcome-labelled audits plus an unbiased random sample. Fine-tuning an LLM is rarely worth it. Imagery detection can start from a pretrained segmentation model and be fine-tuned on a few thousand labelled orthophotos.

State of the art (2026)

• Graph-based transaction network analysis (TNA) is the established technique for VAT carousel detection; Eurofisc is the cooperation channel among Member States [3]. Newer work combines graph neural networks with temporal features and heavily relies on e-invoicing data as it becomes mandatory.
• Gradient boosting remains the strongest practical method on tabular audit data; deep models add little without very large data.
• LLMs now help with document extraction, dossier summaries and drafting audit queries; autonomous agents deciding on audits are not appropriate.
• Explainability and fairness testing are now routine requirements; random-audit controls are the best defence against feedback loops.
• Limits and failure modes: label bias from past audit choices, feedback loops (only flagged groups are audited, so they are found guilty more often), concept drift as fraudsters adapt, proxy discrimination, and false positives that burden honest taxpayers. The Dutch childcare-benefit affair, in which the Dutch DPA found unlawful and discriminatory processing of nationality data by the tax administration [5], is the standard cautionary case (note: it concerned benefits, a related domain, see ANOM-019).

Shared resources & combinations

• Building blocks: entity-resolution and graph pipeline (shared with ANOM-002 AML, ANOM-020 procurement collusion, ANOM-021 customs targeting, KNOW-026 investigative analysis); tabular scoring and MLflow/SHAP governance stack (shared with PRED-028 risk-based audit selection, ANOM-006); document parsing for submitted records (DOC family); random-sample evaluation design.
• Hardware: HW2 CPU/memory-heavy server for graph and tabular work; optional single GPU for imagery and open-weight LLM.
• Combinations: ANOM-021 customs data feeds import VAT checks; ANOM-002 suspicious-activity reports may flow to tax authorities under legal gateways; ANOM-019 shares entity data but is a separate, high-risk system.

Effort, cost & KPIs

• A: months to integrate, licence cost dominates. B: weeks for the assistant layer only. C: 6 to 18 months, team of data engineers, data scientists, tax auditors and a data-protection officer. D: same, plus labelling effort.
• Cost drivers: data integration across silos, legal clearance, model governance, audit capacity to act on the output.
• KPIs: additional tax assessed per audit hour versus random baseline; hit rate (share of audits with change); precision at top-k; time to detect a missing trader before refund; share of random-sample cases; false-positive burden on compliant taxpayers; fairness metrics across groups; complaint and appeal outcomes.

People & change

Involve management and the department lead (audit and risk management) from the start, as the model changes who gets audited. IT and IT security build the infrastructure, the DPO must be involved before data is combined (DPIA under Art. 35 GDPR is practically certain: systematic evaluation, large scale; tax secrecy rules apply on top), and legal checks the legal basis for profiling. Works council: yes. A scoring system that is used by auditors and records their handling of cases is objectively suited to monitor behaviour or performance, so co-determination under §87(1) no. 6 BetrVG applies (in authorities the staff council under BPersVG or state law); the council must also be informed in good time about AI-planned work processes under §90(1) no. 3 BetrVG, and may engage an AI expert under §80(3). Agree on a works or service agreement that bans using case statistics for individual performance rating. AI literacy: support auditors with training on reading reason codes and model limits (Art. 4 AI Act, GUIDE-006). Pilot with one audit office and one tax type, keep random control cases, and let auditors override scores and give feedback. The main concern is fairness: publish the selection criteria internally, test for bias per group and keep a human in every audit decision. See GUIDE-004, GUIDE-005 and GUIDE-008.

Risks, regulation & compliance

• EU AI Act: classification depends. Annex III lists law-enforcement uses (point 6) and public-benefit eligibility (point 5(a)) but does not list tax audit selection [2]. Recital 59 states that AI systems specifically intended for administrative proceedings by tax and customs authorities should not be classified as high-risk law-enforcement systems [6]. A system used for criminal-investigation profiling (point 6(e)) or deciding benefits would be high-risk. Authorities should still apply high-risk-grade governance voluntarily. Art. 5 social scoring and prohibited profiling-only crime prediction must be avoided; Art. 50 transparency applies to any chatbot interface. Check the status of the Digital Omnibus changes to AI Act timelines.
• GDPR: taxpayer data is personal data; Art. 22 limits solely automated decisions with legal effect, and national tax law (AO, tax secrecy, section 30 AO) governs processing. A DPIA is required. Do not use protected characteristics or proxies such as nationality; the Dutch case shows the penalty [5].
• Fiscal law: section 88(5) AO conditions (random sample, human review, effectiveness checks) [1]; Eurofisc / administrative-cooperation rules for cross-border data.
• Risks and mitigations: bias (fairness audits, remove proxies), feedback loops (random audits), opacity (reason codes, documentation), gaming (non-public details are permitted under section 88(5) AO [1]), over-reliance (mandatory human review, appeal rights).

Getting started

1. Inventory data sources and legal bases; involve the data-protection officer and tax-secrecy owner before building anything.
2. Build the random-audit sample design first; it gives unbiased labels and legal compliance.
3. Prototype a gradient-boosting scorer with SHAP reason codes on one tax type and compare top-k hit rate against the current selection.
4. Add a graph prototype for VAT chains on historic known fraud cases; validate with auditors.
5. Define governance: model card, fairness tests, monitoring and an appeal path; then pilot with auditors in the loop.

Sources

1. Section 88 AO (Untersuchungsgrundsatz, risk management systems) — https://www.gesetze-im-internet.de/ao_1977/__88.html
2. AI Act Annex III, high-risk systems — https://artificialintelligenceact.eu/annex/3/
3. Eurofisc, EU network against VAT fraud — https://www.eurofisc.eu/
4. Missing trader fraud (definition, size estimates citing Commission 2018 and European Parliament 2018) — https://en.wikipedia.org/wiki/Missing_trader_fraud
5. Dutch childcare benefits scandal (Dutch DPA findings on the tax administration) — https://en.wikipedia.org/wiki/Dutch_childcare_benefits_scandal
6. AI Act Recital 59 (tax and customs administrative proceedings) — https://artificialintelligenceact.eu/recital/59/