case study — data & analytics engineering
Automated Billing Reconciliation
& Anomaly Detection
A rule-based reconciliation engine for high-volume logistics billing: it matches ~99,000 invoices and payments, flags the billing anomalies that quietly erode margin, and ranks every exception by € at risk. Includes an exploratory unsupervised machine-learning extension for anomaly detection.
(50,250 invoices · 48,779 payments)
01 — The problem
Reconciliation is manual, slow, and leaks margin
A logistics operation issues tens of thousands of invoices a month. Matching them to incoming payments is a spreadsheet-driven process, so billing errors slip through: duplicate invoices, wrong rates, misapplied fuel surcharges, short payments, unapplied cash. Each erodes margin or inflates days-sales-outstanding — and at volume, nobody can review them all by hand.
What I built
An end-to-end, one-command pipeline
A synthetic-but-realistic dataset (500 customers, 12 months, ~3% of transactions seeded with six real-world error types as hidden ground truth), a SQL reconciliation core, an Isolation Forest anomaly layer, and a rigorous evaluation of both against that ground truth.
The six anomaly types
Injected at ~3%, held out as ground truth
Rate discrepancy · duplicate invoice · fuel-surcharge error · short/over payment · unapplied cash · overdue. Plus deliberately dirty data — mixed date formats, noisy customer keys, swapped currency labels — so the cleaning stage is genuine.
02 — Approach
Most of the logic lives in SQL; ML closes the gap
Cleaning, exact and fuzzy invoice-to-payment matching, duplicate detection via window functions, and rate-card revalidation are all expressed in SQL. Python handles data generation, the anomaly model, and evaluation.
Data model
Four reference/transaction tables + a hidden ground-truth table
03 — The result
Rules are precise; ML recovers what rules can't see
Because every anomaly was seeded, detection could be measured exactly. Three systems compared against the same ground truth:
Detection performance
Precision / recall / F1 vs. seeded ground truth
| System | Precision | Recall | F1 |
|---|---|---|---|
| Rules only | 99.4% | 83.3% | 0.91 |
| ML only | 18.8% | 19.0% | 0.19 |
| Rules + ML | 53.2% | 93.8% | 0.68 |
Combined lifts recall 83% → 94%. Precision falls because ML adds candidates a reviewer triages in € order — a fuller net, not a cleaner one.
Recall by anomaly type
Where each layer earns its keep
04 — Delivery
Reconciliation Control Tower
The pipeline feeds a two-page Power BI report. Executives see exposure and trend; operations drill into a ranked, filterable exception queue with a model-performance panel — the numbers below are the live pipeline output.
05 — Under the hood
Tooling & reproducibility
SQL
Cleaning, exact + fuzzy matching, window-function duplicate detection, rate-card revalidation, exceptions register.
Python
pandas + Faker generator with a fixed seed; date parsing; orchestration in one script.
scikit-learn (exploratory)
Isolation Forest on per-invoice features: rate deviation, surcharge ratio, payment behaviour, peer z-scores.
Power BI
Two-page Control Tower over the exported exceptions, trend and KPI feeds.
run_pipeline.py
regenerates the data, runs the SQL layer, scores the model, evaluates against ground truth,
and exports the dashboard feeds — deterministically, in ~16 seconds.