The AI-Native Accounting Tech Stack

Welcome to issue #015 of New Age Accounting. Build it lean. Build it to scale. Build it once.

Jun 17, 2026

Every accountant using AI right now is working with tools. The good ones are working with a system.

There is a difference.

A tool is something you pick up when you need it. A system is something you design once and let run. The Accounting Engineer doesn’t just use a stack — they design one. They think about how data moves, where it lives, what connects to what, and what comes out the other side. They build with the end in mind.

That’s what this article is about.

Not a list of software. Not a vendor comparison. A framework for thinking about how to build an AI-native accounting stack that stays lean as the business grows, automates without sacrificing accuracy, and produces the outputs your team needs every month without rebuilding from scratch.

Here’s how it works.

Start with the end in mind

Before you touch a single tool, answer three questions.

1/ What do you need to produce every month? Close commentary. Flux analysis. Financial statements. Reconciliations. Cash analysis. The outputs define the system. If you don’t know what you’re building toward, you’ll end up with a collection of tools that don’t talk to each other.

2/ How lean do you need to stay? A two-person finance team at a Series A company has different requirements than a ten-person team at a Series C. The stack should scale alongside the business without requiring you to add headcount every time the volume goes up.

3/ What needs to be automated and what needs a human? Not everything should be automated. The goal isn’t to remove humans from the process — it’s to remove humans from the work that doesn’t require them. The Accounting Engineer designs that line intentionally. Everything below it gets automated. Everything above it gets their attention.

Answer those three questions first. The rest follows.

The five layers

An AI-native accounting stack has five layers. Each one builds on the one below it. Get the foundation right and everything above it gets better.

Layer 1 — Data Sources

This is where your data lives. ERP, spend management, payroll, billing, and anything else that produces financial data. The key question at this layer isn’t which tool — it’s whether each tool can get your data out cleanly and consistently. Tools that silo data are a liability. Tools that expose it are an asset.

Modern ERPs are increasingly building MCP connections — meaning Claude can reach in and pull data directly without a manual export. NetSuite, Rillet, and Campfire all have MCP. Spend management platforms like Ramp and Brex do too. If your ERP doesn’t expose your data cleanly, that’s a constraint worth solving before you build anything on top of it.

Layer 2 — Semantic Layer

Raw data from multiple systems is messy. The same concept has different names in different tools. Revenue in your ERP might be labeled differently than revenue in your billing system. The semantic layer is where you standardize — define your metrics, create consistent naming, and make sure that when you ask for “revenue,” every system means the same thing.

This layer is often skipped by smaller teams. That’s a mistake. The semantic layer is what makes the data warehouse trustworthy. Without it, you’re building on an unstable foundation.

Layer 3 — Data Warehouse / Data Lake

This is your single source of truth. All of your financial data — from every source, through the semantic layer — lives here, clean and ready. When Claude pulls data for a flux analysis, it’s pulling from here. When you build a dashboard, it’s reading from here. When an auditor asks for the methodology, you can point here.

The warehouse is what turns a collection of disconnected tools into a system. It’s the layer that makes everything else possible.

Layer 4 — Claude

This is where the work happens. Claude connects to your warehouse via MCP and pulls live data directly — no exports, no copy paste, no manual steps in between. Chat to design what you want to see. Cowork to execute complex multi-step workflows. Code to build exactly what you need. Projects to save the context so you’re not starting from scratch every month.

The quality of what Claude produces is directly tied to the quality of the layers underneath it. Clean data, well-defined metrics, a reliable warehouse — Claude takes that and produces outputs that are structured, consistent, and ready to use. The better the foundation, the better the output.

Layer 5 — Monthly Deliverables

This is what your stack produces. Every month, consistently, without rebuilding from scratch.

Flux analysis — month over month variance with commentary, pulled directly from your warehouse, generated by Claude in the format your CFO expects.

Cash analysis — inflows, outflows, variance to forecast. Claude connects, pulls the data, produces the output.

Financial statements — P&L, balance sheet, cash flow. Structured, reviewed, ready.

Reconciliations — account, bank, intercompany. The agent runs the process. You review the output.

Close commentary — CFO-ready narrative on the period, written in the tone and format you’ve defined in your Project.

These aren’t aspirational. They’re workflows accountants are running right now. The stack makes them repeatable.

What this looks like at a lean company

Here’s what this stack looks like in practice for a lean finance team at an early-stage company.

The ERP is Rillet/Campfire — AI-native, MCP-connected, built for teams that need to move fast without sacrificing accuracy. Spend management is Ramp/Brex — MCP connection means Claude can pull transaction data directly. Payroll and billing feed in. The semantic layer is lightweight but defined — consistent account naming, consistent metric definitions. The warehouse is the layer that ties it all together.

Every month, Claude connects via MCP, pulls the current period data, compares to prior period, and produces flux analysis, cash analysis, and close commentary — all in a format that’s been defined once and reused every month. The close that used to take days now takes a fraction of that. Not because the work disappeared. Because the system handles the work that doesn’t require a human.

The accountant who built that system isn’t spending time on exports and formatting. They’re spending time on the analysis that actually moves the business.

That’s the Accounting Engineer.

Three things to avoid

The biggest mistakes when building an AI-native stack aren’t technical. They’re structural.

1/ Buying tools before defining the architecture. The natural instinct is to start with the tool — find the best ERP, find the best spend management platform, find the best AI. But tools without architecture are just more things to maintain. Start with the end in mind. Define what you need to produce. Then build toward it.

2/ Automating for automation’s sake. Not every process should be automated. The ones that should are the ones that are repetitive, rule-based, and high-volume. The ones that shouldn’t are the ones that require judgment, context, and human oversight. Build the line between them intentionally.

3/ Building something only you can run. The best accounting systems aren’t dependent on one person. They’re documented, organized, and transferable. If the only person who can explain your AI workflows is you — that’s a risk, not an asset. Build like someone else will need to run it.

Building for the future

The accounting profession is in a building phase. The teams that come out of this period ahead aren’t the ones with the most tools — they’re the ones that built the most intentional systems.

Stay lean. Build with the end in mind. Design the stack so the data flows, the outputs are consistent, and the work that doesn’t require a human doesn’t get one.

That’s the Accounting Engineer’s job now.

Go build it.

Here’s my question to you:

What’s the biggest gap in your current stack — the layer that’s holding everything else back? Drop it in the comments. I read every one.

Discussion about this post

Ready for more?