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
financerepo, invites you. - You copy
templates/FINANCE.mdinto 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.
Top comments (0)