Send retailer-compliant EDI 832 price and sales catalogs generated natively by AIMS360. Segments, a sample 832 file, and how GS1 UPCs, product data and standard color and size codes reach the OpenText GXS Active Catalogue, InterTrade and other catalogs without manual data entry.
An EDI 832 is the electronic price and sales catalog a supplier sends so a retailer's system knows what every item is, how it is sized and colored, and what it costs. This reference explains what an 832 is, walks the X12 segments, shows a sample 832 file, and covers how AIMS360 sends UPCs, product data and standard color and size codes to the OpenText GXS Active Catalogue, InterTrade and other catalogs without anyone typing them into a portal.
An EDI 832 is the price and sales catalog transaction set in the ANSI ASC X12 standard. A supplier sends it to a retailer, or to a catalog data pool the retailer subscribes to, so the buyer's system holds the correct item number, description, color, size, pack configuration and price for every product being offered.
Every X12 document has a three-digit code: 850 is the purchase order, 856 is the advance ship notice, and 832 is the catalog. The code appears in the file's ST segment, which is why an 832 always opens with ST*832.
Think of the 832 as the line sheet, the price list and the item master rolled into one machine-readable file. It answers the questions a buying system has to settle before it can order anything: what is this item, what is its GTIN, what colors and sizes does it come in, how is it packed, what does it cost me, and what should it sell for.
The 832 is the quiet document in the order-to-cash cycle. It carries no money and generates no shipment, so it gets less attention than the 850 purchase order or the 810 invoice. It is also the document most likely to be maintained by hand, which is exactly why so many downstream problems trace back to it. A wrong price in a catalog becomes a wrong price on a purchase order, then a short pay, then a chargeback three months later.
Retailers and routing guides use several names for the same file: price catalog, price file, item file, catalog file, product data catalog, or simply "your 832." They all mean this transaction set.
Almost every ERP can produce a UPC. Far fewer can take the whole catalog record — the GS1 UPC or GTIN, the product attributes, the standard color and size codes, the pack configuration and both price levels — and publish it to a retailer's catalog as an 832 with nobody re-typing it into a web form. That gap is where most consumer brands lose hours and gain errors.
AIMS360 generates the 832 from the style record itself. The GS1 UPC or GTIN, the product data, and the standard NRF and GS1 US color and size codes are all written into the file by the ERP, and sent to the OpenText GXS Active Catalogue, InterTrade and other catalog data pools automatically.
You build the style once. Everything the catalog needs already exists, so there is nothing left to enter.
Every price change and every dropped colorway starts this loop again, in every portal.
Change a price or drop a color and a maintenance 832 goes out on its own. No portal, no spreadsheet, no code lookup.
| What the catalog needs | In AIMS360 | Typical ERP without built-in EDI |
|---|---|---|
| GS1 UPC or GTIN | Assigned when the style is built, UCC-12, EAN-13 or GTIN-14 | Often generated, then exported and re-entered |
| Standard color code and description | Mapped automatically from your color, NRF and GS1 US codes | Looked up in a code table by a person |
| Standard size code and description | Mapped automatically from your size scale | Looked up by a person, per size, per scale |
| Product attributes | Pulled from the style record: description, fabric content, country of origin, weight, dimensions | Re-entered per catalog, per retailer |
| Pack and prepack configuration | Carried from the pack setup already in the ERP | Re-described in each portal |
| Wholesale cost and suggested retail | Read from live pricing, with effective dates | Copied from a spreadsheet that ages immediately |
| Adds, changes and deletes | Sent as maintenance 832s when the record changes | Manual edits in every portal, or a full re-upload |
| Who builds the X12 file | AIMS360, natively | A third-party translator, from your export |
AIMS360 develops and owns its EDI engine, and that engine runs inside the consumer brands ERP. It is not a resold or white-labeled third-party service such as SPS Commerce, TrueCommerce, DiCentral or Cleo. One nuance worth stating plainly: sending your catalog to a partner such as InterTrade, which SPS Commerce acquired in October 2022, is not the same as licensing that company as your EDI provider. AIMS360 still builds, maps, validates and transmits the file. For the longer argument, read why an integrated ERP and EDI solution is essential for growing brands.
An 832 rarely goes straight to a buyer's inbox. Most large retailers subscribe to a catalog or data pool and pull item data from it, which is why "register your UPCs" is usually the first thing a new vendor is told to do. These are the destinations consumer brands hit most often.
| Destination | What it is | Who asks for it |
|---|---|---|
| OpenText GXS Active Catalogue | The catalog formerly run by GXS, now part of OpenText Business Network. Retailers pull registered item data from it using your account ID. | Nordstrom, Macy's, Bloomingdale's, Saks, Dillard's and many other department stores |
| InterTrade | A product and transaction data exchange, part of SPS Commerce since October 2022, widely used in Canadian and cross-border retail. | Canadian retail programs and cross-border department stores |
| Retailer direct | Some retailers take the 832 straight into their own item master with no intermediate catalog. | Mass, off-price and specialty chains |
| Dropship platforms | Dropship programs need the catalog before they can list, and pair the 832 with a frequent 846 inventory advice. | Nearly every dropship and marketplace program |
| GDSN data pools | Not an 832. GDSN is a separate GS1 network where item data is published to a certified pool and subscribers synchronize from it. | Mostly grocery, hardlines and some mass retailers |
The last row matters when you read a routing guide. If a retailer names a data pool rather than a transaction set, ask which mechanism they expect before building anything — GDSN and the 832 solve the same problem in different ways, and a brand can end up paying for both. For the OpenText path specifically, the GXS Catalog and OpenText integration page covers required attributes, validation and how updates propagate.
An 832 is a structured text file made of segments. Each segment starts with a two or three letter ID and holds related data elements separated by a delimiter. The header describes the catalog, the detail loop repeats once per item, and the summary closes the file. These are the segments you will see most often in a consumer goods 832.
| Segment | Name | What it carries |
|---|---|---|
| ISA / GS | Interchange and group envelope | Sender and receiver IDs, control numbers and the standard version. Wraps the transmission. The functional group ID for a catalog is SC. |
| ST | Transaction set header | Opens the catalog. ST01 is 832, ST02 is the control number. |
| BCT | Beginning segment for price/sales catalog | Catalog purpose code, catalog number, version and revision, and a description. BCT01 says what kind of catalog this is, for example PC price catalog or SC sales catalog. |
| REF | Reference identification | Extra IDs such as the vendor number the buyer assigned you (REF*IA) or a department number. |
| DTM | Date/time reference | Effective dates for the catalog or the pricing, which is how future price changes are staged in advance. |
| CUR / ITD | Currency and terms of sale | The currency the prices are stated in, and payment terms where the catalog carries them. |
| N1 / N3 / N4 | Name and address | The vendor and the buying party, with the ID qualifier each partner expects. |
| LIN | Item identification | Opens each item. Carries paired qualifier and value: UP for the UPC, UK or EN for other GTIN formats, VP for your style number, SK for the SKU. |
| G53 | Maintenance type | Tells the catalog whether this line is an add, a change or a delete. This is what makes an incremental price update possible without resending everything. |
| PID | Product / item description | The item description, and the coded characteristics most apparel catalogs require, including color and size. Standard color and size code values ride here. |
| PO4 | Item physical details | Pack and inner-pack quantities, size, weight and carton dimensions. |
| MEA | Measurements | Additional measurements such as unit weight where the partner requires them separately. |
| CTP | Pricing information | The prices for that item. CTP01 is the class of trade, CTP02 identifies which price this is, for example net cost or suggested retail, and CTP03 is the amount. |
| SAC | Service, promotion, allowance or charge | Allowances and charges that apply to the catalog or the item rather than to product cost. |
| CTT | Transaction totals | The number of line items in the catalog, used as an integrity check. |
| SE | Transaction set trailer | Closes the catalog and counts the segments. |
Segment and code requirements vary by trading partner. Each retailer and each catalog publishes its own 832 specification defining which segments are mandatory and which code values are accepted, and the same brand can be required to send meaningfully different files to two retailers. AIMS360 configures your map to each one.
A simplified 832 carrying one style in one color and one size. A real catalog repeats the LIN loop once per UPC, so a modest apparel line runs to thousands of lines.
ISA*00* *00* *ZZ*NORTHSIDEAPPRL *ZZ*OPENTEXTGXS *260804*1042*U*00401*000000117*0*P*>~ GS*SC*NORTHSIDEAPPRL*OPENTEXTGXS*20260804*1042*117*X*004010~ ST*832*0001~ BCT*PC*FA26-LINE*004010*01*****Fall 2026 wholesale catalog~ <- catalog header REF*IA*812345~ <- vendor number assigned by the buyer DTM*007*20260801~ <- pricing effective date CUR*SE*USD~ N1*VN*NORTHSIDE APPAREL CO*92*812345~ <- vendor N1*BY*NORDSTROM INC*92*0001~ <- buying party LIN**UP*812345000019*VP*NS4412*SK*NS4412-BLK-MD~ <- UPC, style, SKU G53*003~ <- maintenance type: add full item detail PID*F****WOMEN'S MERINO WOOL CREWNECK SWEATER~ <- free-form description PID*S*35*NR*BLK~ <- coded color PID*S*74*NR*030~ <- coded size PID*F*92***100% MERINO WOOL~ <- fabric content PO4*1*1*EA~ <- pack and unit of measure MEA*PD*G*0.9*LB~ <- unit weight CTP**NET*58.00~ <- wholesale cost CTP**MSR*128.00~ <- suggested retail CTT*1~ <- one line item in this catalog SE*19*0001~ <- 19 segments from ST through SE GE*1*117~ IEA*1*000000117~
Simplified for readability, and illustrative rather than a specification. Envelope control numbers, ID qualifiers and code values — including the catalog purpose code, the maintenance type, the agency qualifier on coded characteristics and the price identifiers — are set by each retailer's published 832 guideline. Read the routing guide before you build, or let the AIMS360 EDI team map it.
The 832 gets mixed up with three other transactions, usually because all four talk about products. The difference is what question each one answers.
| Document | Question it answers | Direction | How often it is sent |
|---|---|---|---|
| 832 Price/Sales Catalog | What is this item, and what does it cost? | Supplier to retailer or catalog | On setup, then whenever an item or price changes |
| 846 Inventory Advice | How many do you have right now? | Supplier to retailer | On a schedule, often daily or hourly |
| 850 Purchase Order | Send me this many of that item. | Retailer to supplier | Whenever the retailer orders |
| 852 Product Activity Data | How is it selling, and what is left on the floor? | Retailer to supplier | Weekly, sometimes daily |
The ordering matters. The 832 has to land before the 850 can reference an item, and a stale catalog is one of the quietest causes of order and pricing disputes. From there the flow continues through the 856 advance ship notice with UCC 128 carton labels, the 810 invoice, and the 820 payment.
Because every one of those documents is generated from the same style, order and shipment records inside AIMS360, they cannot drift from each other. That is not true when the catalog lives in a portal, the order lives in the ERP and the invoice is built by a translator. When a retailer short-pays because the price on the invoice does not match the price in their item file, this is almost always why. Chargeback management gets easier when the catalog was right in the first place.
Create the style in AIMS360 with its full color and size matrix, pack configuration, costs and prices. This record is the single source of truth for every document that follows.
AIMS360 assigns the GS1 UPC or GTIN — UCC-12, EAN-13 or GTIN-14 — and maps your internal color and size values to the standard NRF and GS1 US color and size codes and their descriptions. No code table, no lookup, no per-retailer spreadsheet.
Each partner's extra requirements — published cost, suggested retail, fabric content, country of origin, garment weight, carton dimensions — are applied from the same record without re-entry.
AIMS360 assembles the X12 file itself, validates it against that partner's specification, and transmits it to the OpenText GXS Active Catalogue, InterTrade or the retailer directly. No export, no third-party translator, no VAN in the middle.
AIMS360 processes the 997 functional acknowledgment, and after that the catalog maintains itself. Change a price, discontinue a colorway, adjust packaging or add a style, and a maintenance 832 goes out without anyone logging into a portal.
A useful test when evaluating any consumer brands ERP: ask who types the color code. If the answer is a person, in a portal, once per retailer, the catalog will drift — and every downstream document inherits the drift.
The questions consumer brands ask most often about the price and sales catalog, catalog data pools, and standard color and size codes.
EDI 832 is the Price/Sales Catalog transaction set in the ANSI ASC X12 standard. A supplier sends it to a retailer, or to a catalog data pool the retailer subscribes to, so the buyer's system holds the correct item number, description, color, size, pack configuration and price for every product. It is the electronic version of a line sheet or price list, and it is usually the first document exchanged in a new trading relationship because a retailer cannot issue an accurate purchase order for an item it has never seen.
A typical apparel or consumer goods 832 carries, for every item: the GTIN or UPC, your style number, the product description, the color and size (usually as standard coded values plus descriptions), the pack or prepack configuration, physical details such as weight and dimensions, country of origin, wholesale cost, suggested retail price, and effective dates for that pricing. It also carries a maintenance flag on each line telling the catalog whether the item is being added, changed or deleted.
Practically, yes. The 832 is how a price list and a product catalog travel electronically. Some retailers call the same file a price file, a catalog file, an item file or a line sheet upload. They are all the 832.
The 832 is your catalog and pricing: what the item is and what it costs. The 846 is your inventory advice: how many of that item you have available right now. The 832 is sent when items or prices change. The 846 is sent on a schedule, often daily or hourly, because the number changes constantly. Dropship programs almost always need both.
Yes, and that ordering is the reason the 832 matters more than its reputation suggests. Most retailers will not release a purchase order for an item that is not registered in their catalog or data pool. The 832 loads the item, and the 850 purchase order can then reference it. If your catalog is stale, orders stall or arrive with the wrong price, which becomes a chargeback later.
Any supplier whose retail partners maintain a central item file. In practice this covers most department stores, most large specialty chains, and nearly every dropship program. Nordstrom, Macy's, Bloomingdale's, Saks, Dillard's, Kohl's and many others expect item and price data to arrive electronically rather than by spreadsheet.
They are the standard numeric codes the U.S. retail industry uses so that everyone means the same thing by “black” or “medium.” They were published for decades by the National Retail Federation, which is why the industry still says NRF color codes and NRF size codes. Since June 2020 the codes have been administered by GS1 US and published as the GS1 US Color and Size Codes. The codes themselves carried over, and retailer routing guides still use both names, so you will see them written either way.
Yes. You set up a style once with its color-size matrix in AIMS360, and AIMS360 maps your internal color and size values to the standard coded values and their descriptions. They are then written into every 832 the system sends. Nobody looks up a code table, and nobody types a code into a portal.
Yes. AIMS360 publishes item and price data directly into the OpenText Active Catalogue, formerly the GXS catalog, without a separate catalogue.gxs.com login and without a VAN in the middle. The dedicated page on that integration walks through what is registered, which attributes are required and how updates propagate.
Yes. AIMS360 sends catalog data to InterTrade, which has been part of SPS Commerce since October 2022 and is used heavily by Canadian and cross-border retail programs. Sending a document to a partner's catalog is not the same as licensing that company as your EDI provider. AIMS360 still builds, maps, validates and transmits the file with its own EDI engine.
It is built in. AIMS360 develops and owns its EDI engine and runs it inside the consumer brands ERP. It is not a resold or white-labeled third-party service such as SPS Commerce, TrueCommerce, DiCentral or Cleo. AIMS360 builds the X12 832 itself from the styles, colors, sizes and prices already in your database, maps it to each retailer or catalog specification, transmits it, and processes the 997 acknowledgment that comes back.
You let the ERP send them. In AIMS360 the UPC or GTIN is generated when the style is built, so the moment the style exists the catalog record exists. The 832 carries it to the retailer or data pool automatically. The portal path, exporting a spreadsheet and re-keying it into a web form, is what most brands do and is where most catalog errors come from.
AIMS360 sends a maintenance 832. Each line in an 832 carries a maintenance type telling the catalog whether that item is an add, a change or a delete, so a price change or a discontinued colorway propagates without resending the entire catalog and without anyone logging in.
Both exist and it is worth knowing which one you are being asked for. The 832 is an X12 EDI document sent to a retailer or catalog. GDSN is a separate GS1 network where you publish item data to a certified data pool and subscribers pull it. Grocery, hardline and some mass retailers lean on GDSN. Apparel, footwear, accessories and department stores overwhelmingly use the 832. If a routing guide names a data pool rather than a transaction set, ask which mechanism they expect before you build anything.
AIMS360 supports the X12 versions its retail partners publish, most commonly 4010 and 5010. The segment structure is stable across both. What actually differs between partners is which segments and code values are mandatory, and that is handled per retailer in the map rather than by the version number.
One team. Because the EDI engine and the ERP are the same platform, the people supporting your catalog are the people who built the map and who can see the underlying style record. With a bolted-on EDI provider, a rejected 832 usually means opening tickets with both your ERP vendor and your EDI vendor.
AIMS360 sends your GS1 UPCs, product data and standard color and size codes to the OpenText GXS Active Catalogue, InterTrade and your retailers as an EDI 832 — generated from the styles you already built, with no portal and no re-keying.
