Nobody has to make a mistake for a production run to ship broken. An engineer just has to insert a row.
The story below is a composite. The specifics are constructed, not lifted from one company's postmortem, but the mechanism is real, and it shows up in different disguises across hardware teams running a BOM split across linked spreadsheet tabs. If you've ever kept a master parts list in one tab and a kitting or order-quantity sheet in another, you already have the ingredients.
Two Tabs, One Assumption
A startup building a connected device (PCBA plus a mechanical enclosure) keeps its BOM the way most teams do at this stage: a master tab listing every part, and a second tab the buyer uses to generate purchase orders and kit counts for the contract manufacturer. The second tab was built once, months ago, by whoever needed it fastest. It pulls quantities by referencing rows in the master tab, not part numbers. Row 47 in the kitting tab means "row 47 in the master BOM," and for a long time, that's been fine, because nobody's touched the row order.
The Edit That Looks Like Nothing
Ahead of the team's first paid production run, 300 units for early pilot customers, EVT turns up a part that needs to change: a connector revision, a gasket, something small. An engineer opens the master BOM and inserts a new row in the middle of the sheet, grouped near the rest of that subassembly's parts, because that's the sensible place for it. Every row below the insertion shifts down by one.
This is an entirely ordinary edit. Nobody would flag it in a review. Nothing about it looks like the moment a production run goes sideways.
The Tab That Didn't Get the Memo
The kitting tab doesn't know the master BOM changed shape. It still treats row 47 as if it means what it meant last week. It doesn't anymore; the row insertion pushed a different component into that position. There's no error. No cell turns red. The kitting tab still produces a clean-looking table of part numbers and quantities, it's just now paired the wrong quantity to the wrong part, and only for the section of the sheet below where the row went in.
This is the part that makes it dangerous: everything still looks internally consistent. A spreadsheet doesn't track what a part number is supposed to mean. It tracks what happens to be typed into a cell right now.
Built Exactly to Spec
The buyer generates the purchase order and kit list from the misaligned tab, because that's the tab that's always been the source for POs. The contract manufacturer kits and builds to what they were sent. They don't get anything wrong; they build exactly to the document they were handed. The wrong-value component that ends up on a chunk of the boards was never a CM mistake. It was baked into the paperwork before it left the building.
The Boards Come Back Wrong, and So Does the Blame
Units come back from SMT. A meaningful fraction, everything built from the point in the sheet where the row insertion landed onward, fail functional test at power-on. Debug burns several days before anyone traces it past "bad component" to "the BOM told them to install this." The CM pulls their build records and shows they built exactly to spec. That's the moment it becomes clear the file itself was wrong, not the process of using it, and not anyone standing at the bench.
What a Run Like This Actually Costs
Take a representative version of this failure: a 300-unit run where roughly half the units land after the insertion point and carry the misaligned part. Rework and scrap on that fraction, tracing failures, desoldering and replacing the wrong component, retesting, runs into the tens of thousands of dollars in labor and material once you count the debug time before anyone finds the root cause. The bigger cost is usually the schedule: a two- to three-week slip past a committed pilot-customer ship date, which is the kind of delay that costs you more than the rework line item, especially with an early customer deciding whether your team can be trusted with production timelines at all.
None of that shows up as a line item on the BOM. It shows up three weeks later, the same way every other Excel BOM cost does, just from a completely different mechanism than a stale version or a missing update.
A Part Number Is a Position, Not an Identity
This is a different failure mode than the trigger points that tell you it's time to move off spreadsheets. Those are about knowing when a spreadsheet stops being sufficient. This is about what a spreadsheet fundamentally cannot do, no matter how disciplined your team is about versioning: it has no way to say "this identifier refers to this part, permanently, regardless of where it sits in the sheet." Everything is addressed by position. Move the position, and every reference built on top of it moves with it, silently, whether or not that's what anyone intended.
Fixing the Behavior Doesn't Fix the Structure
The instinctive fix is "be more careful when you insert rows." That doesn't scale, and it shouldn't have to. The engineer who inserted the row did nothing wrong; a reasonable edit shouldn't require auditing every downstream tab that might reference it by position.
The actual fix is structural: give every part a permanent identifier that data attaches to, not a row it happens to occupy. Quantities, cost rollups, and PO templates should all reference that identifier, so a part can move, get reordered, or sit next to a newly inserted line without anything downstream losing track of what it's pointing at. It also means what your CM actually built stays traceable to a real part record instead of a row number that meant something different by the time the build ran, and any change to that record shows up as a tracked event with a reason attached, not a silent shift six rows down.
A spreadsheet will never enforce that on its own. See pricing before your next production run finds out the hard way.
