WooCommerce SAP integration

What a WooCommerce to SAP integration actually does

WooCommerce is where the sale happens: the order, the customer who placed it, the products, the payment, the refund a week later. SAP is where the business runs on that sale: the sales order that drives fulfilment, the customer master it posts against, the material master that has to exist first, the delivery, the invoice, the stock that just dropped. Left unconnected, someone re-keys every order from the WordPress admin into SAP by hand, and someone else exports stock from SAP into a spreadsheet to stop the shop overselling.

A WooCommerce to SAP integration closes that gap in both directions. Orders and customers flow from the store into SAP as proper sales documents against the right master data. Stock levels, prices, and delivery status flow from SAP back to the store so the catalogue reflects reality. Nobody retypes an order, and nobody discovers at dispatch that the item sold out three orders ago.

What data moves

WooCommerce object / event	Becomes in SAP	Notes
Paid order	Sales order (VBAK/VBAP, or ORDR in Business One)	Needs sales org, distribution channel, division set - none of which exist in WooCommerce
Order line item	Sales order line against material number	SKU mapped to the SAP material; unknown SKU is rejected, not guessed
Customer / billing address	Business partner / customer master (Debitor)	Deduplicated on email and VAT ID; B2C can post to a CpD collective account
Shipping & discounts	Pricing conditions / condition lines	Modelled as SAP conditions, not free-text lines
Refund / cancellation	Credit memo / return (Gutschrift)	References the original document, dated to the refund
SAP stock level	WooCommerce stock quantity	SAP is source of truth; delta sync back to the store
SAP price list	WooCommerce product price	Currency and price-list assignment respected
SAP delivery / goods issue	WooCommerce order status + tracking	Moves the order to completed and posts the tracking note

The exact field mappings, number ranges, sales-org configuration, and tax codes are agreed once against your SAP setup and encoded in the pipeline. After that, nobody maps them by hand again.

The details that break naive syncs

A generic plugin or a nightly CSV import gets you 80% of the way and leaves the expensive 20% for your operations and Basis teams:

• Material numbers are not SKUs. SAP material numbers are commonly numeric and zero-padded across an 18-character field; a WooCommerce SKU is whatever a shop manager typed. The mapping and the leading-zero conversion have to be explicit, or every order line lands on the wrong material or none at all.
• SAP will not accept a half-formed order. A sales order needs a valid customer master and valid materials to exist before it is created, plus sales org, distribution channel, and division. WooCommerce carries none of that. The pipeline has to ensure the master data first and enrich the order with the organisational fields SAP demands.
• Customer master duplication. Every guest checkout is a new WooCommerce customer. Without dedup against email and VAT ID you flood the SAP customer master with duplicate Debitoren - which then wrecks reporting and dunning.
• Tax codes, not tax rates. WooCommerce stores a tax rate; SAP posts against a tax code (Steuerkennzeichen / MWST) that also encodes domestic, EU, and export treatment. The two are mapped, not copied.
• Stock timing and overselling. Push stock back too slowly and the store sells what the warehouse already shipped. Delta sync and the right cadence matter more here than anywhere.
• Partial failures. SAP can accept the header and reject a line, or the Service Layer session can drop mid-batch. The pipeline has to detect the partial result, not report a success that never fully landed.
• Idempotency. Re-run a naive import and you post the same order into SAP twice. Every WooCommerce order carries a stable id the pipeline tracks, so a retry never creates a duplicate sales document.

How we build and run it

We treat this as a pipeline, not a batch job. WooCommerce order, customer, and refund events are pulled by webhook or on a schedule, validated, enriched with the master data and organisational fields SAP requires, and posted into SAP through the right interface for your release - OData, BAPI/RFC, IDoc, or the Business One Service Layer. Stock, price, and delivery updates flow back to the store the same way.

The pipeline is idempotent: every WooCommerce order carries a stable identifier, so a retry or a re-run never posts a duplicate sales order or double-decrements stock. It runs on cloud-native, fully EU-hosted AWS infrastructure, so order and customer data never leaves the EU - which keeps your DPA / AVV and GDPR obligations clean, including where SAP itself is on-premise behind your network.

And then we keep it running. Monitoring, alerting, incident response, and - critically - watching for WooCommerce REST API changes, plugin updates that reshape the order payload, and SAP interface changes are our responsibility under contract. You get a named owner and an SLA, not a script your team has to babysit.

When this integration is worth building

If you take a handful of orders a week and someone re-keys them into SAP in a few minutes, a manual process is genuinely fine and we will tell you so. The integration earns its place when order volume makes re-keying a job in itself, when overselling because stock is stale starts costing you, when guest checkouts are bloating your customer master, or when B2B pricing, VAT handling, and returns make the SAP side too intricate to trust to copy-paste. At that point a managed pipeline pays for itself in the errors it stops reaching your ERP.