Currency mismatches in AP automation: a silent bug class worth asking your vendor about
A threshold check that compares an amount to a limit sounds trivial — until the amount and the limit are in different currencies, and nothing in the code notices.
Some of the most consequential bugs in financial software aren't logic errors — they're unit errors. A number gets compared to another number, the comparison runs cleanly, produces a confident result, and nobody notices anything is wrong, because "9,500 is less than 10,000" is TRUE regardless of which currency either number is actually denominated in. The bug isn't in the math. It's in the assumption that both numbers meant the same thing.
The specific failure mode
A threshold check — "flag this expense if it's above the configured limit" — needs exactly one thing to be correct that's easy to overlook: the limit and the amount being compared must be in the same currency. A limit configured once, in one currency, and then applied uniformly to every document regardless of that document's actual currency will silently misjudge every document not in the original currency. A $9,500 expense compared against a €10,000 limit isn't obviously wrong to look at — the comparison still runs, still returns an answer, and that answer is simply meaningless.
Why this specific bug is so easy to ship
Single-currency systems never surface it — if every document a company processes is in the same currency, the bug is structurally invisible, because the comparison happens to be correct by coincidence, not by design. It only manifests the moment a genuinely multi-currency workload arrives, which is often well after the check was written, tested, and shipped. A test suite written against one currency's data will pass every time, because the bug isn't in the logic being tested — it's in an assumption the tests never challenged.
What actually catches it
The fix isn't more precision in the comparison — it's making the comparison currency-AWARE in the first place: resolving the correct limit for a document's own declared currency before comparing, rather than applying one fixed number regardless of what currency the amount is in. And critically, the FIX needs its own explicit test: one that constructs a document in a non-default currency and confirms it's compared against the correct limit for that currency, not the default one. A test that only exercises the default currency will pass whether or not the underlying bug exists.
Why this matters more in accounting software than almost anywhere else
A currency-mismatch bug in a threshold check doesn't crash, doesn't throw an error, and doesn't show up in a stack trace — it just quietly approves or flags the wrong documents, at whatever rate the mismatch happens to produce. In a domain where a missed flag can mean an unusual expense goes unreviewed, and a false flag means real transactions get needlessly escalated, a silent unit-mismatch bug is one of the more expensive classes of error precisely because nothing about its symptoms looks like a bug.
Where else the same bug class hides
| Location | What a silent mismatch looks like |
|----------|--------------------------------------|
| An expense or spend cap | A foreign-currency amount compared against a same-number-different-unit limit |
| A fraud/anomaly threshold | A flag rate that's quietly wrong for every currency but the default one |
| A duplicate-detection tolerance | A percentage tolerance applied to the raw number regardless of currency |
| A reporting cutoff (e.g., "transactions over $X require review") | The same silent mismatch, one layer downstream in a report instead of a check |
The question worth asking a vendor
Ask specifically whether every dollar/euro/pound threshold in their system is resolved per-document-currency, or whether any of them are a single global number applied uniformly. It's a narrow, specific, answerable question — and a vendor who has to check before answering is a useful signal in itself.
Related reading
- How a document trust score actually works: what passes, what fails, and why
- Serving multi-jurisdiction clients: FR, UK, US practice capacity
FAQ
Is this specific to expense caps, or does it show up elsewhere?
The same class of bug can appear anywhere a fixed number is compared against a financial figure without confirming the units match — a fraud threshold, a duplicate-detection tolerance, a reporting cutoff. Expense caps are simply one of the more common places it surfaces, because expense policies are often configured once and rarely revisited per currency.
Does converting everything to one reference currency solve this?
It can, but it introduces a different dependency: a live, accurate exchange rate at the moment of comparison, which is its own source of complexity and potential staleness. A simpler and often more defensible fix is keeping the threshold itself denominated per currency, so no conversion — and no exchange-rate dependency — is needed at comparison time.
How would a business even notice this bug was happening?
Usually not from the software itself — it typically surfaces during a manual review or an audit, when someone notices a foreign-currency transaction that should have been flagged wasn't, or vice versa. That delayed, indirect discovery is exactly why the fix needs an explicit automated test, not just a code review that happens to catch it once.