Free tool

PunchOut cXML & OCI tester

Paste a PunchOutSetupRequest, a PunchOutOrderMessage, an OrderRequest, an invoice, or an OCI return. You get the structural problems back in plain language.

The document you paste never leaves your browser. Validation runs on your machine using the browser's own XML parser. There is no form on this page, and the validator makes no network request of any kind — you can disconnect after the page loads and it keeps working. To be precise rather than absolute: the site does load page analytics, so the network tab is not empty. What it will never contain is your document. Redacting the shared secret before pasting is still a sensible habit.

What it checks

Structure Well-formedness, the cXML root, payloadID and timestamp, and whether the payload sits in the right wrapper — a PunchOutOrderMessage inside <Request> instead of <Message> is a common and confusing failure.
Credentials From, To and Sender blocks, each Credential carrying a domain, an Identity that is not empty, and a SharedSecret where the document type expects one.
Cart lines Quantities that are numeric and positive, a supplier part number, a description, a unit of measure, and Money elements that actually carry a currency attribute.
The things buyers reject on Missing UNSPSC classification, units written as "each" rather than EA, and totals that do not match the sum of the lines — the three that cause a cart to arrive but price wrongly.

About this tool

Is the document I paste sent anywhere?

No. Validation runs entirely in your browser using its built-in XML parser. There is no form on the page and the validator issues no network request, so the document is never transmitted or stored. The clearest way to confirm it is to disconnect from the internet once the page has loaded — the tool carries on working. Note that the site loads page analytics like any other, so the network tab will show those; your document is not in them.

Should I redact the shared secret first?

It is never a bad habit. The tool checks that a SharedSecret element is present and non-empty, not what it contains, so replacing the value with anything non-blank gives you the same result.

What can it check, and what can it not?

It checks structure: well-formedness, the elements and attributes cXML requires, whether a PunchOutOrderMessage sits in the right wrapper, whether money carries a currency, whether units and classifications are present and plausible. It cannot tell you whether your buyer will accept the document — their system may impose requirements beyond the specification, and many do.

Does it validate against the official cXML DTD?

Not literally. Browsers do not perform DTD validation, so this applies the structural rules the DTD encodes, in a form that produces a readable explanation rather than a parser error. For a formal DTD check, validate against the schema published at cxml.org.

It says my document is valid but my buyer still rejects it. Why?

Almost always a buyer-specific rule rather than a protocol one — a mandatory Extrinsic field, a UNSPSC revision they pin, a unit of measure their system does not accept, or credentials that are structurally fine but not the ones they configured. Those are agreed with the buyer, not defined by cXML.

Rather not debug this yourself?

We build and maintain the endpoint, and deal with the buyer's technical team directly. Pricing is published in full.

See pricing Send us the requirement