# The electronic catalog: the document that kills the stale-price order

date: 2026-07-06

> 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:

1. On Monday, the distributor updates prices in its ERP — exactly as it always has.
2. 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).
3. The catalog is transmitted **to every connected customer at once**. There aren't sixty PDFs; there is one publication.
4. Each pharmacy's system receives the catalog and updates its records: prices, presentations, barcodes, availability.
5. 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.

{{< figure src="/images/diagrams/catalogo-en.svg" alt="One publication, every customer: the list stops aging copy by copy" caption="One publication, every customer: the list stops aging copy by copy" class="diagram" >}}

### 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](/en/blog/x12-the-edi-language-of-the-americas/) | 832 (Price/Sales Catalog) | North America and the Americas |
| [UN/EDIFACT](/en/blog/edifact-the-edi-language-of-the-world/) | PRICAT (Price/Sales Catalogue) and PRODAT (product data) | Europe and EANCOM |
| [TRADACOMS](/en/blog/tradacoms-the-grandfather-of-retail-edi/) | 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](/en/blog/gs1-xml-the-language-of-business-learns-web/) | 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](/en/blog/edi-830-planning-without-guessing/) you know **how much they'll buy**; and with the [advance ship notice](/en/blog/edi-856-the-truck-that-calls-ahead/) 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](/en/solutions/) — and count how many credit notes you issued last month over prices alone. That's the number this document takes to zero.