You can build a working AI finance department — revenue manager, spend manager, forecast manager, and reporting manager — using nothing but markdown files and Claude. No code, no API integrations, no Zapier. Each role is a single instruction file that defines what it owns, which files it reads, and where it writes output. One coordinator prompt runs all four roles in sequence, and when assumptions change, you edit one number in one file and the entire forecast rebuilds itself.
The system works because of one design rule: every role writes its output into the next role's inbox folder. The folder structure IS the workflow — no data gets pasted between chats, and every output traces back to one shared company context file. In testing with 18 months of realistic invoice data, this setup caught a duplicate invoice, surfaced $35,000 in at-risk receivables, and reranked its own risk assumptions when the growth plan changed — all without human prompting.
Last verified: 2026-07-31 · This is a how-to guide for building a multi-role AI finance system with plain text files. Pricing and feature details for Claude are current as of the verified date; Claude plans and capabilities change often.
What problem does an AI finance team solve?
The core problem is spreadsheet fragmentation. Most small businesses and agencies run their numbers across multiple chats, tabs, and spreadsheet versions — revenue in one file, expenses in another, forecasting in a third — and none of them agree. A revenue figure in the forecast doesn't match the revenue figure in the report, because each was built from a separate reading of the same data, often by a different chat session that drifted slightly from context.
The spreadsheet error problem is well-documented. A 2024 study by Pak-Lok Poon at the University of Houston-Clear Lake found that 94% of business spreadsheets used in decision-making contain errors (Poon, 2024, via Phys.org). Research compiled by Raymond Panko, the leading authority on spreadsheet errors, shows that cell error rates in spreadsheet development average around 3.2% across 547 tested spreadsheets — and that errors in operational spreadsheets lead to poor decisions that have cost companies millions (Panko, Spreadsheet Research). A 2008 critical review from the Tuck School of Business at Dartmouth concluded that "errors are prevalent in operational spreadsheets and that errors can lead to poor decisions and cost millions of dollars" (Powell, Baker & Lawson, 2008).
An AI finance team structured as role files solves this by forcing every role to read the same company context before touching any numbers. Instead of three separate chat sessions giving you three versions of the truth, all four roles share one set of assumptions, one calendar, and one business description — and their outputs chain together so the numbers always reconcile.
What do you need to build this?
You need three things: a Claude account (the free tier works, though Pro at $20/month gives you larger context windows), a folder on your computer, and your raw financial data in CSV or Excel format. No coding experience is required — everything is written in plain English.
Claude Projects, launched in June 2024, lets you create persistent workspaces with custom instructions and uploaded knowledge files. Each Project maintains its own context across conversations, so you upload your data once and Claude references it automatically in every chat (Anthropic, Claude Help Center). Pro plans support up to 20 files per Project with a 200K token knowledge base; Enterprise plans allow custom file limits (Tygart Media, 2026)).
For this build, you'll use Claude's file-based approach: you upload markdown instruction files and CSV data, then prompt Claude to act as each role. The thinking lives in the files, not in the chat — so the prompt stays short forever.
How is this different from what Anthropic shipped for enterprise finance?
In May 2026, Anthropic released ten ready-to-run finance agent templates for enterprise financial services — including a month-end closer, a general ledger reconciler, a KYC screener, and a pitch builder. These ship as plugins in Claude Cowork and Claude Code, and as cookbooks for Claude Managed Agents on the Claude Platform (Anthropic, May 5, 2026). They work across Microsoft Excel, PowerPoint, Word, and Outlook, and are aimed at large institutions like JPMorgan, Goldman Sachs, and Citi.
The approach in this guide is different. It targets small businesses and agencies — not investment banks. Instead of connecting to enterprise data feeds and compliance systems, it reads your CSV invoices and expense files. Instead of managed agent infrastructure with per-tool permissions and audit logs, it runs from a single chat prompt against a folder of markdown files. The architecture is simpler, the stakes are lower, and you can set it up in an afternoon.
Comparison: Enterprise finance agents vs. the folder-based approach
| Dimension | Anthropic enterprise templates | This folder-based approach |
|---|---|---|
| Target user | Banks, asset managers, insurers | Small businesses, agencies, freelancers |
| Setup | Plugin or Managed Agent cookbook | Folder of markdown files + one Claude prompt |
| Data source | Enterprise data feeds, ERP integrations | CSV/Excel files uploaded to Claude |
| Infrastructure | Claude Platform with managed credentials | Your local computer + Claude chat |
| Audit trail | Full audit log in Claude Console | Manual file tracking in folders |
| Cost | Enterprise pricing (custom) | Free or $20/month (Claude Pro) |
| Best for | Month-end close at scale, KYC screening, pitchbooks | Closing books, forecasting, owner reports for SMBs |
What is the folder structure for an AI finance team?
The entire system is one root folder with four role subfolders, a shared context folder, a coordinator file, and a deck builder file. Here is the structure:
finance-team/
├── shared/
│ ├── company-context.md # Who you are, what you sell, what matters
│ ├── assumptions.md # Growth targets, renewal rates, hiring plan
│ └── calendar.csv # Q1=Jan-Mar, Q2=Apr-Jun, etc.
├── revenue/
│ ├── revenue-manager.md # Instruction file (the "role")
│ ├── input/ # Raw invoice data goes here
│ └── output/ # Revenue summary written here
├── spend/
│ ├── spend-manager.md
│ ├── input/
│ └── output/
├── forecast/
│ ├── forecast-manager.md
│ ├── input/ # Other roles' outputs land here
│ └── output/
├── reporting/
│ ├── reporting-manager.md
│ ├── input/
│ └── output/
├── run-finance-team.md # Coordinator instructions
└── deck-builder.md # Turns everything into a board deck
No code anywhere. Every file is plain English markdown. The folder structure is the entire workflow — each role reads its input folder, processes data according to its rules, and writes results to both its own output folder AND the next role's input folder.
How do you write a role instruction file?
Every role file in the system has the same six parts. Here is the template, using the revenue manager as the example:
1. What the role owns
One sentence defining the role's scope. For the revenue manager: "You own all money-in analysis — recognizing revenue by invoice date, reconciling against the client roster, and flagging anomalies."
2. Which files it may read (by name)
List every file the role is allowed to touch. This prevents the AI from improvising with data it shouldn't see.
Read these files before doing any work:
- shared/company-context.md
- shared/assumptions.md
- shared/calendar.csv
- revenue/input/invoices.csv
3. Rules for treating the data
This is where the role gets serious. Rules are specific, not vague. Instead of "analyze the data," you write:
- Recognize revenue by the invoice date, not the payment date
- Cross-check every retainer invoice against the client roster in company-context.md
- If anything conflicts or looks wrong, flag it clearly — state how you handled it and never silently absorb a problem
That last rule is the one that pays off. It is the difference between a calculator that silently double-counts a duplicate invoice and an analyst that surfaces it for human review.
4. Calculations to run
Specify exactly what math the role performs. For the revenue manager:
- Total revenue by month (18-month rolling)
- Revenue split: retainer vs. project
- Month-over-month change with labeled drivers
- Any invoice appearing more than once: count once, exclude the copy, flag it
5. Output file name and location
The role must write to exact file names — not "a summary" but revenue/output/revenue-summary.csv. If the output specification says "a summary," the next role won't be able to find it and the chain stops. A chain that stops loudly beats a chain that quietly guesses and gives you confidently wrong answers.
6. Save to the next role's inbox
Every role saves its output twice: once to its own output folder and once to the input folder of the next role in the chain. The revenue summary lands in forecast/input/revenue-summary.csv. The spend summary lands in both forecast/input/ and reporting/input/. No files are copied between chats. The folder IS the workflow.
How do you run a single role?
The prompt to run any role is one line:
"Act as the revenue manager. Follow the instructions in revenue/revenue-manager.md exactly."
That is the entire prompt, and it stays that short forever because the thinking lives in the file, not in the chat. When Claude runs this role against 18 months of invoice data, it returns:
- 18 months reconciled, with total revenue booked
- Revenue split (e.g., 83% retainer, 17% project)
- Low and high points with named drivers (which client, which month, why)
- Any duplicate invoices caught and excluded
- Aging analysis of unpaid invoices flagged as at-risk
None of which you asked for explicitly — the role file simply says "never absorb a problem silently," so the AI surfaces everything it finds.
How do the four roles chain together?
The four roles run in a fixed order, and each one waits for the previous role's output files to exist before it starts:
Step 1: Revenue Manager Reads raw invoices + shared context. Outputs a reconciled revenue summary with flags (duplicate invoices, unpaid receivables, at-risk accounts).
Step 2: Spend Manager Reads raw expense data + shared context. Outputs a spend summary. The spend manager can explain rather than just flag — for example, if payroll steps up $7,000/month in January, it reads the hiring plan in the assumptions file and explains the increase instead of marking it as suspicious.
Step 3: Forecast Manager This role never touches raw data. Its inputs are the revenue summary, the spend summary, and the assumptions file. It projects the next 12 months and names the single assumption the entire plan depends on (e.g., keeping two premium clients — lose one and $114,000 of projected profit disappears).
Step 4: Reporting Manager Runs last. It reads all upstream outputs and writes the owner's report in plain English. Every number traces to an upstream file. The duplicate invoice caught in step 1 becomes recommendation number five on the owner's desk as a process problem to fix. No flag gets lost because every role is required to carry flags forward to the end.
What is the coordinator and how does it run everything at once?
The coordinator is one more markdown file — run-finance-team.md — that contains mostly prohibitions rather than instructions:
- Run the four roles in this exact order: revenue, spend, forecast, reporting
- Do not start a role until the previous role's output files exist
- Do not second-guess a role's logic — the instruction files ARE the logic
- Carry every flag from every role to the very end
The prompt to run the entire department is:
"Act as the finance team coordinator. Follow the instructions in run-finance-team.md and run the full team end to end."
A few minutes later, you get: revenue reconciled, spend analyzed, 12-month forecast built, owner's report written, and every flag from every role gathered into one list — duplicates, at-risk receivables, concentration risks, contractor cost floors, and judgment calls the coordinator made on its own and documented transparently.
What happens when you change one assumption?
This is where the folder structure pays off. Instead of rebuilding a spreadsheet, you edit one line in shared/assumptions.md — say, from "one new client per quarter" to "two new clients per quarter" — and then run:
"Assumptions have changed. Re-run the forecast manager and the reporting manager so the forecast and report reflect the new assumptions."
The system goes back to the assumptions file itself rather than trusting anything downstream. It confirms the only change is the signing pace, recomputes the forecast from scratch (revenue and spend don't rerun because history didn't change, only the plan changed), and rebuilds the report. The 12-month revenue projection jumps, projected profit more than doubles, the margin goes up — and the report changes its mind about the biggest risk. Before, the most sensitive assumption was keeping two premium clients. After the change, the most sensitive assumption becomes the signing pace itself, and the system adds a watch item noting that two-per-quarter is ambitious against a historical average of one.
Changing one number didn't just update the math. It reranked the risks. That is the difference between a chat that answers questions and a system that maintains a position.
How do you verify the numbers are correct?
Before trusting any output, run a trace test. The principle is simple: a confidently wrong number is worse than no number at all.
- Open the owner's report. Pick a month — say, June, with $66,000 in revenue.
- Open the revenue summary CSV. Same month, same number: $66,000.
- Open the raw invoice file. Filter to June. Count the invoices: 11 line items (10 retainers, 1 project). Sum them: $66,000.
If every number in the system survives that three-click walk from summary to raw rows, the system is working. This is the test to run before believing any output.
How do you turn the output into a board deck?
The last file in the folder — deck-builder.md — follows the same pattern. One prompt turns everything the roles produced into a presentation. Its rule is the strictest in the system: every number on a slide must already exist in an upstream file. The deck builder presents and never calculates. It also self-QAs: it caught a chart that was silently dropping a data series due to CSV line ending formatting, fixed the parser, rerendered, and checked again. The file says the deck must be presentation-ready, so it does its own quality pass.
What makes this approach fail?
Every failure mode is a management problem, not an AI problem. Here are the four ways this system falls apart:
1. Vague instruction files. If a file says "analyze the data," the role improvises and every run gives you a different department. The instruction files must be boringly specific — exact file names, exact columns, exact calculations, exact output paths.
2. Overlapping roles. If two roles both own revenue, they will eventually disagree and you'll have two versions of the truth — the exact disease this system was built to cure. Each role owns one category and nothing else.
3. No shared calendar. If one role's Q3 is calendar Q3 and another role's Q3 is fiscal Q3, everything reconciles internally and nothing matches reality. One CSV calendar file prevents this.
4. Missing file names in the output spec. If the output specification says "a summary" instead of the exact file name, the next role can't find it and the chain stops. That is the correct behavior — a chain that stops loudly beats a chain that quietly guesses. Make file names explicit.
The lesson: Claude is not the hard part. The hard part is writing down what each role actually owns, what it may read, and where it must write. It always was — whether you're using AI, spreadsheets, or accounting software. The AI just makes it possible to enforce those rules automatically.
What this means for you
If you run a small business or agency and your financial reporting lives in scattered spreadsheets, this approach lets you build a consistent, self-checking finance pipeline in an afternoon. You do not need to hire a financial analyst, buy enterprise software, or write code. You write plain English files describing what your business is, what you care about, and what each role should do — and the folder structure handles the rest.
Start small: build just the revenue manager first. Upload 6 months of invoices, write the instruction file, and run the one-line prompt. If it catches something you missed (a duplicate, an aging receivable, a trend you hadn't noticed), you have your proof of concept. Then add the spend manager, the forecast manager, and the reporting manager — one at a time, verifying each output before chaining the next.
For more on building AI agent systems that work like a company, see how to orchestrate AI agents like a company and how to build an AI agent operating system in 2026. If you're replacing repetitive tasks with AI workflows, our guide on 5 AI agent workflows that replace your most repetitive tasks covers the patterns. And if you want to set up Claude for this kind of work, start with our complete Claude setup guide for 2026.
FAQ
Q: Do I need to know how to code to build this? A: No. The entire system is plain English markdown files organized in folders. You describe what each role owns, which files it reads, and where it writes output — all in natural language. Claude interprets the instructions and executes them.
Q: Which Claude plan do I need? A: The free tier can work for small datasets, but Claude Pro ($20/month) is recommended because it gives you a larger context window and Project support with up to 20 knowledge files. The approach works with any AI that can read files and follow instructions in a conversation.
Q: Can this replace my accountant? A: No. This system does the execution work — reconciling, summarizing, forecasting, and flagging — but you keep the decisions. It catches errors and surfaces risks, but a human still reviews the output and makes the call. Think of it as a junior analyst that never sleeps, not a replacement for professional judgment.
Q: How accurate is the financial analysis? A: The system is only as accurate as your instruction files and your data. The roles flag anomalies and never silently absorb problems by design, which materially reduces error rates compared to manual spreadsheet work. But you should always run the trace test — pick a number from the report, find it in the summary, find it in the raw data — before making decisions on the output.
Q: What if Claude makes a math error? A: Large language models can make arithmetic mistakes, which is why the system is designed for traceability. Every number in a downstream output should trace to an upstream file, and the deck builder's strictest rule is that it presents numbers but never calculates them. If you build the system as described and run the verification test, math errors surface before they reach a decision.
Q: Can I adapt this for other business functions beyond finance? A: Yes. The pattern — shared context files, role-specific instruction files with exact input/output specs, and a coordinator that runs roles in order — works for any multi-step analytical workflow. Sales analysis, marketing reporting, operations monitoring, and project management can all follow the same folder-and-role structure.
Discussion
0 comments