Product variant

Stock is never held at the style level. A shop does not have twelve Hyperfreak boardshorts; it has three in Black/Medium, two in Black/Large, and so on. Every count, every sale and every purchase-order line resolves to a variant, which is why getting variant identity right matters more than getting the parent right.

A vendor document describes variants in the vendor's vocabulary, not yours. The same variant might be HYPRFRK-24-BLK-MD on the invoice and Hyperfreak Boardshort, Black, M in your catalog. When those two fail to reconcile, receiving creates a new variant beside the existing one, and stock splits across both.

The three usual causes are colour codes that do not match your catalog's colour names, size labels that differ in format, and style numbers that encode season or fit in ways your naming does not.

Two variants are the same when they are the same style in the same combination of attributes. Neither the vendor's code nor your internal SKU is sufficient on its own: vendors reuse codes across seasons, and internal SKUs are frequently generated rather than matched. Attribute equality on a shared parent is what actually decides it.

This matters when a document arrives that looks unfamiliar. Before creating anything, the question is not whether the code is new, it is whether this style already exists in your catalog and whether this attribute combination already exists beneath it. A new code on a style you carry is a naming difference. A genuinely new attribute combination is a new variant. Only a style you have never carried is a new product, and that is far rarer than most receiving processes assume.