Item attributes and variants in Business Central

Business Central handles product variation through two related but distinct concepts: variants (which create stock-keeping differences) and attributes (which describe and filter without affecting stock). Knowing which is which avoids most variant-related implementation mistakes.

Variants

An item with variants has one item number but multiple stock-keeping codes — typically size, colour, or trim. Each variant is a row of the Item Variant table, and inventory, transactions, and prices can be specific to it. Variant codes are short (10 characters) and intended for the production / stock-keeping dimension that matters operationally: a shirt with sizes S/M/L/XL or a paint with colours Red/Blue/Green. Variants share the underlying item card (description, base UoM, costing method) so they're a lightweight way to multiply SKUs without multiplying master data.

Two setup details save later grief. First, turn on the item's mandatory variant setting the moment variants exist — otherwise users can post transactions against the bare item number, and you end up with stock split between "T-SHIRT" and "T-SHIRT / M" that no report reconciles. Second, agree a variant code convention before creating the first one: codes are limited to 10 characters, they appear on every document line, and renaming them after transactions exist is not realistically possible. M-RED beats MEDIUMRED1 on every count.

Variants and pricing

Sales and purchase prices can be set per variant, and stock can be reserved per variant, but planning runs at the item-and-variant level so MRP works correctly. If replenishment differs per variant and per location — the red mugs sell only in the Stockholm store — combine variants with stockkeeping units, which give each item/variant/location combination its own reordering policy and lead time. That's also the level at which the planning worksheet generates suggestions, so a variant with real demand and no SKU-level parameters inherits whatever the item card says, sensible or not.

Attributes

Item attributes are descriptive properties — material, country of origin, certification, weight class — used for filtering, search, and reporting. Attributes are key-value pairs with predefined types (Option, Text, Date, Number), and they're attached to an item or an item category. They do not create stock-keeping differences.

Item categories

A hierarchical item category holds default attributes — set "Country of Origin" on the "Imported Bicycles" category and every item in that category inherits the attribute. Categories also default posting groups, item tracking, and reordering policies, so they're the most efficient way to manage large catalogues.

When variants fall short

Variant codes are flat (a single dimension). For two-dimensional configurations — sizes and colours — companies typically encode both into the variant code (L-RED, L-BLU, M-RED, M-BLU) or use ISV apps that add true matrix variants. For configurable products with engineered options, you need a separate product configurator add-on or step up to Supply Chain Management.

Variants and item ledger

Item ledger entries store the variant code, so all inventory transactions, costing, and reporting break down per variant correctly. Inventory valuation rolls up to the item but can be reported by variant.

Attributes and e-commerce

Attributes earn their keep hardest in web-connected catalogues. The Shopify connector and most e-commerce integrations map item attributes to product filters and specifications on the storefront — material, colour family, certifications — while variants map to the purchasable options. Get the split right in BC and the webshop's faceted navigation comes almost for free; get it wrong (everything encoded in item descriptions) and the integration team ends up parsing text with regular expressions. The same attribute data feeds marketplace listings and product data feeds, which makes finance's "descriptive metadata" suddenly a revenue concern. See integrating Business Central with Shopify for the connector specifics.

A decision checklist

For each way a product varies, ask three questions:

1. Does it change what sits on the shelf? Different physical stock → variant. Pure description → attribute.
2. Does it change cost or price? Per-variation pricing works on variants; attributes carry no commercial data.
3. Will anyone filter or report by it? Both support this — but attributes do it without multiplying stock-keeping records, so prefer them when question 1 says no.

And one honest capacity question: how many combinations? A catalogue where items carry 2–20 variants fits BC's flat model comfortably. Hundreds of combinations per item (apparel with size × colour × fit) is matrix territory — budget for an ISV app with matrix entry screens from day one, because keying 300 variant lines by hand is how implementations lose the warehouse team's trust in week two.

A common mistake

Using variants for marketing taxonomy (brand, season, range). That belongs in attributes. Variants are for things that change stock. The tell-tale symptom of the inverted design: sales orders where staff must pick between near-identical variant codes that don't affect what ships, while the webshop team maintains a parallel spreadsheet of the properties customers actually filter by. If that spreadsheet exists, the model is upside down — fold it into attributes and reserve variant codes for the warehouse's reality. For the wider stock picture these records feed, see inventory and warehouse in Business Central.