Every restaurant runs on three systems that each hold a different piece of the same picture: the POS for what sold, the accounting software for what was paid, and the inventory system for what was actually used. Each one is accurate inside its own boundary, and each one is almost useless on its own when the question is where margin is going.
The operators who hold tighter food cost numbers have figured out how to integrate POS, inventory, and accounting in a restaurant so the three systems talk to each other. When sales, purchases, and consumption can be cross-referenced in the same place, supplier price increases stop slipping through and over-portioning stops compounding for a quarter before anyone notices.
This article walks through what each system holds, where the gaps between them tend to sit, and what a connected flow actually looks like from the moment a dish is sold to the moment its ingredient cost is reconciled against the invoice that paid for it.
What POS Holds and Where It Stops
The POS is the system of record for sales. Every order placed, every modifier rung in, every void, every comp, every time a server fired a course to the kitchen, all of it lives in the POS data. Total revenue by day, by category, by hour, by server, by location. Average ticket size. Item-level sales velocity. The POS knows, with high precision, what the restaurant sold and for how much.
What the POS does not know is what each of those sales actually cost to produce. It can store a recipe-linked menu, but unless the recipes are kept current and the ingredient costs behind them are updated as supplier prices move, the cost side of the POS report is a snapshot of an old reality. Most POS reports show a theoretical food cost percentage based on whatever recipe costs were entered at setup. That number drifts further from reality every week the recipes are not refreshed.
The POS also stops at the point of sale. It does not see what came in through the back door, what got prepped and wasted, what walked out, or what sat in a walk-in until it spoiled. Anything that happens between the supplier invoice and the customer order is invisible to the POS.
What Accounting Holds and Where It Stops
The accounting system is the system of record for money in and money out. It holds the supplier invoices, the line items, the payments, the VAT, the payroll, the rent, the utilities. It knows exactly what was spent and what was billed.
The level of detail varies depending on how invoices are processed. In an operation where invoices are entered as a single summary line, the accounting system shows that €4,800 was paid to a meat supplier last week. In an operation where invoices are processed line by line, the same accounting system shows that 90kg of beef mince was purchased at €12.40/kg, alongside chicken thighs at €6.20/kg, and so on down the invoice.
Line-level invoice data is where the real visibility starts, and it is exactly what most restaurants do not capture. Without it, the accounting system can tell you food cost as a percentage of revenue, but it cannot tell you which ingredients moved in price, which suppliers raised quietly, or which categories drove the increase. The accounting system stops at the totals, and the question of why those totals moved sits one layer deeper than accounting can see on its own.
What Inventory Holds and What Only It Can See
The inventory system, when it is being run properly, holds the third piece: what was physically counted as on hand at the start of the period and at the end of it. Combined with what was purchased in between, this is what tells you what was actually used.
Actual usage is the only number that closes the loop. The POS says the restaurant should have used 78kg of beef based on what sold. The accounting data says 90kg was purchased. The inventory count says 4kg is left on the shelf when there was 6kg at the start. That means 92kg was actually used, against a theoretical of 78kg. The 14kg gap is variance, and variance is where the margin story actually lives. It is over-portioning, waste, spoilage, theft, mis-recipes, or a combination of all of them. None of it is visible without the inventory count.
Inventory is also the only place where supplier price changes get reconciled against what the dishes are actually costing today. When ingredient costs cascade into recipes properly, the system can show actual COGS at the dish level, not just at the category level the accounting software produces.
The catch is that the inventory system is only as accurate as the data flowing into it. If it is not connected to the POS, it cannot calculate theoretical usage. If it is not connected to accounting, it cannot keep ingredient costs current. Without those connections, even a well-run inventory count produces variance numbers that nobody can act on because nobody can trace where the variance came from.
The Gap Between Systems and What Gets Lost There
The gap between these three systems is where most of the unexplained margin loss sits. A supplier raises the price of fish by 8%. The invoice clears accounting and gets paid. The POS keeps reporting the same theoretical cost per dish because the recipe was never updated. Inventory shows variance at the end of the period, but the variance gets recorded as “high” without anyone tracing it back to the price movement. Three months later, the fish category has quietly absorbed thousands of euros that nobody saw moving.
The same gap explains why food cost surprises tend to show up at month end rather than during the month. The data exists in all three systems the whole time. What does not exist is the integration that lets a single person see, in one view, that the price of fish moved on the 8th, that recipe cost did not get updated, that POS sales of fish dishes continued at the old margin assumption, and that the resulting variance is structural rather than random.
A connected flow is the only thing that surfaces this in time to act. Pieces like supplier price tracking, inventory variance analysis, and food cost benchmarks only become operational once the underlying systems are integrated. Without the connection, each one stays a report that explains what happened weeks after it mattered.
What a Connected Flow Looks like End to End
When the three systems are integrated, a single sale traces cleanly through every layer of the operation.
1. The first layer is the POS. A customer orders a fish main. The sale records the dish, the price, the time, and the location.
2. The second is the recipe. The dish maps to a recipe with defined quantities of fish, oil, herbs, garnish, side. Each ingredient carries a current cost, fed by invoice data rather than a setup-time snapshot.
3. The third is consumption. Multiplied across every sale of that dish in the period, the recipe defines a theoretical ingredient usage. The POS provides the sales volume, the recipe provides the per-portion quantity, and together they produce the number that says “based on what was sold, this is what should have been used.”
4. The fourth is the invoice. Supplier invoices arrive in accounting and get processed line by line. Each line item updates the cost of the ingredient it represents, and the updated cost cascades into every recipe that uses it. If the price of fish moved on Tuesday, the dish cost reflects it on Wednesday.
5. The fifth is the stock count. At the end of the period, physical inventory is counted. The difference between what was on hand at the start, what was purchased, and what is on hand at the end produces actual usage. Actual usage is compared against theoretical usage from the POS-recipe side, and the variance is visible at the ingredient level. The fish gap is no longer hidden inside the food cost percentage. It is a specific number on a specific ingredient with a specific cause.
That is the food cost tracking system that operators with tight margins are working from. None of the components are exotic. The work is in making the data move between them.
Which Integrations Matter Most
Three integrations carry most of the weight when you are deciding where to invest first.
-
The first is POS to recipe and inventory. Without sales data flowing into the inventory system automatically, theoretical consumption has to be calculated by hand, which means it gets calculated rarely and variance loses its meaning. This is the foundation. Without it, the rest of the stack cannot do its job.
-
The second is accounting to recipe. Supplier invoices need to flow into the system that holds the recipes, and they need to flow at line-item detail rather than as summary totals. This is what keeps recipe costs current as supplier prices move, and it is what surfaces price increases in time to question them. The work involved in catching supplier invoice errors and price drift is largely automated once this integration is in place.
-
The third is the inventory system to both of the above. Inventory is the layer where everything reconciles. It needs the POS data to compute theoretical usage and the accounting data to keep costs current. If inventory only connects to one side, the variance numbers it produces are incomplete.
For multi-location groups, these three integrations matter even more, because the cascade failure of an out-of-date recipe multiplies across every site that runs the same menu.
How to Evaluate an Integration When Choosing Software
Vendor demos are designed to show what is possible. The questions worth asking are about what is automatic versus what is manual.
A short list to put to any vendor when integration is on the table:
1. What POS systems and accounting systems do you support natively, and which ones require workarounds?
- Native integrations stay current as the upstream tool updates. Workarounds tend to break quietly.
2. When a supplier price changes on an invoice, what happens to the recipe cost?
- If the answer involves a manual review step, the integration is not closing the loop.
3. How is line-item invoice data captured?
- If the answer is OCR plus manual review, ask what percentage of invoices need a human to correct them. The number matters.
4. What does the variance report show at the ingredient level, not the category level?
- If the system cannot show variance per ingredient with the price movement and consumption gap attached, the underlying integration is not deep enough.
5. How does the system handle multi-location?
- Recipe cost cascade across sites is where most integrations weaken, because the same menu deployed across five locations needs the cost update to propagate everywhere without a manual sync.
Stockifi sits in this stack as the integration layer between the POS, the accounting system, and the inventory operation. The work can also be done with a combination of other tools and a disciplined operations team. The point is that the integration has to exist somewhere. The restaurants that hold their margin year on year are the ones where it does, and the ones losing two or three points of food cost a year are almost always the ones where it does not.
When you look at your own operation, can you trace a single dish from sale to invoice to actual consumption without leaving one of three systems and stitching the data together by hand?