Building a 13-Week Direct Cash Flow and Liquidity Model in Anaplan: Receipts, Disbursements, Covenant Headroom, and Variance

Most Anaplan finance estates can tell you what net income looks like in Q3. Far fewer can tell you what the bank balance looks like next Tuesday. That gap is the reason treasury teams still run the most business-critical forecast in the company out of a workbook emailed around on Monday mornings — the 13-week direct cash flow.

An integrated three-statement model gives you an indirect cash flow statement: net income adjusted for non-cash items and working capital movements, monthly, on an accounting calendar. Treasury needs something different. It needs a weekly, receipts-and-disbursements view built from open AR, open AP, payroll dates, debt service, and tax calendars — accurate enough in weeks one through four to make a borrowing decision, and directionally useful out to week thirteen.

This tutorial builds that model in Anaplan. It assumes you are comfortable with weekly time ranges, SUM/LOOKUP, and CUMULATE, and that you have some form of data hub in place.

Direct vs. indirect, and why you need both

	Indirect (three-statement)	Direct (13-week)
Starting point	Net income	Opening bank balance
Grain	Monthly, by entity	Weekly, by bank account and currency
Built from	P&L and balance sheet movements	Open AR, open AP, payroll, debt, tax
Horizon	12–60 months	13 weeks, rolling
Answers	Will we generate cash this year?	Can we cover Friday's payroll without drawing the revolver?
Owner	FP&A	Treasury

Do not try to make one module do both jobs. Build the direct model as its own spoke and reconcile it to the indirect view monthly — that reconciliation is a control, not a redundancy.

Step 1: Weekly time, done properly

Anaplan's native weekly calendar is the first design decision and the one people most often get wrong.

• Set the model calendar to Weeks: General with the week start day treasury actually uses (usually Monday), or use a 4-4-5 / 13-period calendar if your fiscal calendar demands it.
• Create a dedicated time range — FY13W — spanning the current fiscal year plus one, at weekly granularity. Do not put weekly granularity on the default model calendar if the rest of your estate is monthly; you will inflate every module that does not need it.
• Add a Week Flags module dimensioned by Time (weeks) with:

Is Forecast Week?   = Week Start Date > Last Actual Date
Week Index          = CUMULATE(1, Is In Horizon?)
In 13W Horizon?     = Week Index >= 1 AND Week Index <= 13
Week Label          = "W" & TEXT(Week Index) & " (" & TEXT(Week Start Date) & ")"
Month Mapping       = parent month, for reconciliation to the monthly model

Week Index relative to Last Actual Date is the backbone of the whole model. Every report, every variance view, and every chart should be driven from it rather than from absolute dates, so the model rolls forward by changing one input.

Step 2: The cash flow line structure

Create a Cash Flow Lines list — flat, ordered, with a Category property (Receipt, Disbursement, Financing) and a Sign property. Twenty to thirty-five members is the right range; more than fifty and nobody reads the report.

A workable starting structure:

Receipts: customer collections (AR-driven), customer collections (cash sales), intercompany receipts, interest income, tax refunds, asset disposals, other receipts.

Disbursements: AP vendor payments, payroll and benefits, commissions and bonuses, rent and leases, indirect tax remittances (VAT/GST/sales tax), income tax instalments, capex, interest, principal repayments, dividends, intercompany payments, other disbursements.

Financing: revolver draw, revolver repayment, term debt draw, equity issuance.

Keep the list a list. Resist the urge to make these line items — you want the flexibility to reorganise the report, roll the same structure across entities, and drive each member from a different forecasting method.

Step 3: Dimensions and the entity/currency question

Core dimensionality for the forecast module:

Cash Flow Lines × Entity × Bank Account × Time (weeks) × Version

That is potentially large, so be deliberate:

• Bank Account is a flat list with Entity, Currency, Account Type (operating, concentration, restricted), and Counterparty Bank properties. Restricted cash must be identifiable and excluded from available liquidity.
• Forecast in transaction currency at the account level, then translate. Do not forecast in reporting currency and back into local — treasury decisions are made in the currency the payment leaves in.
• Not every line applies to every account. Use a boolean Applies? module on Cash Flow Lines × Bank Account and apply Dynamic Cell Access from it. A sparse plan with DCA-blocked cells is far easier for a treasury analyst to use than a fully open grid of mostly-zero cells.

Step 4: Driving receipts from open AR

This is where a direct forecast earns its accuracy. Load the open AR ledger into the hub at invoice grain: customer, invoice number, invoice date, due date, amount, currency, entity.

In the hub, build a collection-timing behaviour model from payment history:

Days Late (Actual)     = Payment Date - Due Date, on closed invoices
Avg Days Late          = weighted average by customer segment, trailing 6 months
Collection Bucket %    = distribution across On Time / 1-15 / 16-30 / 31-60 / 60+ days late

Then, per open invoice, spread the amount into forecast weeks:

Expected Pay Date  = Due Date + Avg Days Late (Customer Segment)
Target Week        = week containing Expected Pay Date, clipped into the horizon
Expected Receipt   = Invoice Amount * (1 - Bad Debt Provision %)

Aggregate invoice-grain results up to Customer Segment × Week once, in one module, and reference that aggregate downstream. Never carry the invoice list into the report layer — the same discipline that keeps a commission model fast keeps a cash model fast.

Three refinements that materially improve accuracy:

• Segment the behaviour, don't average it. Large enterprise accounts pay on their own schedule, and one strategic customer paying 20 days late can swing a week. Forecast the top 20–50 customers individually and the tail by segment.
• Add a manual override layer. A credit controller who has just spoken to a customer knows more than your historical distribution. Give them Override Week and Override Amount line items with a Note field, and show overrides distinctly on the report.
• Model new business separately. Open AR covers invoices that exist. Revenue not yet invoiced needs a separate driver: forecast billings from the sales model, apply invoicing lag and payment terms, and spread with the same bucket logic.

Step 5: Disbursements — mostly calendar, not behaviour

Disbursements are more deterministic than receipts, which is why direct forecasts are usually sound on the outflow side and wobbly on the inflow side.

AP vendor payments. Load open AP at invoice grain and spread by your actual payment run calendar, not by due date. If you run payments on Tuesdays and Thursdays, an invoice due Wednesday pays Thursday. Build a Payment Run Calendar module by Entity × Week flagging the run days, and snap expected payment dates to the next available run.

Payroll. Fully calendar-driven and worth its own module. Pull gross pay from the workforce planning model, then build a Payroll Calendar by Entity × Week with pay date flags, and split into net pay, payroll taxes, pension and benefit remittances — these often leave on different dates. Semi-monthly payrolls produce three-payroll months in some quarters; a naive monthly divide-by-4.33 will miss that entirely and it is exactly the week treasury cares about.

Tax. Indirect tax remittance dates, income tax instalments, and payroll tax deposits are all fixed-date, large, and lumpy. Hard-date them in a Tax Calendar module rather than modelling them as a percentage run rate.

Capex and projects. Take phasing from the capex model and apply a payment lag to each milestone. Capex accruals and capex cash almost never land in the same week.

Recurring fixed items. Rent, leases, insurance, software subscriptions, and debt service belong in a simple recurring-schedule module: amount, frequency, first payment date, escalation.

Step 6: Rolling the balance forward

CF01 Cash Position dimensioned Bank Account × Time × Version:

Opening Balance      = IF Is First Week THEN Actual Bank Balance (loaded)
                       ELSE PREVIOUS(Closing Balance)
Total Receipts       = SUM of forecast over Cash Flow Lines where Category = "Receipt"
Total Disbursements  = SUM of forecast over Cash Flow Lines where Category = "Disbursement"
Net Financing        = SUM over Cash Flow Lines where Category = "Financing"
Net Cash Movement    = Total Receipts - Total Disbursements + Net Financing
Closing Balance      = Opening Balance + Net Cash Movement

Then the liquidity layer, which is the part the treasurer actually reads:

Unrestricted Cash      = SUM of Closing Balance where Account Type <> "Restricted"
Revolver Limit         = input
Revolver Drawn         = CUMULATE(Draw) - CUMULATE(Repayment)
Undrawn Availability   = Revolver Limit - Revolver Drawn - Outstanding LCs
Total Liquidity        = Unrestricted Cash + Undrawn Availability
Minimum Cash Policy    = input by entity
Headroom               = Total Liquidity - Minimum Cash Policy
Breach Flag            = Headroom < 0
Weeks to Breach        = first Week Index where Breach Flag is TRUE

Weeks to Breach is the single number that justifies the whole build. Surface it on the landing card.

Add covenant tests if you have a facility with financial covenants — typically net leverage and interest coverage, tested quarterly on a trailing-twelve-month basis. Because the covenant is tested on accounting metrics rather than cash, pull the TTM inputs from the monthly model and show projected covenant headroom alongside cash headroom. A company can be cash-comfortable and covenant-tight at the same time, and finding that out from a bank rather than from your own model is a bad day.

Step 7: Scenarios that mean something

Treasury scenarios are not the same as FP&A scenarios. Use versions or a small Scenario list with stress levers that are specifically about timing and liquidity:

• Collection slippage: add N days to all expected pay dates, or shift the collection bucket distribution one bucket later.
• Top customer delay: your three largest receipts slip by 30 days.
• Payment stretch: extend AP terms by N days — a management action, so model it as a lever rather than a shock.
• Revenue shortfall: new business billings at 80% of plan.
• FX shock: ±10% on major pairs, which matters if receipts and disbursements are in different currencies.
• Facility withdrawal: undrawn availability set to zero.

For each, report minimum liquidity across the 13 weeks, the week it occurs, and peak revolver draw. Those three numbers, per scenario, on one grid, are what a board liquidity slide actually needs.

Step 8: Variance — the discipline that makes it accurate

A weekly cash forecast without a weekly variance review degrades to guesswork within a quarter. Build the loop into the model.

Snapshot each published forecast into a version or a Forecast Vintage list member. Then:

Actual (Week)          = loaded from bank statements, by line and account
Forecast (Week, W0)    = the forecast for this week made last week
Variance $             = Actual - Forecast (W0)
Variance %             = Variance $ / ABS(Forecast (W0))
Variance Type          = IF ABS(Variance %) < Tolerance % THEN "In Tolerance"
                         ELSE IF Timing Offset Found? THEN "Timing"
                         ELSE "Permanent"
Forecast Accuracy %    = 1 - (SUM of ABS(Variance $) / SUM of ABS(Actual))

Separating timing variances from permanent ones is the most useful thing this module does. A receipt that arrived in week 3 instead of week 2 is a timing variance and self-corrects; a receipt that is not coming at all is permanent and must be removed from the horizon. Treating them identically produces a forecast that keeps re-promising cash that already failed to arrive.

Track Forecast Accuracy % by week offset — accuracy for week 1, week 4, week 8, week 13 — as a trended chart. It sets honest expectations with the board about how far out the forecast can be trusted, and it gives the treasury team a metric that visibly improves as the model matures. Requiring a Variance Reason on every out-of-tolerance line, with DCA blocking the week from closing until reasons are entered, is what turns the review from an exercise into a habit.

Step 9: The weekly cycle

1. Monday early: bank balances and transactions load automatically via Data Orchestrator or CloudWorks; open AR and AP refresh; Last Actual Date advances one week.
2. Monday mid-morning: variance report generates; out-of-tolerance lines flagged for reason codes.
3. Monday afternoon: credit control reviews and overrides collection timing on the top accounts; AP reviews the payment run plan.
4. Tuesday: entity treasury leads confirm their forecasts through Anaplan Workflow.
5. Tuesday afternoon: group treasury reviews consolidated liquidity, headroom, and scenarios; publishes the vintage snapshot.
6. Wednesday: borrowing, repayment, and sweep decisions execute against the published forecast.

If the cycle cannot complete in a day and a half, the forecast is stale before it is used. Automate the loads; that is usually where the time goes.

Step 10: The pages

Three UX pages cover it.

Liquidity Overview (treasurer): KPI cards for total liquidity today, minimum liquidity over 13 weeks, week of minimum, peak revolver draw, and weeks to breach. A combined chart of closing cash bars with a liquidity line and the minimum-cash policy as a threshold. A scenario comparison grid underneath.

13-Week Detail (analyst): the classic grid — cash flow lines down, 13 weeks across, opening and closing balance rows, with actuals in the past weeks and forecast ahead, visually separated. Drill from any cell to the invoice or schedule behind it.

Variance and Accuracy (process owner): last week's actual versus forecast by line, timing/permanent split, reason codes, and the accuracy trend by week offset.

Performance and build notes

• Keep weekly granularity confined to the time range that needs it. A weekly module spanning five years is a common and avoidable cause of size problems.
• Aggregate invoice-grain AR and AP to segment or vendor-group level once, then work from the aggregate. Invoice lists belong in the hub.
• Store the bank transaction history you need for behaviour modelling in the hub, not the spoke. Six months rolling is usually enough for collection buckets.
• Use Forecast Vintage sparingly — thirteen rolling vintages at full dimensionality is a lot of data. Snapshot at line-category level for accuracy tracking and keep full detail only for the current and prior forecast.
• Reconcile the direct forecast to the indirect monthly cash flow every month end. Unexplained differences are nearly always intercompany settlements, FX revaluation, or restricted cash misclassification — find them once and the control holds.

What to build first

You do not need all ten steps to deliver value. A first release that runs in three to four weeks:

1. Weekly time range, bank account list, and cash flow line structure.
2. Actual bank balances loading automatically.
3. AP and payroll forecasting from calendars — the deterministic, high-value outflows.
4. AR collections at segment level with a manual override layer.
5. The cash position roll-forward, minimum cash policy, and headroom.
6. The 13-week detail grid and a single liquidity KPI card.

Add scenarios, covenant testing, vintage variance tracking, and the accuracy trend in release two, once the weekly cycle is running and people trust the numbers. A direct cash forecast earns credibility by being reviewed every single week, not by being comprehensive on day one.

Where this usually goes wrong

Forecasting cash from the P&L. Revenue is not collections and expense is not disbursement. If your direct model is built by applying a lag to P&L lines, you have built a slower indirect forecast, not a direct one.

Ignoring the payment run calendar. Due dates are not payment dates. Snapping to actual run days moves material amounts between weeks.

No variance loop. Accuracy comes from the review, not the maths. A model with no weekly variance discipline will be abandoned within two quarters.

Weekly granularity everywhere. Confine it to a dedicated time range and the modules that genuinely need it.

Treating restricted cash as available. Tag account types from day one and exclude restricted balances from liquidity.

Built this way, the 13-week cash forecast becomes the most-used page in the Anaplan estate — not because it is elaborate, but because someone makes a real borrowing decision from it every Wednesday morning.

If you are extending an existing Anaplan financial model into direct cash and liquidity forecasting, or replacing a treasury spreadsheet that has become a single point of failure, our Anaplan consultants have built this pattern across multiple industries and calendar structures. Get in touch to scope it.