Catering is project accounting wearing a chef's coat. Every event is effectively a one-off job: a quote, a menu built to a headcount, a delivery date, labour, rentals, and a single invoice at the end — which is a very different shape from a restaurant's continuous nightly service. The Acumatica fit for a catering business leans on Project Accounting more than on Manufacturing, and clients are usually surprised by that until they see it working.
Each event is a project, not a sales order
A sales order captures "what was sold." It does not naturally capture "what this event cost us in labour, rented chafing dishes, and ingredients relative to what we quoted," which is the number a catering business actually needs per event to know if pricing is sane. I model each booking as a Project (PM301000) with tasks for menu prep, staffing, equipment rental, and delivery, and revenue budget lines matching the quote. Actual costs — ingredient issues from inventory, timesheet labour, rental POs — post against the project, and the Project Budget vs Actual report becomes the per-event P&L the owner actually wants, instead of a sales order total that hides where the margin went.
Project: CATER-2026-0142 "Ochieng Wedding, 250pax, 14 Aug"
Tasks:
PREP Budget: ingredient cost from recipe BOM x headcount
LABOUR Budget: hrs x role rate (kitchen staff, servers)
RENTAL Budget: PO commitments (tents, chafers, linens)
DELIVERY Budget: fuel/vehicle allocation
Billing: Fixed-price against the original quote,
with change orders for headcount changesRecipes that scale with headcount
A wedding menu costed for 100 guests does not simply 2.5x cleanly to 250 — some ingredients scale linearly, some (a fixed number of serving stations, a flat delivery fee) do not. I still use a BOM per menu item for the linear-scaling ingredients (this is the same BOM machinery covered in the food-manufacturing and bakery pieces), but I keep fixed-cost items as separate project budget lines rather than forcing them into the BOM, because BOM quantities are built to scale with output and fixed costs by definition should not.
Caterers get headcount changes constantly — 250 becomes 280 four days before the event. If the BOM-driven ingredient budget does not get regenerated against the new headcount, the kitchen either runs short or the project shows a cost overrun that is really just a stale budget. I build a small custom action on the Project screen that recalculates BOM-scaled budget lines from a headcount field, so a headcount change is one click, not a manual re-quote.
CRM carries the sales pipeline, not the kitchen
The quote-to-booking pipeline (inquiry, tasting, proposal, deposit, confirmed) fits Acumatica CRM's opportunity stages reasonably well, and converting a won opportunity into a Project is a standard, supported flow — not a custom build. Where clients over-invest is trying to manage kitchen prep lists inside CRM activities; that belongs on the Project's task list, not as CRM tasks, because prep lists need to relate to inventory and labour in a way CRM activities do not.
Wrapping up
Treat each catering job as a Project, not just a sales order, and the Project Accounting suite does the heavy lifting: budgets, actuals, and a true per-event margin. The one piece of custom work worth budgeting for is headcount-driven budget recalculation — a small action, but it is the difference between the tool reflecting reality four days before an event or silently lying about it.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.