The examples and architectures in this series are my personal educational, non-commercial experiments; they are not an offer of IT or consulting services.
Nobody notices a payment that looks like the previous forty. That is exactly what makes the forty-first interesting.
The week below is a composite built from patterns I've seen repeat across finance teams over the years. The suppliers, amounts and signals are made up; they don't describe a specific company, supplier, or incident.
Forty-two payments, one that looks different
You can't see odd without knowing normal
A single limit, say "anything above €10,000", sees the same thing in every supplier: a number. But €10,000 is routine for one supplier and enormous for another. What stands out is a payment that differs from that supplier's own history.
| Supplier (made up) | Usual amount | Usual day | Known accounts |
|---|---|---|---|
| Raw materials | ≈ €18,300 | Tue | 1 |
| Freight carrier | ≈ €2,850 | Thu | 1 |
| Maintenance contractor | ≈ €4,200 | Tue | 1 |
| Software platform | €2,400 (fixed) | Tue | 1 |
| Courier services | ≈ €415 | Thu | 1 |
| Insurance broker | €5,200 (fixed) | Thu | 1 |
The one that stood out
| Signal | Usual for this supplier | This payment |
|---|---|---|
| Amount | ≈ €4,200 | €14,400 (3.4×) |
| Account | The one used before | A new one |
| Day | Tuesday | Friday |
None of the three is damning on its own. A supplier can send a larger invoice, change banks, and ask for a Friday payment. Together they are worth a phone call to a number you already have.
Most odd payments are mistakes
| What it looks like | What's actually true |
|---|---|
| A payment check is for catching fraud | In many teams I've seen, most unusual payments turn out to be mistakes: a duplicate, a typo in an amount, a wrong date |
| One limit for every supplier is enough | One limit is too high for small suppliers and too low for large ones. Each supplier's own history is the better yardstick |
| An alert should be rare | An alert that fires every day is just a very expensive calendar |
| More sensitive is safer | More sensitive means more false alarms, and Post #8 showed what comes next: people stop reading them |
Too tight, too loose, about right
The tolerance is a decision, not a setting. On this composite week, a tight band flags nine payments, a loose band flags none (the odd one included), and the band in the middle flags exactly one.
| Band | Payments flagged | What happens |
|---|---|---|
| Too tight | 9 | Eight false alarms, and people stop reading them |
| Too loose | 0 | The odd payment passes unseen |
| About right | 1 | One phone call |
Illustrative composite from Post #16. The supplier, amounts and weeks are made-up sample data and do not describe a specific company, supplier or incident.
An alert is only as good as the normal it is compared with.
What a check like this has to contain
| Part | What it does |
|---|---|
| A baseline per supplier | The usual amount and spread, the usual weekday and the known accounts, from the last several months |
| A tolerance | How far from usual counts as unusual, tuned on past weeks rather than guessed |
| Reasons | Every flag says why, in plain words |
| A human step | The check only reports. A person decides what to do |
I put together a small script that does exactly this against made-up payments: it builds each supplier's baseline from the earlier weeks, checks one week against it and prints what looks different, with the reason. It only reads and reports, and it is no substitute for the controls your organisation already has. It's in the same personal, non-commercial repository as the earlier demos in this series.
There's a small prototype for this
anomaly_watch_agent.py reads a CSV of payments and prints the ones that don't look like their own supplier's history, with the reason, using sample data.
The first test I'd run is a simple one: take last month's payments, sort them by how far each is from its own supplier's history, and read the top ten. Count how many are mistakes, how many are explained, and how many deserve a call.
Follow the series
Post #17 looks at a different blind spot: the margin on a single product or customer, and how it can turn negative without anyone seeing it in the monthly average.