Spreadsheet to dbt Migration: Move Finance Logic Into SQL

A spreadsheet to dbt migration means moving the calculations your business depends on out of cell formulas and into version-controlled, tested SQL models in your data warehouse. The safe sequence is to rank your spreadsheets by the damage a wrong number would cause, rebuild the highest-risk logic as dbt models, run both side by side until the outputs match, and only then retire the sheet. Done this way, you don't lose the flexibility finance and operations teams like about spreadsheets. You gain tests, history and a single definition of each metric.

Most founders and CTOs we speak to already know they have a spreadsheet problem. What they don't have is a safe way out of it. Nobody wants to be the person who replaced the treasury workbook the week it was needed for a board pack. So the sheet stays, grows another tab, and becomes more load-bearing every quarter. This guide covers how we approach a spreadsheet to dbt migration in practice: what to move first, how to prove the new numbers are right, and where migrations tend to go wrong.

Why Do Critical Business Processes Still Live in Spreadsheets?

Because spreadsheets are the fastest tool for the first version of anything. A finance lead needs a reconciliation view on Tuesday, and a sheet gets it done by Tuesday. The trouble is that nobody schedules the day the sheet gets replaced, so the prototype quietly becomes production.

The scale of this is well documented. The 2025 AFP FP&A Benchmarking Survey, fielded in autumn 2024 among 362 practitioners, reports 96% using spreadsheets for planning and 93% for reporting. A 2025 bluQube survey of 700 finance and business leaders found that 40% of businesses still manage up to half of their financial data manually. This isn't a small-company habit. It is how finance runs almost everywhere.

The accuracy problem is just as well documented. A 2024 literature review in Frontiers of Computer Science concluded that 94% of spreadsheets used in business decision-making contain errors. A 2026 DOSS survey of 1,003 U.S. operations professionals found that 22% deal with spreadsheet errors every day, and the average person spends 3.6 hours a week fixing them. The same research puts the average cost of a single significant error at $4,315. That figure comes from US operations teams, so treat it as a directional benchmark rather than a number to plug into your own model.

The cost that matters more at Seed to Series B stage is harder to put a figure on: nobody trusts the number. A pattern we see repeatedly in our work with early-stage companies is a critical calculation that lives in one person's workbook, with formulas nobody else fully understands, fed by CSV exports pasted in by hand. The sheet works until that person goes on leave, someone sorts a single column, or a source system changes its export format. The failure is silent. The sheet doesn't crash. It returns a confident, plausible and wrong number.

---

📺 Watch: dbt Cloud to dbt Core: Fast Migration Guide (2026)

---

Which Spreadsheets Should You Migrate First?

Not all of them, and not in the order people expect. The loudest complaint usually points to the wrong sheet. We rank candidates on four factors and migrate the highest scorer first.

1. Blast radius. What breaks if this number is wrong by 5%? A sheet feeding capital allocation, investor reporting, customer payouts or regulatory returns outranks a sheet feeding an internal weekly stand-up.

2. Hand-offs. How many people or teams copy numbers out of this sheet into another? Every hand-off is a place where a figure can be re-keyed, rounded differently or taken from the wrong version.

3. Manual inputs. How much of the sheet is pasted exports or typed figures? Manual inputs are where the errors come from. DOSS found manual data entry mistakes were the most common error, followed by formula errors.

4. Change frequency. A sheet that is edited weekly is a bigger risk than one untouched for a year. Frequent edits mean frequent chances to break something.

Score each from 1 to 5 and add them up. In practice, one or two sheets stand out immediately, and they tend to be the ones people already describe as scary to touch. Leave the rest. Some spreadsheets are fine as spreadsheets. A one-off scenario model for a board discussion doesn't need to be a dbt model.

A global fintech we worked with had a capital reconciliation process spread across several linked workbooks. It scored high on all four factors, so it went first. Once the logic was rebuilt in SQL and checked against the source ledgers, it surfaced a $25M discrepancy that had gone undetected. At market borrowing rates, that gap was costing over $6,000 per day. The spreadsheet had been producing a number for months. It just wasn't the right one.

How Does a Spreadsheet to dbt Migration Work, Step by Step?

This is the sequence we follow when we replace Google Sheets with SQL in a client's BigQuery environment. The tooling matters less than the discipline, and the discipline that matters most is proving parity before you cut over.

Step 1: Document what the sheet actually does

Before writing any SQL, sit with the sheet's owner and trace every output back to its inputs. Most workbooks contain three kinds of content mixed together: raw inputs, intermediate calculations, and presentation. Separate them on paper first. You will almost always find dead tabs, hardcoded overrides and formulas that nobody can explain. Write down each one and ask the owner whether it is intentional. This step is where the hidden business rules come out, and it is usually the longest conversation of the project.

Step 2: Land the raw inputs in the warehouse

The sheet's inputs need to arrive in BigQuery or your warehouse automatically, not through a person pasting exports. Source-system data should come through your ingestion pipeline. Where an input genuinely has to be maintained by a human, such as a list of provider fee tiers, we handle that differently, which the next section covers. If your first instinct is to connect a Google Sheet as an external table, read our note on <a href="https://blog.fintel-analytics.com/blog/bigquery-external-tables-as-dbt-sources-the-hidden-traps">the hidden traps of BigQuery external tables as dbt sources</a> first.

Step 3: Rebuild the logic in layers

Translate the workbook into the standard dbt layering, not a literal tab-by-tab copy. Staging models clean and type the raw inputs. Intermediate models hold the business logic, one concept per model. Mart models produce the final tables the business reads. The point is that each formula chain becomes a named, testable step. Repeated spreadsheet formulas, such as a fee calculation that appears in forty cells, become a single macro or function. If you are deciding between the two, we compare them in <a href="https://blog.fintel-analytics.com/blog/dbt-macros-vs-persistent-sql-udfs-in-bigquery-choose-right">dbt macros vs persistent SQL UDFs in BigQuery</a>.

Step 4: Add tests that encode what the owner knows

This is where migration pays back fastest. Every instinct the sheet owner has, such as this total should never be negative, every transaction must have a currency, these two ledgers must net to zero, becomes an automated test. Plain-language rules turn into checks like this:

models:
  - name: fct_daily_reconciliation
    columns:
      - name: transaction_id
        tests: [unique, not_null]
      - name: currency_code
        tests:
          - not_null
          - accepted_values:
              values: ['USD', 'EUR', 'GBP']

In a spreadsheet, the owner's judgement is the only test. In dbt, it runs on every build whether or not that person is in the office.

Step 5: Run in parallel and reconcile

Run the old sheet and the new models side by side for at least one full business cycle, which for finance usually means a month-end. Compare outputs line by line and classify every difference as either a bug in the new model or an error in the old sheet. Expect both. Don't cut over until every remaining difference has an explanation that the sheet owner has signed off. This is the step that builds trust. When the owner can see the new numbers matching theirs, and the differences explained, resistance tends to disappear.

Step 6: Retire the sheet deliberately

Archive the workbook as read-only, point every consumer at the new dashboard or table, and remove edit access. If you leave it editable, someone will use it again within a month.

If you're looking to run this kind of migration in your organisation, explore how Fintel Analytics approaches this. We work with businesses globally to design and deliver exactly this kind of spreadsheet-to-semantic-layer rebuild on BigQuery, dbt and Holistics.

What Do You Do With Inputs That Humans Still Have to Type?

This is the question that stalls most migrations. Some data really does start with a person: negotiated fee schedules, manual adjustments, budget targets, risk limits. Removing the spreadsheet doesn't remove the human.

The mistake is keeping the free-form sheet as the input. A better pattern is a controlled input table with validation at the point of entry. There are three workable options, depending on how often the data changes:

Rarely changing reference data (a few times a year): keep it as a dbt seed in version control. Changes go through a pull request, so every edit is reviewed and has an author and a date.

Occasionally changing data (weekly or monthly): use a restricted input table fed by a form or a locked sheet with data validation, loaded to a raw layer. Then run dbt tests on it for accepted values, no duplicates, valid date ranges and no missing keys. Reject or flag failing rows rather than silently loading them.

Frequently changing operational data: this usually shouldn't be keyed by hand at all. Find the system of record, such as your billing platform, PSP or ledger, and ingest from there.

The goal isn't to stop people entering data. It is to make a wrong entry fail loudly instead of flowing quietly into an executive report. The same applies to credentials: if your sheet connection depends on a downloaded key file, check our guide to <a href="https://blog.fintel-analytics.com/blog/bigquery-service-account-key-in-dbt-repo-find-fix-it">finding and fixing a BigQuery service account key in a dbt repo</a> before it ends up in version control.

What Does a Spreadsheet to dbt Migration Actually Deliver?

The benefits fall into three groups: speed, trust and capacity. These are anonymised outcomes from our delivery work.

Speed. A reconciliation process at a Series A payments company took 30 to 50 minutes to run each cycle. We rebuilt it as an automated SQL pipeline, and it now completes in under 3 seconds. That is not just a time saving. Something that takes 40 minutes gets run once a day, if at all. Something that takes 3 seconds can run continuously and feed alerting.

Trust. Weekly executive reporting at one client required 90 minutes of manual work every week. It was replaced by a live dashboard with zero manual effort, updated hourly. The numbers on that dashboard come from the same models that finance and operations both use, so the old argument about whose figure is right goes away. That is what a single source of truth means in practice: one definition, owned in one place, in your semantic layer.

Capacity. Moving calculations from spreadsheets into dbt models at another client eliminated a class of recurring manual errors and cut weekly maintenance time by 30 minutes. That sounds small, but it is 30 minutes of a skilled finance person's week, recovered permanently, with the errors gone as well.

There is also a compounding effect on risk. When a treasury team we worked with moved from sheet-based monitoring to automated alerting on provider risk, they had real-time visibility for the first time. It reduced funding misses and gave leadership a quantifiable measure of capital efficiency. None of that was possible while the logic sat in a workbook that someone had to open and refresh.

One caution on expectations: migration will not make your data correct by itself. It makes your data's problems visible. Expect the first few weeks of tests to fail on issues that were always there. That is the system working, not the project going badly.

What Are the Most Common Migration Mistakes?

Copying the sheet literally. Recreating forty tabs as forty models preserves every bad design decision. Rebuild the logic around business concepts, such as transactions, balances and fees, not around how the workbook happened to be laid out.

Skipping the parallel run. Teams under time pressure cut over after a quick spot-check. Then a discrepancy appears in a board pack and the new system takes the blame, even if the old sheet was wrong. A full-cycle parallel run protects the project's credibility.

Migrating without the owner. The person who built the sheet holds the business rules. If they are not involved, the new models will be technically clean and commercially wrong. Make them the acceptance tester, not a bystander.

Forgetting the output layer. Finance doesn't want a table in BigQuery. They want something that looks and behaves like what they had, with filters and drill-downs. Plan the dashboard in your BI tool alongside the models, or adoption stalls and people drift back to exporting CSVs.

Letting the new thing go ungoverned. Without ownership, documentation and test coverage standards, a dbt project becomes the next spreadsheet, just with more syntax. Agree who owns each model and what must be tested before it goes to production.

Frequently Asked Questions

Q: What is a spreadsheet to dbt migration?

A: It is the process of moving business calculations from spreadsheet formulas into version-controlled, tested SQL models built with dbt in a data warehouse such as BigQuery. The outputs are then served through a BI tool or semantic layer. The goal is to replace manual, error-prone processes with automated pipelines that have tests, documentation and a full audit trail.

Q: How long does a spreadsheet to dbt migration take?

A: For a single business-critical workbook, expect roughly four to eight weeks including discovery, rebuild and a full-cycle parallel run. Length depends on how tangled the logic is and whether the input data already lands in your warehouse. Trying to migrate everything at once is the main reason projects overrun.

Q: Can you replace Google Sheets with SQL without disrupting finance?

A: Yes, if you run the old sheet and the new models in parallel for a full reporting cycle before cutover. Finance keeps working from the familiar sheet while the new models are validated against it. Only when every difference is explained and signed off do you switch the consumers across.

Q: Which spreadsheets should a startup migrate first?

A: Start with the sheet where a wrong number would do the most damage, especially one with multiple hand-offs, manual inputs and frequent edits. Capital, treasury, reconciliation and investor-reporting workbooks usually come first. Low-risk, one-off analysis models can stay as spreadsheets.

Q: Do you still need spreadsheets after moving to dbt?

A: Yes, for ad-hoc analysis and scenario modelling, which is where they are strongest. What changes is that the inputs to those analyses come from governed warehouse tables, not from pasted exports. Spreadsheets become a consumer of trusted data instead of the place where the trusted data is made.

The Bottom Line

The challenge most growth-stage teams face isn't deciding that spreadsheets are risky. It is finding a migration path that doesn't put this month's close or next month's investor update at risk. At Fintel Analytics, we have helped fintech, payments and e-commerce businesses do exactly that: from auditing the workbooks that carry real risk, through rebuilding them as tested dbt models on BigQuery, to delivering the live dashboards that replace the manual reporting. Every week a critical calculation stays in a sheet is another week you are trusting a number nobody can fully verify, and fixing that costs far less than the first discrepancy you don't catch.