A PCBA yield report is useful when an OEM buyer can reconstruct what entered the process, what happened at each gate and why every unit received its final status. A percentage without that chain may look precise while concealing mixed versions, repeated tests, repairs, engineering samples or excluded failures.
However, Yield also answers different questions at different stages. An NPI team may need to learn whether tooling and instructions are stable. A quality manager may need containment by material lot or program. A buyer may need to understand recurring cost and delivery risk. One headline number cannot serve all three purposes.
In addition, this guide explains how to read the report as a bounded evidence package. It avoids universal targets because product complexity, maturity, coverage, risk and sample size differ. The goal is to know what the result supports, what it does not support and which action follows.
Also, the measurement check follows the bias, short-term variability, long-term variability and uncertainty issues described in the NIST measurement-process handbook . Those concepts support the review method; they do not validate an unexamined fixture or dataset.
Start with the population and build boundary
First, ask which units are in the denominator. The report should identify work order, product, revision, BOM option, firmware, panel quantity, board quantity and time window. It should also identify engineering samples, destructive samples, setup boards and customer-supplied units that follow a different route.
In addition, Reconcile the flow. Record boards started, completed, held, scrapped, accepted, repaired and still in analysis. If panel counts become unit counts after depaneling, show the conversion and any lost units. A report cannot be complete when ten boards disappear between issue and disposition.
Next, separate change points. Material alternates, stencil adjustments, program revisions, fixture repairs and work-instruction changes create new evidence populations. The team may display an overall result for schedule review, but technical conclusions should preserve the before-and-after groups.
Then, confirm route completeness against the released PCB assembly services plan. Units that skip inspection, programming or functional test need an approved reason and a clear release rule. A missing record should remain a gap, not become a pass by assumption.
Report field
Buyer question
Useful evidence
Warning sign
Population
Which exact units are counted?
Work order, revision, serial range and quantity reconciliation
Mixed versions or unexplained exclusions
First pass
What event qualifies as the first attempt?
Timestamped first result at every named gate
Latest result overwrites the first
Retest
Why was another attempt needed?
Reason, action, raw data and operator
Pass after repeated attempts with no cause
Repair
What defect and action changed the unit?
Defect location, repair record and verification
Repair counted as untouched acceptance
Release
Who accepted the remaining risk?
Disposition, deviation and approval
Shipment status used as quality evidence
A readable report begins with one controlled population and reconciles every unit through its route and final status. Define first pass before reading first-pass yield
First-pass yield normally describes units that meet a gate on their first valid attempt without repair or unplanned intervention. The report needs the local operational definition. It should say whether setup confirmation, software reload, connector reseating, fixture cleaning or measurement rerun changes first-pass status.
Next, define the gate. SPI, AOI, X-ray, ICT, programming and FCT observe different characteristics and may use different denominators. A unit can pass electrical test on the first attempt after failing AOI. That history supports different actions from a unit that passes every gate.
Therefore, Preserve the first timestamped result. If a result is invalid because of a documented system fault, keep the event and its invalidation reason. Deleting inconvenient results makes the number easier to read and the process harder to understand.
Also, Distinguish process first pass from final acceptance. Final acceptance tells the buyer how many units eventually met the release rule. First pass exposes how much intervention the route required. Both can appear on the same report when their labels and populations stay clear.
Then, use a route view. For each gate, show input, first-pass count, retest count, repaired count, scrap and open quantity. This prevents a high final acceptance rate from hiding a growing queue of repeated test attempts or manual corrections.
Separate retest, restart and repair paths
In addition, a retest without a change can reveal measurement instability, intermittent contact or unclear handling. A retest after fixture cleaning is a maintenance event. A retest after component replacement verifies a repair. Grouping them under retest removes the evidence needed to choose an owner.
Next, require a reason code before the next attempt. Useful categories include confirmed product defect, suspected fixture contact, invalid setup, software communication, operator handling, approved diagnostic step and no-fault-found investigation. The raw symptom should remain available behind the code.
Also, Track attempt count. One extra test for a known station interruption differs from five attempts until a pass appears. Set escalation rules for repeated attempts and make any final acceptance of intermittent units explicit.
In addition, For repair, retain defect location, component reference, failure mode, action, materials used, operator, inspection and verification. Confirm whether the customer permits repair and whether special approval or marking applies. Repair history should follow the unit into release records.
Then, compare labor and queue effects. A batch can achieve the planned shipment quantity while consuming excessive engineering review, debugging and rework. The report should show touch count and time by reason when the buyer is judging scale readiness or recurring cost.
Retest, restart and repair remain separate paths so the team can see product, fixture, software and handling causes. Read defect codes as claims that need evidence
Also, a defect code should lead to a physical feature, requirement or process event. Codes such as solder bridge at a named reference, missing component, insufficient wetting, fixture contact loss or software timeout support investigation. A code such as failed test simply repeats the status.
Next, check who assigns and verifies the code. Inspection calls may be confirmed, rejected or reclassified after review. Functional symptoms may require analysis before a hardware cause is known. The report should distinguish observed symptom, confirmed defect and verified cause.
Then, review location and recurrence. Plot defects by reference designator, panel position, feeder, material lot, station, shift, fixture interface and time. Clustering can guide containment, but a pattern does not establish cause until the physical or measurement path is checked.
Next, keep false calls visible. AOI or test systems can reject acceptable units. A high false-call load consumes review time and may indicate weak programming, lighting, fixture contact or limits. Removing false calls from the dataset also removes evidence about the inspection system.
For example, Request a small set of underlying records from the supplier’s quality assurance workflow. Sample first results, images, measurements, repair records and dispositions across pass, fail and retest paths. The aim is to verify record linkage for the project, not to accept a generic quality statement.
Check exclusions and denominator changes
In addition, Every exclusion needs a rule, reason, owner and affected population. Setup boards, destructive samples and customer-requested experiments may be valid exclusions when identified before analysis. Units removed after they fail create selection bias unless the report presents them separately.
Also, Look for denominator drift between versions of the report. Started quantity may be replaced by completed quantity, or open failures may disappear after shipment. A revision history should explain corrections and preserve the earlier issue.
Then, confirm that rejected panels and lost units stay in quantity reconciliation. If a panel is scrapped before serial assignment, use another traceable identity. Early process loss still belongs in manufacturing evidence.
Next, ask how split lots are handled. The same work order may use two material lots or two program revisions. A combined result is useful for commercial tracking, while technical review should show each affected group and the reason for combining them.
In addition, Do not compare suppliers until definitions align. One supplier may report line-gate first pass, another may report final accepted units, and a third may exclude false calls and engineering holds. A fair comparison starts with the same population, event and intervention rules.
Verify the measurement and test system
Also, Yield reflects the production process and the system used to observe it. Confirm equipment identity, program revision, fixture revision, limits, calibration or verification state and reference-unit checks. An unstable measurement path can create both false failures and false confidence.
As a result, Review repeated measurements on known units where the method allows. Large variation, frequent reseating or result changes after station restart need investigation. For visual systems, check confirmation rules and reviewer consistency.
Then, confirm coverage. A high yield at a weak gate does not demonstrate product conformity. Link critical requirements and known defect risks to inspection, electrical test, functional test or later system evidence. State gaps and their containment.
Next, Verify that the equipment and route match the project through the current production equipment review. A machine list does not prove the released program, fixture, access or limits used for this build.
Record station interventions. Probe replacement, fixture maintenance, software restart, program update and reference failure create change points. The report should show which units were tested before and after the event and what release check restored confidence.
Yield is credible when test programs, fixtures, limits, reference checks and interventions are tied to the reported population. Use trends without hiding the build story
Trend by comparable population. Compare the same revision, route and definition across time. Mark material, program, fixture, operator and process changes. A line rising after several variables changed cannot identify which action improved the result.
Use control limits or capability studies only when the method and assumptions fit. The process needs evidence of stability, the measurement system must be adequate and the data distribution must be understood. A small trial can produce useful observations without supporting a long-term capability claim.
Review leading evidence with the yield. Setup changes, paste measurement, AOI false calls, fixture contact events, maintenance and touch time may warn of deterioration before final acceptance falls.
Keep severity visible. Ten cosmetic findings and one safety-critical electrical failure have different consequences. Frequency helps allocate improvement work, while risk controls release and containment.
Compare plan with actual response. If the control plan says a repeated defect stops the line, the event record should show when the threshold was reached, who acted and which population was contained. Yield reporting becomes valuable when it tests the reaction system.
Connect summary data to board-level records
Select a failed unit from the chart and retrieve its configuration, material lots, route, first results, retests, repair and final disposition. Select a passed unit and confirm the same chain. Reverse-trace one suspect lot or program revision to all affected boards.
This sampling test checks whether summary data and unit history agree. It also reveals manual joins, missing identifiers and overwritten events. The smart warehouse and traceability context provides a related evidence path for OEM review.
Ask how repaired units appear in shipment data. Serial lists, certificates and customer portals should preserve the agreed status. A final pass flag may be necessary for receiving, but it should not erase the manufacturing history.
Verify access and retention. Name the record owner, storage system, retention period, export format and retrieval time. Buyer access should match contractual and product needs without depending on one employee’s local files.
What evidence supports the decision
Protect interpretation across exports. Column names, code dictionaries, time zones, decimal conventions and revision fields need definitions. A spreadsheet that cannot be read outside the original dashboard is weak handoff evidence.
Decision
Evidence to review
Limit to state
Action trigger
Release this batch
Unit disposition, coverage, deviations and open issues
Applies to the named population
Unknown status or unapproved risk
Scale the route
First pass, interventions, repeated setups and trend
Future variation remains to be observed
Performance depends on engineering support
Accept a corrective change
Before-and-after population with verified cause
Other variables may still contribute
Defect recurs in the first affected population
Compare suppliers
Aligned definitions, route and product maturity
Products and risks may still differ
Definitions or exclusions cannot be reconciled
Approve recurring cost
Retest, repair, touch time, scrap and investigation
Early learning may not recur
Hidden intervention changes the cost basis
Release, scale and improvement decisions use different evidence and must retain the limits of the observed population. Turn the report into an action review
End with a short decision page. State the population, configuration, first-pass definition, route results, dominant confirmed defects, retest and repair paths, exclusions, measurement limits, open issues and requested approvals.
Assign every action an affected population, owner, due date, temporary control and verification method. Identify the first unit or build that will test the correction. This turns a historical summary into a controlled learning cycle.
Ask the supplier to explain two ordinary units and two exception units from source records. A team that can answer these questions quickly has stronger evidence than a team that can only present a polished dashboard.
Use the report to choose the next gate. The right outcome may be shipment, contained shipment, another controlled run, fixture work, design review or a stop. A high percentage does not remove an unresolved critical failure.
Set the review cadence from risk and maturity. A new product may need a short route review during the run, followed by a detailed closeout. A stable recurring product may use exception triggers and periodic trend review. The cadence should ensure that containment still reaches work in process before affected units move beyond a recoverable point.
Who owns the next action
Give sourcing and engineering different views from the same controlled data. Sourcing may need accepted quantity, delivery exposure and recurring cost. Engineering needs location, raw symptom, change point and verification. Quality needs containment, disposition and approvals. Separate summaries are useful when every view can return to the same board-level history.
Record the decisions made during the review. Name who accepted shipment, who approved a deviation, who owns fixture correction and which evidence will close the action. Meeting minutes should reference the report revision and affected serial range. This prevents a later dashboard refresh from changing the context behind an approval.
Carry unresolved questions into the next build plan with a named sample, observation point and pass condition.
Conclusion
OEM buyers can read a PCBA yield report with confidence when the population, event rules and evidence chain remain visible. First pass, retest, repair and final acceptance each answer a different question. Defect codes, exclusions and trends are useful only when their definitions survive review.
For a current project, bring the released configuration, work-order reconciliation, route counts, defect dictionary, raw result samples and open actions. You can Review Your PCBA Yield Evidence against the decisions the report is expected to support.
Frequently Asked Questions
What is a good first-pass yield for PCBA production?
There is no universal target. Set a project-specific threshold and review population, product maturity, process stability, coverage and defect severity before interpreting the result.
Should retested PCBAs count as first-pass units?
A unit that requires another test attempt should remain visible in the retest path. The report can also show final acceptance, but it should not rewrite the original test event.
Can a small PCBA batch prove process capability?
A small batch can reveal defects and measurement problems. It rarely establishes long-term capability by itself because stability, sample size and representative conditions must be demonstrated.
What evidence should accompany a PCBA yield percentage?
Ask for the population definition, route counts, first results, retest and repair paths, defect records, exclusions, change points, measurement checks and final disposition.
