Logistics master data is the relatively stable information that a logistics network expects to remain true long enough for planning and execution systems to use it repeatedly: product dimensions, weight, pack hierarchy, location identity, address, receiving constraints, handling requirements, partner identity, calendars and other foundational attributes.
The truck can be available. The warehouse can be efficient. The route can be clear. The software can be fast. If the carton dimensions are wrong, the delivery address is stale or the product is marked as ordinary freight when it requires a different handling rule, the network begins from a false premise.
Master data is where logistics stores the assumptions it intends to reuse. When those assumptions are wrong, every later optimisation can become a more efficient way of executing the wrong plan.
This is Article 105 in the extended How Logistics Works series. It owns one reader job: how stable descriptive data about products, places, partners and constraints becomes an upstream dependency for physical movement. EPCIS and Event Visibility remains the event-history owner. Inventory Accuracy remains the owner for whether recorded stock matches physical stock. This page asks a different question: was the reusable information describing the object and route correct before the transaction began?
A Route Through This Guide
What master data is · Master data versus event data · Product and packaging data · Location and receiver data · Ownership and source of truth · Changing master data safely · Worked example · Audit and evidence
Master Data Is Reused Context
A shipment event says that something happened. A master-data record describes the thing, place or party involved so later systems know how to interpret the event.
Examples include:
- a product’s dimensions and gross weight;
- the number of units in a case;
- whether the case may be stacked;
- the address and receiving hours of a customer site;
- the identity of a warehouse location;
- a carrier or trading partner identifier;
- a packaging hierarchy;
- the temperature or handling class assigned by the relevant product owner;
- a unit of measure and the conversion between selling, storage and transport units.
These facts change less frequently than orders and scans, but they are not permanent. A product can be repackaged. A customer can move. A warehouse can renumber locations. A receiving site can change its opening hours. Master data therefore needs maintenance rather than reverence.
A Warehouse Does Not Move “SKU 4812”; It Moves the Physical Thing the Data Claims SKU 4812 Is
When a planner builds a load, it usually does not remeasure every carton from first principles. It uses stored dimensions and weights. When a picker is told that one case contains twelve units, the system expects that packaging relationship to be true. When a route planner sends a vehicle to an address, it assumes the address identifies the intended receiving point.
That reuse is what makes scale possible. It is also what gives one bad attribute leverage across thousands of transactions.
Transactional scale amplifies master-data quality. Correct reusable data creates repeated efficiency. Incorrect reusable data creates repeated error.
Master Data, Transaction Data, Event Data and Sensor Data Are Different
| Data family | Typical question | Example |
|---|---|---|
| Master data | What is this object, party or place normally like? | Carton dimensions, customer address, site hours. |
| Transaction data | What business commitment exists? | Order 123 requires 20 units for Customer A. |
| Event data | What happened, where and when? | Pallet received at Dock 4 at 10:22. |
| Sensor data | What condition was observed continuously or repeatedly? | Temperature readings from a monitored shipment. |
These families interact. An event can identify a pallet; master data explains the product and location identifiers inside that event. A transaction can request five cases; master data defines how many units one case contains. Sensor data can show a temperature; the relevant product or shipment requirements determine whether that temperature is acceptable.
Do not solve every data problem by adding more events. A perfect stream of scans cannot compensate for a master record that says the receiver is at an obsolete address.
GS1 Treats Foundational Product Attributes as a Shared Data Problem
GS1’s Global Data Model defines a globally consistent set of foundational product attributes needed to list, order, store, move and sell products. Its Global Data Synchronisation Network is designed so trading partners can maintain and share current product information through certified data pools.
The logistics lesson is broader than one standard: when many partners repeatedly use the same product facts, each partner independently typing and maintaining its own version creates avoidable divergence. Synchronisation is valuable because the same changed attribute can propagate to the parties that depend on it.
The Source of Truth Should Be the Party Entitled and Able to Maintain the Fact
There is no universal database that should own every logistics fact.
- The product owner may own product dimensions and packaging hierarchy.
- The customer or facility owner may own its receiving address and access constraints.
- The warehouse may own internal location identities.
- The carrier may own its service calendars and equipment capabilities.
- A regulator or specialist function may own a classification or restriction that the logistics system must respect.
The important design is not to centralise everything. It is to know which source has authority for which attribute and how updates reach dependent systems.
Dimensions Are Planning Inputs, Not Cosmetic Catalogue Fields
Length, width and height affect:
- cartonisation;
- pallet patterns;
- storage-slot selection;
- parcel sortation eligibility;
- vehicle cube;
- airfreight volumetric charging;
- loading-bay and equipment fit;
- last-metre handling.
A five-centimetre error can be irrelevant for one small parcel and material when multiplied across hundreds of cartons in a trailer. The same attribute can therefore have different consequence depending on scale and geometry.
GS1 publishes a Package and Product Measurement Standard as part of the GDSN standards resources because a measurement is useful only when trading partners agree how it is taken.
Weight Needs a Meaning and a Unit
Net product weight, unit gross weight, case gross weight and pallet gross weight are not interchangeable. Nor are kilograms and pounds.
A planning system should know which object the weight describes and the unit in which it is expressed. Otherwise an apparently plausible number can be applied to the wrong packaging level.
This matters directly to Weight vs Cube. The binding capacity calculation is only as reliable as the dimensions and weights feeding it.
Pack Hierarchy Connects Selling Units to Logistics Units
A customer may order one piece. The warehouse may pick one inner pack. Transport may move one case. A pallet may contain forty cases. Those relationships need stable definitions.
If one case is changed from twelve units to ten units and one system keeps the old conversion, errors can appear as:
- short shipment;
- over-pick;
- incorrect replenishment;
- wrong freight dimensions;
- invoice disagreement;
- inventory imbalance.
Packaging changes should therefore be treated as operational changes, not merely marketing artwork changes.
Stackability and Orientation Are Master-Data Candidates When They Recur
Some handling properties are reusable enough to store: do not stack, keep upright, maximum stack height, lifting point, pallet overhang restriction or other product-specific instructions approved by the relevant owner.
The record should avoid pretending a generic flag can replace specialist packaging or safety requirements. Master data carries the operational instruction; the technical basis belongs to the proper engineering, quality or regulatory owner.
Temperature and Dangerous-Goods Data Have Higher Consequence
A wrong ordinary carton dimension can waste space. A wrong temperature or dangerous-goods classification can create a much more serious failure.
The logistics system should not infer specialist classification from convenience. It should consume an authorised current state from the competent owner and preserve version, source and effective date where these matter.
The current IATA cargo environment reinforces why common data matters. IATA’s 2026 cargo priorities identify fragmented systems and inconsistent data exchange as sources of duplication, delay and compliance risk, while ONE Record provides a common data model, API specification and security framework for air-cargo data sharing.
A New Product Should Not Enter Automation Before Its Required Data Is Ready
When a new SKU launches, operational systems often feel pressure to start shipping immediately. A strong readiness gate asks whether the information needed by the intended processes exists and has been validated.
- Can the warehouse identify and store it?
- Can the packaging be handled safely?
- Can the transport system calculate a feasible load?
- Does the parcel system accept the dimensions?
- Are receiving and handling rules known?
- Are controlled or regulated attributes resolved by the appropriate owner?
A placeholder value such as zero weight or 1 × 1 × 1 centimetres can allow an interface to pass while making the physical plan meaningless.
An Address Is Not Always the Receiving Location
A postal address may identify the property. Logistics may need a more specific operational location:
- which gate;
- which loading dock;
- which tower;
- which basement;
- which warehouse building;
- which internal receiving department.
Article 54, Delivery Instructions, explains the transaction-level receiver information. Master data owns the recurring site facts that should not need to be rediscovered on every order.
Location Identity Should Survive Formatting Differences
“12 Example Road”, “12 Example Rd” and a building nickname can all describe the same physical place. Systems should not create three independent customer locations merely because text differs.
Standard location identifiers help separate identity from presentation. GS1’s identification system uses the Global Location Number for parties and locations, while other industries have their own location-reference structures. The key logistics principle is persistent identity: rename the display text without losing the fact that old and new records refer to the same place.
Receiving Hours Are Operational Master Data Until the Exception Changes Them
A site may normally receive Monday to Friday from 8am to 5pm. That recurring pattern can support route planning. A public holiday closure or temporary dock outage is an exception or event, not necessarily a permanent master-data change.
Confusing these levels creates two failure modes:
- a temporary closure is written permanently into the location record;
- a permanent change is treated as a one-off note and repeatedly forgotten.
Master data needs effective dates and exception mechanisms rather than one undated text field.
Site Capability Is Part of Route Feasibility
A delivery location may have vehicle height limits, tail-lift needs, dock constraints, security procedures or restrictions on delivery size. These recurring capabilities can change which carrier, vehicle and route are feasible.
A route optimiser that sees only latitude and longitude can select a geographically elegant route that the vehicle cannot actually complete.
Duplicate Locations Create Split History
If the same receiver exists under several customer-location records, delivery history and instructions can fragment. One record carries the correct access note. Another carries the latest contact. A third carries most recent performance history.
Duplicate master data is therefore not only untidy administration. It can make the network forget its own experience because evidence accumulates under several identities.
Partner Master Data Controls Who the System Thinks It Is Dealing With
Carriers, suppliers, warehouses, customers and brokers can change names, ownership or systems. Stable partner identity matters for:
- booking;
- billing;
- service eligibility;
- data exchange;
- performance history;
- security and access;
- contract and operational routing.
A display-name change should not automatically create a new operational entity. Conversely, a genuinely different legal or service entity should not be merged merely because its name looks similar.
Every Important Attribute Needs an Owner
“Data team owns master data” is too broad. The data team may manage the system while lacking authority to decide what a product’s correct handling class is.
Separate:
- attribute owner — entitled to determine the business meaning;
- source system — where the current authoritative value is maintained;
- data steward — responsible for completeness, quality and workflow;
- consumer — downstream system or process that depends on it.
One person can hold several roles. The distinction matters because a downstream user should know where to send a correction rather than patching its own local copy indefinitely.
The Consumer Should Be Able to Challenge the Source
Suppose a warehouse physically measures a carton and finds a material difference from the master record. The warehouse should not silently change a supplier-owned product attribute without authority. It also should not ignore the evidence.
A good route is:
observe discrepancy → contain affected planning where necessary → preserve evidence → send correction to the authorised source → validate → publish updated master data → confirm dependent systems received it.
This allows the physical network to challenge the digital model without creating uncontrolled local truth.
Completeness Should Be Defined by the Process That Needs the Data
A product record can contain hundreds of attributes and still be incomplete for one logistics job. Another product can contain twenty fields and be completely usable.
Define required fields by process:
- receiving requires identity and quantity relationships;
- slotting requires dimensions, weight and compatibility;
- load planning requires weight and cube;
- last mile requires receiver location and access;
- specialist cargo requires its authorised handling attributes.
Data quality is therefore contextual. A field is valuable because a real decision depends on it.
Validate Plausibility, Not Only Format
A database can verify that weight is numeric. It may not know that a single pen weighing 900 kilograms is implausible.
Useful validation can include:
- allowed units;
- reasonable ranges;
- pack-hierarchy arithmetic;
- dimension ordering rules where applicable;
- mandatory combinations;
- reference-list membership;
- duplicate checks;
- physical sample verification.
Hard validation should block impossible values. Soft validation can flag unusual values for review without pretending they are impossible.
Units of Measure Deserve Their Own Control
Many data failures are not wrong numbers; they are numbers interpreted under the wrong unit.
Store unit explicitly. Avoid relying on a user to remember whether a field is millimetres, centimetres, metres, grams or kilograms. For conversions, make the conversion rule visible and tested.
A strong interface does not transmit “20” when the receiver must guess whether that means kilograms or pounds.
Master Data Needs Effective Dates
A product’s case size changes next month. Which orders use the old pack and which use the new pack?
If the master record is overwritten today, old stock may be interpreted under the future packaging rule. If it is updated only after the first new package ships, early orders can use stale planning data.
Where a change has a real transition period, use an effective boundary that the physical inventory and transaction system can recognise. This is the master-data version of Logistics Change Control.
Version the Meaning When the Meaning Changes
Changing a spelling mistake does not necessarily change business meaning. Changing the definition of “case height” or the method by which a handling class is assigned may.
When meaning changes, downstream consumers need more than a new value. They need to know that their interpretation may need to change as well.
DCSA’s 2026 digital-shipping roadmap makes this maintenance reality explicit: standards are versioned, validated and updated as implementation experience reveals needs. Data models are living infrastructure, not one-time documents.
Synchronisation Is Not Instantaneous Truth
Even a well-designed synchronisation network has propagation time. A source changes. A receiving system subscribes or consumes the update. Caches refresh. Local applications may apply the new state at different times.
For consequential changes, the network should know:
- when the source changed;
- when the update became effective;
- which consumers acknowledged it;
- which in-flight work remains governed by the old state.
Article 106 will take the problem that follows when systems disagree: Logistics Reconciliation.
Do Not Repair a Source Error With Permanent Local Overrides
A warehouse discovers that Product X is 15 centimetres taller than the shared record and changes its local WMS. The TMS keeps the old dimensions. The carrier portal keeps the old dimensions. The next warehouse keeps the old dimensions.
The local operation improves while the network fragments.
A temporary local control may be necessary while the source is corrected. It should have an owner and expiry so the workaround does not become a second permanent truth.
Data Lineage Makes a Master Value Challengeable
For an important attribute, the system should be able to answer:
- who supplied this value?
- when was it measured or approved?
- what unit and method were used?
- when did it become effective?
- what later corrections occurred?
This does not require every ordinary field to carry a forensic dossier. The level of lineage should follow the consequence of a wrong value and the cost of reconstructing it later.
Automation Raises the Cost of Bad Master Data
A person can sometimes notice that a carton obviously will not fit the assigned bin and stop. Automated storage, routing and robotics can execute large numbers of decisions before a person sees the pattern.
Automation therefore increases the value of:
- validation before release;
- change controls;
- monitoring for improbable outcomes;
- safe exception paths;
- fast correction propagation.
The Warehouse Robotics guide explains the physical automation layer. Master data is part of the information substrate beneath it.
Worked Example: The Carton That Was Smaller in the Computer Than in the Warehouse
The following is an invented example. A distributor launches a product packed six units per case. The product master records the case as 40 × 30 × 20 centimetres. The actual production case is 40 × 30 × 26 centimetres after a protective insert is added.
The WMS uses the dimensions for slotting. The TMS uses them for cube planning. An e-commerce packing system uses them when deciding whether the case can fit into a larger shipment carton.
The first symptom appears in the warehouse: cases assigned to one storage position do not fit as planned. Operators place them temporarily in nearby overflow locations. The inventory system still thinks the planned locations are valid.
The second symptom appears in transport: a load plan expects more cases to fit than the trailer can physically accept without changing the loading pattern. The planner removes cases at the dock and sends them on a later vehicle.
The third symptom appears in fulfilment: the cartonisation system chooses an outer package that is too shallow. Packers manually select another box. The automated recommendation continues to be wrong.
Three departments now have three workarounds. None is the root repair.
The warehouse measures several physical cases and preserves the evidence. The product owner confirms that the packaging design changed before launch and that the master-data update was missed. The authorised source updates the height to 26 centimetres with the correct effective state. Downstream systems receive the update.
The operation then checks the consequences:
- slotting is recalculated for affected stock;
- open load plans using the old value are revalidated;
- temporary local overrides are removed;
- future product-launch readiness now requires packaging dimensions after final protective material is confirmed.
The lesson is not “measure cartons more carefully”. It is that a packaging change crossed several logistics systems without a controlled master-data transition.
The Same Pattern Appears With Addresses
A customer moves its receiving function from Building A to Building C. Customer service updates free-text delivery notes. The customer-location master remains unchanged. Experienced drivers follow the note. A new driver follows the navigation address and reaches the wrong gate.
The workaround has preserved service while allowing the source record to remain stale.
The repair is to update the authoritative receiving location and confirm that routing, labels and customer instructions use the same current identity. Free text remains useful for temporary or order-specific detail; it should not become the permanent substitute for a correct location record.
Data Quality Metrics Should Point to Physical Consequence
“98% complete product records” can be useful but abstract. Ask which missing or incorrect fields create operational impact.
- percentage of active products with validated weight and dimensions;
- orders reworked because pack hierarchy is wrong;
- deliveries affected by stale location data;
- manual overrides caused by master-data discrepancies;
- time from discrepancy discovery to source correction;
- number of consumers still using an obsolete value after the effective date.
The objective is not a beautiful database. It is fewer physical decisions made from false reusable assumptions.
Master-Data Drift Can Hide Under Stable Transaction Performance
Operations can remain successful because experienced people correct bad dimensions, old addresses and wrong pack sizes manually. The customer receives the goods. The data problem remains.
Track manual correction and exception volume. A rise can be an early sign that the master model is drifting away from physical reality before headline delivery performance fails.
This connects directly to Logistics Drift.
Master Data at Three Zoom Levels
One product
Do the dimensions, weight, pack relationships and handling attributes describe the physical product currently being moved?
One facility
Do location identities, capacities, receiving constraints and calendars remain aligned with the real building?
One network
Can source-owned master-data changes propagate across partners without each participant maintaining a permanently divergent local copy?
A Singapore Lens
Singapore’s compact, highly connected logistics environment makes data quality especially visible. Port, airport, warehouse and urban-delivery flows can cross several systems over short physical distances. A stale address, wrong packaging attribute or inconsistent party identity can therefore consume more time at the digital handoff than the truck spends travelling between two points.
The island’s role as a regional hub also means local systems interact with international standards and partners. Common identifiers and reusable data models become valuable not because Singapore is unique, but because high connectivity multiplies the number of interfaces at which inconsistent master data can create friction.
Hostile Test: “The Order Was Correct, So the Data Was Fine”
How many people corrected the route manually? Was the carton repacked because the stored dimensions were wrong? Did the driver rely on a private note because the location master was stale? Did the load planner remove freight at the dock because the cube model was wrong?
A successful shipment can be evidence of good human recovery rather than good master data.
Logistics Master-Data Audit
- Which attributes are reused across many logistics transactions?
- Who owns the business meaning of each critical attribute?
- Which system is authoritative for the current value?
- What unit and packaging level does each measurement describe?
- Are product dimensions and weights physically validated at suitable points?
- Are pack hierarchies arithmetically consistent?
- Do location records identify the actual receiving point rather than only the postal property?
- Are receiving hours, vehicle restrictions and site capabilities current?
- Can duplicate products, locations and partners be detected?
- How are specialist handling attributes supplied by their proper owner?
- What fields are mandatory before a product or site may enter automation?
- How are effective dates handled?
- How are downstream systems notified of changes?
- Can consumers challenge a suspected source error without creating a permanent local fork?
- How long do temporary overrides survive?
- Can the source and history of a consequential value be reconstructed?
- How much manual work is caused by master-data defects?
Evidence and Further Reading
GS1’s Global Data Synchronisation Network explains how trading partners can maintain and automatically share current product information. The GS1 Global Data Model defines foundational product attributes used to list, order, store, move and sell products. IATA’s ONE Record shows the same interoperability problem in air cargo through a common data model, standard APIs and security specification. DCSA’s Track & Trace standard likewise emphasises standardised data definitions and interoperable exchange across maritime stakeholders.
Return to the Logistics Hub
Master data explains why logistics can fail before the first pallet moves: the reusable description of the product, location or partner is already wrong. Return to How Logistics Works to reconnect this data layer to the full physical chain. Continue next to Logistics Reconciliation | When Two Systems Disagree About the Same Shipment.
Final compression: logistics master data is reusable operational truth. It tells the network what the product is, where the receiver is, how the handling unit behaves and which recurring constraints apply. The strongest data model is not the one with the most fields. It is the one in which critical attributes have a clear owner, a trusted source, an effective date, a correction path and enough connection to physical reality that automation can act without repeatedly discovering that the world is different from the database.