The electronic catalog: the document that kills the stale-price order
The electronic product and price catalog (832 in X12, PRICAT in EDIFACT) explained without jargon: how a supplier publishes its catalog, prices, and availability to every B2B customer at once — and why that eliminates the credit notes caused by outdated price lists. From the 'EDI without mystery' series.
The scene repeats itself in any distributor in Venezuela: on Monday you updated the price list. You sent it to your sixty customers over WhatsApp, as a PDF. On Wednesday a big order lands… at last month’s prices. The customer swears that was the list he had. You invoice, he disputes, and your back office ends up issuing a credit note, reconciling the difference, and burning two days of phone calls on an order that should have taken ten minutes.
Nobody lied. It’s simply that every customer holds a different copy of your truth, and copies age at different speeds. In a market where prices change often — like Venezuela’s — that’s not an occasional annoyance: it’s a permanent administrative cost disguised as “that’s just how this business works.”
The transaction that solves it is the electronic product and price catalog (X12 calls it an 832, but it exists in every EDI language — full table below).
What is the electronic catalog, in one sentence?
EDI means Electronic Data Interchange: business documents flowing system to system, with no manual rekeying. The electronic catalog (Price/Sales Catalog) is the document a supplier uses to publish its catalog — products, descriptions, codes, prices, units of sale, and availability — directly into its customers’ systems.
It’s not a PDF someone has to read. It’s data the customer’s system loads by itself: when their purchasing person builds an order, they’re already looking at your current catalog, at today’s prices.
How it works: a pharma distributor that reprices every week
Picture a pharmaceutical distributor with 4,000 products and dozens of pharmacies and clinics as customers, in a market where price lists get adjusted every week or two:
- On Monday, the distributor updates prices in its ERP — exactly as it always has.
- From that system, the electronic catalog is generated automatically: either the full catalog or just the changes (the 300 products that moved, the 5 new ones, the 2 discontinued).
- The catalog is transmitted to every connected customer at once. There aren’t sixty PDFs; there is one publication.
- Each pharmacy’s system receives the catalog and updates its records: prices, presentations, barcodes, availability.
- When the pharmacy builds Thursday’s order (ideally another EDI document, the 850 purchase order), it builds it against the current catalog. The price on the order and the price on the invoice are the same number — because they came from the same source.
The credit note for “stale prices” doesn’t get resolved faster: it stops existing, because the condition that created it — two different copies of the list — no longer occurs.
One publication, every customer: the list stops aging copy by copy
A single source of truth
That’s the underlying idea: the catalog stops being a file you distribute and becomes a single source of truth everyone consults. And the electronic catalog carries more than prices:
- Identification: supplier codes, barcodes (GTIN), descriptions.
- Commercial terms: price per presentation, minimum order quantities, unit of sale (case, blister, unit).
- Lifecycle: new product, price change with an effective date, discontinued item.
- Availability: what’s actually there to ship, so nobody orders what doesn’t exist.
That effective date detail is gold in fast-repricing markets: you can publish today the list that takes effect Monday, and your customers’ systems apply it on exactly that day. Nobody wakes up early to re-send PDFs.
What each side gains
| Supplier | Customer (buyer) | |
|---|---|---|
| Back office | Goodbye credit notes for stale prices; invoices paid without dispute | Orders arrive priced as quoted |
| Sales | A price change takes effect the same day across all customers | Sees new products and availability instantly |
| Operations | One publication instead of sixty sends | Zero transcribing of lists into the system |
| Relationship | Fewer dispute calls, more sales calls | Confidence: the price is the price |
Common mistakes
- Publishing the electronic catalog and still sending the PDF “just in case.” Two price channels is the original problem plus an extra step. The electronic catalog works when it is the channel.
- A dirty catalog. If your internal system has inconsistent descriptions or duplicated codes, the catalog will broadcast that mess to every customer at once. Cleaning the product master is the real prerequisite.
- Updating “whenever we get to it.” The value is in the discipline: every price change triggers its publication, no exceptions. An outdated electronic catalog is a PDF with a fancier name.
- “My customers are small, they don’t have systems.” Many already run accounting software that can receive catalogs; for the rest, web portals can display that same catalog. The single source serves both.
The same document in every EDI language
The electronic catalog is the transaction; “832” is just what one standard calls it. Depending on who you connect with, you’ll find it under these names:
| Standard | Message | Where you’ll see it |
|---|---|---|
| ANSI X12 | 832 (Price/Sales Catalog) | North America and the Americas |
| UN/EDIFACT | PRICAT (Price/Sales Catalogue) and PRODAT (product data) | Europe and EANCOM |
| TRADACOMS | PRIHDR/PRIDET (Price Information File) | Legacy UK retail |
| SAP IDoc | PRICAT01 / MATMAS (SAP’s internal format: not a company-to-company standard, but it’s what your SAP ERP emits and receives) | Companies running SAP |
| GS1 XML | Catalogue Item Notification (CIN) via GDSN | Global data pools |
The takeaway: learn the transaction, not the number. If you understand the electronic catalog — single source of truth, effective dates, lifecycle — switching syntax is a mapping exercise, not a fresh start.
The catalog is the first link
Notice the sequence: with the electronic catalog your customer knows what you sell and at what price; with the delivery schedule you know how much they’ll buy; and with the advance ship notice they know what’s on the way to them. It’s the same idea repeated: replace aging copies with shared information.
If your admin team lives reconciling price differences, the problem isn’t your people — it’s that every customer holds an old snapshot of your list. See how a single connected catalog works in our solutions — and count how many credit notes you issued last month over prices alone. That’s the number this document takes to zero.