A Spreadsheet Column Changed Type and Almost Put 146 People Back on the Roster

So this week one of our ingests almost did something really dumb, and I want to walk through it, because the thing that saved us wasn't clever, and every business that moves data between systems should be doing it.

What happened

We keep a roster for a customer with a couple hundred sales reps. It comes from a spreadsheet they maintain, and one of the columns is a quit date. If the quit date is filled in, the rep is departed. If it's blank, they're active. Simple.

Somebody re-saved the sheet, and in the new version the quit date column had been re-typed as text instead of dates. Same values, same numbers, just stored as text. And our reader for that file only knew how to read dates stored as dates. So every quit date came back blank.

Which means every departed rep looked active. When we ran the update, the plan was to flip 146 of 244 departed reps back to active. Nothing in the data was wrong. The sheet was right. The reader was wrong, and the reader was about to rewrite a customer's roster to say people who'd quit months ago were back on the team.

Why we caught it

We caught it because we don't write in bulk without a dry run, and we don't treat a dry run as passing just because it ran clean. It ran clean. It ran perfectly. It was going to reactivate 146 people with no errors at all.

What caught it was reading the delta, meaning the list of what was about to change, and looking at its shape. Real changes to a roster are small and mixed. A few people leave, a couple join, somebody's phone number changes. When a dry run wants to change one field on 60 percent of a population, all in the same direction, that isn't news about the world. It's a parse failure. The world doesn't move like that, but a broken reader does, every time.

So the rule we wrote on the wall is that a mass, one-directional change is a reading error until proven otherwise.

What we did

The fix was not to patch the one column. The fix was to make the date reader accept dates however a spreadsheet might hand them over, as a real date, as a serial number, or as text like 3/14/2026, and then to use that reader on every date column in every file we take in, not just the one that bit us. Because if the quit date column can get re-typed, so can the start date, so can the hire date, and the next one would have hit a column nobody was watching.

And then after the real write, we proved we hadn't forked anything. Row count matches what we expected. No duplicate IDs. One record per person. Because the second dumb thing an ingest can do, right after reactivating 146 people, is create a second copy of every rep under a slightly different key and double the roster.

Why this matters if you're not us

Because you do this too. Every time somebody imports a spreadsheet into the CRM, uploads a customer list into the email tool, or syncs a price sheet into the accounting system, the same thing can happen. A column changes type in Excel and nobody notices because the cells look identical. A date becomes text. A number becomes text with a comma in it. A ZIP code loses its leading zero. And the import runs clean, and the data is now wrong in a way that looks fine for weeks.

So the checklist I'd hand anybody who imports anything:

Never bulk-write without a dry run you actually read. Clean isn't the same as right.

Look at the shape of what's changing. Small and mixed is normal. Big and one-directional is a reader problem.

When the delta looks wrong, compare the two source files, not just the code. The old export against the new one. Encoding changes look exactly like data changes.

Fix the reader for every column of that kind, not just the one that failed.

After writing, count. Rows, duplicates, one ID per record.

The part I actually like about this

I'm honestly glad it happened this way, because it happened in a dry run and not in production, and the discipline that caught it is now the discipline that runs every ingest we do. That's how Liaison treats every file a customer hands it. The dry run is the gate, the delta gets read for its shape before anything is written, and after the write it proves the counts. We wrote back in April about checking things in the right order when two systems disagree, and this is the same idea one step earlier. Before you compare the data, make sure you read it right.

If you've got a sheet that feeds a system and you've never looked at what an import actually changes, that's worth a conversation. The dry run is free.