From SOLIDWORKS Assembly to Purchase Order in Under an Hour: A Practical Workflow for Small Engineering Teams

It is Friday at 4:45 PM. A mechanical engineer has just finished the last sub-assembly of a fixture for a customer pilot. The release date in the project plan is Monday morning, which means procurement needs a clean parts list, vendor data, and approved drawings before the week starts.

What actually happens over the weekend in many small teams looks less clean. The BOM gets exported to Excel, then edited by hand. Custom properties are missing for half the purchased parts. Two engineers send updated versions to procurement, both named `BOM_final_v2.xlsx`. By Monday, the buyer has three different part counts and no idea which file to trust.

In our observation working with engineering teams of 5 to 50 people, this exact pattern repeats almost weekly. It is rarely caused by sloppy engineering. It is caused by a missing pipeline between CAD and procurement.

This article walks through a practical 5-stage workflow that takes a SOLIDWORKS assembly to a purchase order in under an hour. It is written for small teams that do not have a full enterprise PLM, do not want one, and still need engineering and procurement to stop chasing each other every Friday afternoon.

Key Takeaways

• A repeatable CAD-to-PO workflow has five stages: assembly prep, BOM extraction, vendor and cost enrichment, planning BOM and derivative files, and PO creation
• Most delays happen in stages 1 and 3, not in the CAD work itself
• A typical small team spends 3 to 5 hours per release doing this manually, and around 45 to 60 minutes when the pipeline is automated
• The single biggest source of errors is missing or inconsistent SOLIDWORKS custom properties
• Cloud BOM tools eliminate the "which file is current" problem because everyone reads the same record

The 5-Stage Workflow at a Glance

Here is the pipeline most well-organized small teams converge on, regardless of the specific software they use.

Each stage has a clear input and a clear output. If a stage is fuzzy, the whole pipeline breaks. Below, each stage is broken down by what you are trying to accomplish, common pitfalls, practical tips, and a realistic time estimate.

Stage 1: Prepare the SOLIDWORKS Assembly

Goal: Hand off a clean, predictable assembly that a downstream tool can read without manual cleanup.

This stage is the cheapest place to fix problems and the most common place to ignore them. Five minutes of discipline here saves an hour later.

Common pitfalls:

1. Inconsistent custom property names. Half the parts use `Vendor`, the other half use `Supplier`.
2. Suppressed components left in the assembly that should not appear on the BOM.
3. Reference geometry, sketches, and dummy parts that pollute the export.
4. Configurations that include or exclude components without anyone documenting which one is "the BOM config".
5. Library parts with default file names like `Part1.SLDPRT` instead of real part numbers.

Practical tips:

• Maintain a single property template for every part and assembly. The minimum fields are Part Number, Description, Material, Vendor, Manufacturer Part Number, and Unit of Measure.
• Use a "Production" configuration as the official BOM source. Everything outside that configuration is engineering scratch.
• Mark purchased parts explicitly. A `Part Type` property with values like `Make`, `Buy`, or `Standard` makes the downstream split obvious.
• Use a SOLIDWORKS design checker or task scheduler to flag missing properties before release. There is a detailed walkthrough of how to configure properties and templates in a SOLIDWORKS project that is worth bookmarking if you are setting this up for the first time.

Time estimate: 5 to 10 minutes if the templates are in place. 30 to 60 minutes if you are cleaning up legacy data each time.

Stage 2: Extract a Multi-Level BOM

Goal: Turn the assembly tree into a structured BOM with the right level of detail for procurement.

A BOM is not just a flat list. For anything with sub-assemblies, the multi-level structure carries critical information: which parts roll up into which sub-assembly, what is purchased complete versus assembled in-house, and how quantities propagate.

What to include:

• All purchased parts and raw materials, regardless of level
• Sub-assembly headers if procurement needs to track them separately
• Standard hardware with manufacturer part numbers (not "M4x10 SHCS" with no source)

What to exclude:

• Reference parts and tooling
• Internal mate references and skeleton sketches
• Anything in a suppressed configuration

Common pitfalls:

• Flattening a multi-level BOM too early. You lose traceability and rollups.
• Manually re-typing quantities into Excel. Every manual transcription is a future bug.
• Sending only the top-level BOM and assuming procurement will figure out sub-assemblies.

Practical tips:

• Decide upfront whether procurement needs the indented (multi-level) BOM or a flattened "as-purchased" list. Many teams need both, generated from the same source.
• If your team is moving from spreadsheets to a structured BOM tool, the approach described in multi-level BOM import from a single spreadsheet is a low-risk way to migrate.
• Some teams use a dedicated OpenBOM integration for SOLIDWORKS to handle stages 2 through 4 in one pipeline, pulling the multi-level structure directly from the assembly into a shared, browser-accessible BOM. This is one option among several. The point is to avoid the manual export-edit-email loop.

Time estimate: 2 to 5 minutes with a CAD-integrated extractor. 30 to 90 minutes if exporting to Excel and cleaning up by hand.

Stage 3: Enrich with Vendor and Cost Data

Goal: Attach the procurement-side information to each line item so the buyer is not starting from a blank sheet.

This is where the handoff between engineering and procurement actually happens. Engineering knows what the part is. Procurement knows where it comes from, what it costs, and how long it takes.

Data you need per purchased line:

• Preferred vendor
• Manufacturer part number (often different from internal part number)
• Unit cost and currency
• Minimum order quantity
• Lead time
• Last-purchase date and price (very useful for cost trends)

Common pitfalls:

• Cost data lives only in procurement's head or in a buyer's private spreadsheet
• Single-source assumptions baked into the BOM, with no backup vendor noted
• Old prices that have not been refreshed in 18 months
• No rollup, so the engineering team has no idea what the assembly actually costs

Practical tips:

• Maintain a vendor catalog as a separate database, not as columns in the assembly BOM. The BOM should reference the catalog, not duplicate it.
• Calculate rolled-up cost at every sub-assembly level. If a sub-assembly suddenly costs 40 percent more this release, somebody should know before the PO is cut.
• Track at least two vendors per critical part. The recent supply chain disruptions taught everyone this lesson the hard way.
• For a deeper look at how vendor data, RFQ cycles, and cost rollups interact, the breakdown in how OpenBOM connects CAD to purchase orders gives a good reference architecture even if you are using a different tool.

Time estimate: 10 to 20 minutes when the vendor catalog is current. 1 to 3 hours when cost data has to be reconstructed from old emails.

Stage 4: Generate Planning BOM and Derivative Files

Goal: Produce the actual release package: the BOM that procurement will buy from, plus PDFs, STEP files, and DWGs that vendors and machine shops need.

The planning BOM is the version that gets released. It is no longer engineering's working copy. It has quantities adjusted for the production order, sometimes scrap allowances added, and it is locked against further changes without a formal ECO.

Derivative files vendors typically need:

• PDF drawings for fabricated parts, with title block, revision, and tolerances
• STEP files for machine shops doing CNC programming
• DWG files for laser cutting and waterjet vendors
• BOM as CSV or PDF for the procurement record

Common pitfalls:

• Releasing a BOM without locking the corresponding CAD revisions
• Sending vendors a STEP file that does not match the drawing revision
• No clear marking of which revision a PO line refers to
• Generating derivatives one at a time, by hand, for 80 parts

Practical tips:

• Automate the derivative generation. SOLIDWORKS Task Scheduler can batch-export PDFs and STEPs. Several CAD-connected BOM tools can trigger this from the BOM release action.
• Tie every derivative file to the BOM line. The buyer should be able to click a part on the BOM and download the matching PDF.
• Use a revision scheme that is consistent across CAD and BOM. If the CAD is at Rev B, the BOM line should show Rev B, and the PDF in the package should show Rev B.

Time estimate: 10 to 15 minutes for a 50-part assembly with automation. 1 to 2 hours done manually.

Stage 5: Create the Purchase Orders

Goal: Convert approved BOM lines into actual purchase orders, grouped by vendor, with the right files attached.

This stage looks like procurement's job, but it depends entirely on how clean the previous four stages were.

Common pitfalls:

• One PO per part instead of one PO per vendor. The buyer ends up creating 30 POs for 5 vendors.
• Missing attachments. The vendor gets a PO with no drawing.
• No link back to the BOM. When the part arrives and gets inspected, nobody knows which revision was ordered.
• Manual re-typing from BOM to PO into the accounting system.

Practical tips:

• Group BOM lines by vendor first, then create one PO per vendor with all relevant lines bundled.
• Attach the released drawing (PDF) and STEP file directly to each PO line.
• Keep a back-link from the PO to the BOM revision it came from. This pays off six months later when an inspection question comes up.
• For teams that want the full chain documented end-to-end, the breakdown in an integrated CAD-to-purchase process for seamless procurement shows what a connected pipeline looks like in practice.

Time estimate: 5 to 15 minutes per vendor with a generation step. 30 to 60 minutes per vendor when done manually in accounting software.

Tools You'll Need

You do not need an enterprise PLM to run this pipeline. A small team can get there with four building blocks.

1. CAD with strong property management. SOLIDWORKS already covers this, assuming you commit to property templates.
2. A BOM management layer that reads CAD directly. This is the make-or-break component. Spreadsheets do not scale past one engineer.
3. A file management layer for derivatives. Network drives work. Cloud storage works better when vendors need links.
4. A procurement output, either as POs generated from the BOM tool or as a clean export into your accounting system.

For the BOM management layer specifically, the relevant question is whether the tool plugs into SOLIDWORKS natively. A tool that requires manual exports defeats the purpose. A list of CAD integrations across SOLIDWORKS, Onshape, Fusion 360, Inventor, and PCB design tools is a useful reference when evaluating options, especially if your team uses more than one CAD system.

Real-World Time Breakdown

Here is a comparison of how long each stage takes for a representative 50-part assembly with two sub-assembly levels.

The savings are not the headline number. The headline is that the workflow becomes repeatable. The same engineer can do it again next Friday with the same result, and a second engineer can do it the same way without retraining.

What Can Go Wrong: 5 Common Mistakes

Even with the pipeline in place, a few patterns cause most of the failures.

1. Skipping Stage 1 because "this assembly is small." Small assemblies become subassemblies of bigger ones. The missing properties propagate.
2. Letting engineers edit the BOM after release. Once the BOM is released, changes go through an ECO. No exceptions. Everything else creates ambiguity about which revision was bought.
3. Treating the vendor catalog as a list of vendors, not a list of catalog parts. The catalog should be at the part level: part number, vendor, price, lead time, MOQ. A list of vendor names is not useful for rollups.
4. No revision discipline in derivative files. Drawing PDFs without revision callouts in the file name cause weeks of confusion downstream.
5. No back-link from PO to BOM. This breaks every audit and every quality investigation. It is also the cheapest thing to fix: just include the BOM revision and line number in the PO.

Setting Up Your Pipeline

If your team is just starting to formalize this workflow, the order of operations matters.

1. Fix property templates first. Nothing else works without consistent custom properties.
2. Choose a BOM tool that reads SOLIDWORKS directly. Manual export workflows fail under deadline pressure.
3. Build the vendor catalog as a separate, shared dataset.
4. Automate derivative generation. This is high-effort to set up and high-value forever after.
5. Get procurement and engineering aligned on a single BOM revision scheme before anyone cuts a PO.

The teams that get from SOLIDWORKS assembly to purchase order in under an hour are not faster engineers. They are teams that built the pipeline once and stopped reinventing it every Friday.

If you are evaluating where to start, the easiest wins are in Stage 1 (templates) and Stage 2 (extraction). Both are bounded problems with clear outcomes, and both unblock everything downstream.