Marketplace seller software: trace a stock-sync mismatch

When marketplace seller software shows different stock quantities in the seller's source system and marketplace account, the discrepancy does not by itself establish a software fault. Linnworks or Veeqo might be the source system; Amazon Seller Central or eBay Seller Hub might be the destination. These are examples of existing systems to investigate, not recommendations to replace them.

The deliverable is a support case that identifies what the evidence establishes, what remains unknown and which configuration needs attention. Preserve the relevant records and distinguish the inspected update from any wider history. The case should support a safe review without treating the discrepancy alone as proof of a software fault.

Capture the configuration behind the mismatch

Preserve the configuration relevant to the disputed update before changing it. A corrected setting may remove the symptom while also removing evidence needed to explain it.

Record whether the configuration you can inspect is the one used at the time, or only its current replacement, and identify any historical version you cannot retrieve.

Start with the affected source record and marketplace listing. Keep their identifiers, account context and recorded times together, so a reviewer can distinguish a wrong destination from a late update to the right destination. The record should make clear which fields can be inspected and which remain unavailable.

The field names and available records depend on the installed connection. Do not assume that a Linnworks connection, a Veeqo connection and a manually uploaded file expose the same evidence. Where a setting or historical version cannot be retrieved, name that gap rather than reconstructing it from memory. A screenshot of the current configuration is useful, but cannot establish what an earlier update used unless configuration history supports that connection.

Check identity before comparing quantities

First establish that the records refer to the same intended item and destination. Compare the source product reference, the reference carried in the attempted update and the marketplace listing reference.

Include the marketplace account, because matching text in a product identifier does not establish that the update reached the intended account.

Check variant-level mappings where the affected product has variants. A parent product record and an individual sellable variant are not interchangeable comparison units. Preserve the relevant approved product record so a reviewer can see which listing the stock update was meant to affect.

Then inspect what each quantity means. A source field labelled stock on hand may differ from a quantity available to sell; returned stock may still await a decision before it becomes available. Do not call those differences a synchronisation defect until the connection's documented quantity rule has been checked. The quality checklist can help keep that evidence distinct.

Use these questions to separate an identity problem from a quantity-rule problem:

The investigation should identify the rule actually used, not prescribe a universal stock formula. Keep the selected source field and any documented adjustment distinct from the mapping, so a reviewer can see whether the unresolved question concerns identity or quantity. The final comparison should not treat unlike records as evidence of a defect.

Reconstruct the attempted stock change

Build a chronological record of the disputed update. Preserve the original timestamps and timezones; add a normalised view if needed, without overwriting the original evidence. Two exports taken at different times may describe different stock positions even when neither is wrong, so retain when each record was captured.

Keep the attempted change separate from the marketplace response and the later observed listing. A record that a change was attempted is not the same evidence as a record showing the intended destination changed. An exception-queue view can help keep those events separate.

Where an order or return triggered the stock change, retain that reference alongside the stock trail. Keep order and money events as separate context rather than using a refund label as proof that stock was made available. For related uncertainty about possible failure modes, see stock risk scenarios.

If a response is missing, the update's outcome remains unknown. If staff corrected the listing manually, preserve that correction separately: it establishes a later action, not the cause of the earlier discrepancy. Keep both limits visible when recording what the evidence establishes and what still needs an update record or other support evidence.

Test the explanation against the records

A mapping defect and an approval delay require different evidence. Inspect the point where their explanations diverge rather than repeatedly comparing final stock figures.

The comparison should use the saved configuration and the records for the attempted update, rather than treating the final quantity alone as an explanation for what happened.

For a suspected mapping defect, follow the destination identifier from the saved mapping into the attempted update. If those records point to a different listing, the evidence supports a destination problem. If the correct listing was addressed, that particular explanation is weakened, although other configuration questions may remain unresolved.

For a suspected approval delay, inspect the approval condition and the records showing when it was satisfied. A source change awaiting approval is different from an approved change that was submitted but did not reach the destination. Without the relevant approval or submission record, leave the distinction unresolved rather than treating either explanation as established.

A timing explanation needs the configured update mechanism and a comparable sequence of observations. Do not prescribe a faster synchronisation interval simply because two exports differ. First establish whether they were taken before and after the relevant attempt. Label each conclusion as an observation, an interpretation or an unknown, and attach the evidence reference to each observation.

Explain which additional record would settle an unknown. Avoid assigning responsibility to a supplier, marketplace or staff member on the basis of the final discrepancy alone. Keep the evidence and its limits explicit, as in a review of failed test reruns, rather than turning an unverified explanation into a conclusion.

A worked mapping case with a bounded conclusion

Consider a fictional seller using Linnworks as the source system and Amazon Seller Central as the destination. The seller reports that a listing remained unchanged after a stock correction.

The investigation preserves the affected source reference, the intended listing reference, the saved mapping and the attempted update as separate records for review.

The references below are synthetic labels, not real product or customer records:

The records support a specific explanation for the inspected attempt: it was addressed to the wrong listing. They do not establish that every earlier mismatch had the same cause. In an isolated reproduction, the investigator uses the captured mapping and synthetic references, and the prepared output again addresses LISTING-B.

Changing only the mapping in that isolated test makes the prepared output address LISTING-A. The support case can conclude that the captured mapping reproduces the wrong-destination defect. It can request review of the live mapping and any other records using it, while leaving historical impact unresolved. The test does not authorise a production change or establish that all affected stock has been corrected.

Reproduce the suspected defect without live actions

Use a bounded reproduction only when it can answer a specific remaining question. The purpose is to inspect the mapping or prepared output, not to run a live purchase or make an experimental stock change on a customer-facing listing.

Keep the test within the limits of the captured evidence and the question it is intended to answer.

Write down the expected input, expected output, test owner and stop rule before starting. A useful sequence is:

If isolation cannot be demonstrated, stop the reproduction and hand over the captured records instead. Do not describe a proposed test as completed, or a locally prepared output as evidence of a successful live marketplace update. Keep the test state and any limits clear, as in a state-based implementation rollback.

Keep the support case safe and flag separate impacts

A support case may contain order references or screenshots that identify customers. Apply the UK GDPR and Data Protection Act 2018 when personal data is involved; the definition of personal data is set out in the UK GDPR.

Follow the seller's data protection guidance when deciding what the recipient needs and how the material may be shared.

Remove customer names, delivery addresses and unrelated order details where they are not needed to investigate the mapping. Do not include passwords, access tokens or other credentials in attachments. Keep an unaltered original in its controlled location and identify any redaction or substitution in the shared copy. For a separate accounting question, use the appropriate VAT records guidance.

The following impact referral checklist identifies consequences that may need a separate specialist. It is not a compliance verdict or a software-selection score. Use it to route separate questions without allowing the stock-mapping finding to answer them or stand in for a decision by the relevant owner.

Do not let an identified stock-mapping defect stand in for resolution of these separate matters. Keep each referral distinct from the mapping investigation and identify the relevant owner, so the stock finding does not substitute for a decision on another impact or imply that the separate question has been resolved.

Hand over a reproducible case, not a tool recommendation

The hand-off should let a support engineer or internal owner locate the same records and understand the same uncertainty. Include enough evidence to retrace the inspected attempt, while making clear which records are missing and which conclusions apply only to that attempt.

Attach the configuration evidence, chronological trail and reproduction result, rather than relying on a description such as stock sync broken. The vendor due diligence approach can inform what to ask when seeking support, but the case should remain focused on the records and uncertainty under review.

Finish with a compact case note:

A cause may be supported for one attempt while the broader history remains unresolved. Keep that distinction visible. The useful outcome is a precise correction request or evidence request, not an unsupported recommendation to replace the seller's software.