Why manufacturing data needs a matching BOM and PO
As a past Dynamics 365 functional consultant, a lot of my work was related to data. Creating setup data, data migration, and helping troubleshoot bad data was a lot of my job. To make sure that I have some sample data to use for Northwind Kitchens, I’m going to ask Claude Cowork.
Starting with one item before doing all of them
Here was my prompt:
in a separate folder, create 20 purchase orders for materials needed to manufacture for northwind kitchenware. start with one - i want to review the format and layout before you do the other 20.
make sure you use the branding guide.After thinking about it for a second, I added another section:
you know what? make a few bills of materials for products that use these (and other) purchased parts. let me look at one before you create more.The problem: BOMs and POs that don’t actually agree
For my manufacturing items, from a manufacturing company, I need manufacturing items that need to be made and sold, and then also I need bills and material to show which items need to be purchased to make those items. I use Claude Co-Work to create these for me. What you’ll see though is that in reality there can be inconsistency between those two sets of data. I could ask for Claude Co-Work to generate a list of products and then separately a list of bills and material like I did above, and they may come out and not really match. Maybe it’ll be somewhat consistent, but likely there will be some inconsistencies between them. So what I like to do after creating data that should be referencing each other is also run a new prompt that asks to check for inconsistencies and to update the documents to fix those issues.
Running a consistency check
Here’s the prompt I used:
do a consistency check on the boms and purchase orders. check the names, costs, item numbers, etc.Claude found 4 issues
and here’s the response I got:
...The check is done. Here's the summary of what was found across all 5 BOMs and 20 POs:
All prices matched — every unit cost in the BOMs lines up exactly with the PO unit prices. All arithmetic checks out, no unknown part numbers, no duplicate lines within any PO.
4 real issues were flagged:
[HIGH] Wrong product code in BOM-CK-330 — MMW-CI-BODY330 description says "BRW-330 profile" but the product is CK-330. The PO got it right; the BOM needs a correction.
[MEDIUM] Truncated certification on PO-2026-013 — The ESP32 module (SZE-WIFI-ESP32) is spec'd as FCC/IC/CE in the BOM, but PO-013 only says "FCC certified." If you're selling CN-501 in Canada or the EU, that needs to be fixed on future reorders.
[LOW] Firmware version not in BOM (BRW-101) — PO-2026-011 locks the temp control PCB to FW v2.1.0, but the BOM has no firmware version pinned.
[LOW] Firmware version not in BOM (CN-501) — Same issue: PO-2026-012 specifies FW v1.5.0 for the smart PCB, but the BOM doesn't capture it.
The 22 "unordered" items from stock are all Oregon DC internal supply — no POs needed for those, so those are clean.The nice thing about this is you can ask Claude Cowork to fix the issues it found, too.
Here’s some examples if you want to see the output.
If you’re wresting with messy setup data, migration, or BOM/PO mismatches of your own, Claude Cowork is worth looking at before you spend the afternoon cross-checking stuff. If you want help setting this up, let me know at Tapestries Group; I’m happy to walk through it.
Leave a Reply