Parent Products, SKUs and Variants: How Furniture Catalogs Should Be Structured

A buyer may use "product" to mean the Amara sofa range. The warehouse means one exact SKU: Amara, 3-seat, Oatmeal Linen, Walnut legs. Both are valid, but the catalog needs to keep those levels distinct.

Three concepts to keep distinct

A configurable furniture catalog needs to distinguish the parent product, the sellable variant and its identifiers. They are not necessarily three structural levels.

The parent product groups versions of the same model that differ in defined ways. A broader collection or range may contain several parent products. The parent carries only facts shared by every variant; care instructions, for example, may need to differ by upholstery material.

The variant is one sellable combination of size, fabric, finish or other approved choices. As a data requirement, changing facts such as price, dimensions and applicable imagery must resolve to the correct sellable configuration, even when a system stores some of those facts on a related product record.

The SKU is a stable internal identifier for the sellable item. The warehouse, ERP and retailer ordering process need to identify the same sellable item consistently, using the SKU or an explicit mapping between identifiers. Different trading partners may use different internal codes.

Get the level wrong and the error propagates. Store a dimension at the parent level when it actually varies by size, and every variant reports the same footprint whether or not it's accurate. Store a price at the parent level for a range where fabric grade changes cost, and either every fabric gets the same price or someone maintains a second, unofficial spreadsheet to track the real numbers — which is usually how quoting delays start.

One useful audit is to compare measurements across configurations that appear to differ. If small, medium and large frames all carry the same width, that is a reason to check against the supplier's confirmed measurements. Shared values may be correct; copied defaults may not be.

The identifier confusion: SKU vs. GTIN

Part of why this gets tangled is that furniture businesses conflate two different kinds of identifier. A SKU is internal and controlled by the business. A GTIN is standardized and governed by GS1. GS1's general rule is that a GTIN assigned to one trade item must not later be reassigned to another, apart from narrow exceptions. A SKU follows the business's own rules, but changing one still affects every internal and external record that uses it.

The risk is treating SKU and GTIN fields as interchangeable without a documented mapping. A business may deliberately use the same value for both, but that does not make an internal SKU a valid GTIN. GTINs must follow GS1 allocation rules; they should not be invented by adapting a SKU naming pattern.

What "variant" means to the platform you sell through

If you sell through Shopify, a product can have up to three configurable options and 2,048 variants. The higher variant limit was announced on October 15, 2025. A range with a fourth independent axis cannot represent every choice as a native option on one Shopify product without restructuring.

Check the connected apps as well as Shopify's native limits. Shopify warns that some themes, app extensions, public apps, sales channels and custom apps may not handle products with more than 100 variants correctly.

Search engines model variant groups differently. Schema.org's ProductGroup describes products that vary only in defined ways and uses variesBy to identify those differences. Google's product-variant documentation supports six properties for this purpose: color, size, suggested age, suggested gender, material and pattern.

An axis such as arm style has no direct equivalent among those six properties. Some finish differences may be represented accurately through color or material, but unsupported choices should not be forced into a misleading property merely to fit Google's supported list.

Why "the system will figure it out" doesn't hold

Importing near-identical rows does not remove the need to decide the hierarchy. In Furniture Connect's flat CSV and spreadsheet import, a row whose SKU matches an existing catalog product updates that product; only fields carried by the import are changed. This process does not automatically build parent-and-variant relationships. Variant families require a separately agreed structure and explicit creation of their approved combinations.

Furniture Connect's current native variant model supports up to two axes per product. If a range has more independent choices, decide which belong in the native variant structure and which require separate products, supporting attributes or documented order-time selections.

Supporting attributes and order-time notes are not extra native variant axes and do not automatically enforce compatibility, pricing or stock behavior.

In the current Furniture Connect Agent workflow, native dimensions are stored on product records rather than maintained as separate variant overrides. Where sizes or constructions have different measurements, separate product records with suitable finish or fabric variants provide a supported structure.

Grouping rows from similar names is risky. Amara Sofa - Oatmeal and Amara Sofa Oatmeal (Return) might belong together, or they might represent different commercial records. The name alone cannot settle that.

Building the hierarchy on purpose

The practical fix is to decide the structure before the catalog grows, not after. Write down, for one representative model, which facts are shared and which vary by sellable configuration. Where a destination limits the structure, decide which axes map cleanly and which need another representation before export.

The Furniture Product Data Model covers the wider field set. The configurable furniture guide brings the structure together with dependencies, pricing, availability and imagery.

A quick audit for an existing catalog

If you're checking an existing catalog, start with three questions.

First, does every sellable configuration resolve to the supplier's confirmed measurements? Identical numbers across different sizes are a reason to check, not proof of an error.

Second, are SKU and GTIN fields clearly labeled, correctly mapped and attached to the intended sellable item? Look for duplicate SKUs, misplaced identifiers and GTINs that do not correspond to the product being sold.

Third, if you export to Shopify, does the model fit within three native option axes, and can the connected apps handle the resulting number of variants?

None of these checks require new software — they require someone willing to compare a handful of records against each other directly, rather than trusting that the catalog is internally consistent because it was built carefully once.