Every translation failure in this series has lived somewhere visible.
Wrong products. Incorrect prices. Inventory numbers that mislead. Payment terms that do not enforce. Each one was traceable. A customer noticed it, a support ticket described it, or a finance report flagged it.
This one is different.
The ninth translation failure does not surface in the order. It surfaces in the identity layer underneath it, in the customer record that every other system depends on to know who it is talking to.
When that layer mistranslates, nothing looks wrong. Sync jobs complete. No errors are logged. Customer data moves from ERP to eCommerce exactly as designed.
And checkout starts failing for your most loyal buyers.
The Setup
Absolute Parts (name changed) is a large-scale B2B distributor supplying components to a national network of mechanics, dealers, and service centres. Their customers are repeat buyers. Many log in daily, reorder from established account profiles, and expect the storefront to know exactly who they are and where to ship.
Their systems:
- Storefront: Adobe Commerce
- ERP: Dynamics 365 Business Central
Customer data in Business Central was detailed and actively maintained. Account records were updated regularly: address corrections, new delivery locations added, billing details refined as relationships evolved. The ERP was the single source of truth for every account.
The integration brief was straightforward: keep customer records in Adobe Commerce perfectly mirrored to Business Central. Whatever the ERP held, the storefront should reflect.
At launch, it worked. Customers logged in, saw their accounts, and placed orders without friction. The problems arrived quietly, weeks later, and for the customers no one would have expected to be affected.
Two Customers, Same Failure Mode
Meet Ray Kowalski. He manages procurement for a mid-sized automotive dealership group and has been buying from Absolute Parts for seven years. His account profile in Business Central held four delivery addresses, one for each site his group operated.
Meet Priya Nair. She is an account manager at a regional service centre that had recently expanded, adding two new delivery locations to her Business Central profile in the past six months.
Both were high-value accounts. Both logged in regularly. Both experienced the same problem: checkout had become nearly unusable.
Ray’s checkout page took over thirty seconds to load at the shipping address step. On some attempts it timed out entirely. He called support assuming a website problem and was told the site was performing normally.
Priya had started abandoning her cart and calling in orders instead, a workaround that cost her time and cost Absolute Parts the self-service efficiency the eCommerce channel was built to deliver.
The integration logs showed nothing wrong. Data was moving. No errors. No failed jobs.
An audit eventually found the source. Ray’s Adobe Commerce profile contained not four delivery addresses but two hundred and sixty-three. Priya’s held over ninety. Every one of them was a ghost.
First Translation Failure
Update vs Append
In Business Central, a customer record is a system of operational accuracy. When an address is updated, Business Central treats it as a modification to an existing record. The old value is replaced. One record, one address, one source of truth.
In Adobe Commerce, a customer profile is a system of transactional engagement, designed to preserve history. When new data arrives, Adobe Commerce’s instinct is to append, not overwrite. It adds the incoming data as a new entry because discarding data feels like losing context.
Neither instinct is wrong. Each system is behaving exactly as it was designed to behave.
The translation failure is in the gap between them, in an integration that carried data from one system to the other without carrying the intent behind it.
Every time Business Central sent a customer record update to Adobe Commerce, whether it was a genuine address change, a routine re-sync, or a confirmation of existing data, Adobe Commerce interpreted it as a new entry. A record that Business Central had modified once became two records in Adobe Commerce. Modified again: three. Re-synced during a routine job: four.
For Ray, seven years of account maintenance and routine syncs had accumulated two hundred and sixty-three address entries. For Priya, six months of rapid expansion had created ninety. The longer the relationship, the more syncs, the more ghosts. Integration accuracy was working against the customer.
ERP systems overwrite for accuracy. eCommerce systems append for history. When integration cannot distinguish between a modification and a new entry, the eCommerce platform fills with ghost data that is technically correct and operationally catastrophic.
Second Translation Failure
Ghost Data Targets Your Best Customers
The consequences of ghost data do not distribute evenly. They concentrate precisely where they do the most damage: in the accounts that have been customers the longest, bought the most, and whose records have been touched the most often.
When Ray reached the shipping address step at checkout, Adobe Commerce attempted to render his address options. Not four addresses. Two hundred and sixty-three. Hundreds of identical entries, each one a legitimate database record, each one requiring the browser to process and display it.
But here is what made it worse. Ray could see the problem. Hundreds of duplicate addresses filled his screen. Rather than scroll through two hundred and sixty-three entries to find the correct one, he did what any rational person would do: he created a new address entry. Which added one more ghost to the pile.
The checkout was not slow because of a server problem. It was slow because it was doing exactly what it had been asked to do, at a scale no one had designed for. And the customer’s natural response to the confusion made the underlying problem worse with every order.
The system was overwhelming itself with its own data. And customers, trying to escape the confusion, were helping it do so.
Ghost data concentrates in your oldest and most active accounts, the ones with the most relationship history and the highest lifetime value. In a B2B context, those are almost always your most important customers. The identity layer failure does not distribute risk evenly. It targets the accounts you can least afford to lose.
Third Translation Failure
A Corrupted Identity Layer Breaks Everything Above It
Customer data is not one of many data types in an integration. It is the layer everything else depends on.
Pricing is customer-specific. Credit limits are account-specific. Payment terms are relationship-specific. Delivery routing depends on which address is valid. Order history depends on which profile to attach it to.
When the identity layer carries ghost data, every system that depends on it inherits the problem. Some of Absolute Parts’ account managers were seeing order history that did not match their recollection, because orders had attached to duplicate profile entries rather than the canonical account record. Pricing rules were occasionally failing to resolve correctly because the system could not determine which profile instance was authoritative.
Priya had stopped using the storefront. Ray was close to doing the same. Neither had complained about ghost data. They experienced slow checkout and assumed the platform was unreliable. The conclusion they were drawing was about Absolute Parts’ eCommerce investment.
A corrupted identity layer does not break one thing. It quietly undermines everything built on top of the customer record, and the damage compounds with every sync cycle and every order placed.
Most teams don’t find out until a longtime customer call to report a broken checkout. The ERP-eCommerce Alignment Audit maps your customer data sync architecture against the translation failures in this series, so you know if your system is working for you, or against you.
Breakthrough
Enter i95Dev: Translating Intent, Not Just Data
When Absolute Parts came to i95Dev, the initial diagnosis pointed at server performance. The real diagnosis pointed at the integration architecture.
The question shifted from: ‘How do we make checkout faster?’
To: ‘How does the integration know the difference between a modification to an existing record and a genuinely new entry?’
That question had no answer in the existing architecture. The connector received data from Business Central and inserted it into Adobe Commerce, every time, as a new entry. It carried the data faithfully. It carried none of the intent.
1. Building an Intent Translation Layer and Eliminating Existing Ghosts
The integration was rebuilt with a logic bridge that intercepted every incoming data packet before it touched the eCommerce database. For each incoming record, the bridge evaluated: does this customer already exist in Adobe Commerce? If yes, is this incoming data a modification to an existing address or a genuinely new delivery location?
The evaluation used Business Central’s own record identifiers as the authoritative signal. If the record existed and the incoming data was a modification, the bridge triggered an update. If it was a genuinely new location, it triggered an insert. The eCommerce platform received instructions, not raw data, and those instructions carried the intent Business Central had always expressed but the integration had never translated.
In parallel, a surgical remediation process identified canonical records for each customer and retired the ghost entries. Ray’s two hundred and sixty-three address entries were reduced to four. Priya’s ninety became six, reflecting her two legitimate new locations alongside her original four. No order history was lost. No account relationships were disrupted.
2. Structural Protection and Identity Layer Monitoring
Bulk re-sync operations were redesigned to run as update checks rather than insert operations. A re-sync could no longer create new records. It could only confirm, update, or flag for review.
A monitoring process was introduced that tracked address record counts per customer account over time, flagging any account whose record count grew beyond expected thresholds between sync cycles. Ghost data accumulation, if it ever recurred, would surface as a signal in monitoring before it reached checkout-breaking scale. The integration stopped being a black box. The identity layer became auditable.
The Result
Ray’s checkout loaded in under two seconds. He stopped calling support. His next order went through online without friction.
Priya returned to the storefront within days of the remediation. Her new delivery locations appeared correctly, her order history was intact, and her workaround of calling in orders became unnecessary.
Cart abandonment among Absolute Parts’ highest-value accounts dropped sharply. Support calls about checkout performance stopped. And critically, the address creation loop that had been compounding the ghost data problem with every confused customer interaction closed permanently.
Once the identity layer was trustworthy, every system built on top of it, pricing, payment terms, order history, delivery routing, became more reliable too.
Visual Representation
| Attribute | ERP (Dynamics 365 BC / NetSuite / SAP B1) | eCommerce (Adobe Commerce / Shopify / Magento) | The Gap |
|---|---|---|---|
| System purpose | System of record: operational accuracy, single source of truth | System of engagement: transactional history, customer profile preservation | ERP overwrites for accuracy; eCommerce appends for history. The same update creates a new record. |
| Record update behaviour | Modifies existing records in place; old values replaced, record count stays stable | Appends incoming data as new entries unless explicitly instructed to update | Every ERP update becomes an additional eCommerce record; ghost data accumulates silently |
| Accumulation pattern | Record count reflects actual customer relationships, stable and accurate | Record count grows with every sync cycle and every account update | Ghost records concentrate in oldest, most active accounts. Highest-value customers affected most. |
| Customer experience | Data integrity maintained; no performance consequence from record updates | Checkout renders all address entries; page load time scales with ghost record count | Customers see hundreds of duplicate addresses, create new ones to avoid the confusion, and compound the problem |
The i95Dev Fix
Translate the intent behind customer record updates, not just the data
- Intent translation layer: intercepts ERP data before it reaches eCommerce, evaluating whether each incoming record is a modification or a new entry
- ERP record identifiers carried in every sync payload so eCommerce can resolve intent without ambiguity
- Surgical remediation of existing ghost records: canonical addresses restored, duplicates retired without disrupting order history or account relationships
- Bulk re-sync operations redesigned as update checks rather than insert operations
- Identity layer health monitoring: account record counts tracked over time, anomalies flagged before they reach checkout-breaking scale
The Integration Truth
Every other failure in this series broke something customers could point to. A price that did not match. An order that could not be fulfilled. A checkout that showed the wrong terms.
This one broke something they could only feel. A platform that used to work, now unreliable for reasons no one could explain. And because the failure was invisible at the system level, the blame landed on the product, the implementation, the investment.
ERP and eCommerce do not just treat customer data differently. They treat the concept of a customer record differently. One sees a single source of truth to be maintained with precision. The other sees a history to be preserved with care.
Unless integration carries the intent of each update, those two instincts work against each other with every sync cycle. Quietly. Correctly. And in direct proportion to how long a customer has been with you.
At i95Dev, we do not sync customer records. We translate what each update means, so the identity layer both systems depend on stays clean, accurate, and fast. Because a checkout that fails your best customers is not a performance problem. It is a translation failure that has been building since the first sync.
This Was the Ninth Translation Failure
Eight translation failures, each breaking a different layer. Products, pricing, tax, inventory, discounts, payment terms, sync timing. Each one visible in its own way, traceable to a specific moment of friction.
The ninth was different. It accumulated silently in the background, touched no order directly, and revealed itself only when your most valuable customers stopped trusting the platform they used every day.
The identity layer is not one failure mode among many. It is the foundation the others sit on. And when it corrupts, everything built on top of it corrupts with it.
Where might customer data translation be missing in your integration today?
- Do your highest-value accounts experience slower checkout than newer ones?
- Has anyone audited the address record count per customer in your eCommerce platform recently?
- Does your integration distinguish between a modified customer record and a new one?
- Are routine re-sync jobs designed as update operations or insert operations?
- Has order history ever attached to the wrong profile instance for an established account?
If these feel unfamiliar, that is not reassurance. Ghost data accumulates silently. The absence of a complaint is not evidence of a clean identity layer.
One translation failure remains. Orders that were placed correctly, confirmed correctly, and fulfilled correctly can still come apart when a customer edits, cancels, or returns them. That is where the tenth and final failure begins.
