EDI 832 (Price/Sales Catalog)
EDI 832 (Price/Sales Catalog) is an ANSI X12 transaction set a supplier sends to a trading partner to communicate catalog and pricing data for a set of items — cost, lead time, and item description, line by line. In practice it's used less often to transmit a full catalog than as a price-change notice: a vendor telling a retailer or distributor that a SKU's cost moved from $29 to $32, outside the richer attribute data a PIM feed, cXML PunchOut, or BMEcat file carries.
What EDI 832 actually carries
EDI 832's core product data sits in three segments: CTP (pricing information), LDT (lead time), and PID (product/item description). The transaction header and beginning-of-catalog segments carry trading-partner and effective-date context; everything that actually describes the product lives in a loop that repeats once per line item.
That loop is thin compared to a full catalog standard. PID holds a free-text or coded description, not a structured attribute set — there's no native field for thread pitch, voltage, or material the way a BMEcat file or a PIM export carries. EDI 832 answers "what does this cost and when can you ship it," not "what is this."
Like most EDI transactions, the segment layout differs by X12 version — 003050, 004010, 004030, 004040, and others are all in active use, and the allowed repeat counts and optional segments (a free-text note segment appears in 003050, for instance) vary between them. Two trading partners on different versions will map the same business data differently, so the version in the trading partner agreement, not the generic 832 spec, is what a mapping should be built against.
The most common use: a price-change notice
Full-catalog EDI 832 feeds exist, but the transaction's dominant real-world use in distribution is narrower: a supplier notifying a buyer that pricing changed on items that are already set up in the buyer's system. Vendor A ships Retailer B an 832 stating a SKU's cost is increasing from $29 to $32 effective a given date, and Retailer B's ERP or item master updates the cost field without anyone touching the product's descriptive attributes.
This is why 832 shows up alongside EDI (Electronic Data Interchange) transactions like the 850 (purchase order) and 856 (ASN) in a trading partner's EDI map, but rarely alongside a PIM's product feed — it's solving a pricing-sync problem, not a catalog-onboarding one.
EDI 832 vs. richer catalog standards
| Standard | Primary payload | Attribute depth | Typical use |
|---|---|---|---|
| EDI 832 | Price, lead time, description | Low — no structured attribute fields | Price-change notices between existing trading partners |
| cXML (via punchout) | Live catalog session, cart contents | High — buyer browses supplier's own catalog | Procurement punchout |
| BMEcat | Full structured catalog | High — classification, attributes, pricing | Catalog exchange with industrial/B2B buyers |
| GDSN | Full structured item data | High — GS1-governed attribute set | Retail/CPG master data sync |
Treating EDI 832 as a substitute for one of the richer standards is a common mistake: it moves a price and a description field, not the attribute set a faceted search or a filter rail depends on.
Where EDI 832 breaks in practice
Most failures aren't about the transaction itself — they're about mismatch at the edges:
- Version mismatch. One partner maps against 004010, the other against 004030; segments that are optional in one are required in the other.
- Missing
LDTdata. Lead time is frequently left blank because it changes often and nobody owns keeping it current, which defeats the point of sending the transaction. - Treating it as a product-data feed. Teams that try to backfill attributes from an 832 run into the same wall every time: the segment for that data doesn't exist in this transaction. That data has to come from the supplier's PIM, a spec sheet, or a richer catalog standard.
Frequently asked questions
What is EDI 832 used for?
Most commonly, notifying a trading partner that pricing or lead time changed on items already set up in their system — a supplier telling a retailer a SKU's cost moved from $29 to $32. It can carry a fuller catalog, but its three product-data segments (CTP for pricing, LDT for lead time, PID for description) are thin compared to a dedicated catalog standard.
Can EDI 832 replace a PIM feed or product catalog file?
No. EDI 832 has no structured fields for attributes like material, dimensions, or compliance data — only pricing, lead time, and a description field. It solves a price-sync problem between partners who already have the item set up; attribute data for new-item onboarding still has to come from a PIM, a supplier spec sheet, or a richer standard like BMEcat or GDSN.
What's the difference between EDI 832 and EDI 850?
EDI 850 is a purchase order — a buyer telling a supplier what to ship. EDI 832 runs the other direction and carries a different payload: a supplier telling a buyer what something costs and how long it takes to get. They're often confused because both move between the same two trading partners, but one is an order and the other is catalog/pricing data.
Which version of EDI 832 should I use?
Whichever version your trading partner's EDI map specifies — 003050, 004010, 004030, and 004040 are all still in active use, and segment requirements differ between them. Check the trading partner agreement or implementation guide rather than defaulting to the newest version; mismatched versions are a common source of mapping failures.