You built a good 13-week cash template two years ago. It is on its fourth client now.
Client A has the original. Client B has the version where you fixed the VAT timing. Client C has the one where you added a line for the factoring facility, and client D has B's VAT fix but not C's facility line, because you started D from B on a Friday night.
Four files, all called roughly the same thing. None of them is the template anymore.
That is not a discipline problem. It is what happens to any Excel template that is copied rather than instantiated, and the fractional model makes it happen faster than anywhere else in finance.
Why fractional CFOs feel this more than anyone
The engagement model is the reason. In the CFO Connect 2026 benchmark, the first edition with a dedicated fractional section, 51% of fractional CFOs work with 3 to 4 clients at once, 26% with 2, and only 8% with a single company (fractional CFO statistics). And 65% of their clients have between 1 and 50 employees, which means most of them have no finance team to hold the model when you are not there.
So the same person runs the same 4 deliverables in parallel, for companies that look alike from a distance and differ everywhere up close:
- a 13-week cash forecast, often the first thing asked for and the one refreshed most often
- an annual budget, then a monthly budget vs actuals review against it
- a business plan for a raise, a bank, or a shareholder
- a board pack that pulls from the other three
A full-time CFO maintains one of each. You maintain 3 or 4 of each, at the same time, and the structures are mostly identical. That is the whole case for a template. It is also why the template decays.
How a copied template drifts, client by client
Three mechanisms, and they compound.
Fixes happen in the copy, not the master. You find a bug while working for client B, at 11pm, 2 days before their board. You fix it in client B's file. Going back to the master to fix it there too is the right thing to do and it almost never happens, because the master is not open and the deadline is. Six months later the fix exists in one file out of four.
Client-specific edits leak into the structure. Client C has a factoring facility, so you add a row and wire it into the cash waterfall. It is a perfectly good edit. But it is now part of the structure of that file, and the next time you copy from C, every new client inherits a factoring line they do not have, set to zero, feeding a subtotal nobody will question.
Conventions stay in your head. Client A reports in thousands and books costs as negatives. Client D reports in units, costs positive. Client B's "gross margin" excludes logistics because the founder has always calculated it that way. None of this is written in the file. You know it, and you carry it from call to call, until the day you are ill and someone else opens the workbook, or until you ask Claude to update it and it guesses.
Put together, the template you started with has become 4 forks with no common ancestor you could point to. Reusing it for client 5 means choosing which fork is least wrong.
This is the same pattern that makes deal teams rebuild their M&A model from scratch every deal, just running in parallel instead of in sequence.
Structure, conventions, data: what is standard and what is not
The fix starts with being precise about what a financial model actually contains. There are 3 layers, and a template should share exactly one of them.
| Layer | Examples | Standard or per client? |
|---|---|---|
| Structure | the 13 weekly columns, the receipts and payments waterfall, how opening cash rolls to closing cash, how the budget variance is calculated, the board pack KPIs and how each is derived | Standard. This is the template. |
| Conventions | currency and units, sign convention, fiscal year end, what "gross margin" or "adjusted EBITDA" means for this client, which revenue lines management steers on, materiality threshold for commentary | Per client, and written down. |
| Data | actuals, the opening bank balance, payroll, the client's chart of accounts and how it maps to your lines | Per client. Never in the template. |
Most drift comes from the middle row. Structure is visible and people protect it. Data is obviously client-specific. Conventions are neither, so they end up either silently hardcoded into the structure ("costs are negative in this file") or not recorded at all.
Two practical rules follow.
- If a line only exists for one client, it is not structure. The factoring facility belongs in client C's model as an extension, not in the master. If a second and third client need it, then promote it.
- If you would have to explain it to a replacement, it is a convention. Write it in a short file that lives next to the model, per client. A page is enough. The FINANCE.md standard is one open format for exactly this: currency, units, sign, glossary, and the objective of the model, readable by a person and by an AI agent.
Building a reusable model practice
This is the version that works without any particular software. It costs a few days once, and some discipline afterwards.
1. One master per deliverable, not one mega-template. A 13-week cash master, a budget master, a BP master. A single workbook that tries to be all 4 deliverables becomes the file nobody dares to touch. Small masters are easier to keep clean and easier to reason about.
2. Strip the master of every client. No sample data that looks real, no leftover account names, no client-specific rows. Inputs are clearly separated from calculations. If you cannot tell at a glance which cells a new client must fill, neither can Claude.
3. Keep a changelog on the master. One line per change: date, what, why, which client surfaced it. When you fix a bug in client B's copy, the rule is that the fix goes in the changelog the same day, even if it only reaches the master at the end of the week. The changelog is what lets you decide, later, which clients should receive it.
4. Version the master, and know which version each client runs. "Client A: 13-week v1.2, client D: v1.4" is a sentence you should be able to say. It turns "why does A's model behave differently" from an investigation into a lookup.
5. One conventions file per client. Created at kick-off, before the first number goes in. It is also the first thing you hand to an AI agent when you ask it to work on that client, which is how you stop re-explaining the same 10 conventions every session (the wider version of this problem is in persistent memory for a financial model).
6. Measure re-instantiation time. Starting a new client on your 13-week master should mean: copy the current version, fill the conventions file, map the chart of accounts, load the opening balance. If that takes more than an hour before real numbers go in, something client-specific is still living in the master. Find it and take it out.
The monthly refresh then becomes what it should be: new actuals in, variance out, commentary on what moved. The logic of a budget vs actuals review is identical across clients, and once the structure is shared, only the numbers and the commentary are new.
When copying a template is fine
Honestly, often.
- One-off engagements. A 6-week cash crisis, a single BP for a raise. You will not run this structure again for this client, so the drift never has time to matter.
- The client will own the file. If the deliverable is a workbook their finance manager maintains after you leave, it should be theirs, in their conventions, built the way they will understand it. Your master is a starting point and that is correct.
- Deliverables you build twice a year. The annual budget, for many small clients, is rebuilt from the prior year anyway. The value of a versioned master is small when the cadence is annual.
- One or two clients. The practice above pays back when the same structure runs in parallel across 3 or more live engagements. With 2, a careful copy and a notes tab will do.
The cost is real too. Keeping a master clean takes time that nobody bills for, and a rigid structure can fight a client whose business genuinely does not fit it. The goal is not that every client model is identical. It is that you can tell, for every difference, whether it is structure, convention or data.
Where Layerz fits
This is the problem Layerz was designed around, so it is worth being specific about what it does and what it does not do yet.
Layerz is a structured spreadsheet, ready for AI. The logic of a model (items, formulas, the links between them, the timelines) is stored separately from the values that flow into it. That separation is the first row of the table above, enforced by the tool rather than by your discipline. Claude can drive it through MCP, and any model exports to a clean Excel file whenever a client wants one.
For a model practice, that gives you:
- A master you instantiate rather than copy. Duplicate a model, or fork one from a template, and the new copy starts with the full structure. Saving a model as a private reusable template is part of the Team plan; duplicating a model works on the free Individual plan, which has no cap on the number of models.
- The conventions travel with the structure. Every model carries a FINANCE.md, and a fork keeps it, so the new client starts from the master's usage guide and you edit it into that client's conventions.
- Your existing Excel template as the starting point. You do not have to rebuild your master. The Excel import is deterministic (no AI in the pipeline): native formulas become the live structure, and the import shows a fidelity score for how much of the workbook came across as formulas versus values that stayed frozen, so you know what to check. Taking over a client's own workbook is a slightly different job, covered in taking over a client's financial model.
What it does not do today: a fork copies the model, not its data connections. Imported sources and account mappings do not come along with a fork yet, so each client's actuals are connected and mapped on the client's own copy. For a fractional practice that is mostly the behaviour you want (client A's ledger should never reach client B's model), but it means the mapping step in your re-instantiation checklist is still yours.
The takeaway
The template on its fourth client is not broken because you were careless. It is broken because every fix happened in a copy, every client-specific row leaked into the structure, and every convention stayed in your head.
Separate the 3 layers. Share the structure, write down the conventions, keep the data out. Then client number 5 costs an hour instead of days, and when you fix the VAT timing next time, you fix it once.