A Customer Asked for EDI, cXML, or PunchOut. Start With This Checklist.

Start by identifying the exact exchange

The buyer is describing how its purchasing process exchanges catalogs, orders, shipping information, or invoices. Before choosing a product or estimating the work, identify the exact transactions, the systems on both sides, the test process, and the people who accept the result.

The terms describe different jobs

An onboarding request may use several of these terms. Each one describes a different part of the job.

Supplier onboarding checklist

Collect these items before scoping the work.

• Buyer or procurement-platform contact.
• Requested documents, messages, or PunchOut sessions.
• Implementation guide and version.
• Required fields, account identifiers, item identifiers, and units.
• The supplier system that receives or creates each business record.
• Redacted sample documents and test cases.
• Test environment and connection instructions.
• Validation and rejection rules.
• Target date and any date when the old process stops.
• The person on each side who accepts the result.

Questions to take back to procurement

These answers separate launch requirements from later phases and expose missing decisions before testing starts.

• Which transactions are required for launch, and which are optional or planned later?
• What implementation guide and version control the exchange?
• Who provides test accounts, endpoints, and sample documents?
• What counts as a passed test, and who signs off?
• How should unknown items, price differences, duplicates, invalid addresses, and rejected documents be handled?
• Does the supplier need to send acknowledgments, shipping notices, or invoices after receiving the order?
• When will the buyer stop accepting the old ordering method?

Test and accept one document at a time

Compare the buyer’s requirements with the supplier’s current systems. Define the included transactions, fields, owners, and exceptions, then map and test each document separately.

For a purchase order, test valid orders plus unknown items, price or unit differences, duplicate orders, invalid addresses, and unavailable downstream systems. For an acknowledgment, shipping notice, or invoice, test its own required fields, rejection path, and acceptance response. Record who accepted each transaction and keep a manual fallback for failures.

A PunchOut catalog test establishes the session and cart return. It does not establish that the later order, acknowledgment, shipping notice, or invoice exchanges work. Those documents need their own test evidence.

Prepare for a useful first review

Bring the onboarding packet, redacted samples, the required dates, and the names of the systems that handle orders, inventory, shipping, and invoices. The first review should identify the transactions, owners, tests, exceptions, and likely connection method.

Do not submit credentials, certificates, secrets, or customer data through a public form. Share access details through an approved private method after the parties decide to proceed.

Official sources

The PunchOut sequence above follows the official cXML Reference Guide and the shorter cXML PunchOut session FAQ.