Bill of materials from a SolidWorks assembly: a structure purchasing actually uses

Every company that designs in SolidWorks and buys from suppliers has met the same spreadsheet: the BOM someone exported, then fixed by hand, then emailed to purchasing, who fixed it again. The next revision starts over. The way out is to build the BOM from data that is already correct in the model.

What purchasing needs from a BOM

Column	Why purchasing needs it	SolidWorks source
Item / level	Find the line on the drawing	BOM item number, structure
Part number	Order and track	Custom property PartNo (or file name)
Revision	Order the right version	Custom property Revision
Description	Human-readable name	Custom property Description
Material	Raw material planning	Material property SW-Material
Finish / coating	Outside processing	Custom property Finish
Make / buy	Who supplies it	Custom property MakeBuy
Supplier part number	Purchased items	Custom property VendorPN
Quantity	How many	Computed

Agree on these names once, and put them in your part and assembly templates so every new file starts with them.

Indented vs. parts-only

Structure your assemblies like your process

The indented BOM mirrors the assembly tree. If a weldment is assembled before it goes into the frame, model it as a sub-assembly (or a weldment part with a cut list) so it appears as one line with its own children. If parts are bought as a kit, group them. A tree that follows the shop’s process produces a BOM the shop recognises.

Weldments and cut lists

For welded frames, the cut list gives purchasing what they actually buy: profile, size, length and quantity. Fill the cut-list properties (description, material, length) consistently and include the cut list on the weldment drawing.

Exporting for ERP

1. Save a BOM table template with your columns in the order your ERP expects.
2. Export to CSV or XLSX from the drawing’s BOM table, or use a macro or PDM export if available.
3. Test the import with one assembly and fix the property, not the spreadsheet, when a field is wrong.

Why do BOMs drift from the model?

Three habits cause most of it:

1. Properties typed in the BOM table instead of the part file. The next export loses them.
2. Configurations without their own properties. A family table with ten sizes exports ten lines with the same description.
3. Purchased parts modeled ad hoc. A bolt drawn by hand in one assembly and taken from the Toolbox in another appears as two different items.

Each one is fixed upstream: properties live in the file, configurations get configuration-specific properties, and purchased parts come from a controlled library.

Configuration-specific properties

When a part file holds several configurations (for example lengths of the same profile), the part number and description usually differ per configuration. Store them as configuration-specific custom properties, not file-level ones. Then the BOM picks the right values for the configuration used in each assembly, and you avoid the classic error of ten different lengths ordered under one part number.

A controlled library for purchased parts

Purchased components (fasteners, bearings, gas springs, motors) should come from one library with properties already filled: manufacturer, manufacturer part number, description, and your internal part number if you have one. Downloaded vendor models often arrive with their own names and no properties; add them once when the model enters the library, not every time it is used.

Make, buy and phantom items

Purchasing needs to know what to buy, and the shop needs to know what to make. Three values in a MakeBuy property cover most cases:

Value	Meaning	Appears in
Make	Manufactured in-house or by a subcontractor from your drawing	Shop BOM, routing
Buy	Purchased finished from a catalogue	Purchasing BOM
Phantom	Grouping only, never stocked (for example a sub-assembly built in the line)	Indented BOM for structure

Phantom assemblies keep the tree readable without creating items your ERP will try to stock.

Checking a BOM before release

Before a BOM goes to purchasing, run three checks: every line has a part number and a description, no part number appears with two different descriptions, and quantities in the parts-only BOM match a manual count of one sub-assembly you know well. The last check catches suppressed components and lightweight-mode surprises that otherwise reach the purchase order.

When an ERP import is the goal

ERPs expect stable item codes, units of measure and sometimes a parent-child structure. Agree with whoever runs the ERP which BOM type they import (single-level per assembly or full multi-level), which unit each item uses (each, metres, kilograms), and what happens when an item is new. Writing those three answers down usually removes most of the import errors before any automation is built.

Units of measure for raw material

Profiles, tubes, cables and hoses are bought by length, plates by area or weight, and fasteners by piece. If the BOM says “1” for a tube that purchasing buys in 6-metre bars, someone has to translate it on every order. Add a unit-of-measure property and a quantity expressed in that unit (for weldments, the cut-list length times quantity), so the purchasing BOM reads “4.8 m of 40×40×3 tube” instead of “4 pieces”. Purchasing can then decide how many bars to order and the shop knows the cut lengths.

The rule that saves the most time

Do not edit the exported BOM. If a description, material or quantity is wrong, fix it in the model and export again. The spreadsheet is a report, not the source.