For Managers · 6-minute read

Waste tracking

Every shift produces some waste. PrepTable's job is to make sure that waste gets recorded with enough context that the next shift can decide whether it was avoidable. This page covers what counts as waste, how to record it, and where it shows up after.

What counts as waste

A waste event is any change in stock count that represents food that was prepared but not sold to a customer. It is distinct from receiving (stock that arrived), adjustments (manual corrections during a count), and count corrections (re-counts that found a discrepancy).

The five waste reasons:

Reason	Typical cause
Spoiled	Item went bad on the shelf before it could be used
Over-prep	Prep cook made more than the menu called for; the surplus is unsellable
Contamination	Item was exposed to an allergen or otherwise compromised and cannot be served
Expired	Past the labelled best-by / use-by date
Other	Anything that doesn't fit the above; the manager should add a note

The vocabulary is enforced at the API and database level. Recording "spoiled" requires picking one of these five sub-reasons; recording a movement with reason=waste and no waste_reason is rejected.

How to record waste

1. In the PrepTable app, switch to the campus you manage.
2. Go to Inventory → record waste.
3. Pick the item that was wasted. Enter the quantity and the unit (the same unit the item is stocked in — don't enter "3 lb" if the item is stocked in 50-lb cases; enter 0.06 of a case or the converted quantity, whichever your store convention prefers).
4. Pick the waste reason. Add a note for Other, Over-prep, or anything you'd want to see again at the end of the month.
5. Submit. PrepTable writes a stock_movement row and updates the item's on-hand count in the same transaction.

The form is mobile-friendly — it works from a phone or tablet at the prep station, which is where most waste is recognized.

Recording contamination immediately

If something on the line is contaminated mid-shift, record it right away, even if the broader alert is still unfolding. Waste events are timestamped to the moment of recording, not the moment of contamination, so a 30-minute delay loses the ability to correlate the event with the order queue. The audit log will tell you "user X recorded Y lb of chicken as contaminated at 12:14 PM" later, which is the level of detail you want when investigating downstream.

Recording expired pulls during a stock count

When a stock count reveals expired items, record each expired item separately with reason expired. Don't combine them into a single Other adjustment — the per-event detail is what the usage report breaks down by reason, and combining makes the breakdown useless.

Where the data shows up

Every waste event becomes a row in stock_movements and is visible in three places:

1. The usage report

The campus's weekly usage report includes a used_waste column broken out from used_adjust, used_count_correction, and used_receive. The report values waste at the current item unit cost, so a spike in waste valued at dollars gives a direct signal of financial impact.

The filter selector on the usage report lets you include or exclude each reason. The default is to include everything, which is the right call for the weekly review.

2. The low-stock dashboard

Waste does not, by itself, cause a low-stock alert — that's driven by par-level shortfall. But high waste against a par item is exactly the case where the par level is set wrong (too high relative to actual demand), so when you see an item appearing in both the waste-heavy list and the low-stock list, recalibrate the par.

3. The audit log

Every waste event records:

• The user who recorded it
• The timestamp
• The item, store (campus + location), and quantity
• The reason and the waste sub-reason
• The note, if any

An admin reading the audit log can answer "did we record waste for the chicken that went bad Tuesday?" without checking the kitchen verbally.

Common patterns and what they mean

Waste trends over a week

If the usage report shows used_waste rising week-over-week for a specific item, look at the by_reason breakdown:

• Spoiled is rising → your receiving cadence or first-in-first-out rotation needs work.
• Over-prep is rising → par for that day's menu is too high; the menu-health check might also be flagging this.
• Expired is rising → receiving is delivering more than the shelf can absorb; talk to your vendor about case sizes.
• Contamination is rising → talk to the line about cross-contact; this is a safety signal more than a cost signal.

Waste concentrated on Friday evenings

This is almost always an over-prep signal: the Friday prep list calls for more than Friday demand can absorb. The fix is par-level adjustment for the items, not more careful recording.

A spike in Other notes

Other is the catch-all, so a spike there is a signal that one of the four named categories doesn't fit a recurring pattern in your kitchen. After a few weeks of Other notes, you may want your admin to add a fifth category if a real pattern emerges (unrefrigerated transport, vendor mis-pick, etc.).

What is not waste

To make the boundary clean:

• A line that the customer didn't pick up. That's a fulfilled ticket that went cold, but it left the kitchen as a sale; if it's later thrown out, then record it as waste, but the timing matters.
• Trim from prep. Trim has its own disposition (compost, animal feed, freezer for stock); it's not waste unless thrown away.
• A miscount corrected at the next count. That's a count_correction, not waste — the items went somewhere, you just didn't know where.
• Tasting portions and family meal. Adjustments, not waste. These affect cost but are deliberate, not lost product.

The vocabulary enforces this. Trying to record a customer-no-show as waste will be rejected at the form level — you're being asked to think about which bucket the loss actually goes in.

Where to go next

• Data export — once you've recorded waste for a week, the CSV export is what you hand to the business office
• Par levels & low-stock alerts — the par-recalibration that follows from a waste spike
• The audit log — for admins reading back who recorded what