EDI 832 Price/Sales Catalog: Item Master Sync Without Pricing Errors

A supplier announces a price rise for December, the EDI team loads the 832 the day it arrives, and for two weeks every purchase order goes out at next month's price. In another building, the same file quietly changes a case from 24 packs to 20, the item master keeps the old count, and the receiving dock spends a week reporting shortages that are not shortages. Neither failure shows up as an EDI error. The translator accepted both files without complaint.

The X12 832 Price/Sales Catalog carries exactly the fields that cause these errors: item identifiers, pack structure, price type, price basis and the dates that bound each price. Treat each of those fields as a controlled change to the buyer's item master, with a staging step and a named approver, and pricing variances on invoices drop to the few that are real disputes rather than load mistakes.

• What this guide covers: the BCT header, item identity in LIN, the PO4 pack hierarchy, price lines in CTP, effective and expiry dates, and the India-only label and tax fields that an 832 does not carry unless both sides agree to add them.
• What it adds: a sample 832 with the conversion arithmetic, a worked US ($) and India (₹) case-pack example, an incident trace, and an intake checklist for EDI and master data teams.

What an inbound 832 is allowed to change in the item master

An 832 is a proposal from the seller, not an instruction to overwrite the buyer's records. X12 places the 832 in its supply chain group and describes it as the standard way to furnish or request the price of goods or services in catalog form. Nothing in that purpose says the receiver must apply every field it receives, on arrival, to live pricing.

The useful split is between descriptive fields the seller owns and commercial fields both parties own. Description, dimensions and gross weight usually belong to the seller. Price, the unit that price applies to and the date it starts are commercial terms that should match a contract or a quote. The table sets out who supplies each group of fields and who approves the change before it reaches purchasing.

This article sits next to our piece on flash sale stock buffers and WMS to ERP sync, which deals with how fast available quantity moves between systems during a sale. Here the subject is slower and more expensive to get wrong: the item and price records that every later order, receipt and invoice is checked against.

Reading the BCT header for catalog purpose and change intent

The BCT segment tells you whether the file replaces a catalog or edits one, and nothing downstream should run until that is clear. BCT01 is mandatory and carries the Catalog Purpose Code. In the 4010 code list the values are CP for a customized catalog, PC for a price catalog, PS for a price sheet, RC for a resale catalog and SC for a sales catalog.

• Catalog number and version: BCT02, BCT03 and BCT04 carry the catalog number, version and revision. Store all three and refuse a revision lower than the one already applied, which stops an old file replayed from an archive from rolling prices back.
• Transaction set purpose: BCT10 uses the common purpose codes, where 00 is Original, 04 is Change and 05 is Replace. Sellers usually send an original or replace file as a full catalog, so any item missing from it needs a decision; a change file should move only the items it lists.
• Item-level maintenance: inside each LIN loop, G53-01 states the maintenance type for that item, for example 001 Change, 002 Delete, 003 Add Full Item Detail, 004 Withdraw Item (Temporary) and 005 Restore Item.

Partners rarely use every code. Ask each seller which BCT01 value and which BCT10 values they will send, write the answer into the partner profile, and reject anything outside it to an exception queue rather than guessing. A seller who sends PS price sheets for promotions and PC price catalogs for list prices is telling you which records each file should touch.

Matching items through LIN qualifiers before any price is applied

A price can only be applied once the item is matched without doubt, so identification comes before every other check. The LIN segment carries pairs of a product ID qualifier and a value. Common qualifiers include UP for the U.P.C. consumer package code, UK for the 14-digit U.P.C./EAN shipping container code, EN for the European Article Number, VN for the vendor's item number and IN for the buyer's item number.

Match on the GTIN first, then confirm the vendor number agrees with the cross-reference you already hold. If the GTIN matches one item and the vendor number another, stop: either the seller reused a number or your cross-reference is stale, and applying a price to the wrong record is harder to unwind than holding the file for an hour. Check-digit validation on every UP, UK and EN value is a fixed rule and needs no human.

X12 832 item matching in the buyer's ERP item master should accept a LIN line only when the UP or UK GTIN passes its check digit and maps to the same item as the VN vendor number; a mismatch rate above 0.5% of lines usually means a stale cross-reference, not a seller error.

Retail buyers who also take product data through the GS1 Global Data Synchronisation Network will see the same item twice. GS1's GDSN Operations Manual (release 3.1) describes a recipient answering a catalogue item notification with a Catalogue Item Confirmation in one of four states: Synchronised, Received, Rejected or Review. The same manual notes that data may also reach a recipient through existing EDI message sets unrelated to GDSN, so decide which channel wins for each attribute.

Turning PO4 pack fields into eaches the warehouse can count

PO4 defines how many sellable units arrive in a case, and a wrong pack count corrupts ordering, receiving and cost at the same time. PO4-01 is Pack, the number of inner containers per outer container, or eaches when there are no inners. PO4-14 is Inner Pack, the number of eaches per inner container. PO4-02 and PO4-03 give the size of each unit and its measure.

• Eaches per case: when PO4-14 is present, eaches per case equals PO4-01 multiplied by PO4-14. When PO4-14 is absent, PO4-01 already counts eaches.
• Weight and cube: PO4-05 to PO4-07 give the weight qualifier, gross weight per pack and its unit; PO4-08 and PO4-09 give gross volume; PO4-10 to PO4-13 give length, width, height and their unit. Slotting, pallet build and freight rating all read these.
• Syntax pairs: the standard ties PO4-02 to PO4-03 and PO4-06 to PO4-07, so one without the other is a syntax error the translator can reject on its own.

The dangerous change is a pack count that moves while the case price stays flat. A seller that cuts a case from 24 packs to 20 at the same case price has raised the unit cost by 20%, and a buyer that applies only the CTP line will never see it. Compare the new eaches-per-case figure with the stored one on every file and route any change to the warehouse master data lead and the buyer together.

Our guide to case-pack and pallet-tier ordering rules covers how those pack levels then drive minimum order quantities in the WMS. The 832 is where the pack levels enter, so an error here propagates into every order rounding rule built on top of it.

Price lines in the CTP loop: price type, basis quantity and unit

A CTP line is only meaningful when you know what kind of price it is and what unit it buys. CTP-02 is the Price Identifier Code, CTP-03 the unit price, CTP-04 a quantity and CTP-05 the composite unit of measure; the standard requires CTP-04 and CTP-05 together. A price of 82.80 per CA and 82.80 per EA differ by a factor of the pack count.

• Price identifier codes: the 4010 list includes CAT Catalog Price, CON Contract Price, WHL Wholesale, NET Net Item Price, LPR List Price, PRP Promotional Price, MSR Manufacturer's Suggested Retail and RTL Retail.
• Class of trade: CTP-01 can scope a price to a class of trade, so a distributor price and a retailer price for the same GTIN can travel in one file without colliding.
• Multiple-price quantity: CTP-11 states how many units a price covers, as in three for a stated amount, and requires CTP-03. Store it rather than dividing at load, or the original offer is lost.
• Discount multipliers: CTP-06 and CTP-07 carry a price multiplier qualifier and factor, for example 0.90 for a 10% discount off a referenced price.

The sample below is a single-item change file for a 500 g carton of black tea. It moves the wholesale case price and adds a suggested retail price, each with its own dates. The comment lines after it give the conversion the intake job applies before comparing anything with stored values.

ST*832*0001~
BCT*PC*CAT-2611*3*2******04~
LIN**UP*012345678905*VN*TEA-500-AS~
G53*001~
PID*F****ASSAM BLACK TEA 500 G CARTON~
PO4*20*500*GR**G*11.2*KG~
CTP**WHL*86.40*1*CA~
DTM*007*20261201~
DTM*036*20270531~
CTP**MSR*4.99*1*EA~
DTM*007*20261201~
CTT*1~
SE*13*0001~

-- intake arithmetic (applied in staging, never in the translator)
-- E   = eaches per case = PO4-01 x PO4-14 (PO4-01 alone if PO4-14 is blank) = 20
-- Pe  = price per each  = CTP-03 / (CTP-04 x E) when CTP-05 = CA = 86.40 / 20 = 4.32
-- dP  = (Pe_new - Pe_stored) / Pe_stored
-- hold the line for buyer approval when |dP| > 0.05 or E_new <> E_stored

The five percent hold threshold in that comment is an illustration; set it per category. Fresh produce and commodity-linked goods move often and need a wider band, while a branded consumer item that changes price once a year can sit at two percent. What matters is that the threshold works on the price per each after pack conversion, not on the raw CTP-03 figure.

Staging effective and expiry dates instead of overwriting today

Every price in an 832 needs a start date, and the intake job should store it as a future-dated record rather than change the price in force today. The DTM segment inside the CTP loop carries the dates for that price. In the 4010 date qualifier list, 007 is Effective, 036 is Expiration, 196 is Start and 197 is End.

Agree with each seller which event the effective date governs: the purchase order date, the requested ship date or the actual ship date. Contracts differ, and an ERP that prices purchase orders by order date will disagree with a seller that invoices by ship date whenever an order straddles the change. Write the rule into the partner profile and into the purchase pricing condition, so both systems resolve the same price for the same order.

1. 18 Nov 2026, 07:42: Catalog CAT-2611 version 3 revision 2 arrives with BCT10 = 04, a WHL case price of $86.40 and DTM*007*20261201. The contract price until then is $82.80.
2. 18 Nov, 07:43: The middleware map writes CTP-03 directly to the ERP purchasing price record and ignores the DTM in the CTP loop, so the higher price applies at once.
3. 18 to 30 Nov: Fourteen 850 purchase orders covering 3,150 cases go out at $86.40. Goods receipts value the stock at the same price.
4. 2 Dec, 09:10: The seller's 810 invoices arrive at $82.80 because the goods shipped before 1 December. Three-way match flags a $3.60 per case variance on 14 invoices; inventory is overstated by $11,340 and accounts payable blocks payment.
5. 3 Dec, 10:15: The fix stages each CTP line with valid-from and valid-to dates, prices purchase orders by the contract's ship-date rule, and revalues the 14 receipts. Nothing in the original 832 was wrong; only the load was.

Price intake for an X12 832 change catalog stores each CTP line with its DTM 007 effective date and DTM 036 expiration date as a future-dated ERP pricing condition, so purchase orders created before the effective date keep the contract price and three-way match variances stay below 1% of invoice lines.

Expiry dates deserve the same care. A promotional PRP price with no DTM 036 stays in force until someone remembers to remove it. Reject promotional price lines that arrive without an end date, and alert the buyer a week before any stored price expires without a replacement in staging.

India fields an 832 omits unless partners agree to carry them

The X12 832 has no field defined for an Indian label price or a GST classification, so Indian trading partners must agree where to carry them. This matters most for Indian distributors and exporters exchanging X12 with each other or with US customers; purely domestic partners may use another format entirely, and in that case only the business rules below still apply.

• HSN classification: Notification No. 78/2020-Central Tax requires tax invoices from 1 April 2021 to show a 4-digit HSN code where aggregate turnover in the preceding financial year was up to ₹5 crore and 6 digits above that; the smaller sellers may omit the digits on supplies to unregistered persons. The LIN qualifier HD, International Harmonized Commodity Code, is one place partners can carry it.
• Maximum retail price: rule 2(m) of the Legal Metrology (Packaged Commodities) Rules, 2011 defines retail sale price as the maximum price at which the packaged commodity may be sold to the consumer inclusive of all taxes, and rule 6(1)(e) requires it on every package in Indian currency.
• Unit sale price: rule 6(11) requires the unit sale price in rupees: per gram for packs under one kilogram, per kilogram for larger packs, and per number for items sold by count.
• Online listings: rule 6(10) makes an e-commerce entity display the mandatory package declarations on its platform, so an MRP that changes in the item master must also change on the listing.

For the tea carton in the sample, an MRP of ₹285 for 500 g gives a unit sale price of ₹0.57 per gram. If a seller sends a new MRP through a partner-agreed MSR or RTL line, the intake job should recompute the unit sale price and check that the stock already on shelves, printed with the old MRP, is handled under the rules for revised prices before the listing changes.

A case-pack change worked through in dollars and rupees

A pack count that falls while the case price stays the same raises unit cost and creates false shortages at receiving. The worked example uses the tea carton. The seller moves from 24 to 20 cartons per case and keeps the case price; the buyer's item master keeps the old pack count because only the CTP line was applied. Figures are illustrative.

The receiving team will raise 200-carton shortage claims that the seller will reject, because the seller shipped exactly what its catalog said. Meanwhile the margin report shows the Indian line at 3.2% against MRP before GST is even deducted, which a category manager would never have approved knowingly. Both problems disappear when the pack comparison runs at intake.

Case-pack control for X12 832 intake compares PO4-01 multiplied by PO4-14 with the stored eaches per case in the ERP item master and holds any change for warehouse and buying approval, because a 24-to-20 pack cut at a flat case price raises unit cost by exactly 20%.

Validation rules that run alone and reviews that need a person

Most 832 checks are arithmetic or lookups and should run without anyone watching; judgment is needed only where the file is technically valid but commercially odd. The split below names each task, so the team knows which exceptions a machine can close and which need a buyer, a master data steward or the tax team.

Keep any assisted suggestion out of the live item master until a named person accepts it, and record who accepted what. Auditors reviewing purchase price variance will ask why a price changed, and "the model matched it" is not an answer they accept.

Rolling out 832 intake with a staging table and a parallel price check

Run the new intake beside the current process for one full pricing cycle before letting it update live records. The staging table holds every parsed line, the conversion results and the hold reason; the parallel run compares the staged price per each with what purchasing actually used. Our ERP and WMS integration test cases include item master and unit-of-measure scenarios that fit this rehearsal.

The 832 is one of several item and order messages described across our logistics and supply chain library, alongside ship notices, warehouse orders and carrier status. If you are planning catalog intake for many sellers, or replacing manual price-list loading, you can outline your partners, volumes and ERP through our request for proposal form.