Introducing AI in finance in a structured way means the same thing as any other system implementation: set it up first, then automate. In practice you build six layers from the bottom up. First you capture what you know about your business (context), then you arrange access to the systems (connections), then you automate the fixed rule-based work (automation, which you can now build yourself with vibe coding), then you capture recurring tasks (skills), then you put those in sequence (workflows), and only after that do you let AI do judgement work (agents). Version control and oversight run through every layer.
Chances are someone on your team has already had ChatGPT or Copilot write the commentary on the monthly figures. Sometimes usable, often just off. The wrong GL account named, a variance explained that isn't there, a completely different structure the next month. The conclusion comes quickly: AI isn't ready for finance yet.
That is usually the wrong conclusion. It is the same lesson as every ERP implementation: if you automate what hasn't been defined, you automate the mess. You don't start a new ERP with the reports either. You start with the chart of accounts, the master data, the procedures and the authorisations. AI is no different.
Why finance is stricter here than other departments
An AI model knows a lot about finance in general and nothing about your business. It doesn't know your chart of accounts, your materiality threshold, or the agreement that project revenue is only recognised on delivery. It can't reach your ledger on its own. And a task you haven't defined precisely, it will do slightly differently every time.
For marketing or HR that is often acceptable. For finance it isn't. Numbers have to be right, reconcile and trace back to the source, the same way every month. The auditor wants to see how a figure came about. That calls for a function set up so AI can work inside it, not a tool you bolt on next to the existing way of working.
The six layers
Judgement work and monitoring per domain.
Tasks in sequence, tied to the finance calendar.
Written work instructions, one task per skill.
Capture, processing and links between systems, built with vibe coding.
Access to the ledger, bank and source systems.
What you know about your business, written down.
| Layer | What it is | The question it answers |
|---|---|---|
| 1. Context | What you know about your business, written down | How does this business work? |
| 2. Connections | Access to the ledger, bank and source systems | Where is the data? |
| 3. Automation | Capture, processing and links between systems, built with vibe coding | How does data end up in the right place by itself? |
| 4. Skills | Written work instructions, one task per skill | How do we do this task, every time? |
| 5. Workflows | Tasks in sequence, tied to the finance calendar | What happens when? |
| 6. Agents | Judgement work and monitoring per domain | What does this mean and what needs to happen? |
| Throughout: version control | All context, skills and scripts in GitHub | Who changed what, when and why? |
| Throughout: oversight | Approval, evidence, logging | Where does a human decide? |
The layers build on each other. A skill reads the context. A workflow puts skills in sequence. An agent works with what the layers below deliver. If a layer is missing, the layer above starts to falter.
Layer 1: context
Everything an experienced colleague knows and a new one doesn't yet: the chart of accounts and why it is set up that way, the KPI definitions, the business model, the accounting policies, the agreements with large customers, the materiality thresholds and what went wrong in previous closes. Today that knowledge usually lives in people's heads, in emails and in stray Excel tabs.
You capture it in short, separate documents, one topic per document, each with an owner and a last-updated date. That way every task loads only what it needs, and you know who has to update it when something changes. More on this in Context engineering for finance AI.
Where do you store it? A practical example. The approach that works best in practice: one private GitHub repository for the finance function, with plain text files in Markdown. No Word documents buried in SharePoint and no tabs in the month-end Excel. Markdown is equally readable for people and AI models, every change is visible line by line, and tools like Claude Code read the folder directly.
A structure that works well:
finance-function/
├── README.md ← what lives where, who owns it
├── context/
│ ├── company-and-structure.md ← entities, activities, organisation
│ ├── chart-of-accounts.md ← per account: what belongs on it, what doesn't
│ ├── accounting-policies.md ← revenue recognition, valuation, depreciation
│ ├── materiality-and-thresholds.md
│ ├── intercompany-and-allocation-keys.md
│ ├── kpi-definitions.md
│ ├── customers-and-contracts.md ← agreements that affect the bookings
│ └── close-history.md ← what went wrong before, and why
├── skills/ ← layer 4, one folder per skill
├── scripts/ ← layer 3, the automation you built yourself
└── workflows/ ← layer 5, for example month-end-close.md
And this is what a single context file looks like:
---
owner: Controller
last_updated: 2026-09-30
applies_to: all entities
read_by: variance-review, monthly-commentary
---
# Materiality and thresholds
## Explain in the monthly report
- Variance against budget or last month above € 2,500 and above 10%: always explain.
- Variance on revenue: always explain, regardless of size.
## Known patterns (do not report as a variance)
- Marketing costs (account 4400): structurally higher in Q2 because of trade fairs.
- Holiday pay: accrued monthly, paid out in May.
## Escalate to the CFO
- Any correction to a closed period.
- Any intercompany difference, regardless of size.
Three ground rules come with it. No passwords, API keys or personal data in the context. One source only: whoever also keeps the same information in a Word document will have two versions of the truth within three months. And updating it is a fixed step on the month-end checklist, otherwise it doesn't happen.
If GitHub is a step too far for your team right now, start with the same folder structure and Markdown files in a shared SharePoint or OneDrive folder. You then have the structure already, and moving to GitHub later is a matter of moving the folder.
Layer 2: connections
Access to where the data lives: the accounting package (Exact Online, Twinfield, AFAS), the bank, the invoicing system, the CRM and the folder with contracts. More and more often that access runs through MCP, the standard AI models use to talk to systems (see What MCP is).
The key design choice: read or write. Always start read-only. Write access only comes once a workflow has proven it needs it, and then behind an approval step. Agentic AI and access to your ledger goes deeper into this.
Layer 3: automating capture and processing
Not every system has a ready-made connection, and a lot of finance work is still manual work between systems: exporting, retyping, putting things side by side in Excel. That automation no longer has to be an IT project. With vibe coding you build it yourself. In vibe coding you describe in plain language what you want and an AI model writes the software. What used to be an IT project, a controller now builds in an afternoon.
This layer does three things:
- Links between systems. Invoicing that reconciles to the general ledger automatically, hours linked to projects, the CRM customer matched to the debtor.
- Capture. Purchase invoices read from the mailbox and lined up as draft entries. Bank transactions that come in daily and are pre-matched.
- Processing. Reconciliations, allocation keys and recalculations that run exactly the same way every month.
What you build here is ordinary software, not AI reasoning each time. It does exactly the same thing every time, costs next to nothing per run and interprets nothing differently from last month. That is the point. Everything that follows fixed rules belongs in this layer. The more that is handled there, the cleaner the data the agents further up work with.
The rule of thumb for what belongs here: if two experienced team members did this task independently, would they arrive at the same result? Then it is rule-based work and it belongs in this layer. If it calls for judgement, it belongs with an agent.
Layer 4: skills
A skill is a written work instruction that AI carries out the same way every time: the variance commentary, the weekly liquidity update, the check on accruals and deferrals. You explain the task properly once instead of every time.
Three design rules make a skill reliable:
- One task per skill. If a skill does two things, you won't know which one failed when something goes wrong.
- No hard-coded numbers in the skill itself. Thresholds and exceptions live in the context (layer 1). If the threshold changes, you update one document, not ten skills.
- Show the working. Every result comes with the source, the formula and the intermediate steps. If something is missing, the skill stops and asks.
Layer 5: workflows
A workflow puts skills and automation in sequence and hangs them on the calendar of the finance function: what happens on working day 1, 2 and 3 of the close, what every Monday, what at quarter end. Between the blocks are the moments where a human approves the previous block before the next one starts. See also AI workflow around the month-end close.
Layer 6: agents
The agents sit at the top. They do what can't be captured in fixed rules: interpret a variance, judge whether something is one-off or structural, propose a correction, decide what a human needs to see. You organise them by domain: control, receivables and payables, analysis, forecasting, reporting. An SME starts with one.
Throughout: version control
Once a team really starts using AI, everyone starts building. One person writes a script for the bank reconciliation, another a skill for the debtor emails. That is good, until you notice it all sits on personal laptops. Then that one controller leaves, and the automation leaves with them. Or the auditor asks about a figure from three months ago, and nobody knows which version of which skill produced it.
The solution may sound odd to a finance team, but it is standard practice in software development: put everything in GitHub. The context, the skills, the scripts and the workflow descriptions live in one repository, with the full history of every change.
For finance that delivers three things you already know from internal control:
- An audit trail on your own way of working. You can see line by line who changed the materiality threshold, when and why. And you can look back at which version of a skill ran in a given month.
- The four-eyes principle on changes. A change goes through a so-called pull request: the controller proposes an adjustment, the CFO approves it before it goes live. Exactly like a change to master data.
- Knowledge that stays. What has been built sits in a fixed place, is visible and reusable for the team, and stays when the person who built it leaves.
One rule for everyone who builds something: if it isn't in the repository, it doesn't exist. And when a context file changes, you retest the skills that read it before they run in the close again.
Throughout: the oversight layer
Across all layers runs the question: what if it goes wrong? The answer lies in how you set things up, not in hoping it goes well. Every finding has evidence that can be traced back to the entry. Every action is logged. When in doubt, the system stops and asks. And there are fixed moments where a human approves before anything moves on. Where to place those moments is covered in Human-in-the-loop in finance workflows.
Example: the controller workflow through the layers
A good starting point for almost any finance team is the month-end close review. An error that slips through there comes back in the reporting, in the forecast and eventually in a decision. Take an SME with two entities, Exact Online, an invoicing system and a controller who currently spends two days a month checking. This is how the layers work together.
Layer 1, context. The controller writes down what she now keeps in her head: the chart of accounts with what belongs on each account, the materiality threshold (for example, explain variances above € 2,500 or 10%), the revenue recognition policy, the allocation key for shared costs between the two entities, and a list of what went wrong in recent closes. That last document is worth its weight in gold: it tells the rest of the system where to look. Everything goes into the context/ folder of the finance function's repository.
Layer 2, connections. Read-only access to both ledgers in Exact, the bank accounts, the invoicing system and the contracts folder. Nothing is written.
Layer 3, automation. Using vibe coding, the controller builds a few small programs that do the rule-based work. A reconciliation of revenue in the invoicing system against revenue in the ledger. A reconciliation of the bank against the balance sheet. A check that the intercompany receivable in one entity equals the payable in the other. A comparison of the trial balance with last month per account. These programs run identically every month and produce a list of differences. No interpretation, just facts.
Layer 4, skills. For the judgement work there are skills, each with one task. One skill assesses the list of differences against the materiality threshold. One checks whether revenue and costs were booked in the right period. One verifies that the recurring accruals (holiday pay, invoices still to be received, prepaid licences) are there. One summarises the findings in the controller's standard format. Thresholds and policies come from layer 1.
Layer 5, workflow. On working day 1 after the period closes, the programs from layer 3 run. Then the skills run in a fixed order: first completeness and reconciliations, then period cut-off, then accruals. After each block there is an approval moment. Only when the reconciliations are signed off does the substantive review start.
Layer 6, agent. The control agent takes the output of the layers below and does what rules can't. It connects the dots: the difference between invoicing and the ledger coincides with a credit note booked in the wrong month. It proposes a correcting entry. And it states how confident it is per item, so the controller knows where to look herself.
Version control. After the third close, the materiality threshold for small cost accounts turns out to be too low: the list of findings is too long. The controller proposes a new threshold through a pull request, the CFO approves it, and the skills that read the file are first retested on the previous month. At year end she can show the auditor exactly which threshold applied in which month.
Oversight. The controller gets one overview: findings, evidence per item with a reference to the entry, proposed corrections and the level of confidence. She approves, adjusts or rejects. The agent books nothing itself. Everything that happened is in the log.
The result: the controller no longer searches, she reviews. Two days of checking become a few hours of focused attention on what actually matters. And because each layer does its own job, you also know where to look when something goes wrong. If a definition is off, you fix the context. If the numbers are stale, it is the connection. If the structure is wrong, it is the skill.
What happens when a layer is missing
The structure also works as a diagnostic tool. Anyone who uses AI and is disappointed can usually point to the missing layer:
- No context: the answers are generic and never quite fit your business.
- No connections: someone spends time every month exporting and uploading, and the numbers are always one step behind.
- No automation layer: the agent does rule-based work that ordinary software does better. More expensive, slower, and slightly different every month.
- No skills: quality depends on who asks the question and how they phrase it that day.
- No workflow: separate tools that nobody switches on at the right moment.
- No version control: automations on personal laptops, and nobody can say which version of a skill produced last month's figure.
- No oversight layer: it goes well for weeks, the team stops checking, and then it goes wrong once without anyone noticing.
Where do you start?
Not with the agent, and not necessarily with programming. Start with one workflow that takes time today and whose outcome you can check. The month-end close review is often the best candidate. Set up the repository first, so everything has a fixed place and a history from day one. Then build the layers from the bottom up: write down the context first, then the connections, then automate the rule-based work, then the skills, then the workflow with its approval moments. The agent comes last.
Test the whole chain first on a closed month where you already know the right outcome. Only when it gets that right does it move on to the current month.
The order of the layers is the architecture, not a mandatory build order. Many teams get their first results with context and skills on exports from the accounting package. That is fine. Add the automation as soon as you notice skills or agents doing rule-based work, or someone exporting the same file every month.
The real return often isn't in the agent itself. It lies in being forced to write down how your finance function actually works. If you want to know how far your team is from that, an AI readiness scan is a good place to start.