PunchOut vs EDI: the session before the order and the documents after it

The short answer

PunchOut and EDI sit on either side of the purchase order.

• PunchOut happens before the order. A person at the buyer clicks your tile in Coupa or SAP Ariba, lands in your store logged in, fills a cart and sends it back. The cart becomes a requisition, and nothing is ordered yet.
• EDI happens from the order on. The buyer's system sends a purchase order, your system acknowledges it, and the confirmation, ship notice and invoice follow, file by file, with no person at a screen.

The search for "cXML vs EDI" mixes the two, because cXML covers both: the PunchOut session and a set of order documents that do the work of X12 transaction sets. Facts below were checked on October 3, 2026 against the cXML reference guide, version 1.2.071, and SAP's EDI guide for SAP Business Network suppliers.

Side by side

The same order in both

Bakker Installatie B.V., customer 10432, buys on SAP Ariba. The supplier takes PunchOut carts in cXML and has chosen EDI as its order routing on SAP Business Network.

The first two rows have no X12 counterpart. From the third row on, SAP's guide describes the translation: procurement applications send purchase orders to the network as cXML OrderRequest documents, and the network turns them into an X12 850 or an EDIFACT ORDERS, depending on the EDI language the supplier picked. Going back, the buyer can have the network convert the 855, 856 and 810 into cXML for its procurement application.

The first line of the cart, as it arrives in the cXML order and in the 850:

<ItemOut quantity="120" lineNumber="1">
  <ItemID>
    <SupplierPartID>10482</SupplierPartID>
    <SupplierPartAuxiliaryID>cart-7f3a91</SupplierPartAuxiliaryID>
  </ItemID>
</ItemOut>

BEG*00*SA*4500001234**20261103~
PO1*1*120*EA*9.6**VP*10482~

The quantity, the unit, the price and your part number come through. The cart reference cart-7f3a91 does not: the cXML reference notes that the supplier cookie is of data type "any" and does not easily map to other routing methods such as fax, email or EDI. The integration matches the 850 to the session by part number, quantity and price instead, and lists every order line that matches no cart for a person to check.

Counted per order: the session takes 3 cXML documents (setup request, response, cart). The EDI side takes 1 inbound 850 and 4 outbound files: the 997, the 855, the 856 and the 810. A customer with 40 orders a month means 40 x 3 = 120 session documents and 40 x 5 = 200 EDI files, 160 of them generated on your side from ERP data.

Where each one stops

PunchOut stops at the cart. OCI, SAP's own PunchOut protocol, has no purchase order at all; cXML continues with the order documents, but a supplier whose buyer asks for EDI orders needs the second channel anyway. The session also needs the buyer and the store online at the same moment: the store has to answer the setup request while the buyer waits.

EDI has no session and no cart. It cannot log a buyer into your store or show contract prices, and the closest it comes to a catalog is the X12 832 Price/Sales Catalog, a file of items and prices. On SAP Business Network it has documented limits of its own:

The 997 row is the one that misleads. A supplier that sends only the 997 has told the buyer the file parsed, not that the 120 receptacles will ship. The 855 does that.

What each asks in upkeep

What this means for your integration

PunchOut and EDI meet at the purchase order, and that is where most of the matching work sits: an 850 has to find the cart it came from without the cart reference, and the 855, 856 and 810 have to go out from the ERP with the PO number of the buyer. We build both sides on your existing store and ERP: the PunchOut session in cXML or OCI, and the order documents in cXML or X12, whichever each buyer asks for.

The PunchOut side is described on the PunchOut hub and the cXML documents on cXML PunchOut. The EDI side, with the ERP, is on EDI integration.