A BOM risk report should help an OEM decide whether a PCBA build can proceed, what must be resolved first, and who has authority to approve each exception. It should not be a colored spreadsheet that lists distributor stock without connecting the observation to a controlled BOM revision, an engineering decision, or a production release. When the report is designed as a decision record, procurement can see the supply issue, engineering can see the product impact, quality can define the evidence, and the manufacturing team can use the approved outcome.
This article gives a practical BOM risk report example for that purpose. It focuses on report structure and closure fields rather than predicting a universal lead time or assigning a permanent risk label to any component. The report should preserve what was known on the review date, identify what remains uncertain, and state what evidence is required before material commitment. That boundary matters because lifecycle status, channel availability, project demand, and design approval answer different questions.
Before starting the report, confirm that the source BOM itself is usable. A risk table cannot repair missing manufacturer part numbers, unclear DNP lines, conflicting revisions, or incomplete package information. The buyer can use this guide on improving PCBA quote BOM accuracy before ordering to close those input gaps first.
Define the BOM risk report scope before component review
The report must identify the exact BOM, PCB revision, build stage, and review date. Every report needs a controlled header that tells the reader exactly which build was reviewed. At minimum, record the project identifier, BOM revision and date, PCB revision, assembly drawing revision, planned quantity, build stage, target material-commitment date, report owner, and review timestamp. If approved-source or restricted-source rules exist, identify their current revision as well. These fields prevent an observation made for a prototype from being reused as though it automatically applies to a pilot or mass-production order.
Lock the product and build context
The same component can carry different project consequences in different builds. A part used once on a prototype may permit a temporary engineering evaluation, while the same part used at high quantity across several products may require a broader supply and design decision. The report therefore needs context, context beyond the part number.
Record the per-board quantity, total required quantity, expected attrition or service demand if the OEM has approved it, build location, and any fixed qualification or customer constraints. Do not invent an attrition allowance or planning horizon in the report. If the buyer has not supplied one, mark it as an open input and show how that uncertainty limits the recommendation.
The header should also identify the source files used in the review. If the BOM, AVL, Gerber, pick-and-place file, schematic, and test package do not carry aligned revisions, the first report item is a data-control issue. It is unsafe to investigate a component against one revision and then release material against another.
Separate report date from evidence date
A report may be issued today while some evidence was checked earlier. Keep both dates. The report date identifies the controlled review; the evidence date shows when a manufacturer page, notification, authorized-channel record, data sheet, or internal approval was last confirmed. This distinction makes aging evidence visible.
Availability should always be treated as a dated observation. A quantity displayed by a channel is not a permanent supply guarantee, and a previous quotation does not prove that the same lot, price, traceability package, or delivery condition remains available. The report should state when a recheck is required, especially before a purchase order, a repeat build, or a delayed material commitment.
Give every BOM risk report line decision-ready fields
Each meaningful risk needs evidence, project impact, an owner, and a closure condition. A useful risk line answers six questions: what item is affected, what was observed, what evidence supports it, how the project may be affected, who must decide, and what closes the issue. If one of these questions is missing, the next meeting often repeats the same investigation.
The table below is a reusable field structure. It can be implemented in a spreadsheet, database, MES-linked workflow, or controlled project form, but the information relationships should remain visible.
Field group
Required content
Why the buyer needs it
Item identity
BOM line, manufacturer, full MPN, reference designators, package, per-board quantity, approved-source status
Prevents a finding from being applied to the wrong orderable part or board location.
Controlled context
BOM, PCB and AVL revision; build stage; planned quantity; report and evidence dates
Defines where the observation applies and when it must be refreshed.
Observed condition
Lifecycle label, PCN/EOL notice, source limitation, data mismatch, lead-time exposure, or proposed alternate
States the fact or uncertainty without hiding it inside a color.
Evidence
Direct URL or controlled file, issuer, document or tracking number, affected-part list, revision and check date
Lets another reviewer reproduce the finding and confirm scope.
Project impact
Possible effect on material commitment, schedule, design, layout, firmware, inspection, test, compliance, or repeat orders
Converts a sourcing signal into a project decision.
Action and owner
Required investigation, sample, comparison, buy decision, redesign task, responsible owner and due date
Makes the report operational rather than descriptive.
Approval and closure
Decision, approver, approval date, effective revision, conditions, follow-up evidence and closure status
Connects the report to the released BOM and manufacturing package.
Use exact item identity
Do not shorten a manufacturer part number in a way that removes package, temperature, packing, qualification, or ordering suffixes. The affected device family and the exact orderable part may not be interchangeable for procurement or notification review. Record reference designators because one component can appear in multiple circuit roles, and the impact of a proposed change may depend on where it is used.
If the BOM line allows several approved manufacturers, show whether the observation affects one approved option or the entire released line. A shortage at one source does not necessarily make the line unusable; conversely, stock for an unapproved look-alike does not close the risk.
Describe the condition without overstating certainty
Use a specific condition such as “manufacturer page shows NRND, checked 2026-07-30,” “final EOL notice affects the listed orderable part,” “only one approved manufacturer remains,” or “BOM package field conflicts with the assembly data.” Avoid labels such as “bad part” or “safe part.” Those labels collapse several decisions and age poorly.
For lifecycle work, the issuer’s terminology matters. Texas Instruments, for example, publishes product status categories that include preview, active, not recommended for new designs, last time buy, and obsolete. That TI product lifecycle classification supports a dated status observation for a TI device; it does not automatically define another manufacturer’s terminology or decide whether an OEM build should proceed.
Separate source facts from engineering conclusions
Manufacturer notices and supply observations are dated inputs, not automatic design approvals. The report should visibly distinguish evidence from interpretation. A manufacturer record can show a lifecycle label or affected-part list. A channel record can show a dated purchasing option. A data sheet comparison can identify parameter differences. None of those sources alone authorizes a PCBA design change.
Record manufacturer notices as controlled evidence
When a PCN or EOL notice is relevant, capture the issuer, tracking number, notice type and status, issue or revision date, affected orderable parts, described change, qualification material, implementation or order deadline, and any replacement identified by the manufacturer. Save the direct notice or a controlled copy according to the project’s document rules; a screenshot without the affected-part attachment or revision history may be incomplete.
The fields are not theoretical. TI states that a notifiable product change can include a detailed description, reason, tracking number, affected-product identification, anticipated impact, qualification information, sample availability, and projected production shipment date. Its product change notification process also lists information used for withdrawal or discontinuance notices. A report should extract only the fields that apply to the exact part and notice being reviewed.
Notice status can change. Microchip explains that its PCN system distinguishes initial, intermediate, final, EOL, and cancellation states, and that a tracking number and revision history help identify the notification over time. The Microchip PCN and EOL system is a useful example of why the report must record notice state and revision rather than retaining only the first alert.
Keep supply evidence in its own column
Supply evidence should state the approved channel, quoted or displayed quantity, lot or date-code information if available, traceability documents offered, commercial validity, and check date. Mark whether the evidence is a quote, an order acknowledgment, an inventory display, or a physical lot already under control. These are not equivalent.
Procurement can use this information to evaluate purchase options, but engineering still owns product-impact decisions. If a proposed source or alternate falls outside the released AVL, the report should remain open until the authorized owner approves a defined path. For a detailed approval framework, refer to evaluating component alternatives in PCBA safely .
Turn an alternate into a review package
For an alternate candidate, record the original and proposed full MPNs, manufacturer status, package and pinout comparison, electrical limits, temperature range, tolerance, timing behavior, firmware assumptions, layout effect, inspection and test implications, compliance documentation, sample requirement, and required approvers. Not every category applies to every part, but the report should show which categories were checked and which were judged not applicable.
The risk report is not the final engineering change record. It is the control point that prevents a sourcing candidate from entering production before the applicable review is complete. Once approved, the decision should be transferred to the controlled BOM, AVL, ECN, work instruction, programming file, inspection program, and test package as applicable.
Rank issues by build impact and decision lead time
A red, yellow, or green cell is meaningful only when the team knows what the color triggers. A better method is to rank each issue using documented project variables: probability that the current path will fail, magnitude of the build impact, time needed to obtain a decision, availability of an already approved path, and proximity to material commitment. The report can use words, numeric bands, or workflow states, but it must define them.
The following matrix avoids pretending that one universal score fits every PCBA project.
Decision class
Typical condition
Required action before release
Closure evidence
Monitor
Evidence is current, an approved path exists, and no immediate build change is required
Set a refresh date and owner; retain the source record
Recheck completed with no change to the released path
Confirm supply
Released part remains approved but quantity, channel, lot, or timing is uncertain
Obtain current commercial and traceability evidence before commitment
Approved quote/order evidence tied to the project quantity
Engineering review
Alternate, PCN, specification difference, or revision mismatch may affect the product or process
Complete applicable comparison, sample, DFM, firmware, inspection, test, or compliance review
Signed decision and effective controlled revision
Commercial decision
Last-time-buy, allocation, minimum purchase, or inventory strategy needs OEM direction
Compare demand assumptions, financial exposure, storage life, and redesign timing
Authorized buy or no-buy decision with assumptions
Stop release
Exact part, approved source, revision, or required validation cannot be established
Do not commit or build the affected scope until the missing condition is resolved
Documented resolution and release approval
Prioritize the items that can change the release
Priority should reflect the actual build. A low-cost passive can become critical when its electrical characteristic, qualification, footprint, or sole approved source is essential. A high-cost processor may be manageable if adequate approved material is already controlled for the defined build. Price alone is not the ranking method.
Decision lead time matters as much as component lead time. An alternate that needs a PCB change, firmware work, regulatory review, or new test fixture may require more planning than a part with limited current stock but an already approved second source. The report should therefore include both the supply clock and the approval clock.
Do not write an unsupported completion date. Instead, list the missing inputs and dependencies: sample arrival, data sheet comparison, engineering owner availability, test definition, customer approval, or controlled-document update. This gives the project manager a schedule input without turning uncertainty into a promise.
Close each item through approval and release control
An approved risk decision must reach the material and production release package. An open risk is not closed because a supplier found stock or because a meeting ended. Closure means the chosen path is approved, the correct controlled files are updated, production can identify the effective decision, and required evidence can be retrieved.
Use a defined decision sequence
For each meaningful risk, use a compact workflow:
Confirm the exact BOM line, affected revisions, build quantity, and decision deadline.
Reproduce the condition from the direct evidence and record its date and scope.
Identify the released path and the options that remain within or outside it.
Assign procurement, engineering, quality, manufacturing, or customer actions.
Collect the comparison, sample, traceability, validation, or commercial evidence.
Record the authorized decision, conditions, and effective revision.
Update every downstream file needed for material control and production.
Recheck the closed item before repeat orders when its evidence is time-sensitive.
The report should use explicit states such as open, evidence pending, engineering review, customer decision, approved with conditions, rejected, and closed. “Discussed” is not a closure state. If approval applies only to one quantity, lot, prototype stage, or temporary deviation, record that boundary so it is not reused as a permanent AVL decision.
Connect closure to the manufacturing package
A closed report line may require changes to the BOM, AVL, approved deviation, ECN, purchase instruction, incoming inspection plan, moisture handling instruction, stencil or placement data, AOI/X-Ray program, programming configuration, functional test, label, or first-article plan. The required downstream files depend on the component and the decision; the report should identify them rather than assuming the BOM is the only affected document.
This handoff is where a report becomes useful to production. The material team needs to know what can be received and issued. The line needs the correct part and revision. Quality needs the inspection or validation condition. The OEM needs a record linking the approval to the finished build. A supplier intake workflow such as what happens after BOM and PCBA files are uploaded should preserve those relationships from review through release. Before the purchase order, the buyer can also use a PCBA traceability verification to confirm that the expected records match the project scope.
Refresh the report instead of copying an old result
Refresh the report when the BOM, PCB or AVL revision changes; the build moves from prototype to pilot or production; quantity or timing changes materially; a new PCN/EOL notice appears; a source or alternate changes; an open action reaches its due date; or a repeat order relies on old supply evidence. Keep the previous decision history, but do not overwrite it in a way that hides what was approved at the earlier time.
For repeat orders, compare the current released package with the last build record. Confirm whether temporary deviations expired, whether conditional approvals were closed, and whether the manufacturer or channel evidence remains current. This prevents a one-time exception from silently becoming the default production rule.
Conclusion
A decision-ready BOM risk report does not need dramatic scoring. It needs controlled context, exact item identity, dated evidence, a clear statement of project impact, an authorized owner, and a closure record tied to the released PCBA package. Those fields let procurement distinguish a current buying option from an approved material path, help engineering focus on changes that may affect the product, and give quality and manufacturing a traceable release condition.
Start with the current BOM, PCB revision, AVL rules, build stage, quantity, and target commitment date. Then require every meaningful flag to show its evidence, next action, approver, effective revision, and refresh point. To apply this structure to a live project, send the current BOM, approved-source rules, build quantity, and target date for a structured PCBA project review.
Request a BOM Risk Review
FAQ
What is the difference between a BOM risk report and a BOM check?
A BOM check can confirm whether required line-item data is present. A BOM risk report goes further by recording the evidence, project impact, decision owner, required action, approval status, and closure record for each meaningful issue. The report should remain tied to a specific BOM and PCB revision.
Should every BOM line receive a red yellow or green rating?
Not necessarily. A rating is useful only when its definition is documented and it leads to a specific action. Many ordinary lines can remain unflagged, while meaningful lifecycle, source, data, validation, or build risks should receive an owner, due date, evidence requirement, and release condition.
Can an available alternate be approved directly in the risk report?
The report can identify an alternate candidate and collect comparison evidence, but availability alone does not approve it. The authorized engineering and quality owners should review the relevant electrical, mechanical, firmware, manufacturing, test, and compliance effects before the controlled BOM or AVL is changed.
When should an OEM refresh a BOM risk report?
Refresh it when the BOM or PCB revision changes, the build quantity or stage changes, a manufacturer issues a relevant PCN or EOL notice, an approved source changes, an alternate is proposed, or a repeat order relies on an old availability snapshot. Open items should also be rechecked before material commitment.
