Restaurants bleed margin in the gap between what a dish should cost and what it actually consumed. ERPNext ships strong bones for this — BOM, Item, Stock Entry, Stock Ledger Entry, valuation methods and a POS Invoice flow — but out of the box it treats a plate of food like any other manufactured good. There is no first-class notion of a menu-item recipe that deducts raw ingredients at the moment of a POS sale, no built-in theoretical-vs-actual consumption reconciliation, and no structured wastage or spoilage capture. Kitchen managers end up reconciling food cost in spreadsheets, and the variance that eats three to six points of margin never surfaces inside the system where the decisions are actually made.

We build a proper Frappe application — its own app in the bench, installable via bench get-app / bench install-app, versioned in git — that adds a Restaurant Costing module on top of native ERPNext without forking core. At its heart is a Recipe DocType (with a Recipe Ingredient child table whose rows reference stock Items with quantity, UOM and a yield/waste percentage) linked to the sellable menu Item. A scheduler event (recipe_cost.rollup) plus BOM-aware valuation logic compute a live theoretical cost per menu item from current Item valuation rates, so a change in the price of beef or cooking oil re-prices every affected dish automatically.

On each confirmed sale we deduct ingredients at the component level. A hooks.py doc_events handler on POS Invoice (and Sales Invoice) on_submit explodes every sold menu item into its recipe and posts a backflush Stock Entry (Material Issue) against the outlet warehouse, writing real Stock Ledger Entry movements so on-hand ingredient stock stays honest in real time. A Wastage Log DocType captures spoilage, prep waste, breakage and staff meals against a reason code and posts its own stock issue. Nightly, a scheduled job snapshots theoretical consumption (from recipes × units sold) against actual consumption (physical count / stock movement) and writes a Consumption Variance record per item and outlet, so the variance report is answer-first, not a spreadsheet exercise. A menu-engineering Query Report classifies each item into the star / plough-horse / puzzle / dog quadrant from contribution margin against POS sales popularity.

Everything is exposed through the Frappe REST API and whitelisted methods (@frappe.whitelist()) so a KDS, a third-party POS or a BI tool can read costs and post wastage; role profiles and DocType permissions (Kitchen Manager, Outlet Manager, Cost Controller) keep sensitive margin data scoped. Client Scripts add in-form helpers (live plate-cost badge, allergen flags) without touching the core desk. Because it is build-to-order, delivery works like an engagement, not a download: a short scoping call fixes your menu structure, outlet/warehouse layout, POS setup and reporting needs; we build and test your version against Frappe/ERPNext v15 or v16, run UAT on a staging bench, then install to production with a rollback plan and hand over the git repository. Typical delivery is one working week from confirmed scope.