Your dashboards look fine. Your pipelines ran green overnight. Your team shipped the release on schedule. And somewhere inside your data, a crime is already in progress.
Four data quality disasters reached the public record in 2026, and each followed the same pattern. Two numbers that had to agree were never compared. The reports got signed. The invoices got sent. The gates opened and closed. By the time anyone noticed, the damage was measured in a shuttered hospital, 22,000 repayment demands, and a city’s books off by $1.45 million.
Bad data is not a nuisance you clean up on Friday afternoon. It closes emergency rooms. It sends repayment demands to students who did nothing wrong. It leaves a mayor looking at books that lie by seven figures. When you skip data testing, you are not saving time. You are handing the business a loaded gun and hoping nobody pulls the trigger.
What makes these cases infuriating is that none of them were exotic. No zero-day exploit. No unprecedented technical challenge. Every one would have been caught by the kind of basic data testing that has existed for twenty years, and that you can now run for free. Here are the case files.
Case File 01: The Phantom Billing (West Suburban Medical Center)
Setting: Oak Park, Illinois.
In early 2025, West Suburban Medical Center moved to a new electronic medical record system. According to hospital leadership, it never billed correctly. Doctors saw patients, nurses ran tests, and the surgery suites stayed busy. At least half of that work never made it onto a bill, and the hospital spent the year running on roughly 10 to 15 percent of its normal income, as reported by Crain’s Chicago Business.
On 25 March 2026 the hospital paused all patient care: emergency room, inpatient units, clinics. It ran out of cash to make payroll. A community lost its hospital for months while owner Resilience Healthcare put roughly 120 people on the job of processing more than 120,000 backlogged claims.
One caveat that matters, and that the fix has to account for. The software vendor, Altera Digital Health, publicly disputed that its system caused the closure. That is the argument you get when nobody can point at a test result: the hospital blames the software, the software company blames the implementation, and neither side has a dated record of the two numbers failing to match.
That record is cheap to keep. Count the clinical services delivered. Count the billing output. Run an aggregate balance test between them every night, and a divergence rings an alarm on day one instead of day 365. Whoever turns out to be at fault, the argument lasts a day rather than a year.
Case File 02: The Weekend Heist (Office for Students and the Student Loans Company)
Setting: United Kingdom.
Fifteen universities classified full-time weekend-only courses as in-attendance. Under the rules, weekend-only students count as distance learners no matter where they physically study, and distance learners are not eligible for maintenance loans. The classification was wrong, nothing checked it, and the money went out.
The Office for Students put the scale at roughly 22,000 students receiving up to £190 million in payments they were not entitled to. The Department for Education first directed the Student Loans Company to recover the money immediately. After a campaign by the National Union of Students, it reversed that in April 2026: affected students repay through the normal income-contingent system instead of facing an immediate bill, and childcare grant recovery was paused. The House of Commons Library briefing has the full sequence.
The reprieve is real and it matters to the students. It does not make the data error go away. Around 22,000 people had their finances rewritten by a field nobody validated, and the funding stops going forward.
This is an open-and-shut case for a custom condition test. If study pattern equals weekend-only, then maintenance loan eligibility must be false. One rule. One test. Failing records rejected at submission rather than discovered two years later.
Case File 03: The Transit Trap (Clipper 2.0)
Setting: The San Francisco Bay Area.
Clipper 2.0 launched on 10 December 2025, replacing the fare system for every transit agency in the region. Card data did not survive the trip. Balances came out wrong. Passes vanished. Riders got charged incorrect fares, and ticket vending machines took money without crediting accounts.
The volume tells you how bad it was. Between 10 December and 15 January the customer service center fielded about 47,000 calls to agents, nearly four times what it was contracted to handle, with hold times reaching 100 minutes. Months later the contractor, Cubic Transportation Systems, was still doing manual cleanup of card data that failed to migrate, and three separate outages hit in March 2026, one lasting more than 12 hours.
Here is the part that should stop you cold. Internal emails obtained by KQED show the two sides arguing about testing: transit agency leaders had complained for months that Cubic could not resolve persistent errors, while Cubic staff said the MTC had not authorized enough testing. Testing was a line item somebody was deciding whether to fund, on a migration carrying 15 million riders’ money.
Never trust a migration without a mirror. Reference match tests compare the old database to the new one key by key. Aggregate balance tests compare the sums. Run both against real production data before cutover finishes, and missing funds fail a test instead of stranding a rider at a gate. You do not ship a migration. You prove it.
Case File 04: The Ghost Millions (City of Mechanicville)
Setting: Mechanicville, New York.
The city’s accounting records did not match the cash on hand. The New York State Comptroller reviewed four months of bank reconciliations from a 33-month window running January 2022 through September 2024 and found discrepancies totalling $1,451,933. That is audit 2025M-78, released 3 April 2026.
The audit is blunt about the mechanism. The former finance commissioner did not keep accounting records current or accurate, and city officials did not oversee financial operations. Municipal leaders made decisions on numbers that were fiction. A companion audit found 34 percent of sampled purchases did not comply with the city’s own procurement policy.
Four months of reconciliations produced a $1.45 million gap. Nobody had to go looking for it in a subtle place. It was sitting in the difference between two numbers that anybody could have subtracted, and the test is exactly that subtraction: an automated aggregate balance check matching the city’s books to bank data, plus a custom condition test requiring accounting balances to sum to zero. When the math does not add up, the test fails before the mayor ever sees the report.
The case that never reaches the record
The four above made the news because a hospital closed, a government had to answer questions, a call center melted, and an auditor published. Most data failures never get that far, which is why the most common one is not in the case files.
Consider the shape of it, because you have probably shipped it. A scheduled job aggregates daily usage in UTC. The dashboard it feeds is labelled in local time. Every “yesterday” number covers a window that cuts off before the afternoon, so the figures come out slightly low. Plausibly low. Nothing to flag. The error surfaces in a quarterly review, weeks of reports later, when somebody senior asks why a segment fell off a cliff.
No regulator investigates that one. It costs you a forecast, a renewal conversation, and a chunk of your credibility, and it is invisible to every schema check you own. A volume anomaly test catches it on day two, because the daily row count for that segment drops out of its normal range and stays there.
Don’t wait for the crime to happen
Every one of these happened because nobody was comparing two numbers that had to agree. The dashboards were fine. The pipelines ran. The reports were generated. And inside the numbers, the crime was already in progress.
You do not need a bigger data team to prevent any of it. You need three things running continuously against your data. Automated data profiling tells you what your data actually looks like, not what you think it looks like. Generated accuracy tests flag the values that break the rules, including the rules you forgot you had. Anomaly monitoring catches the drift, drops, and spikes the moment they appear.
Great data teams do not fix broken dashboards. They interrogate the data before it ever reaches the business. Arm your precinct.
TIP
You want to fix this? Try TestGen.
TestGen is the free, open-source data quality tool that DataKitchen built to do exactly the detective work these case files called for. Point it at a database connection. It profiles every column, generates accuracy tests from what it finds, and runs anomaly monitors on a schedule you set. Aggregate balance, reference match, custom condition, volume, freshness, schema drift. All the test types named in the case files above are in the box.
51 profiling characteristics. 48 test types. No per-table pricing. No seat tax on your analysts. It runs in your environment, against your data, without sending anything to us.
Install Open Source TestGen. Run it against one database tonight. See what it finds.
FAQ
What are the key points in this blog?
Four data quality failures reached the public record in 2026: a hospital that could not bill a year of care, 22,000 UK students issued loans they were not eligible for, a transit fare migration that lost card data, and a city whose books were off by $1,451,933. Each was a reconciliation or classification failure, not a novel technical problem, and each maps to a test type that has existed for twenty years.
What caused West Suburban Medical Center to pause patient care in 2026?
Hospital leadership said a new electronic medical record system installed in early 2025 never billed correctly, leaving at least half its clinical work unbilled and the hospital running on 10 to 15 percent of normal revenue. It paused emergency, inpatient, and clinic services on 25 March 2026. The software vendor publicly disputed that its system caused the closure.
What is an aggregate balance test?
An aggregate balance test checks that a rollup still ties to the detail it came from, per grouping, on every run. Count or sum the source records, count or sum the output, and fail the run when the two diverge. It is the test that catches billed services not matching delivered services, or a general ledger not matching the bank, on day one rather than day 365.
How did 22,000 UK students receive maintenance loans they were not eligible for?
Fifteen universities classified full-time weekend-only courses as in-attendance rather than distance learning. Weekend-only students count as distance learners and are not eligible for maintenance loans, so the classification error let up to £190 million in payments through. One row-level rule, enforced as a test, would have failed every affected record before payment.
What data tests should run after a system migration?
Reference match and aggregate balance tests, comparing the old system to the new one before cutover completes. Reference match confirms every value or key in the source exists in the target. Aggregate balance confirms the sums agree per grouping. Run both on real production data, not a sample, and treat a failure as a reason to hold the cutover rather than a ticket to file afterwards.
Why do reconciliation failures stay undetected for months?
Because nothing visibly breaks. Pipelines run green, dashboards render, and reports get signed, since each system is internally consistent and only disagrees with a system nobody is comparing it to. The failure surfaces when an outside party notices, which in these four cases meant a payroll shortfall, a government review, a call center, and a state audit.
