Forecast Version Control: How Biotech CFOs Build a Defensible Forecast Record
What a defensible forecast record looks like, and a checklist you can run this quarter with whatever software you already have.
Forecast version control is the discipline of keeping every forecast you issue as a frozen, reproducible record: which numbers went out, to whom, on what date, and why they changed from the version before. Engineers take this for granted in their code. In clinical-stage finance, mine included, it mostly runs on file names and memory.
The stakes are simple. A forecast you can't reproduce is a forecast you can't defend, whether the person asking is a board member, an auditor, or a lender's diligence team.
This piece lays out what a defensible forecast record looks like (four properties, none of them tied to a tool), and closes with a checklist you can run this quarter with whatever software you already have.
The question that arrives six months late
A clinical-stage biotech reforecasts constantly, and it should. A trial slips, a CRO reprices, actuals land, and the working forecast moves every month. That isn't sloppiness. It's the job being done right.
What breaks is the record.
Here's the board version. Ahead of the next board meeting, the CFO asks why the latest timeline slipped three months, when he was only expecting one. The impacts of the slip (lower expenses last quarter, a longer cash runway) are right there on the slide, and they're correct. The reasoning behind it is an archaeology and field research project: old decks, old email threads, reconfirming with ClinOps, understanding the drivers behind the updated timeline. The numbers survived; the reasoning went opaque.
Here's the diligence version, and it's worse. A lender's team arrives with a ten-word question: "Show us every forecast you sent the bank this year." The honest answer takes days of archaeology (sent-mail folders, file names ending in FINAL_v6, a quiet hope that what surfaces matches what everyone remembers). Every gap between the file you found and the numbers they remember quietly burns credibility with the people writing the checks.
I'll own my version of this. There's a folder on every finance drive labeled something like "BOD Approved." I know because I've dug through mine, months later, trying to triangulate: is this file the version I saved and set down forever? Or did I modify it after the board asked for two changes before approving? I am the finance function at my clients. I reforecast constantly, which is exactly what a good clinical-stage finance team should do. The versions multiply because the work is being done right. What the spreadsheet never held was the record: which version each audience actually saw, and whether the file in the folder is truly the one that went out.
Fifteen years in biotech finance taught me that diligence isn't really testing your numbers. It's testing whether your finance function can reproduce its own history on demand.
Why spreadsheet workflows cannot prove what your board last saw
I want to be careful here, because this is not a competence argument. I've written before about why FP&A teams build in Excel: platforms built for predictable revenue don't fit a company whose next year might be a Phase 3, and nothing else bends to each company's own web of trial timelines, vendor contracts and cash. The people running biotech FP&A in spreadsheets are doing genuinely complex work with remarkable skill. The problem is structural: a spreadsheet workflow has no concept of an issued version, so the discipline has to be supplied by hand, every time, under deadline.
Three things follow from that.
Save-over destroys history. The moment you overwrite the file, the prior state is gone unless someone deliberately made a copy first (and remembered where they put it).
"v4_FINAL_boardcopy" naming is discipline pretending to be architecture. It works right up until the week it doesn't, and that week is always the busy one.
Email attachments are a distribution channel, not a system of record. Sent mail tells you a file left the building. It doesn't tell you whether that file was edited afterward, or which of two identically named attachments was the one on screen in the room.
Underneath all three sits the deeper problem. A forecast is a document full of decisions, and in a spreadsheet every one of them is invisible. Nobody can later separate reality catching up (enrollment slipped) from a choice that was made (we added a cohort). Both show up as the same changed cell with the same date on it.
"What the board last saw" has to be provable from a frozen record, not inferred from whichever file happened to be open. No spreadsheet workflow can make that claim.
What a defensible forecast record looks like
Four properties. None of them depends on a particular tool. If your process has all four, you're defensible regardless of what you run it on. If it's missing one, that gap is where diligence will find you.
Versions are issued, not saved
Saving is something you do all day. Issuing is a declaration: this is the forecast, and it's going to someone who matters. An issued forecast is frozen, numbered, and tied to a named audience (board, investor, bank) with a date and the name of the person who issued it.
The point of the distinction is that distribution and record-keeping become the same act. In a save-and-email workflow they're two acts, and the second one is the one that gets skipped.
Reforecasting is the verb. Issuance is the punctuation.
Issued versions never change
Corrections happen by issuing a new version, never by editing the old one. If Version 3 had an error, the record should show Version 3, the corrected Version 4, and the stated reason connecting them. That's not an embarrassing trail. It's exactly the story a diligence team expects a well-run finance function to tell.
Auditors don't ask whether you kept the file. They ask whether anyone could have changed it since. If the honest answer is "anyone with the link," what you have is a file, not evidence.
An audit trail you can rewrite is not an audit trail.
Every change carries a written reason, captured when it happens
The reason gets written the day the change is made, in the words of the person who made it, not reconstructed at quarter-end from memory. Quarter-end reconstruction produces a plausible story. The day-of note produces the true one.
The reason also needs a classification, because not all movement means the same thing. Some of it is actuals landing (the plan was an estimate, and now it's real). Some of it is timing (the money didn't change, the month did). Some of it is a genuine increase or decrease to the plan. Sorting every change into one of those buckets, as you make it, is what lets you roll a year of edits up into a narrative.
"Expenses rose because the world changed" and "expenses rose because we chose to spend" are different board conversations. A year of classified changes shows which one dominated.
The board pre-read is a three-way reconciliation
Budget, last-seen, now. Budget is what the board approved. Last-seen is what this specific audience provably last received. Now is the working forecast. Movement per line between each pair, with commentary sitting where the movement is, not in a summary paragraph pages away.
Most pre-reads are two columns (budget versus current). That skips the column the board actually remembers, which is the one you showed them last time.
Two more things belong on that page. Cash context up top, expressed as weeks of buffer, because that's the number a clinical-stage board actually breathes. And honest exceptions: if you have to issue past a movement nobody has explained yet to hit a board deadline, record that by name rather than silently. A board deadline is a real constraint. A silent exception is a future problem with your name on it.
A forecast auditability checklist you can run this quarter
None of this requires new software. It requires deciding that the record is a deliverable, on the same footing as the numbers.
- Freeze and archive an exact copy of every externally sent forecast (PDF plus workbook) in one indexed location, and log the audience, the date, and the sender. If the board asked for two changes before approving, the archive holds two entries, not one overwritten file.
- Adopt a version register. Sequential numbers, one line per version stating what changed and why. No version ships without its line. A blank line is the gap every audit will eventually find.
- Keep a change log at edit time, with a small fixed reason vocabulary (timing shift, scope change, error correction, new information, decision) instead of freeform notes. The fixed vocabulary is what makes a year of changes summable.
- Build every board pre-read as budget versus last-sent versus current, per major line, with written variance commentary on every line that moved.
- Run a monthly sweep. List every line that moved since the last issued version with no explanation attached. Clear the list by explaining, escalating, or dismissing with a note. Don't issue until the list is either empty or its survivors are named in the record.
- Watch for the line that keeps sliding right. A cost deferred several quarters in a row without ever landing is a standing hard question, not a timing detail.
The checklist is boring on purpose. Diligence rewards boring.
Where Caladan fits
We built the Forecast Lifecycle Suite in CaladanCore (in production, limited availability) because this discipline should be architecture, not willpower. The four properties above are the design.
Every forecast version you've ever issued, to your board, your investors, your bank, is reproducible on demand, with who received it and when. Issued versions are immutable: no edits, no deletions, ever. No unnamed versions: every superseding forecast records why it replaced the last one, and the reason is required, not suggested.
The board pre-read tie-out, budget versus what they last saw versus now, is prepared by the system and exported in one click. Missing data shows as labeled blanks, never fabricated zeros. The reasoning behind every deliberate forecast change is written the day it happened, in the operator's own words, and it's permanent. Issuing past unexplained movements is allowed (board deadlines are real) but never silent: the version permanently names what it issued past.
Two things a spreadsheet workflow structurally can't do. First, the comparison is grounded in the issuance record: "what the board last saw" is provable, not "whichever file was open." Second, the permanence is append-only by construction: versions and change events are undeletable at the database layer, not by policy. That's architecture, not discipline, which is the whole point. I wrote about why the platform has to be the source of truth for the model itself; the forecast record is the same principle applied to what leaves the building.
The checklist above is worth running whatever tools you use. Software should make the record automatic. It shouldn't change the discipline.
The cost that has been "next quarter" for three quarters
There's a line in almost every long-running forecast that has been "next quarter" for three quarters. It got pushed once for a good reason, pushed again for a plausible one, and now it just sits out there, never landing, never cut, quietly propping up a runway number that assumes it's real.
CaladanCore catches the estimate that keeps sliding right without ever landing. A line whose cost gets deferred twice in a row without landing gets flagged as a standing hard question. Money that lands clears it. A deliberate decision to cut the cost clears it too, because a deferral resolved by choice is resolved, not stalled. Healthy enrollment-driven movement never flags at all: a per-patient line that re-estimates every month as enrollment moves is the well-maintained line, not the stalled one, and the flag is smart enough never to touch it.
Your spreadsheet will never tell you which line it is.
Defensibility is a property of the record, not the model
A brilliant model with no version history is one hard question away from an archaeology project. A modest model with a clean issuance chain answers it from the record, and the record is not whichever file was open.
If "show us every forecast you sent the bank this year" would cost your team days, I'd welcome the conversation.
Holly Lujan
COO & CFO, Co-Founder at Caladan
Holly is a biotech finance executive with 15 years of experience in FP&A for clinical-stage pharmaceutical and biotech companies. She is the co-founder and COO of CaladanAI, where she and her co-founder are building the financial operating system for clinical-stage biotech.
Learn about TrialCast® Engagement