The request almost never arrives as a technology project. It arrives as a sentence from one of your largest accounts: we’re consolidating purchasing in Coupa, and we need you available inside it before we move more spend your way.

That’s a good problem to have, and the answer is almost always yes. Punchout is how you stay in front of the buyers whose own process routes them away from your website, and for most distributors those are the largest accounts they have. It’s worth doing.

It’s also bigger than it sounds, and most of what you’ll find while researching it was written by companies whose business model depends on the answer being “this is quick.” Most distributors have punchout somewhere in the plan by now. What tends to be missing isn’t awareness. It’s that punchout got budgeted as a line item when it behaves like a program.

I build the integration layer underneath this for industrial distributors. Here’s what it takes to do it well.

What does punchout for distributors actually require on your side?

A session handoff, a shopping experience, and a cart return. That’s the whole shape of it.

In practice: a buyer sitting in Coupa, Ariba, or Jaggaer clicks your name in their supplier list. Their system authenticates to yours and hands off the session. Your catalog opens inside their procurement window. They shop, they build a cart, and instead of checking out, they transfer the cart. It returns to their system as a requisition and runs through their approval chain. If it clears, a purchase order comes to you.

Your customers on Coupa, Ariba, and Jaggaer will be on cXML. SAP ERP shops will ask about OCI. The protocol distinction matters far less than the internet suggests, and it isn’t where projects go long.

That’s the mechanism. What it requires on your side is everything the rest of this post is about: a shoppable catalog you probably already own, a handoff layer you don’t, contract prices that survive the trip intact, and a separately scoped project for every enterprise customer you connect.

One account, several ways to buy, and not all of them their choice

Omnichannel in B2B usually gets described as a consistency problem, making sure price and availability and account history look the same everywhere. That’s part of it. The harder part is that a single account moves between channels for reasons that stack on top of each other, and only some of those reasons are anyone’s choice.

At least three things are pushing on any given order at the same time:

What’s driving the purchase. A truck is down and the crew needs a fitting today. Or a project kicks off in six weeks and someone is releasing material against a bill of materials. Urgency and planning horizon change which channel is even usable.

Who’s placing it and how they prefer to work. Some buyers text your rep. Some call the desk because they want a human to confirm it. Some live in the app. Some drive to the branch because they’ve always driven to the branch. This is personal, it varies within the same company, and in my experience it predicts channel better than anything else about the account.

What the company requires. Approval thresholds, approved supplier lists, EDI for replenishment, punchout for everything routed through procurement. This governs the path the order takes to become an order.

These aren’t buckets you can sort orders into. They layer. A punchout requisition placed under corporate policy can still be picked up at the branch by the same person who would have walked in anyway, provided your setup carries a branch-pickup fulfillment method through from the requisition. Policy usually dictates the transaction mechanism, not the fulfillment path, and the buyer’s own preferences keep operating inside whatever the policy allows.

The distinction that matters commercially is elasticity.

The first two are elastic. Better inventory, a rep who answers, an app that doesn’t fight the user, real will-call, and you earn more of the order. Effort produces a return.

That isn’t just an assertion. On the Zebra engagement, we successfully onboarded 14,000+ customer accounts and drastically reduced reliance on fax and phone orders. That was self-service ordering rather than punchout, so it isn’t proof of the policy half of this argument. It is what the elastic half looks like when a distributor actually invests in it.

Policy isn’t elastic. Under it you’re either eligible or you aren’t. A buyer who would rather buy from you still can’t, if you’re not in their procurement system, because their own approval workflow won’t pass the requisition. Meanwhile a competitor with a thinner catalog and a worse counter gets the spend by default, because they’re in there and you’re not.

So, when a customer says “we need you in Coupa,” they aren’t asking for a feature. They’re telling you the terms of eligibility just changed for that account.

Do you need a commerce platform to do this?

You need something that renders a shoppable catalog, because the middle of the punchout sequence is a real storefront experience with search, product data, and a cart. For most distributors that’s the commerce platform they already own. But “we have commerce, so we’re covered” is wrong in both directions, and it’s worth being clear about which parts your platform actually contributes.

Your platform gives you the shopping. Search, faceting, product content, cart, and if you’re running a B2B-capable platform, company accounts and price lists that make customer-specific views possible in the first place. That’s the expensive part to build from scratch, which is why punchout usually gets built on top of commerce rather than beside it.

Your platform does not give you the handoff, the authentication mapping to each buyer organization, the cart serialization back into their system, the contract price truth (that’s almost always your ERP), or the purchase order and invoice round-trip. None of the major platforms ship punchout in the box. Not Adobe Commerce or ACCS. Not BigCommerce. Not commercetools. Not Shopify. That isn’t a knock on any of them. Punchout was never a storefront feature. It’s a handoff between two systems, living in a layer no product roadmap has wanted to own.

Which brings up the fork most distributors don’t know exists.

Punchout isn’t the only way to be inside a buyer’s procurement system. The other option is a hosted catalog, where you send a formatted catalog file that loads directly into their system and your items become searchable there with no session at all. If the contracted assortment for that customer is a few hundred stable SKUs at fixed contract prices, a hosted catalog can satisfy the ask without a punchout project. Punchout earns its cost when the catalog is large, configurable, or priced dynamically enough that a static file goes stale, which, for most industrial and MRO distributors, it is. But it’s a question worth asking before you scope, because the answer is occasionally no.

One more thing your platform doesn’t do: hide. Punchout puts your storefront in front of the most scrutinized audience you have, inside a tool they use all day, with your competitors one click away in the same supplier list. It doesn’t rescue a weak B2B site. It exhibits one.

Priced per trading partner

Give your CFO this in one sentence: punchout isn’t a feature you buy once.

Every enterprise customer you connect is its own scoped effort. Their instance, their contracted catalog view, their item numbers, their approval rules, their test window. Connection two costs less than connection one because the plumbing exists. It still isn’t free, and it never becomes a toggle you flip for the next account.

If punchout came up during your platform selection or replatform evaluation and nobody scoped it as separate work, it isn’t in your number. And when you say yes to this customer, plan for the accounts standing behind them, because there will be more.

The cost line that isn’t in anyone’s project plan

Some buyer networks charge the supplier to transact on them, and that cost sits entirely outside your implementation budget.

Coupa doesn’t. There’s no fee to join their network or to process transactions through it, so a Coupa connection costs you your own work and nothing else.

SAP Business Network is the one to model. Suppliers start free, and the account becomes chargeable once you cross two thresholds with a single buyer inside a rolling twelve months: five qualifying documents and $50,000 in transacted volume. Cross both with one customer and you’re chargeable across every buyer relationship you have on that network, not just the one that tripped it.

From there it’s an annual subscription plus a transaction fee, and the mechanics of both are worth knowing before you sign anything. The subscription level is set by taking your last three months of document count and multiplying it by four, so it’s a trailing quarter annualized rather than a prior-year total. One busy quarter can set your level for the following year. The transaction fee runs 0.155% of qualifying transacted volume, or 0.35% on relationships where service entry sheets are in active use, and it’s capped at $20,000 per buyer relationship per year. (Figures as of 2026, from SAP’s supplier pricing. Check them before you build a model on them.)

The implication for a distributor is worth sitting with. Your first large SAP account can move you into a fee tier that then applies to every other SAP buyer you serve. That isn’t a reason to say no. The cap is what makes it a modelable number rather than an open-ended percentage, and a modelable number belongs in the account’s margin math rather than meeting you on an invoice.

Where these projects slip

Rarely the connector. Usually one of these:

Unit of measure and pack quantity. Their item master says “each.” You sell by the case of twelve. The cart returns a quantity that means one thing on your side and something different on theirs. This is mundane, and it’s the most common source of the variance problem below.

Part number cross-reference. Their internal item ID against your SKU, mapped and maintained by someone, indefinitely.

Customer-specific catalog scoping. Enterprise buyers don’t want your full catalog, they want the contracted subset. Building that subset per customer and keeping it accurate as items change is recurring work that usually lands on a person who didn’t know it was coming.

Real-time price calls under session latency. The prices they see may each require a live call to your ERP, and that call now sits inside a session a procurement user is watching. Response times you tolerate on your own site aren’t tolerable here.

Tax and freight in the cart return. Frequently can’t be returned cleanly, which becomes another variance the buyer has to reconcile.

Testing against the buyer’s live instance. Not a sandbox. Their actual configuration, on their calendar, with their team. You don’t control that schedule.

Purchase order and invoice round-trip. Returning the cart is half the job. The PO and the invoice have to land correctly on their side too, or your AR team inherits the problem.

The one that puts supplier relationships under review

The price shown inside the punchout session has to equal the price on the invoice.

When it doesn’t, the variance surfaces in a procurement audit, and a variance in an audit doesn’t read as a software bug. It reads as a supplier billing incorrectly. That conversation happens with the people who decide how much spend you get next year.

Which is why punchout isn’t really a punchout question. It’s a contract-pricing architecture question wearing different clothes. If your contracted prices are calculated one way for your website and a different way for your invoicing, punchout is the thing that exposes it.

What to ask before you sign

The section above is what breaks. This is what to negotiate. Put these to any vendor or partner quoting the work, and on each one ask the same two questions: whose number is this in, and who owns it after go-live?

The session handoff. The one item every quote covers well. Ask what the second buyer organization costs, and the fifth, because that rate is the real shape of your program budget and it rarely appears in a first proposal.

Catalog scoping per buyer organization. Not “can you build it.” Ask who maintains it after go-live, on what cadence, and whether that is a one-time project cost or a permanent claim on someone’s week on your side. Get the name of the person, not the function.

Item and unit-of-measure mapping to the buyer’s item master. Ask who does the initial mapping and, separately, who owns it when the buyer changes their item master. The second one is almost always assumed to be yours and almost never said out loud.

Real-time contract pricing under session latency. Ask for a response-time target the vendor will put in writing, and ask what happens to scope and price if your ERP can’t hit it. If nobody will name a number, that risk has quietly become yours.

Testing against the customer’s live instance, on their calendar. Ask how many test cycles are in the quote and what the next one costs. You don’t control that schedule, so establish now who absorbs the delay when the buyer’s team goes quiet for three weeks.

Purchase order and invoice round-trip back into their stack. Ask whether this is inside the punchout scope at all. Often it is a separate integration, quoted later, sometimes by a different party, and discovering that in month three is how a program loses a quarter.

Supplier network fees, and which of your accounts would trigger them. This one isn’t a vendor line at all. It’s yours, it sits outside the implementation budget entirely, and it belongs in the account’s margin math before you sign rather than in a surprise invoice after.

Most quotes cover the first one well. That’s the honest reason these projects run past their estimates. The estimate was accurate about its own scope. The scope was one item of seven.

None of this argues against punchout. When a customer tells you they need you in Coupa, they’re telling you where their spend is going, and that’s worth having. Just don’t budget for it as a switch.

If you’re being asked for this right now, the useful next step is a scoping conversation about what the connection actually has to do on your side. Talk to our B2B commerce team and we’ll walk these questions against your ERP and your pricing setup.

Punchout Puts You Where Your Largest Customers Already Buy