Sales & Consumption — how a sale turns into stock leaving the warehouse¶

What this covers. When a restaurant sells something, the ingredients behind it have to leave inventory — at a real cost, charged to the right restaurant's bottom line. This explains how a sale that happened somewhere else (a till, the app, a delivery platform, a spreadsheet, or a manager typing it in) becomes that stock depletion: the one-way line between "selling" and "stock," the single front door every sale comes through, the one item target with two honest depletion behaviors (stocked one-for-one or made-to-order recipe explosion), where the cost is drawn from and who it's charged to, why it's recorded the instant it happens, how a comped plate is still a sale while a staff meal or a recipe test is a separate recorded event of its own, and what happens when a sale is corrected, arrives late, or names something the system doesn't recognize.

1. A sale is two different events¶

The same sale means two completely different things to two parts of the business.

To the selling side — the till, the app, the delivery platform — a sale is a transaction with a customer: a price, a discount, a tip, a tax collected, a payment. That's the money coming in.

To the stock side — the warehouse and the books — the same sale is a depletion: real ingredients physically left the building, and they had a cost. A sold plate of carbonara means spaghetti, guanciale, egg, and cheese are no longer in stock. That's the cost going out.

Both events belong to the same sale, but have separate evidence. Physical lines say what was consumed; financial statements say what was charged, discounted, collected for someone else, or paid to a delivery provider. A printed line price alone does not establish whether it includes tax or a discount. Unclassified money does not establish revenue or expenses. A depletion never depends on a price, and a confirmed financial fact never waits for a recipe to be mapped.

Customer money and the restaurant's earnings¶

A customer's total is not all restaurant revenue. Product, service and the restaurant's own delivery revenue stay separate from collected tax, tips payable to staff and delivery money collected on another party's behalf. Platform commission, payment fees and delivery costs are expenses, not negative product sales. Reported paid, refunded and payout totals are reconciliation evidence; they do not add a second copy of the same revenue.

For example, goods of $100 less a $10 discount, plus $9 tax and $5 tips, produce a $104 customer total and $90 revenue. A $3 platform commission leaves $87 before food cost. A missing commission is unknown, not a known zero. Estimates do not establish confirmed revenue or expenses.

A later refund or delivery invoice has its own economic date. It changes the appropriate money buckets without returning ingredients to stock. Individual sales and cumulative totals covering the same activity must not be counted twice.

Completeness is a separate assertion. Known amounts can be reported even when other amounts are missing, but the report remains incomplete. A partially allocated refund keeps customer amounts incomplete even when the original sale was fully described. A posted stock line does not establish financial completeness, and a held stock line does not make confirmed revenue disappear.

2. The boundary is one-way (and why that matters)¶

The selling side tells the stock side "this was sold." The stock side never talks back, and it never reaches into the customer transaction.

The selling system produces sales facts; the stock system consumes them. Stock doesn't know the menu price; the till doesn't know the recipe or what a kilogram of flour is worth.

Why draw the line so firmly? Because the two sides change for different reasons. The restaurant's food-cost math must not wobble because someone ran a promotion or edited a menu price. The till must not need to understand recipes or average costs to ring up a sandwich. A one-way boundary means the stock side has exactly one thing to get right — turning "X was sold" into "these ingredients left, at this cost, charged here" — and it does that identically whether the sale came from the app, a delivery platform, a spreadsheet, or a manager's keyboard. (What the customer was charged rides the record — the check must add up — but the stock side never reads a price to do its job. The selling side remains responsible for payments, tax calculation and settlement. Their confirmed amounts may accompany the sale as financial evidence for reporting; stock never recalculates them.)

3. One front door for every sale¶

No matter where a sale is born, it enters the stock side through a single front door — one kind of record we'll call a sales ticket. The app feed, a delivery platform, a spreadsheet of last month's sales, a hand-typed sale: all of them become sales tickets, and from that point on they're handled identically. There is one path to get right, not four.

A good front door has to guard against a specific way the books get corrupted: landing on the wrong day. A delivery order placed at 23:55 and handed over at 00:10 straddles midnight; a platform's timestamp may be in a different timezone than the restaurant. If the depletion is recorded on the wrong calendar day, it falls into the wrong accounting month and throws off the month-end count. The fix: the moment a sale comes through the door it is stamped with a business date in the restaurant's own local clock, not the raw timestamp and not "the day we happened to import it."

That is a boundary problem — it happens at the instant a foreign sale crosses into the books — so it is solved right there at the door, not patched downstream.

A ticket may also record which storefront it sold through. That attribution is optional enrichment, freely corrected at any time and never a condition on any sale — the rule and its why live in Menus & storefronts; it matters here because a set storefront sharpens name recognition (§8).

4. One item target, two sale behaviors¶

Every sale line resolves to one item. The item's stable policy facts decide which of exactly two depletion behaviors the sale has. Sellability is therefore a derived meaning — "does the sale verb have an honest depletion?" — never a category name or a freely edited label.

(a) A stocked item — deplete it directly¶

A stocked item leaves its warehouse one-for-one at its own pool cost. This covers a bottle of wine, a case of surplus tomatoes, a can of cola, and a made-ahead grab-and-go product. A stocked producible item still follows this arm: its inputs were consumed when the batch was produced, so exploding its recipe again at sale would count them twice.

A stocked sale must resolve to a real unit. A till may say only "three waters," while stock knows water in milliliters; if one bottle is 250 ml, three sales deplete 750 ml. The item's ordinary stock unit supplies that physical meaning when the source omitted one. If the item has no usable unit, the sale waits rather than turning a count of containers into a false stock quantity.

(b) A made-to-order item — explode the recipe¶

A made-to-order item is a phantom — nothing of it is held, nothing of it is bought, and it never materializes — so what its sale spends is whatever its recipe spends. That covers the dish cooked when the order lands and, just as squarely, the service: an hour of a meeting room, a photo session, a consulting call. Nothing about the sale changes between them; only the recipe does. A sale is not the only thing that asks for a phantom: an internal use (§7) and a write-off (see Stock ledger) explode exactly the same recipe the same way, and the three differ only in where the cost is charged. Its sale line counts a unit like any other — the item's base unit — and the sale spends the share of a batch that quantity is of the recipe's declared output (see Recipes & production): one sold piece of a dish counted in pieces is one portion, while 150 g of a sauce whose batch is 4 × 150 g is a quarter of a batch. The system resolves the recipe in force on the sale's business date, resolves the concrete build the sale declares, walks it down to its raw leaves, and scales them by that share.

Worked example. 12 Carbonaras sold. The recipe, per portion, is 110 g spaghetti, 45 g guanciale, 1 egg, 18 g pecorino. Twelve sold units — twelve declared portions — deplete 1.32 kg spaghetti, 540 g guanciale, 12 eggs, 216 g pecorino — each removed from stock at what that ingredient is currently worth.

If the recipe contains a prep item — something the restaurant makes and stocks in advance, such as dough or base sauce — the explosion stops there and depletes the prep item at its pool cost. It was already made and costed in production; walking through it again would double-count.

A recipe in force may be empty, and then the sale spends nothing. That is the service's ordinary shape: the booking is recorded in full, its revenue counted, and its cost is a known zero rather than an unknown one. The line is as settled as any other — a sale that moves no stock is still a sale, not a sale that failed to record — and the close reads it as answered. A missing recipe leaves a sale waiting, because that is silence, not an answer. When the silence is only about a part — a made-to-order item inside the recipe has no recipe of its own on the sale's date, or a sub-recipe inside never says how much one batch makes — the sale spends the rest and stays held, as it does for a choice nobody made.

Where a sale carries no concrete choice, a matrix recipe uses its base build: fixed and removable lines remain, addable lines stay out, and slots stay empty. This is especially important for a feed detached from any menu, such as an external till report. Extras from that report arrive as their own item lines; the books never guess which dish they belonged to or quietly borrow a menu default.

An aggregate report may count twenty oat-milk substitutions without saying which drinks received them. A proposed allocation can help the operator answer: assign one counter to one compatible sold portion, starting with the most-sold drink, then show the resulting builds as an estimate. A second modifier may belong to the same portion, such as a decaf cappuccino with oat milk. Existing declared choices stand; an unconfigured required choice still needs an answer. Acceptance makes the proposed choices the operator's declaration, and only then do those builds drive consumption. The counter's printed revenue remains on the ticket, without a second ingredient draw. Any excess counter quantity stays held, unless a person has taught its name as selling nothing stocked (§8) — then it settles as taught; either way it does not prevent recording the part that has been answered.

A sale is held until its build answers every required choice. A saved choice that no longer fits the recipe in force is unanswered too. Held says the answer is not final. The sale spends what its build already answers — the fixed lines, the chosen options, the packaging — and draws nothing for the choice nobody made. A cappuccino sold with milk chosen and coffee not chosen spends the milk now; the coffee is neither guessed nor drawn until someone names it, and the completing answer withdraws the partial draw and records the whole build in its place, so nothing is spent twice. A stale choice answers nothing and spends nothing. The line's unresolved stock cost keeps the margin provisional; confirmed revenue remains reportable independently. An optional empty slot needs no answer. A recipe correction can return an open sale to this state: its old consumption is withdrawn and the part the live recipe still answers is recorded again, while its saved choices remain available to answer again. See the close blockers.

No third sale behavior is inferred. A consumable, a counted consumable, a small tool, or a fixed asset remains outside the sales door. A counted consumable may be used directly inside the business (§7), but its zero-value quantity book does not turn it into merchandise.

5. Where the cost comes from, and who it's charged to¶

Every depletion answers two questions: which stock did it come out of, and whose profit-and-loss does the cost land on. These are different questions with different answers, and keeping them apart is what lets one shared warehouse serve several restaurants honestly.

Which stock — the warehouse. Ingredients are drawn from a specific warehouse and priced at that warehouse's average cost. The warehouse is where value lives.
Whose P&L — the restaurant. The cost is charged to the restaurant that made the sale — its profit-and-loss, its food-cost number. The restaurant is who the margin belongs to.

Each restaurant selects one operating-stock warehouse for consumption, with a concrete default storage location and optional station and item exceptions inside that warehouse. Several restaurants may select the same warehouse while drawing quantities from different storage locations and sharing its period price.

Worked example. Restaurant A's Negroni draws gin, Campari, and vermouth from the bar storage location, while an orange-peel exception draws from the kitchen storage location in the same warehouse. Every ingredient uses that warehouse's period price and is charged to Restaurant A's profit-and-loss.

Routing chooses a storage location in this order:

A depleted-item exception, such as the orange peel's kitchen storage location.
The sold item's station, mapped to a storage location by the restaurant.
The restaurant's default storage location, which catches unmapped stations and items without an exception.

The default is a concrete source choice: changing the warehouse's general default does not redirect the restaurant's consumption. A storage location used by current consumption routing stays active until those routes are assigned elsewhere.

This three-level chain applies to recipe leaves. A directly sold stocked item is stationless: its own routing override wins when present, otherwise the restaurant's default storage location supplies it. Station answers who makes a product; it does not invent preparation work for a bottle pulled from stock.

Changing a restaurant's routing or a made-to-order item's station immediately moves its affected sales, internal consumption and dish write-offs — those lines that name no location of their own — to the newly resolved storage locations where both the old and new books remain open, preserving the quantities already consumed. Within one warehouse the cost stays the same; moving to another warehouse uses that warehouse's cost, without recalculating the recipe. Consumption settled by a close or belonging to history before a warehouse's opening date stays where it was.

One consequence worth stating plainly: a sale never depletes a warehouse the goods have already left. Stock that a commissary preps for a restaurant reaches that restaurant's own stores by an explicit transfer before it is ever consumed (see Scope & locations).

6. Record it now, not at month-end¶

The instant a sale comes through the door, the stock is depleted — immediately, not deferred to a month-end batch.

This is what makes the inventory count live: on-hand is correct the moment a sale happens, the food-cost number is real all month, and the reorder math works from the truth rather than a guess. It also means a problem with one sale (say, a sold name the catalog doesn't recognize — §8) surfaces right then, against that one sale, instead of as an avalanche at month-end. The close then becomes a calm reconciliation of what was already recorded against a physical count — not a frantic from-scratch calculation.

7. A sale expects money; everything else is internal consumption¶

A sales ticket records exactly one kind of event: a customer transaction. Money is expected — but expected is not received, and zero is a legal amount. A price can also be simply unknown — a day sheet photographed off a till, a spreadsheet column nobody filled in — and an unknown price is never confused with a zero one: the food was made either way, so the sale still depletes stock; it just doesn't claim the customer paid nothing. A comped dessert for an unhappy customer, a giveaway plate, a marketing tasting served to a customer: the transaction happened, so it is a sale at €0 — no revenue, but the ingredients deplete and the cost lands exactly as if the customer had paid. The €0 price is the comp; there is no separate kind of event for it. Every sale, paid or comped, leaves to the customer side of the books (the virtual destination consumption departs to; see Stock ledger) — a customer consumed the food.

What a ticket must never carry is consumption that was never customer-facing. "Maria ate a burger before her shift," "we burned two batches testing the new mole recipe" — no customer, no transaction, no money expected. These are live events in their own right, and each is recorded as its own document: an internal consumption. Its own door admits three behaviors:

a stocked item depletes directly in a unit, at its pool cost;
a counted consumable depletes directly in a unit, every leg worth zero; and
a made-to-order item explodes the build it declares for its dated recipe, or the base build when it declares none, spending the share of a batch the quantity consumed is of the recipe's declared output — the very explosion a sale of it performs (§4), which is what makes the staff meal and the plate cooked for a photograph ordinary events rather than special ones.

A row whose required choice is unanswered, or whose saved choice the dated recipe no longer fits, spends only what its build answers and holds the close — the same rule a held sale follows (§4).

This door is wider than the sales door: a counted consumable — never a sale — is still directly usable inside the business. The routing and costing reuse the same consumption machinery; only the event's meaning is different. Internal consumption follows the restaurant's consumption routing. An item exception can source gin from the bar for both sales and staff meals; recipe ingredients each follow their own depleted-item exception when one exists. A line may instead name the storage location it was taken from — the staff meal cooked in the commissary rather than where routing would send it. The named location then answers for the whole line, a dish's ingredients included, and a later routing change leaves it where it was put; the consumption is still charged to the restaurant. A write-off line follows the same placement rule (see Stock ledger).

Every internal consumption carries exactly one consumption category — an entry in a small vocabulary the company owns, not a fixed list built into the system. A category does two jobs:

It names the consumption in reports. Every company starts with Staff meal and R&D, and reshapes the list to its own reality — a caterer adds "tasting/samples," another adds "donation" or "owner's draw," a taqueria with no R&D archives that entry. Renaming and archiving are safe: history keeps pointing at the category it was recorded under.
It says where the food went. Each category is created pointing at one of two destinations, and that choice is permanent for the category's life: eaten — a person consumed the food, so it leaves to the customer side like any meal (a staff meal); or used up — consumed by the process, nobody fed, so it leaves to scrap, the same destination recorded waste goes to (a recipe test). A destination that could be edited would silently re-route every future posting, so a category whose destination was wrong is archived and replaced, never bent.

To stock, all of it is the same primitive — ingredients left a warehouse, at a cost, charged to a restaurant. The split carries the meaning: a sale (even at €0) belongs to the customer-facing story and the food-cost-of-sales number; internal consumption is the company feeding itself or its process, reported under the company's own names for it.

8. When things change, arrive late, or don't add up¶

Three things go wrong often enough that the domain handles each on purpose, rather than hoping they don't happen.

A sale is corrected. A ticket that should not exist at all — a duplicate photograph, a document that was never a sale — is cancelled: every depletion it made is withdrawn, while the source record stays to show what was taken back. A ticket that did happen but was written down wrong is corrected instead. A platform amends an order from 12 to 10; a manager fixes a mis-typed sale; a shift report is filed under yesterday, or against the restaurant next door. While the month is open the correction is simply made: the original depletion is withdrawn and the corrected one recorded in its place, so the book shows what was really sold rather than a sum a reader has to work out.

The physical day and restaurant are correctable the same way while no active financial statement fixes the restaurant attribution. Existing financial dates are separate facts: changing a physical date does not rewrite them. The depletion moves with a physical correction — handed back where it stood, drawn again where the sale now belongs, out of that restaurant's own stores. It is valued like any other fresh depletion: the provisional figure while the month runs, the period price once that month closes. So moving a sale within its own month changes what it finally costs not at all; moving it into another month hands it that month's price. The month it leaves must be open, because its draw is taken back; moving it into a sealed month takes that draw back and records the revenue alone. Where a sale came from decides none of this. A ticket typed by hand and one that arrived from a till are the same document once they exist; a close in force is what keeps the period settled.

What a correction never rewrites is the id the sale was recognized by. That id travels with the ticket, so a ticket cannot be moved into a restaurant that has already counted the same arrival — that would be the double-count the front door exists to prevent, arriving by the back. Recognition is per restaurant, though: a ticket corrected onto another restaurant's books is no longer a repeat in the one it left, so the same export re-sent to the shop it left arrives there as a new ticket — a document that should not exist, and is cancelled like any other.

Worked example. "Carbonara ×12" was recorded, then amended to ×10. The ticket is corrected to ×10: the original depletion is withdrawn, the ingredients for 10 portions are recorded in its place, and that is what the book reads. Had the whole shift been filed against the wrong restaurant, the same thing happens at a larger scale: the ticket moves, and every depletion it made leaves the first restaurant's books and appears in the second's, drawn from the stores that restaurant sells out of.

A sale arrives after its month is closed. Its revenue belongs to its business date, but it draws no stock. The closed month's count already included the goods that physically left: drawing them again in the next month would misstate both months. The same rule applies when a held sale is answered after its date has been sealed. Reopening the month lays the draw on its date. Until then the sale's cost belongs to no month: the count already priced it as variance, so the sealed month's food-cost ratio reads lower by that sale.

A sale cannot be mapped or costed. A platform sells "Spag Bol" but the catalog calls the item "Spaghetti Bolognese", or a made-to-order item is selling before its recipe exists. The sale is held: its stock cost is incomplete and close refuses until its target, recipe and build are all answered (§4). Confirmed financial amounts remain reportable. The answer that completes the build records the remaining physical consequences.

The recipe can be missing in two ways, and they are put right in different places: the sold item may have no recipe at all — someone must write and schedule one — or a recipe whose schedule begins after the sale, put right by moving the version's effective date back to cover it (see Recipes & production). Either way, once the schedule answers for the sale's date, the held sale records normally.

Mapping a name also teaches. The confirmed answer — "Spag Bol" means Spaghetti Bolognese, "water" means one 250 ml bottle — joins the company's sold-name vocabulary, one shared list however many restaurants sell under those names; a till prints the same few dozen names every day, so one answer is enough, and tomorrow's report records that name without asking again. Only a person's confirmation teaches; a machine's guess never does, because a wrong remembered mapping would quietly miscost every future sale of that name — the same invisible wrongness the hold exists to prevent.

A person may also teach the complete answer: the item, its measure, and the explicitly chosen build. That lesson answers other waiting sales carrying the exact same printed name and future arrivals, including names previously waiting for modifier review. It can instead be applied to a selected group without teaching anything for the future. Already answered sales and other rows of the current ticket are not swept into a name-based correction.

A complete taught build is an explicit answer and precedes name-only recognition. It is not a frozen recipe: the selected components are judged against the recipe in force on each sale's date. An incomplete or stale choice leaves that sale held; it never becomes the new recipe's default behind the operator's back. Different dated recipes remain different contexts even when their sales share a printed name.

Name recognition preserves a deliberate precedence. An exact made-to-order item wins first; then the company's learned alias or the verdict that the name sells nothing stocked; then the names standing on the served menu; then an exact stocked item. This keeps familiar dish names direct while allowing an operator to teach that ambiguous till text is a charge or a differently named product before a same-named stock item captures it.

A ticket attributed to a storefront reads its names against the menu that storefront was serving when the sale happened. The served menu narrows recognition, never gates it: where an item's exact name finds two candidates, the one standing on the served menu restores uniqueness; the names on the menu answer after the learned vocabulary, so a taught lesson or verdict still outranks them — a levy taught as a charge stays a charge even when a same-named menu item is on sale; and a lesson taught while a menu is served belongs to that menu, answering its storefronts without changing what the same name means everywhere else. A line resolved under a served menu also remembers which menu item it sold as — the resolution that actually happened, kept as written even if the ticket's storefront is later corrected. What the menu never does is exclude: an item sold outside the served menu — a staff meal, an off-menu special, a half-built menu — records as itself, with no menu item remembered. Holding a line answers ambiguity, never absence: the one wait the menu adds is a catalog item the served menu sells as more than one menu item (a large and a small pour of one wine), where a person says which was sold and the answer teaches the vocabulary at the menu-item grain.

A lesson can also be changed. A name taught onto the wrong thing keeps binding every later sale of it — quietly, and looking perfectly correct — so the sold-name vocabulary is something the business can read back, correct, and forget from. A name can be pointed at what it really means, or dropped so that it arrives unknown again and asks. Both are answers about the future: neither corrects what has already happened, because what left stock under the old meaning stays recorded and is put right the way any recorded sale is.

Which of the two to reach for depends on whether anyone still knows the answer. Correcting is the ordinary move — the mistake is usually noticed because someone worked out what the name should have meant. Forgetting is for the name nobody can vouch for: better it ask again than be guessed at twice. What forgetting is not is a way of asking later on purpose — between dropping a name and answering it afresh every sale of it is held out of the ledger, a day on a name that sells daily and longer on one nobody is watching.

A sale still waiting on the name is usually answered on the sale itself rather than in the vocabulary, because that answer does both at once: it says what the name means from now on and records every sale that was waiting under it.

But a name is not always worth one answer. A till that prints "COMBO" over a different plate every hour is not teaching anybody anything, and the right answer there is a judgement about that sale rather than a lesson about the text. So a waiting sale can also be answered on its own: it records, its neighbors carrying the same text keep waiting for their own answers, and the vocabulary learns nothing — because nothing about it was general enough to learn.

Not everything a till prints is a sale of anything anyone stocks. A service charge, a tip, a cover, a rounding line: the customer paid it and it names nothing the business keeps a catalog entry for, so there is no item on earth to point it at. That is an answer in its own right — this text sells nothing stocked — alongside the item target. It is not the answer for something the business genuinely sells and has catalogued: a room hour, a delivery the operator prices as a product of its own. Those are items like any other, made to order, and they record as sales — with an empty recipe if the sale spends nothing. The verdict is for text that never had an item behind it, not for an item whose recipe happens to be empty. Answered that way, the sale is settled where it stands: nothing is drawn from stock, and the money stays on the sale as source evidence. Its financial meaning still needs classification: a service charge can be revenue, while a tip payable to staff is a separate bucket. The non-stock verdict alone says nothing about that distinction. Said about the name, it is a lesson like any other, which is what a levy needs — it prints on every dine-in check, and answering it once is the difference between a list of waiting sales that means something and one nobody can see past. Said about one sale, it teaches nothing, which is what the levy that reads differently every time it prints needs ("Service charge, 4 customers" is never the same text twice).

An exact made-to-order item is recognized before any lesson is read, so a lesson under the same text would be dead the day it was given and is refused. An exact stocked item comes after the learned vocabulary on purpose: the vocabulary is what lets the business say that a printed word which resembles stock actually means a charge or another item.

A learned name states both the item and the measure one of it sold in, so no later ticket has to guess a quantity.

Resolving is not forcing. Mapping the name answers what sold, but the line still has to carry honest sale semantics. A made-to-order target still needs a recipe on the sale date; a stocked target still needs a usable unit; an item outside the two sale arms remains refused. Too little book stock is not one of these reasons — a fact may drive the pool negative and the close will demand its explanation. A held line therefore waits on missing meaning, never on the book's claim about quantity.

An answer given while a line waits is not yet final. Someone mapping a stack of unfamiliar names will occasionally pick the wrong item, or a made-to-order item that turns out to have no recipe to cost itself with — so answering the same name again replaces the earlier answer on every line still holding it and re-teaches the vocabulary with it, and answering one waiting sale again replaces only what that sale says.

An answer can also be taken back, leaving the sale waiting with nothing said about it. It is the way out of a wrong answer nobody can yet replace: the sale goes back among the unanswered, where it is visibly waiting rather than quietly describing something nobody sold. Withdrawing an answer says nothing about the name — though when the lesson is what gave the wrong answer, it can be dropped in the same breath, and only ever the lesson for the text that sale arrived under.

What keeps an answer settled is a close in force. While its period is open the sale is answered again, the draw it made withdrawn and the corrected one recorded in its place. So a charge settled as selling nothing stocked can be re-answered, and the day someone works out that "Delivery" was a real plate all along, answering the name records every sale that settled under the mistake. Without that, an answer of that kind would seal itself shut once it was wrong — no sale would ever wait under the name again, so nobody would be asked, and the cost of those plates would be gone from the books for good.

The name the till printed is never given up. It stays with the line whether the line waited or recorded the moment it arrived — it is what the till actually said, and a mapping sits beside it rather than in its place. That is what keeps a mis-mapped line reachable: it can still be found by the name someone recognizes, long after it has been pointed at the wrong thing.

Why never just record zero. A sale costed at zero would quietly understate food cost and corrupt the month-end variance — and do it invisibly, which is the worst kind of wrong. Holding the line makes the gap loud and fixable instead of a silent hole in the books. (A made-to-order item that is recognized but has no recipe on its sale date is caught the same way — such a sale must never cost nothing by accident. An empty recipe in force is the opposite case: somebody said so.)

9. End to end, in one pass¶

The life of a sold "Carbonara ×12" delivery order:

The platform reports the sale on the one-way feed: every line the customer was charged, the delivery fee included. The depletion that follows never depends on what any of it cost the customer.
It comes through the front door as one sales ticket, carrying the platform's own order id (so a re-send is ignored) and stamped with the restaurant-local business date.
It's recorded immediately. The made-to-order item is unpacked against the recipe in force on that date into its four raw ingredients, each removed from stock at its pool's price. The delivery-fee line settles where it stands — its money kept on the record, nothing drawn from stock.
Each ingredient is routed to the right warehouse — one of the selling restaurant's own stores — and charged to that restaurant's P&L.
It's now a fact: on-hand for spaghetti, guanciale, egg, and pecorino is down; the live food-cost number reflects it; the reorder math sees the real number.
If something's off — the platform amends it (answer the ticket again), the month already closed (record revenue only), or the name didn't match a sellable item (hold until an operator maps it).

At month-end nothing about what left stock is recomputed — the quantities were recorded as they happened. What the close adds is the money: it reconciles the record against the physical count, strikes the period's one price per pool, and writes that price onto every depletion the period already holds. The quantity is the shift's fact; the value is the period's.