Floreant POS in Mexico: what free open source really costs
Free software is not the same thing as a free system. Floreant is real and it works, and the bill it sends arrives as your own time instead of a monthly invoice.
Home / Blog / Restaurant software inventory: two kinds, and which to buy first
Most owners search for one kind of stock software and actually need the other one first. Knowing which is which saves a New Zealand kitchen both money and staff hours.
Agha Shah Zaman · Co-founder, Get Menu · 2 September 2026
Type restaurant software inventory into a search box and you get two products wearing one name. One counts what is sitting in your fridge and your dry store. The other counts what you can still sell tonight before the page has to say sold out. They solve different problems, they cost different amounts of staff time, and most kitchens need the second one working before the first one is worth buying. This article separates them and explains how to choose.
This is the version most people picture. You enter suppliers and ingredients, you build recipes so the software knows a burger uses 180 grams of mince, you count the store room on a schedule, and the system compares what should be there against what is.
Done properly it is powerful. It tells you what your food cost really is, where portions are drifting, and which dishes quietly stopped being worth cooking. Nothing else gives you that.
It also has a well known failure. The comparison only works if somebody counts, and counts honestly, every week, forever. In New Zealand that habit has a price you can put a number on. The adult minimum wage is $23.95 an hour from 1 April 2026, and a real stock count in a small restaurant is rarely under two hours. A senior person doing it costs considerably more. That is a genuine weekly cost against a saving that is often described but rarely measured.
We wrote about why this kind of system decays in the guide to inventory tracking for restaurants, and about how to judge the suppliers in the piece on restaurant inventory management software.
The second kind never asks about mince. It asks a simpler question, and it asks it every few seconds during service: is there still one of these left to sell?
That number is not in your store room. It is the twelve portions of lamb shank the kitchen actually prepped this morning, the last four servings of the fish, the one bottle of a wine somebody ordered by mistake. It changes as orders come in, and if the ordering page does not know it, you sell things you do not have.
Selling something you cannot deliver is expensive in a way that never shows up as food cost. Somebody has to phone the customer. The order gets rebuilt or refunded. The person who was looking forward to that dish decides, quietly, to try somewhere else next Friday.
"Owners tell me their stock system failed and then describe something that never went wrong in the store room at all. They sold a dish that ran out at seven. That is not an inventory problem in the accounting sense. It is that the menu and the kitchen were looking at two different numbers."
— Agha Shah Zaman, co-founder of Get Menu
Three reasons, and they are practical rather than theoretical.
It costs nobody any time. Counts fall automatically as orders are placed. Nobody has to weigh anything or open a spreadsheet on a Sunday.
It is visible to your customers on the day it works. Food costing pays back over months. A dish that greys itself out at zero pays back the same evening, in a phone call nobody had to make.
And it gives you the data the first kind needs. Once you know exactly what sold, in what combination and with which options chosen, ingredient level stock control becomes a much shorter job. Working the other way round, an ingredient system with guessed sales underneath it is guessing twice.
Get Menu is an ordering system, and its stock features are the second kind. They are worth listing exactly, because the useful thing here is knowing the edges.
Counts per item. Set how many portions exist and the number falls as orders come in.
Counts per option too. Options and add-ons carry their own prices and their own counts, so running out of one sauce takes the sauce off the list rather than the whole dish.
Sold out flips itself at zero. Nobody has to be watching. The dish greys out on the menu the moment the last one goes.
A warning before it happens. Low-stock alerts fire once, when the level you set is crossed, not on every order after it.
Cancel an order and the stock comes back. No manual correction, no forgetting.
A movement history. Every count on the screen is explained by a list of what changed it: orders, cancellations, restocks and manual adjustments, each with a date.
That is the whole of it, and it lives beside the rest of the ordering system rather than in a separate program.
Stock is only useful when the page a customer is reading knows about it, which is why the two sit together.
A menu at an address of your own. It sits on getmenu.ae and arrives with the account. Twelve page layouts, your colours and your font, opened from a link with nothing to install.
Prices read again at the last moment. At checkout each line is priced from the menu as it currently stands, compulsory choices must be answered first, and a nervous second tap cannot produce a second order.
Codes drawn for each table. The designer dresses them in your branding and the print pack lands in your email. Each code carries its own table number, so guests type nothing, and one table can build a single bill from several phones.
The kitchen is told in the group chat. Roughly 2 seconds after a customer confirms, a receipt reaches them, a ticket reaches the managers' group and a dispatch note reaches the riders' group with the map pin attached. All 3 messages are logged.
Addresses a driver can find. Buildings and units come from a list you set up, fees can differ between buildings, and free delivery can start above a total you choose.
A reason to return. Stamps tied to orders or to spend, tiers that regulars climb, an automatic discount available at each tier, and rewards with an end date so they get spent. The card goes into Google Wallet and keeps itself current. Apple's card is finished and awaiting a certificate.
Offers with a fence around them. Caps, item exclusions and expiry dates on coupons, one price for any three dishes as a bundle, and only the better of two discounts ever applying.
Paperwork for the accountant. New Zealand charges GST at a rate of 15%, and each invoice shows your registration number and downloads as a PDF without a login. Your sales history comes out as a spreadsheet whenever you ask, which is the same file your food costing wants.
Fifteen days of trial start without card details, and the charge afterwards is a single monthly figure, with 0% of your takings going anywhere else.
It is not ingredient level inventory software. There are no suppliers, no purchase orders, no recipes and no waste sheets in Get Menu. If you want to know your true food cost per dish, you need the first kind of system as well, and we would rather say so than let you find out in month two.
It also takes no payment online. Payment is cash or your own card machine at the door, so no card details exist anywhere in the system.
If you are regularly selling dishes you have run out of, start with sellable stock. It costs no staff time and the effect is immediate.
If your gross margin is drifting and you cannot say why, you need ingredient counting, and you need somebody whose actual job it will be. Buying that software without naming that person is the most common way this money gets wasted.
If you are unsure which problem you have, look at your best sellers first. The guide to menu engineering explains how to tell a dish that sells a lot from a dish that earns a lot, and the answer usually points at which system to buy.
No. It counts sellable items and their options, not kilos of flour. There are no suppliers, purchase orders or recipe costings in it. Many restaurants use it alongside an ingredient system and export their sales history to feed that system.
Each order reduces the count for the items and options it contains. When a count reaches zero the item greys itself out on the menu. Cancelling an order puts the stock back, and every change appears in the movement history with a date.
Yes, once the count reaches zero. Set the count at the start of service for the dishes you prep in batches, and the menu manages itself for the rest of the evening.
No. Sellable counts are typed in when you prep and then look after themselves. A full store room count belongs to ingredient level inventory software, which is a separate decision.
Yes, 15 days, and no card details are asked for to start it, so nothing can be charged by accident.
Free software is not the same thing as a free system. Floreant is real and it works, and the bill it sends arrives as your own time instead of a monthly invoice.
The useful question is not whether to join a delivery app. It is which parts of your business you are happy for somebody else to own, and which parts you are not.
Taking orders online is not one decision. It is five smaller ones, and most kitchens in Nigeria have already solved two of them without noticing.
Fifteen days with everything switched on. No card, no commission, ever.
Questions from other owners are answered in the community.