EDIFACT SLSRPT: Sales Data Report Message Guide

SLSRPT is the closest a supplier gets to seeing the till. Orders tell you what a retailer bought; sales data tells you what shoppers took home, store by store and week by week. That is the signal behind forecasting, vendor-managed replenishment and any honest review of whether a promotion worked.

This guide follows the GS1 EANCOM 2002 SLSRPT layout (directory D.01B, subset version EAN007). Every example is live: it is parsed in your browser by the same engine as our EDIFACT inspector, and you can open each one in the full tool.

What is an EDIFACT SLSRPT?

SLSRPT (sales data report) is the UN/EDIFACT message for reporting basic sales data for products: the location of the sale, the period, the product, and the price, quantity and value sold. GS1 defines it as a message that lets the recipient "process the information automatically and use it for production, marketing or statistical purposes".

According to the EANCOM manual, a recipient can read from it:

• the location of each sale
• the period in which it was sold
• the product, by GTIN
• the selling price, quantity and value
• extra identification such as promotional flags or product group codes

The usual direction is retailer to supplier. GS1 also describes a headquarters or distribution centre compiling sales across its outlets and sending them to a third party such as a market research company.

What SLSRPT is not

GS1's introduction is unusually direct on this point: the message "should never be used to replace business transactions such as Purchase Orders, Delivery Schedules or Inventory Reports." A sales report carries no instruction to ship, and it is not a stock report. In a replenishment programme it travels alongside an INVRPT, and the order still comes as ORDERS.

Where SLSRPT fits: planning, replenishment and VMI

GS1's INVRPT manual draws the link explicitly: actual stock combined with actual sales data (SLSRPT) and sales forecasts (SLSFCT) lets a supplier keep stock close to a target level, or trigger reordering automatically.

How the message is organised: location first

SLSRPT is location driven. The detail section is a list of LOC groups, each identifying a place of sale by GLN. Under each location come the products sold there.

UNH ... header: BGM, DTM (report date and period), NAD, CUX
LOC+162   Store A
  DTM     optional sub-period for this location
  LIN     Product 1: MOA (value), PRI (price), QTY (quantity sold)
  LIN     Product 2: ...
LOC+162   Store B
  LIN     ...
UNS+S     end of detail
UNT

The manual adds that, although the message is organised by location, the receiver can process it by any variable it likes, such as a product across all its stores. Because volumes are high, GS1 strongly recommends using codes only, GTINs and GLNs, rather than descriptions.

SLSRPT segment reference

Status is M (mandatory) or C (conditional) and repeats are the maximum the EANCOM 2002 manual allows. Unlike PRICAT and INVRPT, SLSRPT ends with a mandatory UNS+S. There is no CNT.

Example 1: weekly sales by store

The fictional retailer Brackenfield Stores reports a week of sales of two products from the fictional supplier Fenwold Foods across three stores. Store 5011122001252 does not range the second product, so it has only one line. All GLNs and GTINs are made up with valid check digits.

Two details matter for whoever loads this file. Line numbers run across the whole message, not per store, so the same GTIN appears as line 1, 3 and 5. And the value should equal price times quantity for each line (42 × 3.50 = 147.00); when it does not, the difference usually comes from a price change mid-period, which is what sub-periods are for.

On the document code: the manual's segment example and worked example both use 73E::9, while the code list table in the same edition prints 735 for "sales data report". Use whatever your partner's implementation guide shows.

Example 2: separating a promotional period

Brackenfield ran a price promotion on the oat and honey granola from Thursday 1 to Sunday 4 October, with a shelf display. To keep promotional and normal sales apart, the same store appears in three LOC groups: one for the whole week (the product not on promotion), and two with DTM+356 sub-periods for the product before and during the promotion.

GS1 allows up to five special condition codes in one ALI, one per element, so overlapping promotions can all be flagged. The location-level DTM is optional: the manual says it is not needed when the period is the same as the header's.

Example 3: cancelling a report

If a report was sent with wrong data, BGM function 1 cancels it. GS1 says only the mandatory segments need resending, with at least the sender and receiver NAD, and the number of the report being cancelled in RFF.

To correct a report in one step instead, send the full corrected report with function 5 (replace), a new report number in BGM, and the replaced report's number in RFF+ALS. A replacement contains all the data again, not just the corrected stores. Function 2 (addition) is the exception: it adds products left out of the original by mistake, quoting the original report number in BGM.

Code tables

BGM message function

DTM qualifiers

Formats are 102 (a date), 203 (date and time) and 718 (a date range, start date first).

QTY qualifiers

Other codes

Timing and frequency

Most sales reports are weekly, covering the retailer's trading week, and sent a day or two after it closes. Fast-moving or VMI lines often move to daily reports. The trading week does not always start on Monday, so read the period from DTM+356 rather than assuming. Files can be large: one line per product per store per period adds up quickly across a national estate.

SLSRPT vs the X12 852

Two differences matter most. The organising key is inverted: SLSRPT lists products under each store, while the 852 lists stores under each product (in SDQ). And the 852 often mixes sales and stock in one transaction, while EANCOM usually splits them between SLSRPT and INVRPT, even though SLSRPT's QTY list includes an actual stock code. See the EDI 852 guide for the X12 side.

Common errors and fixes

• Missing UNS+S. It is mandatory in SLSRPT, unlike PRICAT and INVRPT. Receivers reject the message without it.
• Line numbers restarting per store. Number LIN lines sequentially across the whole message. Duplicates confuse loaders.
• Value that does not equal price times quantity. If a price changed mid-week, split the period with location-level DTM, or report the value and use the average price your partner specifies.
• Store codes instead of GLNs. Internal store numbers mean nothing to the supplier. Use the store GLN in LOC+162 with agency 9.
• Ambiguous periods. A report without DTM+356 forces the receiver to guess the week. Always send it.
• Returns netted silently. Agree whether QTY+153 is gross or net of returns, and report returns separately with QTY+61 if asked.
• Wrong UNT count. Large files are generated, but hand-edited test files often miscount.

Testing checklist

1. Agree the period definition, cadence, qualifiers and whether values include VAT with your partner.
2. Load one week for one store and check totals against the retailer's portal or your own EPOS extract.
3. Add stores and products, and check that every store GLN maps to a known location in your system.
4. Test a week with a promotion and confirm the sub-periods and ALI flags load into the right fields.
5. Test cancellation and replacement: make sure a replaced report overwrites, rather than adds to, the original.
6. Check that the file loads within your processing window at full national volume.
7. Paste each test message into the EDIFACT inspector to check structure and counts before going live.

Frequently Asked Questions

What is an SLSRPT message?

SLSRPT is the UN/EDIFACT sales data report. A retailer sends it to a supplier to report units sold, sales value and selling price for each product, by store and period.

Is SLSRPT the same as the X12 852?

They do the same job: the 852 product activity data is the X12 equivalent. SLSRPT is organised by location first and usually carries only sales, while the 852 is organised by item and often includes stock too.

What does QTY+153 mean in SLSRPT?

153 is the qualifier for statistical sales quantity. QTY+153:42' means 42 units of the product in the preceding LIN were sold at that location in the reporting period.

How are promotions shown in SLSRPT?

With ALI special condition codes on the line: 96 promotional advertising, 97 promotional price and 98 promotional shelf display. Use a location-level DTM+356 sub-period to separate promotional days from normal days.

Does SLSRPT need UNS and CNT?

UNS+S is mandatory in the EANCOM 2002 SLSRPT. There is no CNT segment in the message.

Can SLSRPT replace purchase orders in a VMI programme?

No. GS1 states that the message should never replace business transactions such as purchase orders, delivery schedules or inventory reports. Orders still flow as ORDERS, and stock as INVRPT.

Related guides

• EDIFACT explained: syntax, envelopes and the full X12 mapping
• EDIFACT INVRPT: the stock report that pairs with SLSRPT in VMI
• EDIFACT PRICAT: the product and price data behind each GTIN
• EDIFACT ORDERS: the replenishment order that follows
• EDI 852 product activity data: the X12 counterpart
• EDIFACT message types: every message and its X12 equivalent

Sources

• EANCOM 2002 S3: SLSRPT sales data report message, GS1
• EANCOM 2002 S3: INVRPT inventory report message, GS1
• UN/EDIFACT D.01B SLSRPT message, UNECE
• Global Location Number (GLN), GS1

Check your SLSRPT structure, counts and GTIN and GLN check digits in the free EDIFACT inspector.