EDIFACT PRICAT: Price Catalogue Message Guide

PRICAT is the message that has to be right before any order can be. A buyer's system will only accept an ORDERS line for a GTIN it already holds, at a cost price it already agreed. When item data is wrong or late, the first symptom is usually not an error message: it is a rejected order line, an invoice that does not match the buyer's price file, or a new product that misses its launch week.

This guide follows the GS1 EANCOM 2002 PRICAT layout (directory D.01B, subset version EAN009). 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 PRICAT?

PRICAT (price/sales catalogue) is the UN/EDIFACT message a seller uses to send product, logistic and pricing information to a buyer, so that later commercial messages can refer to those products by number. GS1 defines it as a message for "pricing and catalogue details for goods and services offered by a seller to a buyer", which can also flow back from the buyer to accept or reject a catalogue.

In practice a supplier sends PRICAT for four jobs:

• New listings. Identify a new product, its case and pallet, descriptions, weights, dimensions and cost price.
• Price changes. Send new prices with the date they take effect, or a promotional price for a fixed period.
• Delistings. Tell the buyer to delete items from its file, with a last order date.
• Full catalogue refreshes. Resend everything so both sides can check their files still agree.

GS1's principles allow the message to carry either general information valid for all customers or prices and conditions specific to one customer. A full listing or "advance warning of particular changes" are both valid uses.

Where PRICAT fits

PRICAT sits before the order cycle, not inside it. Nothing in ORDERS, ORDRSP, DESADV or INVOIC creates a product; they all refer to products the buyer already holds.

The last row is why price changes matter so much. A buyer's invoice matching compares your INVOIC price with the price on its file for that delivery date. If your new price reached your billing system but your PRICAT never reached the buyer, every invoice from the effective date is a mismatch.

For the full list of EDIFACT messages and their X12 equivalents, see EDIFACT message types.

PRICAT and GS1 GDSN

PRICAT and the GS1 Global Data Synchronisation Network (GDSN) solve overlapping problems in different ways, and many buyers use one or the other for item data.

• PRICAT is point to point. You send a message to one trading partner, or to a central catalogue. The EANCOM manual explicitly allows a supplier to use PRICAT "to feed a central catalogue of products", and its NAD code list includes GX (central catalogue party) and DER (source data pool).
• GDSN is publish and subscribe. GS1 describes it as a network where companies share master product information "by subscribing to a certified GS1 GDSN data pool". The supplier publishes once to its data pool and each subscribing retailer receives the data through its own pool, using GDSN's own messages rather than EDIFACT.

If a buyer takes core product attributes from GDSN, its PRICAT requirement may shrink to commercial data such as cost prices and dates. Some buyers use neither and send a spreadsheet template. The partner's onboarding pack tells you which route it uses; do not assume.

PRICAT segment reference

The table follows the EANCOM 2002 message structure. Status is M (mandatory) or C (conditional) and repeats are the maximum the manual allows. The detail section always starts with PGI, and each product sits in its own LIN group (SG36).

Two things stand out if you are used to other EANCOM messages. There is no UNS or CNT in PRICAT: the summary section is just UNT. And many partners use only a fraction of the 146 segment positions in the manual. Expect a buyer's implementation guide to mark which ones it needs.

Example 1: a new product listing

The fictional supplier Fenwold Foods lists a new granola with the fictional retailer Brackenfield Stores. The message describes two levels of the same product: the 450 g bag (consumer unit) and the case of six (traded unit). A third line links them. All GLNs and GTINs are made up and carry valid GS1 check digits.

How PRICAT describes pack hierarchies

GS1 builds the consumer unit, traded unit and despatch unit hierarchy out of extra LIN lines rather than a dedicated hierarchy segment. The rule in the manual is simple: the first LIN describes the smallest unit, the next describes the level above, and so on. A sub-line (the fifth element of LIN, +1:2 above) says "this line sits inside line 2".

Two quantity codes hold it together:

• QTY+17E on the parent: the total number of units in the level below (looking down).
• QTY+45E on the sub-line: how many of that child are in the parent (looking up).

GS1 says the 45E quantities across a parent's sub-lines should add up to its 17E. To add a pallet, send a fourth line with IMD+C++DU::9, its own GTIN and PAC+++201::9, then a sub-line pointing the case at it with QTY+45E: cases per pallet.

Example 2: a price change with an effective date

A month later Fenwold raises cost prices on two existing products from 9 November, and agrees a promotional cost price for a two-week promotion. Function 4 in BGM says the message changes products the buyer already holds, so only the changed segments are sent.

Each PRI opens its own segment group (SG40), so the date that follows applies only to that price. That is how one line carries a list price and a promotion without ambiguity. Under function 4, GS1 asks that a changed segment is sent with all its previous data and that every repetition of a modified segment is resent, so if an item has three prices and one changes, send all three.

The notice period for price changes is a commercial term, not an EANCOM rule. Your supplier agreement usually sets it. Send PRICAT early enough that the buyer can load the price before its first order for delivery on or after the effective date.

Example 3: delisting a product

Fenwold discontinues its muesli. Function 3 (deletion) in BGM and action 2 (deleted) on each line tell the buyer to remove the items. The order and availability dates tell the buyer's replenishment team how long they can keep ordering.

GS1's own deletion example makes one point worth repeating: when you delete a main line, the receiver must delete its sub-lines. You do not need to send them. Sending the case and the bag explicitly, as here, is still common, because many buyers' systems key items by GTIN rather than by hierarchy.

If a product is replaced by a new GTIN rather than discontinued, PIA qualifier 3 (substituted by) tells the buyer which number replaces it. The LIN carries the old GTIN and the PIA the new one.

Example 4: the buyer's response

PRICAT can also travel back. With document code 51 (price/sales catalogue response), the buyer accepts a whole catalogue with function 29 or rejects it with 27. For full acceptance or rejection, GS1 says only the mandatory segments and the parties and reference need to be sent.

To propose changes to individual lines, the buyer sends lines with action 3 and can explain why in FTX. Lines it does not resend are accepted by default. Not every buyer sends a response; many confirm listings by email or through their supplier portal.

Code tables

BGM document name (first element)

GS1 notes that 727 and 728 exist so the receiver can route a message to the right team, for example pricing versus product data. Older partner guides sometimes show GS1 codes such as 25E; follow the code your partner's guide specifies.

BGM message function (third element)

LIN action code (second element)

GS1's rule: when every line has the same action, BGM carries it and each LIN should agree. If they differ, the LIN action overrides the BGM function for that line.

PRI price qualifiers

The third component is the price type (CA catalogue, CT contract) and the fourth is a price specification such as PRP (promotional price) or ACB (marked retail price).

Useful DTM qualifiers

Timing and frequency

There is no fixed schedule in the standard. In practice:

• New listings go before the buyer's item set-up deadline for a range review or launch, often weeks ahead of the first order.
• Price changes go at least as far ahead of the effective date as your agreement requires.
• Delistings go as soon as the decision is made, with a last order date that lets the buyer run down stock.
• Full refreshes go on an agreed cycle, or whenever either side suspects the files have drifted.

PRICAT vs the X12 832

The biggest practical difference is the hierarchy. An 832 usually describes pack levels as attributes of one item, while PRICAT gives each level its own GTIN and line. If you map 832 data into PRICAT, every case and pallet needs its own GTIN. See the EDI 832 guide for the X12 side. UK suppliers trading in TRADACOMS will know the price information file, PRIHDR; see TRADACOMS file types.

Common errors and fixes

• GTIN check digit wrong. The line is rejected or, worse, creates a phantom item. Validate every GTIN before sending.
• Case GTIN reused from the consumer unit. Each pack level needs its own GTIN. Sending the bag's GTIN at case level breaks ordering in cases.
• Price change sent without a start date. The buyer may apply it on receipt, or not at all. Always pair a new price with DTM+194 or a validity period.
• Function and actions disagree. BGM function 9 with lines marked 3 confuses some receivers. Match them, or follow your partner's guide on which wins.
• Missing segments in a change. Under function 4, a modified segment is resent in full, with all its repetitions.
• Units of measure that do not match ordering. If the buyer orders in cases, the case line needs a price and a minimum order quantity in cases.
• Wrong UNT count. Count every segment from UNH to UNT. PRICAT messages are long and hand-edited ones often miscount.

Testing checklist

1. Agree with the buyer which segments and qualifiers it needs, and whether it takes core attributes from GDSN instead.
2. Validate every GTIN and GLN check digit.
3. Send a new listing for one product with all its pack levels and confirm it loads correctly.
4. Send a price change with a future effective date and confirm the buyer shows the new price from that date only.
5. Send a delisting and confirm the item stops appearing on new orders after the last order date.
6. Place a test order for the new item and check the ORDERS price matches your PRICAT.
7. Paste each test message into the EDIFACT inspector to check structure and counts before sending.

Frequently Asked Questions

What is PRICAT used for?

PRICAT sends product and price information from a supplier to a buyer: new product listings, price changes with effective dates, promotional prices and delistings. It sets up the items that later ORDERS, DESADV and INVOIC messages refer to by GTIN.

Is PRICAT the same as the X12 832?

They do the same job. The 832 is the North American X12 price/sales catalog; PRICAT is the UN/EDIFACT and EANCOM equivalent. The main difference is that PRICAT describes each pack level as its own line with its own GTIN.

How do I send a price change in PRICAT?

Send the line with action 3 (changed), a PRI segment with the new price and a DTM+194 start date in the same price group. Use BGM function 4 if only changed data is sent.

Does PRICAT have a UNS or CNT segment?

No. In EANCOM 2002 the PRICAT summary section is just UNT. Do not add UNS+S or CNT unless your partner's guide asks for them.

What is the difference between PRICAT and GDSN?

PRICAT is a message you send directly to a trading partner. GDSN is a GS1 network of certified data pools: the supplier publishes product data once and each subscribing retailer receives it through its own pool. Some buyers use GDSN for product attributes and PRICAT, or another channel, for commercial terms.

Does the buyer have to respond to PRICAT?

Only if the trading agreement says so. EANCOM defines a response (BGM+51 with function 29 or 27), but many buyers confirm listings outside EDI.

Related guides

• EDIFACT explained: syntax, envelopes and the full X12 mapping
• EDIFACT ORDERS: the order that depends on your PRICAT data
• EDIFACT INVRPT and SLSRPT: stock and sales reports for the same products
• EDIFACT INVOIC: where a missed price change shows up
• EDI 832 price/sales catalog: the X12 counterpart
• EDIFACT message types: every message and its X12 equivalent

Sources

• EANCOM 2002 S3: PRICAT price/sales catalogue message, GS1
• UN/EDIFACT D.01B PRICAT message, UNECE
• GS1 Global Data Synchronisation Network, GS1
• Global Trade Item Number (GTIN), GS1

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