He Finds Out Three Weeks Later. The Proteins Are Already in the Bin.

Monday morning. Victor opens four bank accounts. Scans the weekend transactions across four locations.

Friday delivery from Sysco at Location 2: $4,200. Seems high. Is it high? He'd need to compare it against last week's delivery, against what Location 2 sold over the weekend, against the menu mix and what each dish should cost in ingredients. He doesn't have time. He has a meeting at Location 3 in 40 minutes.

He texts the kitchen manager at Location 2: "Sysco order seemed high Friday. Everything OK?"

Response (3 hours later): "Yeah, we're prepping for the Henderson event next weekend. Plus I stocked up on proteins because the Sysco rep said prices are going up."

Victor takes this at face value. He doesn't have the data to challenge it. Maybe the Henderson event justifies $4,200. Maybe Location 2's kitchen manager is over-ordering because he's afraid of running out (which is what kitchen managers do when there's no system telling them whether they're over-ordering). Maybe the proteins "stocked up" will expire before they're used. Victor doesn't know. He'll find out when the P&L arrives.

Three weeks later, the P&L shows Location 2's food cost at 38%. Target: 30%. The Henderson event accounted for some of the variance. The protein order accounted for more. Waste from over-ordered proteins that didn't move in time accounted for the rest. Total variance: $6,400 above target for the month.

Victor discovered this 45 days after the purchasing decisions were made. The proteins were already in the bin. The money was already spent. The conversation he needed to have should have happened the Saturday after the Friday delivery. Not three weeks into the following month, when the only thing left to do is read the P&L and feel the specific frustration of learning about a problem too late to have prevented it.

Restaurant group in Nashville, Tennessee. Four locations: two casual dining, one fast-casual, one bar and kitchen. Eighty-six employees total. $4.8M combined annual revenue.

Victor is the general manager. He runs the business from aggregated monthly financials prepared by the bookkeeper. Food cost as a percentage of revenue is the number he watches most closely. Target: 28-32%.

Actual over the last 12 months: ranged from 27% to 41%. Three months above 35%. The bookkeeper prepares the P&L 18-25 days after month end. During those 18-25 days, Victor has no visibility into whether last month's food cost was 28% or 41%. He checks bank balances. He scans supplier invoices when he happens to see them. He asks kitchen managers whether spending "feels" right. Which is, when stated precisely, a financial monitoring system whose primary instrument is feelings.

Combined annual food purchases: approximately $1.54M. Estimated overspend in months above target: $38,000-$52,000. Waste (industry benchmark: 4-10% of purchases): estimated $42,000-$58,000. Over-ordering (purchased but expired before use): estimated $24,000-$36,000. Victor's time on financial monitoring (bank checks, invoice review, P&L analysis): approximately 6 hours per week, $18,720 per year. Bookkeeper time preparing food cost reports: approximately $3,840 per year.

Total annual cost of the visibility gap: $127,560-$168,560.

Each location's kitchen manager orders independently from Sysco, US Foods, and local suppliers. Each tracks inventory differently (one uses a clipboard, two use spreadsheets, one uses Toast's inventory module but doesn't reconcile against purchases). Nobody is comparing actual food cost against theoretical food cost (what the recipes say it should cost based on what was sold) in real time. Nobody is comparing purchasing patterns across locations. The data exists. In Toast. In Sysco's portal. In US Foods' portal. In QuickBooks. In recipe cards last updated 18 months ago. In four kitchen managers' heads. In none of these places simultaneously.

Four stages. The core insight: Victor doesn't need a better P&L. He needs the P&L's most important number (food cost percentage) calculated daily instead of monthly, per location instead of aggregated, and delivered the morning after the spending instead of 25 days later.

Stage 1: Purchase data ingestion

Supplier invoices captured via email parsing. Sysco and US Foods send invoice PDFs by email. Claude Haiku extracts line items, quantities, and prices from each PDF. Local supplier invoices photographed by kitchen managers and processed via the same pipeline. All purchases logged by location, date, supplier, item, quantity, and cost.

The parsing handles the gap between supplier item descriptions ("BNLS CHKN BRST 40LB") and recipe ingredient names ("boneless chicken breast"). A mapping table builds over the first month. By week four, the 50 most common items match automatically.

Stage 2: Sales data integration

Toast API provides daily sales mix: every menu item sold, per location, per day. Revenue by item and category. The data that tells Victor what was served, which is the denominator of the food cost equation.

Stage 3: Theoretical versus actual calculation

Recipe database (digitised from paper cards, maintained in the agent's data store): each menu item's ingredient list with quantities and current supplier pricing. Theoretical cost equals the sum of items sold multiplied by recipe ingredient cost. Actual cost equals purchases logged in Stage 1.

Variance equals actual minus theoretical. Calculated daily per location. Rolling 7-day and 30-day averages tracked. When Location 2's rolling 7-day food cost exceeds target by more than 3 percentage points, Victor gets an alert the following morning with context: which items drove the variance, the purchase-versus-sales pattern, and whether the variance is consistent or a spike.

Stage 4: Alerts, dashboard, and reporting

Daily variance check across all four locations. Weekly dashboard: all locations compared side by side (food cost percentage, variance, purchasing trends, top variance-driving items). Monthly report generated on day 1 of the following month (not day 25), replacing the wait for the bookkeeper's P&L on the metric that matters most.

The theoretical-versus-actual calculation is where the value lives. Tracking what you spent on food is accounting. Comparing what you spent against what you should have spent based on what you sold is intelligence. A $4,200 Sysco delivery is just a number. A $4,200 delivery when the sales mix predicts $3,100 in ingredients is a $1,100 variance with a cause worth investigating. The P&L tells Victor his food cost was 38%. The theoretical-versus-actual breakdown tells him why: over-ordering proteins (accountable), waste from unused prep (addressable), or theft (discoverable). The P&L diagnoses. The variance explains.

Recipe digitisation is the bottleneck in the build (which is appropriate for a series about bottlenecks). Four locations, each with 30-60 menu items, each with ingredient lists and quantities. Estimated time: 2-4 hours per location. Tedious. Essential. Done once. Updated quarterly. The paper recipe cards hadn't been updated in 18 months. Ingredient prices on the cards were 12-22% below current supplier pricing. The digitisation process corrected the recipe costs as a side effect. Victor's theoretical food cost calculation had been understated for 18 months because the recipe cards didn't reflect reality.

The Marcus pattern recurs. Marcus in Houston checked his bank balance Monday mornings and hoped. Victor checks four bank balances Monday mornings and guesses. Both are financial monitoring systems whose instruments are a bank balance and an emotion. Both were replaced by systems that calculate forward rather than reflect backwards.

Recommended stack: n8n for orchestration. Toast API for sales data (included in most Toast plans). Claude Haiku for invoice parsing, Sonnet for weekly narrative reports. Postgres for purchases, sales, recipes, and variance history. Email trigger (IMAP) for supplier invoice processing.

Step 1: Set up infrastructure and digitise recipes (Days 1-3). Deploy n8n. Configure Toast API. Set up Postgres. Digitise recipe cards: each menu item's ingredient list with quantities. Enter current supplier pricing per ingredient from most recent invoices. This is the most time-consuming step. Do it once. Worth every minute.

Step 2: Build the invoice processing workflow (Days 3-5). Email Trigger monitors the inbox for supplier invoices. When a PDF arrives, Claude Haiku extracts line items: item name, quantity, unit, unit price, total price. JSON output stored in Postgres by date, supplier, location, item. Build a synonym table for supplier descriptions versus recipe ingredient names. Photographed local invoices enter the same pipeline via webhook.

Step 3: Build sales data integration (Days 5-6). Schedule Trigger daily at 06:00. Toast API pulls previous day's sales by menu item per location. Store in Postgres.

Step 4: Build variance calculation (Days 6-7). Daily after sales pull: theoretical cost per location equals sum of items sold times recipe cost. Actual cost equals purchases for that location in the same period. Variance calculated. Rolling 7-day and 30-day percentages tracked. If 7-day food cost exceeds target by 3-plus points: alert Victor via Slack or email with the specific items driving the variance.

Step 5: Build dashboard and reporting (Days 7-8). Weekly dashboard: four locations side by side. Food cost percentage, variance, top 5 contributing items per location. Monthly report via Claude Sonnet: narrative summary generated on day 1 of the following month.

Step 6: Test and refine (Days 9-12). Run against 2 weeks of historical data (enter past invoices, pull past Toast sales). Compare the agent's food cost against the bookkeeper's P&L. Spot-check 20 parsed invoices. Calibrate the alert threshold. Pilot with one location, roll out to all four after a successful 2-week test.

Estimated build time: 10-12 days for a competent n8n developer. 3-4 weeks if learning alongside.

Monthly running costs:

The Claude API cost for parsing 120 invoices per month: approximately $0.14. Daily variance calculations and weekly reports: approximately $0.17. Total API cost under $1 per month for the intelligence layer.

Build costs if hiring: 10-12 days at $400-$600/day = $4,000-$7,200. Self-built: $0 plus recipe digitisation time.

Year-one total: $4,372-$7,980 (with developer) or $372-$780 (self-built). Compared against $127,560-$168,560/year in total gap cost. Even counting only the overspend ($38,000-$52,000), the ratio is 5-13:1.

Invoice parsing errors. Claude misreads a line item. "BNLS CHKN BRST" doesn't match "boneless chicken breast." Build a synonym table. After the first month, the 50 most common items match automatically. New items get flagged for manual matching once per item. Spot-check 10% of parsed invoices weekly for the first month.

Recipe database goes stale. Menu changes, portions adjust, new items appear. Monthly recipe review prompted by the agent. When a menu item's theoretical cost diverges from actual by more than 15% consistently, flag for review. Kitchen managers confirm ingredient lists quarterly.

Supplier pricing changes. Sysco raises chicken prices. The recipe database still has the old price. Theoretical cost understated. The agent updates ingredient pricing from the most recent invoice data automatically. The invoice parsing captures unit prices. The recipe database inherits the latest price.

Kitchen managers resist photographing local invoices. Only local suppliers need photographing (Sysco and US Foods send PDFs by email). Local suppliers are typically 15-20% of purchases. Alternative: kitchen manager forwards invoices to the monitored email address instead of photographing.

Waste isn't captured. The agent tracks purchases and sales but not waste. The variance shows "more purchased than theoretically needed" but can't distinguish waste from over-portioning from theft. Add a simple waste log as a Phase 2 addition. The core agent works without it. The variance alone tells Victor something is wrong. The waste log tells him what.

Multi-location comparison creates tension. Kitchen managers feel surveilled when Location 2's food cost is posted next to Location 4's. Frame as diagnostic, not competitive. The goal is consistency, not rankings. Share individual location data with that location's manager. Share aggregate trends with Victor. Victor decides what to share across locations.

If your financial monitoring system is a bank balance checked Monday mornings and a P&L that arrives 25 days after the month closes, the spending decisions that produced this month's results are already 45 days in the past by the time you see them. The proteins are in the bin. The waste has been thrown out. The over-ordering has compounded across four kitchens for four weeks while you waited for a report.

The agent doesn't replace Victor's judgment about how to run four restaurants. It replaces the 25-day delay between spending and visibility. Victor still decides whether Location 2's protein purchases are justified. He just makes that decision on Saturday instead of three weeks into the following month. And the difference between Saturday and three weeks later is the difference between a conversation that changes behaviour and a P&L that documents what already happened.

This is Blueprint #50 in the AdAI series. Every week we publish the full architecture of a real AI agent design: the bottleneck, the build guide, and the costs. Free to read. Free to build from.

Want the next one? Subscribe to AdAI News. New blueprint every Thursday.

by CD
for the AdAI Ed. Team