Child Product vs SKU: Differences That Matter In WMS And Catalogs

Child Product A sellable variant connected to a parent product, such as a specific size and color combination. People often conflate the term "child product" with "SKU," but in software and operations those concepts overlap but are not identical.

Understanding the difference matters when you design your catalog, integrate systems, and configure your WMS. A Child Product is a conceptual variant record within a product model; a SKU (stock keeping unit) is typically the identifier used to track that sellable unit in inventory and transactions. In many implementations a child product equals one SKU, but not always.

How The Two Concepts Map

There are several mapping patterns between child products and SKUs:

• One‑to‑One: Each child product has a unique SKU. This is the simplest and most common mapping and is preferred for WMS operations.
• One‑to‑Many: A child product represents a variant that maps to multiple SKUs — for example, different packaging configurations or multiple barcodes for retail vs. distribution.
• Many‑to‑One: Multiple child records mapped to a single SKU occurs in legacy systems where product options are tracked at order lines but inventory is pooled at a broader level.

Operational Implications For Warehousing

WMS systems require SKU‑level resolution for receiving, putaway, picking, and cycle counting. If your child product doesn't map uniquely to a SKU, you must document rules the WMS will use to select the correct barcode or packing configuration. Ambiguous mappings increase picking errors, complicate replenishment algorithms, and create reconciliation headaches.

• Picking Accuracy: Unique SKU per child minimizes wrong‑item picks and simplifies barcode scanning workflows.
• Cycle Counting: Counts based on child SKUs give accurate stock levels and variance traceability.
• Slotting And Replenishment: Turnover and min/max calculations work best when applied to individual SKUs that represent actual stocked units.

Catalog And Channel Considerations

Marketplaces, ERP systems, and EDI partners have different expectations for identifiers. E‑commerce marketplaces may require GTINs at the child level while your internal ERP uses an internal SKU. Always maintain a cross‑reference table so the child product record can expose the correct identifier to each channel.

• Marketplace IDs: Child-level GTIN/UPC is often mandatory for variation listings on marketplaces like Amazon; map the child product to those codes.
• ERP vs PIM: Keep SKU assignments consistent between PIM and ERP or implement a master reference to translate IDs across systems.
• Barcodes: Use barcodes tied to the child SKU that your WMS scans; avoid ad hoc barcode creation at the warehouse without updating the canonical child record.

When The Terms Can Diverge

Certain business patterns create divergence. Examples: kitted products where the child SKU represents a bundle of child SKUs, regional variants where the same child product is sold under different SKUs per country, and serialized inventory where a child SKU may have many serial numbers tracked separately. In each case, treat the child product as the business concept and the SKU as an operational handle.

Best Practices To Avoid Confusion

Document the relationship between child products and SKUs in your data model. Use unique, consistent SKU rules, and enforce them with validations in PIM and ERP. Ensure integration flows carry both the child product ID and the SKU so analytics can group by parent while operations use the SKU.

• Data Dictionary: Define fields: child product ID, SKU, GTIN, sellerSKU, and when to use each.
• Integration Contracts: APIs and EDI files should pass both conceptual and operational identifiers.
• Training: Teach warehouse staff the distinction: the child product describes the variant; the SKU is what they scan and ship.

In short, the Child Product is your catalog’s variant concept, while the SKU is the operational identifier used in the WMS and ERP. Aim for one-to-one mappings where possible; where mappings must diverge, codify rules and keep translations centralized to prevent fulfillment and reporting errors.