Product Master Data Sheet: Fields Every Brand Should Include

A product master data sheet looks simple until teams try to use it.

When key fields are missing, purchase orders drift from approved specs, suppliers fill in gaps on their own, packaging files get matched to the wrong SKU, and 3PL onboarding turns into a chase for carton dimensions, barcodes, and pack quantities.

Most brands already have a spreadsheet. The real question is whether it contains the right fields, at the right level, in a format other teams can actually use.

A good master data sheet should support:

SKU creation
supplier ordering
production approval
packaging handoff
barcode control
wholesale setup
3PL onboarding
carton labeling
inventory and pack hierarchy clarity

If it cannot do those jobs, it is not really master data. It is just a partial reference file.

Why a product master data sheet matters

Your product master data sheet should be the operational source of truth for product data.

That means one controlled place where your team can confirm:

what the product is
how variants differ
which SKU maps to which barcode
what goes in each carton
which dimensions and weights are approved
which supplier or factory is authorized to produce it
which files, versions, and notes apply

This matters more once a brand moves beyond a small catalog. As soon as you have multiple variants, multiple suppliers, retail requirements, or a 3PL, loose product data creates downstream cost quickly.

Typical failure points include:

wrong barcode assigned to the wrong variant
purchase orders using outdated carton quantities
warehouse receiving products with no clear unit-to-case relationship
retailers asking for dimensions, GTINs, or pack data that nobody can confirm
suppliers working from old packaging art or superseded specs

If you have already worked on How to Structure SKUs Properly (Before You Print Anything), the master data sheet is the next layer: the structured data behind those SKUs.

What a master data sheet is, and what it is not

A product master data sheet is not the same as every other product document.

Document	Primary purpose	What it should contain
Product master data sheet	Operational source of truth	SKU master data, variant data, dimensions, barcodes, pack/case hierarchy, supplier references, channel fields
Product specification sheet	Technical definition of a product	Materials, tolerances, formula, components, testing, compliance, construction details
Pricing sheet	Commercial pricing reference	Cost, wholesale price, MSRP, margin targets, channel pricing
Sales sheet	Buyer-facing summary	Product story, key claims, imagery, merchandising info

In practice, your master data sheet may reference other documents, but it should not try to replace all of them.

For example:

The master data sheet can include spec sheet version and packaging artwork version
It should not try to hold every packaging dieline note or every formulation parameter
It should link operational facts to the documents that govern them

That distinction matters. When brands try to cram everything into one sheet, nobody trusts it.

The minimum required fields every brand should capture

If you want a minimum viable master data sheet template, start here.

Core identity fields

These are the fields every row should have at the right level:

Product family or parent product name
Variant name
Internal SKU code
Full sellable SKU name
Status: active, pending, discontinued, seasonal
Brand name
Category or product type
Unit of measure
Country of origin

Commercial and operational identifiers

Internal product ID or item ID
Supplier item code
Factory item code if different
Purchase unit type: unit, inner, case
Standard order multiple
MOQ
Lead time

Barcode fields

At minimum, store the barcode data for the sellable unit:

GTIN or UPC/EAN for the retail unit
Barcode symbology used on pack
Barcode number in plain text
Barcode image or file reference if managed separately

If you are unclear on barcode structure, see GTINs Explained and Which Barcode Should I Use?.

Physical and logistics basics

Unit length
Unit width
Unit height
Unit gross weight
Unit net weight if relevant
Dimension unit: mm, cm, in
Weight unit: g, kg, oz, lb
Shelf life or expiry period if relevant
Storage conditions if relevant

Packaging and case basics

Units per inner pack
Inners per master carton
Units per master carton
Master carton dimensions
Master carton gross weight
Pallet quantity if standardized

File and control fields

Packaging artwork version
Spec sheet version
Approved date
Approved by
Last updated date
Data owner
Notes

Minimum checklist

Before you call your sheet usable, confirm it answers these questions:

Can a buyer place a supplier-ready order from it?
Can a packaging team identify the correct variant and barcode?
Can a 3PL set the item up without asking for carton dimensions later?
Can a wholesale team confirm unit and case configuration?
Can your team tell which version is approved?

If not, your core product data fields are still incomplete.

Product-level fields vs variant-level fields

One of the most common mistakes in product master data is mixing parent-level data with child-level data.

Product-level fields

These apply across a product family unless variants truly differ:

Brand
Product family name
Category
Base description
Core material or formula family
Regulatory notes common to all variants
Primary supplier or approved factory list
Base packaging format

Variant-level product data

These must sit at the actual SKU level when they vary:

SKU code
Size, color, scent, flavor, style
GTIN/UPC/EAN
Unit dimensions and weight
Packaging artwork version
Country-specific label version
Case pack if not uniform
Supplier item code if supplier distinguishes by variant

Example: fragrance brand

A simple fragrance line makes this easier to see.

Parent product: Everyday Candle 250g

Product-level fields:

Product family: Everyday Candle
Vessel type: clear glass
Wax type: soy blend
Packaging format: folding carton
Master brand: North Home

Variant-level fields:

SKU: CND-250-SEA
Variant: Sea Salt
GTIN: unique to Sea Salt
Artwork version: CND250SEA-v4
Unit weight: 610g
Carton text: scent-specific
SKU: CND-250-FIG
Variant: Fig Leaf
GTIN: unique to Fig Leaf
Artwork version: CND250FIG-v3
Unit weight: 612g
Carton text: scent-specific

If you store GTIN or artwork version only at parent level, you create avoidable errors.

Packaging, pack, and case hierarchy fields

Your sheet should not stop at the retail unit. Warehouse, wholesale, and freight teams need the pack hierarchy defined clearly.

At minimum, store the hierarchy explicitly:

Each: the sellable consumer unit
Inner pack: optional intermediate pack
Master carton: shipper level
Pallet: logistics level where standardized

Recommended pack hierarchy fields

Lowest sellable unit SKU
Inner pack code if used
Master carton code if used
Units per inner
Inners per master carton
Total units per master carton
Master carton barcode reference
Cases per pallet
Layers per pallet
Cases per layer
Pallet height

Example hierarchy

Level	Identifier	Quantity relationship	Key fields
Each	BEV-12-LMN	1 sellable unit	GTIN, unit dims, unit weight
Inner	BEV-12-LMN-IN6	6 units	inner qty, inner dims, inner barcode if used
Master carton	BEV-12-LMN-CS24	4 inners / 24 units	carton dims, carton weight, ITF-14
Pallet	PAL-BEV-12-LMN	70 cartons	cases/layer, layers, pallet height

This becomes essential for Master Carton Labelling Guide (Retail + 3PL + Warehouse) and for clean wholesale setup.

Barcode and GTIN fields to include

Barcode confusion usually starts because brands store one barcode field and assume that is enough.

Usually, it is not.

Barcode-related columns to include

Retail unit GTIN
Retail barcode type: UPC-A, EAN-13, etc.
Barcode number in human-readable form
Barcode owner or GS1 company prefix reference
Inner pack GTIN if used
Master carton GTIN or ITF-14
Logistics unit code or SSCC reference if relevant to your process
Barcode artwork file reference
Barcode status: assigned, approved, printed, retired

For brands still setting this up, How to Get a GS1 Barcode (Step-by-Step Guide for Brands & Founders) is worth reviewing before you assign codes casually.

Important rule

Keep barcode fields separate by packaging level.

Do not use one column called barcode if you have different identifiers for:

the retail unit
the carton
the pallet or logistics label

That is how retail-ready product data gets mixed up with warehouse identifiers.

Dimensions, weights, and logistics fields

These fields are often captured late, guessed, or stored without units. That causes trouble in freight quoting, 3PL setup, replenishment planning, and retailer onboarding.

Store dimensions with units every time

Use separate fields for:

unit length
unit width
unit height
dimension unit
unit gross weight
unit net weight
weight unit

Repeat the same structure for:

inner pack
master carton
pallet

Why this matters operationally

These fields support:

3PL receiving and bin slotting
freight class and shipment planning
carton label creation
retailer item setup forms
Amazon or marketplace packaging thresholds
warehouse handling notes

A clean row for product data used in 3PL onboarding should usually include:

SKU
product name
barcode
units per case
case dimensions
case weight
pallet quantity
temperature or handling notes
expiry or lot control flag

If your team is preparing inventory handoff, see How to Prepare Product Data for 3PL Onboarding.

Supplier, factory, and production fields

A master data sheet is not complete if purchasing still needs a separate chain of emails to know who can make the item and under what terms.

Supplier-ready product data fields

Include:

Approved supplier name
Factory name
Supplier contact or account owner
Supplier item code
Factory reference code
MOQ
Standard lead time in days
Reorder lead time if different
Incoterm
Port of loading
Country of manufacture
Purchase unit
Standard carton pack
Production notes
QC or approval notes

This makes the sheet far more useful when paired with How to Write a Supplier-Ready Purchase Order and Supplier Production Approval Checklist.

Add file references, not file chaos

Include columns for:

approved artwork file name
approved artwork version
approved spec version
approval date
approver

Then store the actual files in a controlled location. This reduces the version confusion covered in How to Hand Off Packaging Files to Suppliers Without Version Chaos.

Channel-specific fields: wholesale, ecommerce, marketplaces, and retail

Not every field belongs in the core sheet. The goal is to keep the core operationally clean, then add channel-specific data in separate tabs or linked views.

Keep the core sheet focused on operational truth

The core should hold stable product master data:

identifiers
physical specs
hierarchy
barcodes
supplier references
version control

Additive fields by channel

Wholesale / distributor

Wholesale case pack
buyer-facing case dimensions
showroom name
harmonized description
shelf-ready notes
distributor item code

Ecommerce / DTC

short title
long description
PDP bullet points
image references
bundle flags

Marketplace

channel title limits
channel-specific bullet copy
marketplace category mapping
dangerous goods flags

Retail

retail pack dimensions
shelf orientation notes
display-ready case flag
retailer item form references
planogram notes where relevant

If you sell into wholesale, Product Data Fields Wholesale Brands Should Have Ready Before Buyers Ask is a useful companion.

Common mistakes brands make with master data sheets

Most bad sheets fail in predictable ways.

1. Mixing levels

Putting parent product, variant, carton, and pallet information in one ambiguous row without clear level fields.

2. Missing units of measure

A number like 12 x 8 x 4 is useless if nobody knows whether it is inches or centimeters.

3. Using inconsistent names

For example:

Lavender 8oz
Lavender Candle 8 oz
Candle Lavender Small

Those look similar to humans and break matching across systems.

4. One barcode column for everything

Retail unit and carton identifiers need separate fields.

5. No ownership or approval status

If nobody owns updates, stale data survives.

6. No version control

Suppliers end up producing from an old artwork file, or your 3PL gets a superseded carton spec.

A practical master data sheet structure you can copy

For most brands, a simple tab structure works better than one overloaded sheet.

Recommended tabs

Products
- Parent product fields
Variants / SKUs
- Child SKU-level data
Packaging hierarchy
- Each, inner, master carton, pallet relationships
Barcodes
- GTIN and barcode fields by level
Suppliers
- Approved factory and purchasing data
Files and approvals
- Spec versions, artwork versions, dates, owners
Channel extensions
- Wholesale, retail, marketplace, ecommerce extras

Simple example for a DTC brand with one product and multiple variants

A hydration powder brand sells one product in three flavors.

Products tab

Product family: Daily Hydration Sticks
Format: 12-stick carton
Category: beverage mix
Brand: Peak Standard

Variants tab

HYD-12-LEM | Lemon Lime | 12-stick carton | active
HYD-12-BER | Mixed Berry | 12-stick carton | active
HYD-12-ORG | Orange | 12-stick carton | active

Packaging hierarchy tab

Each SKU = 1 retail carton
Master carton = 24 retail cartons
Pallet = 80 master cartons

Barcodes tab

HYD-12-LEM retail GTIN
HYD-12-LEM carton ITF-14
same structure for each flavor

3PL-ready row example

SKU	Units per master carton	Master carton dims	Master carton gross weight	Pallet qty	Handling notes
HYD-12-LEM	24	41 x 29 x 24 cm	8.6 kg	80 cartons	Keep dry; lot-controlled

That is enough to support receiving, storage planning, and outbound setup without a long clarification cycle.

How to keep the sheet accurate over time

A useful master data sheet is not just about setup. It needs change control.

Assign ownership

At minimum, define:

data owner for SKU setup
approver for packaging and barcode changes
approver for dimensions and logistics fields
owner for supplier and lead time updates

Use a change process

When a field changes, especially one tied to physical product or packaging, require:

change request
impact check
approval
update in master sheet
update to linked files or systems
controlled supplier or 3PL communication

Treat these changes as high risk

barcode updates
case pack changes
carton dimension changes
artwork version changes
supplier changes
country of origin changes

These are not casual edits. They affect ordering, labeling, compliance, and receiving.

FAQ

What is the difference between a product master data sheet and a product spec sheet?

A master data sheet holds operational product data used across purchasing, packaging, warehousing, and onboarding. A product specification sheet holds technical construction or formulation details. They should connect, but they are not the same file.

What are the minimum fields a master data sheet should include?

At minimum:

parent product name
variant name
SKU
status
supplier reference
GTIN or UPC/EAN
unit dimensions and weight
units per carton
carton dimensions and weight
lead time
MOQ
version and approval fields

Should I keep product-level and variant-level data in the same sheet?

You can, but only if the structure is very clear. In most cases, separate tabs for products and variants are cleaner and reduce duplication. Variant-level product data should always be explicit for fields that differ by SKU.

What fields do 3PLs usually need from a brand?

Usually:

SKU
product description
barcode
unit dimensions and weight
case pack
master carton dimensions and weight
pallet info if available
lot or expiry requirements
handling notes

How often should a master data sheet be updated?

Whenever approved product data changes. In practice, brands should review it at every new SKU launch, packaging revision, supplier change, case pack change, and before major 3PL or retail onboarding.

Do I need separate fields for retail units and cartons?

Yes. Retail-ready product data and logistics data should not be merged. Unit GTINs, carton barcodes, and pallet identifiers serve different purposes.

What is the best format for managing product master data?

For smaller teams, a controlled spreadsheet with clear tabs, owners, and version rules can work. As SKU count, suppliers, and channels grow, brands usually need a more structured system so SKU data, files, barcodes, and operational workflows stay aligned.

Build the sheet once, use it everywhere

The best product master data sheet fields are not the ones that look complete in a spreadsheet review. They are the ones that let real teams execute without guessing.

If your sheet can support supplier-ready product data, 3PL onboarding, pack hierarchy control, barcode assignment, and retail setup from one governed source, you are in good shape.

If it cannot, fix the structure before the next PO, packaging print run, or warehouse intake.

That work pays for itself in fewer supplier misunderstandings, less rework, cleaner onboarding, and fewer avoidable SKU errors.

If your team is moving beyond spreadsheets, SKUWorks is built to keep product data, SKUs, barcodes, purchase orders, packaging files, and operational approvals aligned in one place.