The Item Master Data Standard: fields, capture, upkeep

Summary

An item master data standard is the agreed list of fields you capture for every SKU, plus the rules that keep those values true afterwards.

A complete record covers identity, naming, the unit-of-measure hierarchy, dimensions and weight at every level you handle, pallet configuration, handling attributes, and vendor, compliance and lifecycle data. It also covers where each value came from, which is the part almost every item master leaves out.

Most item master work goes wrong before the first scan, when a team starts capturing without agreeing what a complete record looks like. Three weeks in, packing asks for a field nobody recorded, and the work gets done twice.

This page is the field list, the sequence, and the rules that keep the data true afterwards.

Take what applies and ignore the rest, but decide each one deliberately. A blank field and a deliberate "not applicable" look identical in a database and mean opposite things.

Start here: record where every value came from

One thing has to be settled before anything else, because it changes everything downstream.

Most item masters we open hold a dimension and a weight, and nothing about where either came from. That missing context is what makes the file hard to keep current later.

A dimension on its own tells you what somebody believed at some point. It says nothing about whether that came from a laser, a tape, a supplier spreadsheet or a rushed guess.

So every value in the file looks equally trustworthy, which means none of them are, and nobody can say which to fix first.

Capture these alongside every measurement:

The method flag is the one to fight for. It turns a flat list into something you can triage.

Sort by method and every typed or supplier-supplied value becomes a visible candidate for re-measurement, while scanned values can be left alone. A cleanup you can plan beats one you have to do all at once.

The site field earns its place the moment you run more than one building, because two depots can measure the same product in the same week and disagree.

With a site and a date on every value you can write a rule: newest scan wins, or main depot wins. Any rule beats arguing case by case.

To be fair to the alternatives, the GS1 global data synchronisation network and most serious ERP item master specifications do go well beyond dimensions and weight, covering handling, hazmat, temperature and shelf life.

What they rarely carry is provenance. In the item masters we see in practice, the date and the method are almost never there.

Identity, naming and the unit-of-measure hierarchy

1. Identity

Every measurement has to attach to something your other systems recognise.

The failure this prevents is specific. The floor scans a barcode, the system stores an item number, and if nothing maps one to the other then every scan needs a human to match it afterwards. You have replaced one manual job with two.

Hold the item number as your key and record every other identifier against it: the GTIN or EAN printed on the each, the case-level GTIN (commonly expressed as a GTIN-14, though a case can also carry a GTIN-13 or GTIN-12 encoded in a 14-digit field), the supplier part number where the same item arrives from more than one source, and your internal code if it differs.

One warning that catches people out. A pallet label normally carries an SSCC.

Under the GS1 standards an SSCC identifies a logistic unit, meaning any combination of trade items packaged together for storage or transport, and it stays with that unit for its life. It does not identify the product. Trade items are identified by a GTIN.

Storing an SSCC in an item identifier field conflates the two, and it will not survive contact with your first serious integration.

Validate the format at the point of capture. A 13 digit EAN, a 14 digit case code and an 8 digit internal code are easy to separate with a rule and impossible to separate six weeks later.

2. Naming and description rules

Not glamorous, and it causes as much rework as a missing dimension.

Agree the description structure before anyone types one: what goes first, whether size and colour are part of the name or separate attributes, how abbreviations are handled, what case is used.

Agree the unit of issue as well, meaning the unit you buy in, the unit you stock in and the unit you sell in, since they are frequently different and frequently assumed to be the same.

Where you have AI vision capture available, label recognition can pull a lot of this straight off the packaging rather than having someone type it. That only helps if the target structure was agreed first.

3. The unit-of-measure hierarchy

A product exists at several levels at once, and this is where most item masters are thinnest.

The chain runs: each, then inner pack, then case, then layer, then pallet.

You need the quantities between each step: eaches per inner, inners per case, cases per layer, layers per pallet. The last two are often called TI and HI.

In the GS1 global data synchronisation attributes they are the quantity of trade items in a complete layer and the quantity of complete layers in a trade item, which is worth knowing because trading-partner spreadsheets do sometimes swap the two-letter labels. Use the full attribute names in any field spec you publish.

The layer step is the one most often missing, and it is exactly the one palletization needs.

Capture every level you physically handle, because which level matters depends on the job. Picking eaches needs each-level data. Goods-in and put-away need case and pallet.

Cartonization needs each-level, since it is deciding what fits in a box. Palletization needs case-level plus the pallet configuration below.

Never break a case? Then you may not need each-level dimensions. Record that as a decision rather than leaving the field blank.

Dimensions and weight

4. Dimensions

Length, width and height at every level you hold, plus three decisions made once.

Which side is which, and why there is no neutral answer

This is worth getting right because two established conventions disagree.

The GS1 Package and Product Measurement Standard anchors measurement to what it calls the Default Front: the surface with the largest area that the brand owner or manufacturer uses to promote the product to the consumer.

Once that face is fixed, height runs from the base to the top, width from left to right, and depth from front to back. For non-consumer trade items such as cases and display boxes, measurement is taken instead from the natural base, the underside of the packaged item before shipment.

Worth knowing, because it is widely misread: GS1 states plainly that this process gives a consistent, repeatable result and may not always represent the as-merchandised or shelf orientation of the product. The standard is not describing how the item sits on a shelf. It is describing a repeatable rule.

Carriers do something different again. They generally take length as the longest side overall and bill on length plus girth, where girth is twice the width plus twice the height, as UPS publishes it.

So a carton can honestly have two different sets of labelled dimensions depending on who is asking. Saying "any consistent convention works" is not good enough.

Pick one house rule, write it down, and record the mapping to both. If you supply retail, GS1 is usually the sensible master and the carrier view is derived. If you are a pure parcel shipper, the reverse.

What matters is that the mapping exists somewhere other than in one person's head.

Precision and rounding

This is the rule that saves the most money and it is the one most often missing.

Decide how precisely you record, and which way you round, because carriers round up and they round to their own unit. Store 398mm and a carrier billing in whole centimetres treats it as 40cm.

Hold the measured value at full precision in the master, and apply rounding at the point of use. Round in the master to suit one carrier and you have baked that carrier's rule into data that slotting, cartonization and capacity planning all read for different reasons.

Record the precision you measured to and keep it consistent. If a system forces you to round in the master, round up. Every consequence of understating size costs money: an under-quoted parcel, a box that will not close, a pallet that will not go in the rack.

Measured or nominal, and the compressible problem

Nominal comes off a supplier spec sheet and describes the product. Measured comes off the floor and includes the packaging, the shrink wrap and whatever the item settled into in transit.

Both are useful. Record which you have.

For soft or compressible goods, note whether the item was measured relaxed or compressed. A polybag of textiles has two honest answers and they are far apart. Store in one unit and convert on output, because mixed units inside a single item master is a problem that grows quietly and surfaces during an integration. If you handle pallets, the measuring method itself is worth standardising before anyone starts.

5. Weight

Gross is the whole thing as handled, product plus packaging. Net is the product alone. Tare is the packaging alone. Gross equals net plus tare.

People know this. What goes wrong is that someone records a field called "weight" without saying which one, and then two systems read it for opposite purposes.

Here is how that plays out on the freight side. You quote a shipment using net weight. The carrier reweighs at the hub, finds the real gross weight, rebills the difference and adds a correction fee.

You discover this weeks later on an invoice you cannot check, because you have nothing of your own to check it against.

Label every weight you capture. If you can only hold one, hold gross at every level, because gross is what gets lifted, stored and shipped.

Capture weight at every level you capture dimensions. A case weight is not the each weight times the quantity. The carton, the dividers and the tape are real, and they add up across a trailer.

Dimensional weight, and the divisor that decides it

Carriers charge for space as well as mass. Dimensional weight is length times width times height, divided by the carrier's dimensional factor, also called the volumetric divisor. The carrier bills whichever is greater, the actual weight or the dimensional weight.

Watch the divisor, because a smaller number means a higher billable weight for the same box. And it is not a constant. It changes by carrier, by rate table, by region and by contract:

The USPS change is the one worth reading carefully, because most coverage of it got the scope wrong.

USPS moved from 166 to 139 on 12 July 2026, and a second, quieter change went with it: fractional measurements now round up to the next whole inch, where the old rule rounded to the nearest.

That brings the number into line with FedEx and with UPS Daily Rates. It does not bring the scope into line, because USPS still applies dimensional weight only above one cubic foot, while FedEx and UPS apply it to everything. UPS also keeps 166 for its Retail Rates. The change is set out in the Federal Register notice of 15 May 2026.

Priority Mail Cubic and Ground Advantage Cubic are the exception on both counts: they are not dimensional-weight priced and they round down, to the nearest quarter inch.

For European operations, note that 139 in3/lb works out at roughly 5,166 cm3/kg. Above its threshold, USPS has effectively moved to the European parcel norm. And air freight has run on 6,000 cm3/kg throughout.

The divisors converge; the scopes do not. Store the measurement, not the billable weight, and let each rating engine apply its own rule.

This is also why dimension errors are not proportionate to their size. An error that pushes a box across a whole-unit boundary, or over a threshold, costs the same whether it was one millimetre or twenty.

Pallet configuration, handling attributes, and what travels with them

6. Pallet configuration

Without this, nothing can build a pallet or plan a trailer.

One naming trap on footprints. EPAL labels the 1200x1000 pallet EPAL 2 and calls it the industrial pallet.

EPAL 3 also has a 1200x1000 footprint but differs in construction and height, which is why you will see 1200x1000 called EUR 3 in the wild. Record the EPAL designation, not just the two dimensions.

7. Handling attributes

These decide whether an item can be planned by software at all.

Without them, a cartonization or palletization engine produces plans the floor cannot execute, and the floor goes back to doing it by eye.

Capture: stackable; maximum load on top, meaning the compression limit, and use that one name for it everywhere; fragile; compressible, where dimensions change under packing pressure; irregular shape, so a planner knows the volume figure is generous; orientation constraint, this way up; and hazard class and temperature constraint where they apply.

Most are a yes or no. They take a second while someone is already holding the item, and they are close to impossible to backfill from a desk.

8. Vendor, compliance and lifecycle fields

Not dimensional, and they belong in the same conversation because they are captured by the same people at the same moment.

Vendor data. Supplier item number, case pack quantity, minimum order quantity, lead time. These drive replenishment, and they are usually held somewhere other than the item master, which is how they end up contradicting it.

Compliance. HS or commodity code and country of origin, both needed at customs and both frequently missing until the shipment is held.

Lifecycle and traceability. Expiry and shelf life where they apply, and whether the item is under batch, lot or serial control. Get this wrong and no amount of correct dimensions will save the recall.

Storage rules. Temperature band, segregation requirements, whether the item can be stored on the floor or must be racked.

Which process needs which fields

Work backwards from whatever is currently blocked.

If you can only capture a little

Our recommendation for a defensible first pass, not a standard and not a rule: item number, one barcode with its level noted, case dimensions, case gross weight, TI and HI, stackable yes or no, and the three provenance fields.

Ten fields. It unblocks goods-in, put-away, palletization and a first transport rating, and every value carries enough context that the next person can tell what they are looking at.

Capturing it, and keeping it true

Agree the fields before anyone scans

The biggest cost in these projects is the rework, not the measuring.

Get goods-in, transport, packing, IT and whoever owns the WMS in one room, walk this list, and write down what you will capture and what you will not.

Then publish it, because the person scanning in month two will not be the person who was in the room.

Start where something is blocked

Do not work through the item list in order. Find the process that is stuck and capture what that process needs.

If slotting is blocked, you need each and case dimensions and weight for the SKUs in the zone being reslotted. That is a zone, not a catalogue.

If cartonization is stuck, you need each-level dimensions for the SKUs that actually appear in your order profile. In most operations that is a fraction of the range and it covers most order lines.

If transport rating is the problem, you only need the unit that ships. If you ship cases, the each dimensions can wait.

If automation is being designed, the constraint is usually the awkward end of the range rather than the volume end, because that is what determines the equipment.

Then the general heuristics: your fastest movers first, anything sitting near a carrier's size or weight threshold where a small error becomes a surcharge on every parcel, and anything with a visibly impossible value.

Whatever else you do, capture every new line from today. That stops the backlog growing while you decide what to do about the rest.

Do not measure what you already have

Build the check into the flow. The operator scans the barcode, the system looks for an existing record, and if a good one exists it says so and moves on.

This also stops two sites measuring the same product in the same week and producing two different answers.

A campaign, in-flow capture, or both

A campaign puts a small team through the catalogue in a defined window. Fast, focused, and it has an end date, which makes it easier to fund. It also stops when the campaign stops.

In-flow capture makes measuring part of booking goods in. Slower on the back catalogue, but it never stops and new lines are handled by default. Capturing master data for industrial parts is a good example of what that looks like in practice on an awkward range.

Most operations need both. A campaign clears the backlog, in-flow capture stops it rebuilding.

One warning from the floor. Capture added at the packing bench will be resisted, and the resistance is justified, because packing is measured on throughput.

Put capture where the item is already being handled and someone is already stationary and it costs seconds. Put it inside a timed process and it will quietly stop happening.

How long it takes

In the operations we work in, per-item capture time runs from around ten seconds to about a minute. That spread is not noise.

It depends on item size, how far the operator walks, how many packaging levels you are capturing, and how practised the operator is. The same tool at two sites in the same company gives different numbers.

So do not plan from anyone else's figure, ours included. Measure fifty items across your most awkward shape classes and use your own.

Then do the arithmetic honestly. At thirty seconds an item, 16,000 items is roughly 130 hours of pure capture, before walking and before the days somebody is off.

Call it one person for three or four weeks doing nothing else. If nobody is being taken off other work, a three month plan is not a plan.

Gate goods-in

The bluntest control is the most effective. Do not let an item complete goods-in until it has been measured.

Most warehouse management systems support this. Turn it on and the backlog stops growing today. It will slow inbound at first, which is the cost of not repeating this in two years.

Keep it true

Data rots. Suppliers change packaging, items get repacked, and a value that was right two years ago quietly stops being right.

Set a re-measurement cycle: a rolling rescan of a share of the catalogue each quarter, or a rule that flags anything measured more than a year ago.

Aim it with the method flag, so estimates and supplier-supplied values get re-measured first and scanned values are left alone. And write down a conflict rule for when two sites disagree.

If you have already started

Plenty of people reading this are a few thousand items into a capture built on an incomplete list. Recoverable, and usually cheaper than it feels.

Work in this order. First, what can be calculated from what you already hold, since cases per pallet can come from case dimensions and pallet footprint.

Second, what can be sourced from a document, because HS code, country of origin, case pack and lead time live in supplier data and can be pulled from a desk, as long as you set the method flag honestly.

Third, and only third, what genuinely needs re-handling, which is usually a handling attribute nobody thought to record. Do not recapture dimensions you already have. Add the missing field to the existing record.

The one thing worth going back for immediately is provenance. Without a date and a method you cannot triage anything.

Even a rough backfill, marking everything captured before a given date as unverified, restores your ability to prioritise.

Getting the data back where it is used

Capture that never reaches the consuming system is a spreadsheet with extra steps. Settle this before you scan, because it changes what you capture and how you identify it.

Decide which system is master. Your ERP or WMS, or the capture tool. If both believe they are master you get silent overwrites and no way to tell which value is current.

Most operations make the ERP master and treat capture as the source that feeds it.

Pick the direction of travel. Nearly everyone needs capture to write into the master. Many also need a read back the other way so the operator can be told an item already has a good record. That read is what makes the duplicate check possible.

Choose the pattern. A webhook that pushes each completed capture as it happens. An API the receiving system calls when it wants a record. A scheduled file export. Or a native connector where one exists.

Push suits continuous capture. Pull suits systems that want to control their own load. File export is the fallback when neither side will open an interface, and it is slower to reconcile.

Settle these before build starts. Field mapping, because their field names will not be yours. Where unit conversion happens, so it happens in one agreed place.

What happens when the target already holds a value: overwrite, write only if empty, or flag for a human. Error handling, retries, and who finds out when a write fails silently.

Consider a staging table. Rather than writing straight into the item master, land captures in a staging table and let your own integration promote them. Your master keeps its validation rules in one place and a bad capture never reaches production data.

What to ask a vendor. Which directions are supported. Which protocols. Does it write to my item master or to a staging area. Can I see failed writes and replay them.

What is the latency between a scan and the record being available. Is the mapping configurable by us, or does every change need their developers.

Those questions are worth asking whoever you buy from. They are the questions behind how Flux was built: capture runs on a device the operator already carries, every value arrives carrying its own date, method and evidence, and it writes into the systems that consume it rather than into a file somebody has to reconcile.

BME took that route for e-commerce fulfilment. Downstream, cartonization fed real dimensions rather than estimates removes 15% to 30% of the air from outbound boxes on our own customers' numbers, which is the return that pays for the capture.

‍