What Fractional FP&A Actually Buys You: The Deliverable Nobody Shows You Before You Sign

The Deliverable Nobody Shows You Before You Sign

The founder asked to see a sample. "Before we move forward, what does the actual model look like?"

Fair question. He'd been burned before by a consultant who promised "monthly cash flow forecasts" and delivered a three-tab spreadsheet with hardcoded formulas and no scenario logic. It looked clean in the demo, broke the moment you tried to change an assumption, and told you nothing you couldn't have sketched on paper in twenty minutes.

So he wanted to see the real thing. Not a pitch deck describing the work. The actual file.

I sent him a redacted version of a three-statement model I'd built for a similar-stage company: integrated P&L, balance sheet, and cash flow statement, driver-based revenue build, working capital schedule, debt service waterfall, scenario toggles at the top. Forty tabs, maybe fifty formulas deep in places, every line sourced and every assumption documented in a separate assumptions log.

He called back the same day. "This is what fractional FP&A actually is?"

Yes. That's the deliverable. Not a summary, not a dashboard that hides the work, the actual working model that runs the business's financial logic forward in time under different conditions and shows you where it breaks.

And almost nobody shows you that file before you sign, because most people selling "FP&A" aren't building it.

This is what Part 2 of this series unpacks: what the core fractional FP&A deliverable actually looks like when you open the file, why it's structured the way it is, and how to tell whether what you're being offered is a real model or expensive window dressing. A shorter version of this post appears on LinkedIn, but the full structural breakdown lives here.

---

What a Real Three-Statement Model Actually Contains

A three-statement model integrates three financial statements: the income statement (P&L), the balance sheet, and the cash flow statement. The integration is the point. Each statement feeds the others, and the model as a whole has to balance at every time step, or the logic is broken.

Here's what that means in practice.

The Income Statement

Revenue starts from drivers, not guesses. If you're a SaaS company, that's new bookings by cohort, churn rate, expansion revenue, pricing tier distribution. If you're a services business, it's utilization rate, billable headcount, average project size. The model calculates revenue from those inputs, it doesn't accept a top-line number and work backward.

Cost of goods sold follows the same logic. Unit costs, volume, timing. If your COGS includes third-party fees that scale with revenue, the model ties them to the revenue line with a driver or a percentage, and you can see exactly how margin behaves as volume changes.

Operating expenses are broken out by category, fixed versus variable, and often by department if the business is large enough to make that distinction useful. Salaries are a separate schedule, usually tied to a headcount plan that shows hires by month and role. The model knows when each person starts, what they're paid, and what burden rate applies.

The result is net income, but more importantly, the result is a P&L where every line has a reason and you can trace that reason back to an assumption you control.

The Balance Sheet

This is where most "financial models" quietly stop being models. The balance sheet is hard to build because it requires you to track everything the P&L affects: retained earnings, accounts receivable, inventory, accounts payable, debt principal, equity.

A real model does this automatically. Net income from the P&L flows into retained earnings. Revenue on credit terms creates a receivable that sits on the balance sheet until it's collected, and the timing of that collection is governed by your days sales outstanding assumption. Inventory builds when you produce and draws down when you sell, and the cash timing of those events is not the same as the P&L timing.

Debt sits on the balance sheet as a liability, and the model tracks the principal balance separately from the interest expense that hits the P&L. If you have a revolver, the model should be able to draw on it automatically when cash goes negative and pay it down when cash is available, subject to covenants.

The balance sheet has to balance. Assets equal liabilities plus equity, every period, or the model is wrong. That's not a nice-to-have, it's the test of whether the logic holds.

The Cash Flow Statement

This is the one founders care about most, and the one that's hardest to build correctly. The cash flow statement reconciles net income to cash, and it does that by adjusting for everything that affects cash differently than it affects the P&L.

Depreciation is a P&L expense that doesn't touch cash, so it gets added back. An increase in accounts receivable means you recognized revenue but didn't collect it yet, so that's a use of cash. An increase in accounts payable means you incurred an expense but didn't pay it yet, so that's a source of cash.

Capital expenditures hit cash when you pay for them, not when you depreciate them. Debt principal repayments come out of cash but don't touch the P&L. Equity raises add cash but don't affect net income.

The cash flow statement is where you see the truth. A company can be profitable on paper and still run out of cash, and the cash flow statement is the part of the model that shows you exactly when and why that happens.

---

Why Integration Matters More Than Any Single Statement

The reason you build all three statements together is that the business doesn't experience them separately. When you hire someone, that's a P&L event (salary expense) and a cash event (payroll timing) and potentially a balance sheet event (if there's deferred comp or equity). When you sell on credit, that's a P&L event (revenue) and a balance sheet event (AR) and a cash event (collection, whenever it happens). When you take on debt, that's a balance sheet event (liability) and a P&L event (interest) and a cash event (principal payments).

The model has to track all of that simultaneously, or it's not telling you what actually happens. And the way you know it's tracking correctly is that the balance sheet balances and the cash flow statement reconciles.

Most of the "models" I see when a founder asks me to review their existing setup fail this test. They'll have a revenue forecast and a rough cash burn estimate, but no balance sheet, no working capital logic, no way to see what happens if payment terms slip or if a large customer delays. The model looks fine in the base case because the base case was tuned by hand, but the moment you stress it, it breaks.

A real model doesn't break when you change the assumptions. That's what makes it a model.

---

Scenario Logic: The Part That Separates Planning From Guessing

A financial model without scenario toggles is just a spreadsheet with last year's numbers rolled forward. The value is in being able to ask "what if" and get a coherent answer.

What if revenue grows 10% slower than plan? What if a key hire slips by two quarters? What if your largest customer churns? What if your revolver gets pulled?

A real model lets you toggle those assumptions at the top of the file and watch the entire three-statement structure update. Revenue slows, so AR grows more slowly, so cash collection lags, so you draw more on the revolver, so interest expense rises, so net income falls, so retained earnings are lower, and the balance sheet still balances.

That's not magic, it's just correct accounting logic built into the formulas. But it's also the difference between a model that helps you make decisions and a static forecast that's obsolete the day you finish it.

I usually build three scenarios: base, upside, downside. Base is the plan you're operating to. Upside is what happens if two or three things go better than expected. Downside is what happens if two or three things go worse, and it's the one you should be spending the most time on, because downside is when you need the model to be right.

The downside scenario should answer: when do we run out of cash, what would we need to do to avoid that, and how much runway do we actually have if we pull the obvious levers (freeze hiring, cut discretionary spend, renegotiate terms)?

If your model can't answer those questions, it's not doing the job.

---

Working Capital: The Schedule Everyone Forgets and Regrets Later

Working capital is the gap between when you recognize something on the P&L and when cash actually moves. It's accounts receivable (you sold, they haven't paid yet), inventory (you bought, you haven't sold yet), and accounts payable (you owe, you haven't paid yet).

Most early-stage founders don't think about working capital because it's small when the business is small. But it scales with revenue, and it scales badly if your payment terms are loose or your inventory turns slowly.

Here's the formula for the cash impact of a change in working capital:

An increase in AR is a use of cash. An increase in inventory is a use of cash. An increase in AP is a source of cash. The model should calculate these automatically based on your assumptions about collection days, inventory turns, and payment days.

If you're growing fast, working capital is usually a drag on cash. You're selling more, so AR is growing. You're buying more inventory to support the sales. Your payables might be growing too, but typically not fast enough to offset the other two.

This is how a profitable, growing company runs out of cash. Revenue is up, net income is positive, but working capital is consuming more cash than the business is generating, and nobody saw it coming because the P&L looked fine.

A real model shows you this in advance. Not after.

---

Debt Service Waterfall: When Capital Structure Gets Complicated

If your business has debt, the model needs a debt schedule. Principal balance, interest rate, payment frequency, amortization schedule, covenants.

For a single term loan, that's straightforward. But if you have multiple tranches, or a revolver with a borrowing base, or PIK interest, or warrants attached to the debt, the schedule gets complicated fast.

A debt service waterfall maps out how cash flows through the capital structure. Cash available for debt service hits the highest-priority obligation first (usually revolver interest), then the next (term loan interest), then principal repayments in order of seniority. If there's not enough cash to cover everything, the model shows you what gets skipped and what the consequences are.

This matters most when cash is tight. The model should be able to tell you: if we miss next quarter's revenue target by 15%, do we breach a covenant? If we breach, what's the cure period, and what do we need to do to get back into compliance?

I've seen companies lose weeks of negotiating time with their lenders because they didn't have a model that could answer these questions quickly. The lender asks for a revised forecast under stress, and the company scrambles to build it from scratch, and by the time they have an answer, the conversation has moved past them.

A model built correctly answers that question in an hour, because the logic is already there.

---

The Assumptions Log: Why the Model Needs a Memory

Every assumption in the model should be documented. Not in a comment buried in a cell, in a separate tab that lists every driver, the value you're using, the source for that value, and the date you last reviewed it.

Revenue growth rate: 8% month-over-month, based on trailing six-month average, reviewed 2026-08-30.

Churn rate: 3.2% monthly, based on cohort analysis through July, reviewed 2026-08-15.

Gross margin: 62%, based on Q2 actuals adjusted for planned price increase in Q4, reviewed 2026-09-01.

The assumptions log serves two purposes. First, it makes the model auditable. Someone else can open the file, read the log, and understand exactly what you assumed and why. Second, it makes the model maintainable. When you come back to it three months later, you're not guessing what you meant by a formula, you're reading the assumption that drove it.

This is especially important if the model is going to be used by more than one person, or if it's going to be shared with a lender or an investor. A model without an assumptions log is a black box. A model with one is a tool someone else can actually use.

---

What This Looks Like in Practice: A Worked Example

Let's walk through a simplified example. You're running a SaaS business. You have 200 customers at the start of the year, average contract value of $12,000 per year, paid monthly. You're adding 15 new customers per month. Churn is 2.5% monthly. Your cost to serve each customer is $200 per month.

The revenue build starts with the customer count:

Month 1: 200 + 15 - (200 × 0.025) = 200 + 15 - 5 = 210 customers.

Revenue in month 1 is:

Cost of goods sold:

Gross profit: $210,000 - $42,000 = $168,000.

Now assume you bill customers on the first of the month and collect on average 30 days later. That means January revenue of $210,000 doesn't turn into cash until February. The model tracks this with a receivables schedule:

(This is simplified; a real model would use a more nuanced collection curve based on your actual DSO.)

So in January, AR increases by $210,000. In February, you collect the January revenue, and AR increases by the difference between February revenue and January collections.

On the cash flow statement, the increase in AR in January is a use of cash:

If net income in January was $100,000 (after operating expenses), and AR increased by $210,000, cash flow from operations is $100,000 - $210,000 = -$110,000. You're profitable, but you're burning cash because of the timing gap.

This is what the model shows you. And this is why a P&L alone doesn't tell you whether you can make payroll next month.

---

How to Evaluate What You're Actually Getting

When someone offers you fractional FP&A, ask to see the model. Not a sample output, the actual working file. If they won't show it to you, that's your answer.

If they do show it, here's what to look for:

Does the balance sheet balance in every period?

Can you change an assumption at the top and see the whole model update?

Is there a separate assumptions log?

Are the formulas documented, or are you staring at a wall of nested IFs and VLOOKUPs with no explanation?

Does the cash flow statement reconcile net income to cash, or is it just a list of ins and outs?

If the model fails any of those tests, it's not a model, it's a spreadsheet pretending to be one.

The deliverable matters because the deliverable is what you're left with when the engagement ends. If it's a black box, you're stuck. If it's a real model, you can run it yourself, update it as the business changes, and use it to make decisions without calling someone every time you need to see a new scenario.

That's what fractional FP&A actually buys you. Not advice, not a consultant who sits in your meetings and nods, a tool that does the work.

---

Next week: what happens once the model is built, and how the retainer structure keeps it useful instead of letting it go stale the moment the business changes.

If you'd like to see what a working model looks like for your business specifically, I keep a few slots open each month for diagnostic calls: [calendly.com/muhammed-adediran/30min](https://calendly.com/muhammed-adediran/30min).