Foreign-Currency Order Contamination Found Through Buyer Locale, Not the Currency Column
The obvious column lied. The agent checked a column nobody had looked at and found the real signal.
What was getting in the way.
An operating system of record books every order in whatever currency the buyer paid — but marks every row USD in its currency column, with no flag that distinguishes a real dollar order from a Japanese-yen or Israeli-shekel order recorded at raw foreign amounts. The contamination shows up downstream as a gross-margin "collapse" that isn't real, as revenue months that look inflated, and as COGS figures that are about to tell a client their ROAS target is unachievable. The obvious column where you'd look for the problem — the one labeled "currency" — reads clean on every row. Earlier attempts to find the contamination hit that column and stopped.
Context
Universal — the pattern applies to any system of record where a buyer-identifying field is more trustworthy than the system's own currency flag.
How the work runs.
- 01
Stop trusting the column that already failed
The obvious currency flag reads USD on every row. The agent treats it as evidence that the field is unreliable, not as proof the orders are domestic. A column that killed one investigation isn't the right instrument for the next one.
- 02
Pivot to the buyer, not the money
The agent walks the schema for any field that identifies where the buyer lives — a locale, a ship-to country, a billing-address region — and finds a column that was never part of the historical analysis path. One pass isolates every non-domestic order.
- 03
Prove the match arithmetically
For each isolated locale, the agent computes the ratio of order totals to the comparable domestic baseline. The ratios should land on real foreign-exchange scales — roughly 190 for yen, roughly 3.7 for shekels, roughly 1.7 for Canadian dollars. If the numbers land on known FX rates, the orders are what the agent thinks they are. If they don't, the hypothesis is wrong and the agent says so instead of shipping the exclusion.
- 04
Size the damage before writing a fix
Before anything is excluded from any downstream figure, the agent quantifies what the contamination was doing: how many orders, how many months, how much revenue inflation, how much apparent gross-margin "collapse" dissolves on exclusion. Prior conclusions built on the contaminated figures are retracted on evidence rather than defended.
- 05
Deliver the exclusion as a reusable filter
The query that isolates foreign orders is written into a reusable filter the next downstream job inherits, so the next analysis built on the same source doesn't re-discover the contamination from scratch.
Evidence from the workflow.
Each system has a role.
Intake (the authoritative order history)
ERP / order record of truth
Action (where the reusable filter lives)
Warehouse / analytics layer
Signal (the arithmetic FX verification)
Agent query layer
Record of truth (the filter travels with the schema)
Procedure library
Why this is Coworker.
Takes assignments and reports back. You hand it work, it prepares and returns a result.
- 01
No data is excluded without arithmetic proof that the exclusion criterion identifies the right rows. Exchange-rate ratios are reported to the human reviewer alongside the exclusion, so the test is reproducible. Prior conclusions built on the contaminated figures are retracted explicitly, not quietly superseded.
Impact / Outcomes
A contamination that was reading as a double-digit gross-margin collapse dissolves on exclusion — the "collapse" was arithmetic, not business.
A COGS figure that was about to tell a client an ROAS target was unachievable is replaced with the figure the business was actually running at.
The next analysis built on the same order source inherits the fix as a filter, not as tribal knowledge an operator has to remember.
Find where a workflow like this fits.
Start with the systems, work, constraints, and authority already present in your operation.