# EDIFACT SLSRPT: Sales Data Report Message Guide

> EDIFACT SLSRPT explained: weekly sales by store, promotional periods and cancellations, with live EANCOM examples, code tables and the X12 852 mapping.

<QuickAnswer>
EDIFACT SLSRPT is the sales data report message, the equivalent of the X12 852. A retailer sends it to a supplier to report what sold, where and when. Each LOC identifies a store by GLN, with an optional sub-period in DTM; under it, each LIN gives a GTIN with quantity sold (QTY+153), sales value (MOA+203) and selling price (PRI).
</QuickAnswer>

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](https://www.gs1.org/sites/default/files/docs/eancom/ean02s3/part2/slsrpt/toc.htm) 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](/edifact-inspector), and you can open each one in the full tool.

<EDIGuideCTA
  badge="For EDIFACT SLSRPT"
  transactionType="852"
  headline="Turn an SLSRPT file into something you can read"
  body="Paste an SLSRPT into the free EDIFACT inspector to see each store, product, quantity and value explained, with UNT counts and GTIN and GLN check digits verified. OrderSync processes EDIFACT, EANCOM and TRADACOMS orders alongside X12, PDF, CSV and email, straight into your ERP."
  secondaryHref="/edifact-inspector"
  secondaryLabel="Try the free EDIFACT inspector"
/>

## 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](/guides/edi/edifact-invrpt), and the order still comes as [ORDERS](/guides/edi/edifact-orders).

## Where SLSRPT fits: planning, replenishment and VMI

| Use | What the supplier does with SLSRPT |
|---|---|
| Vendor-managed inventory | Combines sales with INVRPT stock to decide what each site needs |
| [Demand forecasting](/glossary/demand-forecasting) | Builds forecasts from real store-level sell-through instead of order history |
| Promotion analysis | Compares sales in the promotional sub-period with the weeks either side |
| Range and distribution checks | Spots stores that stock a product but never sell it, or never stock it |
| Category reporting | Shares sell-through with the retailer's buying team in an agreed format |

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`.

| Segment | Name | Status | Repeats | Carries | X12 852 equivalent |
|---|---|---|---|---|---|
| `UNH` | Message header | M | 1 | Message reference, `SLSRPT:D:01B:UN:EAN007` | `ST` |
| `BGM` | Beginning of message | M | 1 | Sales report document code, number and function | `XQ` |
| `DTM` | Date/time/period | M | 5 | Message date (`137`), sales period (`356`) | `XQ02`, `XQ03` |
| `RFF` (SG1) | Reference | C | 9 | Contract, or the report being replaced or cancelled | `N9`, `XPO` |
| `NAD` (SG2) | Name and address | M | 5 | Seller (`SE`), supplier (`SU`) and other parties | `N1` loop |
| `CUX` (SG5) | Currencies | C | 5 | Pricing currency, `CUX+2:GBP:10` | None common |
| `LOC` (SG6) | Place of sale | C | 200000 | Store or outlet GLN, qualifier `162` | `SDQ` location IDs |
| `DTM` | Date/time/period | C | 5 | Sub-period for this location | `DTM` |
| `LIN` (SG8) | Line item | C | 200000 | The product's GTIN with `SRV` | `LIN` |
| `PIA` | Additional product id | C | 5 | Buyer's item number, promotional variant | `LIN` qualifier pairs |
| `IMD` | Item description | C | 5 | Description, if the partner wants it | `PID` |
| `RFF` | Reference | C | 5 | Contract or price list for this line | `REF` |
| `ALI` | Additional information | C | 5 | Promotion flags: advertising, price, display | Partner-specific |
| `MOA` | Monetary amount | C | 5 | Value of sales, qualifier `203` | `ZA` amounts, where used |
| `PRI` (SG9) | Price details | M | 1 | The price at which it sold | `CTP` |
| `QTY` (SG10) | Quantity | M | 1 | Quantity sold (`153`), returns, promotion quantity | `ZA` with activity code |
| `UNS` | Section control | M | 1 | `UNS+S`, end of the detail section | None |
| `UNT` | Message trailer | M | 1 | Segment count and message reference | `SE` |

## 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.

<EdifactSample
  title="Weekly sales by store: three stores, two products"
  description="BGM 73E sales report for 5 to 11 October 2026, then one LOC+162 group per store with MOA+203 sales value, PRI selling price and QTY+153 quantity sold for each GTIN."
  label="EANCOM 2002 D.01B"
  raw="UNA:+.? '
UNB+UNOC:3+5011122000002:14+5067890000003:14+261012:0700+BS0092230++SLSRPT'
UNH+1+SLSRPT:D:01B:UN:EAN007'
BGM+73E::9+BS-SLS-2026W41+9'
DTM+137:20261012:102'
DTM+356:2026100520261011:718'
NAD+SE+5011122000002::9'
NAD+SU+5067890000003::9'
CUX+2:GBP:10'
LOC+162+5011122001016::9'
LIN+1++5067890100017:SRV'
MOA+203:147.00'
PRI+AAA:3.50'
QTY+153:42'
LIN+2++5067890100024:SRV'
MOA+203:67.50'
PRI+AAA:3.75'
QTY+153:18'
LOC+162+5011122001184::9'
LIN+3++5067890100017:SRV'
MOA+203:87.50'
PRI+AAA:3.50'
QTY+153:25'
LIN+4++5067890100024:SRV'
MOA+203:41.25'
PRI+AAA:3.75'
QTY+153:11'
LOC+162+5011122001252::9'
LIN+5++5067890100017:SRV'
MOA+203:206.50'
PRI+AAA:3.50'
QTY+153:59'
UNS+S'
UNT+32+1'
UNZ+1+BS0092230'"
/>

| Segment | What it says |
|---|---|
| `BGM+73E::9+BS-SLS-2026W41+9'` | Sales data report (`73E`, a GS1 code, hence `::9`), number BS-SLS-2026W41, original |
| `DTM+356:2026100520261011:718'` | Sales period 5 to 11 October 2026, format `718` (date range) |
| `NAD+SE` / `NAD+SU` | Seller (the retailer) and supplier |
| `CUX+2:GBP:10'` | Values and prices are in sterling (`10` = pricing currency) |
| `LOC+162+5011122001016::9'` | Place of sale: the store with this GLN |
| `LIN+1++5067890100017:SRV'` | Product sold, by GTIN |
| `MOA+203:147.00'` | Sales value for the week: 147.00 |
| `PRI+AAA:3.50'` | Selling price 3.50 |
| `QTY+153:42'` | 42 units sold |
| `UNS+S'` | End of the detail section; mandatory in SLSRPT |
| `UNT+32+1'` | 32 segments from UNH to UNT inclusive |

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.

<EdifactSample
  title="One store, one week, split around a promotion"
  description="Repeated LOC+162 groups for the same store with DTM+356 sub-periods. The promotional line carries ALI+++97+98 (promotional price and shelf display) and the lower selling price."
  label="EANCOM 2002 D.01B"
  raw="UNA:+.? '
UNB+UNOC:3+5011122000002:14+5067890000003:14+261005:0700+BS0092118++SLSRPT'
UNH+1+SLSRPT:D:01B:UN:EAN007'
BGM+73E::9+BS-SLS-2026W40+9'
DTM+137:20261005:102'
DTM+356:2026092820261004:718'
NAD+SE+5011122000002::9'
NAD+SU+5067890000003::9'
CUX+2:GBP:10'
LOC+162+5011122001016::9'
LIN+1++5067890100024:SRV'
MOA+203:63.75'
PRI+AAA:3.75'
QTY+153:17'
LOC+162+5011122001016::9'
DTM+356:2026092820260930:718'
LIN+2++5067890100017:SRV'
MOA+203:45.50'
PRI+AAA:3.50'
QTY+153:13'
LOC+162+5011122001016::9'
DTM+356:2026100120261004:718'
LIN+3++5067890100017:SRV'
ALI+++97+98'
MOA+203:117.00'
PRI+AAA:3.00'
QTY+153:39'
UNS+S'
UNT+27+1'
UNZ+1+BS0092118'"
/>

| Segment | What it says |
|---|---|
| First `LOC+162` group, no `DTM` | The header period applies: the whole week, 28 September to 4 October |
| `DTM+356:2026092820260930:718'` | Sub-period Monday to Wednesday, before the promotion |
| `DTM+356:2026100120261004:718'` | Sub-period Thursday to Sunday, during the promotion |
| `ALI+++97+98'` | Special conditions `97` (promotional price) and `98` (promotional shelf display) |
| `PRI+AAA:3.00'` | The promotional selling price |
| `QTY+153:39'` | 39 sold in four promotional days, against 13 in the three days before |

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`.

<EdifactSample
  title="Cancel a previously sent sales report"
  description="BGM function 1 (cancellation) with RFF+ALS quoting the sales report number being cancelled. No location or line detail is sent; UNS+S still closes the message."
  label="EANCOM 2002 D.01B"
  raw="UNA:+.? '
UNB+UNOC:3+5011122000002:14+5067890000003:14+261012:1530+BS0092262++SLSRPT'
UNH+1+SLSRPT:D:01B:UN:EAN007'
BGM+73E::9+BS-SLS-2026W41C+1'
DTM+137:20261012:102'
RFF+ALS:BS-SLS-2026W41'
DTM+171:20261012:102'
NAD+SE+5011122000002::9'
NAD+SU+5067890000003::9'
UNS+S'
UNT+9+1'
UNZ+1+BS0092262'"
/>

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

| Code | Meaning in EANCOM SLSRPT |
|---|---|
| `9` | Original |
| `1` | Cancellation of a previous report, identified in `RFF` |
| `2` | Addition: products omitted from the original report |
| `5` | Replace: a full report that replaces one identified in `RFF` |
| `6` | Confirmation: a resend of a previous report, same number and date |
| `31` | Copy for a third party, for information |

### DTM qualifiers

| Code | Meaning |
|---|---|
| `137` | Message date (mandatory) |
| `356` | Sales date or period |
| `90` / `91` | Report start / end date |

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

### QTY qualifiers

| Code | Meaning |
|---|---|
| `153` | Statistical sales quantity: units sold |
| `61` | Return quantity |
| `210` | Returned by consumer |
| `26` | Promotion quantity |
| `145` | Actual stock |
| `217` | Out of inventory quantity |

### Other codes

| Segment | Code | Meaning |
|---|---|---|
| `LOC` | `162` | Place or location of sale (the only qualifier) |
| `MOA` | `203` | Line item amount: value of sales for the period |
| `ALI` | `96` / `97` / `98` | Promotional advertising / price / shelf display |
| `PRI` | `AAA` / `AAB` | Calculation net / gross price |
| `PRI` | `AAE` / `AAF` | Information price including / excluding taxes |
| `NAD` | `SE` / `SU` / `CO` | Seller / supplier / corporate office |

## 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

| Data | EDIFACT SLSRPT | X12 852 |
|---|---|---|
| Report number and purpose | `BGM` | `XQ` |
| Reporting period | `DTM+356` with format `718` | `XQ02` and `XQ03` |
| Parties | `NAD+SE`, `NAD+SU` with GLNs | `N1` loop |
| Organising key | Location first: `LOC`, then `LIN` | Item first: `LIN`, then `ZA`, then `SDQ` by location |
| Item | `LIN` with GTIN and `SRV` | `LIN` with qualifier pairs |
| Quantity sold | `QTY+153` | `ZA` with a sold activity code |
| Sales value | `MOA+203` | Partner-specific |
| Selling price | `PRI` | `CTP` |
| Promotion flag | `ALI` codes `96`, `97`, `98` | Partner-specific |
| Stock on hand | Usually a separate INVRPT | Often another `ZA` in the same 852 |
| End of detail | `UNS+S` | `CTT` |

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](/guides/edi/852-product-activity-data) 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](/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](/guides/edi/edifact)**: syntax, envelopes and the full X12 mapping
- **[EDIFACT INVRPT](/guides/edi/edifact-invrpt)**: the stock report that pairs with SLSRPT in VMI
- **[EDIFACT PRICAT](/guides/edi/edifact-pricat)**: the product and price data behind each GTIN
- **[EDIFACT ORDERS](/guides/edi/edifact-orders)**: the replenishment order that follows
- **[EDI 852 product activity data](/guides/edi/852-product-activity-data)**: the X12 counterpart
- **[EDIFACT message types](/guides/edi/edifact-message-types)**: every message and its X12 equivalent

## Sources

- [EANCOM 2002 S3: SLSRPT sales data report message](https://www.gs1.org/sites/default/files/docs/eancom/ean02s3/part2/slsrpt/toc.htm), GS1
- [EANCOM 2002 S3: INVRPT inventory report message](https://www.gs1.org/sites/default/files/docs/eancom/ean02s3/part2/invrpt/toc.htm), GS1
- [UN/EDIFACT D.01B SLSRPT message](https://service.unece.org/trade/untdid/d01b/trmd/slsrpt_c.htm), UNECE
- [Global Location Number (GLN)](https://www.gs1.org/standards/id-keys/gln), GS1

Check your SLSRPT structure, counts and GTIN and GLN check digits in the free [EDIFACT inspector](/edifact-inspector).