POS Sales That Do Not Match Your Inventory System: The Two Root Causes and How to Reconcile Them

First, Pin Down Which of the Two Mismatches You Have

When your point-of-sale system and your inventory platform disagree on what you sold - when your POS sales are not matching inventory - the cause is almost never random. In nearly every case it is one of two things: sales started flowing before your recipes were mapped, or a later change on the POS quietly broke a mapping that used to work. Name which one you have before you fix anything.

That single question - did the mismatch exist from day one, or did it appear after go-live - splits almost every case cleanly, because the two causes need opposite fixes. A day-one gap means the links were never finished. A drift that shows up months later means something on the POS moved and the inventory side never heard about it. Left unnamed, a revenue mismatch can sit unresolved for four months and turn a dashboard operators paid for into one they stop opening. So start with the decision below, then jump to the matching section.

Root Cause 1: Sales Started Flowing Before Your Items Were Mapped

This is the most common reconciliation failure at onboarding. The sales feed gets switched on to hit a go-live date, but the recipe and menu-item mapping is not finished yet. Every ticket for an unmapped item still lands in the system as revenue, but because that menu item is not linked to a recipe, no ingredients are depleted for it. Sales look roughly right while stock quietly stops moving, so theoretical usage and actual usage drift apart and your cost numbers follow them down.

The fix is to finish the links, not to re-import the data. Every menu item your POS can sell has to point at the recipe it consumes, so that one sale deducts the correct ingredients, modifiers included. Supy's recipe and menu-item linking is what closes this gap: link each sold item to its recipe once, and depletion starts flowing the moment a ticket arrives. Do this for the full menu before you trust a single variance report, and re-count once so the system has an accurate opening baseline to measure against.

Root Cause 2: A POS Change That Never Reached Inventory

The second cause looks different because everything used to reconcile. Then someone on the POS side renames a revenue centre, adds a new PLU for a seasonal item, or splits one menu item into two. None of those edits are wrong, but the inventory side still expects the old names, so the changed items now land unmapped and the numbers separate again. Nobody broke anything on purpose; the two systems simply fell out of sync.

Reconciling this one means re-mapping what moved, then confirming it. The Integrations screen shows your incoming sales imports, so you can filter for the items that came in without a mapping and fix exactly those instead of rebuilding everything. For providers that use revenue centres, you can map several centres within one branch to a single inventory location, which is what catches a renamed or newly-added centre. After you re-map, trigger a manual re-sync and check the import history to confirm the previously-unmapped tickets now land correctly.

The Check Everyone Skips: Does Your Integration Actually Flow Both Ways?

Before you blame any mapping, confirm sales are even arriving. Some connections that get called a POS integration only export data out of the POS; they never write sales back into inventory. If that is what you have, every ticket has to be uploaded by hand and the automated feed you expected does not exist, so no amount of re-mapping will ever reconcile it. This is the trap operators discover only after go-live, when they realise the promised live feed was one-directional all along.

Confirm the direction first: over a normal week, does the sales import count roughly match the tickets your POS rang up? If it reads zero while the POS shows a thousand-plus tickets, you have a one-way feed, not a mapping problem. The fix is a genuine two-way connection - Supy connects to 75+ integrations across the major POS platforms - and where a regional POS has no native connector at all, the honest interim answer is a scheduled managed import, not a promise of instant live sync. If you want the wider context, these mismatches are one slice of the broader POS data-quality gaps that quietly distort inventory. Rule the direction out before you spend an afternoon re-checking mappings that were fine all along.

Reconcile in This Order

Work the three checks from the outside in, and stop at the first one that fails. First, confirm the feed is two-way - if sales never import, fix the connection before anything else. Second, if the mismatch was there from day one, finish the recipe-to-menu-item links across the full menu and re-count for a clean baseline. Third, if it used to reconcile and drifted later, find the recent POS change, re-map the item or revenue centre it touched, and re-sync. Name the branch you are in, make the one move that fits it, and confirm against the import history before you trust the dashboard again.