Punchout-Kataloge und B2B-Beschaffungsintegration

Ein Spezialchemiehersteller im Rhein-Main-Gebiet schließt einen 3-Jahres-Liefervertrag mit einem Fortune-500-Industrieabnehmer ab. Der Vertrag ist 14 Mio. Dollar über die Laufzeit wert. Die Preise sind festgeschrieben. SLAs sind verhandelt. Die Beschaffung auf der Käuferseite ist zufrieden. Der Deal ist unterzeichnet.

Dann kommt die operative Anforderung, vergraben auf Seite 47 des Rahmenvertrags: „Alle Bestellaktivitäten unter diesem Vertrag müssen von der E-Procurement-Plattform des Käufers (Coupa) ausgehen. Der Lieferant stellt einen gehosteten Punchout-Katalog bereit und ist in der Lage, cXML-Bestellungen zu empfangen, cXML-Auftragsbestätigungen, Versandavise und Rechnungen zu übermitteln. Die Punchout-Integration ist spätestens zu Beginn von Q3 betriebsbereit.“

Der Sales VP leitet diesen Absatz mit einer einzeiligen Notiz an den IT-Direktor weiter: „Mach das zum Laufen.“

Der IT-Direktor hat das Wort „Punchout“ schon mal gehört — auf einer Messe, in einem Anbieterpitch, den er nicht ganz verstand. Er hat 90 Tage, keine interne Expertise und einen Vertrag, der stillschweigend von einer Integration abhängt, die sein Team nie gebaut hat.

Das ist eine häufigere Situation, als SaaS-Marketingtexte zugeben. Punchout ist keine Randanforderung. Es ist die Eintrittskarte, um an die meisten der Fortune 1000, große Krankenhausysteme, Bundes- und Landeskäufer und jede große industrielle Beschaffungsorganisation zu verkaufen, die sich auf Coupa, Ariba, SAP Concur, Jaggaer oder Oracle iProcurement standardisiert hat. Wenn Sie kein Punchout können, können Sie mit diesen Käufern nicht regelkonform Geschäfte machen. Sie werden Ihnen keine POs mailen. Sie werden ihre Anforderer nicht SKUs in ein Portal tippen lassen. Die Bestellung muss aus dem Beschaffungssystem heraus entstehen.

Dieser Artikel geht durch, was Punchout tatsächlich ist, die cXML- und EDI-Flüsse dahinter, was die Implementierung kostet, was schief geht, und — die Frage, die die meisten Anbieter nicht ehrlich beantworten — ob Sie es überhaupt unterstützen sollten.

Was Punchout tatsächlich ist, in einfachen Worten

Weg mit dem Jargon. Punchout ist ein Weg für einen Käufer, Ihren Katalog von innerhalb seines eigenen Beschaffungssystems zu durchstöbern und den resultierenden Warenkorb dann in seinen Beschaffungsworkflow zurückzubringen, um ihn zu genehmigen und eine Bestellung zu erzeugen.

Das Nutzererlebnis für den Anforderer des Käufers sieht so aus:

1. Der Anforderer meldet sich in der E-Procurement-Plattform seines Unternehmens an — Coupa, Ariba, SAP Concur, Jaggaer, Oracle iProcurement. Das ist das System, das er täglich nutzt, um Büromaterial, Laborreagenzien, MRO-Teile, IT-Ausrüstung zu beschaffen.
2. Er navigiert zu einer Liste genehmigter Lieferanten. Er klickt auf die Kachel Ihres Unternehmens.
3. Er wird lautlos zu Ihrem gehosteten Katalog umgeleitet (ein Webshop, den Sie pflegen, gebrandet wie ein normales E-Commerce-Erlebnis). Er ist bereits authentifiziert — er hat kein Passwort eingegeben.
4. Er stöbert, konfiguriert und fügt Produkte zu einem Warenkorb hinzu. Der Katalog zeigt seine vertraglich vereinbarten Preise, nicht Listenpreise, weil die Weiterleitung seine Account-Identität getragen hat.
5. Er klickt auf „Warenkorb übermitteln“ oder „Warenkorb zurückübertragen“.
6. Der Warenkorbinhalt wird an sein Beschaffungssystem zurückgepostet. Der Anforderer sieht seinen normalen Beschaffungsbildschirm, wobei der Warenkorb nun als Entwurfsanforderung erscheint.
7. Der interne Genehmigungs-Workflow des Käufers läuft. Manager genehmigt bis 5.000 Dollar. Abteilungsleiter genehmigt darüber. Finance genehmigt Investitionen. Das kann Stunden oder Tage dauern, und Sie haben keine Einsicht.
8. Nach der Genehmigung gibt das Beschaffungssystem eine elektronische Bestellung aus (cXML oder EDI 850), die in Ihrem Bestellmanagementsystem landet.
9. Sie bestätigen die Bestellung (cXML oder EDI 855). Sie versenden und posten ein ASN (cXML oder EDI 856). Sie stellen eine Rechnung (cXML oder EDI 810). Die Zahlung kommt als cXML PaymentRemittance oder EDI 820 zurück.

Von Anfang bis Ende hat kein Mensch auf der Käuferseite eine SKU in Ihr System getippt. Kein PO kam per E-Mail an. Kein CSR hat eine Bestellung erneut erfasst. Die Transaktion hat eine saubere, prüffeste Spur innerhalb des Beschaffungssystems des Käufers vom Warenkorb bis zur Zahlung.

Das ist der ganze Sinn.

Warum Enterprise-Käufer es verlangen

Beschaffungsteams in großen Organisationen haben die letzten 15 Jahre damit verbracht, Ausgaben auf E-Procurement-Plattformen zu konsolidieren, gerade um Maverick-Buying zu eliminieren — bei dem ein Manager einem Lieferanten außerhalb des Systems einen PO mailt, Finance keine Sicht hat und das Audit die Ausgaben nicht nachverfolgen kann. SOX-Compliance, interne Auditrichtlinien und Lieferantenvielfaltsberichte setzen alle voraus, dass jede Bestellung aus der Beschaffung stammt.

Ihr Ansprechpartner im Werk des Käufers, der Ihnen früher POs mailte, kann das nicht mehr tun. Seine Beschaffungsorganisation erlaubt es nicht. Wenn er es versucht, wird Finance die Rechnung ablehnen, wenn sie eintrifft, weil es keine passende Bestellung im System gibt.

Die praktische Konsequenz: Wenn Sie kein Punchout können, können Sie viele große Käufer nicht bedienen. Oder genauer: Sie können den Vertrag gewinnen — aber operativ wird das Beschaffungsteam des Käufers die Ausgaben an einen Wettbewerber routen, der Punchout kann, auch bei höherem Stückpreis. Der Vertrag wird zur Jagdlizenz, die Sie nicht nutzen können.

Das ist die Rechnung hinter dem Fortune-500-Liefervertrag, der Punchout bis Q3 fordert. Der Chemiehersteller hat den Vertrag über Preis und Qualität gewonnen. Er wird das Volumen durch operative Reibung verlieren, wenn Punchout nicht live geht.

Der cXML- und OCI-Fluss — was tatsächlich über die Leitung wandert

Das ist der Abschnitt, der in den meisten Anbietermarketingtexten vereinfacht wird. Das sollte er nicht. Wenn Sie eine IT- oder Digitalführungskraft sind, die Implementierungsoptionen evaluiert, müssen Sie das Protokoll gut genug verstehen, um intelligente Fragen zu stellen und zu erkennen, wann ein Anbieter blumig redet.

Es gibt zwei Punchout-Protokolle, denen Sie begegnen werden:

• cXML (commerce XML) — der moderne Standard, verwendet von Coupa, Ariba, SAP Ariba Network und den meisten Cloud-E-Procurement-Plattformen. XML-basiert, läuft über HTTPS POST.
• OCI (Open Catalog Interface) — der ältere SAP-Standard, noch verbreitet in On-Premise-SAP- und SRM-Umgebungen. Formularkodiert, einfacher, weniger ausdrucksstark.

Für cXML sieht der Fluss so aus:

Schritt 1. PunchOutSetupRequest. Das Beschaffungssystem des Käufers sendet ein XML-Dokument an eine von Ihnen veröffentlichte Setup-URL. Es enthält: Shared-Secret-Anmeldedaten (DUNS- oder Domain-Identifier plus Passwort), die Nutzeridentität des Käufers, eine Rückgabe-URL, auf die Sie den Nutzer später zurückleiten werden, und ein Käufer-Cookie, das Sie später zurückgeben müssen.

Schritt 2. PunchOutSetupResponse. Ihr System authentifiziert die Anfrage, erstellt eine Sitzung, die dem Nutzer des Käufers zugeordnet ist, und gibt eine XML-Antwort mit einer einmaligen Sitzungs-URL zurück. Das Beschaffungssystem des Käufers leitet den Browser des Nutzers lautlos zu dieser URL weiter.

Schritt 3. Der Käufer stöbert. Der Nutzer landet in Ihrem gehosteten Katalog, bereits authentifiziert, mit angewendeten accountspezifischen Preisen. Er stöbert, fügt Artikel hinzu, baut einen Warenkorb. Das ist normaler E-Commerce, nur dass der Katalog weiß, wer er ist, ohne Anmeldebildschirm.

Schritt 4. PunchOutOrderMessage. Wenn der Nutzer auf „Warenkorb übertragen“ klickt, erstellt Ihr System eine cXML PunchOutOrderMessage mit den Warenkorbpositionen (SKU, Beschreibung, Menge, Stückpreis, UNSPSC-Code, Harmonized-System-Code bei internationalen Sendungen). Ihr System postet dies an die Rückgabe-URL zurück, die das Beschaffungssystem ursprünglich bereitgestellt hatte. Der Browser des Nutzers wird zurück zu seinem Beschaffungssystem geleitet, das den Warenkorb nun als Entwurfsanforderung anzeigt.

Schritt 5. Genehmigung. Intern beim Käufer. Undurchsichtig für Sie. Kann Minuten, Stunden oder Tage dauern.

Schritt 6. cXML OrderRequest (oder EDI 850). Nach der Genehmigung gibt das Beschaffungssystem eine Bestellung aus. Dies kann als cXML über HTTPS POST kommen oder als EDI 850 über ein EDI-VAN (TrueCommerce, SPS Commerce, OpenText) oder AS2. Die Bestellung verweist auf Ihren Warenkorb und enthält die PO-Nummer des Käufers, Rechnungs- und Lieferadressen und etwaige Genehmigungsanmerkungen.

Schritt 7. cXML ConfirmationRequest (oder EDI 855). Sie bestätigen die Bestellung und bestätigen Positionen und zugesagte Versanddaten. Dies muss innerhalb des vom Käufer vorgegebenen SLA gesendet werden — oft 24 Stunden.

Schritt 8. cXML ShipNoticeRequest (oder EDI 856). Wenn die Bestellung versendet wird, übertragen Sie ein Advance Ship Notice mit Frachtführer, Tracking-Nummer und Mengen pro Position. Das ASN ist es, was die Warenannahme des Käufers dazu bringt, die eingehende Sendung zu erwarten.

Schritt 9. cXML InvoiceDetailRequest (oder EDI 810). Sie stellen eine Rechnung. Die Rechnungspositionen müssen den PO-Positionen exakt entsprechen. Wenn Sie 47 Einheiten gegen einen PO für 50 versenden, muss Ihre Rechnungsposition 47 mit einem Rückstandsverweis zeigen, nicht 50. Nichtübereinstimmungen erzeugen eine automatische Rechnungsablehnung im AP-System des Käufers.

Schritt 10. cXML PaymentRemittanceRequest (oder EDI 820). Zahlungsavis, typischerweise übertragen, wenn die AP des Käufers den Scheck schneidet oder den ACH einleitet.

Die cXML- und EDI-Dokumente sind inhaltlich gleichwertig. Die Unterschiede sind syntaktisch und operativ: cXML fährt über HTTPS zu Ihrem Endpunkt, EDI fährt durch ein VAN oder eine AS2-Verbindung. Die meisten großen Hersteller, die B2B verkaufen, unterstützen am Ende beides, weil einige Käufer cXML vorschreiben und einige — besonders große Einzelhändler und der Staat — EDI vorschreiben.

cXML vs EDI: Wann welches verwenden

Die meisten Coupa- und Ariba-Implementierungen verwenden cXML für das Punchout-Setup, die Order-Message, den PO, die Bestätigung, das ASN und die Rechnung. Die meisten deutschen Einzelhandelsketten (Metro, Edeka, Rewe) und öffentlichen Einkäufer werden EDI oder XRechnung verlangen, auch wenn ihre interne Beschaffung auf einer modernen Plattform läuft.

Wenn Ihr größter Kunde EDI 850/855/856/810/820 verlangt und Ihr zweiter Kunde cXML verlangt, betreiben Sie beides. Planen Sie dafür.

Implementierungspfade und was sie kosten

Es gibt drei realistische Wege, Punchout in einen B2B-Betrieb hinzuzufügen. Die richtige Antwort hängt von Ihrer Engineering-Kapazität, Ihrem Zeitplan und wie vielen Käuferintegrationen Sie unterstützen werden.

Pfad 1: Eigenbau. Sie schreiben die cXML-Handler, die Session-Verwaltung, das Katalog-Rendering, die PO-Bestätigungslogik, den ASN-Generator, die Rechnungsübertragung. Sie verwalten die Zertifikate, die IP-Zulassungslisten, die Testumgebungen bei Coupa und Ariba.

• Zeitplan: 6–12 Monate für eine erste Integration, 2–4 Wochen pro zusätzlichem Käufer, sobald die Plattform existiert.
• Kosten: 150K–400K Dollar, je nachdem, ob Sie vorhandene Engineering-Fähigkeit und einen vorhandenen B2B-Katalog haben. Dies sind vollkostenbelastete interne Kosten, keine Anbieterrechnung.
• Richtig, wenn: Sie ein starkes Engineering-Team haben, 20+ Käuferintegrationen über 5 Jahre erwarten und spezifische Kataloglogik haben (Konfiguratoren, regulierte Chemikalien, Chargenrückverfolgungs-Constraints), die Standardanbieter schlecht abwickeln.

Pfad 2: Punchout-Anbieter. Spezialisierte Middleware-Anbieter übernehmen die cXML- und EDI-Verrohrung in Ihrem Auftrag. Sie geben ihnen einen Produktfeed und Account-Preislogik; sie übernehmen die Protokollschicht, das Käufer-Onboarding, die Tests.

• Anbieter: TradeCentric (ehemals PunchOut2Go) ist der etablierteste. GraphiteConnect (jetzt Teil von Workday) ist stark auf Käuferseite. B2BGateway bedient EDI-lastige Umgebungen. Pepperi, SureDone und eine Handvoll weiterer besetzen angrenzende Nischen.
• Zeitplan: 2–6 Wochen für eine erste Integration nach Vertragsunterzeichnung. Nachfolgende Käuferintegrationen: Tage, nicht Wochen.
• Kosten: 25K–60K Dollar erstmalige Implementierung, plus 1K–3K Dollar/Monat laufend je nach Transaktionsvolumen und Anzahl der Käuferverbindungen.
• Richtig, wenn: Sie in 90 Tagen live sein müssen, Sie kein dediziertes B2B-Engineering-Team haben und Ihr Katalog einigermaßen standardmäßig ist.

Pfad 3: Eingebettet in Ihre B2B-Commerce-Plattform. BigCommerce B2B Edition, Adobe Commerce (Magento), OroCommerce, Salesforce Commerce Cloud B2B und Shopify Plus haben alle Punchout-Erweiterungen unterschiedlicher Reife.

• Kosten: in der Plattformlizenz enthalten oder als Erweiterung verfügbar (5K–20K Dollar).
• Zeitplan: Wochen, stark abhängig von der Reife der spezifischen Erweiterung und dem Käufersystem.
• Richtig, wenn: Sie bereits auf einer dieser Plattformen sind und die Käuferanforderungen mainstream Coupa oder Ariba sind. Achtung: Erweiterungen bewältigen oft den Happy Path, stolpern aber über Randfälle (Account-Hierarchien, Ship-to-Überschreibungen, komplexes Genehmigungsrouting auf der Käuferseite).

Für die meisten deutschen Hersteller, die sich ihrer ersten Punchout-Anforderung nähern, lautet die ehrliche Empfehlung Pfad 2. Verwenden Sie einen Anbieter wie TradeCentric. Versuchen Sie nicht, es intern zu bauen, es sei denn, Sie haben einen spezifischen Grund — und „wir wollen cXML lernen“ ist kein spezifischer Grund.

Die Auswirkungen für Ihren Gesamtstack sind bedenkenswert. Egal, ob Sie Ihr Bestellmanagement auf Ihrer eigenen Infrastruktur selbst hosten oder es als Managed Service betreiben, der Punchout-Anbieter sitzt vor Ihrem OMS und übersetzt Beschaffungsplattform-Protokolle in die Bestellungen, ASNs und Rechnungen, die Ihr OMS nativ abwickelt. Der Entscheidungsrahmen für die zugrundeliegende Plattform ist derselbe, der im Entscheidungsrahmen B2B-Portal vs E-Mail behandelt wird — Punchout ist eine Schicht über einem funktionierenden B2B-Fundament, kein Ersatz dafür. Viele Hersteller betreiben ihre Punchout-Integration neben einer selbst-gehosteten Bestellmanagement-Bereitstellung, in der die Back-Office-Workflows leben.

Was schief geht (und wie man es vermeidet)

Punchout-Fehler betreffen selten das Protokoll. Der cXML-Handshake ist gut dokumentiert und vorhersehbar. Die Fehler häufen sich an fünf anderen Stellen.

Katalogdatenqualität. In dem Moment, in dem Ihr Katalog einem Beschaffungssystem ausgesetzt wird, wird jede abgeschnittene Beschreibung, jede fehlende Herstellerteilenummer, jede mehrdeutige Mengeneinheit zu einem Käuferseiten-Ticket. Beschaffungssysteme taggen und klassifizieren Ihre Produkte gegen UNSPSC- und Harmonized-System-Codes; wenn Sie diese Codes nicht zugewiesen haben, lehnt das System des Käufers Ihre Artikel entweder ab oder steckt sie in eine generische „Verschiedenes“-Kategorie, die die Ausgabenanalytik des Käufers aushebelt. Budgetieren Sie Zeit, um Ihren Katalog aufzuräumen, bevor das Punchout live geht, nicht nachdem das Beschaffungsteam des Käufers sich beschwert.

UNSPSC- und HS-Code-Zuweisung. Jede SKU braucht eine UNSPSC-Klassifizierung (8 oder 10 Ziffern). Für internationale Sendungen braucht jede SKU auch einen Harmonized-System-Zolltarifcode. Die meisten Hersteller haben weder das eine noch das andere systematisch gemacht. Für einen 2.000-SKU-Katalog rechnen Sie mit 40–80 Stunden Arbeit, um alles zu taggen, ggf. mit einem Drittanbieter-Klassifizierungsdienst.

Preisbehandlung. Der Katalog, den der Punchout-Nutzer sieht, muss seine vertraglich vereinbarten Preise zeigen, nicht Listenpreise. Das heißt, die Punchout-Setup-Anfrage muss die Account-Identität des Käufers tragen, Ihr Katalog muss die Vertragspreise für diesen Account nachschlagen, und die Warenkorbpositionen müssen diese Vertragspreise zurückübertragen. Machen Sie das falsch, und Ihre Rechnung stimmt nicht mit dem PO überein, was eine AP-Ablehnung auslöst, die einen 30-Tage-Inkassozyklus auslöst. Account-spezifische Preislogik ist nicht trivial; die Mechanik wird im Detail in B2B-Account-basierte Preise behandelt. Wenn Ihre Preis-Engine noch keine accountspezifischen Vertragspreise abwickeln kann, beheben Sie das, bevor Sie Punchout einschalten.

Genehmigungsrouting auf der Käuferseite ist undurchsichtig. Sobald der Warenkorb zurückübertragen ist, wissen Sie nicht, ob die Anforderung in der Warteschlange eines Managers, in der Finance-Prüfung oder lautlos storniert worden ist. Bestellungen können 3–15 Tage in der Genehmigung hängen. Bauen Sie die Erwartung in Ihre Vertriebsgespräche und Ihre CSR-Workflows ein. Versprechen Sie keine Lieferzeiten ab Warenkorbübertragung; versprechen Sie sie ab PO-Empfang.

Rechnungspositionsübereinstimmung. Das AP-System des Käufers führt eine 3-Wege-Übereinstimmung durch: PO, Wareneingang, Rechnung. Wenn Ihre Rechnung 12 Positionen hat und der PO 11, wird die Rechnung automatisch abgelehnt. Wenn Ihre Rechnung Fracht in eine zusätzliche Position rollt, die nicht im PO war, wird die Rechnung abgelehnt. Wenn Ihre Stückpreise vom PO durch Rundung um auch nur einen Cent abweichen, wird die Rechnung abgelehnt. Ihr Rechnungsstellungsprozess muss den PO exakt spiegeln. Das ist operativ schwerer, als es klingt, besonders wenn Teilsendungen und Rückstände ins Spiel kommen.

Sollten Sie Punchout überhaupt unterstützen? Eine ehrliche Antwort

Der meiste Anbieter-Content zu diesem Thema argumentiert, dass jeder B2B-Hersteller Punchout braucht. Das ist falsch und nützt den Anbietern, die den Content schreiben, mehr als den Herstellern, die ihn lesen.

Der ehrliche Entscheidungsrahmen hängt von Ihrem Kundenmix ab, nicht vom Fähigkeiten-Neid.

Sie brauchen Punchout mit hoher Wahrscheinlichkeit, wenn:

• Ihre Top 10 Kunden 60–80 % oder mehr des Umsatzes ausmachen und einige davon Fortune-1000-Unternehmen, große Krankenhausysteme, Bundes-/Landesbehörden oder große Universitäten sind.
• Sie Lieferverträge mit den oben genannten anstreben und Ihre Wettbewerber bereits Punchout haben.
• Ihre bestehenden Großkundenkontakte Ihnen sagen, dass ihre Beschaffungsorganisation „nächstes Jahr auf Coupa umzieht“ oder bereits umgezogen ist.

Sie brauchen wahrscheinlich kein Punchout, wenn:

• Ihr Kundenstamm über Hunderte oder Tausende kleiner und mittlerer Unternehmen fragmentiert ist, ohne Enterprise-Beschaffungssysteme.
• Ihre durchschnittliche Bestellung unter 2.000 Dollar liegt und Ihre Kunden per Mail an Ihr Vertriebsteam oder über ein Self-Service-Portal bestellen.
• Ihr strategischer Wachstumspfad mehr KMUs und Mid-Market-Accounts ist, nicht das Gewinnen von Enterprise-Lieferverträgen.

Im ersten Szenario ist Punchout obligatorische Infrastruktur. Im zweiten ist es ein 25K–60K-Dollar-Projekt, das stillschweigend nie genutzt wird, weil keiner Ihrer Käufer die Beschaffungssysteme hat, um davon zu profitieren.

Die Falle, die zu vermeiden ist: von einem Interessenten über Punchout zu hören, in Panik zu geraten und übermäßig in eine Fähigkeit zu investieren, die 95 Prozent Ihres Kundenstamms nie anfassen werden. Validieren Sie die Nachfrage. Fragen Sie Ihre Top 20 Accounts, welche E-Procurement-Plattform sie nutzen. Wenn die Antwort „keine“ oder „wir mailen den PO“ lautet, haben Sie andere Prioritäten.

Wenn die Antwort von drei oder mehr Ihrer Top-Accounts „Coupa“ oder „Ariba“ lautet, verlagert sich die Frage von ob zu wie schnell.

Die 90-Tage-Realität

Zurück zum Chemiehersteller in der Eröffnungsszene. Mit 90 Tagen und ohne interne Expertise sieht der realistische Plan so aus:

• Tage 1–14: Engagieren Sie TradeCentric oder einen vergleichbaren Punchout-Anbieter. Unterzeichnen Sie den Vertrag. Stellen Sie die Testumgebungen bereit.
• Tage 15–45: Katalogaufräumen. UNSPSC-Codes den 800 SKUs zuweisen, die der Käufer am wahrscheinlichsten bestellt. Bestätigen, dass accountspezifische Preise für den Account des Käufers in Ihrem OMS korrekt sind.
• Tage 30–60: Der Punchout-Anbieter baut die Integration zur Coupa-Instanz des Käufers auf. Sie stellen den Katalogfeed und die Preisregeln bereit. Testen Sie PunchOutSetupRequest, PunchOutOrderMessage und den cXML-PO/Ack/ASN/Rechnungs-Zyklus in der Testumgebung des Käufers.
• Tage 60–80: Benutzerakzeptanztest mit dem Beschaffungsteam des Käufers. Iterieren über Randfälle (Großbestellungen, Teilsendungen, Ship-to-Überschreibungen für die 12 Empfangsanlagen des Käufers).
• Tage 80–90: Produktivumschaltung. Gehen Sie live mit einer kleinen Gruppe genehmigter Anforderer. Skalieren Sie in den folgenden 30 Tagen auf den vollen Käuferzugang.

Eng, aber machbar, mit einem Anbieter, der die Protokollarbeit erledigt, und Ihrem Team, das sich auf Katalogqualität, Preislogik und operative Integration mit Ihren bestehenden Back-Office-Workflows konzentriert. Wenn Sie lieber darüber sprechen, wie Punchout in einen breiteren B2B-Operations-Stack passt — einschließlich Bestellmanagement, Ausnahmebehandlung und accountspezifischer Workflows — kann unser Team die Architektur mit Ihnen durchgehen.

Die Beschaffung wird nicht langsamer. Die Fortune 1000 hat zwei Jahrzehnte damit verbracht, Ausgaben auf Coupa, Ariba, SAP Ariba Network, Jaggaer und Oracle iProcurement zu konsolidieren, und das nächste Jahrzehnt wird diese Konsolidierung tiefer in den Mid-Market drücken. Die Hersteller, die operativ bereit sind, über diese Systeme zu transaktieren, werden die Enterprise-Lieferverträge besitzen. Die, die es nicht sind, werden sich erneut erklären müssen, warum ihre Rechnungen immer wieder abgelehnt werden.