Before any tool is on the list, a finance team of three to six writes down six things about itself: which ledger and which entities the data will come from, the cadence the forecast has to run at, who will maintain it and for how many hours a month, what the IT reviewer will ask about access and security, what the forecast has to show and what it does not need to do, and what the finance director signs off, including the cost over three years and the way out. Scored on one sheet with the disqualifiers marked, that list rules out most of the market before a demo is booked. Government small-business guidance in both the UK and Australia says the same thing in plainer words: write the requirements first, split the must-haves from the optional, and only then look at what is for sale.

Why the list comes before the shortlist

Most software decisions go wrong at the start. A team opens a comparison page, finds eleven tools on a feature grid, and starts eliminating on features it has not yet decided it needs. Australia's business.gov.au puts the order the right way round: "Make a list of your must-have and optional features before you research the tools available", and "choose tools based on what you need, not what you might use later." The UK government's Help to Grow: Digital service runs the same sequence, objectives first, then a written requirements list, then a budget, then the shortlist. CPA Australia's guide to selecting accounting software adds the warning every finance team has heard and few have acted on: "Don't choose a software package because it has the most 'bells and whistles'."

The list should be short. No professional body prescribes a number, and the page does not pretend one exists. Six sections is the structure here because it matches the six people and constraints a finance team of this shape has: the ledger, the calendar, the person who owns the model, the IT manager, the forecast itself, and the director who pays for it. Each section ends with the answers that rule a whole category of tool out, so the scoring sheet at the end does its job before the demo, not after it.

This page is the requirements side of the decision. Once the list exists, the guide to comparing cash flow forecasting tools sorts the market into categories and sets out the questions that decide it in the demo, and the roundup of forecasting software for finance teams names the tools. Neither is much use until the list exists.

How to write the requirements list, in six steps

Step 1: Establish what your ledger holds, and what it does not. Name the accounting platform, the number of entities and which ledger each one sits on, the bank accounts and whether every one of them feeds the ledger, the currencies, how payroll is recorded, and how often the accounts are reconciled. Every forecasting tool builds on top of this; none of them fixes it.

Step 2: Decide the cadence the forecast has to run at. A rolling 13-week weekly view serves the payment run and the liquidity decision; a rolling 12-month monthly view serves the plan. Decide which you need, whether you need both, and who reviews each one and when.

Step 3: Name who maintains it and count the hours. One owner, one reviewer, and a number of hours a month the team can give without the forecast becoming someone's second job. Write the number down; it disqualifies more tools than any feature does.

Step 4: Write down what the IT reviewer will ask. What the tool can read and write in the ledger, how the connection is revoked, how users authenticate, where the data is held, who else can see it, and how it is deleted at the end. Most of these have factual, per-platform answers, set out below.

Step 5: Specify what the forecast has to show, and what you are not buying. Invoice-level detail, expected dates as well as due dates, scenarios that sit on top of the base forecast, a group view across entities, a cash floor. Then decide whether alerts, scheduled report delivery, profit-and-loss forecasting and payment execution are real needs or borrowed ones.

Step 6: Write the page the finance director signs. Total cost of ownership over three years including running costs, the pricing shape and what drives it, the contract term, the trial, and what happens to the data when you leave.

Step 1: Your ledger and your data

A cash flow forecasting tool for a business of this size reads the accounting platform. So the first requirements are about the platform, not the tool. The Victorian government's guide to choosing accounting software asks the ledger the questions a forecasting buyer should already have answered: "Will the system be able to handle multiple bank accounts?", "Does the system need to handle foreign currency?", and "Does the system track separate financial records for each business or department within the business?" If the answers are not settled at the ledger, no forecasting tool inherits them.

Write down, for each entity: the accounting platform and plan; the bank accounts and credit cards and whether each one has a bank feed into that ledger; the base currency and any others; how payroll is posted (as a bank transaction, through the platform's own payroll, or by manual journal); and how often the accounts are reconciled. The last item matters more than it looks: a tool that reads reconciled data shows reconciled data, so if the accounts are matched weekly the opening balance is six days old on the day before the reconciliation. That is a discipline decision for the team, not a feature to buy.

Then decide the one architectural question that splits the market: do you want bank data to reach the forecast through the ledger, so there is one source of truth and the forecast agrees with the accounts, or directly from the banks, so it is fresher but is a second copy of the numbers? Neither answer is wrong, and each rules out half the market.

Rules a tool out if: it does not connect natively to your ledger; it needs a direct bank connection you have decided not to run, or lacks one you have decided you need; it cannot take a second entity from a second ledger of the same platform; or it needs data the ledger does not hold.

Step 2: The cadence you will run

The Association of Corporate Treasurers describes the operational cash forecast as one that "generally covers the next 13 weeks on a rolling basis", updated "weekly or monthly depending on the industry", and used "for cash positioning", with medium-term forecasting serving funding and investment decisions instead. In a finance team of three, the 13-week weekly view is the one that answers what to pay this week, what to chase and whether the balance holds through the next payroll. A rolling 12-month monthly forecast is the usual companion for the plan, the lender and the year ahead. Some teams need one, most need both, and a tool built for one grain seldom does the other well.

Write down: the horizon and grain of each forecast you will run; the day of the week or month each is refreshed; who prepares it and who reviews it; and the decisions it feeds (payment run, hiring, drawdown, board pack). Cadence is the requirement most often left implicit until the demo, when the tool turns out to forecast in months and the job was Fridays.

Rules a tool out if: it cannot produce a weekly rolling view and that is the job; it cannot produce a monthly view to the horizon the plan needs; or its refresh depends on a manual rebuild the team will not do on the day.

Step 3: Who maintains it, and for how many hours

Business Victoria's software-selection guide asks the question most requirements lists skip: "Who is going to run and maintain it?" Help to Grow: Digital asks whether you will "need support to get it up and running" and whether there are "extra installation and ongoing support costs". For a finance team of three to six, the answer is a name and a number. Name the person who owns the forecast day to day, the person who reviews it, and the hours a month each can give. A tool that needs a partner-led implementation, a model owner, or a monthly rebuild is not a worse tool; it is a tool for a team you do not have.

The Association for Financial Professionals, writing for larger finance functions, warns against "a 'nuclear powered mousetrap' that is overengineered and introduces operational risk", and recommends weighing a tool that meets every requirement against one that meets most of them with less complexity. The trade-off is sharper at this size, with less slack to absorb the wrong call.

Rules a tool out if: implementation is partner-delivered and measured in weeks or months; the tool needs someone to maintain a model when the team only has time to review a forecast; or the hours it needs exceed the number you wrote down.

Step 4: What the IT reviewer will ask

The IT manager is the one member of the buying committee who can stop the purchase, and the questions are ordinary ones any SaaS supplier gets. Most have factual answers before the vendor is even asked, because two of them depend on the accounting platform, not the tool.

What the tool can read, and whether it can write. On Xero, a connected app asks for named permissions when it connects, and since March 2026 those permissions are granular: separate scopes for invoices, payments, bank transactions and manual journals, each with a read-only form, so the business can see exactly what an app is asking to read and whether it is asking to write anything at all. Apps created before March 2026 have until September 2027 to move to the granular model. On QuickBooks Online, Intuit publishes one accounting permission that covers reading and writing accounting data, with no read-only form, so on that platform read-only is a promise the tool makes about its own behaviour, not a guarantee the platform enforces. The requirement is the same on both: the vendor states in writing what it reads, what it writes, and that nothing it does in its own product flows back into the ledger.

How the connection is ended. On both platforms the business's own administrator can disconnect a connected app from inside the platform, Xero from the organisation's connected-apps settings and QuickBooks Online from its integrations page, without asking the vendor. Write it into the requirements anyway, and ask what the vendor keeps after the disconnection.

How users authenticate. Xero requires multi-factor authentication for every user invited into an organisation. Intuit runs a device verification it says cannot be turned off, with two-step verification on every sign-in as an opt-in setting. The forecasting tool needs its own answer. For a UK business that holds Cyber Essentials, that answer is not optional: the April 2026 requirements state that "authentication to cloud services must always use MFA", that "cloud services cannot be excluded from scope", and that users get "access to only those applications, computers and networks that the user needs to carry out their role". A tool that cannot mandate MFA for all users blocks a Cyber Essentials business outright.

The supplier questions. The National Cyber Security Centre's lightweight approach to cloud security is a published question list written for exactly this situation, a service that does not hold sensitive data, and it applies to SaaS. Its questions are worth putting to any forecasting vendor in the NCSC's own words: "Does the service encrypt data when at rest?", "Can 2FA be mandated for all users?", "Does the service support Single Sign-On to my organisation's identity provider?", "Does the service have the concept of privileged administrative users that can alter configurations, and standard users that cannot?", "Do you make security logs available to the customer?", "Do you have an incident response process?", "Do you have a vulnerability disclosure process?", "Can you tell me where my data will be processed and stored?" and "Do you publish a privacy policy?" Australia's Cyber Security Centre adds questions about backups ("Does the CSP back up your data or do you need to?"), whether you can restore data yourself, and whether the provider notifies you of logins from unfamiliar devices. New Zealand's Own Your Online guidance adds what happens to your data if the provider is bought or fails. The NCSC's advice on certifications is worth carrying verbatim: "It is the evidence presented with such standards and certifications that can give you confidence in the service, not the fact that a service holds a certification."

One caveat on scope. The NCSC's lightweight list is for services not holding sensitive data. A forecast holds customer and supplier names and amounts owed, and for some businesses that is enough to warrant the fuller set of cloud security principles the NCSC publishes alongside it.

The data-protection questions. In the UK, the Information Commissioner's Office sets out what a controller must have in place when it uses a processor: a written contract covering the subject matter, duration, nature and purpose of the processing and the categories of data, with terms on processing only on documented instructions, confidentiality, security measures, sub-processors, data subjects' rights, assisting the controller, end-of-contract provisions, and audits. The ICO also requires "sufficient guarantees" from the processor before it is engaged, and, where data leaves the UK, a three-step test to identify a restricted transfer and a safeguard to cover it. The ICO notes that its processor-contract guidance is under review following the Data (Use and Access) Act, so check the current page. In Australia, the Privacy Act permits overseas cloud processing, and the OAIC's guidance treats storage with a provider as a "use", not a disclosure, where the contract limits the provider and the business keeps effective control, with due diligence and destruction at contract end expected under APP 11; businesses with turnover of A$3 million or less are generally outside the Act. In New Zealand, a provider storing or processing information solely on the business's behalf does not "hold" it under the Privacy Act, so the business stays responsible for it and for the security safeguards. In the United States there is no single federal equivalent for a general business, and obligations vary by state and sector.

Rules a tool out if: the vendor cannot state what it writes to the ledger; MFA cannot be mandated for all users; there is no written answer on where data is held, who can access it and how it is deleted; or the contract cannot carry the processor terms your jurisdiction requires.

Step 5: What the forecast has to show, and what you are not buying

This is the section where borrowed requirements creep in. Write down what the forecast must show, from the decisions in Step 2 backwards: the balance by week and by month; every open invoice and bill with an expected date the team can set, not only a due date; recurring costs projected without re-keying; a scenario the team can lay over the base forecast and take off again without touching the ledger data; a floor, and the date the balance crosses it; a view across entities, and a decision about whether that view needs to be a group cash position or a statutory consolidation with eliminations; and the exports the board pack and the lender need.

Then write down what you have decided not to buy, because these are the requirements that pull a finance team of three towards software built for a treasury of thirty. An alert sent to your phone is a different requirement from a date displayed on the screen; decide which you need before a vendor decides for you. A report delivered on a schedule is a different requirement from a report you export when you want it. A profit-and-loss and balance-sheet forecast, the three-way model, is a different product from a cash forecast, and a business that needs it for a covenant or a capital programme should buy it knowing that it is buying a planning suite. Payment execution belongs to a treasury platform. None of these is wrong to want. Each one, written down as a requirement, removes an entire category of tool, so be sure the need is yours.

Rules a tool out if: it forecasts at the wrong grain for Step 2; it cannot set expected dates per invoice and bill; scenarios change the base data; or you have decided you need three-way forecasting or payment execution and the tool is cash-only.

Step 6: What the finance director signs

The director signs one page. business.gov.au's instruction is to "work out the total cost of ownership for each tool you're considering", meaning "the upfront cost plus running costs over the tool's life span"; the Association for Financial Professionals, for larger functions, puts a horizon on it: "Model a three-year cost of ownership to understand the total costs, and negotiate all points as part of the complete package." For a team of this size the page carries: the subscription at the plan you would be on, with what drives it (entities, users, revenue band, scenarios); the implementation and any partner cost; the hours from Step 3 at the cost of the person giving them; the contract term and notice period; the trial, and whether it needs a card; and the exit, which is the ICO's end-of-contract provision and the OAIC's destruction-at-contract-end question restated as a line item. What to ask about pricing, and why the market's published prices are easy to misread, is covered in the guide to what cash flow forecasting software costs.

Rules a tool out if: pricing is quote-only with a twelve-month minimum and the team needs a trial first; the pricing driver is one you cannot see before you connect; or the three-year cost exceeds what the forecast is worth to the decisions in Step 2.

The scoring sheet

The downloadable sheet carries the six sections above as rows, with four columns: whether the requirement is a must-have or optional, a weight from one to three, whether a failing answer is a disqualifier, and the vendor's answer with a fit score from zero to three. The must-have and optional split follows business.gov.au's two-tier prioritisation; the weighting and the disqualifier column are this page's own working method, not a standard any professional body prescribes, and the page says so. A tool's score is the sum of weight times fit; a tool that fails any disqualifier is out whatever its score. The sheet is built for one vendor per copy, so a shortlist of three is three copies, compared at the end on the same rows.

Download the requirements scoring sheet (Excel)

A worked example: a finance team of three on Xero, with two entities

Take a UK business of thirty people, two entities on Xero, three bank accounts feeding the ledger, weekly reconciliation, one finance manager who owns the forecast and a finance director who reviews it on Mondays, an IT manager who holds Cyber Essentials, and a decision that the 13-week weekly view is the job with a monthly view for the year. The sheet, filled in against Float from its own documentation, looks like this.

Three things to notice. The rows that read "meets, by design" are the ones where the team's own decision in Step 1 or Step 5 did the work: the same product is a pass for a team that wants bank data through the ledger and a fail for a team that wants direct feeds. The row marked "ask the vendor" is what any vendor's public documentation looks like on those four points, and it is the IT reviewer's list for the call. And the last row is the disqualifier: a team that needs a three-way model has ruled Float out on its own sheet, which is the sheet working.

Where the shortlist goes next

With the list scored, the comparison guide sorts the market into the categories a finance team can choose between and sets out what to test in the demo; the roundup of forecasting software for finance teams names the tools in each; the multi-entity consolidation guide goes further on the group-view question in Step 5; and the cost guide carries the pricing questions for Step 6.

Frequently asked questions

What should a finance team require from cash flow forecasting software?

Six things, written down before any tool is on the list: which ledger and entities the data comes from and whether bank data arrives through the ledger or directly; the cadence, usually a rolling 13-week weekly view with a monthly view for the plan; who maintains the forecast and for how many hours a month; what the IT reviewer will ask about read and write access, authentication, data location and deletion; what the forecast must show and which needs (alerts, scheduled delivery, three-way forecasting, payments) are real; and the total cost over three years with the exit terms. Each section ends with the answers that rule a category of tool out.

I'm ready to implement forecasting software for liquidity. What do I establish first?

Establish the ledger facts before the software facts: the accounting platform, the number of entities and bank accounts and whether every account feeds the ledger, the currencies, how payroll is posted and how often the accounts are reconciled. Then decide the horizon, which for a liquidity decision is usually a rolling 13-week weekly forecast, and name the person who will maintain it and the hours they have. Government small-business guidance in the UK and Australia puts the requirements list before any tool research, and splits must-haves from optional features first.

How do I implement cash flow forecasting in my finance team without buying the wrong tool?

Write the six-section requirements list on this page, score it on the sheet with the disqualifiers marked, and only then read a comparison. The failure types that named bodies warn about are the same three: comparing on feature count instead of the few things you must have, ignoring who will run and maintain the tool, and buying for a scale the business does not have. The implementation guide covers the rollout once the tool is chosen.

Should we require a 13-week cash flow forecast?

For operational cash decisions, yes. The Association of Corporate Treasurers describes the operational cash forecast as generally covering the next 13 weeks on a rolling basis and used for cash positioning, with medium-term forecasting serving funding and investment decisions. A rolling 12-month monthly forecast is the usual companion for the plan and for lenders. The requirement to write down is which of the two the team will run, on which day, and who reviews it; a tool that forecasts in months when the job is the weekly payment run fails Step 2.

What security questions should our IT manager ask a forecasting software vendor?

The National Cyber Security Centre publishes the list: whether data is encrypted in transit and at rest, whether two-factor authentication can be mandated for all users, whether single sign-on is supported, whether there are separate administrator and standard roles, whether security logs are available to the customer, whether there is an incident response process and a vulnerability disclosure process, where the data is processed and stored, and whether a privacy policy is published. Add backups and restore, breach notification, what happens on acquisition or insolvency, and the scope of any certification, not the badge. For a UK business holding Cyber Essentials, MFA on every cloud service is a requirement of the certification.

Does a forecasting tool need write access to Xero or QuickBooks Online?

A forecasting tool should not need to write to the ledger, and the requirement is that the vendor says so in writing. On Xero, connected apps request granular permissions, each with a read-only form, so the business can see whether an app asks to write. On QuickBooks Online, Intuit publishes a single accounting permission with no read-only form, so read-only there is the tool's stated behaviour, not a platform guarantee. On both platforms the business's administrator can disconnect a connected app from inside the platform.

Do we need a tool that connects directly to our bank?

Decide it in Step 1, because it splits the market. Bank data through the ledger means the forecast agrees with the accounts and shows only reconciled transactions; bank data direct from the banks is fresher but is a second copy of the numbers that will not always agree with the ledger. A finance team that reconciles weekly and wants one source of truth usually chooses the ledger route and writes "no direct bank connection required". A team that needs intraday balances across many banks is describing a treasury requirement and should buy accordingly.

How much should we budget for cash flow forecasting software?

Budget the total cost of ownership, not the headline price: the subscription at the plan you would be on and what drives it, implementation and partner costs if any, the hours the team gives the tool each month, and the exit. business.gov.au tells small businesses to work out upfront plus running costs over the tool's life; the Association for Financial Professionals recommends a three-year model. The market prices per company, per entity, by revenue band, per licence and by quote, and the cost guide sets out what to ask about each.

If the sheet points at the ledger route, a weekly 13-week view and a team that reviews and does not rebuild, and you run Xero or QuickBooks Online, you can fill the sheet in against your own numbers with a free 14-day trial of Float, or book a demo and bring the sheet.