Delivery Aggregator Orders and Inventory: Why Marketplace Sales Skip Your Stock Counts and Hide Your Real Food Cost

Where Aggregator Sales Disappear Before They Reach Your Inventory

Delivery aggregator orders affect your inventory only when each sale is linked back to a recipe and fed into your stock system. When a marketplace order bypasses that link - because the platform does not connect to your POS, or the integration only exports data out - the ingredients it consumed are never deducted, so your on-hand counts and food cost drift steadily away from reality.

This is the gap operators hit first. One multi-site Poké chain running a central production kitchen was in talks with several delivery marketplaces while running its tills on a mainstream POS, only to find that some of the platforms it was evaluating did not connect to that POS at all. Every bowl sold through those channels left the kitchen, but no system deducted the proteins, bases and toppings it used. The central kitchen kept producing to a plan that its own sales data quietly contradicted.

The cost of that blind spot is measurable. One multi-channel operator found that roughly 30% of order revenue - the share flowing through delivery channels - was invisible to the back-of-house system, because those orders never reached the inventory engine. When a third of your volume does not deplete stock, variance reports, reorder suggestions and theoretical food cost are all built on a partial picture. The counts look wrong, and no one can say why.

The fix is to close that link before you trust another count: every delivery channel needs a live connection that carries each order into recipe-level stock depletion, so a bowl sold on a marketplace draws down the same proteins, bases and toppings as one sold at the till. Once every channel deducts stock, the roughly 30% that used to vanish reappears as real depletion, and your variance, reorder and food-cost reports finally run on the whole business rather than the dine-in slice of it. This is the gap Supy is built to close: it connects your POS and delivery aggregators and maps each menu item to a recipe, so marketplace orders deplete inventory automatically instead of leaving a blind spot in your counts.

Why Modifier and Build-Your-Own Orders Deduct the Wrong Ingredients

Even when aggregator sales do reach your system, high-modifier menus are where the deductions go wrong. A build-your-own bowl or burrito is not one dish - it is dozens of ingredient combinations sold under a single menu name. If the delivery menu is not mapped to recipes at the modifier level, every order deducts the same default ingredients no matter what the guest actually chose.

Operators feel this pressure at the till. One quick-service group found that making staff select every ingredient choice on a high-modifier item was too slow for service, so they built one recipe per menu item based on the single most-common choice - the base ordered on about 75% of tickets - and adjusted stock by hand for the exceptions. It works until it does not: the manual adjustments slip during a rush, and the 25% of orders that took a different base slowly poison both the stock count and the recipe cost.

This is the deduction problem in miniature. When a menu item maps to recipes at the modifier level, each sale - dine-in or delivery - depletes the exact ingredients it used, including the swaps and add-ons, so the count reflects what really left the shelf. That mapping is also what lets a delivery order and an in-store order of the same dish consume stock correctly from the same recipe. Without it, the more your menu lets guests customise, the faster your numbers rot.

The Food Cost Number Delivery Commission Quietly Breaks

Delivery does not just distort your stock counts - it distorts your food cost percentage, and in a direction that flatters the number. Marketplace platforms take a commission of roughly 25-35% of the order value before you are paid. If you calculate food cost against the gross order value shown on the platform, rather than the net revenue you actually keep, every delivery sale looks more profitable than it is.

The maths is unforgiving. A delivery brand that reports 28% food cost against gross revenue is, at a 30% take-rate, actually running closer to 40% food cost against the revenue it retains. That is the difference between a healthy channel and one that loses money on every order - and it is completely hidden if your reporting never separates gross from net. Ghost and delivery-first brands hit this hardest, because delivery is not one channel among many; it is the whole business.

The fix is to cost delivery items against retained revenue and to watch that channel separately from dine-in, the same discipline you would apply when you isolate theoretical versus actual food cost variance by site. A blended food cost across channels averages the delivery problem into invisibility; a per-channel view surfaces it.

One-Way Export vs Two-Way Sync: What to Confirm Before You Trust an Integration

Because so much of this depends on data actually flowing into your inventory system, the direction of a POS or aggregator connection matters more than whether one exists at all. One operator was told during the sales process that his POS would automatically feed live sales into his new inventory platform, then discovered after signing that the integration only exported data out - the only way in was a manual file upload. He said plainly he would not have signed up had he known.

Third-party limits make this worse. Some POS and aggregator providers refuse open API access, or cannot supply the SKU and modifier detail an inventory system needs to deduct accurately - a constraint the operator cannot resolve alone. Before you commit, confirm the connection is a live two-way sync, not export-only; that it carries item-level and modifier-level detail, not just order totals; and that it warns you before a duplicate manual import double-depletes stock. These are the same questions that decide whether a POS feed will keep your inventory accurate or quietly corrupt it.

This is also where breadth of native connections earns its keep. A platform that already covers POS, online-order and aggregator categories across 75+ integrations is far more likely to have a real two-way link to the specific platforms you run than one that has to scope a custom connector for each.

To tell whether this is happening in your own operation, reconcile a single delivery-heavy day: pull the orders each aggregator reports, then check whether those exact sales appear as stock depletion and whether the ingredients deducted match what those dishes actually use. If delivery volume is not moving your counts, the feed is broken or export-only. If your food cost report shows one blended number, rebuild it per channel against net revenue and see where delivery really sits. And if your high-modifier items map to a single default recipe, that is your first fix - map to the modifier level before you trust another count.

Getting delivery right is not a marketing project; it is a back-of-house data problem. When aggregator sales flow into recipe-level depletion and are costed against the revenue you keep, delivery becomes just another channel you can actually manage - not a hole in the middle of your inventory and food cost. Supy connects POS and delivery aggregators, maps menu items to recipes at the modifier level so sales deplete the right ingredients, and keeps channel-level food cost honest.