Food cost control in a multi-site restaurant business is one calculation run repeatedly: what the day's sales should have consumed, against what actually left the store. Producing the first number requires exploding POS sales back through the recipes — which is why most chains never see the variance at all.

The loop

  1. Recipes hold true cost. Ingredients, portions, and yield loss at each preparation stage.
  2. The POS records what sold. Dishes, by site, by day.
  3. Explosion converts dishes to ingredients. That is theoretical consumption.
  4. Stock movement gives actual consumption.
  5. The difference is the variance — waste, over-portioning, theft, or a recipe that is wrong.

Break any link and the loop produces nothing. Most chains have steps one, two and four, and no step three — so they have two numbers that cannot be compared.

Yield loss is part of the cost

A kilogram of whole onions yields perhaps 800 grams diced. Stock that raw kilogram against a recipe written in diced weight, and every portion is costed against an ingredient quantity that was never available.

Central kitchens compound this, because prep items are produced from raw items and then consumed by dish recipes — two levels, each with its own yield. The BOM has to carry the loss at the stage where it occurs.

Sales explosion

Codeunit 50210 POS Recipe Explosion Engine.al
codeunit 50210 "POS Recipe Explosion Engine"
{
    Access = Public;
    Subtype = Normal;

    procedure ProcessDailyPOSSales(StoreLocationCode: Code[10]; MenuItemNo: Code[20]; QtySold: Decimal)
    var
        BOMHeader: Record "BOM Component";
        ItemJnlLine: Record "Item Journal Line";
        LineNo: Integer;
    begin
        // Deconstruct Sold Menu Item into Raw Ingredients
        BOMHeader.SetRange("Parent Item No.", MenuItemNo);
        if not BOMHeader.FindSet() then
            exit;

        repeat
            LineNo += 10000;
            ItemJnlLine.Init();
            ItemJnlLine."Journal Template Name" := 'ITEM';
            ItemJnlLine."Journal Batch Name" := 'POS-CONSP';
            ItemJnlLine."Line No." := LineNo;
            ItemJnlLine.Validate("Entry Type", ItemJnlLine."Entry Type"::Consumption);
            ItemJnlLine.Validate("Item No.", BOMHeader."No.");
            ItemJnlLine.Validate("Location Code", StoreLocationCode);
            
            // Factor in Raw Ingredient Quantity & Yield Loss Scrap %
            ItemJnlLine.Validate(Quantity, (BOMHeader."Quantity per" * QtySold) * (1 + (BOMHeader."Scrap %" / 100)));
            ItemJnlLine.Insert(true);
        until BOMHeader.Next() = 0;
    end;
}

Run it nightly per site. The output is theoretical consumption in ingredient units, which is directly comparable to what stock movement says was used.

Reading the variance

PatternUsual cause
One site, one ingredient, persistentOver-portioning, or a prep method that differs from the recipe.
All sites, one ingredientThe recipe is wrong, or yield has changed with the supplier.
One site, many ingredients, suddenA count error, or something that needs a conversation.
Gradual drift everywhereRecipes have not been updated as prices and specifications moved.
The value of daily variance is not precision. It is that a number attached to yesterday's shift gets investigated, and a number attached to last month gets explained.

Franchise and intercompany

Where the central kitchen supplies franchised sites, each transfer is a sale between legal entities, with royalty calculation on top. That is intercompany accounting, not stock movement, and treating it as the latter is how a group discovers its franchise revenue was never invoiced properly.