Variant Table

A variant table is a matrix-style representation that maps product variants to the options or characteristic values that define them — providing a structured, human-readable overview of a product family’s variation. In variant management, variant tables are used to document which options apply to which variants, to communicate the scope of a product family, and to define the selection logic that drives variant BOM derivation.

A variant table has variants as rows (or columns) and characteristics or options as columns (or rows). Each cell contains the value of a characteristic for a specific variant, or a marker indicating that the option is included, excluded, or not applicable.

Types of variant tables

Variant tables take different forms depending on what they document:

Enumerated variant table Every variant is listed explicitly as a row. Each column is a characteristic; each cell is the characteristic value for that variant. This format is complete and unambiguous, but grows large quickly: a product family with 100 variants and 20 characteristics has a 100 × 20 table.

Variant	Engine	Transmission	Market	Colour
Model A-EU-1	1.5L Petrol	Manual	EU	Silver
Model A-EU-2	1.5L Petrol	Automatic	EU	Silver
Model A-US-1	2.0L Petrol	Automatic	US	Black
Model B-EU-1	Electric	Single-speed	EU	White

Rule-based variant table Instead of enumerating every variant explicitly, the table expresses which option combinations are valid using inclusion/exclusion markers or conditions. This format scales to larger option spaces but requires interpretation.

Modular option table A simplified form that lists which options are available (without full enumeration of combinations). Used for customer-facing product configurator documentation and sales catalogues.

Variant tables in SAP

In SAP’s variant configuration environment, a specific type of variant table — the SAP variant table — is a formal configuration object used in SAP LO-VC SAP LO-VC / AVC (ˌes-ˌā-ˈpē ˈel-ō-ˌvē-ˈsē) n. abbr. SAP LO-VC (Logistics – Variant Configuration) is SAP's module for configuring complex products at order time, deriving variant BOMs from characteristics, classes, and variant rules. . An SAP variant table:

• Has defined columns (typically characteristic names)
• Contains rows of characteristic value combinations
• Is referenced in procedural variant rules Procedural Variant Rule (prə-ˈsē-jər-əl ˈver-ē-ənt ˈrül) n. Procedural variant rules govern feature models and variant BOMs by executing IF-THEN logic in sequence. Unlike constraints, the result depends on which rules fire first. to look up which component applies for a given combination of characteristic values

Rather than writing explicit IF-THEN rules for every combination, a rule references the variant table: “look up the motor assembly part number in the motor selection table, given the selected power rating and voltage.” This makes the configuration logic maintainable: adding a new valid combination requires adding a row to the table, not editing a rule.

Role in variant management

Variant tables serve different purposes depending on their context:

Documentation and communication A variant table makes the scope of a product family visible at a glance — what variants exist, how they differ, what is common. This is valuable for engineering teams, sales, and service organizations who need a structured reference.

Configuration model input In rule-based configurators, variant tables provide the lookup data that procedural rules reference. They centralize the option-to-component mapping, making it easier to maintain and audit.

Scope management A variant table that grows uncontrollably — new rows added for each customer request — is a signal that variant management is not in place. A well-managed variant table has a defined structure and a governance process for adding new variants or options.

Examples

• Electronic connectors — A connector family is documented in a variant table with columns for contact count, housing material, IP rating, and termination type. Each row is a standard catalogue variant. Distributors and customers use the table to identify the right part number; the engineering team uses it to verify that all variants are covered by qualified tooling.
• Paint finishes — A manufacturer documents available colour/finish combinations in a variant table, with columns for substrate material, base colour, and finish type. The table defines which combinations are approved (standard process) and which require special approval (non-standard). Variant rules reference the table to determine which painting process applies to each order.

Frequently asked questions

When is a variant table better than a constraint model?

Variant tables work well when the number of valid combinations is manageable and enumerable — typically when there are few characteristics with few values each. They are easy to read, audit, and maintain by non-specialists. Constraint models scale better to large option spaces where explicit enumeration is impractical (hundreds of characteristics, thousands of combinations). In practice, many variant management implementations use both: constraint models for the core configuration logic and variant tables for specific lookup operations or documentation.

Is a variant table the same as a 150% BOM?

No. A 150% BOM 150% BOM (ˌwən-ˌfif-tē pər-ˈsent ˌbil əv mə-ˈtir-ē-əlz) n. A 150% BOM lists all possible components across all product variants, serving as the master structure for subtractive configuration in variant management. is a product structure that lists all possible components across all variants — it is an engineering BOM artifact. A variant table is a matrix that maps variant definitions to their characteristic values or option selections — it is a configuration documentation artifact. The 150% BOM answers “what components exist across the product family?” The variant table answers “what options define each variant?” Both are tools in variant management, but they document different aspects of the product family.