Do you write into SAP Business One via the Service Layer or the DI-API?

By default the Service Layer (OData v4), because it is the supported, HANA-friendly interface for SAP Business One 9.x and 10 and it handles concurrent load cleanly. Where a customer runs an older SQL-based install without a usable Service Layer, or needs a specific add-on object, we fall back to the DI-API. We agree the interface, the company database, and the licensing up front so nothing surprises your SAP partner.

How do you avoid creating duplicate Business Partners for the same customer?

Matching is the hard part, so we make it explicit. Shopware customers are resolved against existing SAP Business Partners by a deterministic key you choose - email, VAT ID, or an external number - before any new BP is created. Guest checkouts and B2B accounts with an existing debtor are handled by separate rules. New BPs get a defined CardCode series and group, never a random one, so your accounting stays clean.

Does the Shopware order become a Sales Order or an A/R Invoice?

Whichever fits your process, and often both in sequence. Many B2C shops post a paid Shopware order straight to an A/R Invoice plus incoming payment; B2B and pick-pack workflows post a Sales Order first, then let SAP drive delivery and invoicing. We map the Shopware payment and fulfilment status to the right document stage so SAP is never ahead of, or behind, what actually happened in the shop.

SAP Business One has no webhooks - how does stock stay current in Shopware?

Correct, SAP Business One does not push events, so we poll the Service Layer on a short schedule using UpdateDate filters to pull only what changed - item prices, warehouse stock, master data - and write deltas back to Shopware. The interval is tuned to your catalogue size and how fast stock moves, so availability in the shop tracks the ERP without hammering the Service Layer session.

Who operates it after go-live?

We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor. If Shopware or the SAP Business One Service Layer changes, or a session expires, or an order fails to post, that is our alert to act on - not something your team finds when a customer asks where their order is. You get a named owner, monitoring, and an SLA rather than a script on someone's machine.

Shopware SAP Business One integration

What a Shopware to SAP Business One integration actually does

Shopware is where the sale happens - the customer, the basket, the chosen payment method, the shipping address, the tax the storefront calculated. SAP Business One is where the business is actually run - the Business Partner ledger, the item master, warehouse stock, pricing, and every document from Sales Order to A/R Invoice to incoming payment. Both systems think they own the customer and the product. Neither is wrong, and that is the problem.

A Shopware to SAP Business One integration makes them agree. Orders flow from the shop into the ERP as the correct documents against the correct Business Partner and Items; item master data, price lists, and warehouse stock flow back so the storefront sells what actually exists at the price finance agreed. Nobody re-keys an order into SAP, and nobody edits a stock figure in Shopware by hand.

What data moves

Shopware object / event	Becomes in SAP Business One	Notes
Registered / guest customer	Business Partner (Customer, CardCode)	Matched to an existing BP first; new BPs get a defined CardCode series and group
Placed order	Sales Order (ORDR)	Header + line items mapped to Item codes; document numbering left to SAP series
Paid / fulfilled order	A/R Invoice + Incoming Payment	Document stage driven by Shopware payment and fulfilment status
Order line item	Document line, per Item	Sales unit vs inventory unit and UoM conversion resolved here
Tax on order lines	VAT group / tax code per line	Domestic, EU OSS, and reverse-charge each map to the correct SAP tax code
Item master (from SAP)	Product in Shopware	ItemCode as the product number; description, attributes, active flag
Price list (from SAP)	Customer-group / net prices in Shopware	Currency and price-list-per-BP respected
Warehouse stock (from SAP)	Available stock in Shopware	Which warehouse(s) feed the shop, on-hand vs committed, agreed once

The exact field mapping, CardCode logic, tax codes, and which warehouses feed the shop are agreed once with you and your SAP partner and encoded in the pipeline. After that, nobody maps them again by hand.

The details that break naive syncs

A nightly CSV import or a generic connector gets you most of the way and leaves the expensive part on your desk:

Business Partner matching. The same shopper can be a guest today and a registered B2B debtor tomorrow. Resolving a Shopware customer to the right existing CardCode - by email, VAT ID, or external number - before creating a new BP is what keeps your debtor ledger from filling with duplicates.
Item and unit mapping. Shopware product numbers are not automatically SAP ItemCodes, variants multiply the mapping, and the shop’s sales unit may differ from SAP’s inventory unit. UoM conversion has to be explicit or quantities post wrong.
Tax codes, not tax rates. Shopware calculates a tax amount; SAP needs a tax code (VAT group). Domestic, EU distance sales under OSS, and B2B reverse-charge are different codes, and net-vs-gross pricing has to line up or the A/R Invoice will not match the order total.
No events from SAP. SAP Business One does not emit webhooks, so stock and price sync is polling. Pulling everything every run does not scale; delta sync on UpdateDate does, and it has to respect the Service Layer session lifetime rather than re-authenticating on every call.
Document numbering and stages. SAP owns its numbering series - the integration must never force a DocNum. And posting an invoice for an order that was refunded or cancelled in Shopware minutes later is how a naive sync corrupts the ledger.
Partial failures. An order can create the Sales Order but fail on the invoice, or match the BP but fail on one line. The pipeline needs idempotency - a stable Shopware order reference stored on the SAP document - so a retry resumes rather than duplicates.

How we build and run it

We treat this as a pipeline, not a batch job. Shopware orders are pulled by the Admin API or received by webhook, validated, resolved against SAP Business Partners and Items, and written into SAP Business One through the Service Layer as the agreed documents. Item master, price lists, and warehouse stock are polled from SAP on a delta schedule and written back into Shopware.

The pipeline is idempotent: every Shopware order carries a stable identifier that we store on the SAP document, so a retry, a re-run, or a Service Layer session drop never posts the same order twice. It runs on cloud-native, fully EU-hosted infrastructure, so order and customer data never leaves the EU - which keeps your DPA / AVV and GDPR obligations clean.

And then we keep it running. Monitoring, alerting, incident response, and - critically - watching for Shopware Admin API and SAP Business One Service Layer changes are our responsibility under contract. A named owner and an SLA replace the script nobody wanted to own.

When this integration is worth building

If you push a handful of orders a day and someone re-keys them into SAP in ten 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 Shopware stock lags SAP costs you real money, when B2B customers with existing debtor accounts and price lists need to be matched correctly, or when your SAP partner is billing you to clean up duplicate Business Partners and mis-coded documents that a pipeline should have prevented.