Here's a BOM for a real IoT asset tracker. Seven line items. One of them is a lie.
We'll get to that.
The BOM
This is a top-level BOM for a battery-powered IoT sensor with cellular connectivity and a solar charging input. COTS enclosure, custom PCB, off-the-shelf electronics. Simple product, relatively simple BOM.
| System | Part Name | Description | MPN | Link | QTY | Unit Cost |
|---|---|---|---|---|---|---|
| Electronics | PCBA | Custom main board | — | — | 1 | — |
| Electronics | Battery | LiPo 3.7V battery pack | BL0750F5030481S1PCTC | DigiKey | 1 | $8.99 |
| Electronics | BG95 Module | Cellular + GNSS mini PCIe module | BG95M3LA-MINIPCIE | DigiKey | 1 | $34.25 |
| Electronics | SIM Card | eUICC global SIM | GL1-100 | DigiKey | 1 | $1.50 |
| Electronics | Antenna | Flex PCB LTE antenna, 150mm UFL | YF0028AA | DigiKey | 1 | $1.42 |
| Hardware | Enclosure | COTS, 4.5 × 3.5 × 2.1 in | WC-23F | Polycase | 1 | $18.34 |
| Hardware | Solar Panel | 0.6W 6V ETFE solar panel | P123 | DigiKey | 1 | $9.00 |
Seven rows. Clean, readable, ready to hand off.
Except for that first one.
The Phantom Row
The PCBA line is doing something that looks fine on paper and will absolutely cause you problems later: it's a placeholder. No MPN, no link, no cost. Just "Custom main board."
That's because the PCBA isn't really a single component; it's an entire sub-BOM of its own. Every resistor, capacitor, IC, connector, and test point on that board has a part number, a quantity, a manufacturer, and a supplier. The full component list for this board lives in Eagle, my ECAD tool. It's a separate document, maintained separately, exported separately, and sent to the CM separately, if it gets sent at all.
This is the sub-BOM problem. Your top-level BOM references a thing. That thing contains other things. Those other things live somewhere else. When you go to build your product, someone has to go find all those somewhere-elses and stitch them together into a coherent package.
If that sounds like the setup for a FrankenZip, it's because it is.
When your CM asks for your full build package, you're assembling it from multiple sources: the top-level BOM, the PCBA BOM from your ECAD export, the mechanical BOM from your MCAD tool if you have custom parts, the assembly instructions in a Word doc, maybe a readme that explains which file supersedes which. The documents come together at the last minute, under pressure, and they were never designed to be read together.
Don't be surprised when that monster turns on you and kills your production run.
The honest note about the IoT sensor above: the PCBA sub-BOM in Eagle isn't actively managed. I know what's on the board because I designed it. But if I handed off the top-level BOM to a stranger and said "build this," they'd think I'm incompetent. That's the gap; it's more common than anyone admits.
What Data Actually Goes in a BOM
A BOM is the recipe for your product. The question you're trying to answer with every row is: could a stranger read this and build the thing?
That stranger is your contract manufacturer. They don't know your product, your history, or which version of that file is the latest one. They have what you send them. So send them enough.
Here's what belongs in every line item:
Manufacturer: Not the distributor: the OEM. This matters when you're validating alternates, tracking lifecycle status, or dealing with a shortage and need to find a second source.
Manufacturer Part Number (MPN): The canonical identifier for the part. Not the distributor SKU, not your internal number: the MPN. Two different distributors selling the same component will have different SKUs; the MPN is the thing they have in common.
Quantity: Units needed to build one SKU. One finished unit, fully assembled. Not a pack quantity, not a bulk order: one unit. Scaling to a production run is a separate calculation.
Source / Link: Where you buy it. A DigiKey or Mouser link gets you most of the way there. Include it even if the URL might expire. A dead link with a known MPN is still recoverable; a missing link with no MPN is just a mystery part.
Description: What the part actually is, in plain language. When the link fails, when the MPN gets discontinued, when someone opens this BOM two years from now with no context, the description is what tells them what they're looking at. "RF TXRX MOD CELL NAV MINI PCIE" is technically correct and genuinely useful. "BG95" is not.
Internal Part Number: For a lot of early-stage startups, you don't have one of these yet, and that's fine. Internal part numbers become useful once you're managing a real parts library and need a reference that's independent of any specific manufacturer or revision. If you're running a PLM, this is the field that ties your BOM to the rest of your component data; if you're in a spreadsheet, skip it for now.
Revision / Version (custom parts only): For anything you designed, PCBs, custom machined parts, injection-molded enclosures, you need to know which revision of the design this BOM row refers to. Rev A and Rev B of the same board are not the same component. A BOM that says "PCBA" without a revision number is not a complete BOM.
Nice to Have
These aren't strictly required to hand off a buildable package, but they save real time:
Price: Useful for cost rollups, margin calculations, and quotes. Note whether the price reflects a one-off order or a bulk MOQ; the difference can be significant, and it's easy to forget which one you entered.
Notes: A freeform field worth using. Quick assembly notes, torque specs, orientation callouts, supplier lead time flags: anything that lives in your head and should live in the document instead.
Alternate suppliers: A single-source component is a supply chain risk. If there's a known alternate, document it in the BOM. You'll thank yourself during the next shortage.
The Part You'll Skip (Don't)
Hardware teams at the startup stage tend to treat documentation as something you do after the real work is done. That instinct isn't entirely wrong; in the prototyping phase, moving fast matters more than keeping clean records. Get the thing to work first.
But there's a transition point, and it's easy to miss. The moment you're preparing for a production run, or handing anything to a CM, a supplier, or a new team member, your BOM becomes load-bearing. It's not a reference document anymore; it's the instruction set for building your product. And if it's incomplete, out of date, or scattered across four different files that haven't been reconciled since the last design review, the consequences are real: wrong parts ordered, old revisions built, components going end-of-life with no one catching it in time.
Warning: sales pitch incoming. That's why tools like oroForge exist, not to add documentation overhead, but to give you a single source of truth that's easy enough to maintain that you'll actually maintain it. The goal isn't a perfect BOM on day one; the goal is a BOM that's always current, always complete, and always in one place. So when your CM asks for your latest build package, the answer is a link, not an afternoon of file assembly and a zip file that might be wrong.
Your BOM is only as good as how well you keep it. Start the habit now, before it becomes expensive not to.
If you haven't read Part 2, it covers the specific failure modes, including the FrankenZip in full detail, that show up when spreadsheet-based BOM management hits its limits. Worth a read before your next production run.