Cube Blog

AI in Finance: Build or Buy?

Written by Christina Ross | May 19, 2026 5:03:10 PM

01 — Reframing the question

What "build" means in 2026.

The build path used to mean a team of engineers, a custom database, and a homegrown UI. That version is mostly dead. The build path today is something almost every finance team already has half-assembled.

02 — Why Cube was built this way

Cube works with the tools your team already uses.

Cube has worked with thousands of finance professionals and invested tens of millions of dollars learning the use cases, edge cases, and breakage modes that matter most when finance has to be right. That experience is built into the product. Most FP&A platforms ask finance to abandon the tools they live in. Cube was built the opposite way — to live inside your existing stack and make it finance-grade.

 

03 — What goes wrong

What actually breaks when finance teams try to build.

Five patterns we see over and over from teams who tried to assemble their own FP&A stack. None of them are about the tools failing. They're about what the tools were never built to do.

Pattern 01 — The board meeting

No traceability. No auditability. No answer.

The board deck shows 14% YoY revenue growth. The board chair asks where the number came from. The CFO turns to the FP&A lead. The FP&A lead pulls up the Claude transcript that produced the figure, then the warehouse query, then the spreadsheet that adjusted for a customer who pushed a contract from Q3 to Q4 — except that adjustment was made in a different version of the spreadsheet, and the version Claude pulled from is the wrong one.

Twenty minutes into the meeting, the team is still trying to figure out which number is right. There's no traceability back to the source, no audit trail showing how the number was built, and no way to answer the question in the room. The CFO ends the conversation by saying they'll come back next week with a clean answer. The board doesn't ask another question that quarter.

With Cube

Full traceability and auditability built in. The CFO clicks the number on the slide and drills straight to the underlying transactions. The conversation moves on in 30 seconds.

Pattern 02 — The ERP migration

The chart of accounts changes. The whole stack breaks silently.

The company switches from one ERP to another. The schema changes. New accounts appear. Some contra accounts come over with the opposite sign convention from the old system. Revenue accounts that used to live under one parent get re-parented to another. The warehouse pipelines get updated. The BI dashboards get rebuilt. Nobody updates the Claude skill that defines the chart of accounts, because it lives on the FP&A lead's laptop and was set up nine months ago.

Claude doesn't flag any of it. When it sees an unknown account, it makes its best guess at where it belongs. When the sign flips on a contra-revenue account, it reads the negative as a refund instead of a netting adjustment. For the next two months, every analysis is wrong in a quiet way that nobody notices. The team finds out at the start of audit, when the auditor asks why account 4250 keeps appearing in ARR calculations. By then, the last two board reports already went out.

With Cube

Cube's Data Manager flags every unknown account, every sign-convention change, and every unmapped dimension before the data lands in a report. It pings finance to confirm the right treatment instead of guessing. The chart of accounts is defined once and the platform tells you what changed — it doesn't make it up.

Pattern 03 — The analyst leaves

The system worked. Then the person who built it gave notice.

The senior FP&A analyst spent eight months building out the prompt library, the warehouse views, the Excel templates, and the dashboard pipelines that made the build stack actually work. They knew which prompts were canonical, which dashboards were stale, which spreadsheet templates had the right reconciliation logic. They were also the only person who knew.

They got recruited. Two weeks notice. The team spent the next six weeks reverse-engineering their own platform. The CFO discovered, mid-quarter, that they had built a critical piece of finance infrastructure on top of one person's personal toolkit.

With Cube

The platform is documented, governed, and finance-owned by default. When someone leaves, the system stays.

Pattern 04 — The consolidation

The numbers consolidate. Nobody can audit how they got there.

Revenue per head is calculated in a workforce planning tool. Cost of sales is calculated in a separate operations spreadsheet. Working capital comes out of the treasury system. Each one was built by a different person, using slightly different definitions of headcount, slightly different inclusion rules for COGS, slightly different cutoff dates. Then the FP&A team consolidates the outputs into the board model.

When the audit committee asks how revenue per head was calculated this quarter — which heads, what revenue, what time period, why the number is different from last quarter — the answer requires reaching into three different systems run by three different teams. Some of the inputs traced back to the GL. Some didn't. The CFO can't say with confidence whether the consolidated number is right, only that the source files all say what they say.

With Cube

Calculations live in one place with one set of definitions. Headcount, revenue, COGS, and working capital all pull from the same governed source. Click the consolidated number on the board slide and drill back through every input — including which definition of headcount, which revenue accounts, and which adjustments were applied. Auditable end-to-end, not just at the GL.

Pattern 05 — Works on my machine

Runs on the builder's machine. Nowhere else.

The build stack that works in demo looks like this: one analyst's machine, one set of credentials, one folder structure, one set of environment variables that connect the warehouse, the BI tool, the LLM, and the Excel add-in. When they share it with the rest of the team, it breaks. Different Python version. Different pathing. Credentials that only work for the original builder. No documentation, because the setup happened iteratively over three months of trial and error on a single laptop.

The team can't use it. They can't maintain it. They can't build on it. Every finance request routes through one person — the only one who can actually run the analysis. What looked like a platform is a personal tool that one analyst knows how to operate. The CFO has inadvertently made a single point of failure the center of the finance function.

With Cube

Cube is the production environment finance teams actually need — governed, permissioned, and single source of truth. FP&Agents delivers the AI layer on top: grounded in your data and your logic, with full traceability so the answers hold up. Because it's no-code with unlimited users, the whole team and their business partners work from the same system — not one analyst's script. That's the line between an experiment and a finance-grade platform.

04 — Why these patterns repeat

Where the LLM + warehouse stack works, and where it doesn't.

The patterns above aren't bad luck. They're the predictable result of using a stack of general-purpose tools to do a job that requires a finance-grade layer underneath.

General AI is probabilistic. Finance is deterministic.

Claude is a language model. It's built to generate the most likely answer based on patterns in the data and the prompt. That's a probabilistic system, and on most questions it works beautifully — until you ask it for a number that has to be exactly right.

Finance doesn't operate on patterns. Every number has one correct answer that traces back to a specific transaction. Pointing a probabilistic engine at a deterministic problem is the architectural mismatch that produces confident, articulate, wrong answers.

AI can be 80% right. In finance, 80% right means someone gets fired over the other 20%.

Cube is deterministic. The number you see on a Cube report is the number, every time, calculated the same way. When Claude pulls from Cube through the MCP Server, Claude stops guessing and starts retrieving — Claude's writing on top of Cube's arithmetic. 

The semantic layer has to live somewhere. The question is whether it's enforced.

Yes, you can give Claude a skill or a context file that defines your chart of accounts, your COGS formula, and your hierarchies. Claude will follow it most of the time.

A skill is an instruction, not a constraint. When the prompt is ambiguous, Claude will sometimes do what the skill said not to. There's no compiler. No error. Just a confident wrong number. And a skill on one person's machine isn't a skill on another person's machine — the semantic layer forks across users and tools.

Cube enforces the calculations at the data layer. Every query — yours, Claude's, a dashboard's — gets the same answer because the answer is calculated, not interpreted.

Your warehouse doesn't see the data that lives outside it.

Your warehouse has the GL. It does not have the spreadsheet adjustment your VP made at 9pm Tuesday, the Slack thread where the CFO and COO agreed to defer a hire, slide 14 of last quarter's board deck where the reforecast got memorialized, or the email pushing a contract from Q3 to Q4.

Your real numbers are a blend of warehouse data and adjustments that never made it back to the warehouse. Claude querying the warehouse gives you a confident answer that's missing 15% of reality, and won't tell you it's missing anything.

Cube lives in the spreadsheet, the deck, and the chat. It captures the adjustments the warehouse can't see and makes them part of the governed record.

There's no audit trail in a chat log.

Your CFO asks where the 12% growth number came from. So does the audit committee. So does the diligence team during the next round. So does the SOX auditor at the public-company readiness review.

In the build stack: read the Claude transcript, figure out which prompt produced the answer, what data Claude saw, whether the answer was cached, whether Claude interpreted the schema the same way last time. There's no path back to the source. There's a chat log. That doesn't pass diligence and it doesn't pass audit.

In Cube: click the number, drill to the underlying transactions. Every figure traces back to the GL. Every change has an owner, a timestamp, and a before/after — the kind of audit trail SOX, M&A diligence, and the board chair all expect by default.

Maintenance is the silent line item.

The build stack on day one looks lean. The build stack on day 400 looks like: someone owns the warehouse pipelines. Someone owns the BI dashboards. Someone owns the prompt and skills library, plus drift. Someone owns the spreadsheet templates that re-import warehouse data. Someone fixes it when the ERP migration changes the schema. Nobody owns the place where these things meet.

That work doesn't show up on the build-vs-buy spreadsheet. It shows up as the FP&A team doing less FP&A every quarter.

Cube ships those pieces as one platform, owned by finance. When the chart of accounts changes, you change it in one place. When the analyst leaves, the system stays.

05 — Total cost, honestly

The TCO comparison that accounts for the modern build stack.

Most build-vs-buy spreadsheets only look at direct cost. The lines that matter are the ones the spreadsheet leaves off — and the ones that don't show up until something goes wrong.

 
Path A
Build: warehouse + BI + LLM
Path B
Buy: Cube on top of your existing stack
 
Direct cost
Visible day one
Warehouse compute, BI seats, LLM API or seat costs. Small line item. You're already paying most of it.
Cube subscription. One platform fee. Sits on top of the warehouse and BI you already pay for.
Maintenance cost
Semi-visible after 6 months
FP&A lead and analyst time spent maintaining prompts, skills, schemas, dashboard pipelines, and spreadsheet templates. Compounds quarterly. Walks out the door when an analyst leaves.
Finance owns one platform. Logic lives in one place. Change the chart of accounts once, it updates everywhere.
Risk cost
Invisible until it isn't
A wrong number in front of the board. A failed audit. A diligence delay because nothing traces back to the GL. Hard to model. Real.
Every number drills to the transaction. Audit-ready by default. Cell-level access control enforced at the data layer.
Time to first answer
Days
Fast. Connecting Claude to a warehouse and writing a useful prompt can happen in a week.
Fast. Cube connects to your existing source systems and stands up in days.
Time to the hundredth
answer
Months
Months — done continuously. Hierarchies, formulas, scenarios, access rules, and audit logic encoded across drifting prompts, dashboards, and spreadsheets. Rebuilt every time someone leaves.
Months — done once, in a platform built for it. The work compounds instead of decaying.
Owner
Who maintains it
Engineering owns the warehouse. FP&A is now in the prompt-engineering business. A part-time job nobody hired for.
Finance, end-to-end. No tickets, no consultants, no engineering dependency for changes to financial logic.

06 — The Cube case

Cube is the layer that makes the stack you already have finance-grade.

Keep the warehouse. Keep the BI tool. Keep Claude in Excel. Cube sits on top, encodes your math once, and gives the rest of your stack something it can't build on its own: a single, governed source of truth.

QUESTION FROM THE BOARD
"Where did the 14% number come from?"
 
 
 
 
 
CALCULATED ANSWER
+14% YoY · trace to 1,847 transactions
 
SOURCE OF TRUTH
GL transactions
FROM ERP
Spreadsheet adjusts
FROM EXCEL / SHEETS
Slack / Teams Decisions
NATIVELY WHERE
YOU COLLABORATE
Board deck overrides
CAPTURED IN PPT
Owner · timestamp · diff
AUDIT TRAIL
01

Math that's calculated, not interpreted.

Your chart of accounts, your COGS formula, your hierarchies, your scenarios — defined once in Cube and enforced at the data layer. No skill drift. No version forks. The same number every time.

02

The data your warehouse can't see.

Cube lives in the spreadsheet, the deck, the chat — the places where finance actually works. Adjustments, decisions, and overrides become part of the governed record instead of disappearing.

03

Audit-ready every quarter, not just when the auditor shows up.

Every number drills to the GL. Every change has an owner, a timestamp, and a before/after. Cell-level access enforced at the data layer. SOX, diligence, and board questions answered the same way: by clicking the number.

07 — Where you are right now

Match yourself to the closest scenario.

Six situations we hear from finance leaders every week. None of them are made up. All of them have the same answer.

01

You already have a warehouse, a BI tool, and Claude.

The pieces are there. The numbers still don't tie out at month-end.

What Cube Does

Sits on top of the stack you already pay for. Gives the pieces a single source of truth so the numbers tie out the first time.

02

You're multi-entity, with real audit and board reporting requirements.

Every quarter, someone has to manually reconcile across entities, currencies, and adjustments.

What Cube Does

Multi-entity consolidation, intercompany eliminations, multi-currency, and audit logging built into the core architecture.

03

One person on your team built the system that holds everything together.

They know which prompts are canonical, which dashboards are stale, which templates are right. They are also the only person who knows.

What Cube Does

The platform is documented, governed, and finance-owned by default. When someone leaves, the system stays.

04

Every number on every board slide needs to trace back to a transaction.

For SOX, for audit, for diligence, or because the board chair will ask.

What Cube Does

Click the number on the slide, drill straight to the GL. Every figure has an owner, a timestamp, and a before/after.

05

You want Claude in Excel to actually work for finance.

Right now it's a smart assistant pointed at messy data. You need it pointed at clean, governed data.

What Cube Does

The Cube MCP Server connects Claude to a single governed source. Claude stops generating numbers and starts retrieving them.

06

You don't want to wait six months for finance to be modern.

You want the platform live, owned by finance, and answering board questions in days — not after a consulting engagement.

What Cube Does

Stands up in days. No consultants required. Finance owns the platform end-to-end from day one.

AI is probabilistic. Finance is deterministic. Cube is the layer in between.

AI does a great job at the 80% version of the answer. In finance, someone is accountable for every number on the page — and that accountability has to trace back to a transaction, not a language model's best guess. The board chair, the auditor, the diligence team — they all need the same thing: a number with a source, an owner, and a path back to the GL.

Keep the warehouse. Keep the BI tool. Keep Claude in Excel. Cube sits on top, encodes your math once, captures the data your warehouse can't see, and connects to Claude through the MCP Server so the answers you get are calculated instead of generated.

Cube is what makes the stack you already have finance-grade.