In this guide 6 sections
A punchout catalogue lets a buyer shop your range inside its own procurement system. EDI exchanges purchase orders, acknowledgements and invoices as structured files. A portal is your own ordering site. Choose by what the buyer demands, how often it orders and how clean your catalogue already is.
What each route actually is
With punchout, a buyer’s staff click a supplier link inside a system such as Coupa or SAP Ariba, where their approver already sees the budget. Your catalogue opens in a session. The filled cart returns to their system as a requisition. Common formats are cXML and OCI.
EDI has no browsing at all. A purchase order arrives as a structured file, in X12 or EDIFACT, and you send back an acknowledgement, then a ship notice, then an invoice. Machines talk to machines.
A portal is yours. Buyers log in to your site, see their own price list, download last month’s invoices and reorder from any past order without calling anyone. Their staff leave their own system.
What punchout asks of your catalogue
Punchout shows your range inside a stranger’s system. Every field must be clean. A missing unit of measure or a vague description makes the requisition fail approval, and the buyer’s purchasing team will blame the supplier, not their own system. Contract prices must follow the logged-in account.
Plan for the return trip as well. The cart goes back carrying codes that the buyer’s finance team expects, and a wrong category code can send the order to the wrong approver. Nobody tells you. The order just stalls.
Test the session before you offer it. Ask the buyer’s procurement team for a sandbox, send three items back and compare every total, tax line and delivery address with what left your server. Mismatches are cheap to fix now. They are expensive after go-live.
- Supplier part number and the buyer’s own item reference
- Unit of measure that matches the buyer’s system
- Account-level contract price on every line
- Commodity or UNSPSC code per item
- Lead time shown before the cart is returned
What EDI asks of your order flow
EDI is about discipline. Each buyer has trading partner identifiers, ship-to codes and a deadline for the acknowledgement, and a late one can be logged against you in the buyer’s supplier scorecard. An unread document is a missed order.
Every buyer needs a mapping and a test cycle. The map tells your system which field holds the quantity, which holds the delivery address and which holds the buyer’s line number for matching the invoice. Testing takes weeks. Watch the first live orders closely.
The usual failure is a mismatch of units. The buyer orders in cases. You invoice by the each. The invoice bounces.
When a portal is the better answer
Many buyers have no procurement system at all. A small kitchen chain or a school laboratory may only want a login, and for them a portal is faster than any integration project.
Portals also suit repeat buyers who order the same forty lines every week, because saved lists, quick reorder and invoice downloads matter more to them than a protocol.
Many suppliers run a portal as the fallback. Buyers who adopt punchout later can move across, and their order history, saved lists and contract prices go with them, so nothing is rebuilt from scratch.
- Buyers without a procurement system
- Standing lists reordered every week
- Statements and invoice downloads in one place
- Approvals handled by your own role rules
Ask the buyer three questions before you quote
Ask which route they require. Ask which documents they expect. Ask who builds the connection and who pays for it. Ask when they want the first test order.
The answers decide the scope. Setting up a portal login costs days. A buyer who needs EDI with a ship notice and a matched invoice costs you weeks of mapping and testing.
Write the three answers on one page per buyer. Then list the catalogue fields still missing. Fix those first.
Buyer route worksheet
Each institutional buyer gets a line on this single page, filled across seven columns: buyer, procurement system, route requested, documents needed, catalogue fields missing, test order date and owner. A short block underneath lists the three questions to ask a new buyer and leaves space to record who pays for the connection.
Open a blank worksheet to printQuestions owners ask
Is punchout the same as EDI?
No. Punchout is a shopping session inside the buyer’s system. EDI is paperwork without shopping. Some buyers use both, one to browse and one to send the final order once the cart has been approved.
Can one portal serve buyers who want punchout later?
Yes, if the catalogue is organised by account. The portal then becomes the base that a punchout session reads from, so account prices and part numbers are reused and nothing is typed twice.
How long does a first EDI connection take?
It depends on the buyer’s testing queue more than on your code. Expect several rounds of sample documents and corrections before live orders flow. Ask the buyer for their test schedule at the start.
Who normally pays for the connection?
It varies, and it is worth settling early. Some buyers supply the tooling and expect you to follow their specification to the letter, whatever your own system does by default. Others expect the supplier to bear the cost. Put it in writing.