The $770,000 That Never Existed: Why You Never Default a Missing Exchange Rate to 1

One line of code claimed three quarters of a million dollars of revenue that did not exist. It ran for months. Nothing crashed, nothing logged an error, and every dashboard built on top of it looked healthy.

The line was a fallback. An ingest pipeline was pulling orders from a store selling in more than twenty currencies and normalising everything to dollars for reporting. Where an order carried both its local total and a dollar total, the pipeline derived the exchange rate by dividing one by the other. Sound approach. Rate per order, no external lookup, no stale rate table.

Where the dollar total was missing, the code said: else 1.

Why a default of 1 is not neutral

A missing multiplier defaulted to 1 does not look like an error. It looks like arithmetic.

An order of ¥45,900 was logged as $45,900. A ₩120,000 order became $120,000. The pipeline did not fail on these rows — it processed them confidently, wrote them to the warehouse, and rolled them into the revenue total that everyone read every morning.

Total overstatement when it was finally measured: $770,721 across 2,958 orders.

This is the specific danger of a neutral-looking default. A null is honest — it propagates, breaks a chart, and forces someone to look. A zero at least reads as suspicious. A 1 in the multiplier position is indistinguishable from a correct answer, and it is the value most engineers reach for when they want the code to keep running.

Every default value is a claim about reality. Most of them are never audited, because they were written to avoid a crash, not to be true.

What caught it was not a currency check

Nobody found this by reading the code. It surfaced because the pipeline had one unrelated guard: a sanity gate that compared average order value across markets.

Real markets differ. Purchasing power, product mix, shipping thresholds — a 1.5x to 2x spread in average order value between a store's strongest and weakest market is ordinary.

The gate measured a 5.2x spread, and refused to pass the run.

That gate was not looking for a currency bug. It had no concept of currency. It was looking for a ratio that a real business does not produce. That is the entire value of a sanity gate: it does not need to know which failure mode is coming.

The fix, and why the obvious version is wrong

The repair is to learn a rate per currency from the rows where it was derivable, then apply that to the rows where it was not.

The obvious implementation takes the mean. That is wrong, and wrong in a way that hides itself.

The broken rows already sit at a rate of exactly 1.0. Include them in the average and they drag the mean toward 1 — which is the precise error being repaired. The worse the contamination, the closer the correction moves to no correction at all, and the whole thing still returns a number.

Use the median of the derivable rows, computed per currency, from rows that had a real rate. A median ignores a cluster of 1.0 outliers the same way it ignores any other tail. Then re-run the market spread gate and confirm the ratio has collapsed back into a plausible range.

The defaults that lie

Once you have been burned by one of these, you start seeing them everywhere. Every one of these has shipped in production somewhere this week.

• 1 for a missing multiplier or rate. Silently asserts that two different units are the same unit.
• 0 for a count that is actually unknown. Turns "we have no data for this segment" into "this segment performed terribly", which is a completely different business decision.
• Today's date for a missing timestamp. Every historical record migrates into this week and your cohort analysis dies.
• The largest market for a missing country. Concentrates every unattributed order into your primary geography and inflates the market that already gets the budget.
• 100% for a missing denominator. Any rate calculated against it reports a perfect result.

The pattern is identical in all five: a value chosen so the code does not stop, presented downstream as a measurement.

The protocol

1. Never default a unit-bearing value. Currency, rate, weight, duration, percentage. If it is missing, write null and let it surface.
2. Gate on ratios, not totals. A total can absorb an enormous error without looking odd. A ratio between two segments cannot. Average order value per market, revenue per order, conversion per session, spend per click.
3. Set the gate from what the business does, not from the data. If you calibrate the threshold against the current numbers, you calibrate it around the bug.
4. Learn repairs from clean rows only, using a median. Explicitly exclude the rows you are repairing from the statistic that repairs them.
5. Count the rows you defaulted. Log it every run. 2,958 rows is not an edge case, and the only reason it read like one is that nobody was counting.

The operator's version of this

An unaudited default is the business equivalent of a lift you have never actually loaded to the number on the plan. The number in the log says 140kg. Nobody weighed the bar.

You do not find that out gradually. You find out on the day it matters, under load, and the failure is not proportional to the error.

Numbers that run a business earn one round of adversarial checking before they get to run anything. Not because the engineer was careless — the fallback was written by someone competent, on purpose, to keep a pipeline alive. That is exactly why it survived. Deliberate compromises are the ones that never get revisited.

Find your else 1. There is one in every system that reports money.