Hoe punchout werkt

Ergens in je inbox zit een bericht van je grootste klant dat ongeveer zo klinkt: “Onze inkoopafdeling vraagt of jullie punchout-catalogi ondersteunen. Hebben jullie een cXML-endpoint?” Draai je een B2B-shop op Shopify en klinkt die zin als een vreemde taal, dan is dit de lange versie van het antwoord. Wat punchout echt is, de volledige roundtrip stap voor stap, het verschil tussen cXML en OCI, wat Shopify al kan, wat de inkoopkant van je gaat vragen, en waar een connector past.

Wat punchout is

Punchout is hoe grote bedrijven bij leveranciers inkopen zonder hun eigen inkoopsoftware te verlaten. Je klant surft niet over het open web. Hij werkt in een inkoopsysteem: Ariba, Coupa, Jaggaer, Oracle, Workday of een SAP-omgeving. Heeft hij jouw producten nodig, dan klikt hij jouw naam aan in dat systeem. Je catalogus opent in een venster, hij vult een winkelwagen, en die winkelwagen reist terug zijn systeem in als bestelaanvraag. Hij voert de winkelwagen niet opnieuw in en betaalt niet in je webshop. De inkooporder komt later, via een eigen kanaal.

Al dat ceremonieel bestaat om één reden: controle. Inkoopteams worden betaald om goedkeuringsketens, budgetten en onderhandelde prijzen op elke order af te dwingen. Een publieke webshop dwingt daar niets van af, dus vouwt hun software zich om de jouwe heen: winkelen gebeurt bij jou, bestellen bij hen.

Voor jou als leverancier is punchout het verschil tussen een voorkeursleverancier op papier en in de praktijk. Betekent bij jou bestellen: het systeem verlaten, artikelnummers overtypen en een PDF bijvoegen, dan schuiven inkopers op naar de concurrent die wél aangesloten is. Staat je catalogus één klik verderop, tegen contractprijzen, dan is bij jou blijven de weg van de minste weerstand.

De roundtrip, stap voor stap

Een punchout-relatie heeft twee helften: het winkelen heen, en de inkooporder terug. Zes stappen maken de cirkel rond.

cXML versus OCI

Twee protocollen dragen vrijwel al het punchout-verkeer. Welke jij nodig hebt, bepalen je klanten.

cXML (Commerce XML) is de standaard van de Ariba-wereld en qua verspreiding de grootste. Het is documentgebaseerd: vier XML-documenttypen vormen een complete cyclus (PunchOutSetupRequest, PunchOutSetupResponse, PunchOutOrderMessage, OrderRequest). Coupa, Jaggaer, Oracle en Workday spreken het ook. De kracht zit in de terugweg: inkooporders reizen over hetzelfde protocol, dus beide richtingen lopen als gestructureerde documenten. Nederlandse inkooporganisaties draaien overwegend op deze cXML-netwerken; zie Ariba en Coupa voor de details per netwerk.

OCI (Open Catalog Interface) is SAP's oudere, bewust simpele standaard, dominant in Duitstalig Europa en overal waar SAP SRM of S/4HANA de inkoop doet. Geen XML-documenten op de heenweg: het ERP roept je catalogus-URL aan met een HOOK_URL-parameter, en de winkelwagen komt terug als geïndexeerde NEW_ITEM-velden. OCI verplaatst winkelwagens, geen inkooporders; de PO komt terug via het kanaal dat het ERP aankan. De praktische complexiteit zit in velddialecten per installatie. Details op de OCI-pagina.

Voor de Nederlandse praktijk: de meeste inkooporganisaties hier draaien op de cXML-netwerken, met Coupa en Ariba voorop. OCI kom je vooral tegen bij dochterbedrijven van Duitse concerns en bij industriële klanten die hun inkoop in SAP hebben zitten. Lever je aan beide groepen, en veel Nederlandse groothandels doen dat, dan heb je uiteindelijk beide protocollen nodig: één klant op zelfgehost SAP, de volgende op Ariba of Coupa. Dat is het argument om beide protocollen in één connector te doen in plaats van in twee projecten. Een praktische vergelijking lees je in onze gids cXML vs. OCI in de praktijk.

Wat Shopify meebrengt, en wat niet

Eerst het goede nieuws. Shopify B2B dekt de commerciële helft van de punchout-checklist al af, de helft die achteraf echt lastig in te bouwen is: bedrijfsaccounts met meerdere company locations, catalogi en prijslijsten per location (dat zijn je contractprijzen), hoeveelheidsregels zoals minima en verpakkingseenheden, betaaltermijnen. Verkoop je vandaag groothandel via Shopify, dan staat het prijs- en rechtenmodel dat punchout-klanten eisen er waarschijnlijk al.

Wat Shopify op geen enkel plan heeft, is een punchout-endpoint. Niets ontvangt een PunchOutSetupRequest, niets valideert een shared secret, niets rendert NEW_ITEM-velden naar een HOOK_URL, niets verwerkt een OrderRequest. Shopify's B2B-functies stoppen aan de rand van je shop; punchout is precies de machinerie die over die rand het systeem van je klant in reikt.

Dat gat vult een connector: de protocol-endpoints, de credential-validatie, de sessie die een netwerkidentiteit aan de juiste company location koppelt, de winkelwagen-transformatie heen, de order-verwerking terug, en de logs die alles controleerbaar maken. Let bij het kiezen vooral op dat laatste: zonder ruwe logs van beide richtingen ben je bij elke storing afhankelijk van de supportafdeling van je leverancier, en die van je klant.

Wat inkoopnetwerken van leveranciers vragen

Het protocol is de snelle helft van een punchout-project. De trage helft is enablement: het proces dat elk netwerk of elke klant doorloopt voordat je koppeling live gaat. Ken het voordat je een livegang belooft.

Ariba is het zwaargewicht. Trading relationship op SAP Business Network, identiteiten en shared secret uitwisselen, catalogus-indexbestand per klant laten valideren, testen in het test realm van de klant. Punchout vraagt in de praktijk een Enterprise-account, en Ariba is het enige grote netwerk met leverancierskosten: 0,155% transactiefee, gemaximeerd op 20.000 USD per klantrelatie per jaar boven de drempels, plus abonnementstiers waarbij cXML-automatisering je in Silver plaatst, 750 USD per jaar. Echte inkoopdocumentatie noemt 8 tot 12 weken doorlooptijd, vrijwel allemaal coördinatie.

Coupa is het lichtgewicht: portal gratis, geen leverancierskosten, en de admin van je klant configureert de koppeling zelf. Eerste koppelingen landen doorgaans binnen een week of twee. Dat maakt een Coupa-klant het ideale eerste punchout-project. Jaggaer, Oracle en Workday zitten ertussenin: cXML-gebaseerd, zonder leverancierskosten, met enablement op het tempo van het projectteam van de klant.

Overal hetzelfde patroon: de engineering-uren zijn klein, de coördinatieweken niet. De hendel die jij vasthoudt is hoe snel elke testronde sluit. Ruwe sessielogs die de IT van je klant zonder overleg kan lezen, zijn daarvoor het beste gereedschap.

Twee dingen kun je nu al voorbereiden in je eigen catalogus, nog voordat het eerste enablement start. Eén: stabiele SKU's op elke variant die via punchout verkocht wordt. cXML identificeert artikelen met de SupplierPartID, en wat je daar één keer verstuurt, staat blijvend in het artikelbestand van je klant. Een kale variant-ID uit het shopsysteem wil je daar niet vereeuwigd zien. Twee: een mapping voor eenheden. Inkoopsystemen verwachten ISO-eenheden zoals EA, BX of CS op elke regel, en Shopify kent dat concept simpelweg niet. Beide zijn in een uur geregeld en besparen je de twee klassieke vragenrondes waarmee bijna elk enablement anders begint.

Waar PunchRelay past

cXML-inkooporders worden duurzaam opgeslagen, vergeleken met de teruggestuurde winkelwagen en in de inbox ‘Purchase orders’ van de PunchRelay-app gezet. In Shopify ontstaat niets tot iemand van je team de PO controleert en op ‘Create Shopify order’ klikt. Dan wordt de order onbetaald aangemaakt, met openstaande betaling, klaar om te verzenden. OCI verstuurt alleen de winkelwagen; de bestelroute wordt per klant apart afgesproken en getest.

We onboarden nu early-access-merchants en bouwen hun eerste koppelingen samen met ze. Vroeg een klant je net om punchout? Begin bij de pagina die bij zijn systeem past: Ariba, Coupa of OCI voor SAP. Of laat hieronder je e-mailadres achter, dan schetsen we de kortste route naar je eerste live koppeling.