ERP for restaurants: do you actually need one?

An erp for restaurants is a single system meant to hold finance, purchasing, stock, staff and sales in one place, so that a number entered once appears everywhere it is relevant.

For a large group that is genuinely useful. For most restaurants it is an expensive answer to a question they do not have. This article gives you a straightforward test, and says what to do instead when the answer comes back no.

What an ERP is meant to solve

The problem an ERP exists for is not complexity. It is re-entry.

In a business without one, the same fact gets typed several times. A delivery arrives and is written in a stock sheet, typed into an accounts package, and reconciled against an invoice by a third person. Each retyping is a chance to be wrong, and nobody finds out for a month.

An ERP removes the retyping. That is the whole promise, and it is a real one.

The test, which takes five minutes

Answer these honestly:

How many times is the same number typed in your business? If the answer is one or two, you do not have the problem an ERP solves.
How many people would have to change how they work? An ERP is not a purchase, it is a change project, and its cost is mostly in that change.
Do you have somebody who will own it? Not use it. Own it, for years. Without that person, an ERP becomes an expensive database that slowly stops matching reality.
Is the thing that hurts actually finance? Or is it that orders arrive as messages nobody has time to answer, and stock runs out at eight without warning?

Most independent restaurants answer one or two to the first question and no to the third. If that is you, an ERP is not the next purchase.

"People ask us about an ERP when what they mean is that they cannot see what is happening. Those are different problems, and only one of them costs a year of somebody's salary to fix."

— Anzul Aqeel, founder of Get Menu

The Dutch VAT wrinkle either way

Whatever you buy, it has to get the tax right, and food service is not a single rate. The Belastingdienst publishes the VAT tariffs and which goods and services fall under each, and that is the source to check rather than a supplier's summary.

The practical requirement is simple: your system must let you set the rate per item, not per sale, and show the breakdown correctly on a receipt and in a report. Ask to see an order containing several different kinds of item and look at how it splits. This one check has quietly ended more shortlists than price ever has.

What to do instead, when the answer is no

If the pain is visibility rather than re-entry, the fix is smaller, cheaper and faster.

A restaurant pos handles money at the counter. Beside it, an ordering layer handles everything that happens away from the counter, with no hardware at all:

Your own ordering page, in any of 12 page layouts, so the menu reads the way you want it to and the link carries your name.
Options and add-ons with their own prices, and required choices the kitchen can rely on, all edited by you in the browser.
The live menu sets the price: every line is re-priced at checkout, and an old page in somebody's browser cannot undercut you.
Nobody types a message. Customer confirmation the moment the order arrives, kitchen ticket, rider link with the pin dropped at checkout: 3 messages in about 2 seconds.
Counts on every item and every option, falling as orders land, with a dish greyed out at zero so it cannot be sold twice.
Stamps that accrue as regulars order, tiers they grow into, an automatic discount at each tier, and the card in the wallet through Google's loyalty card format with nothing to install.
A tax invoice with your registration number on every order, downloadable without the customer logging in.
The code does the addressing: the kitchen sees the table number without anyone writing it.
One bill for a group, with everyone ordering from their own phone.
Coupons with exclusions and expiry dates, upsells, and bundles at a fixed price, and two automatic discounts never stack.
A whole menu from one spreadsheet, uploaded in a minute rather than typed over an evening.

Between a counter system and that, most single-site restaurants have every number they were hoping an ERP would give them, without a change project.

What the smaller answer actually costs you in time

It is worth being concrete about the difference in effort, because that is the real comparison.

An ERP rollout is measured in months and touches everybody. Menus, suppliers, chart of accounts, roles and permissions all have to be agreed before anything works, and the agreeing is the slow part.

The smaller path is measured in an afternoon. A menu imported from a spreadsheet, a code printed for 8 tables, and a trial that runs 15 days without a card. If it does not help, you stop, and the only thing you have spent is the afternoon.

That asymmetry is the argument. Not that an ERP is bad, but that you can find out whether the smaller fix solves your problem before committing to the larger one, and most restaurants never do it in that order.

When an ERP genuinely is the answer

To be fair to the category, there are cases:

Several sites with a central kitchen, where stock genuinely moves between entities.
A group large enough that purchasing is its own job with its own staff.
A finance team that already exists and is drowning in reconciliation.
Investors or a parent company requiring consolidated reporting on a fixed timetable.

If two or more of those describe you, look properly, and read the sister article on phasing an ERP system in rather than buying it all at once.

Frequently asked questions

Is an ERP the same as a POS?

No. A POS takes money at the counter. An ERP is a back-office system meant to hold finance, purchasing, stock and staff together so a number is entered once.

How do I know if I need one?

Count how many times the same number gets typed in your business. If it is once or twice, you do not have the problem an ERP solves.

Is Get Menu an ERP?

No, and it is not sold as one. It is the ordering, menu, stock and loyalty layer, with a POS add-on for the counter, and it can run beside your counter system.

What does it cost to get this wrong?

Mostly time rather than licence fees. An ERP nobody owns drifts out of step with reality, and then people quietly go back to spreadsheets while still paying for it.

How do customers pay?

Cash or your own card machine when the food arrives. There are no online payments in our system, so no card details are held in it.