A PunchOut gateway is an intermediary that sits between buyers and suppliers so that each side builds and maintains one connection instead of one per counterparty.
To see why that matters, you have to look at the arithmetic of direct connections, because it is worse than most people expect.
The N by M problem
A PunchOut connection is bilateral. Buyer and supplier exchange credentials, agree endpoints, align on unit of measure and classification conventions, run a test cycle, and then maintain that configuration indefinitely. The mechanics are covered in what is PunchOut.
Crucially, none of it is reusable. A supplier who has connected to one buyer has not made the second connection easier. Different credentials, different endpoint, different field expectations, another test cycle.
So for N buyers and M suppliers wanting to trade with each other, the number of connections is N times M. Fifty buyers and two hundred suppliers is ten thousand connections, each individually built and individually maintained. Nobody builds ten thousand connections. What actually happens is that the largest buyers connect to the largest suppliers, perhaps a few hundred connections in total, and everyone else transacts by email and PDF.
The suppliers this strands are not marginal. In sectors with fragmented operational supply bases, they carry the majority of transactions by count even when they carry a minority of spend by value.
What a gateway changes
A gateway replaces the N times M mesh with N plus M connections. Each buyer connects once, to the gateway. Each supplier connects once, to the gateway. The gateway brokers everything in between.
Fifty buyers and two hundred suppliers becomes two hundred and fifty connections instead of ten thousand. More importantly, the marginal cost of the next supplier stops depending on how many buyers they want to reach.
This is not a novel idea. It is the same reasoning that produced payment networks, EDI value-added networks, and PEPPOL’s four-corner model. The pattern recurs because the arithmetic is the same every time.
What a gateway actually has to do
Sitting in the middle is more than proxying traffic. A working gateway handles at least five things.
Protocol translation. Buyers are not uniform. Some speak cXML, SAP-based estates commonly use OCI, and older integrations run on EDI. A supplier who has implemented one should not need to implement the others. The gateway accepts what the supplier can produce and emits what each buyer expects. The protocol layer itself is covered in what is cXML.
Credential and session brokering. Each buyer relationship has its own identity domains and shared secrets. The gateway holds those, authenticates incoming setup requests, opens the supplier session, and ensures the returning cart carries the right BuyerCookie back to the right buyer. Getting this wrong is not a cosmetic failure: it means a cart returning to the wrong requisition.
Content structuring for suppliers who cannot do it themselves. This is the part that decides whether a gateway reaches the long tail or just makes life easier for suppliers who were already capable. A supplier with a spreadsheet and no developers should be able to participate. That means ingesting CSV, SFTP drops, or API feeds and doing the catalogue structuring, classification and normalisation centrally, as discussed in catalog management.
Field-level normalisation. Units of measure, currency, tax treatment and classification codes have to be reconciled between what the supplier sends and what each buyer expects. Unit of measure in particular is where unmanaged connections produce expensive errors, and a gateway is the natural place to enforce consistency once rather than per pair.
Isolation and data governance. A gateway holds commercially sensitive contract pricing for many parties at once. Supplier A’s pricing to Buyer B must not be visible to Buyer C. In European deployments this is a GDPR question as much as a commercial confidentiality one, and it is an architectural requirement rather than a policy statement.
Gateways compared to supplier networks
The obvious comparison is to supplier networks such as the Ariba Network or Coupa’s supplier portal. They solve a related problem and are worth distinguishing.
A supplier network is typically tied to one procurement platform. Suppliers join it to reach buyers on that platform, which is genuinely useful if a supplier’s buyers are concentrated there, and less so otherwise. Networks have also historically charged suppliers for participation, sometimes on transaction volume, which pushes smaller suppliers out of exactly the segment that most needs the connectivity.
A gateway is platform-neutral by design. Its value proposition is reaching buyers across different procurement platforms through one integration, rather than reaching buyers on one platform well.
Neither model is universally correct. A supplier whose customers are all on one platform is well served by that platform’s network. A supplier selling into a fragmented buyer base, or a group purchasing organisation that has to deliver the same catalogue content into many different member systems, is not.
Where this leaves the long tail
The reason to care about any of this is the segment that direct connections never reach.
The pattern in most estates is stable and unsatisfying: a small number of strategic suppliers are properly integrated, and everything else runs on free-text requisitions, emailed PDF orders, and manually keyed invoices. Every downstream control degrades as a result, from spend classification to invoice matching, as traced in what is three-way matching.
That outcome is not a failure of intent. It is the direct consequence of per-connection effort staying constant while per-connection value falls as you move down the spend curve. Changing the outcome requires changing the arithmetic, not trying harder within it.
This is the problem BoreaTech is building toward. SupplierForge today is a supplier catalog management platform for group purchasing organisations and procurement teams, ingesting supplier content through CSV, API, SFTP and EDI and integrating with existing P2P systems, with per-tenant isolation so each client’s data sits in a dedicated environment. The PunchOut Gateway described in this article is the next layer, currently in development: universal cXML, OCI and EDI translation so that a supplier integrates once and becomes reachable from any P2P platform, in any direction.
We write about it now because the pattern is worth understanding on its own terms, whether or not you end up using ours.