Hi Reader,

Most finance teams don't have an AI problem. They have an integration problem.

You can hand your team the best model on the market and it won't matter if that model is disconnected from your actual systems. You'll still be exporting CSVs, pasting numbers into a chat window, and manually re-uploading the "latest version" of a file three times a week. That's not an AI-ready stack — that's a chatbot with extra steps.

An AI-ready finance stack is built in layers, from the ground up. Each layer depends on the one below it actually working. Skip a layer, and everything built on top of it inherits the gap. This newsletter walks through all five, in order, with what to actually do at each one — and where to go if you want to go deeper.

Working through this alone? If you want a community of FP&A and finance people doing the same thing — swapping prompts, workflows, and what's actually working — join the AI Finance Club.

Layer 0: Data — the core

Before you touch a single AI tool, map out where your numbers actually live.

For most finance teams, that means: your ERP, your general ledger, your CRM, your bank feeds, and — let's be honest — a folder of spreadsheets that nobody officially owns but everyone secretly depends on.

The goal of this layer isn't to pick a tool. It's an audit. For each system, ask:

• Who owns it, and who has write access?
• Can it be reached programmatically (API, export, database connection) or does someone have to click "download" every time?
• How often does it actually get updated?

This is unglamorous work, and it's tempting to skip straight to "which AI tool should we buy." Don't. Every layer above this one is only as reliable as this audit is honest.

Read more:

• ​Single Source of Truth in Finance — Onetribe Advisory — a clear-eyed look at why SSOT is a governance outcome, not a tool, and where most finance teams actually go wrong at this stage.
• ​SSOT Explained — Workday — a practical walkthrough of auditing and standardizing data sources before you consolidate anything.

Layer 1: Connectors — the pipes

This is where "AI-assisted" turns into "AI-ready."

If your AI tool only accepts file uploads, you're still doing the integration manually — the AI just helps you analyze the file after you've done the work of getting it there. A connector removes that step entirely, giving the AI tool direct, live access to a data source.

In practice, this looks like:

• Native connectors — built-in integrations (Claude connecting directly to Google Drive or Google Workspace, for instance) that read live data without you exporting anything.
• MCP (Model Context Protocol) — an open standard, introduced by Anthropic, that lets an AI application connect to any compliant data source or tool through one shared protocol instead of a custom integration for every pairing. If you've ever had an engineer say "we'd need to build a custom integration for that," MCP is the thing that removes that sentence from the conversation.
• iPaaS tools (Zapier and similar) — useful glue for smaller, event-based workflows where a full MCP server is overkill.

The test for whether this layer is working: can someone ask a question and get an answer from current data, without anyone manually refreshing a file first?

Read more:

• ​MCP, Explained for a CFO — interactive guide — the analogy and the technical breakdown, in one visual walkthrough.
• ​Introducing the Model Context Protocol — Anthropic — the original announcement, explaining what MCP is and why it exists.
• ​What is MCP? — Model Context Protocol docs — the plain-English starting point if you want to actually understand how it works before your IT team gets involved.
• ​Use Google Workspace connectors — Claude Help Center — a concrete example of what a native connector looks like in practice, including what data it can and can't touch.

Layer 2: OSS — One Source of Truth

Here's the layer most AI rollouts quietly skip, and it's the one that determines whether the whole stack is trustworthy.

If your AI tool is connected to five different systems that each define "revenue" slightly differently, you haven't solved your data problem — you've just given it a faster way to produce five different answers. Garbage in, garbage out still applies, and it applies faster with AI in the loop.

Building a real single source of truth doesn't require a data warehouse on day one. It requires three things:

1. A chart of accounts (or equivalent) that's consistently applied across every system feeding into it.
2. One agreed definition per metric — what counts as revenue, what counts as a "closed" deal, which currency and unit convention wins when systems disagree.
3. A reconciliation cadence — a regular check that catches drift between systems before it reaches a dashboard or an AI-generated answer.

Start small. Pick one domain — revenue, headcount, whatever causes the most arguments in your monthly review — and get that one clean before expanding.

Read more:

• ​Single Source of Truth in Finance — Onetribe Advisory — includes a useful stat: the average organization maintains 3–5 competing "sources of truth" for the same financial data.
• ​Master Data Management: How to Build a Single Source of Truth — a practical breakdown of the different MDM approaches (registry, consolidation, transactional hub) and which fits which team size.

Layer 3: Playbooks & Context — the judgment layer

This is the layer most people building an "AI stack" don't know exists — and it's the difference between an AI tool that gives generic answers and one that reasons the way your team actually reasons.

An AI model with access to clean data can tell you what the numbers are. It can't tell you why a 12% variance in Q3 marketing spend is fine but a 12% variance in COGS isn't unless someone tells it your team's actual judgment calls, definitions, and standard operating procedures.

This layer includes:

• SOPs — how your team actually handles a close, a reconciliation, an exception.
• A prompt library — the handful of prompts that reliably produce good output for your recurring tasks, saved and reused instead of reinvented every time.
• Definitions and KPI documentation — the internal glossary that keeps everyone (and every AI tool) using the same vocabulary.
• Institutional memory — prior close notes, past variance explanations, context that usually lives in one senior analyst's head and nowhere else.

In AI terms, this is sometimes called "context engineering" — deliberately curating what an AI tool sees, rather than assuming a bigger context window solves the problem on its own. More context isn't automatically better context.

Read more:

• ​Context Engineering for FP&A Teams — interactive guide — the "new analyst's first meeting" analogy, plus six concrete moves mapped to a close cycle.
• ​Effective context engineering for AI agents — Anthropic — the source guide on curating what an AI tool actually needs to see, including the "context rot" problem of just dumping in everything you have.
• ​Context Engineering: A Practical Guide — Sourcegraph — a more accessible walkthrough if the Anthropic piece feels dense, with a clear framework for organizing this layer.

Layer 4: AI — the apex

This is the layer everyone starts with, and it should be the layer you finish with.

Claude, ChatGPT, Gemini, Copilot — the specific model matters less than what it's actually plugged into. A frontier model with no access to Layers 0 through 3 is still just a very articulate guess. The same model, sitting on top of clean data, live connectors, one source of truth, and your team's actual playbooks, is a genuinely different tool.

Once the first four layers are in place, this layer is mostly about interface: where do people actually ask the questions? A chat panel embedded in your dashboard. An assistant inside your spreadsheet. A Slack bot pulling from live data. The point is to put the AI where the work already happens, not to create a new tab people have to remember to open.

Read more:

• ​MCP in Anthropic products — Claude docs — a practical index of where MCP connectors actually show up across Claude.ai, Claude Desktop, and the API, useful once you're ready to wire this layer into the ones below it.

The takeaway

The teams getting real value from AI in finance aren't the ones with the most tools. They're the ones with the fewest gaps between their tools.

If you're starting from zero, don't start at Layer 4. Start at Layer 0 — go audit your actual data sources this week — and build up. Each layer you skip is a gap the one above it has to compensate for, and AI is not good at silently compensating for bad data. It's good at confidently reporting whatever you gave it.

If you want a structured way to actually roll this out with your team, week by week: The Six-Week FP&A AI Adoption Plan — interactive guide.

None of this has to be a solo project. If you'd rather build this alongside other FP&A and finance people doing the same work — sharing what's actually working, not just what sounds good in a demo — join the AI Finance Club.

Thanks for reading and if you have any questions, let me know!! (and also congrats for reading the whole newsletter)

This is an infographic I'll post next week on this btw, you get to see it first!

Christian Martinez