How to Sync Delivery Notes Without Duplicate Fulfillments or Broken Tracking

For businesses running SAP Business One alongside a BigCommerce storefront, there's a gap in the order lifecycle that most teams only find out about when a customer complains.

A Delivery Note gets created in SAP Business One. Goods leave the warehouse. But BigCommerce shows nothing — no shipment confirmation, no tracking link, no status update. The customer is in the dark, and your support queue fills up with "where is my order?" tickets that should never have existed in the first place.

The real problem: syncing SAP B1 shipments to BigCommerce isn't a simple data copy. It requires item-level fulfillment mapping, split shipment logic, carrier normalization, and a duplicate-prevention mechanism. Get any one of these wrong and the integration quietly fails in ways that are expensive to clean up.

This guide covers how a reliable SAP Business One to BigCommerce shipment integration actually works, the three failure modes that cause the most operational damage, and how appse ai automates the whole process on a five-minute schedule without any manual intervention.

Order creation gets most of the attention in any ERP-to-ecommerce integration. Orders flow from BigCommerce into SAP Business One, inventory gets allocated, and the fulfillment process kicks off. That part usually works fine.

Shipment sync is where things quietly fall apart.

When a Delivery Note is created in SAP Business One, it represents a real warehouse event: products have been picked, packed, and dispatched. That event needs to reach BigCommerce quickly, accurately, and in a format the platform can actually use. If it doesn't, the downstream effects compound pretty fast.

What goes wrong when shipment sync is missing or unreliable

• Customers see an open order status long after goods have left the warehouse.
• Support teams end up handling avoidable queries about shipment status.
• Operations staff reconcile SAP and BigCommerce records manually, usually in spreadsheets.
• Finance teams can't close orders cleanly because fulfillment data is incomplete.
• Split shipments are either lost entirely or collapse the order before it should be closed.

The business cost is pretty direct. Every mis-synced shipment becomes a support ticket. Every broken tracking link chips away at post-purchase trust. Every duplicate fulfillment record needs a manual correction that shouldn't have been necessary to begin with.

A well-designed SAP Business One to BigCommerce shipment integration removes all of that friction. It keeps SAP B1 as the operational source of truth while giving BigCommerce the structured fulfillment data it needs to keep customers informed automatically.

Most SAP B1 to BigCommerce shipment integrations fail in one of three predictable ways. Knowing what each failure looks like is the first step to building something that actually avoids them.

Failure 1: Orders closed too early when shipments are split

Split shipments are pretty common in B2B ecommerce. An order might include items from multiple warehouses, products available on different dates, or goods that have to ship separately because of packaging or supplier constraints. In SAP Business One, this usually means multiple Delivery Notes are created against a single BigCommerce order.

The integration problem happens when the first Delivery Note gets treated as a complete fulfillment.

If the workflow marks the BigCommerce order as fully shipped after the first delivery, the remaining items lose their fulfillment context. The customer sees a completed order. Your team sees a closed record. The second shipment has nowhere to go, and items effectively go missing in the process.

The correct behavior:

• Delivery Note 1 (six of ten items) creates a BigCommerce fulfillment for those six items only. Order status: Partially Shipped.
• Delivery Note 2 (remaining four items) creates a second fulfillment. Order status: Completed.

Each SAP B1 Delivery Note needs to map to a BigCommerce fulfillment that contains only the exact line items and quantities included in that delivery. Nothing more.

Failure 2: Tracking numbers arrive without working tracking links

A raw tracking number isn't a tracking experience.

Customers expect to click a link and see live carrier status. If BigCommerce doesn't recognize the carrier name attached to the tracking number, it can't generate a usable tracking URL. The customer gets a string of digits that leads nowhere, and trust in the post-purchase experience takes a hit.

This failure starts in SAP Business One, where carrier naming is rarely standardized for external platform consumption. Some common examples of the mismatch:

A reliable integration includes a carrier-mapping layer that translates SAP shipping method values into the provider names BigCommerce recognizes. Without it, tracking is basically broken by default.

The workflow should also validate tracking numbers before creating the fulfillment. If no tracking number exists, the integration needs to follow a defined business rule — create the shipment without tracking, hold it for review, or route to an exception queue. Whatever the choice, the behavior should be intentional, not accidental.

Failure 3: The same Delivery Note gets processed more than once

Scheduled automations run repeatedly by design. Without something to mark records as processed, every run picks up the same SAP B1 Delivery Notes and tries to create the same BigCommerce fulfillments all over again.

The result: duplicate fulfillments, duplicate customer notifications, and a fulfillment history that nobody can make sense of. Cleaning up duplicates is manual, time-consuming, and completely avoidable.

The fix is idempotency — the workflow needs to be safe to run multiple times without producing duplicate results for records that've already been synchronized.

What a processed-record mechanism looks like in practice:

After BigCommerce confirms the fulfillment, the workflow writes back to the SAP B1 Delivery Note:

• A synced or processed flag (boolean or status field)
• The sync timestamp
• The BigCommerce fulfillment ID
• An error status if the sync failed

Every subsequent run filters out Delivery Notes that already have a successful sync result. If a temporary API failure happens, the workflow logs the error and retries safely. It won't create a new fulfillment if a valid BigCommerce fulfillment ID is already on the record.

appse ai automates the SAP Business One to BigCommerce shipment sync on a five-minute polling schedule. The workflow runs continuously in the background, doesn't require manual exports, and handles every failure mode described above by design.

Here's exactly what happens on each run.

A shipment sync that works fine in testing but fails in production usually traces back to one of seven setup gaps. Worth confirming each of these before you enable the integration.

Skipping any of these doesn't stop the integration from running. It just means the failure shows up in production, where fixing it costs a lot more.

Shipment synchronization sounds like a background task. In practice, it's one of the most customer-facing processes in a B2B commerce stack — and one that most businesses only discover is broken when a customer complains.

The three failure modes covered in this guide (premature order closure, broken tracking links, and duplicate fulfillments) aren't edge cases. They're the default outcome of a shipment integration that wasn't built to handle the operational realities of SAP Business One and BigCommerce running together.

appse ai's shipment workflow addresses each failure point directly. The automation runs every five minutes, processes only eligible Delivery Notes, creates item-level BigCommerce fulfillments, maps carriers correctly, and writes the sync result back to SAP B1 so no record ever gets processed twice.

Your operations team stops reconciling spreadsheets. Your customers get accurate shipment updates within minutes of goods leaving the warehouse. And your fulfillment history stays clean enough to actually be useful.

That's the difference between a connected business and one that's still discovering integration failures through customer complaints.