The First 90 Days of a Fractional CFO Engagement
Founders who have never worked with a fractional CFO tend to picture the same thing: someone arrives, builds a beautiful financial model in a week, and hands it over. That is not what happens, and engagements that start that way are usually the ones that fail quietly six months later. Here is what the first ninety days actually look like when they work.
I have started enough of these engagements now to notice the pattern in how founders describe their expectations on the first call. They talk about "the model" — as if the deliverable is a spreadsheet, and the job is to produce it quickly. It is a reasonable thing to assume, because that is what most people can picture a CFO doing. It is also close to backwards. The model is not the hard part, and building it first is the most common mistake I see, including from CFOs who should know better.
The hard part is everything that has to happen before the model means anything: knowing which numbers in the business are real, which are assumed, which are simply wrong, and why. Skip that step and the model is a well-formatted guess. It will look finished. It will not survive the first hard question from an investor or a board member, because nobody actually checked whether the inputs were true.
Days 1–15: the audit, not the advice
The first two weeks are unglamorous and mostly involve reading. I go through twelve months of bank statements against the general ledger, line by line, not because I distrust the bookkeeper but because reconciliation gaps are where the real information lives. I pull the cap table and every underlying document — SAFEs, option grants, advisor agreements — and check whether they agree with each other, which they frequently do not. I look at what the founder currently uses to answer the question "how much cash do we have," and how many steps that takes.
This phase produces a list, not a plan. Typically it runs ten to twenty items: a SAFE conversion term that was never modelled correctly, three months of subscription revenue booked as one-time, an option grant that exists in a Slack message but not in any document, a vendor contract with an auto-renewal nobody flagged. None of these are dramatic individually. Together they explain why the founder's existing numbers do not add up, and why every board update takes longer than it should.
A financial model built on top of unreconciled data does not become more accurate because the formatting is good. It becomes a more convincing way to be wrong. The audit is what lets everything built afterward — the model, the board deck, the fundraising narrative — actually hold up when someone pushes on it.
Founders sometimes find this phase frustrating, because it does not look like progress. There is no deliverable to show a board member, no chart to put in a deck. I tell people upfront that this is coming, for exactly that reason — an engagement that skips straight to something presentable in week one is usually building on a foundation nobody checked.
Days 15–30: the first reporting pack
The first real deliverable is not the full model. It is a monthly reporting pack that is accurate, even if it is not yet sophisticated: revenue by the actual definition the business uses, burn calculated consistently, cash position reconciled to the bank, a short narrative explaining what moved and why. Plain, correct, and repeatable is the standard, not impressive.
The first thirty days are not about building the model the founder is picturing. They are about fixing plumbing nobody has looked at closely in a year, and making sure the next number produced is one you can actually trust.
This is also when the operating relationship gets established — how often we talk, what the founder still owns directly versus what moves to me, and which decisions need to happen together rather than in a monthly update. Getting this cadence wrong early is a quieter failure mode than any single accounting error: a CFO who is too hands-off produces reports nobody reads in time to act on them, and one who is too involved becomes a bottleneck the founder starts routing around.
Days 30–60: building the model that reflects the business
Once the reporting layer is stable and the historical numbers reconcile, the financial model gets built — and it gets built on top of the audit, not instead of it. This is the part that actually looks like what founders expected from day one, and it goes faster than they expect once it starts, because the slow part already happened.
The model has to reflect how the specific business actually works, not a generic SaaS template downloaded from somewhere. A company with usage-based pricing needs different revenue logic than one selling annual contracts. A two-sided marketplace needs supply and demand modelled separately before they get combined into a single revenue line. Getting this structure right is most of the effort; once it exists, updating it monthly is quick.
This is also when scenario planning starts in earnest — a base case, a case with slower growth, a case that tests what happens if a specific large customer churns or a specific hire does not work out. The point of scenarios is not to predict the future correctly. It is to know, before something happens, roughly how much runway it costs.
One thing founders consistently underestimate is how much of this phase is a conversation rather than a spreadsheet exercise. Building the revenue logic for a usage-based product means sitting with the founder and working through how pricing tiers actually behave when a customer upgrades mid-cycle, or what happens to recognized revenue when a annual contract gets paid quarterly. I cannot infer that from the accounting system alone — it lives in the founder's head, in sales contracts, and occasionally in nobody's head at all, which is its own useful discovery. Blocking two or three hours across these weeks for that kind of working session matters more to the quality of the eventual model than any amount of time I spend alone in a spreadsheet.
Days 60–90: settling into a rhythm
By the final third of the first quarter, the engagement should feel less like a project and more like an operating rhythm: a monthly close that happens on a predictable schedule, a board package that gets assembled in hours rather than days because the underlying data is already clean, and a founder who can answer basic financial questions immediately instead of promising to check and follow up.
This is also usually when the actual priorities of the engagement become clear, because by now I understand the business well enough to see them. For one company that might be getting investment-ready ahead of a raise starting in a few months. For another it might be pricing work, or getting genuine visibility into unit economics across products. The first ninety days are what make it possible to have that conversation with real information behind it, rather than guessing at priorities in week one before anyone has looked closely at anything.
Where it goes wrong, on both sides
The most common founder-side mistake is treating the engagement as bookkeeping with a better title — expecting transaction categorization and month-end numbers, and being surprised when the CFO also wants to be in strategic conversations. The value of the role is largely in those conversations. An engagement that never gets invited into them ends up producing accurate reports about decisions that were already made.
The second common mistake is withholding context that feels embarrassing — the cap table nobody wants to fully explain, the customer contract with terms that were a mistake, the co-founder situation that was never properly resolved. Every one of these surfaces eventually during the audit anyway. Surfacing it early costs less than having it discovered.
On the CFO side, the most common failure is impatience: skipping the audit because the founder wants a model immediately, and producing something polished that is quietly wrong. A close second is over-building — delivering a twenty-tab model with more granularity than a twelve-person company needs, because it is easier to build a complicated model than to decide what actually matters and leave the rest out.
There is a subtler version of over-building that is worth naming separately, because it looks like diligence rather than a mistake: modelling every product line, every geography, and every pricing experiment to the same level of detail regardless of size. A ten-person company with one meaningful revenue line does not need the same model architecture as a company with four distinct business units. Matching the model's complexity to the business's actual complexity — rather than to what a spreadsheet is capable of — is a judgment call, and it is one that gets revisited every few months as the company grows into needing more granularity than it started with.
How to know it is actually working
At the ninety-day mark, the honest test is not whether the model exists. It is whether specific things have changed. Can the founder state current burn, runway, and the top two things driving variance from plan, without opening a spreadsheet? Does the cap table reconcile to the underlying documents, with every SAFE and grant accounted for? Does a board request that used to take a week now take a day, because the reporting pack already answers most of it? Has at least one real decision — a hire, a pricing change, a renewal — been made differently because of something the numbers showed?
If most of those are true, the ninety days did their job, even if the model still has rough edges and always will — models are living documents, not finished products. If none of them are true and the primary output has been a polished spreadsheet nobody consults between board meetings, something in the sequence above got skipped, usually the part that does not look like progress.