PunchOut catalog

cXML (commerce XML) is the message format behind most PunchOut integrations. A session is a short, ordered exchange of documents between the buyer's procurement system and the supplier's site.

Document	Direction	What it carries
PunchOutSetupRequest	Buyer → supplier	Identity and shared secret, a buyer cookie, and the URL the cart should post back to
PunchOutSetupResponse	Supplier → buyer	A one-time start URL for this session
PunchOutOrderMessage	Supplier → buyer	The cart: one line per item, with part ID, description, price, UOM, UNSPSC
OrderRequest	Buyer → supplier	The approved PO, after the requisition clears internal approval

Three things follow from that flow. The session is authenticated, so the pricing shown is that buyer's contract pricing, not list. Nothing is ordered at cart return. The line sits in a requisition until someone approves it. And the OrderRequest you receive later has to reconcile against the part IDs and units you sent in the cart, or the PO fails at your end.

Each line in the PunchOutOrderMessage is a small, strict record. Here are the fields the buyer's system validates on arrival, with a hex cap screw as the example:

cXML element	Example value	Rule
SupplierPartID	HCS-38162-G8Z	Must match the ID on the OrderRequest you get back
SupplierPartAuxiliaryID	ZINC-YLW-BX100	Carries the variant and pack context; omit it and the line loses which variant was bought
Description	3/8"-16 x 2" Grade 8 hex cap screw, zinc-yellow	Gets truncated to the buyer's field length, so front-load the identifying spec
UnitOfMeasure	BX	Must be a UN/CEFACT code such as EA, BX, or CA, not the word "box"
UnitPrice	42.60 USD	Must be price per the UOM sent, or the invoice mismatches
Classification domain="UNSPSC"	31161500 (bolts)	Must be an 8-digit commodity code; shallower codes usually pass validation but misroute the spend

UNSPSC is the field that catches distributors out. The buyer wants an 8-digit commodity code per SKU for spend analysis and category routing. A blanket 31000000 on every fastener will usually pass validation, and then the buyer's spend report rolls every fastener you sell into one line.

Buyers use three arrangements, and large accounts often run more than one at once.

Model	Where the data lives	What it demands of you
Hosted / CIF catalog	Uploaded into the buyer's system as a flat file	Every line pre-classified, priced, and unit-coded; refresh on a cycle
Level 1 PunchOut	Your site, reached from the procurement system	A working session, contract pricing, a clean cart return
Level 2 PunchOut	Both: an index file in the buyer's system, deep-linking into your site	An index of items with UNSPSC and UOM, plus everything Level 1 requires

Level 2 is where the attribute burden shows up. The buyer searches your items inside Coupa or Ariba before ever reaching your site, so your item index becomes their search experience. If that index says only "hex bolt," nobody finds the Grade 8 zinc-yellow one by thread pitch.

The integration is rarely the problem after go-live. The data is. Common failures, roughly in the order they surface:

• UNSPSC at the wrong depth. Segment-level codes across tens of thousands of SKUs, because nobody classified below the 2-digit segment during onboarding. 31000000 is a segment code, not a commodity code.
• UOM drift. The site sells per box of 100, the cart sends EA, and the invoice mismatches by two orders of magnitude.
• Descriptions that identify nothing. "Hex cap screw" survives truncation; the diameter, thread pitch, grade, and finish do not.
• Search inside the PunchOut that ignores specs. A maintenance buyer needs a UL listed 600V wire connector for 12-10 AWG. If gauge range and voltage rating are not filterable attributes, they call your branch instead, and PunchOut was supposed to stop that call.
• Part ID drift. The cart's SupplierPartID no longer matches your ERP item after a renumbering, so OrderRequest documents fail silently.
• New items missing from the PunchOut entirely. They exist in the ERP, but were never classified or attributed well enough to expose.

The attributes you send in the cart are the attributes your buyer's category manager reports on. Your largest accounts see your UNSPSC codes, your unit codes, and your specs inside their own spend reports, and the gaps become their problem before they become yours.

A PIM is where UNSPSC, UOM, and the attribute set live. What it does not do is fill the empty UNSPSC cells across a catalog, normalize BX / Box / box of 100 down to one code, or read a manufacturer's spec sheet to find the thread pitch that belongs in a filterable field.

That completion work is what Anglera does, alongside the PIM you already run.