Punchout

A punchout is a session that hands a user out of their own software and into a supplier's catalog, under the buyer's account, then returns the finished cart to the document they started from. The buyer never leaves their workflow. The supplier never has to publish their pricing anywhere.

How does a punchout session work?

Four moves. The buying system sends a signed request to the supplier and gets back a session URL. The user lands in the supplier's catalog already logged in as their company. They search, pick and build a cart. When they check out, the cart comes back to the buying system as structured lines with part numbers and prices attached.

Nothing is typed twice, and that is most of the value. A part number keyed by hand into a second system is one transposed digit away from a wrong part on a truck, which is a much more expensive problem than a slow afternoon.

Why does a punchout exist at all?

Because catalog data and price data live in different places. The supplier's catalog is enormous, changes constantly and depends on the vehicle, so copying it into every buyer's system is a losing job. Account pricing makes it worse, since the number the buyer sees is a function of their own program and volume.

The handoff solves both at once. The supplier keeps the catalog and the pricing rules on their side of the line, and the buyer gets their own numbers without a spreadsheet passing between two companies every month. The standard behind it comes from cXML, whose documentation describes application integration "including the widely-used PunchOut feature".

What comes back from a punchout?

Line items, at minimum a part number, a description, a quantity and a price. Better implementations return brand, availability, a core deposit and an internal identifier the supplier can match to the order later. Those extra fields are what let the receiving system attach the parts to a job instead of dumping them in a list, and the brand field is only as wide as the supplier's line card.

What does not come back is a commitment. The cart is a quote taken at a moment, and stock moves. A cart built at nine and submitted at two can find the part gone, so the transaction that counts is the purchase order somebody submits afterward.

Where do punchouts break?

Sessions, mostly. The handoff carries credentials and a clock, and a cart left open too long dies quietly. When the return leg fails, the symptom is a cart that seems to submit and never arrives, and the fix is a question for whoever set the integration up, because nobody at the counter can change how the handoff is configured.

The other failure is silent price drift. A session that starts without the right account attached returns list pricing that looks plausible on the screen and destroys parts margin on the ticket. Put a spot-check on somebody's list: one familiar part number against a cost you already know, on a schedule that has a name attached to it.

What does punchout change on a repair order?

It removes the retyping between the catalog and the estimate. Parts land on the repair order with the numbers the supplier quoted, so the price on the estimate is the price the shop will pay, and the part number on the line is the one that will show up in the box.

That matters most on long parts lists. A cooling or driveline job on a diesel can carry a dozen small items behind the two everybody talks about, and each one is a chance to key a digit wrong when somebody moves it by hand. It also gives the counter something to say when a customer asks why a part costs what it costs, since the line carries a supplier and a date instead of a number somebody remembered.

The limits are worth stating out loud to whoever uses it. A returned cart is a quote and stock is a snapshot. Neither one becomes an order until a purchase order goes in and the supplier accepts it.

Back to the glossary, or read about how an estimate gets priced.