Why “Shipped” Means Something Different to Your ERP and Your Customer 

Every customer asks the same question after placing an order. 

“Where is my order?” 

It sounds like the simplest question in commerce. And most of the time, customers do not need to ask it at all — the answer should already be on the order page. But when an order ships in pieces, the answer fractures. The website says one thing. The warehouse did another. And by the time anyone notices, the customer has already called. 

ERP order statuses are built to track operational reality with precision. eCommerce order statuses are built to communicate progress in language customers understand. For a simple order, those two purposes produce the same answer. For a partial shipment, they produce three different ones, and the customer receives whichever one the integration happened to map last. 

This is not a failure of data. The ERP is correct. The warehouse is correct. The integration is moving data exactly as designed. The failure is in what the status means when it reaches the customer, because the two systems were never designed to mean the same thing. 

That gap has been absorbing support calls, eroding trust, and costing repeat orders since the first partial shipment went out. 

PrecisionFlow Tools (name changed) is a B2B supplier serving contractors, distributors, and facilities management companies across multiple regions. Their catalog combines stocked items, special-order components, and warehouse-transfer inventory. For most customers, a single order spans all three. 

Their systems: 

• Storefront: Adobe Commerce 
• ERP: Dynamics 365 Business Central 

Partial shipments were not an exception at PrecisionFlow. They were the norm. Business Central handled them with precision: ship available items immediately, hold special-order items until sourced, transfer warehouse stock on its own timeline, invoice each shipment separately. Operationally, this was correct and efficient. 

On Adobe Commerce, each order had one status field. It was mapped to Business Central at setup: Processing, Shipped, Complete. The mapping reflected the most common scenario. It did not account for the most common reality. 

When a customer’s order began moving through multiple shipments, Adobe Commerce received status updates from Business Central and applied the most recent one. The result was a single status field trying to communicate a multi-threaded fulfilment event to a customer who had no way of knowing it was multi-threaded. 

Support calls followed. So did the pattern underneath them. 

Meet Leon Vasquez. He manages procurement for a regional maintenance contractor whose crews depend on tool availability across job sites. His orders are large, time-sensitive, and frequently include a mix of immediately available stock and items that need to come from a secondary warehouse location. 

Meet Anita Patel. She runs supply chain operations for a mid-sized facilities management company. Her team places regular orders, reconciles them against purchase orders, and tracks delivery against project timelines. Accuracy matters more than speed. She needs to know what is coming and when. 

Leon placed a fourteen-line order on a Monday morning. Nine items were in stock at PrecisionFlow’s main warehouse. Three were available at a regional location two days away. Two were special-order components expected within the week. 

Anita placed a six-line order the same day. Four items shipped immediately. Two were on back-order, expected Thursday. 

By Wednesday, Leon’s storefront status read: Shipped. His crews were on site waiting for a full delivery. Nine items arrived. Five did not. He called support. His first words were: ‘Your website says shipped. Half my order isn’t here.’ 

By Wednesday, Anita’s storefront status read: Processing. Four items had already arrived at her facility on Tuesday. She called support asking why her order had not moved. 

Neither status was technically wrong. Both were operationally useless. And both produced support conversations that should never have been necessary. 

We Run Two Systems and They Never Agree 

Business Central tracks order progress across multiple dimensions simultaneously. A single order can be in Released state for some lines, Partially Shipped for others, and Pending for the rest, all at the same time. That granularity is not a quirk of the ERP. It is the operational truth of how complex orders fulfil. 

Adobe Commerce has one status per order. That status is a customer communication tool. It tells the buyer what stage their order is in, using language designed for comprehension: Processing, Shipped, Complete. Those words carry clear meaning in a consumer context. In a B2B partial fulfilment context, they carry almost none. 

When Business Central sent PrecisionFlow’s integration a status update reflecting the first partial shipment, the integration updated Adobe Commerce’s order status to Shipped. From that moment forward, Leon’s order said Shipped. It would continue saying Shipped regardless of whether five more items were still pending in a warehouse queue. 

The integration had not failed. It had done exactly what it was built to do: keep the eCommerce status current with the ERP’s most recent update. The problem was that “most recent update” and “complete picture” are not the same thing, and the customer had no way to know the difference. 

ERP order statuses describe what has happened in the warehouse. eCommerce order statuses communicate what the customer can expect. Those are different jobs. When integration maps one directly to the other, customers receive operational data dressed up as customer communication, and it fails both purposes. 

Business Central holds the full operational picture: which lines shipped, from which location, on which date, with which tracking reference, and what remains outstanding. Adobe Commerce holds one word. The translation failure is not in moving the word incorrectly. It is in treating one word as sufficient to carry the full picture across. 

The Invoice That Arrives Before the Goods 

Business Central invoices each shipment as it leaves the warehouse. This is correct financial behaviour: revenue is recognised when goods ship, not when the full order completes. For PrecisionFlow’s finance team, this was standard and appropriate. 

Anita’s team received an invoice for four items on Tuesday, the day the first partial shipment left the warehouse. Their purchase order covered all six items. Their accounts payable process required a three-way match: purchase order, invoice, and goods receipt. 

The invoice covered four items. The PO covered six. The goods receipt covered four. The match was incomplete and required a hold until the remaining two items shipped and a second invoice arrived. 

None of this was wrong. Business Central had invoiced correctly. PrecisionFlow’s finance team had processed correctly. The problem was that Anita’s team had received an invoice in a context where they expected a single invoice for the full order, and the storefront had given them no indication that a partial shipment model was in play. 

When they called to query the invoice, they were told it was normal. That answer was accurate. It did not address the problem Anita put plainly when she called: “Finance has one view, the store has another. How are we supposed to reconcile against a PO when we don’t know how many invoices are coming?” 

ERP invoicing logic follows financial rules: invoice when goods ship. eCommerce customer experience follows expectation logic: one order, one invoice, one delivery. When a B2B customer operating on purchase order matching receives a partial invoice against a full PO with no prior communication, the financial accuracy of the invoice does not offset the operational disruption it creates. 

Tracking That Answers the Wrong Question 

Leon’s nine items shipped with a tracking reference. That reference was sent to him in a dispatch notification from Adobe Commerce. He clicked it. The carrier showed the shipment in transit. 

What the notification did not tell him: the tracking reference covered the first shipment only. Three more items were leaving a regional warehouse the following day under a different carrier reference. Two items had not yet been released from the special-order queue. 

From Leon’s perspective, he had one tracking number for one shipment. He assumed it was the complete order. His crews planned around the delivery date on that tracking reference. When the truck arrived with nine of fourteen items, the job site stopped. 

The second tracking reference arrived the following day, in a second dispatch notification, for a shipment Leon had not known was separate. The third notification, covering the back-order release, arrived four days later with no explanation of why those two items had not been in the original shipment. 

Every notification was technically correct. Each one described a real shipment with a real tracking reference. Collectively, they communicated nothing useful about the relationship between the three shipments, the original order, or when the full order would be complete. 

A tracking number answers the question: where is this package? It does not answer the question every B2B customer is actually asking: when will my complete order arrive? When partial shipments generate multiple tracking references without a parent-level view of order completion, customers plan against individual packages and get surprised by incomplete deliveries. 

eCommerce platforms communicate shipment events. ERP systems manage fulfilment sequences. In a partial shipment scenario, the customer needs fulfilment sequence visibility, not shipment event notifications. When the integration passes only shipment events, each one correct, the customer receives accurate information about fragments they never knew were fragments. 

Support Carries the Burden of Missing Context 

By Wednesday afternoon, PrecisionFlow’s support team had four calls in the queue from customers asking variants of the same question. Where is the rest of my order? Why does my order say shipped when half of it is not here? Why did I get an invoice before everything arrived? 

Each call required the support agent to log into Business Central, locate the order, identify which lines had shipped and which had not, explain the partial shipment model, and communicate expected dates for outstanding items. None of this information was visible on the storefront. None of it had been communicated proactively. 

The average call lasted eleven minutes. For questions that should have been answered by the order status page. 

Leon’s call was the most consequential. He had planned a job site around a complete delivery. The partial arrival created a full day of downtime for his crew. He did not dispute this calmly. He questioned whether PrecisionFlow’s digital channel was worth the overhead. His words, before hanging up: “We run two systems, and they never agree. At least when I call my rep, he tells me what’s actually happening.” 

That question is the real cost of the translation failure. Not the support call. Not even the job site delay. The customer reconsidering whether the eCommerce channel delivers enough value to justify the reduced human contact. 

Support teams absorbing order status questions are not a customer service problem. They are an integration problem. Every call that asks ‘where is my order?’ is a call that the order status page failed to answer. When ERP holds the complete picture and eCommerce shows a fragment of it, support carries the cost of the gap, one eleven-minute call at a tilme. 

PrecisionFlow’s support volume did not spike dramatically. It crept. Partial shipment calls accumulated as a consistent percentage of total support contacts, week after week, without triggering an obvious alarm. The pattern became visible only when someone mapped support categories against order types and found that partially shipped orders generated six times more support contacts per order than fully shipped ones. 

Six times more. For orders that were fulfilling correctly. 

The operational cost was measurable. The relationship cost was harder to quantify. Leon was not the only customer who had started questioning the channel. Several repeat B2B accounts had reverted to phone-based ordering for complex multi-line purchases, citing unpredictability. They had not complained formally. They had simply stopped using the storefront for the orders where it mattered most. 

The integration was not losing orders. It was losing the customers who placed them most often. And those customers were saying the same thing on their way out: ‘We went live and nobody told us it would work like this. Now we’re paying for it.’ 

Enter i95Dev: Translating Fulfilment Sequences into Customer Communication 

When PrecisionFlow came to i95Dev, the immediate instinct was to fix the status mapping. Map Partially Shipped in Business Central to a new Partially Shipped status in Adobe Commerce. Close the obvious gap. 

The question we asked was different: what does a customer actually need to know at each stage of a partial fulfilment, and which system holds that information? 

Business Central held everything. Adobe Commerce was showing almost none of it. The work was not about adding a status. It was about building a communication layer that carried the ERP’s fulfilment intelligence into the customer-facing experience. 

1. Parent-Level Order Tracking With Line-Level Visibility 

The integration was rebuilt to maintain a parent order record in Adobe Commerce that tracked overall completion status separately from individual shipment events. When a partial shipment left the warehouse, the parent record updated to show which lines had shipped, which were in transit from a secondary location, and which remained outstanding. 

Leon’s order page stopped showing a single Shipped status. It showed nine items shipped with tracking, three items in transit from a regional warehouse with an expected arrival date, and two items on special order with a confirmed release date. Every line had a status. The parent order had a completion percentage. The question “where is my order?” had a complete answer before he needed to ask it. 

2. Proactive Shipment Notifications With Full Order Context 

Dispatch notifications were redesigned to carry order context rather than just shipment events. When the first partial shipment left the warehouse, Leon received a notification that stated the shipment was partial, identified which items were included, and provided the expected timeline for remaining items. 

The second and third notifications referenced the original order explicitly and updated the outstanding item count. By the time the final shipment left the warehouse, Leon had received three notifications that together told a coherent story, not three separate dispatch events with no relationship to each other. 

His crews planned around a complete delivery timeline, not around a single tracking reference. The job site delay that had cost a full working day became structurally avoidable. 

3. Invoice Sequencing Communicated at Order Confirmation 

For accounts like Anita’s, where purchase order matching is a standard financial process, the integration introduced an order confirmation step that communicated the invoicing model upfront. When a multi-line order included items on different fulfilment timelines, the order confirmation stated that the order would be invoiced in stages as items shipped, with a projected invoice schedule. 

Anita’s accounts payable team received the first partial invoice expecting it. They had the projected schedule for the second. The three-way match that had previously required a hold and a support call became a planned, anticipated process. The invoice did not surprise anyone because the communication had preceded it. 

4. Support Visibility Aligned to Customer Visibility 

The final change was operational rather than architectural. Support agents gained a unified order view that showed the same parent-level tracking information customers could see, alongside the full Business Central fulfilment record underneath it. When a customer called, the agent saw what the customer saw and what Business Central knew, in the same interface. 

The eleven-minute calls that had required logging into Business Central separately, locating the order, and manually translating operational status into customer language shortened significantly. The information was already translated. The agent’s job became confirming it, not producing it. 

Leon’s next multi-line order showed him a fulfilment timeline at the point of confirmation. When the first partial shipment left the warehouse, he received a notification that told him exactly which items were in it and when the rest would follow. His crews planned accordingly. No surprises. No downtime. 

Anita’s team received a projected invoice schedule with their order confirmation. When the first partial invoice arrived, it matched their expectations precisely. The three-way match completed without a hold. She did not call support. 

Partial shipment support contacts dropped by over sixty percent within two months. The customers who had reverted to phone-based ordering for complex purchases began using the storefront again, because the storefront was now giving them the information a sales rep would have given. 

PrecisionFlow’s eCommerce channel did not become more capable by adding features. It became more trustworthy by closing the gap between what Business Central knew and what customers could see. 

Visual Representation 

Order event	ERP (Dynamics 365 Business Central / NetSuite / SAP B1) behaviour	eCommerce (Adobe Commerce / Shopify / Magento) behaviour	The gap
Partial shipment	Updates individual order lines to Partially Shipped; retains full visibility of outstanding lines with their own statuses and timelines	Updates the single order status field to Shipped or the most recently received status; no line-level distinction visible to the customer	Customer sees Shipped. Five items are still in the warehouse. Job site plans around a complete delivery that has not happened.
Partial invoicing	Generates an invoice for each shipment at point of despatch; correct financial behaviour aligned to revenue recognition rules	No native communication of partial invoice model; order confirmation does not indicate that multiple invoices will follow	Customer receives a partial invoice against a full PO with no prior warning. Accounts payable hold. Support call.
Multiple tracking references	Generates a separate despatch record and tracking reference for each shipment event, linked to specific order lines	Sends individual dispatch notifications per shipment; each notification is standalone with no reference to order completion progress	Customer receives three separate notifications that each describe a fragment. No parent view. No completion context. Planning fails.
Order completion	Order closes when all lines are invoiced and shipped; clear completion criteria at the line level	Order marked Complete when all lines reach the mapped ERP status; customer not informed of partial completion stages	Customer has no visibility into how complete their order is at any given point. Every status update is a surprise.

Translate fulfilment sequences into customer communication, not individual status events 

• Parent-level order tracking with line-level visibility: each order line carries its own status and timeline, and the parent record shows overall completion progress 
• Proactive partial shipment notifications: dispatch communications state which items are included, which are still outstanding, and when each remaining group is expected 
• Invoice sequencing communicated at confirmation: multi-line orders with staged fulfilment show a projected invoice schedule before the first invoice arrives 
• Unified support view: agents see the same parent-level tracking customers see, alongside full Business Central fulfilment detail, without switching systems 
• Status vocabulary aligned to customer expectation: partial shipment states use language that communicates progress rather than operational stage names 

The Integration Truth 

ERP systems describe operations precisely because operations require precision. Every line, every location, every shipment, every invoice has a status that the system maintains accurately and continuously. 

Customers do not need that precision. They need clarity. They need to know whether their order is complete, what is still coming, and when it will arrive. Those are simpler questions than what ERP answers. They are also harder to answer from a single status field. 

The gap between ERP precision and customer clarity is not a data problem. All the data exists, in detail, in Business Central. It is a translation problem. And the cost of leaving it untranslated is not measured in incorrect data. It is measured in support calls that should not exist, job sites that stop because a delivery was incomplete, and customers who decide that calling a sales rep is more reliable than using a platform that cannot answer a simple question. 

At i95Dev, we do not treat order status as a field to keep updated. We treat it as a communication contract between the business and the customer, one that the ERP holds the information to honour and the integration has the responsibility to deliver. 

Because a customer who asks where their order is and gets the wrong answer does not blame the ERP. 

They blame the business. 

This Was the Twelfth Translation Failure 

The series began with a catalog that exposed operational logic to buyers who needed buying logic. It ends here, with an order communication layer that exposes operational data to customers who needed customer communication. 

Both failures are the same failure, expressed at different ends of the commerce lifecycle. The integration moved data correctly. The translation was missing. And the customer paid for the gap. 

Twelve translation failures. Twelve layers where ERP logic and eCommerce logic diverge without announcing it. Each one silent in the integration logs. Each one visible in the customer experience. 

Where might order status translation be missing in your integration today? 

• Are customers calling you because the website says Shipped but only part of their order has arrived? 
• Do customers receive individual dispatch notifications with no parent-level view of how complete their order is? 
• Does your order confirmation communicate whether the order will be invoiced in stages? 
• Does your support team have to log into a separate system to answer ‘where is the rest of my order?’ — a question the order status page should have already answered?
• Have you mapped what each Business Central order status means in customer language, for every status that can appear on a partially fulfilled order? 

If these feel unfamiliar, your customers are already experiencing the gap. They are either calling support to fill it, or they have stopped expecting the storefront to answer it at all. 

Both are translation failures that live beyond the sync.