Restaurant Cost of Goods Sold: What Reaches the Ledger

What Actually Reaches Your Ledger (and What Doesn't)
A restaurant inventory-to-accounting integration posts documents, not cost calculations. Supplier invoices, goods received notes and credit notes flow into your accounting system, each carrying a live posting status. Your cost of goods sold (COGS) and your sales revenue do not - they stay inside the inventory platform as reports. Knowing which is which is the entire job at month-end.
Most finance teams assume "integrates with my accounting system" means "posts my period-end cost journals." It does not, and the gap is where trust in the numbers breaks. Here is the honest scope of a restaurant inventory accounting integration and where each figure actually ends up.
| Document or figure | Reaches your accounting system? | Where it lives |
|---|---|---|
| Supplier invoices and goods received notes | Yes, with posting status | Your ledger |
| Credit notes and supplier returns | Yes, with posting status | Your ledger |
| Cost of goods sold (COGS) | No | Supy dashboards and reports |
| Sales revenue | No | Your point-of-sale system |
This is not a Supy quirk - it is how the category works. Supy's accounting connectors sit inside its 75+ integrations alongside Xero, QuickBooks, Zoho Books and Wafeq, and every one of them pushes documents and posting status rather than a finished cost journal. Plan month-end around that fact and the rest of this article is a checklist. Ignore it and you will spend every close arguing with your own accounting system.
Why Your Food Cost Percentage and the Ledger Disagree
A group expecting cost of goods sold around 25% opens the accounting system, sees 20%, and stops trusting the numbers. Nothing has been stolen. The ledger only ever received purchase invoices - never the cost of what actually sold - so it is answering a different question than your recipes are.

Two things drive the gap, and both are timing, not error:
- Theoretical COGS updates daily as you buy and sell. Actual COGS depends on a stock count, and a monthly count is too slow to steer daily cost decisions. Our guide on theoretical food cost versus actual walks through why the two diverge.
- A day or two of sync lag means the inventory platform and the ledger are rarely looking at the same moment, so a snapshot comparison always shows a mismatch.
The fix is not to force the two numbers to match. It is to know which one answers which question: the ledger tells you what you paid suppliers, and Supy tells you what those goods cost as they sold.
The Accounting Setup That Silently Blocks Posting
The most common reason an invoice never reaches the ledger is not a bug. It is a missing setup step, and it fails silently - no error, no warning, just an invoice that quietly never posts until month-end refuses to reconcile.

Three preconditions have to be true before a single invoice posts:
- Every item needs an accounting category. Miss it and that item's invoices never post - one operator had to assign categories across roughly 800 items before their close would tie out.
- Every supplier must be mapped on both sides. An unmapped supplier posts nowhere and reports nothing.
- The integration has to be switched on. It has been found disabled at the start of onboarding more than once, blocking the entire close before anyone noticed.
Verify all three before your first period close, not during it. A test post of one invoice, confirmed on both sides, is the cheapest insurance you will buy all quarter.
Posting Across Legal Entities Without Hitting the Wrong Books
Multi-brand and central-kitchen groups carry a second trap: an invoice can post to the wrong legal entity. The cost is real - one entity's month-end will not tie out, and nobody knows why until someone traces it back to a mapping set once at go-live and never checked. Groups running a central kitchen hit this hardest, as our guide on where a central kitchen breaks ERP inventory modules shows.
| Branch | Legal entity in the ledger | Mapping status |
|---|---|---|
| Harbour View | Central Kitchen Holdings | Verified |
| Airport Outlet | Retail Entity | Verified |
| North Branch | Retail Entity | Missing - invoices posted to the wrong books |
When a branch is mapped to the wrong entity, the fix is mechanical, not a support escalation: unpost the affected invoices, correct the venue-to-entity mapping, then repost so the export re-fires against the right books. Do the mapping check at go-live for every branch and entity, because a group only ever discovers it the hard way, at close.
Redesign Month-End Around What the Integration Can't Do
Once you accept that the integration posts documents and not cost journals, month-end stops being a monthly argument and becomes a fixed sequence. The integration handles the invoices; you own the two steps it cannot.

- Pull actual COGS from your reports after the count. In Supy the numbers are already there in the interactive dashboards, in one-click spreadsheet exports by site and dish, or through the inventory platform API if you feed a data warehouse.
- Confirm every invoice posted on both sides. A document can read as posted in one system and unsent in the other, so check both rather than trusting one.
- Book the cost journal by hand from that COGS report. This is the step no integration in the category does for you.
- Check entity and venue mapping before you reconcile, not after.
- Reconcile and close.
Run that same order every month and the 5-point gap disappears - not because the systems finally agree, but because you stopped asking the ledger a question it was never posted to answer.
Your 60-Second Self-Check
Before your next close, work out which of these is already true in your operation:
- Your accounting system's food cost looks lower than your recipes say it should - your cost journals are not being posted, only your invoices.
- You only find unposted invoices when month-end will not reconcile - your item or supplier mapping has gaps.
- One entity's numbers never tie out - a branch is mapped to the wrong books.
If any of these sound familiar, the answer is not more integration. It is deciding, on paper, what your integration posts and what you post by hand, then wiring your close around it. Start by pulling one month of actual cost of goods sold from your reports and comparing it line by line against what your ledger received - you can sanity-check your target with a food cost calculator before you do.


.jpg)

