Practical guide

Inventory sync mismatch: investigate one event before retrying everything

Last materially reviewed 2026-09-24

Quick answerFind one identifiable event that differs between systems, preserve both states and establish its expected behavior before attempting a repair.
What to know

Describe the mismatch as a specific symptom

Write down the item, order identifier, systems involved, expected event and observed result. A statement such as the stock is wrong hides whether the problem is a missing order, delayed receipt, duplicate adjustment or a difference in quantity definitions. In a fictional case, an online store shows eight available units while the inventory screen shows ten on hand. Before treating that as a technical failure, check reservations, locations and timing. Two legitimate fields can differ without either being broken.

What to know

Diagnose the event path and its owner

Follow the record from the system that owns it to the destination that should receive it. Check the documented trigger, filters and plan capabilities. Did the relevant event occur, or was the record merely saved in a draft state? Is the expected update supported, or is it an assumption? Read the official integration documentation and inspect visible error information. Avoid sharing private order contents in public support forums. A concise sanitized record of the failing transition is usually more useful than a screenshot of the entire customer database.

What to know

Choose the smallest authorized repair

Do not repeatedly reconnect applications, import the same file or replay all historical orders. After an uncertain attempt, first establish whether the destination already received the event. Ask the vendor how its supported retry handles duplicates and which side should be corrected. Preserve exports or screenshots of the relevant non-sensitive state according to your data policy. This publication does not provide instructions to bypass permissions or alter financial records. The appropriate owner should approve any correction affecting an actual order or accounting entry.

What to know

Verify both the target record and its neighbors

After a supported repair, check the specific event and a small set of related records for unintended duplicates or changed quantities. Document what changed and what remains unknown. A green status badge is not enough if the original order still disagrees. If the cause remains uncertain, pause the affected automated path through its authorized controls and maintain an explicit exception list rather than inventing a reconciliation. Escalate the bounded case to the provider, including the plan, integration and event timing, so another person can investigate without repeating the entire history.

Continue when useful

Next: Define what inventory and accounting integrations are allowed to change

Write down which system owns each record and what event triggers a transfer before enabling a two-system workflow.

Open Define what inventory and accounting integrations are allowed to change →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. inFlow and QuickBooks Online integration — Merchant documentation · inflowinventory.com · Merchant-controlled · checked 2026-09-24
  2. inFlow data export scope and exclusions — Merchant documentation · inflowinventory.com · Merchant-controlled · checked 2026-09-24