From Spreadsheets to AI: A Head of Finance's Guide to Getting the Order Right

Every finance leader I talk to is being pitched the same promise: AI will transform your close, your forecasting, your reporting, your team's capacity. But at startups, we're not just buying these tools anymore — we're building them ourselves. A few API keys, a weekend with Claude or ChatGPT, and suddenly the Head of Finance is shipping their own categorization scripts, reconciliation agents, and reporting copilots. And then, six months later, the same teams are quietly back in Excel. It's not because the AI is bad. It's because we built it in the wrong order.

As Head of Finance at a SaaS startup, I've spent the last weeks mapping out what actually works — what AI can deliver today in finance operations, what it can't, and why so many in-house builds underwhelm. The pattern is consistent enough to be worth writing down. This post is about the part nobody puts in a tutorial: the data foundation underneath. It's the part most finance teams underestimate, and it's where the actual ROI of AI in finance lives or dies.

The Core Idea, Stated Plainly

AI in finance doesn't fail because models are dumb. It fails because the data you're feeding it is:

• Inconsistent — the same customer is "Acme" in Stripe, "Acme Corp" in your CRM, and "Acme GmbH" in DATEV

• Incomplete — bank transactions have no reference to the invoice they paid

• Late — month-end close means your "current" data is 15 days stale

• Unstructured — your ARR sits in a Notion doc, not a queryable table

• Untrusted — three people compute MRR three different ways

When you ask an AI "what's our cash runway?" or "why did gross margin drop?", it can only be as good as the data it can reach and reconcile. Most "AI doesn't work" complaints in finance trace back to one of these five problems, not to the AI's capability. The real work, then, isn't the AI layer. It's the foundation underneath.

Building the Foundation: A Practical Sequence

Step 1: Audit Your Data Sources

A spreadsheet listing every system that holds finance-relevant data:

• System name (Stripe, HubSpot, DATEV, bank, Personio, etc.)

• Type of data (revenue, customers, expenses, headcount, etc.) - do it with AI: drop your list of tools into Claude and ask it to categorize them by data type, integration availability, and refresh cadence — it'll structure the audit faster than you would manually.

• API available? (yes/no/limited) - do it with AI: ask Claude what its API capabilities and limitations are. Most major SaaS APIs are well-documented in training data.

• Export format if no API (CSV, XML, manual)

• Who owns it internally

• Current refresh cadence (real-time, daily, monthly)

• Data quality issues you already know about

Deliverable: a one-page summary that gives you a clear map of where finance-relevant data lives, what's accessible, and where the gaps are.

Step 2: Stand Up a Warehouse

Tool choices:

• BigQuery if you want low setup overhead and pay-as-you-go pricing. Best for most startups

• Snowflake if you have data engineers and expect to scale to enterprise-level data

• Postgres (Supabase, Neon) if you're truly small and cost-sensitive — works fine up to a few million rows

ELT tool to pull data out of source systems and dump it into your warehouse on a schedule:

• Fivetran is the gold standard, expensive

• Airbyte is open-source, cheaper, more setup work

• Stitch is the budget option

• Hightouch if you also need reverse-ETL

• Ask Claude to write the connector scripts for the sources without easy ELT options

What to pipe in first, in priority order:

• Accounting (DATEV via Maesn/Chift, or direct for sevDesk/lexoffice)

• Billing (Stripe, Chargebee)

• Bank (via open banking aggregator like Finapi or GoCardless)

• CRM (HubSpot/Salesforce)

• HR/payroll (Personio)

• Product usage (if relevant for revenue/usage analysis)

• Expense/spend tools (Moss, Pleo)

Deliverable: raw data from all key sources landing in your warehouse on a daily schedule.

Step 3: Define Your Top 10 KPIs in Writing

A one-page document where each KPI has:

• Plain-English name (MRR)

• Precise definition - do it with AI: ask Claude for the standard definition of each metric and adjust it when needed

• Edge cases addressed (annual contracts → divide by 12; mid-month upgrades → prorated) - do it with AI: paste your specific situation and let AI surface edge cases you hadn't considered

• Source system (Stripe)

• Refresh cadence (daily)

Deliverable: a signed-off KPI definitions doc. Treat it like a constitution.

Step 4: Build the Metrics Layer

Step 3 gave you definitions on paper. This turns them into code that produces those numbers automatically, every day, identically for everyone who asks.

The tool: a semantic layer. This is what turns raw warehouse data into trusted KPIs. Two years ago this required dbt plus an analytics engineer; today, semantic layer tools have absorbed most of that work:

• Cube.dev — easiest, AI features built in, hosted. Default pick

• Lightdash — open-source, dbt-friendly

• Omni — polished, more expensive

The steps, done with AI:

• Map each KPI to your source tables. Paste your Step 3 definitions and warehouse schema into Claude. Ask which raw tables each KPI needs

• Generate the YAML definitions. Claude writes the Cube/Lightdash config for each metric — dimensions, filters, time grains. You review and adjust

• Handle the messy transformations. For anything the semantic layer can't do cleanly (multi-source customer unification, revenue recognition), AI drafts SQL views in your warehouse. These sit underneath the semantic layer

• Reconcile. Run each KPI and compare against your existing source of truth (board deck, Stripe dashboard, accounting reports). Paste mismatches back to Claude — it's good at spotting where the definition diverged

• Sign off. Once a KPI reconciles cleanly, that's the official number from now on

Deliverable: a working metrics layer where every KPI from Step 3 is computed automatically, tested, and reconciled. "What's our MRR?" now has one answer, available in seconds, identical for everyone.

Step 5: Layer AI Tools on Top (Ongoing)

Now and only now does AI tooling pay off cleanly. Possible use cases, prioritized by ROI for an early-stage finance team:

• Natural-language KPI queries. Cube has this built in; or wire your metrics layer to a Slack bot using Claude/OpenAI. The team asks "what was net new ARR last week by segment?" and gets answers without bothering you

• AI in Excel and Google Sheets - answer questions on your workbooks, suggest formulas, build pivots, clean messy data, reformat exports

• AI-powered dashboards - natural-language chart generation, auto-summarized insights, anomaly detection on visuals, "explain this dashboard" buttons for non-finance viewers. You design the metric; AI handles the visualization and interpretation layer

• Document extraction and summarization. Drop in vendor contracts, customer MSAs, term sheets, leases — AI extracts key terms (payment schedules, auto-renewal clauses, liability caps) and feeds them into your tracking sheets

• Auto-drafted variance commentary. Pull verified numbers from your metrics layer, hand them to Claude, get a draft commentary for your monthly review. You edit for tone and judgment calls

• Anomaly alerts. AI watches your KPIs daily and flags meaningful changes ("MRR dropped 4% week-over-week, driven primarily by 3 enterprise customers in past_due status — likely a dunning issue, not real churn")

• AI-drafted board reports and investor updates (verified numbers + AI narrative)

• Fully agentic finance workflows

• ML-based forecasting.

Deliverable: an AI layer that makes the data foundation visible and useful — to your team, your CEO, your board.

The Takeaway

If you've read this far, you probably came in expecting a list of AI tools to buy and ended up reading mostly about data infrastructure. That's the point.

The finance teams getting real leverage from AI right now aren't the ones with the most subscriptions or building fancy dashboards. They're the ones who put in the unsexy work first: a clean warehouse, signed-off KPI definitions, a metrics layer that gives one answer to every question. Then AI sits on top and makes everything visible, explainable, and fast.

A few principles worth holding onto:

• Data quality is the ceiling on AI value. Every hour you spend cleaning up customer records, agreeing on definitions, and reconciling sources compounds. Every AI tool you buy before doing that work delivers a fraction of its potential.

• Definitions before code. The Step 3 doc — your signed-off KPI definitions — is the single highest-leverage artifact in this whole sequence. It's where the real disagreements get surfaced and resolved, in a Word doc, where they're cheap. Skipping it just pushes them into Slack threads at 11pm before a board meeting.

• Build vs. buy is the wrong question now. The real question is: where in your stack do you want AI assisting you (writing your SQL, drafting your reports, auditing your models), and where do you want a vendor to have already solved it (AP automation, expense management, close orchestration)? Both are legitimate; neither is universally right.

• Start with one workflow, not ten. Pick the one that costs you the most time every month — usually variance commentary, close prep, or board reporting — and rebuild it end-to-end on the new foundation. Prove it works. Then move to the next.

• The technology gets cheaper and better every quarter. Your data foundation doesn't build itself. Two years from now there will be far more powerful AI tools available to finance teams. The teams that benefit most will be the ones whose data was already in shape to use them.

The end state isn't a finance team replaced by AI. It's a finance team that spends less time chasing numbers and more time interpreting them — closer to the business, faster on decisions, harder to surprise. That's the version worth building toward.