EDI 832 Price/Sales Catalog: The Complete Guide (2026)

Before a partner can order your product, their system has to know it exists — the right item number, the right pack, the right price. The EDI 832 Price/Sales Catalog is how that knowledge gets there and stays current. It's the least glamorous document in most trading relationships and, quietly, the one whose staleness explains the most downstream failures: orders for items the buyer half-knows, invoices that short-pay because the price on file is last quarter's.

The catalog as reference data

An 832 is a structured feed of your item master, built from a few core segments per product. LIN carries the identifiers — UPC or GTIN, your item number, the partner's number where one exists, and industry-specific keys where they apply. PID describes the item; PO4 defines pack: units per case, inner packs, dimensions, weight. CTP carries pricing, potentially at several levels — list, contract, promotional — distinguished by qualifier.

What makes the document consequential is how partners use it. The catalog isn't a brochure; it's loaded into the partner's system as the reference for validating everything else. When an 850 order arrives, it was built from catalog data. When your 810 invoice is matched, the price is checked against the catalog. An 832 that's out of sync doesn't fail loudly — it makes other documents fail, weeks later, in ways that are tedious to trace back.

Who leans on it hardest

Catalog-driven trade is the norm wherever assortments are deep and pricing is contractual. Industrial distribution is the sharpest example: Grainger wants full attribute depth in the 832 — manufacturer part number, UNSPSC classification, and pack data, not just price — and expects catalog updates to precede any price change that shows up on an invoice. Foodservice broadliners treat the catalog as the contract that opco orders validate against. Pharmaceutical wholesalers key their catalogs by NDC with tiered contract pricing. Hardware co-ops feed member-store pricing from it. Across all of them, the same rule holds: the 832 moves first, everything else follows. Retail programs use it more selectively — often at item setup and for price maintenance — but the sequencing rule is identical.

Alongside it, many of the same partners want the 846 inventory advice — the 832 says what exists and costs, the 846 says what's available today, and together they define what a distributor will actually sell on your behalf.

Keeping it in sync without a project manager

Catalog maintenance fails when it's an event instead of a pipeline — someone exports a spreadsheet quarterly, formats it, uploads it, and in between, reality drifts. The durable fix is generating the 832 from your item master automatically: a price change or new item in the ERP triggers a delta to every partner who needs it, in each partner's preferred shape (full refresh or changes-only), on each partner's schedule. That's how EDISQ runs it, with per-partner formatting handled in the map — one item master in, correctly-shaped catalogs out, across 30+ integrated systems.

Versioning discipline completes the picture. Partners validate documents against the catalog they currently hold, not the one you just sent — so effective dates matter, and price changes need to land far enough ahead of the invoices that reference them. Building that lead time into the publishing pipeline is cheaper than disputing the short-pays that skip it.

The pricing footnote

A ten-thousand-item catalog and a ten-item catalog are each one document, and EDISQ charges by the document: monthly documents 1 through 25 are free, then rates run from $0.50 down to $0.10 apiece as volume tiers fill, applied marginally. No mapping or setup fees, no penalty for attribute depth — so there is never a cost reason to publish updates less often than your data changes. Given what a stale catalog does downstream, that's the right incentive.

FAQ