Dropship and Marketplace Seller Operations Field Guide: Diagnosing and Fixing Dropship Lead Time Reference Table Divergence

Your customer sees Ships in 5–7 business days at checkout. Your supplier portal says 10 days. Your ERP shows 7. It is not a rounding issue. It is not a supplier communication problem. And manually updating the storefront every time a supplier changes their lead time is not a solution — it is a workaround for an integration architecture problem.

The root cause has a specific name: Lead Time Reference Table Divergence. Your supplier portal and your ERP are each holding the lead time value in a separate reference table. Your storefront is polling whichever one wrote last. Until the divergence between those two tables is diagnosed and closed, every other fix — manual storefront updates, supplier notifications, buffer days added to checkout — is a patch over a structural problem.

This dropship and marketplace seller operations field guide gives dropship ops teams a ranked diagnostic sequence: which table is authoritative, what transformation rules are causing the dropship lead time mismatch, and how to close the sync gap so the number the customer sees at checkout actually reflects what the supplier can ship.

What Dropship Lead Time Reference Table Divergence Actually Is

The failure mode is precise: two systems hold different lead time values for the same SKU, and no sync rule determines which one the storefront should read.

Concretely:

• The supplier portal holds supplier-reported lead time in one table — updated by the supplier when they change their ship window, or via EDI 846 transaction when the supplier's system sends an updated lead time segment.
• The ERP holds a separately-maintained lead time in a different table — updated manually by your team, or pulled from a different EDI field, or set once during item setup and never revisited.
• The storefront polls one or both without a consistent rule for which value wins.

This is not a supplier delay, a fulfillment error, or a carrier transit miscalculation. Those are execution problems. Reference table divergence is a data architecture problem — the number was wrong before the order was placed.

A distinction that matters in every dropship and marketplace seller operations environment: supplier ship capability (time to ship from the supplier's warehouse) is different from carrier transit time (time in transit after the package leaves the supplier). These are frequently conflated, and when both live in the same lead time field across both systems, the mismatch compounds. One field may be carrying two meanings simultaneously — enough ambiguity to generate three different displayed values for the same SKU.

Why Dropship Lead Time Mismatch Keeps Happening Between Portal and ERP

Reference table divergence is structural, not accidental. It reasserts itself every time one system is updated without triggering a sync event into the other. In our work with fragmented omnichannel stacks, we consistently see six root causes active alone or in combination:

1. Independently-maintained tables. The supplier portal and the ERP are updated by different teams at different times, with no designated authoritative source. When the supplier updates their portal, nobody checks whether the ERP record was updated. When the ops team updates the ERP, they may not know the supplier already changed the portal. Both tables are technically "correct" from each team's perspective — but they disagree.

2. Item-level vs. supplier-level data model mismatch. The supplier portal typically stores lead time at the supplier level — one value per supplier, covering all items from that supplier. The ERP may store lead time at the SKU or item record level — meaning two different items from the same supplier can have different lead time values in the same ERP table. When a sync job maps supplier-level data into an item-level field, the transformation is lost or applied inconsistently, and the resulting value in the ERP may not match what the portal intended.

3. EDI/API table parsing differences. EDI 846 transactions carry lead time in specific segments. Middleware that parses these transactions may write to a different ERP field than the one your team uses for the item record lead time. In one engagement, a supplier reported a 7-business-day lead time via EDI 846 while the ERP item record held a 5-business-day value that nobody had updated in over eight months — because the EDI parser was writing to a separate staging table that fed a different field than the one the storefront read.

4. Batch sync lag windows. Nightly batch syncs write ERP values from portal data — but only for records updated before the batch window closed. Mid-day updates to either system are not reflected until the next batch runs. A lead time change made at 2pm is not visible to the storefront until the next morning's batch — and if the customer orders before then, the delivery date shown at checkout is already wrong.

5. Manual override loops. When the ops team discovers a mismatch, the fastest fix is usually to update the storefront directly or to update the ERP item record. Neither action notifies the other system. This creates a third source of truth that the portal and ERP do not know about, and each subsequent update overwrites the previous value without a reconciliation check.

6. Conflating supplier ship capability with carrier transit time in the same field. Both systems may store lead time as a single number — but that number means different things in each system. The portal may be recording time-to-ship. The ERP may be recording time-to-delivery. When both numbers are displayed as the same checkout field, customers see a lead time that is actually the sum of two unverified values.

Step 1: Find Which Reference Table Your Storefront Is Actually Polling

The diagnostic starts with a three-system audit for a single SKU. Before you can fix anything, you need to know which table your storefront is reading right now.

Pull one SKU's lead time from all three systems simultaneously — supplier portal, ERP, and storefront (or middleware cache if your storefront reads from a middleware layer rather than directly from the ERP).

Document each system's sync trigger type:

• On-demand API call — the storefront calls the ERP or portal API at render time and caches the result for a defined TTL
• Scheduled batch — the storefront cache is refreshed on a schedule (e.g., every 6 hours, nightly at midnight)
• Event-driven webhook — the authoritative system fires an event when a lead time value changes, and the middleware or storefront cache updates immediately

Build a simple audit table:

| SKU | Portal value | ERP value | Storefront value | Last sync | |-----|-------------|-----------|-----------------|-----------| | SKU-4001 | 10 business days | 7 calendar days | 5 business days | Middleware cache refreshed 11 days ago |

This audit log determines every subsequent decision. In a similar inventory sync investigation we documented, a dropship operation discovered the storefront was reading a middleware metafield that had not been refreshed in 11 days — not the ERP, not the portal. The sync gap was in the middleware layer, not between portal and ERP. The fix was not in the ERP-to-portal sync; it was in the middleware cache refresh rule. The same pattern applies here for dropship lead time discrepancies between supplier portal and ERP systems.

Step 2: Designate the ERP as the Authoritative Lead Time Reference Table

Designate one authoritative source and document it formally — not in a Slack thread, not as oral institutional knowledge.

The ERP is typically the correct authoritative source because it is the system of record for order management, PO creation, and financial close. The supplier portal is the input layer — suppliers report lead times there, but the portal does not know about your order volumes, PO history, or fulfillment windows. It holds a supplier's perspective, not your operations perspective.

Document the designation explicitly: which table is authoritative, what data flows into it, what data flows out of it, and what happens when the two disagree. The disagreement is resolved through a reconciliation process — not by letting whichever system was updated last win by default.

Common objection: "But suppliers update the portal directly — shouldn't that be authoritative?" No — for this specific use case. Supplier portals are input systems, not order management systems. A supplier updating their portal is reporting a number from their perspective. Your ERP is where you manage the actual PO, the fulfillment window, and the financial close. When those two numbers disagree, your ERP's number is the one that should determine what the customer sees at checkout — because that is the number your order management system is operating against.

Second objection: "Our ERP data isn't always current either." Correct. The fix is to make the ERP authoritative AND fix the sync into the ERP — not to split authority between ERP and portal. Splitting authority means neither table is reliable and every displayed lead time becomes a coin flip.

Step 3: Map the Transformation Between Portal and ERP Tables Before Building Any Automated Sync

Most sync builds fail at the assumption stage — before a single line of code is written. Do not assume both tables hold the same data in the same format. They rarely do.

Document these three structural mismatches before you build:

Item-level vs. supplier-level storage. The portal holds one lead time value per supplier. The ERP may hold per-SKU values that differ by item from the same supplier. When these tables sync without a transformation rule, the supplier-level value may overwrite per-SKU values incorrectly, or the wrong SKU may receive the supplier-level default.

Unit difference. The portal uses business days. The ERP uses calendar days. A value of "10 business days" is not the same as "10 calendar days" — and neither is the same as "10 business days stored as 14 calendar days." Without a documented conversion rule that specifies which unit the authoritative table stores and which unit the input system sends, these mismatches silently propagate into displayed lead times.

Buffer application inconsistency. The portal may apply a buffer automatically when reporting lead times (e.g., reporting 8 business days when the actual ship window is 6). The ERP buffer may be configured separately, resulting in two different numbers for the same supplier's actual lead time — even when both systems are technically "correct" from their own configuration perspective.

Worked example:

Supplier portal reports: 10 business days lead time ERP item record shows: 12 calendar days These are not the same number — and they should not be written into the same table without a documented conversion rule specifying which unit the authoritative table stores and which unit the input system sends.

Transformation matrix before coding:

| Field | Portal format | ERP format | Conversion rule | Authoritative unit | |-------|-------------|-----------|-----------------|-------------------| | Lead time | Business days | Calendar days | 5 business days ≈ 7 calendar days | Calendar days |

This step is where most integrations break down — not in the sync execution, but in the assumption that both tables hold equivalent data. Map the mismatch before you build the sync, or you will build a sync that perpetuates the mismatch.

Step 4: Replace Manual Storefront Updates with Event-Driven Sync from the Authoritative Table

The goal is same-business-day updates, not next-morning batches. Once the ERP is designated authoritative and the transformation mapping is documented, replace the manual update loop with an automated event-driven sync.

Event-driven trigger: When the ERP lead time field is updated — whether by portal sync, manual item record update, or EDI 846 transaction — fire a sync event to update the storefront cache or middleware. This closes the sync window to minutes or hours, not the next morning.

Daily reconciliation checkpoint: Set up an automated comparison of portal value vs. ERP value with a defined threshold:

• Divergence of 1 business day: alert the ops team for review
• Divergence of 3 business days: hard stop — storefront displays a warning or falls back to the ERP value, preventing a bad lead time from reaching checkout

Idempotency keys: Prevent late-arriving portal updates from overwriting correct ERP values that arrived in the wrong order. Portal updates older than the current ERP timestamp should not overwrite the current value — otherwise, a delayed EDI 846 transaction can revert a correct lead time to a stale one.

Monitoring: Generate a weekly lead time accuracy report comparing what the storefront shows vs. what the ERP shows for the top 20 SKUs by order volume. This surfaces new dropship lead time integration problems before they surface as customer complaints.

In our implementation work, teams who establish ERP-led authoritative tables and event-driven portal sync see storefront accuracy improve meaningfully within the first sync cycle — because the storefront stops displaying values that were updated days ago.

How to Tell If You Need an Integration Repair or a Process Redesign

Not every dropship lead time mismatch is a sync configuration problem. Some are process problems that sync configuration cannot fix.

Repair signals — sync configuration will resolve it:

• Both the portal table and the ERP table are individually accurate when audited against confirmed supplier lead times
• Divergence is caused by sync config gaps (missing sync trigger, wrong transformation rule, batch lag)
• A defined sync rule can close the gap within 2–4 weeks

Redesign signals — the problem is in the supplier onboarding process:

• Suppliers change lead times without a formal notification (no EDI/API transmission — calling or emailing lead time changes)
• The supplier portal has no automated transmission capability and suppliers cannot or will not use it
• SKU count has outgrown manual update processes entirely
• Both tables are routinely stale because there is no disciplined update mechanism feeding either one

If the supplier portal has no EDI or API capability and lead time changes come in by phone or email, the problem is not a sync configuration issue — it is a supplier onboarding and transmission infrastructure problem. That requires a process redesign, not an integration repair.

The Integration Foundation Sprint is scoped as a 2-week repair engagement covering the audit, authoritative designation, transformation mapping, and sync implementation for up to 50 SKUs. It is designed for the repair scenario. If redesign signals are present, the sprint functions as a diagnostic that produces a clear scope document for the larger engagement — not as a full fix. We will tell you honestly in the sprint which scenario you are in.

For process redesign work involving supplier collaboration infrastructure, see the broader Omnichannel Systems service lane. For related cross-system debugging patterns, see our field guide on diagnosing customer identity write-back failures — the architectural pattern of two systems holding different values with no designated authoritative source shows up across the dropship and marketplace seller operations stack.

FAQ

We show 5–7 days but supplier can't ship for 10 — where did the wrong number come from? It came from whichever reference table the storefront polled last. If the storefront reads from the ERP and the ERP holds a stale value, the customer sees the stale number. If the storefront reads from a middleware cache that hasn't been refreshed, the customer sees whatever was cached. The number is wrong before the order is placed — the fix is not in supplier communication, it is in the sync architecture.

Supplier portal says one thing, ERP shows another, customer sees a third — which is correct? None of them is necessarily correct, and that is the point. Without a designated authoritative table and a documented sync rule, every displayed value is whatever was last written to whichever table the storefront read. The first fix is not to pick the "right" number — it is to establish which table is authoritative and ensure the storefront always reads from it.

Why do orders come through before suppliers confirm lead times in the portal? Because the storefront is reading a cached or ERP value, not a real-time portal value. Suppliers have not confirmed a lead time in the portal, but the storefront is still displaying whatever the last sync wrote. This is a common scenario when suppliers are onboarded to the portal but the ERP-to-portal sync has not yet been configured for that supplier's lead time field.

Updated supplier lead time in the portal but storefront still shows the old number — what's stuck? The sync trigger is not firing. Common causes: the sync runs on a batch schedule (next refresh not yet reached), the middleware cache TTL has not expired, the ERP authoritative field was not updated (portal updated but ERP did not), or the transformation rule is dropping the new value silently. Run the three-system audit from Step 1 to identify which layer is holding the stale value.

Which table should be authoritative — portal or ERP? ERP, in nearly every case. The supplier portal is an input system. The ERP is the system of record for order management, PO creation, and financial close. The dropship lead time the customer sees at checkout should reflect what your order management system is operating against — not what the supplier last reported without operational context. See Step 2 for the full designation framework.

Do we consolidate the two tables or sync them? Sync, not consolidate. The portal should remain the supplier-facing input layer. The ERP should remain the authoritative operational record. The sync flows from portal into ERP, and the storefront reads from ERP. Consolidating into one table creates a single point of failure and removes the supplier's ability to update their own lead time independently. The transformation mapping in Step 3 determines how the sync handles structural differences between the two tables.

Closing

Lead Time Reference Table Divergence is a structural integration problem, not a supplier communication problem or a rounding error. The fix sequence is specific and testable: audit all three systems for one SKU, designate the ERP as authoritative, document the transformation mapping, and replace the manual update loop with an event-driven sync from the authoritative table.

The mismatch does not fix itself. Without a designated authoritative source and a documented sync rule, the portal and ERP will continue to drift apart every time one of them is updated. Manual storefront updates perpetuate the problem by creating a third source of truth that neither system knows about.

See if your dropship integration architecture is ready for a diagnostic and repair sequence — Integration Foundation Sprint.