ERPNext item variants for sizes and colors

What ERPNext item variants do and when teams need them

When one product comes in many sizes, colors or model years, ERPNext handles it with an item template that holds the shared details and a set of attributes, such as size and color, that generate variants. Each variant is a separate item with its own item code, stock balance, purchase and selling history, and valuation, even though it inherits most of its master data from the template. The feature lives in the item master, so the same variant appears in sales orders, purchase orders, stock entries and reports without extra mapping. Teams should use variants when the attribute combinations are predictable, the variants share one description and set of rules, and buyers think of the product as one family. Exact behavior, including which fields copy from the template and how attribute values are edited after creation, should be confirmed against the ERPNext version in use.

Separate items are usually the better choice when variants differ in cost, supplier, tax treatment, unit of measure or lifecycle, or when the attributes are so few and unrelated that a family structure adds no value. Consider a model year change that alters the specification entirely: a new item often reads more clearly than a new variant under an old template. Before building anything, ask the implementation team to map every attribute, its allowed values, and which fields must differ per variant. Then confirm how price lists, barcodes and reorder levels will be set for each variant, since these are where most rework appears after go-live. Because attributes and template fields shape the item master that every module depends on, changes late in the project are costly, so the decision should be made with the warehouse and sales leads present.

Which way to model variations in ERPNext

This table compares three ways to represent product variation in ERPNext: an item template with attribute-driven variants, separate items for each product, and inventory dimensions for extra stock detail. Read each row against your catalog shape, and treat the final row as the checklist to confirm in your target version before you commit to a design.

Option	What it suits	What it complicates	What to confirm in your ERPNext version
Item template with attribute variants	Products that share one description and one set of attributes, such as a shirt sold in sizes and colors	Every variant inherits template fields, so products with different specifications or compliance data strain the shared model. Reports and pricing must be read per variant.	How attribute values are created and whether variant generation covers your size and color combinations
Separate items for each product	Unrelated products, or products whose specifications, suppliers, tax treatment or item codes differ enough to stand alone	No shared attribute structure, so consistent pricing, reordering and reporting across a family must be maintained by hand or through scripts	Whether your item codes, naming series and item groups can express product families without variants
Attribute-based fields on items	Descriptive detail that matters for search, printing or catalog display but does not change stock	Attributes do not split stock or valuation, so they cannot answer questions about where a specific variant sits	Which attribute fields print on documents and appear in standard reports for your version
Inventory dimensions for stock detail	Extra stock attributes such as project, rack or quality grade that must be tracked alongside the item	Stock balances, reservations and reposting are split by dimension, which adds setup and report-reading work for warehouse staff	Whether the dimension applies to every stock transaction type you use, and how dimension reports appear in your version
Pricing per variant	Price differences between sizes or models that follow a rule, such as a fixed premium for a finish	Price lists must be maintained at variant level or through rules, and price changes on the template do not always reach every variant	How item prices and pricing rules resolve for variants in your version, and whether bulk updates are available
Reordering and replenishment	Planning that treats a family of variants as one demand pattern with separate stock levels	Reorder levels, purchase requests and forecasts often run per item, so each variant may need its own rules	Which reorder and material request settings apply at variant level in your version
Reporting across a product family	Management reporting that groups sales, margin or stock by model or by template	Grouping by template needs consistent attributes and item groups, or the report shows many separate lines	Whether standard reports group by template, and what custom reports would need
Serial and batch tracked variants	Items where each variant carries its own serial numbers or batches	Tracking settings and negative stock rules apply per item, so mixing tracked and untracked variants under one template needs review	Whether serial and batch settings can differ by variant in your version, and how they behave on receipts
Changing the model later	Teams that start with separate items and later want a family view, or the reverse	Converting items into variants or merging items alters history, item codes and open documents	Whether your version supports the conversion you need, and what must be closed or archived first

How to set up item variants in ERPNext, step by step

This sequence takes a product family from a list of sizes, colors or model options to a set of generated variants that carry the right attributes, codes and stock settings. Each step ends with a check so errors surface before stock or sales documents depend on them.

Define attributes and their values
Start in the item attribute list and create one attribute for each dimension the product family varies on, such as Size, Color or Model. Add every value the range will need, using the spelling and abbreviations your warehouse and sales teams already use, because these values become part of item names and search results. Ask your product owner to confirm the full list before you continue, since adding values later is simpler than renaming variants that already have stock or sales history. The step is done when each attribute lists the complete set of values for the range.
Create the item template with variant attributes
Create a new item, mark it as a template, and add the attributes from the previous step to its variant attributes table. Set the item group, the default unit of measure and the valuation and stock-related flags that the template should pass down to variants, and confirm they match how the product is bought and sold. The template itself is not sold or stocked, so do not enter stock quantities on it. The step is done when the template saves with its variant attributes listed in the order you want them to appear in item names.
Generate the variants
From the template, use the variant generation option to create one item per combination of attribute values, or create individual variants for combinations that exist. Review the combinations before saving, and remove any that the range does not carry, such as a size that only exists in one color. Each generated variant is a separate item with its own code, price list entries and stock ledger. The step is done when the item list shows the expected number of variants under the template, and opening a sample variant shows the attribute values you selected.
Review item codes and naming
Check the item codes and item names that ERPNext generated against your numbering and labeling rules, because codes are used in purchase orders, barcodes and integrations. If your codes must follow a company pattern, confirm with your ERPNext administrator whether item naming settings or a script will apply it, and check how that interacts with your existing items. Print a short list of variants and compare it with the naming standard. The step is done when a sample of codes matches the standard and no two variants share a code.
Confirm stock settings and default units
Open a sample of variants and verify that stock tracking, default unit of measure, valuation fields and any serial or batch settings have inherited correctly from the template. Confirm that the units used for purchasing and selling match the units used for stock, and that any conversion factors are entered where a supplier or customer uses a different unit. Where a variant needs a different setting, change it on that variant only and record why. The step is done when test variants show the expected settings and a sample purchase receipt uses the correct unit.
Check pricing and attribute values on sample documents
Add a few variants to a test price list or sales order and confirm that the price applied matches the price you intended for each size, color or model. Check that the variant attributes appear on the document and in reports that you use to filter by attribute. Ask your sales lead to confirm the pricing approach for the range before you load the full list, because price list rules and variant-level prices are maintained separately. The step is done when sample documents show the correct price and attribute values for each tested variant.
Load large ranges with the Data Import tool
If the range has many variants, prepare the item data in a spreadsheet using the Data Import template and load it in batches. The ERPNext documentation advises importing only a few thousand records at a time, so split large files into smaller batches and check each batch before starting the next. Confirm the total variant count and a sample of attribute values after each import. The step is done when the item count in the list matches your source file and the sample checks pass for every batch.

What changes across selling, buying and stock when variants are used

Once an item template has variants, each size, colour or model becomes a stockable item with its own history, prices and reorder behaviour. The effects below reach sales, purchasing, warehouse and production at the same time, so decisions made in one area shape the others. Test each one with realistic sample data before loading the full catalogue.

Stock balances and ledger by variant

Each variant keeps its own stock ledger entries, valuation and balance in each warehouse. Decide which attributes must be separate stock items and which can be handled as a single item with a note, because every extra attribute multiplies the number of balances to count and reconcile. Check in a test environment that a receipt of one variant leaves sibling variants untouched and that stock reconciliation works at variant level for a cycle count.

Purchasing and reorder rules

Purchase orders, material requests and reorder levels are set per variant, not per template, so a reorder point on the template alone will not trigger replenishment for each size. Decide who maintains reorder levels for hundreds of variants and whether suppliers quote by variant or by template. Check that a purchase order created from a low-stock report lists the correct variant codes and that the supplier item codes map back to your internal variants.

Price lists and selling prices

Prices can be set on each variant or inherited through attribute-based rules, and a price list entry on the template does not automatically apply everywhere. Decide whether price differences follow attributes such as size, or whether each model carries its own price, since this determines how many price list rows you maintain. Check that a sales order for a specific variant picks up the intended rate from the right price list and that discounts apply to the correct line.

Barcodes and reporting roll-ups

Barcodes and GTINs are stored per item or per UOM, so every variant that is scanned at receiving, picking or point of sale needs its own code. Reports show variants separately by default, which makes template-level totals a question of how you group or filter. Decide the barcode scheme early and check that scanning a variant in a delivery note records the right item, and that stock and sales reports roll up to the template level as your management team expects.

Production and BOM links

Bills of material, work orders and production planning can reference a variant, and a template-level BOM may need attribute-based substitutions to cover every variant. Decide whether each variant carries its own BOM or whether a shared BOM takes attribute-driven component changes, because this affects costing and material requirements planning. Check in a test environment that a work order for one variant consumes the right components and produces the right finished variant, and that the cost roll-up uses the expected component set.

When separate items are the better choice

Use separate items instead of variants when the products differ in more than appearance. If two sizes of a product come from different suppliers, carry different costs, use different bills of materials or need different regulatory data such as certificates, hazard classifications or tariff codes, the variants share little beyond a name. In that case a variant structure forces every attribute change through the template, and the template then has to serve products that do not really belong together. Separate items give each product its own purchase terms, valuation, BOM and compliance fields, and they keep reports on one product from being filtered by an attribute that does not apply to it.

Variants also become the wrong route when their lifecycles diverge. A color variant that is discontinued while its siblings continue, or a model that is redesigned while the previous generation keeps selling, needs its own status, reorder rules and pricing history. Variants inherit most of their setup from the template, so each exception becomes an override that someone must find and maintain. The cost of separate items is the reverse: you maintain more item records, and product families are no longer grouped automatically in stock and sales reports. You can recover some of that grouping with item groups, brands or a custom field that names the family, but those are manual disciplines your team has to keep.

Before committing, build a test with one real product family. Create it both ways in a sandbox, using the attributes you expect to need, then run a purchase receipt, a sales order, a price list update, a BOM change and a discontinuation through each structure. Check how the stock ledger, item-wise sales reports and purchase analysis read the result, and count the clicks needed for a routine change. Confirm with your implementation partner how the chosen version handles variant attributes and reporting, since behavior has changed across ERPNext releases. The test takes an afternoon, and it shows which route your team will actually maintain.

How apparel, furniture and manufacturing teams model variations

Apparel is the most common case for item variants. A single style, such as a knit polo, is sold in a fixed grid of sizes and colors, and each combination needs its own stock count, barcode and sales history. In ERPNext, the team usually creates one item template for the style and generates a variant for each size and color pair from the attributes. The template holds the shared description, tax template and default settings, while each variant carries its own item code.

Attribute values: Define Size and Color as item attributes with the exact values the business sells, such as the sizes printed on labels. Changing values later affects existing variants, so agree the list before generating.
Variant naming: Set a consistent naming convention for item codes so receiving, picking and reporting can read them without a lookup.
Stock by variant: Each size and color is tracked separately in the stock ledger, so a missing medium navy polo shows as a gap, not as a shortfall of the style.
Pricing: Confirm whether one price applies to all variants or whether certain sizes, such as extended sizes, need their own price list entries.
Barcodes: Check how each variant's barcode is assigned and whether scanners read the variant code directly.

Before you generate the grid, confirm with merchandising whether any size or color is discontinued seasonally, because retired variants still hold history that reports will show.

Access, validation and custom logic for variant data

Variant data touches item templates, attributes and the pricing and stock records built on them, so who can change those records and how rules are added matters as much as the initial model. The cards below cover permissions, template changes after variants exist, and the scripting limits that decide how validation can be built.

Role permissions on items and attributes

Item and Item Attribute are separate DocTypes, so a user can be allowed to create a variant but not to edit the attribute values that every variant depends on. Review which roles can create, edit and delete item templates, attributes and attribute values, and confirm that sales and purchasing users only read them. Test each role with a sample template before go-live, because a permission gap here changes the catalog for every product line at once.

Changing templates after variants exist

Once variants have transactions, changing the template's attributes or attribute values can alter how existing items are described and reported. Decide in advance who approves changes to attribute lists, and whether new values should be added rather than renamed. Ask your implementation partner to document the change procedure, including how to handle a value that was entered incorrectly after stock or sales were recorded against it.

Validation through standard settings first

Many variant rules can be enforced with the built-in setup, such as required attributes, allowed values and naming conventions, before any code is written. Check which checks your team needs and whether the standard configuration covers them. Custom fields and Client Scripts can add form-level behavior, but they should not be the only control for rules that affect pricing, stock or accounting.

Server Scripts must be enabled

Server Scripts run Python on document events, so they are the usual route for validation that must hold on every save, including imports and API calls. From version 15, they are disabled by default and must be enabled through the server_script_enabled setting, which your administrator controls. Frappe Cloud public shared benches do not allow them, so confirm your hosting option before designing logic that depends on them.

Reviewing custom logic before release

Custom scripts that change variant generation or pricing need the same review as code, with a named owner, a test site and a record of each change. Confirm who can enable scripts in production, how scripts are exported and versioned, and how a failed script is rolled back. Ask for a written list of every custom rule so that upgrades and audits can check each one against the release notes.

Questions buyers ask before hiring help with item variants

What drives the cost of an item variant model in ERPNext?

The cost depends mostly on how many attributes and attribute values the catalog needs, how many existing SKUs must be converted, and how many downstream places depend on those items. Each attribute adds design decisions about naming, units and which variants should exist at all, and each existing product line adds mapping and checking work. Pricing rules, price lists and reporting that must work across variants add further configuration. Ask the partner for a written scope that lists attributes, expected template count, number of SKUs to convert, and each integration that reads item codes. Fixed-scope work is usually quoted from that list, so a complete inventory of attributes before the quote is the most useful input you can prepare.

How long does the design and setup phase take for item variants?

Duration is set by decisions, not by the act of creating records. The phase usually runs longer when attribute rules are unsettled, when sizes or colors differ by product family, or when sales, purchasing and warehouse teams disagree on what a variant is. Data quality also matters: inconsistent units, duplicate descriptions and missing barcodes take time to resolve before any template can be built. Ask for a timeline in the written scope that separates the design workshop, the template build, the test import and the sign-off. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the schedule should reflect the number of decisions your teams can make in advance.

What does the client need to provide before variant work starts?

The work needs product data, agreed attribute definitions and a set of sample SKUs that represent each product family. Product data includes item codes, descriptions, units of measure, barcodes, current prices and any supplier codes. Attribute definitions should state the allowed values for size, color or model, the order they display in, and who approves new values. Sample SKUs, typically a few representative items from each family with their real stock and sales history, let the team test template behavior before the full catalog is converted. Ask the partner to list these inputs, their format and the owner on your side in the scope document, along with a date by which each is due.

Can our internal team set up item variants without outside help?

Yes, for a small catalog with few attributes and one owner who understands both the product structure and ERPNext item settings. ERPNext includes item templates and attributes, so a trained administrator can build a basic model with the documentation and a test environment. Outside help becomes more useful when the catalog is large, when existing SKUs must be converted without breaking stock history, when pricing, barcodes and integrations depend on the item structure, or when the team has no time to test. A practical approach is to have your team build a pilot template in a test site, then decide which parts to hand over. Ask any partner to separate the work they will do from the work your team keeps.

How are existing SKUs migrated into a variant structure?

Migration maps each existing item to a template and attribute values, then decides whether old items are kept, renamed, merged or disabled. The main risk is stock and transaction history: items that already carry stock, open orders or purchase history need a plan so that balances and reports stay correct. ERPNext's Data Import tool can import and update records from CSV or Excel files and supports child table rows, but its documentation advises importing only a few thousand records at a time, so large catalogs are loaded in batches with checks between them. Ask for a written mapping table, a test import on a copy of production data, and reconciliation reports for stock and open documents before cutover.

When is a retainer more useful than a fixed-scope variant project?

A fixed-scope project suits a defined catalog with agreed attributes and a clear end state. A retainer is more useful when the catalog keeps changing, when new product families are added every season, or when the team needs help with attribute governance, new pricing rules and upgrades over time. Retainers cover ongoing changes and support rather than one conversion. Ask for the scope of included requests, response expectations and how additional work is quoted. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and quotes both fixed-scope work and retainers from a written scope.

Limits to confirm in your ERPNext version and environment

Variant behavior in ERPNext depends on the version you run, the apps installed beside it and the data you already hold. The cards below list what to confirm with vendor documentation and a test run before you commit an item model to production.

ERPNext version and variant behavior

Confirm how item templates, attributes and variant generation behave in the exact ERPNext version you will run, not in the version a blog post describes. Supported versions are listed on Frappe's policy page, and the supported majors receive frequent minor releases, so read the release notes for the minor you plan to deploy. Record the version in your design document, because a later upgrade may change variant handling.

Attribute and variant count limits

Ask the vendor and test in your environment how many attributes, attribute values and generated variants a single template can carry before list views, pricing lookups and reports slow down. Build a representative test template with your real size, color and model counts and time the common screens. Do not assume a ceiling. Write down the largest count you validated so the catalog plan stays inside it.

Interaction with installed apps

Confirm how variants interact with the apps and customizations you have installed, including custom fields on Item, custom print formats, pricing rules, stock reports and any integration that reads item codes. A custom script written against a parent item may not handle variant rows. Test each sales, purchasing and stock flow that touches variants end to end, and note which apps you must upgrade together.

Mapping existing item codes and barcodes

Decide how your current SKUs, legacy item codes and barcodes map to templates and variants before any import. Check the Data Import template for item records and confirm whether the import creates variants, updates existing rows or only reads them. Test barcode lookups on variant items, since a barcode printed on a parent code will not resolve to the sellable variant. Keep a mapping sheet that the migration team signs off.

Scripts and server-side rules

If your variant logic depends on Server Scripts, confirm your target version and hosting before design. Since version 15, Server Scripts are disabled by default and must be enabled with the server_script_enabled setting, and public shared benches on Frappe Cloud do not allow them. Test whether your pricing or naming rules need a custom app instead, and confirm that choice with your hosting plan.

How DeployOpen scopes and delivers ERPNext variant setup

DeployOpen plans, builds, documents and supports ERPNext item variants inside your own infrastructure, starting from a written scope. We model your attribute set, variant rules and pricing against how your sales and stock teams work, then hand the configuration over with the evidence your team needs to run it.

How we scope

Inventory of your product families, attributes and the sizes, colors and models each one carries today.
A written decision on which products become templates with variants and which stay separate items.
Agreed list of pricing rules, UOM and barcode needs, and the reports variant stock must feed.
Fixed-scope engagement: deliverables and timelines are agreed in writing before work starts.

How we build

Attribute values and item templates configured in a non-production ERPNext site first.
Variant generation tested with sample items, including edge cases such as discontinued attribute values.
Variant pricing and price list behavior checked against your quotation and invoice documents.
Any custom fields or scripts reviewed for upgrade impact before they reach production.

How we hand over

Documented attribute and naming conventions your catalog team can apply to new products.
Test records and a sign-off checklist covering purchasing, stock, selling and invoicing flows.
Runbook for adding attributes, creating variants and handling changes to existing variant items.
Walkthrough sessions with the users who create items and handle day-to-day stock movements.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainer scope can cover reviewing new variant families before launch and checking releases for impact.
Ask any provider which ERPNext versions they cover and how they test upgrades against your configuration.
Confirm with us in the quote how changes after go-live are logged, tested and approved.

ERPNext item variants for sizes, colors and models