DEV Community: anthomakr

GitHub for Fractional CFOs: One Method Repo, One Repo per Client

anthomakr — Mon, 12 Oct 2026 14:59:12 +0000

Most guides on GitHub for finance assume a team: a CFO, a few analysts, a controller who reviews. The setup for finance teams is two repos, logic and data, and a review loop where the reviewer is never the author.

A fractional CFO has none of that team, and three or four companies instead of one. Half of fractional CFOs serve 3 or 4 clients at once (our statistics page). That changes the setup in three places: how many repos, who owns them, and who reviews.

The Rule That Matters More for You: Method Is Yours, Data Is Theirs

For a team, separating logic and data is good hygiene. For a fractional CFO, it is the business model.

Your method is what you sell: the close checklist you refined over thirty closes, the skills that draft the variance commentary, the mapping templates, the board pack structure, your conventions. It should get better with every client and follow you to the next one.

Your client's data is theirs: the ledger, the mappings filled with their accounts, their payroll, their board pack. It should never sit in a place that follows you to the next client, and confidentiality clauses increasingly say so in writing (see when the client contract prohibits AI).

On GitHub, that rule becomes a structure.

The Structure: One Method Repo, One Repo per Client

your-account/
  cfo-method            private, yours: skills, checks, templates, FINANCE.md template

client-a (the client's own GitHub organization)/
  finance               the client's repo: filled FINANCE.md, mappings, runs, exports

client-b/
  finance

cfo-method lives in your account and is private. The quickest start is to create it from the free finance-team-template on GitHub, which has a fractional CFO variant. It holds:

skills/: close, reconciliation, variance commentary, cash forecast, board pack draft. Written once, with no client name anywhere.
checks/: the tie-outs you run every month, as plain rules.
templates/FINANCE.md: your conventions file with the blanks a client fills (currency, fiscal year, sign convention, what "revenue" means at this company).
onboarding/: the checklist and the questions for week one.
CHANGELOG.md: what you improved, and at which client you learned it, without the client's data.

Each client repo lives in the client's organization, not yours. The client creates the organization (free) and invites you as a collaborator. Inside: their filled FINANCE.md, their account mappings, the outputs of each close, the exports sent to their board.

Why the client's organization, not yours

Because of the last day of the engagement. If the client repo is in your account, the end of the mission becomes a transfer, a copy, or a debate about who owns the mapping you built on their chart of accounts. If it is in theirs, you remove yourself and the work stays exactly where it belongs. It also answers the confidentiality question before it is asked: the client controls who sees their data, including you.

It costs the client nothing on GitHub Free, which allows unlimited collaborators on private repositories. If the client wants GitHub to enforce approvals on that private repo, that is the Team plan, priced per user (github.com/pricing, checked 12 October 2026).

How the Method Reaches a Client

The method repo never contains client data, and the client repo never contains your full method. The link between them is your agent session.

When you open a session for client B, Claude (or your agent) reads the skills from cfo-method and the conventions and mappings from client-b/finance. The skill is the same at every client; only the context changes. This is the a16z rule adapted to a portfolio, as we put it in AI for Fractional CFOs: if you do it at two clients, make it a template; at four, make it a skill.

What you must not do is improve a skill inside a client repo. You fix the accrual logic during client B's close, and the fix stays in client B's folder. Next month, client A runs the old version. Every improvement goes back to cfo-method through a pull request, and the client repo keeps only what is specific to the client.

Review When You Are Alone

The team rule is "the reviewer is not the author". Alone, you are always the author. Two substitutes work.

A test instead of a colleague. Every change to a skill is rerun on a month you already closed and signed, at at least one client. If the output matches the signed figure, the change can merge. If it does not, you have found the problem before a client did. Write the proof in the pull request: "October close, client A: EBITDA 412,300 before, 412,300 after."

The client as approver for anything that touches their numbers. A change to a client's mapping, a reclassification rule, a new forecast assumption: open it as a pull request in the client repo and ask their finance lead or founder to approve it. It takes them one click, it gives them a record of what changed in their reporting, and it gives you a written approval if the number is ever questioned.

Pull requests also make good working notes for the founder. "What changed in our reporting this quarter?" has an answer: the list of merged pull requests.

The Excel Question, Multiplied by Four

The finance team guide has a section on the Excel file git cannot read: git stores a .xlsx but cannot show what changed inside it. For a fractional CFO the problem is four times larger, because each client has its own model, and you rarely built it yourself (see taking over a client's model).

The fix is the same. Keep the model in a structured form with its own history and diff, and treat Excel as the export the client keeps.

This is where Layerz fits in a fractional practice. Each client model lives in Layerz as a structured spreadsheet: formulas and their dependencies readable, a history of changes, scenarios as branches, a diff between two versions. Claude edits it over MCP during the same session that reads your skills from GitHub. The client receives a clean .xlsx whenever they want one, and keeps it when you leave. Layerz is free for one person working alone, with unlimited models, so four clients cost nothing more than one.

Onboarding the Next Client

The setup is only worth it if the next client is faster. A first week that uses it:

Client creates a GitHub organization and a finance repo, invites you.
You copy templates/FINANCE.md into it and fill it with the client during the kickoff call.
You map their chart of accounts, using the mapping template from cfo-method.
You run your skills on the last closed month and compare with what they reported.
Whatever did not match becomes either a client-specific mapping (client repo) or a method improvement (pull request to cfo-method).

Keep one number: how many days from signed engagement to first close you are comfortable signing. If the method repo works, it goes down with every client.

Offboarding, in Ten Minutes

Last export of the model to .xlsx, saved in the client repo.
Final changelog entry in the client repo.
Any method improvement learned at this client merged into cfo-method, without their data.
Remove yourself from the client's organization.

The client keeps the repo, the history, the approvals and the model. You keep the method, a bit better than when you arrived.

FAQ

Can I keep all clients in one repo with a folder each?
You can, but then their data sits in your account, every client folder is one permission mistake away from another, and offboarding becomes a copy job. One repo per client, in the client's organization, removes all three problems.

My clients are not technical. Will they create a GitHub organization?
Most will if you do it with them in five minutes during onboarding. If a client refuses, keep their repo in a separate organization you create for them and transfer it at the end; never mix it with your method repo.

Should my method repo be public?
Some fractional CFOs publish part of it as a calling card, the way agencies open-source their skills. Publish the generic pieces (a close checklist, a FINANCE.md template), keep the parts that are your edge private, and never publish anything learned from a client's data.

The Takeaway

GitHub fits a fractional practice better than it fits a team, because the line it draws (logic here, data there) is the line your contracts already draw. Keep your method in one private repo that improves with every client. Put each client's data in a repo they own. Replace the missing reviewer with a test and the client's approval. And judge the whole setup by one thing: whether the next client is cheaper than the last.

Keep Reading

GitHub for Finance Teams: A Setup Guide for CFOs (2026)

anthomakr — Mon, 12 Oct 2026 14:57:41 +0000

Six months ago, a finance team using AI meant one analyst with a clever prompt. Today it means a dozen skills, a close checklist an agent runs, three scripts that pull from the ledger, and a convention file that tells Claude which sign the expenses carry. All of it lives somewhere. Usually on the laptop of the person who wrote it.

Alyona Mysko, who writes The Finance Engineer, put the symptom well when her own team started building: files everywhere, nothing standardized, and automations that left on holiday with their owners. Her answer is the one developers reached twenty years ago. Put the work in a shared repository.

This guide is the finance version of that setup, with a free repo template you can copy at the end: what GitHub gives a finance team, the two-repo structure, what goes in each, how a change reaches production, and the two details most guides skip (a paid-plan feature you need, and the Excel file git cannot read).

Why GitHub and Not a Shared Drive

A shared drive holds the latest file. That is its whole job. It does not tell you what changed between the version that worked in September and the one that broke during the October close, it does not stop anyone from saving over a colleague's work, and it puts the vendor mapping for every subsidiary in the same folder as the skill that reads it.

GitHub adds three things.

	Shared drive	GitHub
History	Last version, sometimes a short revision log	Every version of every file, with who changed it and why
Control	Anyone with access can overwrite	A change waits in a pull request until someone approves it
Separation	Folders, same permissions everywhere	Separate repositories, separate permissions

The history is what you will use first. A skill that misclassifies accruals on day three of the close is not a crisis when you can open the version from last month, see the two lines that changed, and roll back.

The five words you need

Repository (repo): a project folder GitHub tracks.
Branch: your working copy of a change, separate from the shared version.
Commit: a saved change, with a one-line note on why.
Pull request (PR): "I changed this, please review it."
Merge: the approved change joins the shared version.

That is enough vocabulary for a finance team. Nobody needs to learn rebasing.

Step 1: An Organization, Not a Personal Account

Create the repos under a GitHub organization named after the company (acme-finance), not under the CFO's personal account. An organization means the repos belong to the finance function. When someone leaves, their access goes; the work stays.

Fifteen minutes: create the organization, ask each person on the team for their GitHub username, invite them under People.

Step 2: Two Repos, Not One

This is the rule that makes the rest safe.

finance-logic: everything you would reuse at another entity, or at another company. Skills, prompts, agent workflows, the close checklist, reconciliation checks, the convention file. No company data. The whole team can read it.

finance-data: everything specific to this company. Chart-of-accounts mappings, entity settings, vendor rules, exported reports, the output of a run. Access is narrower, and it may differ by entity.

The test for where a file goes is one question: would this file be useful, unchanged, at a different company? If yes, logic. If no, data.

The payoff of the split is not only security. A skill that never sees a hard-coded entity name is a skill you can run on every entity. The moment someone writes if entity == "FR01" inside a skill, the logic has absorbed data, and it stops being reusable.

What goes in the logic repo

finance-logic/
  README.md            what this repo is, who approves changes
  FINANCE.md           conventions: currency, units, sign, fiscal year, glossary
  skills/
    month-end-close/   one folder per skill: instructions, examples, tests
    vendor-mapping/
    variance-commentary/
  checks/              reconciliation and tie-out rules, as plain text or code
  prompts/             reviewed prompts the team reuses
  CHANGELOG.md         one line per merged change, in finance language

Two files deserve a word.

FINANCE.md is the file an agent reads at the start of every session: currency and units, sign convention, fiscal year, what "revenue" means here, how the P&L is structured. Without it, each skill restates the conventions, and they drift apart. FINANCE.md is an open spec for that file; you can also write your own, what matters is that there is exactly one. More on the idea in The FINANCE.md Standard.

CHANGELOG.md is for the controller, not the developer. "Accrual skill now excludes intercompany invoices (approved by M.L., 14/10)" is a line an auditor can read. A commit hash is not.

What goes in the data repo

finance-data/
  entities/
    fr01/              mappings, settings, vendor rules for this entity
    uk01/
  runs/                outputs of each close, dated
  exports/             reports sent to the board or the sponsor

Never put credentials in either repo: API keys and ledger tokens go in a secret manager or the agent's own configuration, not in a file someone can commit. A .gitignore that refuses .xlsx, .csv and .env files in the logic repo, plus a check on every pull request, turns the rule into a control (both are in the template below).

Step 3: The Review Loop

Every change follows the same path:

Open a branch for the change.
Make it (often with Claude Code or another agent doing the writing).
Run it on last month's data, which you already know the answer to.
Open a pull request: what changed, why, and the before/after on last month.
A reviewer approves, or asks for changes.
Merge, and add the line to the changelog.

Step 3 is the one finance teams skip and the one that matters most. A skill is tested when it reproduces a close you already signed. "It ran without an error" is not a test.

A good pull request description for a finance change has four lines:

What: the skill or check that changed.
Why: the problem it fixes, in business terms.
Proof: the figure it produced on last month, against the figure you signed.
Risk: which entity or which report it touches.

The paid-plan detail

Here is the part most setup guides leave out. "Nothing goes live without review" only holds if GitHub enforces it, through branch rules and required reviewers. On GitHub Free, those rules apply to public repositories only. Your finance repos are private, so on Free anyone with write access can still merge without approval: the review becomes a convention, not a control.

Enforced review on private repos is a GitHub Team feature, listed at $4 per user per month on github.com/pricing (checked 12 October 2026). For a finance team of six, that is a rounding error next to the cost of one bad close. If your auditor will ever ask "who approved this change to the close process?", pay for it.

Step 4: The Excel File Git Cannot Read

Sooner or later someone commits the budget workbook to the data repo. Git will happily store it, and every version after it. What git cannot do is tell you what changed.

Git compares text, line by line. A .xlsx file is a zipped bundle of XML: change one assumption and the diff says the binary file changed, full stop. The two things you most want to review in a finance change, which formula moved and which number it moved, are exactly the two things the pull request cannot show. Cell-level diff tools for Excel exist and help at the margin, but the workbook is still the wrong unit of review: a formula pasted as a value looks like a one-cell change.

So the practical rule is:

Text goes in GitHub: skills, conventions, checks, mappings, prompts. Git was built for it.
The model lives in a structured, text-based form with its own history and its own diff: variables, formulas and their dependencies, timelines, scenarios. Git-friendly formats exist for that (JSON definitions, plain-text accounting files, a model layer with an API).
Excel is an export. You generate it for the board, the sponsor, the auditor. You do not review changes inside it.

This is the split Layerz is built on. A Layerz model is a structured spreadsheet: the structure (items, formulas, the links between them) is kept apart from the values, every change is recorded in the model's history, a scenario is a branch, and two versions can be diffed formula by formula. Claude edits it over MCP, so the same agent that runs the skills from your GitHub repo changes the model without retyping it. And it exports to a clean .xlsx whenever someone needs the file. The GitHub repo holds the method; the model holds the numbers and their logic.

You do not need Layerz to follow this guide. You do need an answer to the question "how do we review a change to the model?" that is better than "open both files side by side".

Step 5: Rules Worth Writing Down

Put these in the README of the logic repo, so a new hire reads them on day one.

No company data in the logic repo. Ever.
No credentials in any repo.
One FINANCE.md. Skills read it, they do not restate it.
Every change goes through a pull request, including the CFO's.
A change is tested on a month you already closed.
The reviewer is not the author.
One skill, one job. A skill that "does the close" is ten skills.
Changes to the close are frozen during the close.
The changelog is written for an auditor.
Models are reviewed in their own diff, not as Excel files.

Who Owns This: the CFO

It is tempting to hand GitHub to IT. Resist it. Every decision in this guide is a finance decision: who may change the close process, which entity's data a skill may read, what counts as tested, which approval an auditor will accept. IT can create the organization and connect single sign-on. The structure, the rules and the review belong to the person who signs the numbers. That is also why the role of finance engineer now appears in finance teams rather than in IT.

Where to Start This Week

Day 1: create the organization and the two repos. Move the convention file and the three skills people use most into finance-logic.
Day 2: write the README with the ten rules and the reviewer for each area.
Day 3: take one skill through the full loop: branch, change, test on last month, pull request, review, merge.
Day 4: decide on GitHub Team if the repos are private and the review must be enforced.
Day 5: decide where the model lives, and how a change to it is reviewed.

You do not have to start from an empty repo. Everything in this guide is packaged in finance-team-template, a free GitHub template (MIT): the folder structure, a FINANCE.md to fill, two example skills (month-end close, variance commentary), the tie-out checks, the pull request template, CODEOWNERS, the ten rules, and a GitHub Action that blocks spreadsheets, data exports and secrets from the logic repo. Click "Use this template" and name the copy finance-logic. For the models themselves, finance-models publishes forkable three-statement models (LBO, valuation, project finance, SaaS).

FAQ

Do finance people need to learn git commands?
No. GitHub Desktop or the web interface covers branch, commit and pull request. In practice, Claude Code or another agent writes most changes and opens the pull request; the human reviews and approves.

Is a private GitHub repo safe for financial data?
Keep company data in a separate repo with narrow access, keep credentials out of every repo, and check your contracts and your auditor's expectations before storing client or employee data there. The logic repo should hold nothing you would mind a contractor reading.

Can we just use SharePoint version history?
It records versions of a file. It does not give you a review before the change goes live, and it cannot show what changed inside a workbook either.

What about Excel files we must keep?
Store the exports in the data repo, dated, as a record of what was sent. Review changes in the model, not in the exported file.

The Takeaway

A finance team that builds with AI is now a small software team, whether it likes it or not. GitHub gives it history, review and separation for the price of an afternoon and a few dollars per seat. Put the logic in one repo and the data in another, enforce the review on private repos, and keep the model in a form whose changes you can actually read. Excel stays where it belongs: at the end, as the file you send.

Keep Reading

Month-End Close Across Multiple Clients: An AI Playbook for Fractional CFOs

anthomakr — Mon, 12 Oct 2026 10:37:21 +0000

OpenAI's finance team, according to a16z, is building toward "a zero-day close and a continuously updated forecast". That is the ambition of an in-house team with engineers on call and one company to run.

Your month looks different. Four clients. Four bookkeepers or accounting firms, each closing on their own schedule. Four ledgers, maybe four charts of accounts. And four board packs that all seem to fall due between the 5th and the 10th.

A fractional CFO on r/CFO put the problem in one sentence: "You can't review a pitch deck, review a sales partnership and present the financials to the board all at the same time for 5 different clients." And, the same comment goes on, the industry runs "on monthly cycles with deliverables expected between days 5-10 of the month."

Most guides to the AI-assisted close are written for one company. This one is written for a portfolio. Our stage-by-stage guide to the monthly close covers where AI helps inside a single close. Here the question is different: how do you run the same close at four clients without four times the work, and without letting a model near your signature?

Why a Portfolio Close Is a Different Problem

Three things change when the close is not yours alone.

You accept the close, you do not perform it. The accounting close (accruals, reconciliations, the trial balance) usually happens at the client's bookkeeper or accounting firm, inside the client's ledger. Your job starts when they say "done", and it consists of deciding whether "done" is true.

The calendars collide. Each client's accountant has their own deadline. Nobody coordinated them with your other clients. Without a deliberate calendar, everything lands in the same week.

The setup multiplies. A different ledger, a different chart of accounts, a different founder who wants a different level of detail. Any step that depends on remembering how this client works costs a warm-up every time you switch.

The fix is not to work faster. It is to decide, once, which parts of the close are standard across your clients and which parts are not.

The Rule: Reuse the Workflow, Never the Sign-Off

When we posted about this on LinkedIn, a finance manager asked exactly the right question in the comments: which part do you rebuild for each client? The answer fits in a table.

Standard across clients (build once)	Rebuilt for each client, each month
The close calendar logic	The dates agreed with this client's accountant
The acceptance checklist	The evidence that each check passed
The model structure (P&L, cash flow, balance sheet)	The actuals and the forecast values
The mapping template per chart of accounts	The exceptions in this client's mapping
The adjustment log format	Every adjustment, and who approved it
The board pack layout and commentary format	The commentary and the signature

Everything in the left column is a candidate for AI to run. Nothing in the right column should be decided by it.

The Playbook in Six Steps

Step 1: Stagger the calendar, in writing

Agree a close date with each client's accountant in the first month of the engagement, and spread your acceptance days so that no two clients land on the same day. An illustrative month for four clients:

Client	Ledger	Accountant's close	Your acceptance	Pack to founder
A	Xero	Day 4	Day 5	Day 7
B	Pennylane	Day 6	Day 7	Day 9
C	QuickBooks	Day 8	Day 9	Day 11
D	DATEV export	Day 10	Day 12	Day 14

The order matters less than the gaps. One acceptance day per client, with time to push back if the close is not clean. If an accountant slips, the slip stays on that client instead of spreading to the others.

Where AI helps: reminders and status. An assistant that checks each morning which clients are due, which exports have arrived and which are late is cheap to set up and removes a recurring source of stress.

Step 2: Write the acceptance checklist once

"Accepting the close" should mean the same thing at every client. Write the checks down:

the bank balance in the ledger ties to the bank statement at month end, for every account
receivables and payables aged balances tie to the ledger
payroll booked matches the payroll report
revenue ties to the billing system (Stripe or equivalent), within a stated tolerance
known recurring costs are accrued (rent, software, retainers)
the suspense or "to categorise" account is below an agreed threshold
VAT accounts move in line with activity
large invoices around the month end are booked in the right period

Some clients need more (inventory, intercompany, deferred revenue), so the checklist has a standard core and client-specific additions. The core does not change.

Where AI helps: running the checks on the exports and listing which passed, which failed, and by how much. It does not decide whether a failed check is acceptable. You do, and you write down why.

Step 3: Keep the sources untouched, and log every adjustment as data

This is the step that separates a close you can defend from one you cannot.

The exports from the ledger, the bank and the billing system stay as they arrived. You never edit them. When something needs correcting (a missing accrual, a misclassified invoice, a revenue cut-off), the correction is a separate row in an adjustment log:

Field	Example
Period, client	2026-09, Client B
Line affected	Software subscriptions
Amount	-1,200
Reason	Annual licence booked in full in September, spread over 12 months
Evidence	Invoice reference, contract dates
Proposed by	Assistant (flagged as unusual vs. the 6-month average)
Status	Approved
Approved by, date	You, 2026-10-07

Two things follow from this format. First, every number in your pack can be traced: source, plus logged adjustments, equals what you present. Second, recurring adjustments replay next month without being rediscovered. Practitioners who run this well often start by hand, with a few CSV files and a list of checks, and that is enough to begin.

This is the part a16z describes as "an auditable, trusted chain from each of finance's numbers to its source". In their words, if an agent drafts an entry, "it needs to keep the supporting work papers and evidence and follow approval rules before posting it."

Where AI helps: proposing adjustments, with the reason and the evidence attached. That is a large share of the work. The approval column is yours.

Step 4: Load actuals into a stable structure

Once the close is accepted, the actuals go into the model that drives reporting and the forecast. In a spreadsheet rebuilt by hand, this is where things break: a pasted column, a shifted row, a formula pointing one month off.

The fix is structural. If the model's structure (lines, formulas, links between statements) is kept separate from its data, loading a month of actuals is a data operation that leaves the logic alone. And if your mapping from each chart of accounts to your standard reporting lines is a template, the same structure serves all four clients. Fractional CFO Financial Model Template covers how to set that up.

Where AI helps: mapping the new month's accounts to your lines and flagging any account it has not seen before, instead of guessing silently. New accounts are where errors hide.

Step 5: Explain the variances, rank them, sign the commentary

With actuals in the model, the question is always the same: why is this different from the budget or the last forecast? Budget vs. Actuals explains why this stage eats whole days.

Where AI helps: ranking variances by materiality, tracing each to its driver in the model, and drafting the commentary in your standard format. A model that can see the structure can say that the overspend came from a hiring assumption, not just that costs are up 18%.

What you keep: deciding which explanations are real. The commentary goes to the founder with your name on it.

Step 6: Reforecast and ship the pack

The close is finished when the forward view is updated and the founder has the pack. Same layout at every client, numbers pulled from the model, and a file the client can edit without you or an assistant. Boards move slides five minutes before the meeting.

Where AI helps: rolling the forecast forward with the new actuals, running the one or two scenarios the founder will ask about, and drafting the one-page summary.

Where AI Should Stay Out of a Client's Close

Three lines hold at every client, whatever the tool:

No posting in a ledger you do not own. The official Xero and QuickBooks MCP servers expose write operations. For your work, read-only is the right scope. Entries are the accountant's job, under their review.
No automatic acceptance. A check that fails is a decision, not a status. The assistant reports; you accept or push back.
No untraceable figures in the pack. If a number came from a chat answer rather than from the model, it does not go in.

None of this slows the close down. Reviewing a proposed adjustment with its evidence attached takes seconds. Reconstructing an unexplained number the night before a board takes hours.

Measure the Close per Client

Track one number: hours per close, per client. Start the clock when the accountant's export arrives and stop it when the pack is sent.

The target is not a fixed figure. It is a shape. The fourth close of the month should cost a fraction of the first, because everything in the left column of the table above was already built. If it does not, find the step that still depends on remembering how this client works, and make it standard.

This number is also your pricing conversation. One fractional CFO on r/CFO started tracking hours per client against the retainer and found that "some clients were getting 60-70% more of my time than the engagement was priced for". You cannot fix that without knowing which clients.

Where Layerz Fits

Layerz is a structured spreadsheet, ready for AI. In this playbook, it holds steps 4 to 6: one model per client, built on a structure you reuse across clients, so a month of actuals loads without touching the formulas.

Claude drives it over MCP with your own account. It reads each client's conventions from the model's FINANCE.md, loads the accepted actuals (from Pennylane, Qonto and Stripe connectors, or from FEC, DATEV and any ledger report exported to Excel or CSV), compares actuals with the forecast, and runs scenarios as variants of the base case. The version history shows what changed in the model and when. Every model exports to Excel with formulas intact, so the pack and the model stay editable without anyone re-prompting.

It is free for one person working alone, with unlimited models: one per client, as many clients as you have.

FAQ

How many clients can a fractional CFO close each month?
51% of fractional CFOs work with 3 or 4 clients at once, and 16% with five or more (CFO Connect, 2026). The limit is less the number of clients than how many acceptance days collide. A staggered calendar is what makes five clients workable.

Can AI do the month-end close?
AI can run most of the mechanical work: normalising exports, running reconciliation checks, proposing adjustments with evidence, drafting variance commentary. Posting entries and accepting the close stay with people: the accountant posts, the CFO accepts.

What is the difference between the accountant's close and the CFO's close?
The accountant closes the books in the ledger (accruals, reconciliations, trial balance). The fractional CFO accepts that close, loads it into the model, explains the variances, updates the forecast and reports to the founder or the board.

How do I keep an audit trail when AI proposes adjustments?
Never edit the source exports. Record each adjustment as a row with the reason, the evidence, who proposed it and who approved it. The trail is then the source plus the log, and it replays the next month.

The Takeaway

You will not get a zero-day close across four companies you do not run. You can get a close that costs less every time you repeat it.

Standardise the calendar, the checks, the structure and the pack. Keep the sources untouched and every adjustment on the record. Let AI propose; approve it yourself. Reuse the workflow, never the sign-off.

Keep Reading

AI for Fractional CFOs: What to Automate, What to Sign (2026 Guide)

anthomakr — Mon, 12 Oct 2026 10:36:16 +0000

On 8 October 2026, a16z published You Need a New CFO. The argument fits in one line: the CFO went from accountant to banker, and is now becoming a builder. The scarce skill, they write, is "designing the operating system the company runs on. This means the data, workflows, agents, skills and controls that turn context into intelligence and decisions."

The piece never mentions fractional CFOs. Read it with one in mind anyway, and it reads like a portrait:

lean teams, down to 2% of headcount → a team of one
"senior domain experts can get the most leverage out of AI" → senior by definition
CFOs building their own tools → no IT department to ask
"an auditable, trusted chain from each of finance's numbers to its source" → your name on the numbers of every client
scenarios run live in the meeting → a different founder asking "what if?" every week
"if you do something twice, write a workflow" → the same close, three or four times a month

There is one difference, and it is the subject of this guide. a16z describes a CFO with a team, an engineering department down the hall, and one company to run. You have none of that, and four companies. So what does an AI-native practice look like when it is one person, several ledgers, and a signature on each?

The Shape of the Job, in Numbers

Start with what is measured. All figures below are on our fractional CFO statistics page, with sources and scope.

	Value	Source
Fractional CFOs working with 3 or 4 clients at once	51% (16% have 5 or more)	CFO Connect, Salary Benchmark 2026
Their main clients with 1 to 50 employees	65%	same
Fractional CFOs net positive about AI in finance	96%	same
Independent professionals not using AI at all	11%	Heidrick & Struggles, 2026
US firms with 4 or fewer employees using AI	under 20%	US Census Bureau, 2026

Read the last two lines together. You are more likely to use AI than your clients are. In most engagements, you are the one who brings it in, which means you are also the one who answers for it.

Three Layers: Drafted, Computed, Signed

Most advice on "AI for finance" asks which tasks to hand to a model. For a fractional CFO, the better question is who is accountable for each number, because the answer is always you.

Split every deliverable into three layers.

Drafted by the model. Commentary, summaries, first-pass mappings, the list of anomalies worth a look, the email to the founder explaining a variance. Language work. Fast, cheap, and fine to be wrong in a first draft, because you read it.
Computed by a structure. Totals, balances, ratios, the forecast, the cash runway. These should come from formulas in a model with a known structure, not from a model's arithmetic in a chat. A language model asked twice can answer twice differently. A formula cannot.
Signed by you. The accepted close, the board pack, the forecast you present, the advice. Nothing here should contain a figure you cannot trace back to its source in two clicks.

a16z puts the same idea in one sentence: "finance sets the rules and owns sign-off. Having controls enables speed." The second half matters as much as the first. Controls are what let you go fast, because you stop re-checking every step by hand.

The fear behind this split is not abstract. Fractional CFOs describe it in almost the same words everywhere: AI that silently changed figures, dropped lines from an invoice base, hardcoded an assumption, or gave a different result when asked the same question twice. When a full-time CFO is wrong, one company is affected. When you are wrong, the client is affected and so is the referral network your practice runs on.

Your Month, Stage by Stage

Here is the recurring work of a fractional practice, with what to hand to AI and what to keep.

1. Switching between clients

Every switch costs a warm-up: where was I, what did we decide, which version is current. Asked about the biggest pain of the job, a fractional CFO on r/CFO answered with the problem of every consulting business: "context switching." Across four clients and several switches a day, the warm-ups add up to hours a week.

Give AI: the recap. What changed since the last session, what is open, what the founder asked.

What makes it work: the context has to live somewhere other than the chat history. One project or workspace per client, with the conventions written down (currency, sign convention, what counts as recurring, the fiscal year), so the assistant reads them instead of guessing. We published FINANCE.md as an open format for exactly that file. Without it, every session starts from zero, and the six things that must survive between sessions are listed in Persistent Memory for a Financial Model.

2. The month-end close

You usually do not close the books. The bookkeeper or the accountant does. You accept the close, and you cannot accept four of them on the same day.

Give AI: normalising exports, flagging what moved, proposing explanations, drafting the acceptance checklist.

Keep: the acceptance itself, and every adjustment. The rule that works across a portfolio is short: reuse the workflow, never the sign-off. The full multi-client playbook (staggered calendar, acceptance checks, adjustments kept as data) is in Month-End Close Across Multiple Clients.

3. Reporting and the board pack

The pack is what the client judges you on. Keep the layout identical across clients, so the fourth pack of the month costs a fraction of the first.

Give AI: the first draft of the commentary, ranked by materiality; a plain-language summary for a founder who reads one page.

Keep: the numbers in the pack come from the model, never typed from a chat answer. And the file stays editable without AI. A board can move a slide five minutes before the meeting, and you will not be re-prompting anything then.

4. Forecasts and scenarios

a16z points to continuous planning and "complex scenarios live in the meeting". For a fractional CFO, the meeting is where the value is visible: a founder asks what happens to cash if hiring slips a quarter, and you answer on the spot.

Give AI: the scenario request in plain language, and the explanation of the result.

Keep: the scenario runs on the model's structure, as a variant you can compare to the base case, not as a fresh calculation in the chat. Otherwise you have a number you cannot reproduce next week.

5. Onboarding a new client

This is where a fractional practice wins or loses its margin. The first month on a new client is mostly reading someone else's spreadsheet and mapping a new chart of accounts.

Give AI: reading the inherited model, listing hardcoded values and broken links, proposing a mapping from the client's chart of accounts to your standard structure.

Keep: the decision about what to rebuild. The first-week checklist is in Taking Over a Client's Financial Model, and the way to reuse one structure across clients is in Fractional CFO Financial Model Template.

6. The founder's questions

"Can we afford this hire?" "Why is gross margin down?" These arrive by message, between closes. They are the most visible part of the job and the least priced.

Give AI: the first answer, drafted against the model, with the figures pulled from it.

Keep: the judgment. a16z quotes a growth-stage CFO saying junior staff "lack the experience and context to know what 'great' looks like". That context is what the client pays you for.

Write the Workflow Once, Run It at Every Client

a16z gives the operating rule of the finance engineer: "if you do something twice, write a workflow; if you write the workflow twice, write an agent." Anthropic's own finance team, they report, maintains "70+ finance-specific AI skills they treat like production code", one of which produces a 90 to 95% complete monthly review in about thirty minutes.

A portfolio gives you more repetitions than any in-house CFO. Translate the rule:

If you do it at two clients, make it a template. The model structure, the board pack layout, the acceptance checklist.
If you do it at four clients, make it a skill. A written procedure your assistant runs the same way every month: load actuals, run the checks, draft the variance commentary, list what needs your decision.
Version it like code. When a skill changes, you know which month's output it produced.

The test is consistency. The owner of an accounting practice with CFO advisory put the requirement plainly on r/CFO, after an automation that worked for 30 days and then switched tools on its own: "I want the same workflow and I want the same output." A skill that behaves differently at each client, or each month, is a prompt, not a workflow.

Build or Buy: The Fractional Version

Fractional CFOs were builders before the word was fashionable, because nobody else was going to build for them. Some of the most AI-fluent are now writing their own tools: a three-statement FP&A app built in Claude Code and used with paying clients, a saved script per client company driving QuickBooks through MCP, a close pipeline of CSV files and checks. Kevin Steele, a fractional CFO, walked through his own app at a CFO Connect live build: six weeks, no prior coding experience. His view: "If you're a fractional CFO, you can go crazy and code your own app." His warning, in the same session: "People are making business decisions with your information. It cannot be wrong."

That is a real option. It has three costs that are easy to miss at the start:

Upkeep. The tool works for the clients you built it on. Every new ledger, chart of accounts or edge case is a maintenance task, and the hours saved on the close go into the code.
Drift. A workflow that lets the model decide the structure each run will produce a slightly different model each run. That is fine for a draft, not for a forecast you present every month.
Key-person risk. A client, or a buyer in due diligence, will eventually ask who else can run this. An undocumented tool that lives on your laptop is a weak answer.

The line we would draw: build the method, own it, and keep it portable. The structure of your models, your mappings, your conventions, your skills. Put the computation and the history on a layer that does not depend on you remembering how it works, and that the client can open without you.

Confidentiality, Client by Client

A question that now reaches search engines almost word for word: how do fractional CFO firms handle confidentiality around financial data when they use AI? There is no single policy, because every client contract is different. There is a set of habits that holds up.

Work on the client's subscriptions, not yours. Ask for an advisor seat on their ledger. Do not import their books into an account you pay for.
One workspace per client. Never let one client's numbers sit in a conversation where another client's are.
Read-only on ledgers you do not own. The official Xero and QuickBooks MCP servers expose write operations as well as reads. For analysis, read-only is the right scope.
Check the contract, then ask. Some agreements forbid putting financials into an LLM, others require consent or specific retention terms. What those clauses actually cover is in Your Client's Contract Says No AI, and what happens to data on each AI plan is in AI and Confidential Financial Data.
Leave a clean exit. When the engagement ends, the client keeps a working Excel model, formulas intact, that their next CFO can read.

The Time You Save Is Not Free Time

The most common complaint in fractional practices is not about tools. It is about scope: "some clients were getting 60-70% more of my time than the engagement was priced for," one fractional CFO wrote on r/CFO, once they started tracking hours per client against the retainer. AI does not fix that by itself. It can make it worse, because faster answers invite more questions.

Two habits help. Track hours per client per close, so you can see whether the fourth close of the month is actually cheaper than the first. And price on the deliverable, not the hours, once the deliverable is stable. a16z frames the new CFO as someone who decides "what's best done by the team and by software". For a practice of one, that decision is also a pricing decision.

A Four-Week Start

If you are starting from scattered prompts, do not try to automate the whole month. Pick one client and one loop.

Week	Do	Done when
1	Write the conventions file for one client (currency, sign, fiscal year, what is recurring, materiality)	The assistant answers a variance question without asking you which sign convention you use
2	Put that client's model on a stable structure and load the last 12 months of actuals	Next month's actuals load without touching a formula
3	Write the close skill: load, check, draft commentary, list decisions	One close runs end to end, and you only made decisions
4	Run the same skill on a second client	The second client took less than half the setup time of the first

Week 4 is the only one that matters. If the second client costs as much as the first, the setup is not portable yet.

Where Layerz Fits

Layerz is a structured spreadsheet, ready for AI. It covers the "computed" layer of the split above: the model's structure (items, formulas, timelines, the links between the P&L, cash flow and balance sheet) is kept separate from each client's data, so you reuse one structure across clients while the values stay in each client's own model.

You bring your own agent. Claude drives Layerz over MCP: it reads the conventions in each model's FINANCE.md, loads actuals, builds scenarios as variants of the base case, and changes the model without breaking the formulas. Actuals come from Pennylane, Qonto and Stripe through native connectors, or from FEC, DATEV, and any ledger report exported to Excel or CSV. Every model exports to clean Excel with formulas intact, so the client keeps a file they can open without you.

It is free for one person working alone, with unlimited models. That is the shape of most fractional practices.

FAQ

How do fractional CFOs use AI in 2026?
Mostly for language work around the numbers: drafting commentary and board narratives, explaining variances, normalising exports, reading inherited models, answering founders' questions. The numbers themselves are better computed in a model with a known structure, and signed by the CFO.

Can AI replace a fractional CFO?
It replaces part of the hours, not the accountability. Clients hire a fractional CFO for judgment and for a name on the numbers. We wrote the longer answer in Will AI Replace the CFO?

What should a fractional CFO never hand to AI?
Posting journal entries in a ledger you do not own, accepting a close, and any figure in a deliverable that cannot be traced back to its source.

Which AI assistant do finance teams use?
In CFO Connect's 2026 tools survey, 41% of finance teams named Claude, ahead of Gemini (12%), ChatGPT (10%) and Copilot (9%). For a fractional CFO, whose account the assistant runs on and whether the client agreed matter more than which brand.

How do I keep AI outputs consistent across clients?
Write the conventions down once per client, run the same written procedure (a skill) every month, and let a structured model do the computation. Consistency comes from what persists between sessions, not from a better prompt.

The Takeaway

a16z wrote about CFOs with teams becoming builders. Fractional CFOs got there first, by necessity, and with a harder constraint: one person, several companies, and a signature on each.

Let the model draft. Let a structure compute. Keep the signature. And judge every piece of your setup by one question: does it make the next client cheaper than the last?

Keep Reading

The Fractional CFO Tech Stack, Layer by Layer (2026)

anthomakr — Mon, 28 Sep 2026 11:43:21 +0000

A full-time CFO picks a stack once and lives with it for years. You inherit four.

One client runs Xero with a bookkeeper in another time zone. One has Pennylane and a French accountant who closes on the 12th. One is German and sends you a DATEV export when the Steuerberater gets to it. The fourth has QuickBooks, Stripe and a forecast in a spreadsheet the founder built in 2023.

According to CFO Connect's 2026 salary benchmark, 51% of fractional CFOs work with 3 or 4 clients at once. That single number changes what "tech stack" means. Most published stack guides are lists of logos for a company that gets to choose. Yours is a question of which parts you carry between clients, and which parts you leave where they are.

Here is the stack, organised by layer.

Start With Ownership, Not Categories

Every layer below falls on one side of a line.

The client owns the ledger, the bank accounts, the billing system, the payroll, and every number inside them. When the engagement ends, all of that stays, and it should.

You own the method. The structure of your forecast, the way you map a chart of accounts to reporting lines, the conventions you apply (sign, materiality, what counts as recurring), the layout of your board pack, the prompts that work.

Get this line wrong in one direction and you rebuild your method from scratch at every new client. Get it wrong in the other and you end up holding client data in your own accounts, which is a confidentiality problem before it is a tooling problem.

Layer 1: The Ledger (the Client's)

You rarely choose it, and the market is fragmented. In the CFO Connect Top CFO Tools Report 2026, a survey of 215 finance leaders fielded in June and July 2026, the most-cited cloud accounting platforms were Xero (14%), NetSuite (10%), QuickBooks (8%), Pennylane (7%) and DATEV (7%), with Odoo, SAP and Sage behind. No platform clears 15%.

Among companies under 50 employees, the segment where most fractional work happens, Xero leads at 30% and QuickBooks follows at 14% (same report). By country, the picture shifts again: Pennylane in France, DATEV in Germany through the Steuerberater, Sage across the UK and continental SMEs.

Your job at this layer is access, not administration. Ask for an advisor or accountant seat on the client's own subscription, never import their books into an account you pay for. What you need out of the ledger is modest: a monthly P&L, a monthly balance sheet and the general ledger underneath, over the longest window available. The QuickBooks version of that routine is in How to Analyze Your QuickBooks Data with AI, and the Xero one in How to Use AI with Xero.

Layer 2: Bank Feeds and Billing

The ledger tells you what was booked. The bank tells you what is there today. For a cash forecast, which is often the first thing a fractional CFO is hired to produce, the gap between the two matters.

Most bank feeds already land in the ledger: Qonto, Mercury, Revolut Business or a traditional bank, synced for the bookkeeper's reconciliation. Billing sits beside it, often Stripe for subscription businesses. Treasury rarely has its own tool at this size. The same CFO Connect report found that 55% of finance teams manage treasury in spreadsheets and 17% have no treasury tool at all.

The practical rule: pull cash from the bank layer, not from the ledger, whenever the close runs more than a few days behind. A 13-week cash view built on last month's booked balance is already 3 weeks stale when you present it.

Layer 3: Close and Reconciliation

This layer is usually not yours. The bookkeeper or the external accountant closes the books, inside the ledger's own reconciliation rules or with a dedicated close tool.

What you own is the calendar and the standard: which day the numbers are final, what "final" means, which accounts you check before you accept the close. Agree it in writing in the first month of the engagement. Most of the fractional CFO's month is scheduled backwards from that date.

AI helps here, and finance teams know it: reconciliations were cited as the best AI use case by 9% of respondents in the CFO Connect survey, behind financial analysis (20%), reporting (12%) and modelling (12%). The method that keeps an audit trail is in How to Use AI for Your Monthly Financial Close.

Layer 4: The Model (Where the Forecast Lives)

This is the layer that decides whether your practice scales.

The market has not moved much. In the CFO Connect report, 76% of finance teams run FP&A in spreadsheets, up from 71% the year before, and another 7% use no tool at all. Among companies under 50 employees, the spreadsheet share is 85%.

Dedicated FP&A platforms exist and are good at what they are built for. Abacum, Pigment, Jirav, Runway, Mosaic and others give a single company a planning system with integrations, workflows and permissions. They fit best when the client has a finance team that will keep running the platform after you leave. If that is the case, build there, and hand over a system rather than a file.

For the other clients, the forecast lives in a spreadsheet. That is portable, which is why we all keep using it. It is also where the rebuild happens: a new client, a new chart of accounts, a model reassembled by hand or regenerated by an AI that re-decides the structure every session. Two companion pieces go deeper: taking over a client's existing model, and a template you can reuse across clients.

The test for this layer is simple. Can you open a new client on Monday and have their actuals sitting in your standard structure by Wednesday, without rebuilding the formulas?

Layer 5: Reporting and the Board Pack

The board pack is the part the client sees, so it is the part they judge you on.

Tooling varies: Excel and PowerPoint or Google Slides for the pack itself, a reporting add-on on the ledger (Fathom and Syft are two examples on Xero and QuickBooks), a BI tool such as Power BI, Looker Studio or Metabase once the client wants live dashboards.

Two rules hold whatever you use. The pack draws from the model, not directly from the ledger, otherwise you end up with two versions of revenue in the same meeting. And the layout is yours: the same structure, the same order, the same commentary format across every client. That consistency is the cheapest leverage in the job. Your fourth board pack of the month should take a fraction of the first.

Layer 6: The AI Assistant, and How It Connects

The assistant layer changed fastest. The CFO Connect report found that 67% of finance teams use AI tools in 2026, against 31% in 2024. Asked which tool, 41% named Claude, 12% Gemini, 10% ChatGPT and 9% Copilot, with Claude Code at a further 5%. Dedicated finance AI platforms were each named by 1% or less.

There are three ways an assistant reaches a client's numbers, and each has a different profile.

Upload an export. You download the P&L, drop it into the chat, ask the question. Nothing to set up, and nothing persists after the session.
Connect the ledger over MCP. The Model Context Protocol is an open standard for letting an assistant call external tools. Xero publishes an official MCP server, and so does Intuit for QuickBooks Online. The assistant can query the ledger directly instead of waiting for a CSV. Note that these servers expose create and update operations as well as reads. On a ledger you do not own, read-only is the right scope for analysis.
Connect a model layer over MCP. The assistant works on a structured model rather than on raw transactions, so the mapping and the forecast it builds are still there next month.

Then comes the question that matters more than which assistant: whose account does it run on, and has the client agreed? Some client agreements now prohibit putting financials into an LLM outright, others only require consent or specific retention terms. What those clauses actually forbid, and the workflows that stay inside them, is covered in Your Client's Contract Says No AI. What happens to the data on each plan is in AI and Confidential Financial Data. Keep a separate project or workspace per client, and never let one client's numbers sit in a conversation where another client's are.

The Portability Test

Run it on your own stack. For each item, ask whether it goes with you to the next client or stays where it is.

Goes with you:

the model structure (P&L, cash flow and balance sheet, and how they connect)
the mapping templates per chart of accounts: French PCG, SKR03 and SKR04, a QuickBooks default chart
your conventions, written down once, so an assistant reads them instead of guessing
the board pack layout and the commentary format
the prompts that have survived more than one client

Stays with the client:

the ledger, the bank, the billing data, the credentials
the actuals and the forecast values
a copy of the model, in a format they can open without you

The last line is the one that gets forgotten. When you leave, the client should keep a working model in Excel, with formulas intact, that their next CFO can read. Anything else is lock-in, even if you did not intend it.

Where Layerz Fits

Layerz sits in layer 4. It is a structured spreadsheet, ready for AI: the model structure is kept separate from each client's data, so the same structure can be reused from one client to the next while the values stay in each client's own model.

Claude drives it over MCP. It pulls actuals from Pennylane, Qonto and Stripe through native connectors, and takes FEC and DATEV files, or any ledger report exported to Excel or CSV. There is no native QuickBooks or Xero connector today: you export the reports, and Claude maps them into the model. It also imports an existing Excel model, which is usually where a new engagement starts. Every model exports to clean Excel with the formulas intact, so the client keeps a file their next CFO can open.

It is free for one person working alone, with unlimited models, which is the normal shape of a fractional practice. If a client runs a full FP&A platform with a team behind it, build there instead. Layerz is for the clients whose forecast would otherwise live in a spreadsheet you rebuild every quarter.

The Takeaway

You will not get to standardise your clients' ledgers, banks or accountants, and you should not try. That half of the stack belongs to them.

The other half is yours: the model structure, the mappings, the conventions, the board pack. Pick tools for that half on one criterion. Does it make the fifth client cheaper than the first?

Keep Reading

Taking Over a Client's Financial Model: A Fractional CFO's First-Week Checklist

anthomakr — Mon, 28 Sep 2026 11:41:00 +0000

The engagement letter is signed on Thursday. On Friday the founder sends you a workbook called Budget 2026 v7 FINAL (2).xlsx, with a note: the board meets on Tuesday, can you present the forecast.

You did not build it. The founder did, over two years, with a previous CFO who left in March. It has 14 sheets, three of them called Sheet1, old and Copy of P&L. The cash line in month 9 is a number with no formula behind it.

You have four days to be able to defend it. And then, unlike a deal, you have to keep it alive every month after that.

This is a checklist for that week.

Why this is not a deal review

The transaction reflex is to read it like a data-room file: start at the output, trace the drivers, write a red-flag memo. That method is right, and I wrote it up for analysts who inherit a model on a deal.

A client model is a different job in three ways.

You will own it. A deal model is read once and argued over. A client budget comes back every month with new actuals, and every shortcut you accept in week 1 is a shortcut you run in month 6.

The builder is still in the room. The founder knows why row 47 is hardcoded, and may be attached to it. Your review is also a conversation with the person who pays you.

The numbers already have a history. The board has seen last quarter's forecast. Whatever you change has to be explainable against what they were shown, or the first thing you present looks like a restatement.

And you do this several times over. CFO Connect's 2026 benchmark of 516 finance professionals found that fractional CFOs typically serve 3 to 4 clients simultaneously (more in our fractional CFO statistics). Four clients, four models you did not design.

Day 1: freeze a copy and write down what it is for

Before opening a single formula, do two things.

Save the file as received, untouched, with the date in the name. This is your baseline. When the founder says in May that the forecast used to show a profitable Q4, you want to be able to open the version that said so.

Write 5 lines on what the model is for. Who built it, when, what decisions it has fed (a fundraise, a hiring plan, a bank covenant), which numbers the board or the investors have already seen, and what you are expected to produce from it next. Ask the founder for what you cannot answer. Twenty minutes on a call saves a day of reverse-engineering.

That list is the one people skip, and it tells you which cells matter.

Step 1: map it

Start at the outputs. Find the 5 to 10 numbers that leave the file: the cash runway, the EBITDA line the board tracks, the headcount plan, the covenant ratio if there is debt. Then trace each one back to where it comes from.

While you trace, build a sheet inventory, one line per sheet:

Role: input, calculation, output, data (a ledger export, a bank statement), or unknown
Read by: which other sheets reference it
Time axis: monthly, yearly, both, none

The last column catches more than you would expect: a monthly P&L feeding a yearly cash sheet through a /12 is a timing assumption nobody decided.

Then list every sheet nothing reads. In a founder-built budget these are usually last year's version of a calculation, kept "just in case". They are noise, and you want them out of your head by day 2.

Step 2: find what is hardcoded

A deal model has usually been through a professional's hands. A founder budget has been edited by whoever was in a hurry that month, and a hardcode is the natural result: someone needed the forecast to show a number, and typed it.

It is also the most common way models fail. Across 85 operational spreadsheets examined through multi-day inspections, errors were found in 94% of them (Panko, EuSpRIG 2015; more figures in our spreadsheet errors and risks page). Not every error is a hardcode, but hardcodes are the ones that pass the eye test.

Three checks, in this order:

Constants sweep. In Excel, select the calculation sheets and use Go To Special, then Constants, numbers only. Every literal outside the assumptions area is either an input in the wrong place or a hardcode. There is no third category.
Pattern breaks. In a row where the same formula is dragged across 24 months, look for the one cell that differs. Month 9 overridden with a number is a typical find. Excel's green error triangle ("inconsistent formula") flags many of them.
Perturbation. Move one driver by 10%, the one that should ripple furthest (volume, price, headcount), and read the outputs. Anything that does not move is disconnected. Then undo it.

That takes about 15 minutes and finds most of it. The full list of checks is in how to stop AI from hardcoding a financial model. It applies whether an AI or a founder at 11pm typed the hardcode.

Do not fix anything yet. Write each finding down with its location.

Step 3: find the drivers

Now you know where the model is live and where it is frozen. The next question is which few inputs actually carry it.

In most small-company budgets the answer is 3 to 6 lines: new customers or volume per month, price or average basket, gross margin, headcount by month with average cost, payment terms, and one or two business-specific items (churn, a large contract, a capex programme).

For each driver, find three things:

Where it lives. One cell, or scattered across sheets? A growth rate typed in 4 places will be updated in 3.
Where it came from. A historical average, a board target, the founder's gut. Ask. "Where does the 8% come from?" is a legitimate question in week 1 and an awkward one in month 4.
How much it moves the answer. A crude sensitivity on runway is enough. If a 10% change in new customers moves runway by 2 months and payment terms by 2 weeks, you know where to look first.

Step 4: tie it to actuals

This step separates taking over a model from reading one. Before touching any forecast assumption, check that the model starts from reality.

Take the last 3 closed months and compare them line by line with the accounting: revenue, gross margin, payroll, total opex, closing cash. Then check that the opening cash of the first forecast month equals the bank balance at that date.

You will find gaps. The usual ones:

Actuals typed in by hand, from a P&L export, with one month copied from the wrong column
Accounts mapped differently from the accounting: the model's "Marketing" includes tools that the ledger books as software
Timing: the model books annual subscriptions when invoiced, the accounts spread them
Opening cash off because a financing inflow was forecast and never updated to what actually arrived

A forecast that does not start from the real opening cash is wrong in every month after, however good the drivers are. The monthly version of this problem, and why it eats hours, is in budget vs actuals.

Write down the account mapping you end up with. It is the most reusable thing you will produce this week.

Step 5: decide what to keep

You now have a map, a hardcode list, the drivers and a gap list. The temptation is to rebuild. Resist it for 2 weeks.

A simple triage, section by section:

Section	Ties to actuals?	Hardcodes?	Decision
Revenue build	Yes	2, known	Keep, fix the 2
Payroll	Yes	None	Keep
Opex	Partly	Several	Fix the mapping, replace hardcodes with drivers
Cash	No	Month 9	Rebuild from the P&L and working capital

Rebuild only what you cannot defend. Every number the board has already seen must stay reconcilable to whatever you hand them next. If you change the structure, prepare the bridge: last forecast, what changed, new forecast, one line per reason.

What you send the client at the end of week 1

One page. What the model is for, what you trust, what you do not trust yet and why, what you are changing before Tuesday, and what you will change over the next month. The founder should be able to read it in 5 minutes.

It sets the scope of what you will defend in front of the board, and it records, with a date, the state of the model the day you took it over.

Making month 2 cheaper than month 1

Engagements are getting longer. Heidrick & Struggles' 2026 survey of 3,810 independent professionals found that 42% of projects now last longer than six months, up from 27% in 2021 (across all functions, not CFOs specifically). The takeover week is a one-off. The monthly run is the job.

What makes month 2 cheap is keeping three things from week 1: the account mapping, the list of known hardcodes and what replaced them, and the version of the model you took over. If they live in your head or in an email thread, you will redo part of this checklist every month, for every client. I went through what has to survive between working sessions separately; it is the same list, whether the session is yours or Claude's.

Where Layerz fits

Everything above works in Excel alone. If you take over one model a year, do it that way.

If you take over several, steps 1 to 3 are the mechanical part, and that is the part Layerz now does for you. Layerz is a structured spreadsheet, ready for AI, and since September 2026 it imports an Excel model through a single Import file button.

The import is deterministic, with no AI in it. It reads the workbook and turns its formulas into the model's live structure: a dragged formula becomes a line that computes, an input row becomes an assumption. What does not come across is not hidden. You get:

A fidelity score: the share of the workbook's numbers that now live as formulas and values
Kept as values: the lines frozen to their Excel value, grouped by cause (a cell that broke its row's pattern, a formula with no equivalent). When a whole line is frozen, its original Excel formula stays attached to it as a comment
Not imported: what was left out and why, for example a sheet whose periods could not be dated

That report is the takeover map from steps 1 and 2, in the time it takes to upload the file. When the model totals a ledger sheet with SUMIFS per account and per period, that sheet comes in as a data source and those formulas become mapping rules: half of step 4's account mapping, written down for you. Not every ledger shape is read yet; the ones that are not show up in the report instead of disappearing. On any line, ⌘I opens the inspector: its properties, its notes, and what uses it.

Two limits, plainly. A high fidelity score means the model came across, not that it is right: a wrong assumption imports perfectly. And steps 4 and 5 are judgement. The import gives you somewhere to aim, it does not aim for you. When the client wants a file back, the model exports to Excel with live formulas. The verification cost does not disappear, it shrinks to the part only you can do.

The takeaway

The founder's workbook is not the problem. It holds two years of reasonable decisions about the business. None of them are written down, and you have four days.

Freeze it, map it, find the hardcodes by behaviour, find the few drivers that carry it, tie it to the ledger, and change only what you cannot defend. Then keep the map. Month 6 on this client, and week 1 on the next one, both start from it.

How to Stop AI From Hardcoding Values in a Financial Model

anthomakr — Mon, 28 Sep 2026 11:38:13 +0000

You asked for a five-year forecast. You got one in about fifteen minutes: assumptions page, income statement, cash flow, balance sheet, formatted to something close to professional standards.

Three weeks later, you change the growth rate from 12% to 9%. Revenue moves. Gross margin moves. Operating expenses sit exactly where they were.

Somewhere in row 34 there is a number that should have been a formula. It was right when it was written. It is wrong now, and it has been wrong since the moment you changed the assumption, silently, in a file you have already sent to two people.

That is a hardcode, and it is the single most common way an AI-built financial model fails.

Why it is worse than a wrong number

A wrong number announces itself eventually. Someone recognises that the figure is implausible, or a total does not tie, or a ratio looks absurd.

A hardcode does none of that, because when it is written it is correct. The agent computed a plausible value for that position and wrote the value instead of the relationship that produced it. The row totals correctly. The statement ties. The formatting is consistent. Every test you would run by eye passes.

The failure is deferred to the next time an input changes, and the person who changes the input is usually not the person who would recognise the omission.

The Financial Modeling Institute demonstrated this in front of an audience of finance professionals, building complete five-year models live from a single prompt. Their summary of the problem is the one worth remembering: finding and fixing a hardcode buried in an otherwise coherent line takes hours, because the hardcode does not show to the eye.

This is measured, not anecdotal

Two independent evaluations, from institutions with no product to sell in this category, land on the same failure.

Columbia Business School's MBABench is built specifically to score the artefact rather than the answer: does the agent produce a workbook a managing director could open, read, challenge and edit. Across 206 tasks and more than 18 agents, the best agent scored 72.6 out of 100 on medium-hard tasks, against 92.4 on easy ones: performance falls away as soon as a task is more than a few chained calculations. Hardcoding is measured directly: one frontier model hardcoded roughly a quarter of its answer cells rather than pointing them at the calculation sheets, while its workbook still presented well.

Wall Street Prep's 2026 comparison of four tools on a three-statement build reached the same place from a different direction. Every tool beat a human on setup, 15 to 25 minutes against one to two hours. None beat a weak analyst on the finished model. Debt integration was not handled properly by any of them. Interest that should depend on a balance, which itself depends on the cash flow that interest feeds, got resolved with a plug rather than a real link. And the most dangerous category of error they found was the subtle one: individual lines wrong, totals correct.

One more detail from the FMI demonstration, and it is the one that should change how you work rather than how you feel. The same prompt, run twice, produced different results. On an unbalanced balance sheet, the tool could neither locate nor correct the gap, and one of the two assistants tested suggested the imbalance was acceptable to present.

What is actually going on

It is tempting to file this under "the model is not good enough yet". That reading predicts the problem disappears with the next release. It has not, across several releases now, and there is a reason.

A language model produces what a number looks like at that position. Writing =B12*(1+$C$4) instead of 1,340,000 is not a harder arithmetic problem, it is a different kind of problem: it requires holding the dependency graph of the model in mind and committing to a relationship rather than to a value. Values are local. Relationships are global, and they have to stay true for every future state of the model, including states nobody has described.

Which is why the failure shows up more on harder tasks, not less, and why it shows up across vendors rather than at one of them.

The claim that holds, and the one that does not. It is not true that AI cannot do arithmetic. Agents delegate calculation to tools routinely and get the right answer. Anyone arguing "the AI can't count" is making a claim that is easy to disprove and that discredits the real point. The real point is narrower: an agent does not reliably build and maintain the structure that connects the calculations, and does not reliably keep it intact when the model is edited later.

Confusing the two weakens the case. Keep them apart.

Seven things that work

Ordered by return on effort. The first three catch most of it.

1. Run the perturbation test, do not re-read the file

This is the highest-yield check in the list and it takes ninety seconds.

Change one driver by 10%. Growth, headcount, price, whichever one should ripple furthest. Then read the outputs.

Anything that does not move and should have is a hardcode.
Anything that moves absurdly is a broken link.
Anything that moves by exactly the amount you changed and nothing else is a suspiciously shallow dependency.

Then undo it. This finds in a minute and a half what an hour of cell-by-cell reading misses, because you are testing behaviour rather than inspecting appearance.

Do it a second time with a different driver. Hardcodes cluster in the lines that nobody thinks of as drivers: working capital days, tax, other operating expenses, anything below EBITDA.

2. Make the assumptions block the only legal home for a constant

State this as a rule before generation, not as a correction after it.

Every number that is not derived from another number must live in the assumptions block and be referenced from there. No literal values anywhere else in the workbook. If you need a constant that is not in the assumptions block, add it there first and tell me you added it.

The last clause is the one that earns its place. Without it, the agent invents a constant, uses it, and does not mention it. With it, you get a list of what it needed that you had not specified, which is often more informative than the model.

3. Ask for the dependency before you ask for the number

Have the agent write the structure first, in prose or as a list, and confirm it before a single cell exists. What drives revenue. What drives each cost line. What the balance sheet ties to. Where cash comes from.

Reviewing ten lines of stated dependencies is cheap. Reverse-engineering them from four hundred populated cells is what costs you the afternoon. And an agent that has committed to a dependency in writing hardcodes noticeably less when it comes to implement it.

4. Run it twice and diff

Given that identical prompts do not reliably produce identical models, generate twice and compare. Cells that differ between the two runs are, by definition, cells where the agent had no principled reason for its choice. That is exactly the population you want to inspect, and it is usually short.

This is also the cheapest way to find out whether your prompt is underspecified. A well-specified structure produces two near-identical models. A vague one produces two different ones.

5. Never let it fix an imbalance

When the balance sheet does not tie, do not ask the agent to make it tie. It will find a way, and the way is a plug.

Ask it instead to locate the difference: which statement, which line, which period. If it cannot, that is information. A tool that cannot tell you where the gap is cannot be trusted to close it, and closing it invisibly is worse than leaving it open, because an open imbalance is at least an alarm.

6. Do a constants sweep before the file leaves

Before anything is sent, list every cell in the workbook that contains a literal number and is not in the assumptions block. In Excel, Go To Special then Constants over the numeric range gets you most of the way in a few seconds.

Every hit is either a legitimate input in the wrong place, or a hardcode. There is no third category. This is the check to run on a model you inherited, including one you inherited from yourself three weeks ago.

7. Keep the structure out of the generation step

The six checks above are hygiene. They reduce the rate. They do not change the underlying condition, which is that the structure is re-derived every time the model is touched.

The structural version of the fix is to hold the dependency graph somewhere that is not regenerated: a definition the agent reads and edits, rather than a workbook it rewrites. When the structure is an object rather than an output, a hardcode is not a thing that can be silently introduced, because there is no step in which the relationship is re-invented.

What does not work

Waiting for the next model. The failure has persisted across model generations and across vendors, and it tracks task difficulty rather than model quality. Planning around its disappearance is planning around an assumption nobody has evidence for.

Prompting harder. "Use formulas, not values" helps at the margin and stops helping quickly, particularly on the lines furthest from the ones you described. It is worth saying, it is not worth relying on.

Native spreadsheet access. Native access is not native competence. Putting the agent inside the file does not give it the structure of the file: the relationships still have to be written, cell by cell, and nothing in the grid holds them once they are.

What to do with an AI-built model you already have

If you are holding one right now and it is going somewhere that matters, three passes, in this order:

Constants sweep. Every literal outside the assumptions block. Ten minutes.
Perturbation, twice. Two different drivers, 10% each. Three minutes.
Trace the three numbers that carry the conclusion. The valuation, the covenant line, the funding need. Follow each back to a named assumption. If the trail ends in a cell with no story behind it, you have found the thing you cannot defend in the meeting.

That is under twenty minutes and it catches the class of error that survives everything else. It is also the sequence I would run on a model built by a junior analyst, which is the point: the review is not different in kind, it is different in that nothing tells you where to aim. I wrote about why that undirected review is the real cost separately.

Where Layerz sits in this

Layerz holds a financial model as a structure separate from its data. The dependency graph, meaning what drives what, is a stored object. The values sit on top of it.

The practical consequence for this specific failure: an assumption is a node, not a cell. Changing it propagates by construction, because the relationship is what is stored and the value is what is computed. There is no generation step in which a relationship can be quietly replaced by the number it produced today. Claude drives the model from outside over MCP, so it edits the structure rather than rewriting a grid, and the change is recorded as a change.

The Excel export is a clean, standard workbook with live formulas, because a model that cannot be opened and challenged by the other side has not been delivered. That export is never paywalled, and your own model exports without a watermark.

None of which removes the review. The 63 senior modellers who said they would not trust an AI-produced model without human review were right, and they will still be right. What changes is that the review has somewhere to aim.

Further reading: Why Not Just Build It Yourself With AI? · AI Financial Model Generator: What These Tools Actually Produce · Can You Trust an AI-Generated Financial Model? What 63 Expert Modellers Say · The Verification Tax · How to Build a Financial Model with AI That Doesn't Drift · LLM Reliability for Financial Calculations: Statistics

Layerz keeps a financial model as structure separate from data, so an assumption is a node rather than a cell. Excel export is clean, standard, and never paywalled. Explore Layerz →

Persistent Memory for a Financial Model: The Six Things That Must Survive a New Session

anthomakr — Thu, 06 Aug 2026 13:53:41 +0000

The second session is always worse than the first.

The first one goes well. You explain the model, the agent picks it up, you get real work done. Two days later you open a new session and you are back at the beginning: re-explaining what the model is for, which line is a driver and which is an output, why costs are positive, why that one warehouse is excluded from the ramp.

The usual diagnosis is that the AI has no memory. That is roughly true and completely unhelpful, because most memory features solve a different problem. They remember the conversation. What you need is for the model to be readable when the conversation starts.

Those are not the same object, and the difference is why "turn on memory" rarely fixes this.

Why chat memory is the wrong primitive

A conversation is a lossy recording of work. Memory features compress it further, into something like a summary of what was discussed. Summaries of a financial model are exactly where the damage happens: "revenue is driven by headcount" is a sentence that survives compression, and it is not a formula.

A model is a different kind of object. It has a shape, and the shape is either exactly right or it is wrong. There is no useful approximation of a dependency graph.

So the question is not "how do I make the assistant remember more." It is "what has to exist outside the conversation so the next session does not need to remember anything."

That list is short, and it is testable.

1. What the model is for

The first thing an agent needs is not a number. It is the deliverable.

An agent building a lender-facing budget under covenants behaves differently from one filling in a template: it stays conservative, it flags anything that moves headroom, it does not quietly improve your assumptions. Without that framing it defaults to generic competence, which is the wrong register for most finance work.

This is one paragraph. What the model produces, for whom, by when.

Failure mode: the agent optimises for elegance instead of defensibility. It simplifies a structure your bank specifically asked for.

Test: open a fresh session and ask what this model is for. If you have to answer, it does not persist.

2. The conventions

Every number in the model is read through a set of conventions, and almost none of them are visible in the numbers themselves.

Units and sign first, because they change what a figure means: 1 200 is €1.2 million or €1,200 depending on a decision nobody wrote down. Then the working language, the closing calendar, and the terms your company redefined. Most finance teams have at least one term that means something non-standard internally, and it is usually a term the agent thinks it already knows. "Marge brute" that stops at purchases and excludes logistics is not gross profit, and an agent that assumes otherwise will produce a coherent, wrong answer.

This is what FINANCE.md exists for: one versioned file, read at session start, that says how to read the numbers before anyone touches them.

Failure mode: silent unit errors. The worst class of error, because the output looks right.

Test: ask what a value of 1 200 means in this model. A correct answer without your help means the conventions persist.

3. The structure

This is the part people underestimate, and it is the expensive one.

The structure is which items exist, what type each one is (an input you can change, a computed line you cannot, a balance that accumulates), and what depends on what. It is the difference between a model and a grid of numbers that happen to be arranged in a familiar way.

An agent reading a spreadsheet does not receive this. It receives cells, and it infers. Inference on a well-built model is often right, which is precisely what makes it dangerous: you stop checking. Then it meets a row that breaks the pattern for a good reason, treats the exception as an error, and helpfully fixes it.

The real failure here is not amnesia. It is confident reconstruction: the agent rebuilds a plausible structure from what it can see, gets most of it right, and is wrong in the places that took you longest to get right.

Related, but a different question: why spreadsheet access alone is not enough for an agent covers what structure buys you during a session. This is about what has to be there before it starts.

Failure mode: an edit that computes correctly and breaks a link you needed.

Test: ask what feeds gross margin, and what would change if you moved one assumption. An agent that answers from the model rather than from pattern matching has the structure.

4. The grain

Monthly, quarterly, yearly, or a single constant. Where the model changes grain, and how the periods line up.

Grain sounds like a detail until an agent projects a yearly assumption across twelve months by dividing, when your model ramps it. Or annualises a partial period without saying so. Both produce numbers that pass a sanity check and fail a review.

Failure mode: a plausible number in the wrong period. Hard to spot, easy to present.

Test: ask over which periods a given assumption applies, and what happens in the first partial year.

5. The values, kept separate from the structure

A model has logic, and it has the numbers currently loaded into that logic. If those two are the same object, every scenario is a copy of the whole thing, and the copies drift.

Keeping them separate is what makes "run this with a 3% ramp instead of 5%" a change to one input rather than a new file. It is also what makes a model reusable next quarter, when the structure still holds and every value has moved.

Failure mode: version proliferation. Six files, none of them clearly the reference, and the differences between them are undocumented.

Test: change one assumption and see whether you produced a variant or a new file.

6. The history

What changed, when, and why.

The first two are mechanical and most tools give you something. The third is the one that matters and the one that is almost never captured: an assumption that moved because the sponsor asked for it in a call is a different object from one that moved because someone was testing. Six weeks later they look identical.

History is also what makes an AI-assisted model defensible rather than merely fast. When a board asks where a number comes from, "the model was built with AI" is not an answer. A traceable chain from output to assumption, with the reason attached, is.

Failure mode: you can see that something changed, and you cannot reconstruct whether it was a decision.

Test: ask what changed since last month and why. The "why" is the part that tells you whether history persists or only diffs do.

When none of this is worth it

Most of the time, honestly.

For a one-off analysis you finish in a single sitting, a chat window and a spreadsheet are the right tools, and any of this would be overhead. Same for exploration: when you do not yet know what you are building, structure is a cost with no return, and you should not pay it before the shape settles.

This list starts paying when a model gets touched again. By you next month, by a colleague, by an agent in a session you are not watching. The cost of reconstruction is roughly linear in how often that happens, and most finance models get touched far more often than the person who built them expected.

The other honest case against: if your model genuinely lives in one person's head and always will, the constraint is not tooling. Writing the six items down would help that person more than any AI setup, and it would help them whether or not an agent ever reads it.

The short version

Persistence is not a feature you switch on. It is six specific things existing outside the conversation:

	What it answers	The failure when it is missing
Objective	What is this for	Elegant instead of defensible
Conventions	How to read a number	Silent unit and definition errors
Structure	What depends on what	Confident reconstruction
Grain	Over which periods	Right number, wrong period
Values	What is loaded right now	Version proliferation
History	What changed and why	Cannot tell a decision from a test

Open a new session and ask three questions with no context: what is this model for, what feeds gross margin, and what changed last. If the answers come from the model rather than from you, it persists. If you find yourself re-explaining, you have located exactly which of the six is missing.

That is a more useful diagnosis than "the AI forgot."

Further reading: Why Finance Agents Need a Model Layer · FINANCE.md: An Open Standard for Financial Modeling Conventions · How to Save Tokens When Building Financial Models with AI

Layerz keeps a financial model as structure separate from data, with its conventions in a FINANCE.md and every change versioned with its reason. An agent reads all six at session start instead of reconstructing them. Excel export is clean, standard, and never paywalled. Explore Layerz →

Your Client's Contract Says No AI. What You Can Still Do.

anthomakr — Thu, 30 Jul 2026 19:05:48 +0000

There is a pattern showing up in financial modeling that nobody predicted two years ago: experienced practitioners are using less AI than they were, not more.

Not because the tools got worse. Because the contracts changed. Engagement letters and NDAs increasingly carry a clause prohibiting confidential information from being entered into a generative AI system, and the practitioner who signed it now has a spreadsheet in one window, a chat interface in the other, and a rule against connecting them. The workaround is deliberately vague prompting: debug this formula, explain this accounting treatment, never a real number.

That is a real constraint and it deserves a real answer, not a reassurance. This article is about what those clauses actually prohibit, what actually happens to data you send to a model provider, and which workflows stay inside the line. Sources are linked throughout, because on this topic a confident claim without a citation is worth nothing.

First: read the clause. Three different prohibitions get called "no AI"

Practitioners tend to collapse three very different restrictions into one blanket "we can't use AI." They have different scopes and different remedies.

1. No training on our data. The most common formulation. It prohibits your data being used to improve a model, not the act of inference itself. This one is often already satisfied by the commercial terms of the provider you were going to use anyway.

2. No consumer-grade or publicly available tools. The second most common. Typical drafting: the recipient shall not input confidential information into any publicly-available or consumer-grade generative artificial intelligence or large language model. This restricts the tier, not the technology. A commercial API account under a data processing agreement is a different object from a personal Pro subscription, and the clause frequently says so.

3. No processing by any third party. The broadest. This one genuinely rules out any hosted model, and the only remaining paths are a local model or no model at all.

The distinction matters because the three clauses have different answers, and because the middle one is the most common while also being the one most often read as if it were the third. Before changing how you work, get the actual sentence in front of you and identify which of the three you are dealing with. If it is ambiguous, that ambiguity is a question for the client, not something to resolve by assuming the strictest reading.

Second: know what actually happens to the data

Most of the fear in this area is calibrated to a 2023 understanding of how these services worked. The terms have changed, they are public, and they are specific. What follows is what the providers themselves document, with the nuances that get lost in summary.

On the commercial tier, your data is not training the model. Anthropic's developer documentation states that retained data "is never used for model training without your express permission," and that inputs and outputs on the commercial API are deleted within 30 days by default (Anthropic, API and data retention). OpenAI documents that since 1 March 2023, data sent to its API "is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)," with abuse-monitoring logs retained up to 30 days (OpenAI, Data controls).

The consumer tier is a genuinely different product, and this is the one your clause is about. Under the consumer terms announced in August 2025, users on Claude Free, Pro and Max choose whether their chats are used to improve the model, with retention of five years if they allow it against the standard 30 days if they do not. That update explicitly does not apply to services under Anthropic's Commercial Terms, including API use (Anthropic, 2025). If you are working from a personal Pro subscription, you are on the tier the clause was drafted to catch. That is worth sitting with, because it is the single most common gap between what practitioners believe about their setup and what is true.

Zero data retention exists, and it is narrower than the name suggests. Under a ZDR arrangement, prompts and responses are not stored at rest after the response is returned. But the documentation lists what the arrangement does not cover: consumer plans, the Claude Teams and Enterprise product interfaces, Console and Workbench, Claude for Excel, Managed Agents, third-party integrations, and the models designated Covered Models, which require 30-day retention. A separate eligibility table puts further features outside it, among them code execution, the Files API, batch processing, the MCP connector and Agent Skills. The trap is that using one of those does not fail loudly: nothing blocks the request, and the documentation is explicit that using an ineligible feature "is a choice to step outside your ZDR arrangement for that specific data." ZDR is enabled per organization and arranged through sales, not toggled in settings (Anthropic, API and data retention).

Nothing is absolute. Anthropic documents that even with a ZDR or HIPAA arrangement, content flagged by automated trust and safety systems may be retained for up to two years. Any claim that data "never touches their servers" is false for every hosted model, and you should distrust any vendor who tells you otherwise.

The honest summary: on a commercial tier with a DPA, your data is processed, retained briefly, not trained on, and subject to documented exceptions. That is a materially different risk profile from a consumer subscription, and it is checkable rather than assumed.

Third: the obligation may exist even if the contract is silent

For US CPAs there is a second layer that does not depend on what the client's contract says.

The AICPA Confidential Client Information Rule (1.700.001) provides that a member in public practice shall not disclose confidential client information without the client's specific consent. Interpretation 1.700.040 addresses what happens when a third-party service provider is involved: before disclosing confidential client information to that provider, the member should either enter into a contractual agreement with the provider to maintain confidentiality and give reasonable assurance of appropriate procedures, or obtain specific consent from the client (Blatch, Journal of Accountancy, 2015 · Journal of Accountancy, 2024). The Code's word is "should", not "must", and the interpretation predates generative AI: it does not name it, which is precisely why it applies to it.

A hosted model provider is a third-party service provider on any plain reading, and the rule gives you two doors rather than one. The contractual door is a DPA with a commercial provider. The consent door is a conversation with your client. Neither of them is "stop using AI."

Silence in the engagement letter is not permission, and it is not prohibition either. It is an unanswered question, and the profession's own rule tells you how to answer it.

The four workflows that stay inside the line

Ranked from the most restrictive constraint to the least.

1. Never send client numbers at all: build the structure, populate offline

This is the one most people miss, and it is the one that works even under the broadest clause.

A financial model is two things stacked together: a structure (the logic, the formula relationships, the timeline, the ordering of a debt waterfall, the shape of a three-statement build) and data (this client's actuals, this deal's assumptions). Confidentiality attaches to the data. It does not attach to the fact that interest expense is a function of average debt balance.

So you can do the expensive part with AI on a structure that contains no client information, using placeholder or synthetic figures, then populate the real numbers in a separate step that no model ever sees. The AI does the work you actually wanted help with, which is the architecture and the formula logic, and the confidential figures never leave your environment.

This is not a trick and it does not need a vendor. You can do it with a blank workbook. It does require a tool where structure and data are genuinely separable, because in a normal spreadsheet the logic and the numbers live in the same cells and there is no clean line to cut along.

2. Move to a commercial tier and paper it

If the clause targets consumer-grade tools, the remedy is to stop using a consumer tool. A commercial API account or an enterprise agreement with a DPA, plus ZDR if your use case qualifies for it, addresses the substance of most clauses in this family, and it happens to be exactly the contractual-agreement limb of AICPA 1.700.040.

Read the exclusion list before you rely on it. If your workflow depends on file uploads, code execution or a hosted connector, check whether those specific features are inside your arrangement.

3. Ask for consent, specifically

The most underused path. Practitioners assume the answer is no and never ask.

A specific request works better than a general one: name the tool, name the tier, name what data would be sent, name the retention and training terms, and offer the alternative. Clients who would refuse "can I use AI on your file" quite often approve "I would use a commercial account under a data processing agreement with no training on your data and 30-day retention, for the model structure only." You have also just created a written record, which is the thing your professional obligation actually wants.

4. Run a local model

If the clause prohibits any third-party processing, a model running on your own hardware is the only remaining option that keeps AI in the workflow. The trade is real: local open-weight models are meaningfully behind frontier models on multi-step numerical reasoning, and financial reasoning is one of the areas where the gap shows. For structural work, boilerplate and formula debugging on a straightforward build, they are usable today. For a complex model, they are not a substitute.

Most practitioners in finance do not know this is even possible. It is worth two hours of your time to find out where the ceiling is for your own work, rather than assuming it either solves everything or nothing.

What not to do: the quiet regression

The most common response to a restrictive clause is none of the four above. It is to keep using the same consumer tool, and simply be vaguer about it. Paste less. Describe the problem in general terms. Rename the client.

This is the worst available option, and it is worth naming clearly.

It does not actually achieve compliance, because "less confidential information" is not "no confidential information," and a pasted formula from a live client model with the numbers changed is still derived from confidential material. It removes the audit trail, because the work is now happening in a chat window nobody can reconstruct. And it degrades your output, because you have deprived the model of the context it needed while keeping every risk that mattered.

It also has a measurable cousin. In one analysis of 22.4 million enterprise AI prompts and uploads, financial data (projections, investment analysis, sales pipeline) was the single largest category of sensitive information detected, at 16.6% of all exposures (Harmonic Security, 2025, vendor telemetry rather than a representative panel). The vagueness strategy is how most of that happens: not deliberate exfiltration, just practitioners who believed they were being careful enough.

Pick a real path. An informal one is not a path.

Where a model layer helps, and where it does not

Full disclosure of the obvious: we build Layerz, a workspace that holds a financial model as structure separate from data, which Claude drives from the outside through MCP. So take the following with the appropriate suspicion, and note what it does not claim.

It does not make you compliant. If you point an AI at a model that contains your client's real numbers, those numbers go to the model provider exactly as they would from any other tool, and no architecture changes that. Anyone telling you otherwise is selling you something.

What separating structure from data does change is that workflow #1 above stops being a discipline you have to maintain by hand and becomes the default shape of the work. The logic, the dependencies and the timeline are one object. The values are another. You can hand the first to an AI and keep the second out of scope, then export a clean Excel file and populate it where the confidentiality obligation lives. That is a narrow claim, and it is the only one worth making.

The related question of whether the tool itself introduces new exposure, through dynamic code execution on files you did not author, is a different problem covered in AI and Confidential Financial Data: What Actually Happens to Your Numbers.

The checklist

On the contract:

Get the actual clause in front of you. Which of the three prohibitions is it?
If it is ambiguous, it is a client question, not an assumption.

On your setup:

Which tier are you on? Consumer subscription or commercial account with a DPA?
If you rely on ZDR, have you checked your specific features against the exclusion list?
Would you be able to describe your data flow to the client in three sentences? If not, you do not yet know what it is.

On the work:

Which parts of this engagement need real numbers, and which are structural?
Can the structural part be done on a model that contains no client data?
Is there a record of what the AI touched, or only a chat history?

The bottom line

A clause prohibiting confidential data in a generative AI system is not a prohibition on using AI. It is a constraint on which data, on which tier, and with whose consent. Practitioners who read it as a total ban give up most of the value while frequently retaining the actual exposure, because the vagueness workaround is not compliance.

The most durable answer is also the least technological: keep the confidential figures out of the part of the work you delegate. That was good practice before any of this existed. The tooling question is only whether your tools let you draw the line cleanly, or force you to hold it in your head.

The Finance Engineer Job Description Is a Spec for Infrastructure Nobody Has Built

anthomakr — Mon, 27 Jul 2026 09:21:39 +0000

VulnCheck, a security company in Boston, is hiring a Finance Engineer. The posting asks the hire to connect the GL, billing, CRM and spend management systems "via API/MCP." To build Claude-powered workflows that draft variance commentary and flag anomalies. And to own the financial model's technical architecture, "including version control and forecast logic."

Read that last one again. Version control. For a financial model. Owned by someone whose team is listed as Finance.

That is not really a job description. It is a systems requirement, written by a company that needed a capability, found no product that provides it, and hired a person instead.

We went looking to see whether this was one unusual posting or a pattern. It is a pattern, and the pattern says something uncomfortable about the tooling underneath.

What the postings actually say

So we counted. In July 2026 we queried the public job board APIs of 1,061 candidate employers across the US and Europe, scanned all 27,278 open postings on the 421 live boards that answered, filtered on the department each employer assigns to the posting itself, and coded every survivor from full text. That produced 37 qualifying requisitions across 26 employers, published with the full method, the adjudication rules and the corpus in The Finance Engineer Role: Job Posting Statistics. Three findings matter here.

Nobody agrees what to call it. Thirty-seven requisitions, thirty-seven distinct titles. No two employers word it the same way, and exactly one calls the job plainly "Finance Engineer." The rest are Agentic Finance Engineer, Tech Lead for Finance & Supply Chain Engineering, Head of Engineering for Finance Systems, Finance System Architect Manager, Order to Cash Track Lead for Finance Engineering, and so on. Sixteen of the thirty-seven carry no finance word in the title at all: Brex's "Data Engineer," OpenAI's "Workday Engineer," Attentive's "Anaplan Application Developer," ElevenLabs' "Systems Architect," each sitting inside a finance or accounting department. A title search cannot find this population, which is the first thing anyone counting it should know.

It is also rare. Of the 987 open finance-department roles across those 421 employers, 26 were engineering roles. That is 2.6%, or one in thirty-eight. This is not yet a wave. It is a small number of companies making a specific and expensive bet.

And they are making it alone. The obvious alternative is to let a vendor deploy an engineer instead, which is exactly what the forward deployed engineer boom is for. On the same boards there are 348 open FDE postings across 66 employers. Precisely one requisition is finance-facing. Widen it to every deployment-shaped role, solutions architects and implementation engineers included, and you get 545 requisitions of which 14 touch finance, nearly all of them presales attached to a platform sale. Nobody is coming to build this for you.

And it is not only an American story. A dedicated European pass over 91 additional employer boards found the role in Germany, the UK, Spain, Sweden and Poland: Helsing hiring a Finance Data Engineer in Munich, Zilch a finance analytics engineer in the UK, Celonis a Finance Systems Engineer in Madrid, Lovable a Financial Systems Engineer in Stockholm. Europe runs at 1.9% of finance-department openings against 2.6% in the US, so the gap is real but narrow. What Europe does not have is the vocabulary: not one European posting calls the job a finance engineer.

It mostly, but not always, sits in Finance. Twenty-six of the thirty-seven are placed by their employer in a Finance, Accounting or Finance Systems department: Anthropic, OpenAI, Coinbase, Databricks, Brex, Stripe, Twilio, Attentive, Cloudflare, SoFi, Mercor, Affirm, VulnCheck. Where a reporting line is spelled out, it names a finance leader: VP of FP&A, Head of Finance Systems, Senior Manager of Finance Data and AI.

The eleven exceptions complicate the tidy version of this story. Klaviyo runs an entire "Finance Engineering" function out of IT & Security. Block puts a Senior Finance Systems Engineer in Engineering, CoreWeave and Epirus theirs in IT, Harvey in Product, Whoop in Business Intelligence. So the direction of travel is real, and finance is staffing its own systems rather than filing tickets for them. But roughly one role in three is still owned outside finance, and anyone claiming the shift is universal has not counted.

It wants two careers in one person. Spring Health's Senior Finance Engineer posting asks for "4+ years designing and deploying automation, AI, and/or ML systems in Finance" and, separately and additively, "4+ years in FP&A, Strategic Finance, Accounting, or Finance Transformation." Its named tool list runs NetSuite, Pigment, Airbase, Claude, ChatGPT, Gemini. Commercial LLMs, listed by name, in the requirements section of a finance role.

The tell is in what these postings assume already exists

Strip the postings down to their verbs and a shopping list appears. Across the corpus, employers casually assume the following are available to a finance team:

Version control over a financial model. Not over a file. Over the model: what changed, when, by whom, and what it moved downstream.
An API surface over financial logic, not just over financial data. Model Context Protocol is now named by protocol in four postings across three employers, all inside finance departments: VulnCheck, ElevenLabs, and both of OpenAI's Enterprise AI Platform roles. An agent interoperability standard released in late 2024 has become a line item in corporate finance hiring.
Conventions that persist between sessions and between people. When the posting says "assemble reporting packages," it assumes the definition of ARR used in October is the definition used in March.
An audit path from an output number back to the assumption that moved it. Every posting mentioning close, variance commentary or ASC compliance assumes this implicitly.

Every one of those four is unremarkable in software engineering. Git, APIs, schemas, commit history: solved decades ago. None of the four is standard in finance. And the reason is not that finance teams are less sophisticated. It is the substrate.

It is also expensive, and the shape of the expense is the tell. Seventeen postings disclose a US base range, spanning $112,000 to $385,000, with a median band midpoint of $231,500.

The sharper number comes from OpenAI, which publishes structured bands on every role and has enough openings to compare like with like. Its five finance-department engineering roles carry a median band midpoint of $307,500. The other forty-five roles in the same finance department: $228,000. Its two hundred and ninety-seven product engineering roles: $309,000.

So a finance-department engineer there is paid 35% above the rest of the finance organization, and within half a percent of a product engineer. The premium is not for finance expertise, and it is not a cost-centre discount. These companies are paying full engineering rates for engineering work that happens to sit in finance, which is what you do when you have concluded the capability has to exist and no vendor sells it to you.

The spreadsheet is an excellent calculator and a poor substrate

This is worth saying plainly, because the anti-Excel genre is tiresome and mostly wrong.

Excel is extraordinary at what it does. It is the lingua franca of finance, readable by anyone in the building without training, the format your investor and your auditor and your acquirer all accept, and the fastest way in the world to answer a question with numbers. Nothing here argues for replacing it as the deliverable. It is not going anywhere and it should not.

But a spreadsheet has properties that make it a bad foundation for the four requirements above:

A file copy is not a version. Model_v4_FINAL_rev2_JD.xlsx records that something changed. It does not record what, or why, or what it broke.
The API is over cells, not over logic. You can read D14. You cannot ask what D14 means, what feeds it, or whether it is an input or an output. That distinction does not exist in the file format.
Intent does not persist. The reason a growth rate is 12% lives in the modeler's head, or in a comment, or nowhere.
There are no types. 0.12 might be a tax rate, a margin, a churn assumption or a rounding artifact. A human infers it from context. An agent guesses.

So when a company writes "own version control and forecast logic for the financial model," the honest answer available to a finance engineer today is a stack of workarounds: a naming convention, a folder of .xlsx files in a git repo that nobody can meaningfully diff, and a page of documented conventions that goes stale within a quarter. It works right up until someone changes an assumption and half the links quietly stop following.

That is the gap the job postings are papering over with a hire.

"We will ask for examples"

There is a second thing happening in these postings, and it is the part most likely to change how the role is filled.

Finance hiring ran on credentials for a long time, and for a defensible reason: the work was invisible. It lived inside someone else's ERP, under an NDA, in a file you could not take with you. There was nothing to show, so people showed a CPA, an MBA, a bank on the résumé.

The postings in this corpus are not asking for that. They are asking what you built. The automation you shipped, the close you cut from seven days to two, the agent workflow your team actually uses. That shift only works if the work is showable.

Here is the problem: most finance work still is not showable. A spreadsheet is something you attach, not something you show. It carries your employer's real numbers, it takes forty minutes to explain, and its structure is inseparable from its data, so you cannot share the thinking without also sharing the confidential inputs.

A model whose structure is separable from its data is a different artifact. The logic, the dependency graph, the conventions, the timeline: shareable, forkable, reviewable, and provably yours, with nobody's actuals inside it. That is a portfolio piece. It is also, not coincidentally, the same property that makes version control and API access possible in the first place.

What a substrate for this role would need

If you are stepping into one of these roles, or writing one of these job descriptions, the underlying question is what you build on. The requirements are consistent enough now to name:

Structure separated from data, so the logic can be versioned, reviewed and reused without dragging the numbers along.
A dependency graph that is explicit, so a change to an assumption produces a knowable set of downstream effects rather than a surprise.
Conventions written down in a form the tooling reads, not just the humans. This is what FINANCE.md is for: currency, units, sign convention, what your organization means by ARR, carried with the model instead of in someone's memory.
An agent-addressable interface, because the postings already assume the LLM is in the loop. If your agent has to re-read the entire model to change one number, you will pay for it in tokens and in drift.
Excel on the way out, always. The deliverable is still .xlsx. A substrate that traps you is worse than the spreadsheet it replaced.

Layerz is built for exactly this shape: structured models an agent drives over MCP, with the structure versioned separately from the data, and clean Excel export that is never paywalled. It is worth being clear about what it does not do. It is not an ERP and will not run your close. It does not replace NetSuite, Workday or your billing system, which are the systems most of these postings spend their time integrating. And if your work is genuinely one-shot analysis, a spreadsheet and a good prompt will beat it on speed every time.

Where it earns its place is the part the postings keep describing and no spreadsheet can hold: a model that persists, that an agent can change without breaking, and that you can hand to someone else with the reasoning intact.

The bottom line

The finance engineer role is real, it reports into Finance, and it is being asked to deliver software engineering guarantees on top of a substrate that offers none of them. Right now the gap is being closed by hiring unusually capable people and letting them improvise infrastructure out of file naming conventions.

That works, for a while. It is not a foundation. The postings have already written the spec. The question is only whether the person filling the role has to build it from scratch.

Layerz is a financial modeling substrate that keeps a model's structure separate from its data, versioned, and drivable by any AI agent over MCP or REST. Finance teams use it as the layer their agents and their Excel exports both sit on top of. Explore Layerz

The corpus behind this piece is open: 37 requisitions, 26 employers, method and exclusion rules published, with the coded data on Hugging Face under CC BY 4.0. Recount it and disagree if you think we drew the line in the wrong place.

Why Finance Agents Need a Model Layer, Not Just Spreadsheet Access

anthomakr — Thu, 02 Jul 2026 13:14:25 +0000

You have built the agent. It calls a spreadsheet via API, reads the relevant cells, and produces something useful: a variance analysis, a scenario update, a summary for a board meeting. It works. Until you change the spreadsheet layout. Or until you start a new session and have to explain the model structure all over again. Or until the agent produces a number that is technically correct from the cell values it read, but violates a convention you have maintained for three years without anyone knowing to encode it.

Connecting an AI agent to a spreadsheet is a reasonable first step. It is not a model layer. And the difference turns out to matter a lot for anything you would call real financial work.

What spreadsheet access actually gives an agent

When an agent reads a spreadsheet (through an API, a plugin, or a code execution tool), it gets cells. It can read values, detect patterns in ranges, and make inferences about structure from formatting and proximity. That is more than nothing.

What it does not get:

Types. A cell with the value 0.12 could be a tax rate, a growth assumption, a margin, or a rounding artifact. The agent does not know.
Dependencies. Whether that 0.12 feeds into three downstream formulas or is an isolated value, the agent cannot see this without parsing every formula string in the file.
Timeline semantics. Which columns represent months vs. years, where the actuals end and the forecast starts, whether a value is per-period or cumulative: all inferred, none explicit.
Roles. Whether a line is an input assumption, a formula driven by other lines, an aggregation, or an output: these are categories that do not exist in spreadsheet format.
History. What the value was last week. What changed and why.

For a one-shot query ("what is the EBITDA in 2026?"), this is fine. For anything iterative (updating assumptions across scenarios, understanding why a number changed, rebuilding context across sessions), spreadsheet access is a thin foundation.

The session reset problem

The most underrated cost of running agents on spreadsheets is the context overhead on every new session.

A well-built financial model has logic that took days to develop: revenue drivers, cost structure dependencies, debt waterfall rules, EBITDA normalization conventions. An agent working on this model in session one learns all of this through your prompts and its own inference. Session two starts from scratch.

You re-explain the model structure. You re-establish the conventions. You re-orient the agent toward the right interpretation of ambiguous cells. Then you do the actual work. For anyone running regular AI-assisted financial workflows, this overhead compounds quickly.

A model layer solves this structurally. The model's structure (its variables, their types, their dependencies, their timelines) is stored and queryable. The agent reads it at the start of every session without explanation. The context is persistent, not reconstructed.

The convention problem

Financial models carry organizational conventions that are not visible in cell values.

Your EBITDA excludes IFRS 16 lease costs, a decision made three years ago for comparability reasons. Your FX rates are ECB end-of-period, not average, because an auditor asked for it once and it became the standard. Restructuring charges from 2024 are excluded from adjusted figures: that was a board decision, documented in a memo nobody can find anymore.

These conventions are real. They are defensible. They are the difference between your numbers and a competitor's numbers when a PE board asks why the EBITDA margins differ. And they exist nowhere in the spreadsheet.

An agent working on your model does not know any of this. It calculates what the cells tell it to calculate. It reports what the formulas produce. If the conventions are not encoded somewhere the agent can read, every run is a convention violation waiting to happen.

This is what FINANCE.md addresses: a structured file that encodes organizational financial conventions in a format any agent can read at session start. EBITDA definition, FX policy, restatement rules, declared once, versioned, queryable. The agent knows the rules before it touches the numbers. See the FINANCE.md open standard for the specification.

What a model layer actually provides

A model layer sits between an agent and a data store. It exposes not just values, but structure.

Typed variables. Every variable in the model has an explicit type: assumption, formula, aggregation, output. An agent knows whether it is looking at an input it can change or a derived value it should only read.

Dependency graph. The relationships between variables are explicit and traversable. An agent updating a revenue growth assumption knows which downstream variables will be affected before it makes the change.

Timeline semantics. The model's temporal structure is declared: monthly, quarterly, annual, the start and end of the forecast, where actuals end. The agent does not infer this from column headers; it reads it from the model definition.

Query interface. An agent can ask "what are the revenue drivers?" and get a structured answer, not a range of cells to interpret. It can ask "what changed since last week?" and get a diff, not a request to compare two file versions.

Convention encoding. The model layer stores not just the structure but the rules: what this organization means by EBITDA, how FX is applied, which items are normalized. These travel with the model, not with the analyst who built it.

When spreadsheet access is enough

This distinction only matters for agents doing iterative, multi-session financial work with real conventions and real stakes.

For one-shot automation ("pull these ten values from this spreadsheet and put them in this report"), spreadsheet access is entirely sufficient. The agent reads cells, formats output, done. No model layer needed.

The model layer becomes necessary when:

The agent needs to modify the model, not just read it, and modifications need to respect the model's logic
The agent operates across multiple sessions and cannot reconstruct context each time
The model's conventions need to be respected, not just its formulas
Multiple people or agents work on the same model and need consistent interpretation
The model's history matters: what changed, when, and why

For finance professionals building agent workflows around their core models (budget, deal model, unit economics), these conditions are almost always present.

The bottom line

The gap is not whether AI can work with financial data. It can. The gap is whether the infrastructure behind the agent is designed for financial logic: structured variables, typed dependencies, persistent conventions, traceable history.

Spreadsheet access is a starting point. For agents doing real financial work (iterative, multi-session, convention-bound), it is not enough. The model layer is what makes the agent's output defensible, its context persistent, and its conventions consistent with what your organization actually means by its numbers.

If you want the numbers behind this, we keep a source-backed library on AI in finance and AI financial model risk, every figure linked to its primary source.

Layerz is a financial modeling infrastructure that exposes structured model layers to AI agents via REST API and MCP. Finance professionals use it to build agent workflows where context persists across sessions, conventions are encoded and versioned, and every output is traceable. Explore Layerz.