The GDSN Attribute List for Food: What Publishes and What Rejects

Seven attributes. That is the entire list a GDSN message cannot be published without: the GTIN, the trade item unit descriptor, the information provider's GLN and party name, the target market, the GPC category code, and the brand name. A food brand can push an item through the pool on seven fields. Then the retailer opens it and refuses it for the dozens it left blank, or accepts it and bills the brand for the one it filled in wrong.

Which attributes are required has three different answers depending on who is asking. GS1's own guidance for retail grocery sorts the list into tiers: GDSN Mandatory, where "a message cannot be published without these elements," and Required, where "a message may not be accepted by a Trading Partner if these attributes are not completed". The practice adds a third tier GS1 does not name: the attributes that publish clean, pass the retailer, and generate deductions every week after.

Seven fields publish. Dozens get you accepted.

The mandatory seven identify the item and its owner; they say nothing about what the item is. Everything a buyer, a warehouse, or a label printer needs sits in the next tier, and GS1's Trade Item Implementation Guideline is explicit about how the tiers relate: the combination of information-provider GLN, GTIN, and target market is the key, and everything else hangs off it.

For a food item the second tier is where the work is. GS1 US's grocery guidance and its foodservice attribution guide together mark the fields recipients expect: the functional name and short description; net content, populated whenever the item is a consumer unit; height, width, depth, and gross weight at every hierarchy level; country of origin at the each; start availability date; storage temperature minimum and maximum; the ingredient statement; and the nutrition and allergen modules, which become mandatory the moment they are invoked, with "all nutrient information populated at the lowest GTIN in a hierarchy". Shelf life travels as minimum trade item lifespan from time of production, in days.

| Tier | What it means | Food examples | Who enforces it | |---|---|---|---| | GDSN Mandatory | Message will not publish | GTIN, unit descriptor, provider GLN and party name, target market, GPC code, brand name | The data pool, at validation | | Required by recipient | Retailer may refuse the publication | Net content, dimensions and weight per level, country of origin, nutrients, allergens, ingredients, storage temperature, shelf-life days, availability date | The retailer's playlist, at publication | | Bills you when wrong | Publishes clean, accepted, then deducts | Case pack, case dimensions and cube, gross weight, pallet TI/HI, shelf-life days, hierarchy links | The receiving dock, monthly |

The third row is the one no attribute list mentions, because nothing in GDSN is wrong with those values. They are well-formed, they pass every rule, and they are false.

The pool validates the format. The retailer validates the presence. Nobody in the chain validates the truth.

Every level of the hierarchy is its own list

The list is not filled in once per product. Each level in the item hierarchy must be identified with a GTIN, and in grocery that hierarchy normally includes retail point-of-sale, case, and pallet. Wakefern's implementation guide, published through 1WorldSync, states it as a requirement rather than a norm: trading partners are required to publish all applicable levels, each, pack, case, and pallet, with a GTIN at every level.

Cinderhaven Provisions is a fictional sauce and salsa brand, and its fifty SKUs and every figure below are a synthetic dataset; its hierarchy math is the ordinary kind. One consumer unit, one case, one pallet configuration per SKU: 150 GTINs, each carrying its own dimensions, weight, and quantity-of-next-lower-level. Call it forty attributes per level after the food modules, and the product master behind one GDSN publication is a 6,000-cell spreadsheet. Twelve of those columns generate most of the chargebacks: the physical and logistics fields, repeated three times.

The each-level values get the most attention because they carry the label copy, the nutrients, and the image. The case-level values get the least, and the case is what the distribution center receives, measures, scans, and fines. A net content typed carefully at the each and a case pack copied from last year's spec sheet is the normal division of effort, and it is backwards.

The each is what the shopper reads. The case is what the retailer bills against.

Validation runs three times, and none of them checks the carton

A published item is validated in layers. The GDSN operations manual makes the first one the source data pool's job: it shall validate item information against the GDSN validation rules, business rules of the form "if the item is a dispatch unit, gross weight shall be greater than zero." 1WorldSync, now part of Syndigo, runs two more on top: its own data quality and completeness validations, and recipient validations based on playlists, the attribute and rule sets each retailer registers. Any of the three can return a warning, which does not stop the sync, or an error, which does.

Consider what those rules can and cannot say. A rule can require that gross weight be greater than zero. It cannot know that the carton weighs 14.2 pounds and the field says 12.6. A playlist can require the case pack to be populated and can check that the case-level quantity multiplies out to the each-level count. It cannot know that the co-packer changed the pack from 12 to 6 in March and nobody updated the master. The three validations are a spelling check on a document whose sentences might be lies.

Cinderhaven's own ledger is the demonstration. Its case-pack field passed every layer and became the largest of its four invalid-deduction families, $27,000 a year in shortage claims, because purchase orders written against the published pack expected twice what the carton held. A case-cube figure four hundredths of a cubic foot off the physical box, keyed into a retailer portal with the same confidence, produced a $4,200 OTIF fine on a shipment that arrived on time and complete. Neither value ever tripped a rule. Both were formatted perfectly.

The validation stack is thorough about everything except whether the number is true.

Fill the list from the carton, not the spec sheet

The practical order of work follows the tiers backwards. Start with the third tier, the fields that bill: measure a physical case of each SKU on a real scale and a real tape, record case pack from the carton in hand, and derive TI/HI from a built pallet. Those values then feed the second tier, because the case dimensions and the quantity-of-next-lower-level are the same numbers the recipient playlist checks for internal consistency. The mandatory seven come last and take ten minutes, since each GTIN must already be registered in the GS1 Global Registry to build the hierarchy at all.

Then treat the published record as the single source and push it outward, because the retailers do. Walmart's implementation guide for GDSN says its system uses only the GDSN data for synchronized items; once synchronized, the pool's value overwrites whatever the portal held. That cuts both ways. A correct case cube in GDSN fixes the item file everywhere. A wrong one does too.

The seven errors that get a publication rejected are loud and cheap. The list above is about the ones that are quiet and expensive.

Three levels, twelve fields, one afternoon

Send me one SKU's GDSN export at all three hierarchy levels, and the co-packer spec sheet it was typed from. I will measure the billing-tier fields against each other and against the spec, and write back with which level disagrees with which, and what each disagreement is costing on the remittance. Send the export and the spec sheet. The rest of the line usually shares its mistakes.