Turn cash burn forecasts into a reviewed working table

What shipped

Google has added a useful capability to the Gemini app: it can generate interactive simulations and models, including tables and simple visual models, from a prompt. The examples include learning tools, but the practical SME angle is finance. A cash burn or runway model is exactly the sort of table that benefits from being interactive, provided it is grounded in the company’s own figures and reviewed by the finance lead before anyone acts on it.

For an Irish SME, the interesting point is not the product release itself. It is the workflow it makes more realistic to prototype. Many owner-managers still rely on a cash forecast spreadsheet that has grown over years. It may pull from Xero, QuickBooks, Google Sheets, a payroll report, bank balances and a list of expected invoices. It works until someone changes a formula, forgets to update a tab, or asks a reasonable question in a management meeting that the file cannot answer quickly.

A better first step is not to replace your accounts package. It is to build a small reviewed assistant around the forecast. The assistant extracts the key figures, structures them into a burn-rate table, shows runway under agreed assumptions, and lets the owner or finance lead test simple what-if scenarios. The output is decision support only. The named human review step is the Finance Lead Approval Note, where the finance lead checks the assumptions, edits the figures, and approves the version used in the meeting.

This is a good fit for rapid AI prototyping, because you can learn a lot from one anonymised forecast before changing the wider finance process.

Who should care

This is most relevant to an owner-manager, finance lead or operations manager in a business with 10 to 250 people where cash visibility matters but the finance team is small. Common examples include agencies, distributors, manufacturers, professional services firms, construction suppliers, hospitality groups and funded start-ups.

The pain is usually familiar. The business has enough moving parts for cash to be hard to read, but not enough finance capacity to rebuild the forecast every week. One person understands the spreadsheet. Management asks what happens if a debtor pays late, if a new hire starts next month, or if a large stock purchase goes ahead. The answer is possible, but it takes manual updates, copying, checking and explaining.

An interactive runway assistant helps when the problem is not accounting accuracy, but repeatable preparation. It does not decide whether to hire, delay a supplier payment or take out finance. It gives the management team a clearer, faster table to review. The person responsible for finance still owns the numbers.

It is not the right starting point if your source data is not trusted, your accounts are months behind, or the business needs a full budgeting and forecasting platform. In those cases, fix the basics first. You can still use the idea later, once the monthly accounts and cash inputs are consistent.

A worked example

Imagine a 45-person Irish services business. It uses Xero for accounts, a spreadsheet for sales invoices expected in the next 60 days, a payroll summary, and a list of known costs such as rent, software, insurance, loan repayments and subcontractors. The owner wants a simple answer before each monthly management meeting: how many months of runway do we have, what is the current burn rate, and which assumptions could change the answer?

Today, the finance lead exports reports, updates a spreadsheet, checks formulas, adds comments and saves a meeting copy. It takes half a day. The file is useful, but fragile. If the owner asks what happens if two large customers pay 30 days late, the finance lead may need to duplicate tabs or edit several cells while everyone waits.

A prototype assistant would start with an anonymised version of that workflow. It would take the monthly accounts export, current bank balance, expected invoices, payroll and known costs. It would then create a structured table with opening cash, expected receipts, payroll, fixed costs, variable costs, net movement, closing cash, burn rate and runway by month.

The first version should keep scenarios deliberately simple. For example:

1. Base case, using the current expected invoice dates and planned costs.
2. Delayed payments, where selected customer receipts move out by 30 days.
3. Growth cost, where a new hire or large purchase is added from an agreed month.

The assistant can show the impact on closing cash and runway without hiding the assumptions. The finance lead can edit invoice dates, remove a cost, change a hire date or adjust the opening bank balance. Each change is visible in the table.

The human review is not a courtesy step. It is the control that makes the workflow usable. The Finance Lead Approval Note should record who reviewed the table, the date, which source files were used, which scenarios were included, and any figures changed manually. The approved table can then go into the management pack. Anything not approved stays as a draft.

This approach also reduces key-person risk. If the original spreadsheet owner is away, the business still has a documented flow: input files, modelled table, visible assumptions and approval note. For related examples of AI applied to practical SME workflows, see Artellis insights.

Where I'd start

Start with one real forecast, anonymised if needed. Do not begin with every finance report the business owns. Pick the minimum set of inputs needed to answer the runway question: month-end accounts export, bank balance, expected invoices, payroll and known committed costs.

Then agree the three scenarios before building anything. This matters because scenario creep is where small tools become confusing. A good first set is base case, delayed receipts and one planned cost change. If the table cannot explain those clearly, it is not ready for more.

Next, define the output. For most SMEs, the best first output is not a dashboard. It is a reviewed table that can be refreshed in under an hour and pasted or exported into a management meeting pack. Columns should be plain English. Assumptions should sit beside the numbers, not in a hidden tab.

The prototype should test four things. Can it extract the right figures from the chosen exports? Can it structure them into a reliable monthly table? Can a finance lead edit the assumptions without breaking the model? Can the approved version be understood by the owner in a meeting?

If those tests pass, the next step is workflow design. Decide who refreshes the table, where the source files live, how the Finance Lead Approval Note is stored, and when the owner sees the output. That is the point where a clever table becomes a dependable finance routine.

For many SMEs, the value signal is modest but real: a recurring half-day spreadsheet update becomes a checked table refreshed in under an hour. More importantly, the business can see how the cash position moves when the assumptions move.