EDI 832 Price/Sales Catalog Guide

The EDI 832 Price/Sales Catalog is the X12 transaction set vendors use to publish their product catalog (item identifiers, descriptions, pricing tiers, attributes, dimensions, and pack configurations) to trading partners. It is the foundational document that lets retailers and distributors set up new items in their merchandising systems without manual data entry.

What Is an EDI 832?

An EDI 832 is a structured catalog document defined by the ASC X12 standards body that a vendor sends to a trading partner to communicate item-level data: SKUs, UPCs, descriptions, prices, weights, dimensions, packaging, and any retailer-specific attributes. It typically precedes the first PO from a new partner and is updated whenever the catalog changes.

Two common 832 modes:

• Full catalog refresh: vendor sends the complete current catalog. The receiving partner replaces their stored copy.
• Incremental updates: vendor sends only added, changed, or discontinued items, marked with action codes (A = add, C = change, D = delete).

The 832 is also called the Item Catalog or Item Maintenance document depending on the trading partner.

EDI 832 Format and Key Segments

The 832 is one of the larger X12 transaction sets because catalog data carries many attributes per item:

The catalog repeats the LIN-through-G39 block per item, sometimes thousands of times per file.

Common Use Cases

Vendor onboarding with a new retailer

When a vendor ships their first PO to a new retailer, the retailer needs item data on file before the first 850 can be processed. The vendor sends an 832 with their full catalog. The retailer's merchandising system ingests it, creates item records, and only then is the trading relationship live.

Quarterly price updates

Vendors send an incremental 832 with BCT01 = PR (price update purpose) and only changed items, each carrying the new CTP pricing. The retailer updates list price and effective date in their POS or pricing system.

Seasonal catalog rotations

Apparel and seasonal goods vendors push a fresh 832 at the start of each season with the new season's items. Discontinued items get marked with action code D so the retailer's planogram and replenishment systems stop ordering them.

New item adds during the season

Mid-season SKU adds (line extensions, new colors, new sizes) go out as incremental 832s with action code A, letting retailers ramp up new items without waiting for the next full catalog refresh.

Interactive Example: Vendor 832 Catalog

This is a real vendor-to-retailer 832 shape with two items, three pricing tiers (retail, wholesale, MSRP), and packaging detail. Use the Plain English tab for a translation or Split View to compare raw vs parsed.

In the example above: action A (add), Spring 2026 catalog, item 1 (Spring Cleanser 8oz, vendor SKU ACME-001) at retail $9.99 / wholesale $5.50 / MSRP $12.99, item 2 (Spring Toner 4oz, vendor SKU ACME-002) at retail $7.99 / wholesale $4.25. Both made in the USA.

Interactive Example: Walmart Grocery 832 with Nutrition Data

Walmart and other grocery retailers require richer item attributes than general merchandise: GTIN-14 identifiers, nutrition flags, allergen handling, and refrigeration class. The G39 segment carries these as positional flags.

The example above publishes two grocery items (Steel Cut Oats and Organic Orange Juice) using GTIN-14 (UK qualifier) instead of UPC-12, with full dimensional packaging (PO4), wholesale pricing, and item characteristics including organic, gluten-free, and refrigeration class.

Interactive Example: Incremental 832 Price Update

Most price changes don't need a full catalog refresh. A purpose-code PR 832 carries only the items whose prices changed, with the new pricing tiers and an effective date via DTM*007.

The example above updates retail and wholesale prices for three items effective 2026-06-01. No descriptions, no packaging, no measurements — just LIN identifiers and new CTP pricing tiers. The receiving partner's system applies the new prices on the effective date and continues using existing item attributes from the prior full catalog.

Trading Partner Requirements

832 implementations vary widely by partner because catalog data is the most attribute-rich EDI document. Common variations:

• Identifier qualifiers required: Some retailers require GTIN-14 (UK) instead of UPC-12 (UP). Others require multiple identifier qualifiers per LIN segment.
• Pricing tier codes: RES (retail), WHL (wholesale), MSR (MSRP), PRO (promotional), CST (cost) — partner-specific which are required.
• Mandatory attributes: Walmart requires nutrition/ingredient data for grocery via G39. Target requires DPCI mapping. Amazon Vendor Central requires brand registry attributes.
• Catalog ID convention: Partner-specific format for BCT02 so the receiving system can dedupe and version catalog versions over time.

Implementation Best Practices

1. Publish a fresh full catalog at least quarterly even if you also send incremental updates. Full refreshes catch drift between your system of record and the retailer's stored copy.
2. Always set effective dates on price changes via DTM segments so the retailer knows when to apply new CTP values.
3. Coordinate item adds with marketing launches — a new item add via 832 is the upstream trigger for the retailer's PIM team to set up product detail pages and physical store assortment.
4. Mark discontinued items with action code D rather than just omitting them. Omission lets stale items linger in the retailer's system. Explicit deletion forces cleanup.
5. Validate UPC check digits on every line — invalid UPCs are the most common reason 832s fail compliance and require a manual catalog cleanup at the retailer.

Related Transaction Sets

• EDI 850 Purchase Order — Retailers can only PO items they have on file from your 832
• EDI 846 Inventory Inquiry/Advice — Inventory levels for the items defined in the 832
• EDI 855 PO Acknowledgment — When a retailer POs an item not on file, they may receive an 855 rejection until the catalog is updated
• EDI 879 Price Information — Price-only counterpart used by some retailers instead of 832 for price updates

Frequently Asked Questions

What is an EDI 832 used for? The 832 communicates a vendor's product catalog to trading partners: SKUs, UPCs, descriptions, prices, packaging, dimensions, and partner-specific attributes. It's how new items get set up in retailer merchandising systems before any PO can flow.

How often should I send an EDI 832? At least quarterly for full catalog refresh. Plus incremental 832s any time items are added, changed, or discontinued, or when prices are updated.

Can I send an EDI 832 with only price changes, not item details? Yes. Use BCT01 = PR (price update) and include only the items whose prices changed. Some partners prefer the EDI 879 for price-only updates instead.

What is the difference between EDI 832 and EDI 879? The 832 carries the full item catalog including descriptions, packaging, attributes, and pricing. The 879 is price-only — typically used between trading partners that already share item master data through another channel.

How large can an 832 file be? Files of 100,000+ items are common for large vendors with broad assortments. Most retailers accept files up to several gigabytes via SFTP or AS2. Compression (*.zip) is standard for files over 50MB.

Need Help With EDI 832?

OrderSync generates 832s directly from your product catalog (NetSuite, Shopify, custom PIM) with retailer-specific attributes mapped automatically. Onboard new retailers without rebuilding your catalog export per partner.

Try the free EDI Inspector to parse and validate your 832 samples.