Glossary — every domain word, in one plain sentence¶
What this covers. This is the dictionary for the whole domain bible. Every term, abbreviation, and shortcut the other chapters lean on is defined here in one clear sentence — plus a short why or a tiny example where that helps it land. It is grouped by area (foundations → the ledger → locations → scope → items → units → costing → recipes → procurement → sales → documents → close → fixed assets → the financial boundary → food safety → catalog → tenancy), so you can read it straight through once to build the vocabulary, then come back to it as a lookup. Entries define the domain concept and the canonical industry name for it; they are not a catalog of the words a programmer would type.
Foundations¶
Perpetual inventory — the discipline where on-hand quantity and inventory value are kept current after every receipt, sale, transfer, and adjustment, and are read back by summing the record of movements rather than from a stored running total. Why: a stored total drifts and hides who changed what; a summed one cannot.
Periodic inventory — the opposite discipline, where on-hand is established only
now and then by a physical count, and what was used is inferred by subtraction
(opening + purchases + transfers − closing). The system runs perpetually for the
live book and uses a periodic count to true it up at the close.
Perpetual vs periodic — the pairing of the two above: the perpetual book is a running claim about what should be on hand; the periodic physical count is the truth event that reconciles it, because theft, spoilage, and over-portioning are visible only to a count.
Derive, don't store — the founding rule that on-hand, value, and profit are all computed (on-hand by summing movements, value by weighted average, profit by rolling up), never saved as an authoritative figure that could fall out of step with the record. Why: one source of truth removes the whole class of bugs where a cached total and the underlying movements disagree.
On-hand — the quantity of an item currently sitting in the storage locations a business manages, obtained by summing the movements into and out of them as of a date. Computed from the last close's snapshot plus the movements since, never by replaying all of history. Example: on-hand flour today is its value at the last month-end plus every flour movement recorded since.
Contra-move — the correction mechanism for a record that is never edited: to fix a mistake you post an equal-and-opposite movement that reverses it, then post the right one, so both the error and its correction stay visible. Example: a 10 kg receipt booked into the wrong warehouse is fixed by a −10 kg reversal there plus a fresh +10 kg into the correct one — the original is never altered.
Taught in: Stock ledger, Invariants.
The ledger¶
Stock movement — one immutable record of stock changing place: which item, how much (an unsigned quantity, in the item's base unit), out of which location, into which location, on which business date, and the reason. It is the atom everything else is summed from. Example: a flour delivery is one movement from the supplier into the back-room storage location, 25 kg, reason "supply".
Stock-move journal — the append-only, never-edited record of all stock movements; the single source of truth for both quantity and value. One movement shape covers receipt, sale, transfer, waste, count adjustment, and production — there is no separate "type" for each.
Double-entry location moves — the principle that every movement is a move between two locations, so an increase in one place is always a decrease in another and the total quantity in the world is conserved. There is no bare "in" or "out", only a transfer between two places — and suppliers, customers, scrap, and production are themselves locations (see virtual location). Why: one primitive then covers all six operations uniformly, and transfers and production come out naturally two-sided instead of as special cases.
Lot detail — the layer beneath a movement that names the specific lot(s) involved, used only for items tracked by lot or by serial number; one movement can be filled from several lots. The quantity and money live at the movement level (valued per warehouse); the lot, its expiry, and its traceability live at this finer level. Example: issuing 10 kg of flour under first-expiry-first-out splits into "6 kg from the older lot, 4 kg from the newer lot".
Quant — the canonical name for derived on-hand: the physical-state view you get by summing movements over the storage locations a business manages. There is no stored quant; on-hand above is the quant, computed when you read it.
Valuation layer — the canonical name for the money view of stock, kept separate from quantity so value can change while quantity does not, and the reverse. Why the split matters: a transfer between your own warehouses moves quantity at no change in total value, and how you cost stock can change without any unit physically moving.
Valuation entry — an explicit, append-only record of a value-only change: the revaluation of the on-hand portion when a late invoice updates a receipt's prices, the correction after a negative-on-hand episode, the closing re-spread. Each one is linked to the document that caused it. Why explicit: value must never change silently — the quantity movements plus the valuation entries together reconstruct every derived figure.
Four conceptual layers — the mental model the ledger keeps even when the data is physically collapsed together: the movement (the event), the lot detail (which lot), the quant (derived on-hand), and the valuation layer (value, kept apart from quantity).
Reason code — the label that tells apart two movements that share the same pair of locations, the way a sold dish and a staff meal both leave from a storage location to the customer and differ only by reason. Why: reporting can group by reason to separate "sold" from "consumed internally" without treating them as different kinds of event.
Business date — the calendar day a movement is counted on, expressed in the restaurant's own local clock, stamped once and permanently — so an event lands in the right day, and therefore the right accounting month, no matter when it was recorded or imported.
Taught in: Stock ledger.
Locations¶
Location — one end of a stock movement: anything goods can move from or into. The locations a business manages are its storage locations; the rest are virtual stand-ins (below), so that every operation can be a move between two locations.
Storage location — a count area the business manages inside one warehouse ("walk-in", "bar", "back room"). It is the bucket a quantity is counted in and the scope of one stock count; it carries no value of its own — value belongs to the warehouse around it. Why the two grains differ: you count where things are, and you value where they are all priced alike — so a move between two storage locations of one warehouse is value-neutral by construction.
Usage — the kind of a location: a storage location the business manages, or one of the six virtual kinds — supplier, customer, transit, scrap, production, stock loss.
Warehouse — the set of storage locations a business values together: one cost pool and one weighted-average cost per item. The same item has a distinct cost in each warehouse, because you value a place. A bar and a kitchen can be two warehouses, each with its own pool. In its accounting role it is the accounting contour (below).
Accounting contour — the warehouse named for what it is in the books: the one grain where valuation and the period close sit together, over exactly the storage locations it owns. Why the walk and the value are bound: a closing value is only auditable if a single complete walk of exactly those storage locations is the evidence for it.
Warehouse · storage location · note — the three rungs of "where is it?": the warehouse carries value and closes, the storage location carries the quantity and the custody, and a free-text note or label ("shelf 3", "with Vasya") preserves detail too fine for a list.
Placement decides the books — where a document names a storage location, the warehouse that owns that location is the one whose books carry the goods; the location is stated and the warehouse follows. Receipts and write-offs state it line by line, so one document may reach across warehouses; where a document speaks for a whole warehouse — an opening count — it names the warehouse directly. Why the two are never both stated: naming them together lets them be named in conflict, and then the goods would sit in one place while their value sat somewhere else. A line may reach a draft unplaced and be placed before it posts — why: a document records what happened, never where it was carried, and posting is the moment value lands on books.
Production floor — the storage location a prep session works on (a kitchen table, a prep room). An ordinary storage location inside the warehouse that feeds it: raw goods walk onto it by relocation, a batch may draw its ingredients from it, and it is counted and closed like any other. Why it needs no regime of its own: its stock is the warehouse's stock, priced by the same pool.
Valuation area — the canonical term for a warehouse in its valuing role: the place where stock is held at a cost. It is the same thing as a warehouse, named for what it does in the books.
Virtual location — a location the business does not manage: either outside its scope entirely (the supplier side of a receipt, the customer side of a sale) or kept by the system (the transit leg of a transfer, the scrap bin for waste, the production counterparty when a batch is made, the stock-loss counterparty for a count adjustment). Virtual locations are generic — the specific supplier or customer lives on the document, never on the location. Example: waste is just a movement from a storage location to scrap; a count shortage is from a storage location to stock loss.
The operations, as moves — receipt is supplier → storage location; sale is storage location → customer; transfer is storage location → transit → storage location; waste is storage location → scrap; a count overage is stock loss → storage location and a shortage is storage location → stock loss; producing something consumes storage location → production and yields production → storage location.
Taught in: Scope & locations.
Scope axes¶
Company — the tenant: the top-level boundary that owns all of one business's data and isolates it from every other business's. Defined in full under Tenancy.
Warehouse (as a scope) — the grain at which stock is valued, held, and reconciled: one shared cost pool and one weighted-average cost per company, warehouse, and item. A warehouse may be a single restaurant's back-of-house store or a shared commissary that serves several restaurants. Its books also carry the fixed assets placed on it (see asset placement).
Valuation strategy as topology — the rule that how finely a company values its stock is decided by how many warehouses it creates, never by a setting: one materials warehouse gives one blended cost for the business; a warehouse per site gives independent pools, counts, and closes. Why no switch: a blended figure spanning warehouses that are walked on different days is confirmed by no single count, so it could not be audited from any one walk.
Profit center — the canonical name for a restaurant in its money role: the business unit whose food cost, cost of goods sold, and margin a consumption is charged to. It is stamped onto each consumption and never owns the stock pool. Why separate from the warehouse: who the cost belongs to (the restaurant's profit-and-loss) is independent of where the stock physically sat (the warehouse that held and valued it).
Channel — the marketplace or till a sale came through; an attribution label only, never a stock location.
Warehouse-to-restaurant (many-to-many) — the "supplies / consumes-from" link: a restaurant draws from one or more warehouses (usually one primary), and a commissary warehouse can supply several restaurants. The link governs eligibility and routing — which warehouses a restaurant's sales may deplete, and which restaurants a warehouse may supply — never remote consumption. Why many-to-many: a shared commissary feeding several restaurants is the textbook "one plant serves many profit centers" shape.
Valuation grain vs profit grain — the rule that crystallizes the split: stock is valued per warehouse, while a restaurant's profit-and-loss is a roll-up of the consumption charged to it, never a second place where stock is valued. "Company-wide" is just the special case of a single warehouse.
Commissary — a central prep-and-hold warehouse that produces prep items and supplies several restaurants — always by explicit transfer into each restaurant's own warehouse before any sale consumes the goods. It is the case that forces the many-to-many link above.
Taught in: Scope & locations.
Items and their policies¶
The rule that governs this whole cluster: an item's behavior never depends on its category, because categories are a free, user-extensible classification that a customer can rename or translate. Behavior keys off a few explicit policy fields and the facts derived from them; the category supplies only a code prefix and sensible defaults.
Item (inventory item) — anything material the business holds, buys, makes, or uses: a raw material like flour, a bought-in good sold as-is like a bottle of cola, a paper clamshell, an oven. The item is the record that measurement, purchasing, the accounting treatment, and the food attributes all attach to. "Inventory item" is the full name; after this first definition the domain simply says item.
Archived item — an item set aside as a reversible soft-hide: it drops out of working lists and pickers and new documents won't accept it, but its history stays, a delivery against it can still be received, and it can be brought back. Archiving asks that nothing is on hand, so a warehouse can still close. An item is usable the moment it's created — there is no separate draft or activation step. Separately, an item locks: accounting treatment and tracking freeze once it has any stock movement, and the base unit freezes once it has a movement or is wired into a recipe (see Recipe role); that is about facts of use, not a lifecycle stage.
Accounting treatment — the stored choice of how an item's value is handled, which is the single switch that says how it behaves. Four values, named by when the cost hits the books: stocked (at consumption), expensed on receipt (on arrival), expensed on write-off (when an implement dies), and capitalized-and-depreciated (over time). It locks once the item has transaction history, because you cannot silently re-route the accounting of something people have already received.
Stocked item — an item carried on the ledger: tracked, counted, and valued at a running weighted-average cost (flour, beef). This is the stocked accounting treatment, and "is it stocked?" is the master gate that many older one-off capability flags collapse into.
Expensed-on-receipt item — an item whose cost is written off the moment it arrives, with no on-hand, no count, and no valuation (oil, salt, gloves, napkins). Why: tracking the on-hand of a pinch of salt costs more than it is worth.
Implement — a durable smallware (a frying pan, a knife, a gastronorm tray): too long-lived to be a consumable, too cheap to depreciate. The expensed-on-write-off treatment: purchases accumulate in a per-warehouse pool of quantity and value, nothing drains through sales, and the cost is recognized only when a unit breaks, is lost, or a count finds it gone — into the implement write-off bucket, never food cost. A count may also find more than the book claims, and the sighting stands; the surplus is put right by entering the receipt that paid for it, never by an overage (see Overage). In one phrase: a fixed asset with zero depreciation, kept out of the asset register.
Capitalized item — an item routed to the fixed-asset side of the house: booked as an asset when received, then depreciated over its life (an oven, a mixer). This is the capitalize-and-depreciate treatment — and the item is still bought through an ordinary purchase order and goods receipt, like anything else.
Tracking granularity — the stored choice of how finely an item is traced: not at all, by lot (a batch with an expiry), or by serial number (one record per physical unit). Example: milk is tracked by lot because expiry matters; table salt is not tracked at all.
Storage condition — the stored default condition for shelf-life policy: ambient, chilled, or frozen. It is copied from the category at item creation and used when lot expiry is stamped.
Packaging item — an item with the packaging recipe role: placeable on a recipe's packaging rows, with its cost always in a separate bucket from food cost. By default it is stock-tracked — cups and clamshells are real countable stock that depletes as dishes sell — though a negligible wrapper can be expensed. Example: a kraft clamshell rides a dish's packaging row and costs into packaging, keeping the food-cost percentage honest.
Producible item — an item flagged as something you make rather than buy raw — the candidate filter for "can this have a recipe?" (you make dough, not raw flour). It is the candidate flag only; whether a recipe yet exists is a separate fact.
Receiving routes by treatment — the rule that any item may appear on a purchase order or a goods-receipt line; there is no separate "procurable" switch. What the received line does is routed by the item's accounting treatment — into stock, straight to expense, or to the fixed-asset branch. Why: buying is universal; only the accounting consequence differs.
Prep item — an in-house intermediate that is both made and stocked and has its own recipe — a batch of dough, a base sauce, peeled carrots (formally, a semi-finished good). It is what you get when a producible item is also stocked. Why it earns a name: a stocked prep item stops the recipe explosion (below), because it was already made and costed once.
Recipe role — the policy fact saying what an item may be inside a recipe: exactly one of none, ingredient (an atom line that never decomposes), producible (a made thing with its own recipe), or packaging (rides out with the dish in packaging rows); recipe lines are gated by it. The role is freely changed until the item is wired into a recipe — then it freezes, and the same wiring freezes the item's base unit. Why one exclusive choice: an item can't be both a leaf and a branch of the costing tree. The gate and the freezes in full: Item model & policies §5.
Decomposing intermediate — a producible item that is never held in stock: a named sub-recipe (a house spice mix) that dishes reference as one tidy line, while costing and consumption pass through to its components as if the dish had listed them directly. Why it earns a name: its stocked counterpart, the prep item, stops the recipe explosion; the decomposing intermediate is the same role with the opposite behavior, told apart purely by is-stocked.
Valuation is independent of the recipe role — the rule that an item's accounting treatment has nothing to do with what it may be in a recipe (the role's question). An expensed ingredient contributes to a recipe's theoretical cost at a reference price but stays out of counts and out of actual-usage variance. Why: coupling the two would drag an expensed item back into full valuation — the exact tangle the policy fields exist to prevent.
Reference price — the standing price (last purchase, or a set standard) at which a non-stocked ingredient is costed into a recipe, since it has no running average of its own. Example: salt, expensed at receipt, still adds its few cents to a dish's theoretical cost at reference price.
Price policy — the item-level rule that chooses how an item's menu price is found: automatic (the newest market fact seen), pinned (follows one chosen supplier article until unpinned), manual (a hand-typed price), or stock price (what the item's own stock is worth on average). A policy that cannot resolve reads as unpriced, loudly, never silently falling back. Why on the item, not the dish: a price is a fact about an ingredient, so steadying it once protects every dish at once. How each setting behaves: Menu & catalog §5.
Manual price — a price a human types for an item from their own knowledge ("blueberries run about €12/kg") — a single current value, not a history, for when no purchasing record exists yet or to override noisy ones. It feeds the menu cost only and never values stock. Distinct from a reference price — the automatic last-purchase-or-standard fallback an expensed ingredient is costed at; a manual price is a deliberate human override.
Taught in: Item model & policies.
Units of measure¶
Unit — a measure: how much of something there is — a kilogram, a liter, a piece — carrying no price and no supplier. A unit scoped to a single item may also stand for the bundle that item comes in (a 25 kg sack, a case of 6 × 2 kg), then additionally carrying that bundle's barcode and an optional photo; structurally it is still just a per-item unit with a ratio to base, measured and converted like any other — only how a vendor prices it lives elsewhere (a supplier article, below). Conversion happens only within a single dimension (mass, volume, or count), never across.
Dimension — the family a unit belongs to: mass, volume, or count. The boundary across which the system refuses to auto-convert, because turning liters into kilograms needs a density it does not assume. (The blessed workaround is an item-scoped mass measure — "a cup of this flour = 120 g" — a deliberate, per-item, operator-owned factor, never an implicit conversion.)
Base unit — the single canonical unit of an item's dimension (grams for mass, milliliters for volume, pieces for count), in which every stored quantity and every unit cost for that item is expressed. Why one base unit: it is the common denominator that lets the accounting core do arithmetic without thinking about which unit a quantity was keyed in.
Base-unit immutability — the rule that an item's base unit freezes once it has its first stock movement, because it is the denominator of every stored quantity and cost; changing it would silently rescale history.
Stock unit (unit of issue) — the per-item unit a human naturally counts, issues, and reads an item in: kilograms for flour, pieces for buns. It pre-fills entry on counts, write-offs, and production outputs, and always converts to the base unit on posting. Why separate from the base unit: the base unit is the machine's denominator and must stay fixed; the stock unit is the human's pen and can change freely.
Pricing unit — a per-item choice of the measure to read prices in, so a supplier's quote is shown on a legible, comparable basis: butter per 100 grams, flour per kilogram, oil per liter. It changes nothing but the display — the price itself stays attached to each supplier article, and the figure shown is simply that article's cost re-expressed in the pricing unit. Its only job is to let two suppliers' articles in different units be compared at a glance ("which butter is cheaper per 100 g?") instead of as an unreadable price per gram. Left unset, prices read in the base unit.
Standard units — the company-shared seeded dictionary of ten units (grams, kilograms, ounces, pounds; milliliters, liters, fluid ounces, quarts, gallons; pieces), laid down once per company and server-protected so a standard unit's factor can never be edited — every one is a universal physical constant. A company may hide the standards it doesn't use (an EU kitchen hiding oz/lb/qt/gal): hiding only removes the unit from pick-lists for new entries — anything already referencing it keeps converting — and the canonical bases (g, ml, pcs) can never be hidden. A bundle you buy in — a 25 kg sack, a case of 6 × 2 kg — is not a separate kind of thing either: it is simply a per-item unit that also carries a barcode.
Custom unit — a company-shared measure an operator adds to the dictionary for vocabulary with no universal definition (a baker's dozen, a tray of 30, a house scoop) — the same company-wide scope as a standard unit, but operator-owned and editable (rename, re-factor, retire) until a document first references it. Why lb/qt/gal are standard, not custom: they are physical constants, and an editable constant is a typo away from corrupting every quantity entered through it.
Supplier article — the optional catalogue line that prices one item for one supplier, bought in a chosen unit: how you buy this item from this vendor, and at what. It references an item and the unit it is priced in — a per-item bundle (the Case 6 × 2 kg) or a plain measure (apples priced per kg) — and carries the commercial terms (the price, the minimum order quantity, the lead time) together with the recognition keys that let a delivery's invoice line be matched to it: the supplier's code (their printed article number) plus the free-text descriptions it has used before, learned over time. It also accumulates the price history the anomaly checks read. It is never required to record a purchase — a cash or market receipt carries an item, a unit, and a price with no article at all — and the same item bought from two vendors, or priced two ways by one vendor (per sack and per pallet), is simply two articles. A freshly imported line may sit unresolved — naming a supplier and the supplier's own words for what it sells and in what (a code too, when known) but no item or unit yet — until someone matches it, and the two match independently: the item can be pinned down before the unit is (you know it's this flour before you've worked out whether the line means the sack or the pallet), but the unit can only be matched once its item is known, since a unit is only ever valid for one item. Example: "Baker's Supply sells flour as a Case 6 × 2 kg at €18.00, 1-case minimum, 2-day lead."
Convert-to-base (the boundary rule) — the rule that no quantity enters the ledger except after conversion to the item's base unit, at the moment of posting. Why: keep the unit-juggling at the edge and the entire accounting core stays unit-agnostic, working only in base-unit decimals.
Taught in: Units of measure.
Costing¶
Cost of goods sold (COGS) — the value of everything consumed by selling over a period, assembled at the close with shrinkage re-spread inside it: the period aggregate, split into food and packaging buckets at the financial boundary. A month has a COGS; a single dish has a plate cost (see Labor and payroll). The two meet only when dishes sell.
Weighted-average cost (WAC) — the costing method where an item's unit cost is the value-weighted average of everything received into its cost pool. The right choice for fungible, commingled food, where tracking which exact kilogram of flour you used is fiction. Example: 10 kg already on hand at €2.00/kg, receive 10 kg at €3.00/kg → new average is €50.00 ÷ 20 kg = €2.50/kg.
Average cost (AVCO) — the accounting synonym for weighted-average cost; used interchangeably.
Moving average — the live form of weighted-average cost, re-blended on every single receipt so the running book always shows a current unit cost. Its counterpart at the close is the periodic weighted-average, which is the authoritative figure that rolls value forward.
Two-stage average — the costing rhythm: a blended price during the period keeps the live book current, then a value-conserving closing price is struck at the close and carried into the next period. Computed per warehouse, on its one shared cost pool.
Dish-cost snapshot — an append-only record of what a dish cost to make on a given day, carrying both cost worlds side by side: the menu cost (from current item prices) and the stock-valuation cost (from the blended average of the stock actually held), plus the recipe version priced and the date priced as of. A dish is never stocked, so each is a single company-level number — no warehouse; the per-ingredient breakdown is priced fresh on demand, never stored. Distinct from cost of goods sold, which is posted warehouse-accurately when the dish is actually sold.
Replacement cost — the costing method behind the menu cost: pricing a recipe's ingredients at what they would cost to re-buy today — the most recent market fact seen for each, unless the item's price policy overrides it. A made-in-house prep is never bought, so it is costed by looking through to the raw materials it is made from. Why it matters: when prices climb while cheaper stock is still on hand, it shows the margin the next batch will really carry.
Quantity is independent of value — the load-bearing decoupling (see valuation layer): a transfer between your own warehouses moves quantity at no net change in value, and the average is simply re-blended at the receiving warehouse if its pool differs.
Landed cost — the full cost placed on a goods-receipt line: the line's subtotal (quantity × price, less any discount), plus its share of freight and handling allocated by value, plus that line's non-recoverable tax. The receipt movement carries this net figure, not the bare line price, because freight and non-recoverable tax are genuinely part of what the stock cost you. Example: €100 of beef + €8 freight share + €0 non-recoverable tax → landed cost €108.
Line-level tax — the rule that tax is a fact of each receipt line — its own rate (or amount) and its own recoverability — never a header pot spread across the document by value. Why: one invoice can mix rates and taxability; a header allocation would mis-cost every line.
Recoverable input VAT — value-added tax a business can reclaim from the tax authority on its purchases, so it is not part of inventory cost: stock is valued net of it and the tax becomes money owed back to the business. The EU case (Portugal first), tracked per line — each line carries its own rate and recoverability. Example: €100 of ingredient + €23 recoverable VAT → stock valued at €100, with €23 sitting separately as a receivable.
Non-recoverable tax — tax that cannot be reclaimed and is therefore folded into that line's cost as part of landed cost. The US case sets recoverable tax to zero, so net equals cost and one code path serves both regions.
Gross vs net (payable vs capitalized) — the two money totals on a receipt: the gross is what you owe and what ties out to the invoice; the net is what feeds the valuation. Why it matters: the average must be built on the net value — capitalizing the gross would quietly overstate what stock is worth.
Negative-on-hand handling — the reference treatment for an issue that drives on-hand at or below zero: it is costed at the current average, the gap goes to a price-difference account (recorded as an explicit valuation entry), and the receipt that later lifts on-hand back up is split so the books stay consistent. Why: food businesses routinely sell before the paperwork catches up, so the math must not break on a brief negative.
No-backdated-average repair — the reference rule that a movement entered for a past date takes the current average, with any cost difference expensed on the movement's own business date rather than threaded backward through the whole history of averages. Why: re-striking every past average for one late entry is both expensive and surprising.
Taught in: Costing & valuation.
Recipes and production¶
Recipe — the company's recipe knowledge base for a dish or prep item — far
more than a parts list. It holds the structured ingredients + packaging and portion
facts (the bill of materials the stock side explodes), the free-form preparation
steps, photos, and notes (how it is actually made), the evidence the
nutrition/shelf-life/allergen logic reads, and the material a cook learns from, is
attested on, and opens on a tablet while prepping. Each version is a frozen
snapshot, so a sale can always be costed against the recipe as it stood on that day.
Historically also called a tech card; the domain term is recipe.
A recipe carries its own name (independent of the linked dish/prep item). A draft
may be ownerless — created and built before it is linked to the dish or prep item it
produces; the link (dish XOR item, at most one) is required only to activate, which
is also when the per-owner version number is assigned. An unnamed recipe falls back to the
owner's name for display. Each recipe version also has its own reference code (RC-...) so
operators can search and share the recipe row directly without using a dish or item code as
a substitute.
Bill of materials (BOM) — the canonical name for a recipe's component list — a tree of component + quantity + unit. A recipe's structured ingredients form a bill of materials (the recipe itself carries more — see Recipe); those ingredient rows are the bill's lines.
Recipe explosion (BOM explosion) — walking a recipe's tree down to its leaf ingredients to produce the list of items a sale actually consumed. Why: a sold dish has to become depletions of flour, beef, oil, and so on to drive both theoretical usage and cost.
Date-correct explosion — exploding against the recipe that was in effect on the sale's business date — picking the version active on that day, walking its frozen tree, and pinning that version onto each consumption so the historical cost is reproducible. Why: costing a sale against today's recipe when the recipe has since changed would give the wrong number.
Explosion stops at a stocked prep item — the rule that the walk halts when it reaches a stocked prep item and depletes that prepped item one-for-one at its own cost, instead of carrying on down to the prep item's raw ingredients. Why: the prep item was already made and costed once; re-exploding it would double-count and would ignore the batch already in stock.
Yield (edible-portion vs as-purchased) — the gap between what you bought and what is usable after prep: as-purchased (AP) is the whole, unpeeled invoice quantity; edible-portion (EP) is what survives trimming and peeling. Costing at the as-purchased price systematically understates food cost — the classic mistake this domain avoids. Example: an as-purchased carrot at €1.00/kg yielding 81% really costs about €1.23/kg of usable carrot.
Emergent yield — the fact that yield is not a number anyone types in; it falls out of a prep item's own recipe as output weight ÷ total ingredient weight. Example: 124 g of whole carrots peeled down to 100 g gives a yield of 100 ÷ 124 = 81%, read straight off the "peeled carrots" recipe — there is no separate yield field.
Prep-item unit cost — the cost a prep item carries into the dishes that use it: its total ingredient cost divided by its output, which embeds the yield (less output from the same ingredients means a higher unit cost). Example: €1.00 of whole carrots ÷ 0.100 kg of peeled output = €10.00/kg of peeled carrot.
Production (the move-pair) — making a prep item expressed as two ordinary movements: consume the ingredients storage location → production, then yield the finished item production → storage location, with the ingredients' cost rolling into the output. It posts at operator-stated quantities — cost = stated ingredients ÷ recorded output — while the recipe stays the standard. The ingredients leave the storage location the session names (see production floor) or the warehouse's default; the yield always lands at the default. Why it needs no special machine: manufacturing is just the movement engine plus a recipe.
Recipe correction — the document that fixes journals posted with a wrong recipe (distinct from a missing one, which is held unposted until it exists): after the corrected version is activated with backdated effect, it posts the delta between the correct and the wrong explosion per affected line — on the original dates while the period is open, or as a net-zero reclassification (consumption plus shrinkage reversal) in the current period once it has closed. Total cost of goods never changes; the correction buys back explanation and attribution. Taught in: Recipes & production §10.
Trim-loss — the prep loss that is handled implicitly: because the output weighs less than the ingredients, their full cost rolls into the smaller output, raising its unit cost. Booking the trim explicitly to scrap is a later refinement.
Theoretical-vs-actual (AvT) — the central food-cost variance comparison. Theoretical usage is what should have been consumed — sales multiplied through the recipe explosion. Actual usage is what the count says was really depleted. The variance is theoretical minus actual, in quantity, money, and percent. Example: theoretical flour use 100 kg, counted actual use 108 kg → variance 8 kg.
Unexplained variance — the operationally important number left after you subtract logged waste from the total variance: the part that points at over-portioning, theft, or mis-invoicing. Example: an 8 kg variance with 3 kg of logged waste leaves 5 kg unexplained.
Taught in: Recipes & production.
Procurement¶
Shopping list — the casual, manual list you jot for a walk-in cash or market run: "101 eggs, 5 kg flour, some cling film", scribbled before any supplier, unit, or price exists, and maybe before a firm item — a line need only name something (a catalog item or free text), with quantity and unit optional. It is pre-ledger: a shopping list never moves stock. Its one exit is to seed a walk-in goods receipt, which records what was actually bought; a single running list can feed several receipts across a week's trips, so it stays open until you sweep it closed by hand. Its life is open → closed, with cancelled to abandon a partly-shopped list. The trade also calls this a market list. Example: the running list on the pass the chef shops on the way in and books against the till receipt.
Requisition — loose buying intent captured for the formal purchasing lane, before it is resolved into orders: the same "name something, quantity optional" shape as a shopping list, but headed for suppliers rather than a cash run. A header-plus-lines document like the order, and equally pre-ledger (it never moves stock), but deliberately unresolved — a line need only name something (a catalog item or free text), and its quantity, unit, needed-by date, and warehouse are all optional. It is the third, manual source of demand beside the two automatic feeders (par reorder points and the forecast cascade): the only one a human authors by hand, which Plan it turns into supplier orders. Its life is open → closed, with cancelled to abandon it. Example: a week's running list the buyer plans into purchase orders across several vendors.
Plan it — the action that turns a requisition into real orders. It runs the order-shaping half of the procurement engine — resolve each line to a supplier and a unit, round up to whole units and the minimum order quantity, group one draft order per supplier — but skips netting by default: a hand-written quantity is taken at face value (ask for 101 eggs, order enough whole units for 101 eggs). Subtracting on-hand is an opt-in; with it on, a line is reduced by what is already on hand and on order, and a line that comes out fully covered is marked covered and ordered as nothing. Lines that can't be planned (no firm item, no quantity, an unconvertible unit, no warehouse) or can't be sourced (no supplier article) are surfaced for the operator, never silently dropped.
Requisition line state — the stage of one requisition line: open (captured, still awaiting a decision — free-text or quantity-less lines may linger here indefinitely), planned (turned into a draft purchase-order line by Plan it, and linked to it — deleting that draft line before it is ordered reverts the line to open), covered (netting found enough already on hand and on order, so nothing was ordered — reachable only via the opt-in subtract-on-hand), or dropped (set aside as no longer wanted).
Purchase order (PO) — a commitment document: a promise to buy, which never itself moves stock. Example: "order 50 kg of flour from Acme" is a purchase order; the flour actually entering stock is a later goods receipt. It has a six-state lifecycle (see purchase-order fulfillment state).
Purchase-order fulfillment state — the stage of a purchase order's life: draft → ordered → partially received → received or over-received, with cancelled available throughout. The three receipt states are derived from the posted goods-receipt links, never set by hand: an order is received once every line has arrived within tolerance, partially received while any line is still short, and over-received when every line is met and at least one line arrived above its order (beyond tolerance). One rule settles the mixed case — still-short always wins: if any line is under-delivered the order stays partially received however far another line ran over. Both received and over-received are finished (no further edit or cancel). Not to be confused with the over-receipt adjustment (a pre-count stock overage; see Period close), which shares the "over-received" spelling but is an unrelated stock-loss concept.
Goods receipt — the document that books goods arriving: it runs the per-line landed-cost calculation, posts the supplier → storage location movements, and creates the lots for lot-tracked items; a capitalized asset line moves no stock and routes to the fixed-asset branch (see receiving routes by treatment). Each line names the storage location its goods went to, so one delivery can put produce in the kitchen's walk-in and a mixer in the back-of-house store — two warehouses — and still be one payable document, the books that carry each line following the location it names (see placement decides the books). It is invoice-optional at posting: a walk-in cash-and-carry purchase posts complete with its invoice in one step, while a delivery posts from the delivery note at order or estimated prices and the supplier invoice attaches later as a price update — the on-hand portion revalues through a valuation entry, and the already-consumed portion's difference is expensed. One document either way; the invoice is an attachment event, not a second document. It is also first-class without a supplier: a no-supplier market or cash run posts from nothing more than an item, a quantity in a plain measure, a cost, a storage location, and a date — no article, no vendor required — so the everyday bazaar buy moves stock with the lightest possible entry.
Delivery note — the paper (or PDF) the goods physically arrive with when the supplier invoices later: quantities, usually order or estimated prices, no final tax math. A goods receipt may post from it immediately — stock should not wait for paperwork — with the invoice attaching afterwards as a price update.
Invoice read (scanned receipt) — building a draft goods receipt by reading a photo or PDF of the supplier's invoice instead of typing it. It identifies the supplier by name (creating a new supplier if none matches), auto-fills the lines whose printed code or description exactly matches what that supplier has used before — binding them to the right item and unit, and learning the match — and sets every other line aside for review. The read only ever produces a draft for a human to finish; it never posts.
Extracted line awaiting review — a line read off a scanned invoice that the system would not auto-bind: a product it can't confidently place, one never seen from this supplier, or a credit/return. It holds what was read (description, quantity, price, and the source file/page) plus, when confident, a suggestion to confirm an existing item or create a new one — a prompt for a human, never a binding. The operator applies it (turning it into a real receipt line, creating the item or unit first if new) or dismisses it; either way it leaves the list. A draft cannot post while any such line remains, so a readable-but-unplaced line can never silently drop its stock.
Recorded price (price history) — what a supplier article has actually cost, learned from the receipts that posted it or from a direct correction when purchasing knows better (re-quoted by the vendor, or a catalogue re-import). Each one adds to the same history; the article carries its current price and a typical price — the middle value of its recent history, so a single mistaken posting cannot drag the figure off.
Pack-jump guard — the sanity check on an invoice read: an auto-fill is trusted only while the invoice's per-unit price stays near the article's typical recorded price (a recent purchase, or the originally seeded price if it has never been bought). A large jump usually means the unit the line was billed in changed, not the price — a ten-piece box read against the single piece — so the line is set aside for review instead of silently booking a tenth of the stock at ten times the cost. When the jump is a clean whole-number multiple (a box priced at exactly ten times the piece), the review line carries a one-click proposal to record the larger unit (a per-item bundle); an uneven multiple (catch-weight produce) is left for the operator to resolve by hand.
Catch-weight — goods sold by a weight that varies per delivery rather than in a fixed bundle: a side of beef, a wheel of cheese, loose produce weighed at the counter. The supplier prices them per measure (per kilogram); the unit is that measure itself, and a received line carries the actual weight that arrived (5.945 kg, not "one case"). The weight is the quantity — there is no fixed bundle to convert — so the ledger books exactly what the scale read.
Par / reorder point — a per-item, per-warehouse minimum-and-maximum level that drives reordering. Only stocked items get a par; expensed and capitalized items can be ordered but only by adding them by hand. Example: flour par at the dry store is a minimum of 20 kg and a maximum of 80 kg.
Replenishment rule — the stored record of a par level: the minimum and maximum quantities for one stocked item at one warehouse, expressed in the item's base unit. One rule per item-and-warehouse pair; the netting engine reads it automatically.
Netting — the subtraction step that makes a plan stock-aware: gross demand for an item minus the on-hand quantity at the relevant warehouse minus the quantity already committed on open purchase orders (those in Ordered or Partially received, and also Draft proposals standing from this run so a re-run does not duplicate them) equals the net need — the gap that still requires buying. Example: gross need 40 kg, on-hand 12 kg, open order 25 kg → net need 3 kg → round up to 1 × 25 kg sack.
Three-way match — the buying control that ties the purchase order to the goods received to the supplier invoice: a derived comparison with a small price tolerance on the gross amount (a per-currency configuration default). When the invoice arrives after the goods (see delivery note), the match completes when it attaches; and a capitalized asset line participates like any other — the €4,500 oven invoice is exactly the one worth matching. Walk-in receipts with no purchase order stay first-class — the link is optional.
Stock-aware procurement plan — the engine that proposes what to buy: it combines par-based reorder points with a demand forecast, nets against real on-hand and already-open orders, applies minimum-order and whole-unit rounding plus lead-time back-dating, and emits draft purchase orders grouped one per supplier. Why net against open orders: without it, the plan re-orders things already on the way.
Taught in: Procurement.
Sales and consumption¶
Sales ticket — the single front door through which every sale enters the stock side, no matter where it was born (a till, the app, a delivery platform, a spreadsheet, a photographed day sheet, a typed-in sale). It belongs to one restaurant and carries a restaurant-local business date stamped once; its lines name what sold and how many, and a sale whose price nobody wrote down still depletes stock — an unknown price is never confused with the deliberate €0 comp. Why one door: there is then one path to get right, not four.
Idempotency (count-once) — the guarantee that the same sale arriving twice depletes stock exactly once. A sale's identity is its restaurant plus the document's own id — never a free-text label — and a sale with no id at all gets one minted, counting once as its own sale. Why: tills and platforms retry, and a sale counted twice silently drives stock negative and inflates food cost.
Two sale-line targets — the two things a sale line can point at: a dish (a menu item), which is exploded down to its leaf ingredients, or a stocked item directly, which leaves one-for-one with no recipe.
Direct sale (material resale) — selling a stocked item as is, with no recipe: a one-for-one storage location → customer depletion at the item's own cost. Why it is ungated: whether something is "on the menu" is the selling side's business; stock's only question is whether there is any on hand to remove. Example: selling a surplus case of bottled water at cost.
Eager posting — the rule that consumption is recorded the instant the sale comes through the door, not deferred to a month-end batch. Why: on-hand is correct the moment a sale happens, food cost is real all month, and a problem with one sale surfaces against that one sale instead of as an avalanche at the close.
Station — a small per-company vocabulary of preparation points (seeded with kitchen and bar) tagged on each dish; every restaurant then maps each station to one of its own consumption warehouses. It is the dish-line default for consumption routing when no per-item override applies. Why on the dish: "a Negroni is made at the bar" is a fact about the dish, true at every restaurant; which bar warehouse that means is each restaurant's own mapping.
Consumption routing (three-level fallback) — how stock decides which warehouse a sale depletes — always one of the selling restaurant's own consumption warehouses: first a per-ingredient override, then the dish's station as that restaurant maps it (a bar drink draws from its bar warehouse, a kitchen dish from its kitchen warehouse), then the restaurant's mandatory default warehouse. Each level may also pin a storage location inside that warehouse — two restaurants sharing one central warehouse each drawing from their own location; unpinned, the warehouse's default storage location takes the draw. Why a fallback chain: a sale is then never left with nowhere to draw from.
Comp (€0 sale) — a comped plate, giveaway, or marketing tasting served to a guest, recorded as an ordinary sale line at zero price: the guest transaction happened, so no revenue but the full ingredient cost flows, to the customer side like any sale. Why no separate kind: the €0 price is the comp.
Internal consumption — the record of a live non-guest event in which the business consumed its own stock: a staff meal, a recipe test. Its own document, never a sales-ticket line — it says what was consumed (a dish unpacked through its recipe, or a raw item as-is), under exactly one consumption category, plus a free note. Routed and costed by the same machinery as a sale. Why its own event: no guest and no money expected — folding it into sales would overstate the guest-facing story and hide the company feeding itself.
Consumption category — an entry in the small per-company vocabulary that names internal consumption in reports, each created pointing permanently at one of two destinations: eaten — a person consumed the food, it leaves to the customer side (a staff meal); or used up — consumed by the process, it leaves to scrap (a recipe test). Every company starts with Staff meal and R&D and reshapes the list; history keeps pointing at the category it was recorded under. Why a vocabulary, not a fixed list: what internal consumption is called is operator reality; where it goes is the only part the books need pinned.
Restatement — correcting a posted sale by reversing the original and re-posting the corrected version (never editing history), so both stay visible. A late sale into an already-closed month is posted as a prior-period adjustment in the next open month; an unmapped name or recognized dish with no active recipe is quarantined rather than silently costed at zero.
Quarantine (the held-out line) — holding a line of an arriving document out of the ledger and flagging it when it cannot post honestly yet, instead of guessing or recording zero: a sold name that matches no known dish or stocked item, a sold dish with no active recipe on the sale date. It belongs to documents nobody is editing — a till's tickets arrive as they are — so the line waits rather than the document. Why never zero: a line costed at zero would quietly understate food cost and corrupt the close — invisibly, the worst kind of wrong; quarantine makes the gap loud and fixable.
Sold-name alias — a learned entry in the restaurant's sold-name vocabulary: a raw name the till prints ("Spag Bol"), remembered against the dish or stocked item an operator once confirmed it means; from then on the same printed name records as if it had matched exactly. Why confirmation-only: a wrong guessed mapping would miscost every future sale of that name invisibly, so only an answer a person gave is remembered.
Taught in: Sales & consumption.
Posting documents¶
Posting document — the mutable layer that creates movements. Each is a header with lines and a real lifecycle: a draft is freely editable with no effect on the books; posting emits immutable movements (the stock count is the exception — its posting freezes an observation and emits none; see stock count); amending reverses and reopens an editable copy; cancelling reverses. Why a mutable layer over an immutable ledger: operators need to draft, review, and correct, while the ledger needs to stay append-only.
Immutable ledger, mutable documents — the pairing of the two layers: the ledger of movements is never edited (corrections are contra-moves), while the documents that create them have a genuine draft-post-amend-cancel life.
Stock count — the document recording a physical count: a snapshot assertion of the absolute quantity physically there, not a change figure — and a pure observation: posting it freezes the sightings and moves no stock (the overage and shortage adjustments post later, as a separate gesture — see posting differences). Every count belongs to one storage location; a free-text label may preserve finer walk detail ("shelf 3"). Its scopes are full (every item at that location, zeros confirmed), partial (a subset — see cycle count), and opening (what the operator writes down, with silence read as zero — see opening count). A full or opening sheet also carries the warehouse's implements and its asset serial confirmation. How the sheet is walked and reconciled: Period close §2.
Pre-drawn count rows — the rows a count sheet supplies itself from the books: the warehouse's implements, and its asset serials from the register. A serial may not be added by hand — the register is the roster of identified units — while an implement sighting the book never knew about is recorded like any other. Why the sheet supplies them: a walk should confirm what the books already claim without anyone retyping it.
Transfer — the dated document that hands goods, or a fixed asset, from one warehouse to another. Stock rides two legs (storage location → transit → storage location), costed at the sending warehouse's average and re-blended into the receiving warehouse's pool; an asset line names one identified unit and simply moves which books carry it, with no movement and no transit leg. A document may mix both, or carry assets only. It is also the commissary-distribution document: what a commissary preps for a restaurant reaches that restaurant's own warehouse this way. Why two legs for stock: goods in transit belong to neither end while they travel. Why a document for an asset: two warehouses' books change hands, so the change needs a date both closes can honor.
Wastage — the document that records waste (storage location → scrap), under reasons that include expired (see expiry write-off). Each line names the storage location the quantity came off, so one document may span warehouses.
Sale-consumption — the document derived from a sales ticket: explode the dish, then post storage location → customer.
Production run — the document that records what a prep session produced: one document per session, one line per prep item made ("this morning: sauce 5 L, dough 12 kg"). It opens as a draft — the shift's working sheet, freely editable and with no effect on stock — and posting asserts the whole session at once, every line's move-pair (see production, the move-pair) or none, drawn from the session's storage location or the warehouse's default. A line's ingredients come from the active recipe scaled to the recorded output, or are stated by hand, which is how production is recorded before any recipe card exists. A draft dated inside a period blocks that period's close; a posted session is frozen, and corrections reverse the whole document and record a corrected one. Why a draft: the cook who writes the sheet is rarely the person who signs it off.
Measured usage (the session's sighting) — what a prep session records it actually got through, at document level ("flour, 12 kg total"), kept beside the theoretical total its lines add up to. It is a measurement, not an instruction: the books post the lines, never this. An operator who wants the measured number on the books edits the lines until they agree; a gap left standing turns up at the next count as ordinary shrinkage, with the session as the place to look.
Taught in: Stock ledger, Period close.
Period close and reconciliation¶
Accounting period — the close calendar, kept per company and warehouse, so each warehouse closes its own books on its own calendar in its own timezone. Why per-warehouse: a shared commissary and a restaurant's own warehouse may run on different clocks.
Close policy — a warehouse's declared close cadence: on demand, weekly, monthly, quarterly, or annual. It is a hint, never a gate — it says where the next boundary falls so a close date can be pre-filled and a due period flagged, while closing stays a deliberate act and any date remains legal. On demand is the count-to-count rhythm: no calendar boundary, and the date offered is that of the warehouse's latest full count. A warehouse holding only fixed assets, set to annual, is how the traditional yearly asset walk is expressed.
Period close — the gated boundary that finalizes a period: a full count observes what is physically there → whoever closes reconciles each item and posts the surviving differences → the close freezes the snapshot. Count wins: the closing average re-spreads value over the counted quantity, which is how shrinkage lands in cost of goods sold. The close binds the earliest posted, non-superseded full count dated on or after the period's last day — the count keeps its own date; the corrections carry the period's.
Posting differences — the deliberate human gesture that makes the book agree with a posted count: whoever reconciles accepts an item's surviving gap, per row or in bulk, and exactly that residual posts as an overage or shortage. Mid-period differences are dated the count's own day; at a close, the period's last day. Reversing differences is the append-only undo — available until the close seals them.
Unreconciled variance — an item whose gap between the qualifying count and the live book is non-zero and not yet accepted; recomputed live, never stored, melting as journal fixes land. The close refuses while any remains.
Closing snapshot (period snapshot) — the frozen record written by a successful period close: one period header and one item row for every pool the warehouse must carry forward, used as the next period's opening balance.
Overage — the adjustment posted when a count finds more than the book claims: a stock loss → storage location movement, valued at the current average (or, against an empty pool, at zero — value is never born without a priced document; see opening count). An implement is the carve-out: its surplus is recorded on the sheet but posts no overage at all, because the found units take their quantity and their cost from the priced receipt that was never entered.
Shortage — the adjustment posted when a count finds less than the book claims: a storage location → stock loss movement. It is the usual way theft, spoilage, and over-portioning enter the books, and what the closing re-spread turns into shrinkage inside cost of goods sold.
Over-receipt adjustment — the positive adjustment posted outside a count, when stock turns up before any count asserts it — for example, more goods physically arrived than the paperwork said. The count-derived case is the overage.
Cycle count — a partial stock count taken mid-period over a subset of items; its differences, once posted, are dated the count's own day and valued at the current average — the book is corrected on the spot. Cycle counts keep the book honest between closes; the close itself still requires a complete count per warehouse.
Untracked era — a standard warehouse's life before its opening count: every operational document posts freely, but ordinary counts, posted differences, and the period close are refused — there is no asserted truth to reconcile against. The opening count settles the era's net effect at its chosen date.
Opening count — the count that starts a warehouse's stock-keeping, and the one count that may carry costs: dated any past or present day (never the future), its lines assert counted quantities and unit costs, and posting settles whatever the books held before that date so each pool reads exactly the asserted figures — the untracked era's net effect lands as one profit-and-loss line on the opening date. It asserts a book rather than verifying one, so silence means zero: an item left off the form has its pool zeroed and its value extinguished at the boundary, and an empty opening asserts a warehouse holding nothing. It is also where an unplaced asset is taken onto these books. At most one live per warehouse (cancel or amend to redo), and it does not double as a close's full count. With the priced goods receipt, it is one of the only two doors value enters the books through.
Reconciliation — bringing the running book into agreement with the truth: the count → post-differences → close flow plus the self-check below.
Self-check (tie-out) — the close invariant that the sum of the detailed inventory records equals the inventory control total, within a small tolerance (a per-currency configuration default). The accounting name for the controlling-account guarantee.
Close-blocker — a condition that blocks a close until it is resolved: no opening count yet (the warehouse does not keep stock), no qualifying full count, an unreconciled variance row, an item the count never saw, an unconfirmed serial, unresolved sales or production lines, draft documents dated inside the period, or a sold dish with no costed recipe on its sale date. The system enumerates them; the agent only diagnoses and ranks, and the operator approves any correction.
Unconfirmed serial — the close-blocker for fixed assets: a unit on the warehouse's books that the qualifying count did not tick off. Exactly two resolutions, both ordinary gestures — amend the count and tick it (found), or dispose the asset (gone; its remaining book value becomes a loss on disposal). A unit registered after the qualifying count's date is exempt. Why no third option: a "missing but still depreciating" state is never cleared, so the books carry value nobody can point at.
Restaurant profit-and-loss — a restaurant's result for the period, built by rolling up the consumption charged to it; the company result aggregates the warehouses and restaurants. It is a roll-up, not a second place stock is valued (see valuation grain vs profit grain).
Taught in: Period close.
Fixed assets¶
Fixed-asset sub-ledger — the separate, deliberately slim set of books for capitalized items, kept apart from the stock ledger: the asset register, straight-line depreciation, disposal, and the serial confirmation on a warehouse's count. Anything more — jurisdictional book/tax depreciation, alternative methods — belongs to the operator's accounting system, which receives the figures across the financial boundary.
Asset register — the list of capitalized assets, one row per identified unit (tracked by serial number): code, serial, capitalized cost, in-service date, the warehouse whose books carry it and since when, the storage location it is kept in, and status. A register entry is created when a capitalized item is received on an ordinary goods receipt (one unit per receipt line — each oven is its own row) or entered directly at onboarding for units already in service. A capitalized item is bought like anything else; only the accounting consequence differs: an asset entry, no stock movement. What the register is: the record of what the company owns — whose books carry each unit is a separate decision (see asset placement).
Asset status — where a unit is in its life: acquired (on the books, not yet depreciating), in service (the depreciation clock runs), or disposed (off the books). Three states and no fourth — an asset is either on the books or it is not. Placement is a separate axis: see asset placement.
Asset placement — the decision recording which warehouse's books carry an identified unit, and from what date. A goods receipt places as it registers (its line names a storage location, and the warehouse follows); an asset already in the building is placed by that warehouse's opening count; afterwards an asset transfer hands the unit to another warehouse's books, which is also how a misplacement is corrected. There is no gesture back to unplaced: a unit returns to that state only by retracting the document that placed it — cancelling or amending its opening count — and not even then once those books have put it into service, because depreciation already accruing cannot belong to nobody.
Unplaced asset — a registered unit no warehouse's books have taken on: owned and costed, but on nobody's balance. No count offers its serial, no close asks anyone to find it, and it does not depreciate — it cannot be put into service at all, because an asset no books stand behind is not in service (nor is a unit still in its crate). Why the state exists: a business onboarding a shed full of assets knows what it owns long before it has decided whose books answer for each unit, and a forced guess would put serials on walks nobody expects them on.
Depreciation — spreading a capitalized asset's cost across its useful life, straight-line only, every eligible month posting exactly once and catching up automatically if a run was missed. Why straight-line only: anything fancier is the operator's accounting system's territory. The month-by-month arithmetic: Fixed assets §4.
Book value — the remaining carrying value of a fixed asset: capitalized cost minus accumulated depreciation. Derived from the register's posted entries; never stored as a separate figure, and never frozen by a close — so the figure for any date reconstructs from the record. Reaches zero (or salvage, if non-zero) when the asset is fully depreciated. A warehouse's balance is its stock pools, plus its implements pool, plus the book value of the assets its books carry. An unplaced asset's book value is in no warehouse's balance — it is reported at the company level, because the company owns the unit whether or not a warehouse claims it.
Disposal — retiring or selling a fixed asset, recognizing the gain or loss (proceeds minus book value at disposal date); this, not a stock movement, is how an asset leaves the books, and it is also one of the two answers to an unconfirmed serial. Why: selling an oven is asset disposal, not stock leaving a storage location.
Asset serial confirmation — the serial section of a warehouse's count: one checkbox per asset the warehouse's books carry, pre-drawn from the register and closed to hand-added rows. Posting freezes the ticks and changes nothing; an unticked box becomes an unconfirmed serial at the close. On an opening count the same section also offers the company's unplaced units, where a tick is not a confirmation but an asset placement. Why here and not in a separate ritual: the warehouse that carries the books is the one that walks the building, and its close policy already sets how often that happens.
Asset transfer — moving a fixed asset from one warehouse's books to another's: an asset line on an ordinary transfer document, dated, and legal only inside both warehouses' open periods. Posting hands over the books and assigns the receiving storage location (it named a place in the old warehouse); cancelling hands them back. Why not a field edit: an undated change would move an asset out of a period that had already closed over it.
Taught in: Fixed assets.
The financial boundary¶
Financial boundary — the line where the stock domain ends and the operator's accounting package (QuickBooks, Xero) begins: the system keeps no general ledger of its own and instead emits a small, fixed set of conceptual accounts for the books to import — inventory on-hand value, cost of goods sold split into food and packaging buckets, shrinkage, price-difference expense, input-VAT receivable, expense-on-receipt expense, implement write-off expense, depreciation expense, and gain or loss on asset disposal.
Taught in: Financial boundary.
Labor and payroll¶
Shift — the unit of worked time: one teammate, one restaurant, one business day, start to end minus unpaid break. The restaurant on the shift is the profit center the labor cost charges to — the same role it plays for a consumption movement.
Timesheet — the weekly per-restaurant approval envelope for shifts; approval freezes the hours inside it, making them the facts payroll reads (the labor counterpart of "count wins").
Employment terms — a teammate's pay, effective from a date: an hourly rate or a monthly salary in the company currency. A raise is a new row from a new date; rows are never edited, so any past payroll stays explainable from the terms in force then.
Payroll period / payroll run — the company-calendar period and the once-per-period run that turns approved hours into gross pay per teammate, refusing to post while deterministic blockers remain (an unapproved timesheet, a shift with no pay terms). Net pay, withholdings, and payslips belong to the operator's payroll provider — the same boundary the financial boundary draws for the books.
Prime cost — cost of goods sold plus gross labor, per restaurant per period: the restaurant's vital sign, and the number the labor domain exists to produce.
Direct labor — work with a countable path to specific output, e.g. a production day spent making prep items: these hours, this batch. Absorbed into the value of what was produced.
Indirect labor — work with no traceable path to any particular plate (cleaning, service, management, à-la-minute cooking during service). Stays a period-level restaurant cost; never spread onto dishes, because every spreading rule gives a different answer — the tell that none is true.
Labor absorption — the single seam where labor enters stock value: a production run carrying labor lines adds those wages to the produced item's value (recorded as its own explicit artifact, subtracted from the wages expense so nothing counts twice). From there the ordinary pool price and recipe explosion deliver it to every dish that uses the prep item.
Plate cost (of a dish) — the dish's food + packaging cost at real pool prices, including direct labor embedded via absorption and deliberately excluding any share of indirect labor: every euro in it is traceable to something that went into the plate. (COGS is the period aggregate of dishes actually sold — a month has a COGS, a dish has a plate cost. "Self-price" is a calque and not model vocabulary.)
Taught in: Labor & payroll.
Food attributes and food safety¶
Food attribute — a fact about what the food is — its nutrition, allergens, and shelf-life — as opposed to how much you have or what it cost. Food attributes roll up the recipe tree and post no stock movements; they touch the books at exactly one seam (expiry, below).
Nutrition profile — a per-100-gram nutrient set (calories, protein, carbohydrate, fat, sodium, fiber, sugars, saturated fat, cholesterol), with the per-serving figure derived at the dish from its serving weight. Any item may carry one, including a resale bottle of Coca-Cola.
Two-axis nutrition yield — the two independent reasons nutrition concentration shifts, both distinct from cost yield: output weight (whole-batch moisture change — 100 g of dry pasta becoming 250 g cooked dilutes the per-100-gram figures by 2.5), and consumed grams (the per-ingredient mass that actually enters the food — absorbed frying oil counts up, drained brine counts as zero). Why separate: they answer different questions and collapsing them mis-states nutrition.
Declared output weight — the weighed mass of a finished batch, the denominator every per-100-gram nutrition figure divides by. A batch counted in pieces or by the milliliter needs this weight declared before its nutrition means anything; without it the batch is one of the gaps that block a computed profile (see all-or-nothing computed nutrition). The weight is optional everywhere — a kitchen that doesn't publish nutrition never declares it, and nothing else (cost, production, stock) depends on it.
All-or-nothing computed nutrition — a dish or prep states computed figures only when every ingredient it draws is fully profiled: each leaf carrying all nine nutrients, every prep along the way weighable, the serving count known. Any single gap blanks the whole panel, and the food instead shows the short list of what to complete; a hand-typed figure is taken as a complete statement and always shows. Why blank, not partial: a confident-looking-but-incomplete label is worse than an honest blank.
Allergen — a declared allergen, set-unioned up the recipe tree to every prep item and dish that contains it; present (declared in) and may-contain (cross-contact) are distinct states that roll up distinctly. A restaurant is screened against its jurisdiction's allergen standard (below) — and EU law makes allergen information mandatory at the point of sale even for non-prepacked food. Why computed, never guessed: mislabeling is a legal and safety failure.
Allergen standard — the fixed list a jurisdiction regulates, the EU-14 or the US Big-9; a restaurant is screened against the list its country uses. The standard a statement was checked against is recorded on the statement, not re-chosen on each read, so an attestation stays legible as it was made even if the business later changes country — the stored allergen facts remain the single canonical set, and the standard is only the lens they are read through.
Shelf-life — how long a product stays safe and usable. Recorded as a use-by (a hard safety date) at the item's default storage condition, with an adjustment for once a pack is opened. For a made item it is recipe-derived — capped at its shortest-lived component's remaining life — and recalculated when the recipe changes.
Default storage condition — the storage condition (frozen, chilled, or ambient) an item is assumed to be kept under, carried on the item itself; it selects the shelf-life window that stamps a lot's expiry at receipt. Moving a lot between conditions (freezer to fridge) is not modeled. Why a default: a receipt must be able to stamp an expiry without asking where every case will end up sitting.
Two-stage shelf-life advisory — the way a shelf-life is recalculated: first a classifier reads the recipe's evidence into a fixed set of risk flags and is forbidden from naming a day count; then a cited, deterministic policy table maps those flags to a recommended and maximum number of days. Why two stages: it keeps the judgment that needs a food-safety source out of a free-form guess.
Risk flag / mitigation flag — a risk flag is one entry in the fixed vocabulary the classifier emits (an ingredient risk, a preparation, a process); a mitigation flag (such as "rapidly chilled, extends 2 days to 4") is surfaced only when ticking it would actually change the recommendation.
Food-safety policy table — the cited, data-driven, per-jurisdiction rule set that maps risk flags to shelf-life days (US food code versus EU rules). It is versioned data, so tuning a day-cap is an edit, not a rebuild. Two jurisdiction sets ship: a US set that is live, and an EU/Portugal set that is review-gated — every EU/Portugal rule is held for review, so the advisor only ever suggests review on those until a person signs the citations and day-caps off. The set a kitchen sees follows its country (Portugal gets the EU/Portugal set; everywhere else, including other EU countries until their own set lands, gets the US set). The advisor answers for any storage condition — frozen and ambient have a single conservative review-gated fallback rather than a full rulebook yet — and it only ever suggests; a person still sets the day count.
Min-of-children cap — the rule that a made item's shelf-life is no longer than its shortest-lived component's remaining life (the most-restrictive-component principle), computed on the shared rollup. Example: a bowl built from a 3-day chicken prep item and a 7-day dressing caps at 3 days.
First-expiry-first-out (FEFO) — the order for issuing lot-tracked stock: take the earliest-expiring lot first (it supersedes plain first-in-first-out). It is possible because lots carry an expiry at the lot-detail level. It is one deterministic rule, never an operator setting: lots without an expiry date allocate last, oldest-received first — so FEFO degrades to plain FIFO exactly where expiry doesn't apply. FEFO is also an inference, not a data-entry step: it mirrors the kitchen's physical rotation (front package first), no one registers per-package openings, and the stock count is what re-syncs the per-lot book to what is physically there.
Lot expiry — a lot's expiry date, set at receipt as receipt or production date plus shelf-life for the item's default storage condition (the use-by date is the hard one), living at the lot-detail level — the single seam where shelf-life meets the books.
Expiry write-off — removing a lapsed lot through an ordinary wastage movement (storage location → scrap, reason expired) at the lot's cost. No new mechanism: expired stock is spoilage with a specific reason.
Taught in: Food attributes (the §14.5 expiry seam is the one part inside the stock model).
Catalog and preparation¶
Dish — a prepared menu item, with its price, status, tags, nutrition and allergen facts, photos, descriptive text, and a station tag (kitchen, bar) that tells the stock side where a sale of it draws from.
Recipe version — one frozen edition of a recipe. A draft is fully editable; once active it locks its composition and output facts while its descriptive text, steps, media, and notes stay editable. Version two and later must carry a short change note explaining what changed from the previous version. Why versioned: a sale must always be costable against the recipe as it stood on its day (see date-correct explosion).
Active-from / recipe actuality — the date a recipe version takes effect; the recipe in force for a dish on any date is the active version with the latest active-from on or before that date. This is the anchor that makes a sale cost against the right recipe. Activation may be backdated — the new version's effective date must come strictly after the latest active version's, but it may lie in the past — which is how a dish that sold before its recipe was recorded gets one without rewriting history (already-posted consumption is never re-exploded).
Completeness score — an advisory 0–100 readiness score for a recipe, built from weighted checks (ingredients, steps, header facts, media, packaging). It guides the operator and never blocks activation. It scores the authored production document only — never how many languages a translation covers, since translations are a reading-side convenience the author never has to think about.
Recipe line — one component row in a recipe, pointing at either an item or a pinned nested recipe version (a bill-of-materials line). The two propagate differently: an item reference resolves that item's own recipe by date at every explosion, so child edits flow to every dish automatically; a pinned nested version is frozen until the parent is re-versioned. An ingredient line may point only at an item whose recipe role is ingredient or producible; packaging items ride separate packaging rows (see Recipe role).
Tag — a per-company, keyed taxonomy label for dishes, with an authored name the operator types in their own language; its category states the tag's role and the seeded standard catalog gives every new company a baseline vocabulary, while visual styling belongs to a future storefront presentation model.
Authored text — the only text anyone writes: a plain value (a description, a step, a tag name) typed in whatever language the writer happens to speak, carrying no language label. The system never needs to know which language it is. Authored text is the single source of truth; editing it is the only way to change what a dish says.
Derived translation — a machine-made rendition of a piece of authored text into one of the company's chosen reading languages. Translations are a disposable cache: regenerated whenever the authored text changes, never hand-edited, always safe to discard. Each carries the content version of the authored text it was made from, so a reader can tell at a glance whether a rendition is up to date or waiting to catch up. Regeneration runs in the background after a save, not in the moment, so a just-edited text reads as up to date in the language it was typed in and catches up in the others shortly after; a reader can also ask for a refresh on demand. The translator stays faithful — it carries the words across, never restyling, summarizing, or inventing, and it keeps numbers, times, temperatures, and brand and equipment names exactly as written.
Content version — a single counter on a recipe or tag that ticks up each time any of its authored text actually changes. A derived translation is current when it was made from the same version, and stale when it lags behind — the one fact that tells a reader a rendition is out of date.
Auto-translation languages — the set of reading languages a company turns on. Empty by default: with no languages chosen the system translates nothing and costs nothing. Adding a language asks the system to keep a rendition of every authored text in that language; removing one simply stops using the renditions it already made, never deleting any authored text.
Copy proposal — a tidy-up the system offers for a recipe's prose. On request it reads the authored description, notes, and step text and proposes a cleaner version of each in the company's kitchen voice — tighter, more concrete, on style — while holding every number, time, temperature, and brand, dish, or equipment name exactly as written and inventing nothing. It is purely a suggestion: each field is shown side by side, original against proposed, and nothing changes until the writer accepts it (and they can edit it first). Accepting is an ordinary edit of the authored text, so it is the same act as typing — which is why it, too, refreshes the translations. The proposal is a one-shot aid, never stored and never applied on its own; tags get no such tidy-up. (Distinct from a derived translation, which carries the same words into another language; a copy proposal stays in the language it was written in and changes the wording.)
Taught in: Menu & catalog, Recipes & production.
Tenancy¶
Company — the tenant and the top isolation boundary: it owns all of one business's data (catalog, inventory, recipes, files, and the people who operate it). Every company-scoped record is filtered to the resolved company on read and stamped with it on write.
Company scoping (fail-closed) — the rule that, with no resolved company, a company-scoped read and a company-scoped write both refuse rather than returning or defaulting another tenant's data. The resolved company comes from the authenticated session, never from a value the client supplies.
Currency — the single currency a company keeps its money in (one per company; multi-currency receipts are out of scope). It is fixed at registration and never changes, since changing it would re-interpret every number already stored.
Tax regime — the per-company setting (US or EU at first) that selects how recoverable input VAT is handled at receipt (see recoverable input VAT).
Restaurant — a company-scoped site that is the profit center (see profit center): the grain that food cost and margin are attributed to, linked many-to-many to warehouses, stamped onto each consumption, and never the owner of a stock pool. It carries its own optional timezone, which is what stamps a sale with the right business date. It is a data dimension, not an authorization boundary — that boundary is the company.
Taught in: Scope & locations, Menu & catalog.
Agent-surfaced findings¶
Dough finding — the operator-facing name for an issue the agent surfaces: a quarantined unmapped sale, a close-blocker diagnosis, an invoice-line discrepancy. Why a dedicated name: findings are spoken about to the operator in agent terms, not in the internal vocabulary of how they were computed. (Distinct from a stock count's overage or shortage adjustments, which are ledger facts, not agent-surfaced issues.)
See also¶
- Stock ledger — the journal of moves these terms name.
- Scope & locations — warehouse (where value lives) vs restaurant (whose profit-and-loss it is), and the routing in between.
- Item model & policies — how an item knows how to behave (the accounting treatment and the rest of the item cluster).
- Units of measure — the dimensions, base units, and the convert-to-base boundary.
- Costing & valuation — weighted-average cost, landed cost, and the tax split.
- Recipes & production — the recipe explosion, prep items, and yield.
- Procurement — purchase orders, par levels, and the three-way match.
- Sales & consumption — how a sale becomes stock leaving a storage location.
- Period close — the period close that reconciles the book against the count.
- Fixed assets — the separate books for capitalized assets.
- Financial boundary — what the stock domain hands to the operator's books.
- Food attributes — nutrition, allergens, and shelf-life off the recipe tree.
- Menu & catalog — the catalog — dishes, items, categories, measures, supplier articles, and recipes — in full.
- Invariants — the cross-cutting rules these terms must obey.