When Does a Hardware Project Outgrow a Spreadsheet?

# When a Spreadsheet Stops Being Enough for Hardware BOM Management

A spreadsheet is an excellent tool for a bill of materials.

It is fast, flexible, universally readable, and requires almost no training. Suppliers, EMS providers, and manufacturers are comfortable working with XLSX and CSV files, and large engineering organisations still use spreadsheets for plenty of perfectly valid tasks.

So the useful question is not:

Should we stop using spreadsheets for BOMs?

It is:

At what point does maintaining the relationships between BOMs, components, revisions, and products become harder than maintaining the table itself?

That point usually arrives gradually.

Stage 1 — One board, one person

You have one board and one BOM:

RefDes | Qty | Value | Manufacturer | MPN
R1     | 1   | 10k   | Yageo        | RC0603FR-0710KL
C1-C4  | 4   | 100nF | Murata       | GRM188R71C104KA01D
U1     | 1   |       | STMicro       | STM32G474RET6

It is simple, readable, and sufficient.

There is no engineering reason to make it more complicated.

First friction: none worth acting on.

Stage 2 — Revisions start accumulating

The board evolves.

Files begin to look like this:

main_board_BOM_v2.xlsx
main_board_BOM_v2_final.xlsx
main_board_BOM_revC.xlsx
main_board_BOM_revC_final2.xlsx

The spreadsheet still works perfectly well as a BOM.

What starts to degrade is configuration identity.

It becomes harder to answer confidently:

Which of these files corresponds to the Rev C hardware we actually released?

How to extend this stage without changing tools

Start with the cheap fixes.

Put identifying information inside the BOM itself:

Product: Control Unit
Board: Main Control Board
Hardware revision: C
BOM revision: 3
Release date: 2026-09-14
Status: RELEASED

Do not rely only on the filename.

Use a stable naming convention:

Main_Control_Board_RevA_BOM.xlsx
Main_Control_Board_RevB_BOM.xlsx
Main_Control_Board_RevC_BOM.xlsx

And once a BOM is released, store it somewhere where it will not continue changing by accident.

With reasonable discipline, this model can work for years.

Stage 3 — A second board appears

Now you have:

Main Control Board
Power Board

and both use the same capacitor:

GRM188R71C104KA01D

In one spreadsheet it is a row.

In the other spreadsheet it is another row.

Conceptually, those rows represent the same component. At file level, however, they are independent records.

If you update one BOM, the other file has no inherent way to know anything changed.

That is where one of the important limits of a file-based model begins to appear.

The problem is not that Excel “cannot” have component records

You can build a master component sheet:

Component_ID | Manufacturer | MPN | Description
CAP-000142   | Murata       | GRM188R71C104KA01D | 100nF 16V X7R 0603

and reference it from multiple BOMs using:

• XLOOKUP;
• INDEX/MATCH;
• Power Query;
• macros;
• scripts;
• external connections.

That can work very well.

But at that point you are already building a small data system around the spreadsheet.

The structural issue is not that spreadsheets are incapable of representing relationships.

It is that a BOM row does not inherently share identity with the same component used in another BOM.

That identity has to be created and maintained through additional conventions or tooling.

Stage 4 — More than one person works on the data

With several engineers, coordination becomes another concern.

With local files, it is easy to end up with:

MainBoard_BOM_Alex.xlsx
MainBoard_BOM_Sam.xlsx
MainBoard_BOM_FINAL.xlsx

Two copies diverge, and reconciling them becomes a manual comparison exercise.

Cloud editing solves much of this problem

Google Sheets, Excel Online, SharePoint, and similar tools have improved this stage significantly.

They can provide:

• simultaneous editing;
• history;
• comments;
• author tracking;
• recovery of previous states.

For many small teams, this is enough for a long time.

It would therefore be wrong to say spreadsheets cannot support safe collaboration.

What collaborative editing does not solve by itself is a different question:

What relationship does this component have to every BOM in which it appears?

That is a data-model problem, not a file-locking problem.

Stage 5 — Questions start crossing board boundaries

Eventually someone asks:

Which of our products use the TPS62130RGTR?

With three BOMs, manual searching is reasonable.

With ten, it is still manageable.

With dozens of boards, revisions, and products, the query becomes increasingly awkward.

The important consequence is not simply losing twenty minutes.

It is that some questions stop being asked often enough.

For example:

This component has a PCN. Where do we use it?

or:

We want to replace this regulator. Which designs would be affected?

or:

Do any other boards use this connector?

If the answer depends on opening many files and trusting that every team has written the MPN in exactly the same way, the cost of querying the data grows quickly.

That is where a structural limitation becomes an operational one.

The underlying limits

There are only a few.

1. Component identity

Inside a conventional BOM:

STM32G474RET6

is text in a cell.

In another BOM:

STM32G474RET6

is another piece of text.

Conceptually, they refer to the same component.

But that shared identity exists only because the strings match, or because you have added another layer that links them.

A system based on persistent entities can represent something different:

Component #1842
└── Manufacturer: STMicroelectronics
└── MPN: STM32G474RET6
└── Used in:
    ├── Main Control Board Rev C
    ├── Interface Board Rev B
    └── Test Controller Rev A

That distinction changes the kinds of questions you can ask directly.

2. Relationships between engineering objects

A spreadsheet can absolutely represent:

Board -> Component

using a table.

What it does not usually provide natively is a navigable relationship model where you can move in both directions:

Board → uses → Component
Component → used by → Boards

You can build that behaviour.

But the more you build, the less the spreadsheet is acting as a simple spreadsheet.

3. Version semantics inside the BOM

File history can answer:

What did this XLSX look like yesterday?

That is useful.

It does not necessarily answer cleanly:

Which three BOM lines changed between Rev B and Rev C?

You can solve that with:

• file comparison;
• scripts;
• Power Query;
• macros;
• Git for suitable formats;
• specialised tools.

But row-level engineering diffs are not an inherent property of an ordinary XLSX BOM.

4. Configuration context

A file might be named:

MainBoard_RevC.xlsx

but that alone does not establish:

• which schematic belongs with it;
• which manufacturing package was released alongside it;
• which hardware revision it describes;
• which supporting documents belong to the same configuration.

Folders and naming conventions can maintain that context successfully.

The problem appears when there are enough relationships that maintaining them manually becomes fragile.

Signals the model may be getting too small

There is no universal number of boards after which spreadsheets stop working.

Two complex products may justify structured tooling earlier than twenty simple ones.

Behaviour is a better indicator.

Useful warning signs include:

• you frequently need to search the same component across multiple BOMs;
• a substitution must be applied across several products and you cannot immediately identify which ones;
• different engineers have used different BOM versions while believing theirs was current;
• your master component spreadsheet now needs substantial automation to remain reliable;
• it is becoming difficult to identify which BOM was actually released for a hardware revision;
• changes on one board require manually updating duplicated information elsewhere;
• answering “where is this part used?” requires opening several files;
• you maintain relationships between products, boards, revisions, and BOMs manually.

One signal matters more than the others:

You cannot confidently identify which bill of materials corresponds to the hardware currently being built or shipped.

At that point, the issue is no longer spreadsheet convenience.

It is configuration control.

Do the cheap things first

Changing tools has a cost.

Before doing that, there are several inexpensive improvements that solve a large part of the early-stage problems.

1. Put revision information inside the BOM

Do not depend entirely on filenames.

Include:

• product;
• board;
• hardware revision;
• BOM revision;
• release status;
• release date.

2. Separate data with different purposes

An engineering BOM does not necessarily need to become all of the following at once:

• price history;
• purchasing forecast;
• stock record;
• open-order register;
• obsolescence tracker;
• production log.

Those datasets can be related without turning one spreadsheet into the database for the whole company.

3. Preserve releases

Released BOMs should remain recoverable.

You can achieve that with:

• permissions;
• snapshots;
• release folders;
• SharePoint;
• Drive;
• a repository;
• a document-control system.

The mechanism matters less than preventing a historical release from silently changing.

4. Normalise component identification

At minimum, keep:

Manufacturer
Manufacturer Part Number
Internal Part Number, if used
Description

Do not rely only on descriptions such as:

CAP 100nF 0603

if you need to distinguish approved parts.

5. Decide which source owns each fact

For example:

Approved MPN        → component master
Quantity per board  → BOM
Current price       → purchasing system
Stock               → ERP

This avoids four spreadsheets maintaining four different versions of the same information.

If you migrate, you do not need to migrate everything at once

When a team adopts a more structured system, the instinct is often:

We need to move every product, every BOM, every document, and fifteen years of history.

That is usually unnecessary.

A lower-risk approach is to start with the problem that causes the most repeated work.

Often that is component identity.

Instead of every BOM carrying an independent copy of:

Manufacturer: Texas Instruments
MPN: TPS62130RGTR

you maintain a shared component record that multiple boards reference.

Then:

Where do we use this component?

becomes a direct data question instead of a text search across files.

From there, you can decide whether it is worth structuring:

• BOMs;
• revisions;
• documentation;
• releases;
• change history.

The transition does not have to happen all at once.

Some things should stay in spreadsheets

Structured data does not make spreadsheets obsolete.

They remain excellent for:

• quick cost estimates;
• supplier comparisons;
• temporary analysis;
• engineering calculations;
• imports and exports;
• ad hoc data manipulation;
• what-if modelling.

Moving every temporary calculation into a permanent structured system can make the work worse rather than better.

The goal is not to replace spreadsheets.

It is to identify which information needs persistent identity, relationships, and configuration control, and which information is still best represented as a table.

A practical decision rule

You can continue using spreadsheets quite happily while you can answer these questions quickly and reliably:

1. Which BOM is current for this hardware revision?
2. Where else is this component used?
3. What changed between these two revisions?
4. Which manufacturing package belongs with this BOM?
5. Who can modify released information?

If those answers are fast and trustworthy, you may not need another system.

If they require repeated searching, manual comparison, and knowledge held by particular people, Excel has not suddenly become a bad tool.

The problem has simply stopped being only a table.

XKEMA is intended for that point: representing components, boards, and engineering documentation as related information, while keeping version and baseline context for the supported engineering objects rather than relying only on isolated files and naming conventions.

It does not replace ERP for purchasing or inventory, and it does not make spreadsheets a poor choice for ad hoc analysis. Its value appears when engineering relationships themselves become something the team needs to preserve.

Related reading

• How XKEMA works
• Single source of truth for hardware data
• How to organise hardware engineering documentation