1. Freeze the Approved Assembly Revision and Variant

Begin with the assembly that purchasing has been asked to support. Record its identifier, approved design revision and variant, along with the person responsible for that approval. Keep the design release reference separate from the spreadsheet export date. A file saved more recently may contain working changes; its timestamp alone cannot show that those changes belong in the procurement requirement.

Retain an identifiable baseline. Record the source design or released document reference and the version of the exported list. Where several variants share a design, state which population applies. This checklist combines public design-tool documentation with procurement suggestions. Assign approval through your organisation's process.

Altium's BOM Portal documentation illustrates a source-project revision comparison before updating a Managed BOM and the option to save releases before and after an update. That is a software-specific example of keeping change history visible. A controlled spreadsheet can support these checks without a new EDA product.

  • Identify the assembly, revision, variant and approval owner.
  • Record the export date separately from the approved design release.
  • Keep the baseline available for later comparisons.

2. Export the Intended Population and Check Quantity Basis

Review the export configuration before accepting its totals. KiCad's version 9.0 documentation explains that BOM content follows the displayed rows, fields and grouping, with options for schematic scope and DNP handling. DNP and Exclude from BOM are separate attributes in this KiCad example. A selected sheet or filtered view can describe a different population from the assembly purchasing intends to build.

Check do-not-populate and excluded items against the approved variant. Retain their status where needed to explain the design, while distinguishing the components required for the particular build. Do not remove every flagged item without understanding the release, or combine populations from different variants into one unexplained quantity. Preserve the relevant reference designators so engineering can reconcile a row with its intended design positions.

Define the quantity basis explicitly. KiCad documents its quantity field as a count of grouped symbol instances. That design count is different from the purchase quantity for a production release. Keep per-assembly count, approved build quantity and any purchasing allowance in separate fields. Explain an allowance rather than hiding it in the exported count, and leave unconfirmed build quantities unresolved.

  • Confirm the intended sheet or project scope and variant population.
  • Keep reference designators linked to the relevant component rows.
  • Label per-assembly counts, build quantities and allowances separately.

3. Preserve Ordering Codes and Group Only Equivalent Lines

Keep manufacturer, complete manufacturer part number (MPN), internal material reference, reference designators and footprint as separate information. A schematic value describes a design field; it may not identify the approved purchasable item. If the ordering code is missing, record the gap and ask the design owner for it. Preserve suffixes and punctuation without guessing their meaning or replacing them with a shortened family name.

Inspect the fields used to combine rows. KiCad groups symbols when their selected grouping fields match. A grouping based only on value or footprint may therefore hide distinctions important to purchasing. Check that every combined procurement line preserves the approved manufacturer identity, ordering code and relevant population. Similar electrical values or footprints alone are not an engineering decision that two supplied parts are equivalent.

Keep a mapping from the reference-level population to the combined purchasing rows. Altium's documentation separately identifies manufacturer and manufacturer-part-number fields during BOM mapping. Whether you use a tool or a manual table, confirm which column contains the actual ordering code. Proposed alternatives should remain identifiable until the responsible engineer approves their use for the specified design.

  • Check grouping keys against manufacturer, ordering code and variant.
  • Leave unknown codes visible for engineering clarification.
  • Retain the reference-to-procurement-row mapping.

4. Issue a Dated BOM and Explain Revision Changes

Publish a dated list version for the inquiry with the assembly and variant in its identifying information. Compare it with the retained baseline before sending a replacement. Use a change summary that names affected rows and distinguishes added, removed or changed ordering codes, quantity changes and variant changes.

Record who reviewed the changes and which decisions remain pending. An export can contain data before the organisation has approved its use; it is also not a purchase order. Keep unapproved substitutions and unresolved quantities separate from the confirmed requirement. Ask suppliers to reference the list version in their responses so a quote for an earlier population remains distinguishable.

If the requirement changes during quotation, send the revised list with its change summary and identify which earlier version it replaces. Retain both versions and request confirmation of the affected offer scope. Avoid silently editing a circulated file while continuing to compare offers against an outdated quantity or ordering code.

For a BOM-based sourcing review with ICULTRA, share the assembly revision, intended variant, dated list, quantity basis and unresolved code or approval questions. The general RFQ guide covers wider quotation preparation; this checklist helps establish which design data those requests should use.

Sources and further reading

Public EDA documentation supports the tool-specific examples above. The revision, approval and supplier handover checks are preparation suggestions; these documents do not confirm component availability or approve a procurement list.