Restaurant Back-Office Station

$39.00

an independent restaurant that got quoted a monthly recipe-costing add-on on top of an already expensive POS contract and decided it wasn’t paying twice.

Local-firstNo telemetry — nothing phones homeNo lock-inNo migration

Feed it your ingredient costs, your recipes, and your menu prices and it costs out every plate, works the food cost percent on each one, and flags the dishes past 33% that are quietly eating the night’s margin.

$39 a month for the restaurant. No per-seat charge, no POS lock-in. Cancel any day and the reports you already ran stay on your disk.

The dish that sells great and makes nothing

You know the burger moves. What you don’t know, without sitting down with a calculator, is that beef is up since spring and that burger now runs a 41% food cost while you’re still charging last year’s price.

Spread that across a menu of forty items and the leak is real money, every service. Most operators find out at month-end, off the P&L, long after the night they could have nudged the price or swapped a garnish.

Three CSVs in, a costed menu out

  1. Drop in three exports: ingredients with unit costs, recipes as ingredient lines, and menu prices. A fourth, your vendor invoices, is optional.
  2. It costs each plate by summing quantity times unit cost, normalizing the units as it goes, so a recipe line in ounces still costs right against an ingredient you buy by the pound.
  3. It divides plate cost by menu price for the food cost percent, flags anything over your target (33% out of the box), and if you gave it invoices, points out which ingredients crept up.

What the reports actually tell you

  • RECIPE_COSTING.md: plate cost, menu price, and food cost percent for every dish, with the thin-margin ones marked so you can’t scroll past them.
  • MENU_ANALYSIS.md: the same list sorted worst-margin first, which is the order you’d fix them in anyway.
  • PRICE_ALERTS.md: the ingredients where your latest invoice cost more than your first. This is the file that catches the slow bleed nobody watches week to week.
  • costing.json, machine-readable, if your bookkeeper wants the raw numbers.

Who it fits, and who it doesn’t

Built for a single independent room, an owner or chef who knows the menu cold and wants the math without a consultant. A cafe, a bar kitchen, a neighborhood restaurant.

Not for you if you want costs to keep themselves current. This reads CSVs you export. A place that needs invoices and POS sales flowing in automatically wants a different kind of product, and a different monthly bill to match.

What it replaces, and what those do better

The recipe-costing module bundled with Toast, or a full back-office platform like MarginEdge. Those are genuinely better at automation: they pull your invoices and POS sales in on their own, so the numbers update without you exporting anything.

What they ask in return is a contract and your recipes living on their servers. This is a flat monthly price, no POS to integrate, and every CSV stays on your machine. For one room watching its margin by hand, that’s the trade that makes sense.

Your data, and where it stays

Your ingredient costs, your recipes, the prices you charge, none of it leaves the building. It reads the CSVs from disk and writes the reports back to disk at 0600 permissions, with no network call anywhere in the pipeline.

Your recipes are about the only thing a kitchen truly owns. They stay yours, on your hardware.

$39 a month, and your first costed menu

Set the four file paths in a .env and run it. First full costing in a few minutes once your CSVs are lined up, and lining them up is the real work the first time. After that it’s a two-minute rerun whenever a price moves.

Flat monthly, cancel any day, and the reports are plain files that stay on your disk even after you stop.

Security and privacy

Handles restaurant operating data (recipes, ingredient costs, menu prices, vendor invoices). Security is designed in.

Principles
Local-first. INGREDIENTS_CSV/RECIPES_CSV/MENU_CSV/INVOICES_CSV are read from disk and never transmitted anywhere; nothing in this tool touches the network. Nothing is uploaded, no telemetry, no cloud dependency.
Non-destructive. Source CSVs are only read, never modified or deleted.
Least privilege. Reads the configured input CSVs, writes only under OUTPUT_FOLDER.

Protections implemented (v0.1.0)
Path-traversal defense — every output filename is sanitized (safeSegment) and every write is checked with assertWithinRoot(), so the report can’t be written outside OUTPUT_FOLDER.
Fail-fast config validation — clear errors for missing/invalid INGREDIENTS_CSV/RECIPES_CSV/MENU_CSV/OUTPUT_FOLDER/TARGET_PCT before any file is touched.
Restrictive permissions — the generated report (RECIPE_COSTING.md, MENU_ANALYSIS.md, PRICE_ALERTS.md, costing.json) is written 0600.
Defensive parsing — the CSV parser and numeric field parser never throw on malformed input (missing fields default to empty string, unparseable numbers default to 0); a bad row degrades that recipe’s costing rather than crashing the run.
Secrets discipline.env and generated Costing/ output are git-ignored; no secrets or client data in the repo.

Distribution / AV trust

Known limitations / roadmap
Unit normalization is basic and same-family only. Weight (oz/lb), volume (tsp/tbsp/fl oz/cup/pint/quart/gallon), and count (each/ea/unit/ct) units convert correctly within their own family. A recipe line in a unit that doesn’t match the ingredient’s costed unit family (e.g. recipe uses “each” but the ingredient is priced per lb) is passed through unconverted (multiplied as-is) — review RECIPE_COSTING.md for recipes with an implausible plate cost, which usually indicates a unit mismatch.
Missing ingredient costs degrade silently to $0 in the plate cost total, not an error — they’re surfaced separately under “Missing ingredient costs” in RECIPE_COSTING.md so they aren’t missed, but a recipe with several missing ingredients will understate its true food cost %.
Price trend is first-vs-latest by invoice date, not a full time series — a mid-period spike that later corrects won’t be flagged; review costing.json‘s underlying invoice data for the full picture if a single price alert seems surprising.
TARGET_PCT is a single portfolio-wide threshold, not per-category (e.g. entrees vs. bar) — segmented targets are on the roadmap.

Reporting
Report suspected vulnerabilities privately to the maintainer before public disclosure.

Frequently asked questions about Restaurant Back-Office Station

What does the restaurant back-office station do for an independent kitchen?

The restaurant back-office station takes the paperwork that piles up behind a busy line and turns it into two numbers an owner can actually use, your real food cost percentage and the true plate cost of each recipe. You scan or import your vendor invoices, and the tool reads what you bought and what you paid. From there it works out what a dish costs to make at today’s prices, not last year’s guess, and shows you where your food cost is drifting week to week. The reader who buys this is usually an independent restaurant owner who has always done costing on the back of an envelope because the tools built to do it properly were priced for chains.

The order of operations is short and honest. First you scan or import your vendor invoices into the restaurant back-office station. Then it calculates your food-cost percentage and updates recipe pricing off the ingredient prices it just read. After that you review each recipe cost and decide what to charge, so the menu price reflects what the plate really costs. Nothing is filed anywhere and nothing is transmitted to a government office. The tool does the math and leaves the pricing decision with you.

Because the numbers come straight off the invoices you already receive, the food cost you see is grounded in real purchases. When a supplier raises the price of oil or chicken, the next invoice you scan carries that increase into every recipe that uses it, and the plate cost moves the same day. A spreadsheet never keeps up, because it is only as current as the last time somebody remembered to retype a price.

Running a food operation is not only about margin. A restaurant is also a regulated food business, and the food you serve falls under the state and local rules modeled on the FDA Food Code, the code regulators adopt for restaurants and retail food. The restaurant back-office station does not inspect your kitchen or manage food safety for you. What it does do is keep a clean, dated record of every vendor invoice you feed it, which is exactly the kind of purchase trail that helps when you need to show where an ingredient came from or trace a product back to a supplier.

The whole thing is built to fit a small shop. There is no point-of-sale contract to sign and no lock-in, because the tool works off your own invoice files rather than demanding you run your registers through it. That matters if you already have a register you like and only want the costing brain that the expensive back-office add-ons bury inside a bigger bill. You keep your own suppliers, your own menu, and your own way of writing a recipe.

What you get at the end is a plain picture of what you are spending to put food on plates and what each plate should sell for to hit the margin you want. You can read more about how it fits a working kitchen on the Restaurant Back-Office Station product page, and see the rest of the lineup for independents on the small business operators page. The tool does one job, costing off real invoices, and it does it the same way every week, which is what makes the number something you can plan against.

How long should I keep the vendor invoices the tool scans, and does it help me stay organized for tax time?

Every invoice the restaurant back-office station scans is a business record, and business records have to be kept. The tool reads your vendor invoices to work out food cost, but a useful side effect is that it holds a dated, searchable trail of what you bought and paid all year. That trail is worth keeping well past the moment you costed a recipe with it, because your purchase records back up the expenses on your return. The IRS guidance on how long to keep records lays out how long a small business is expected to hold onto supporting documents, generally at least three years and longer in certain situations, and vendor invoices are squarely the kind of supporting document that guidance is talking about.

The reason this matters for a restaurant is simple. Food and supply purchases are usually the single biggest deductible cost a kitchen has, and if that number is ever questioned the invoices are the proof. When your invoices live as a loose stack in a drawer or as photos scattered across a phone, pulling the right one months later is a bad afternoon. When they have already passed through the restaurant back-office station, they are dated, tied to a vendor, and easy to find, so the record you need for tax time is a by-product of the costing you were doing anyway.

The tool itself is not tax software and it does not file anything. It will not prepare a return or talk to the IRS for you. What it gives your bookkeeper or accountant is a clean, organized set of purchase records instead of a shoebox, which is the difference between a quick handoff and an hourly bill spent sorting paper. Many independent owners find that the organization alone pays for the subscription, separate from the food-cost work it does.

It helps to think of retention as a habit the tool quietly keeps for you. You do not have to remember to file each invoice, because scanning it for costing already puts it in order. If you close the books on a year and want to archive that year’s records, they are already grouped and dated. If a supplier disputes what you paid, you have the original invoice on hand rather than a fuzzy memory of the delivery.

None of this changes where your files live. The restaurant back-office station works off your own invoice files on your own machine, so keeping records with it does not mean shipping years of purchase history to somebody else’s server. You decide how long to hold a given year and when to let it go, guided by the retention windows the IRS describes rather than by a storage vendor’s default.

If you want to see how the costing and the record trail fit together for a small kitchen, the Restaurant Back-Office Station product page walks through it, and the small business operators page shows how the same idea plays out across other independent operators. The short version is that good costing and good recordkeeping turn out to be the same act here. You scan the invoice once, and it serves both the plate cost today and the paper trail you will want at tax time.

Where does my data live, and is my restaurant’s financial information safe with this tool?

Your data stays with you. The restaurant back-office station works off your own invoice files on your own machine, so your vendor prices, your recipes, and your cost numbers are not copied up to a cloud back office as a condition of using the tool. For an independent owner this is the honest answer to the question every small operator should ask before adopting software, which is who else gets to see my numbers. Here the answer is nobody by default, because the costing runs where your files already are.

That local-first setup matters because a restaurant’s back office holds more sensitive information than people expect. Vendor account details, pricing you have negotiated, and sometimes staff or payment records all pass through the same drawer. The FTC’s plain-language FTC guide Protecting Personal Information is built around a few simple ideas, take stock of the personal information you hold, keep only what you need, lock down what you keep, and get rid of what you no longer use. A tool that keeps your files on your own machine fits that thinking, because there is no extra copy sitting on a server you do not control.

The restaurant back-office station keeps a record of what it did with your files, so you can see which invoices were read and when. It does not upload your invoices to run the costing, and it adds no separate cloud copy of your books. If you want to move or archive a year of records, you do that with your own files rather than exporting them out of somebody else’s system. That is a deliberate design choice for owners who are wary of handing their financials to a platform they cannot inspect.

Being local-first does not mean the safety is automatic, and it would be dishonest to pretend otherwise. The machine the tool runs on still needs the ordinary care any business computer needs, a password, current updates, and a backup so a dead hard drive does not take your records with it. What the tool removes is the extra risk of a third-party breach, because your numbers are not sitting in a shared cloud waiting to be part of someone else’s incident. You are responsible for a smaller surface, and that is easier for a small shop to actually manage.

The same care the FTC guide describes for personal information applies to the payment and staff details that drift into a back office. Keep only what you truly need, store it where you can lock it, and clear out what has aged past its use. The restaurant back-office station supports that by leaving your data in your hands, where you can apply those steps, rather than scattering it across services.

If data location is the thing keeping you from adopting a costing tool, this is the point in its favor. You can read how the local-first approach works in practice on the Restaurant Back-Office Station product page, and see how it lines up with the way other independents run on the small business operators page. Your invoices, your recipes, and your margins stay yours, and the tool earns its keep without asking you to give that up.

How is the restaurant back-office station different from Toast, MarginEdge, or xtraCHEF?

The short answer is scope and price. Tools like Toast, MarginEdge, and xtraCHEF are strong, but they are built as pieces of a larger back-office platform, and the costing you actually want often rides inside a bill sized for a growing group rather than a single independent. The restaurant back-office station does the one job an owner cares about most, costing off real vendor invoices, without asking you to adopt a whole platform or run your registers through a system that then charges by the location.

Start with the register question. A point-of-sale suite naturally wants to own your sales, your payments, and your back office all at once. That is fine for some operators, but it means lock-in, and it means the card sales that flow through those registers show up on a IRS overview of Form 1099-K, the form third-party payment networks send for the goods and services you sold. The restaurant back-office station takes the opposite stance. It works off your own invoice files with no POS lock-in, so you can keep whatever register you already trust and add only the costing brain, rather than swapping your whole system to get it.

Price is the other real difference. The back-office add-ons that do proper food costing tend to be positioned above what a small independent wants to pay, which is exactly why so many owners fall back to a spreadsheet and stop costing at all. This tool is priced for the shop that has been shut out of those tiers. It is not trying to be the whole restaurant operating system. It is the costing and recipe-pricing part, sold on its own so a single kitchen can afford the number that keeps it alive.

There is also a difference in where your data sits. Several of the incumbents are cloud-first by design, which means your purchase history and pricing live on their servers as part of the deal. The restaurant back-office station is local-first and works off your own invoice files, so your numbers stay on your machine. For an owner who is uneasy about handing years of financials to a platform, that alone can decide the choice.

What you give up by going lighter is honest to state. You are not buying an all-in-one that also runs your floor, your payroll, and your online orders. If you need all of that in one place, a full suite may fit you better. But if what you actually lack is a trustworthy food-cost percentage and recipe prices that track real invoices, paying for the entire platform to get that one number is the expensive way around.

The restaurant back-office station is the focused alternative for the independent who wants the costing without the platform. You can compare how it fits your kitchen on the Restaurant Back-Office Station product page, and see where it sits among tools for independent operators on the small business operators page. One job, done off your real invoices, at a price a single shop can carry.

How does the tool turn vendor invoices into accurate recipe pricing?

The recipe pricing in the restaurant back-office station is built from the ground up out of what you really pay, which is what makes it more trustworthy than a menu price you set once and forgot. It starts with the invoices. You scan or import your vendor invoices, and the tool reads each line, the item, the quantity, and the price you were charged. Those real prices become the cost basis for every ingredient, so a recipe is not costed against a made-up number but against the actual delivery that came in the door.

From there the tool maps ingredient costs onto your recipes. When a dish calls for a given amount of an ingredient, it pulls the current per-unit price from your latest invoice and works out what that portion costs. Add up the portions and you have the plate cost, the true cost to produce one serving. Set that against your menu price and you have your food cost percentage for the dish, the single figure that tells you whether the plate is carrying its weight or quietly losing money every time it sells.

The reason this beats guesswork is that prices move and menus do not. A supplier bumps the price of an ingredient, and unless you are costing off invoices you never notice until the month is already thin. Because the restaurant back-office station reads each new invoice, the next time that ingredient arrives at a higher price, every recipe using it is recalculated, and the plate cost reflects reality the same day. You see the drift while you can still act on it, by adjusting a portion, switching a supplier, or nudging the menu price.

The workflow keeps you in the driver’s seat. After the tool calculates food-cost percentage and updates recipe pricing, you review each recipe cost and decide what to charge. It suggests the picture, but you set the price, because you know your neighborhood, your regulars, and what the market will bear. The tool is doing the arithmetic that is tedious and easy to get wrong by hand, not making the business call that only you can make.

Keeping recipes costed this way also leaves a clean purchase trail as a bonus, the same dated invoice records that back up your costs. The FDA’s model food code, published as the FDA Food Code and adopted in state and local rules, treats a restaurant as a food business with real recordkeeping around what it buys and serves, and a tidy record of vendor invoices supports that side of the operation even though the tool itself is about cost rather than safety.

The result is recipe prices you can defend, grounded in invoices rather than instinct, and updated as your costs change. You can see the costing flow laid out on the Restaurant Back-Office Station product page, and find the rest of the tools aimed at independent kitchens on the small business operators page. Scan the invoice, let the tool cost the plate, and set a menu price that actually holds up when the next delivery costs more than the last one.

Attributes Value
Deployment

On-Premises

Platform

Windows

License Type

Subscription

Billing Period

Monthly

Target Customer

Small Business & Retail

Free Trial

Yes

Reviews

Be the first to review “Restaurant Back-Office Station”

Your email address will not be published. Required fields are marked *