Weekly Cash Flow for Hospitality

This use case explains how to build a weekly cashflow model for restaurants, cafés and bars in Model Reef.

Hospitality is cash intensive, with short cycles between trading, payroll, rent and supplier payments. Weekly visibility can be more useful than monthly reporting when managing runway, staffing and ordering decisions.

You will use weekly model periodicity, driver-based revenue and costs, and timing rules for payments and receipts.

When to use this pattern

Use this pattern when:

  • You need to manage short term cash risk in a hospitality business.

  • You make staffing, ordering and payment decisions weekly.

  • Monthly cashflow views are too coarse to be actionable.

If you require daily visibility, you can use daily periodicity and then aggregate to weeks in dashboards, but weekly is usually sufficient for planning.

Architecture overview

A weekly cashflow model uses:

  • Weekly periodicity — the model is built with weeks as the base period.

  • Weekly drivers — revenue drivers per week; staff hours and wage costs per week; weekly purchasing and other costs.

  • Timing rules — delays between card/platform receipts and cash arrival; supplier payment terms; payroll and rent cycles.

  • Cash outputs — weekly Cashflow Statement and Cash Waterfall; minimum cash balance and funding gap views.

1

Create a weekly model

When creating the model:

  • Choose weekly as the periodicity.

  • Set a start date and end date that cover the planning horizon (for example 12 to 24 months).

  • Align the start date to the start of a trading week if possible.

You can still view results on a monthly or quarterly basis using reporting aggregation, but calculations will occur at weekly resolution.

2

Set up weekly revenue drivers

In the Data Library, create weekly drivers such as:

  • Weekly Covers - Venue City Centre

  • Average Spend per Cover - Weekly

  • Weekly Delivery Orders

  • Average Spend per Delivery Order

If you have historical weekly data from POS exports, import it as CSV and tag each series clearly.

Define Revenue variables per venue and stream, for example:

  • Revenue - Food - Weekly

  • Revenue - Beverage - Weekly

  • Revenue - Delivery - Weekly

Example formulas:

  • Revenue = Weekly Covers × Average Spend per Cover

  • Delivery Revenue = Weekly Delivery Orders × Average Delivery Spend

You can incorporate seasonality and events by adjusting weekly drivers over time.

3

Model weekly COGS and purchasing

For consumables and ingredients, create COGS variables with occurrence and timing that reflect:

  • When goods are consumed (COGS occurrence).

  • When suppliers are paid (delay).

Examples:

  • Occurrence pattern based on weekly revenue and expected gross margin.

  • Delay representing supplier terms, for example 14 to 30 days.

If you plan pre-season or bulk purchases, use additional Asset or COGS style variables to represent those purchases in specific weeks and adjust working capital behaviour manually (this is an approximation).

4

Model weekly staff and roster costs

Use Staff variables for roles such as:

  • Front of house

  • Back of house

  • Bar staff

  • Managers and supervisors

Drivers:

  • Weekly hours per role

  • Hourly wage rates

  • Oncosts such as superannuation

Timing:

  • Payroll cycles and delays between end of working week and cash payment

This will generate weekly staff costs in P&L and corresponding cash outflows in Cashflow, with payables in between if applicable.

For roster design ideas, see Retail Workforce and Roster Forecasting (applies analogously to hospitality).

5

Represent other weekly costs

Add Opex variables that occur weekly, fortnightly or monthly, including:

  • Weekly or fortnightly rent payments if applicable

  • Weekly marketing spend

  • Utilities and other overheads, usually with monthly billing but weekly accrual

  • Debt service where relevant

Use timing settings and delays to match reality, for example:

  • Rent paid weekly on a regular day

  • Utilities accrued weekly but paid monthly

Model Reef will still work at weekly resolution even if some items occur on slower cycles.

6

Configure cashflow views and alerts

With drivers and variables in place, use:

  • The Cashflow Statement to see weekly net cash movement.

  • The Cash Waterfall to understand how revenue, COGS, staff, Opex, tax and funding combine to create cash movements.

Build a dashboard that shows:

  • Weekly opening and closing cash

  • Minimum expected cash balance over the horizon

  • Weeks where cash is projected to fall below thresholds

  • Contributions by category to cash movements

This can serve as an early warning system for funding gaps and help prioritise actions such as reducing costs, changing rosters or negotiating terms.

7

Use scenarios for stress testing

Clone the weekly model into separate models for:

  • Base trading expectations

  • Downside scenarios (lower covers, higher cancellations)

  • Upside scenarios (higher volumes, price changes)

For each scenario, compare:

  • Weekly cash positions and minimum balances

  • Timing and size of any funding gaps

  • Sensitivity of cash to changes in revenue and labour

Because scenarios are separate models, you can change assumptions freely without risking the base plan.

circle-info

Check your work

  • Weekly revenue and cost patterns approximate actual trading behaviour.

  • Supplier and payroll timing assumptions match real payment cycles.

  • Cash balance movements look plausible compared to prior actuals where available.

  • The model is understandable by non-modellers who rely on it for operational decisions.

Troubleshooting

chevron-rightWeekly model feels heavy to maintainhashtag

Focus detailed weekly assumptions on the next 3 to 6 months and use smoother patterns for later periods.

chevron-rightCash swings look exaggeratedhashtag

Check for one-off spikes caused by incorrect timing or double counting of costs, and verify COGS and staff drivers.

chevron-rightStakeholders find weekly charts overwhelminghashtag

Provide both weekly and monthly aggregated views so they can zoom in when needed but still see the bigger picture.

Last updated