Electronic Shelf Label Data Readiness: How to Audit SKU, Price, and Store Data Before Integration

Electronic shelf labels display the data that connected retail systems send to them. A gateway, API, and label can all work correctly while the shelf still shows the wrong product, price, promotion, unit information, or store-specific offer.

The cause may be a duplicated SKU, an ambiguous system of record, a missing expiration time, an incorrect store code, a template field that does not fit the display, or a physical label that remains bound to a discontinued product.

Quick answer: An electronic shelf label data readiness audit should trace every required field from its approved source to the physical label, measure whether the data is fit for its intended use, define validation and error actions, test full and incremental changes, and document the evidence required for cutover approval.

An electronic shelf label solution normally combines label hardware, gateways, management software, product and price data, and connections to other retail systems. Data readiness determines whether those components can exchange the correct business meaning, not merely whether they can exchange a technically valid message.

What Electronic Shelf Label Data Readiness Means

Electronic shelf label data readiness is the condition in which approved retail data can move from its source systems to the correct physical labels without unresolved identity, format, timing, scope, transformation, or ownership conflicts.

Technical connectivity answers:

Can the systems communicate?

Data readiness answers:

Can the systems communicate the correct product, price, store rule, timing, and display result?

An API acceptance response does not automatically prove that:

• The product identifier refers to the intended selling unit.
• The price is the currently approved price for the selected store.
• The promotion applies to the customer and channel.
• The unit-price inputs are complete.
• The text fits the assigned label template.
• The correct physical label is bound to the product.
• An expired or discontinued record will be removed correctly.

Readers who need the hardware and communication foundation can first review how electronic shelf labels work. This guide concentrates on the business data and approval process that must be completed before live integration.

An Eight-Step ESL Data Readiness Audit

The audit should follow a project sequence rather than becoming a collection of unrelated field checks.

1. Inventory source systems and data flows.
2. Profile the existing data and establish a quality baseline.
3. Define ownership and the source of truth for each field.
4. Resolve product identity and packaging relationships.
5. Audit price, promotion, store, template, and binding data.
6. Build source-to-target mappings and validation actions.
7. Test full loads, incremental changes, failures, and deactivations.
8. Reconcile the final result and approve cutover or rollback.

This process complements the broader electronic shelf labelling workflow, but it deliberately focuses on the information that enters and leaves each system.

Step 1: Inventory Source Systems and Build Data Lineage

Start by identifying every system that creates, changes, transforms, or stores data used by the ESL workflow. Depending on the retailer, these may include:

• ERP or product master
• PIM platform
• POS pricing service
• Promotion or loyalty engine
• Store master
• E-commerce platform
• Integration middleware
• ESL management platform
• Store gateway
• Physical label and product-to-label binding record

For every critical field, document the path:

A data lineage document prevents a later team from treating a transformed value as though it came directly from the product or pricing master.

Step 2: Profile Data Quality Before Designing the Mapping

Do not begin by manually correcting a few visible records. First measure the current condition of the data.

The UK Government Data Quality Framework describes data quality as fitness for purpose and recommends assessing quality across the data lifecycle. Its related guidance identifies accuracy, completeness, uniqueness, consistency, timeliness, and validity as useful dimensions rather than assuming that one measure proves quality.

Referential integrity is added here as a project-specific control because an ESL workflow depends on relationships among products, stores, prices, templates, and devices.

There is no universal quality percentage that makes every retailer ready. The team should identify critical fields, profile the complete data set where feasible, and define project-specific blocking conditions before corrections begin.

Step 3: Define the Source of Truth for Every Field

A retailer may legitimately keep product descriptions in a PIM, regular prices in a pricing engine, local overrides in a store workflow, and label bindings in the ESL platform. The risk begins when more than one system can change the same business field without an approved priority rule.

Ownership should be defined by field. A statement that one application "owns retail data" is not enough when another application can still override a price or store scope.

Supplier architecture affects which ownership and validation controls are available. Review these requirements while choosing a retail ESL solution, rather than discovering them after the mapping has been built.

Step 4: Resolve Product Identity, GTIN, and Packaging

Product identity is the foundation of every later price, template, and binding decision.

Separate Internal SKU and GTIN Roles

An internal SKU is usually created for the retailer's own operations. GS1 explains that a Global Trade Item Number can uniquely identify trade items that may be priced, ordered, or invoiced.

A retailer may use either or both identifiers in its ESL workflow, but the relationship must remain unambiguous. For every active selling unit, verify:

• Internal SKU
• GTIN where applicable
• Product name and approved short name
• Brand and variant
• Pack size and selling unit
• Net quantity and quantity unit
• Product status
• Applicable stores and channels
• Template group

Check Packaging Levels and Variants

GS1 guidance treats units, packs, cases, and other packaging levels as linked trade items with their own identifiers where appropriate. A case-level identifier should not silently replace the identifier for an individual selling unit.

Flag conditions such as:

• One SKU representing several separately priced selling units
• Different active SKUs sharing one GTIN incorrectly
• A multipack and a single item sharing an ambiguous quantity basis
• A product description that omits flavor, size, color, or another priced variant
• Pack quantity stored only in uncontrolled free text

Resolve Duplicates Without Breaking Dependencies

Do not delete a duplicate merely because its description looks similar to another record. Determine which systems, historical transactions, promotions, and label bindings still reference it.

A duplicate-resolution record should identify:

• The approved survivor SKU
• The record to be retired
• Verified identifier mappings
• Dependent labels and stores
• Required rebindings
• Historical retention rules
• The date after which the retired record must no longer publish

Step 5: Audit Price, Store, Template, and Binding Data

Price and Promotion Data

Every regular price should identify the product, store or price zone, currency, selling unit, price type, version, effective time, approval status, and source system.

A promotion additionally needs eligible products, stores, channels, customer conditions, priority, quantity conditions, start time, expiration time, and the approved price that follows expiration.

For system-to-system timestamps, the RFC 3339 date-time format provides a standard Internet representation that includes a defined relationship to UTC. The project must still decide whether campaign rules follow store-local time, a regional rule, or another approved business time zone.

Unit-price inputs require special attention. For retailers operating in the European Union, the European Commission explains that the selling price and price per unit of measurement are covered by the Price Indication Directive. Other markets require their own regulatory review.

Incorrect data can have a direct customer impact. The guide to what happens when price displays are wrong explains why price accuracy, exception handling, and correction evidence should be treated as operational controls rather than cosmetic details.

Store and Channel Scope

Every connected system should use compatible controlled identifiers for stores, regions, price zones, fulfillment locations, online markets, and currency regions.

A store name is not a reliable integration key. Names can change, repeat, or contain inconsistent abbreviations.

For local overrides, record the approving role, product, store, start time, expiration or review date, reason, replacement rule, and audit reference. Online-only, app-only, loyalty-only, delivery-only, and pickup-only offers also need explicit channel eligibility rather than a free-text campaign name.

Template Requirements

Valid product and price data may still fail when they do not fit the assigned display.

For each label size and template, document:

• Required and optional fields
• Maximum text length and number of lines
• Supported characters and languages
• Price, currency, and unit formatting
• Barcode, QR, or image requirements
• Promotion badge rules
• Fallback behavior

Test long names, large prices, multiple languages, and missing optional fields. Update behavior also depends on the display and workload, so the existing guide to ESL refresh rates and display performance should be considered when defining realistic test results.

Product-to-Label Binding

A correct payload can still appear beside the wrong product when the physical binding is wrong.

A recommended binding record should include the store, zone, fixture, product, label ID, label model, template, binding time, binding method, operator or system, verification status, and last change. Actual fields vary by platform.

Test product relocation, shelf resets, label replacement, discontinued products, temporary promotion displays, multiple facings, and products displayed in more than one location. Physical deployment procedures should align with the site's electronic shelf label installation guidance.

Step 6: Build the Mapping and Validation Matrix

A useful mapping document should record more than source and destination field names.

The complete working version should also include data type, required status, null handling, default policy, code-set mapping, mapping version, test case, lineage reference, and change approver.

Step 7: Test Full Loads, Changes, Failures, and Deactivations

Do not make the first full data transfer a customer-facing event. Use test labels, a controlled fixture, a pilot location, or another environment approved for the project.

Test the Initial Full Load

Select representative records including regular prices, promotions, multipacks, unit-priced products, local overrides, long names, multilingual content, inactive products, multiple label sizes, and products displayed in several locations.

Test Incremental Changes

Verify that the process handles:

• A normal price update
• A corrected product description
• A future promotion
• Promotion expiration and replacement price
• A store-scope change
• A product relocation and label rebinding
• A newly activated product

Test Invalid Data Deliberately

Submit controlled failures such as:

• Unknown SKU
• Missing store ID
• Duplicate or older version
• Promotion without expiration
• Unsupported currency
• Invalid quantity unit
• Missing mandatory display name
• Unregistered label
• Template mismatch

The expected result should be the documented rejection, quarantine, fallback, or review process. Invalid data should not publish silently.

Test Deactivation and Deletion

Data readiness also includes removal. Test:

• Discontinued SKU
• Replacement SKU
• Cancelled promotion
• Expired local override
• Unbound or replaced label
• Store closure or removal from a price cluster

The project should define whether the interface uses status changes, deletion events, tombstone records, end dates, or another controlled mechanism. Historical records may need retention even after publication is stopped.

Reconcile the Final Output

Compare:

1. The approved source record
2. The extracted and transformed integration record
3. The ESL platform record
4. The device or endpoint status where supported
5. The visible physical label and product placement

When a device does not update, distinguish data, binding, gateway, network, template, and hardware causes. The article on electronic shelf labels not updating provides a separate troubleshooting path.

Step 8: Plan Cutover, Rollback, and Final Sign-Off

A successful dry test does not complete the audit. The team still needs a controlled transition to production.

Before Cutover

• Approve the mapping and validation-rule versions.
• Resolve all blocking defects.
• Record conditionally accepted issues and excluded records.
• Define a data-freeze or controlled-change window where appropriate.
• Capture the final full or incremental source extract.
• Confirm owners, contacts, and escalation paths.
• Document the rollback trigger and replacement state.

During Cutover

• Record the load or event batch identifier.
• Monitor rejected, quarantined, delayed, and unconfirmed records.
• Reconcile critical prices, stores, templates, and bindings.
• Prevent an older delayed version from replacing the approved state.
• Stop or roll back when a defined blocking condition occurs.

After Cutover

• Complete the first production reconciliation.
• Confirm that expired and discontinued records cannot republish.
• Close or assign every open exception.
• Save logs, screenshots, test evidence, and the final approval.
• Define monitoring for data-quality regression and mapping changes.

Communication architecture can affect acknowledgement and retry behavior, so platform-specific assumptions should be checked against the comparison of Bluetooth, Wi-Fi, and Sub-GHz ESL communication.

Illustrative Data Audit Example

The following example is hypothetical and demonstrates the process rather than claiming a customer result.

A retailer plans to deploy ESLs for a 500 g yogurt sold in several stores. Data profiling finds:

• SKU YOG-500-A and YOG500A refer to the same selling unit.
• Only one record contains the verified GTIN.
• Net quantity is stored as "500g" in one system and as separate value and unit fields in another.
• A member promotion has a start time but no expiration.
• One override uses a store name instead of the controlled store ID.
• Two shelf labels remain bound to the duplicate SKU that should be retired.

The project should block live distribution for those records. A controlled correction would:

1. Select the approved active SKU.
2. Preserve the verified GTIN relationship.
3. Standardize quantity as value 500 and unit g.
4. Add the approved promotion expiration and replacement price.
5. Replace the free-text store name with the controlled store ID.
6. Rebind the physical labels to the approved SKU.
7. Deactivate the duplicate publication path without losing required history.
8. Test full load, promotion activation, expiration, and later incremental updates.
9. Reconcile the source record, platform state, and visible labels.

The data becomes ready only when the retired path can no longer publish an unintended event and the final evidence is approved.

Use Clear Release Gates

The cost of poor data may appear as rework, delayed rollout, incorrect prices, extra support, and unnecessary hardware investigation. These items should be considered alongside the real costs of electronic shelf labels.

Audit Deliverables to Keep

The final audit package should contain:

• Source-system inventory and data-lineage map
• Data profiling and quality report
• Field ownership matrix
• Approved SKU, GTIN, and packaging decisions
• Source-to-target mapping version
• Validation, fallback, rejection, and quarantine rules
• Open and closed exception report
• Full-load and incremental test evidence
• Deactivation, rebinding, and rollback results
• Final source-to-label reconciliation
• Conditionally accepted issues and exclusions
• Named business and technical approvals

In grocery environments, product quantities, unit prices, frequent promotions, and local store rules often increase data complexity. The guide to supermarket electronic price tags provides additional deployment context.

Common Data Readiness Mistakes

• Starting with API development: an interface built before ownership and meaning are defined only moves ambiguity faster.
• Cleaning only product names: identity, price, time, quantity, store, template, and binding data also require validation.
• Testing only valid records: the workflow must prove that invalid and stale records are stopped.
• Deleting duplicates without dependency analysis: old labels, transactions, or campaigns may still reference the retired record.
• Using free text for controlled decisions: stores, units, currencies, channels, price types, and statuses should use approved codes where practical.
• Assuming the ESL platform repairs source data: a platform may transform a known value but should not invent missing business meaning.
• Skipping deactivation tests: a product or promotion that cannot be removed safely is not ready.
• Approving an API response without physical reconciliation: a correct payload can still reach the wrong label or shelf position.

Final Takeaway

Electronic shelf label data readiness is not a one-time spreadsheet cleanup. It is a controlled agreement about product identity, ownership, price and store scope, transformations, template requirements, physical binding, validation, error handling, testing, and approval.

Before live integration, the retailer should be able to trace every critical field from its approved source to the physical label, demonstrate how invalid and outdated records are stopped, and show who approved the final result.

Review the available electronic shelf labels and discuss source systems, label formats, binding processes, integration scope, and audit evidence with the LEGOYO team before defining a production rollout.