You briefed the VP on Q2. A month later the same query returns a different number. Nobody changed the SQL. Nobody touched the warehouse. The vendor changed the past.
In one illustration from our post on the commercial data most likely to be wrong, Q2 net sales read $4.20M as of April 30 and $3.85M as of May 31. Same quarter, different number. The load succeeded both times. Source and target agreed both times. Every deterministic check you run on arrival passed.
Restatement is how syndicated data works
Third-party sales data is part actual, part projection. The vendor backfills gaps with an algorithm, gets better inputs the next month, and reruns it. The data sources reference lists restatement on refresh as the characteristic failure of the IQVIA and ICON/Symphony prescription and prescriber feeds. It is normal behavior, not an error. That is what makes it hard to test.
The pattern has a shape. Many syndicated products revise the most recent months on every refresh while older periods remain fixed. Call the recent months the restatement window and the older months the stable tail. A single rule can’t cover both.
| Period | What the vendor does | Rule that’s wrong | Rule that works |
|---|---|---|---|
| Stable tail (older than the window) | Nothing. These periods are closed. | Ignore change | Exact match to the prior delivery (Aggregate Balance) |
| Restatement window (recent months) | Revises values on every refresh | Forbid change | Shape holds even as values move (Distribution Shift) |
A rule that forbids change fires every week on the window. A rule that ignores change misses a real break in the tail.
How to tell performance from data
Ask one question of every number that moved: did the history move, or only the newest period?
If only the newest week moved and the overlapping periods match what the vendor sent last time, the change is performance. Brief it.
If the overlapping periods moved too, the data changed underneath you. Now ask where. Movement inside the restatement window is expected, so review it and accept it. Movement in the stable tail is a silent rewrite, and it gets flagged before it reshapes a trend line.
You can only ask if you kept the answer. Keep a snapshot of each period exactly as you received it. When the next file lands, diff the overlapping periods against the snapshot. This is the check most teams skip, because extract-to-load reconciliation assumes last month’s history is still last month’s history. In commercial pharma it often isn’t.
The mix tells you when a mapping broke
Some changes are neither performance nor restatement. A sudden swing in the mix of payer types, specialties, or geographies usually means a mapping regression upstream, not a real market movement. An NDC remapped from one market basket to another is the classic case: one product group’s dispense totals jump, another drops by roughly the same amount, and nothing upstream failed. An Aggregate Balance test flags both groups. Then you warn the brand team instead of fielding the complaint.
Two more traps make restatements harder to see. A unit-of-measure change, units one month and packages the next, makes one product show a 10x jump. And vendors love wide files, with periods spread across columns. Those defeat trend logic. Normalize them to long format in your refined layer and test after the normalization.
What to set up
Split the checks the way the data splits. In DataOps TestGen, run Aggregate Balance against the prior delivery on the stable tail only. Point Distribution Shift, which compares two distributions using Jensen-Shannon divergence, at the restated months. Then put Metric Trend tests on the gold metrics.
Give each result a disposition. Confirm it, dismiss it as a reviewed restatement, or mute the test, so a known issue stops reading as fresh noise. That record is what you show when leadership challenges the forecast and asks whether the history moved under you.
The restatement will still arrive. The difference is whether you find it in a test result or in a business review.