Your Restaurant's Food Cost Is Not a Percentage. It's a Memory Problem.

Most food-cost leaks don't show up in a clean report. They show up by accident.

A chef says the cheese case feels expensive. A manager spots a smaller jug at the same price. The P&L looks off, but only after the month closes. You open the recipe sheet and the price in there is from last season, a different supplier, or just plain wrong.

Then comes the awkward question:

Do we actually know what this dish costs today?

That's the problem Mornay is built around. Not a fancier dashboard. Not "AI for restaurants." Just a way to keep your costs current as your suppliers, menu, and team change.

We call it cost memory: a running record of what you pay, what changed, and what it does to your margin, with proof for every number.

What is restaurant cost memory?

It's a system that answers five plain questions:

1. What did we pay last time?
2. What did we pay on the latest invoice?
3. Did the price actually go up, or did the case size change?
4. Which dishes does this hit?
5. What should we do: ignore, monitor, reprice, or get a quote?

The key word is memory. Scanning one invoice doesn't get you there. A recipe sheet doesn't get you there. A POS report doesn't get you there. None of those things on their own keep your costs current.

Most restaurants already have the pieces:

• supplier invoices and statements
• forwarded supplier emails
• paper receipts and photos
• recipe books and prep notes
• cost sheets in Google Sheets or Excel
• POS sales reports
• inventory counts
• chef notes that never make it back into the system
• owner calls made over text or in a quick pre-service chat

The leak starts when those pieces stop talking to each other. A supplier raises a price, but the recipe sheet stays the same. A case shrinks, but the menu cost still uses the old size. A dish keeps selling, but nobody notices the margin slipped. A real price hike hides inside 400 invoice lines no one has time to read.

Cost memory is the layer that keeps it all connected.

The old food-cost routine is too slow

Most restaurants treat food cost as a monthly accounting job:

• update recipes
• enter invoice prices
• do inventory
• review COGS
• explain the variance
• fix what's obvious
• do it again next month

That works only if the business is slow and the data stays clean. Restaurants are neither.

Prices move. Suppliers swap items. Cases get smaller. The menu changes. Someone uses the wrong code. The vendor's description doesn't match what the kitchen got. Accounting just wants the bill paid.

Bigger platforms, like MarketMan, MarginEdge, Restaurant365, and Octogone, handle parts of this: invoices, inventory, recipes, suppliers, ordering, accounting sync.¹²³⁴ But even good software can leave you stuck in the gap between systems. That gap is where most restaurants actually live.

The leak is rarely one big event

A margin leak usually looks small at first. A few real examples:

What changed	Why it matters
Mozzarella moves from $28.40 to $33.10 for the same case.	The Margherita gets more expensive, but the menu price doesn't.
Olive oil invoice looks the same, but the jug is now 3.5 L instead of 4 L.	The line price hides a real per-liter increase.
Flour looks more expensive on paper.	It might just be a different pack size. Updating blindly creates fake numbers.
Chicken is cheaper from a supplier you already use.	Worth a buying call, but only if quality and delivery still work.
Garlic is up 50%, but you barely use any.	Real change. Low priority. Watch it, don't chase it.

You don't need 400 alerts. You need the three things worth attention this week, with the invoice behind every number and a clear next step. That's the difference between data and memory.

A good cost system has to admit when it's not sure

You shouldn't trust a black-box recommendation. If a tool says "raise this menu price by $1.25," the first question is: based on what?

Was the item matched right? Was the case size normalized? Is the recipe current? Is the POS data recent? Did the chef change the portion last week? Is this a real price change or just a mapping mistake?

A good cost-memory system labels every finding plainly:

• Confirmed — invoice and item match are solid.
• Estimated — useful, but depends on a recipe or sales assumption.
• Needs review — something's unclear: an item, a unit, a case size, or a recipe link.
• Blocked — we need a yes-or-no from you before going further.

The first version of your cost memory will never be perfect. That's fine, as long as the system is honest about it. The point isn't to know everything on day one. It's to give you a useful first review, get your fixes, and run faster the next time because we kept those fixes.

"Real-time" isn't the point. Current enough to act is.

Restaurant tech overuses "real time." What you actually need is a system current enough to keep you from making a bad call.

A good workflow looks like this:

1. An invoice comes in by email, photo, upload, or accounting export.
2. The system reads the line items, units, case sizes, and prices.
3. It compares the new price to what you've paid before.
4. It does the unit math (per pound, per liter, per each).
5. It checks which ingredients, recipes, and dishes are affected.
6. It flags confidence and missing info.
7. It sends you a short note: what changed, what matters, what to do.

That last step is the product. Not the scan. Not the dashboard. Not the invoice file.

The product is the moment you can say:

• "Yes, that match is right."
• "No, that case size changed."
• "Ignore it, we barely use that."
• "Get a quote, but don't switch suppliers yet."
• "This dish needs a price review."
• "Ask the chef for the yield first."

That back-and-forth is how cost memory gets sharper.

Why scanning invoices isn't enough

Scanning tells you what came in. Cost memory tells you what it means.

You can scan every invoice and still not know:

• if a price hike is big enough to matter
• if the unit math is apples-to-apples
• which dishes use the item
• whether the dish even sells enough to care
• whether to reprice, renegotiate, get a quote, or do nothing
• which fix would make next week's review cleaner

That's why the strongest first output isn't a giant invoice table. It's a small note tied to a real decision. For example:

That's useful because it's specific, you can check the math, and there's an obvious next step.

Don't make me set up everything before I see value

Most restaurant software starts the same way:

• "Connect your POS."
• "Import all recipes."
• "Clean your vendor list."
• "Set up inventory."
• "Map every product."
• "Train the team."
• "Then the insights will be great."

Sometimes that effort pays off. Most owners won't put in that work before they see it work. Mornay starts smaller. The smallest set of files we need to give you a useful review.

That might be:

• 3 to 5 recent supplier invoices
• your current menu with prices
• any recipe or cost sheet you already have
• POS data later, if it sharpens the numbers
• a few quick yes/no answers when we're unsure

The first review should be honest about what it doesn't know. The promise isn't "we know your whole restaurant on day one."

The promise is: we start with the messy stuff you already have, show what changed, show the proof, ask only the questions that matter, and remember your answers next time.

That's how a heavy setup turns into a light routine.

Cost memory changes the weekly conversation

Without it, the meeting sounds vague:

• "Food cost feels high."
• "Suppliers are expensive."
• "We need to look at the menu."
• "Someone should update the sheet."

With it, it sounds concrete:

• "Tenderloin is up 9% across two invoices. The tartare and steak frites are exposed."
• "That flour spike is probably a case-size mismatch. Confirm before updating."
• "Garlic is up, but we barely use any. Just monitor."
• "Chicken is cheaper from an approved supplier, but delivery minimums could wipe out the savings."
• "The next useful fix is yield on the short rib, not another POS export."

That's a better meeting. Shorter. Tied to evidence. You leave with decisions, not homework.

What to look for in a cost-memory system

If you're shopping for food-cost software, invoice automation, inventory, or any AI tool for restaurants, ask these questions.

1. Can it show its work?

Every number should trace back to an invoice, a recipe, a sales report, or your own correction. If it can't show where a number came from, you'll stop trusting it.

2. Does it handle case-size and unit changes?

Prices aren't useful until the unit math is right. A case, a kilo, a pound, a liter, a bottle, a bunch, and "each" aren't the same thing. A shrinking case can hide inside a line that looks unchanged.

3. Does it tie prices to actual menu impact?

A price change only matters if it touches something you sell, stock, or prep in real volume. The best systems connect invoice lines to ingredients, recipes, dishes, and what's actually selling.

4. Does it admit when it's not sure?

A good review says, "we need you to confirm this." A bad one quietly guesses and shows clean numbers that are wrong.

5. Does it remember your fixes?

If you correct a supplier name, a case size, a recipe, or a yield, the next review should be faster. If the same questions keep coming back, that's not memory. That's manual cleanup, over and over.

6. Does it suggest a real next step?

Don't stop at "price increased." It should help you decide:

• ignore
• monitor
• update the recipe cost
• reprice the menu item
• renegotiate
• get a quote
• change a par
• tweak the order
• ask the chef or owner one quick question

A simple test: does the second run get easier?

The real test isn't whether the first report looks impressive. It's whether the second run takes less work.

After one review, the system should already know:

• this supplier name and that vendor are the same
• this item is the same despite a different description
• this case size changed
• this dish uses a different portion than the old recipe says
• this item is low priority unless volume jumps
• don't contact this supplier without asking first
• get quotes, but don't switch suppliers without a yes

That's the loop. You teach it once. The memory improves. The next review is faster, sharper, more useful.

The future isn't another dashboard to babysit

You don't need more places to check. You need fewer surprises.

You need to know when a price hike is real, when a case is shrinking quietly, when a dish is losing margin, and when the right answer is simply "do nothing." You need a cost system that stays alive after setup week.

That's why Mornay is built around restaurant cost memory. Invoices, menus, POS data, recipes, sheets, and your own fixes shouldn't live in separate piles. They should be one running record that answers the only question that matters:

What changed, what does it cost us, and what should we do next?

If you can't answer that quickly, your food cost isn't just a percentage. It's a memory problem.