Restaurant margin report from till, purchasing and bookkeeping

The idea is one place that pulls three streams together: what the till sold, what you bought from suppliers, and what the books record. From them it shows margin by dish, by category and by week, instead of one number at month end. Data arrives by export files or official interfaces, whichever each product genuinely supports.

I am keeping vendor specifics out of this page on purpose. What a given till or bookkeeping product exposes changes, so I check its own developer documentation for your products before I design the connection.

What does it look like?

A weekly screen with sales per item from the till, estimated cost per item from recipes and the latest purchase prices, and the gap between them. Click a dish and you see its recipe lines, the last invoice price of each ingredient, and how that price has moved. A second screen lists purchase invoices and whether each one has been matched to a supplier and a bookkeeping category.

How is it built?

• Sales import. Daily till export, by file drop or a documented interface, stored raw and then normalised into items, quantities, discounts and voids.
• Purchasing. Supplier invoices entered or uploaded, with line items mapped to ingredients, units and pack sizes. Conversion matters here: a case of 12 litres becomes cost per millilitre.
• Recipes. Each dish lists ingredients and quantities, with a waste allowance you set.
• Margin engine. Plain code that joins the three and keeps the history, so a price change does not rewrite last month.
• Bookkeeping side. Either a documented direct connection or a generated import file in the exact layout your bookkeeping software accepts.

What about card payments through Stripe?

If you take online orders or deposits through Stripe, you can export payments, fees and payouts yourself and turn them into bookkeeping entries without a paid connector. The pieces that make this correct are the ones people skip: matching each payout to the individual payments inside it, booking fees separately, handling refunds and disputes, and keeping currency and dates straight. I would build it from Stripe’s own reports and API after reading its current documentation, and test against a month of your real payouts before trusting it.

Where does it go wrong?

Recipes that nobody updates, supplier items renamed between invoices, till items sold as combos or modifiers that hide the real dish, and tips or service charge mixed into sales. The tool surfaces unmapped items rather than silently dropping them.

When is off-the-shelf better?

Several restaurant inventory and cost-control products exist, and if one fits your till out of the box, it will be quicker than a build. Custom makes sense when your mix of systems has no off-the-shelf link, or the monthly connector fees add up to more than the one-off cost.

What I need from you

• Sample exports from the till, a few supplier invoices and a bookkeeping export.
• Your recipes, even rough ones.
• Your bookkeeper’s view on the import format and on who approves entries.