cXML vs EDI: Purchase Order Formats Compared

cXML and EDI are both ways to send a purchase order as structured electronic data instead of a document a person reads, but they come from different worlds. EDI uses the X12 850 transaction set exchanged over a VAN or AS2 and dominates retail and manufacturing supply chains. cXML uses XML documents and is the language of cloud procurement platforms like Coupa, SAP Ariba, and Jaggaer, especially for punchout catalogs. If you are choosing between them, the deciding factor is usually which one your trading partners already speak.

Below is a plain-English breakdown of each format, a side-by-side comparison, and guidance on when each fits, plus what to do about the orders that still arrive as a PDF and belong to neither camp.

What is EDI?

EDI (Electronic Data Interchange) is a decades-old standard for exchanging business documents as structured data between companies. For purchase orders, the relevant document is the EDI 850, the ANSI X12 transaction set for a purchase order. An 850 carries the PO number, buyer, ship-to, dates, terms, and line items as coded segments and elements, and it moves between partners over a value added network (VAN) or a direct AS2 connection. EDI is deeply established in retail, grocery, automotive, and manufacturing, where large buyers often require suppliers to trade by EDI as a condition of doing business.

What is cXML?

cXML (commerce XML) is an XML-based protocol created for business-to-business e-commerce. A purchase order in cXML travels as an OrderRequest document whose XML elements hold the same buyer, ship-to, PO number, and line-item data. cXML is the backbone of modern procurement suites: Coupa, SAP Ariba, and Jaggaer use it to send POs and to run punchout, where a buyer shops inside a supplier catalog from within their procurement system and the cart returns as a cXML order. Because it is XML, it is human-readable in a text editor and comparatively quick for a developer to work with.

What is the difference between cXML and EDI?

The core difference is the encoding and the ecosystem. EDI encodes a purchase order as X12 segments transmitted over a VAN or AS2, and it rules traditional retail and manufacturing supply chains. cXML encodes the same order as XML and rules cloud procurement platforms and punchout catalogs. EDI tends to require more setup and specialized translation software; cXML is lighter to implement and native to tools like Coupa and Ariba. Neither is universally better; the right one is whichever your customers and suppliers already use.

cXML vs EDI: side-by-side comparison

What does a cXML purchase order look like?

A cXML purchase order is a plain-text XML document with a Header block that identifies the buyer and supplier by credential, and a Request block containing one OrderRequest. The order header carries the order ID, date and total, and every line becomes an ItemOut element with a quantity, a supplier part number, a unit price and a description. Here is a trimmed OrderRequest:

<!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.014/cXML.dtd">
<cXML payloadID="[email protected]" timestamp="2026-08-16T12:00:00-05:00">
  <Header>
    <From><Credential domain="DUNS"><Identity>123456789</Identity></Credential></From>
    <To><Credential domain="DUNS"><Identity>987654321</Identity></Credential></To>
    <Sender><Credential domain="NetworkID">
      <Identity>buyer.com</Identity><SharedSecret>secret</SharedSecret>
    </Credential><UserAgent>Coupa 1.0</UserAgent></Sender>
  </Header>
  <Request>
    <OrderRequest>
      <OrderRequestHeader orderID="PO12345" orderDate="2026-08-16" type="new">
        <Total><Money currency="USD">125.00</Money></Total>
        <ShipTo><Address addressID="WH1">
          <Name xml:lang="en">Main Warehouse</Name>
        </Address></ShipTo>
      </OrderRequestHeader>
      <ItemOut quantity="10" lineNumber="1">
        <ItemID><SupplierPartID>ABC-123</SupplierPartID></ItemID>
        <ItemDetail>
          <UnitPrice><Money currency="USD">12.50</Money></UnitPrice>
          <Description xml:lang="en">Hex bolt, 1/2 inch</Description>
          <UnitOfMeasure>EA</UnitOfMeasure>
        </ItemDetail>
      </ItemOut>
    </OrderRequest>
  </Request>
</cXML>

Two things in that sample cause most of the integration questions. The DOCTYPE line points at a versioned DTD on xml.cxml.org, so the cXML version you claim has to match the elements you actually send, and trading partners do reject documents that reference one version but use another version's elements. The SharedSecret inside the Sender credential is the authentication, which is why cXML posts go over HTTPS and why that payload should never be logged in plain text.

The same order as an X12 850 looks nothing like it. Segments are delimited by a terminator, elements by a separator, and nothing is labeled in a way a person can read without a segment reference open:

ISA*00*          *00*          *ZZ*BUYERID        *ZZ*SUPPLIERID     *260816*1200*U*00401*000000001*0*P*>~
GS*PO*BUYERID*SUPPLIERID*20260816*1200*1*X*004010~
ST*850*0001~
BEG*00*SA*PO12345**20260816~
REF*DP*DEPT42~
N1*ST*MAIN WAREHOUSE~
PO1*1*10*EA*12.50**VP*ABC-123~
PID*F****HEX BOLT 1/2 INCH~
CTT*1~
SE*8*0001~
GE*1*1~
IEA*1*000000001~

Read the PO1 segment as line 1, quantity 10, unit of measure EA, unit price 12.50, then a qualifier VP meaning vendor part number, then the part number itself. That positional structure is the whole difference in one line: cXML tells you what a value means by naming it, X12 tells you by where it sits.

What is the difference between EDI and XML?

That compactness is also why an X12 file will not open as a table, and converting an EDI 850 to Excel means walking the segments and rebuilding the item loop by hand. The same is true of every other transaction set, and the EDI to Excel converter guide sets out which detail loop becomes your rows for each one.

EDI is a set of business document standards, and XML is a way of encoding data. Classic EDI standards like X12 and EDIFACT use compact positional segments, while XML uses named, nested tags. The practical difference is readability and tooling: an XML order can be validated against a schema and read without a translator, and an X12 file cannot. cXML is simply an EDI-style order expressed in XML.

It helps to stop treating them as competing choices. EDI answers the question "which document standard do we both agree on", and XML answers "how is that document written down". There are XML-based EDI standards, and cXML, xCBL and OAGIS are all examples. When a supplier asks whether you support EDI or XML, what they usually mean is whether you can exchange X12 through a VAN or AS2, or post an XML document to an HTTPS endpoint.

Neither answer helps with the orders that arrive as an email attachment, and for most US suppliers that is still the largest share by document count. A buyer on a procurement suite sends cXML, a national retailer sends an 850, and the remaining several hundred customers send a PDF that a person retypes.

When should you use cXML vs EDI?

Use EDI when your trading partners require it, which is common if you sell into big-box retail, grocery, or automotive supply chains where the 850 is the expected format and compliance is mandatory. Use cXML when you operate inside a cloud procurement platform such as Coupa or SAP Ariba, or when you need punchout so buyers can shop your catalog from their system. Many suppliers end up supporting both, because different customers standardized on different formats and neither side wants to switch.

Can cXML and EDI work together?

Yes. Plenty of mid-market and enterprise suppliers run both in parallel, and integration middleware often translates between them so an order can arrive in one format and post into an order system in another. A data integration platform that connects your apps and APIs is a common way to normalize cXML and EDI feeds into one internal order structure, so the downstream ERP does not care which protocol the order came in on. The goal is a single clean order record regardless of the wire format.

How do you handle purchase orders that arrive as PDFs?

cXML and EDI are two of several ways an order can arrive without paper, and the electronic purchase order guide lays out the full set of formats and where each one fits. Neither cXML nor EDI covers the customer who simply emails a PDF, and there is always at least one. Smaller accounts, new buyers, and one-off orders frequently skip electronic formats entirely. Those PDFs still have to reach the same order system, which usually means someone retypes them. A faster path is to extract the data automatically: our tool reads a PDF or scanned purchase order and returns the header and every line item as structured fields you can route into either pipeline. If your target is XML, see purchase order to XML; if it is EDI, see PDF purchase order to EDI. For the wider picture of why PDF and EDI orders coexist, read EDI vs PDF purchase orders, and Coupa buyers can pair extraction with purchase order to Coupa. Upload a PO at the top of this page to see the structured output.

What is punchout and how does cXML enable it?

Punchout is the feature that made cXML the default in cloud procurement. In a punchout session, a buyer working inside their procurement system, such as Coupa or SAP Ariba, clicks through to a supplier's online catalog, shops there, and returns to their own system with a filled cart. cXML is what carries that round trip: a PunchOutSetupRequest opens the session, and a PunchOutOrderMessage brings the cart back, which the buyer then approves and issues as a cXML purchase order. EDI has no equivalent to this interactive catalog experience, which is a large part of why procurement suites standardized on cXML rather than X12. If your buyers expect to punch out to your catalog, cXML is effectively mandatory; if they send scheduled bulk orders through an established supply chain, EDI is the norm. This is another reason so many suppliers maintain both: the sales channel that runs on punchout and the one that runs on EDI rarely overlap.

The bottom line

cXML and EDI solve the same problem, moving a purchase order as machine-readable data, for two different ecosystems: cXML for cloud procurement and punchout, EDI for established retail and manufacturing supply chains. Choose based on what your partners require, expect to support both if you serve a mixed customer base, and have a plan for the PDF orders that fall outside both, because those are the ones that quietly cost your team the most manual time. If the decision in front of you is which procurement suite to run rather than which format to send, the practical differences are laid out in Coupa vs Ariba.