Restaurant ERP Consultant, USA

Franchisees, franchisors and the reporting in between

Many US restaurant groups operate under someone else's brand. A franchisee with stores in two or three states has its own lender, its own investors and a franchise agreement that sets out how royalties and advertising fund contributions are calculated, what counts as net sales, and which reports must be sent each period. Those definitions decide how the ERP is built.

I start by reading the reporting clauses with your controller. Questions that look minor turn out to matter: whether employee meals and discounts are deducted before the royalty base, how third-party delivery sales are treated, whether gift card sales or redemptions drive the calculation, and how the brand wants its chart of accounts mapped. The answers become calculation rules and test cases, not notes in a spreadsheet.

Where you are the franchisor, the view flips. You may run corporate stores in the ERP while collecting sales and royalty data from franchisees who use their own systems. I design the intake: a standard sales file per unit, invoices for royalties and fund contributions, and a dashboard comparing unit performance. Franchise law and disclosure questions stay with your attorney; my role is the data and the process. The general model for restaurant groups is on ERP for restaurants.

Delivery marketplaces and their weekly statements

Third-party delivery has turned one sale into several numbers. The POS records the order at menu price, the marketplace statement shows a commission, a marketing fee, a promotion the restaurant agreed to fund, perhaps a refund for a missing item, and then a deposit that matches none of them directly. Most groups book the deposit and move on, which hides the true cost of the channel.

I design a reconciliation that starts from the statement, not the bank. Each marketplace export is mapped to the POS orders it covers, the gross sale is recognized in full, and commissions, promotions, adjustments and error charges each land in their own account. Differences above a tolerance go to a review queue with the order reference, so disputes can be raised while the platform still accepts them.

Sales tax needs care. In a number of states, the marketplace collects and remits sales tax on orders it facilitates, while in others the restaurant may remain responsible. I record which applies for each store as confirmed by your tax advisor, and design the postings so tax is neither reported twice nor missed. The result is a channel profit view per store that reflects what delivery really earns. Interface details are part of my ERP integration work.

Theoretical food cost with broadline distributor data

American restaurants usually buy most of their product from one or two broadline distributors, with produce, protein, bakery and beverage vendors alongside. Distributors often provide electronic invoice files and order guides, which makes them the best source for theoretical cost, provided the units of measure are mapped properly. A case of chicken breasts, a pound on the scale and a six-ounce portion must all resolve to the same item.

I build the item master around that chain: purchase unit, inventory unit, recipe unit and yield after trim or cooking. Recipes and sub-recipes roll up into plate costs, and each POS menu item, combo and modifier points to one of them. When the distributor invoice arrives, the latest cost flows through to every affected dish.

Counts then close the loop. I usually recommend a weekly count of high-value items such as proteins, cheese and alcohol, with a full count at period end. Theoretical usage from POS sales is compared with actual usage from counts, purchases and transfers, and the variance is listed by item and store. Owners see prime cost, food plus labor, each week rather than after the books close. Labor arrives from your payroll and scheduling tools as journals by store; the rules behind it stay with your payroll provider.

Ghost kitchens and virtual brands sharing one line

Some US operators run more than one concept from the same kitchen: a burger brand, a wings brand and a salad brand, each with its own marketplace listing, all cooked on the same line from the same walk-in. Some do it inside an existing restaurant, others from a shared commissary facility rented by the station.

The ERP question is how to measure each brand without splitting the stock artificially. My usual design keeps inventory at the kitchen location, maps each brand's menu items to shared recipes, and treats the brand as a reporting dimension on sales and recipe consumption. Theoretical food cost then appears by brand, while the count happens once for the whole kitchen. Packaging, which often differs by brand, is costed as part of the recipe rather than left in overhead.

Rent, station fees and shared labor need an allocation rule agreed with the owners, usually by order volume or sales. I write the rule down and build it into the period close so brand profitability does not depend on whoever prepares the spreadsheet. When a virtual brand underperforms, the data is there to retire it cleanly. If you also bottle sauces or pack meals for grocery retailers, the production side is covered on my US food and beverage ERP page.

Platform choice, migration and a remote rollout

A typical starting point for a US restaurant group is a POS it intends to keep, a QuickBooks company file per entity, inventory tracked in the POS back office or a separate tool, and spreadsheets that hold it all together. The first decision is whether a dedicated restaurant inventory product plus accounting is enough, or whether the group needs a full ERP because of a commissary, several entities, franchise reporting or investor demands.

When an ERP is justified, I shortlist from Zoho, Odoo, ERPNext and Microsoft Dynamics 365 Business Central and test each on the same scripts: a busy store day from the POS, a distributor invoice with a price above contract, a marketplace statement with a refund, and a period royalty calculation. Hotel-based outlets and banquet operations are covered separately on my US hospitality ERP page.

Rollout runs remotely, district by district. A pilot store goes live first, its first variance report is reviewed with the chef and manager, recipes are corrected, and the template moves on. Workshops are scheduled to suit your head office time zone, with recordings for store managers who cannot leave the floor. Broader US topics such as multi-state sales tax and entity structure are on my US ERP consultant page and the US hub.