Automating cash flow forecasting with n8n and AI

The cash flow spreadsheet many SMEs still keep has a structural flaw: it's accurate on the day someone takes the time to fill it in, then goes stale the moment the next transaction happens. The result is that an overdraft often gets discovered the same day it occurs — when the bank rejects a direct debit — rather than three weeks earlier, when there would still have been time to chase a receivable or push back a supplier payment. The building blocks to fix this already exist and are documented on this blog: the Qonto or GoCardless banking API for the real balance, the Pennylane or Sage Business Cloud API for outstanding invoices. This guide assembles those blocks into a rolling cash flow forecast, refreshed automatically, that alerts before the overdraft rather than after.

Why a manual forecast always arrives too late

A hand-maintained cash flow forecast suffers from three compounding flaws: it demands data-entry time that few SMEs set aside every week, it relies on manually pulling the list of outstanding invoices (easily forgotten as soon as activity picks up), and it only updates at the pace of whoever maintains it — never in real time. A recent study by Bartłomiej Małkus, Szymon Bobek, and Grzegorz J. Nalepa, published in 2025 ("Financial Management System for SMEs: Real-World Deployment of Accounts Receivable and Cash Flow Prediction", see the study), deployed under real-world conditions with freelancers and small businesses, starts from exactly this observation: existing forecasting tools target large enterprises with abundant historical data, while very small and small businesses have little history and limited resources to exploit it — which justifies an approach combining customer payment-delay prediction and cash flow forecasting, built for those constraints rather than a simple port of a model designed for a large corporation.

The architecture: three sources, one projected balance

The n8n pipeline relies on three data flows that already exist in your tools, with no re-entry:

Schedule Trigger (daily, early morning)
        │
        ├─► Real bank balance (Qonto or GoCardless API)
        ├─► Unpaid customer invoices + due dates (Pennylane / Sage API)
        └─► Outstanding supplier bills + due dates (Pennylane / Sage API)
        │
        ▼
   Code: week-by-week projection (13-week rolling)
        │
        ▼
   Safety threshold breached? ── no ──► log to Supabase
        │ yes
        ▼
   Slack/email alert with the detail of the movements involved

Pulling the real bank balance

An HTTP Request node scheduled by a daily Schedule Trigger queries Qonto's Business API (GET /v2/transactions) or the GoCardless equivalent depending on your bank, to get today's balance and recent transaction history. This is the non-negotiable starting point of any projection: starting from an inaccurate balance invalidates everything downstream, however carefully it's calculated.

Listing receivables and payables coming due

Two additional calls to your accounting tool's API complete the picture: customer invoices still marked unpaid along with their due date (money that should come in), and recorded but unsettled supplier invoices along with their own due date (money that should go out). If your books run on Pennylane, the /customer_invoices endpoint and its /supplier_invoices counterpart cover exactly this need, as detailed in our n8n ↔ Pennylane connection guide.

Projecting week by week

A Code node adds up, for each week over the next three months, the starting balance, expected inflows (customer invoices due that week), and expected outflows (supplier invoices due that week). This weekly granularity over a roughly thirteen-week rolling horizon isn't an arbitrary choice: it's a proven financial management method, fine-grained enough to be actionable and short enough to stay reliable — unlike an annual projection that accumulates uncertainty. The same node recalculates the entire projection on every run rather than patching a running history, following the same full-recalculation principle covered in our Compare Datasets node guide for other reconciliation use cases.

Refining with AI: weighting due dates by actual customer behavior

A first version of the forecast assumes every customer invoice will be paid exactly on its due date — an optimistic assumption few businesses actually see confirmed. Once a few months of history have built up in Supabase (stated due date versus actual payment date, per customer), an AI Agent node or a simple LLM call can weight each upcoming due date by the average delay already observed for that specific customer, rather than treating every customer identically. This approach directly connects to the work of Dimitrios Kotios, Georgios Makridis, Georgios Fatouros, and Dimosthenis Kyriazis, published in the Journal of Big Data in 2022 ("Deep learning enhancing banking services: a hybrid transaction classification and cash flow prediction approach", see the study), which couples a bank-transaction classification model with a cash flow prediction model built on recurrent neural networks, as part of a banking service aimed at SMEs — the same logic of per-entity personalization rather than a single, global rule.

In practice within n8n, a structured prompt using a Structured Output Parser receives a customer's payment history and the pending invoice, and returns a likely payment date rather than the stated due date:

{
  "invoice_id": "F-2026-0842",
  "stated_due_date": "2026-09-18",
  "likely_payment_date": "2026-09-27",
  "average_delay_observed_days": 9,
  "confidence_level": "medium"
}

That adjusted date, not the raw due date, then feeds the week-by-week projection — a forecast built on optimistic dates is only good for creating false confidence.

Alerting before the overdraft, not after

An IF node compares, for each projected week, the calculated balance against a safety threshold you define (for example, one month of fixed costs). As soon as a week drops below that threshold, a Slack or email alert goes out with the detail explaining the drop — which customer invoices weigh on the expected inflow, which supplier payments are scheduled that week — so the decision stays human: chase an overdue receivable through an automated follow-up workflow, negotiate a deadline with a supplier, or draw on a credit line ahead of time rather than in a rush on the day itself. For ambiguous cases where the call deserves validation before acting (delaying a scheduled supplier transfer, for instance), the human-approval-via-Slack pattern closes the loop cleanly.

Logging to refine the model over time

Each weekly projection, once calculated, deserves to be archived in a Supabase table rather than overwritten by the next one — following the same traceability principle as our GDPR audit trail guide, applied here to financial data. This history serves two purposes: comparing the projection to reality after the fact to calibrate the safety threshold, and feeding the per-customer average delay calculation described above, which mechanically improves as the history grows longer.

Common pitfalls

• Ignoring recurring movements with no invoice. A SaaS subscription charged automatically or a salary paid at month-end goes through no invoice at all: without a separate list of these recurring fixed costs, the projection systematically underestimates outflows.
• Confusing the due date with the actual payment date. This is the naive model's costliest gap, and the whole reason for the customer-history weighting described above.
• Setting one arbitrary safety threshold forever. The right threshold depends on the seasonality of the business and moves with it — a shop with a December peak doesn't need the same cash cushion in January as in September.
• Logging no history at all. Without archiving past projections, there's no way to know whether the model systematically over- or underestimates the real balance, and therefore no way to correct it.

Taking it further

This forecast closes the loop between the bank and the accounting system already connected to n8n: if bank reconciliation isn't automated yet on your end, our Qonto and Pennylane guides lay the exact groundwork reused here. For the logging and audit-trail side of every projection, the Compliance & Audit Pack (€149) provides the Supabase schema and follow-up workflows already built. If supplier invoices still arrive by email before any processing, the Inbox AI Pack (€79) handles their initial sorting. All three packs, bundled in the Complete FlowKit Bundle (€269 instead of €347 bought separately), cover the entire financial journey, from receiving the document to a consolidated view of cash flow.