Direct answer

Defect recording in SAP QM captures a nonconformance using predefined defect codes and related detail. Depending on the inspection setup, defects can be recorded at inspection-lot, operation, or inspection-characteristic level. The resulting records support consistent analysis, follow-up tasks, quality notifications, and more informed inspection completion.

Defect record versus rejected result

During results recording, an inspector may enter an out-of-specification measurement or a rejected qualitative result. That answers whether the characteristic met the specification. A defect record goes further by classifying the nature of the problem—such as a scratch, dimensional error, contamination, missing feature, wrong assembly, or another defined defect type.

SAP Help defines a defect as a property or attribute of a material, product, or process that does not meet an inspection characteristic specification. Defect codes are maintained in inspection catalogs so that failures can be described consistently instead of relying only on free-text comments.

SHOP-FLOOR DEFECT REVIEWMeasured result25.42 mm · rejectedDefect classificationOversize diameterINSPECTOR CAPTURESdefect type / locationquantity / text / contextevidence for follow-upquality inspector
The defect record adds a standardized explanation to the rejected result so the issue can be analyzed beyond one inspection lot.

Where defects can be recorded

SAP documents defect recording at three levels: the inspection lot, an operation, or an inspection characteristic. The available level depends on the inspection structure. If no inspection plan or material specification is available, recording may be limited to the lot. With an inspection plan, the defect can be attached more precisely to the operation or characteristic that failed.

That precision matters. A lot-level defect says the overall inspection event had a problem. A characteristic-level defect can show that a particular dimension or quality criterion failed. The right level improves root-cause analysis and reporting.

How catalogs make defect data usable

SAP QM catalogs provide standardized codes and texts for quality information. Defect types use catalog 9 in the standard catalog model, while related catalogs can describe causes, activities, locations, or other quality information. The value is consistency: “surface scratch,” “cosmetic mark,” and “scratch on face” should not become three unrelated descriptions if the business wants one analyzable defect category.

Catalog governance is therefore part of quality governance. Too many overlapping codes make analysis noisy; codes that are too broad hide useful patterns.

ANATOMY OF A USEFUL DEFECT RECORDWHAT FAILED?Defect type codeWHERE?Lot / operation / characteristicHOW MUCH?Quantity / extentWHERE ON OBJECT?Defect locationWHAT NEXT?Task / notification follow-upCONTEXTText / evidence / ownershipGood records make repeated failures comparable across lots, shifts, materials, suppliers, or production lines.
A useful defect record combines standardized classification with enough context to support action and trend analysis.

Manual and automatic defect creation

SAP supports manual defect recording during results recording and before the usage decision. SAP documentation also describes automatic creation of defect records when a characteristic is rejected and the required defect settings and codes are maintained. The exact capability and user experience depend on the SAP product edition and app being used.

Automation should not create meaningless defect noise. If every minor failure creates a generic record with no usable classification, the data volume grows without improving quality decisions.

Controls that matter

  • Code governance: defect catalogs should be specific enough for analysis without becoming unmanageable.
  • Recording level: capture the defect at the most meaningful lot, operation, or characteristic level available.
  • Quantity and location: record extent and location when they materially affect disposition or root cause.
  • Link to evidence: defect records should connect back to the correct inspection lot and inspection context.
  • Follow-up discipline: significant defects should lead to defined tasks, notifications, containment, or investigation where appropriate.
  • Trend review: repeated codes should be analyzed for systemic process, supplier, equipment, or design problems.

Defects are not the same as quality notifications

A defect record describes a nonconformance in the inspection context. A quality notification is a broader object for managing a quality problem, including tasks, activities, causes, partners, and follow-up. A defect may justify a notification, but not every defect requires one. The business should define escalation rules based on severity, recurrence, customer impact, compliance, and process risk.

Consultant thinking: design for analysis, not only capture

When defect recording is implemented, ask what decisions the business wants to make from the data six months later. If leaders want to identify the top defect by production line, supplier, material family, or operation, the code structure and recording discipline must support that question. A good screen design cannot compensate for poor classification logic.

Key takeaway

Defect recording turns inspection failures into structured quality intelligence. The best design links the failure to the right inspection context, uses governed defect codes, captures meaningful detail, and routes important problems into controlled follow-up.

Official SAP References

Continue the SAP QM inspection cluster.