Get an Excel workbook into BigQuery without a script.

When the source of truth is a workbook

Someone in ops keeps the real numbers in Excel. A vendor sends a workbook with three sheets and a header row that isn't quite where you'd expect. Before that data is useful for anything past a single meeting, it has to land in BigQuery next to everything else you already query. Google Sheets sync covers the spreadsheet case; this is the same problem for an actual .xlsx file sitting on someone's Mac.

Before you start

• An Excel file and a BigQuery connection, both added under Databases.
• Pipelines tier. Data Sync isn't part of Studio.
• Know which sheet and header row you need if the workbook has more than one tab.

Steps

1. Add the file as a connection: click the + next to Databases and pick CSV/Excel, then select the workbook and sheet.
2. Open Pipelines → Build and click New Sync.
3. On the left, pick the Excel connection as your source.
4. On the right, pick your BigQuery connection and the target table, or create one.
5. Drag columns across, or click AI Map to pair them by name.
6. Pick a MODE: Insert for a fresh load, Update or Upsert if rows already exist and you're refreshing them.
7. For Update or Upsert, set a MATCH ON field, a column that's unique per row.
8. Click Dry Run, check the preview, then Save or run it now.

A worked example

A quarterly budget workbook, one sheet per department, needs its Actuals tab loaded into a shared BigQuery table finance already queries from:

-- target table
CREATE TABLE IF NOT EXISTS `my-gcp-project.finance.dept_actuals` (
  department STRING,
  cost_center STRING,
  actual_spend NUMERIC,
  period DATE
);

Map the sheet's Dept, Cost Center, Actual and Month columns to department, cost_center, actual_spend and period. If this is the first load, set MODE to Insert. If finance sends a corrected workbook later in the month, switch to Upsert with MATCH ON set to cost_center plus period so a resend replaces the old numbers instead of doubling them.

Check it worked

Dry Run shows exactly what would write before anything does. After a real run:

SELECT department, SUM(actual_spend) AS total
FROM `my-gcp-project.finance.dept_actuals`
GROUP BY department
ORDER BY total DESC;

and check that against a quick sum in the workbook itself. A mismatch usually means a header row got picked up as data, or a merged cell in the sheet left a blank the sync read as null.

Troubleshooting

What this doesn't do

This reads a workbook as it exists at the moment you sync it. It doesn't watch the file for changes or reopen it automatically when someone edits and re-saves. If the workbook gets replaced on a predictable schedule, save the sync as a job and swap in the new file before each run; if it needs to reflect edits the instant they happen, a live Google Sheet is the better source, not a static Excel file.

When to switch to Google Sheets instead

If the same people keep editing this workbook by hand every week, moving it to Google Sheets and syncing from there directly cuts out the file-handoff step entirely, since QueryFlow can read a live sheet instead of a new file export each time. Excel still makes sense when the file genuinely is the deliverable, like a report a vendor hands you as-is.

Handling a workbook with more than one useful sheet

A single Excel connection points at one sheet at a time. If a workbook has separate tabs per region or per department that all need to land in BigQuery, add a separate file connection for each sheet you need, pointing at the same underlying file, and build one sync per tab. It's more setup up front than a single all-in-one load, but each sync stays simple to read and debug on its own, rather than one large sync trying to branch logic based on which tab a row came from.

A note on numeric precision

Excel stores numbers as floating point internally, which occasionally introduces tiny rounding differences that only show up once the data lands in BigQuery's NUMERIC type and gets compared against a source system's exact figure. For anything involving money, round explicitly in the mapping or in a downstream query rather than trusting that a spreadsheet's displayed value and its stored value are always identical.

Related syncs

See also: Integrations Load a CSV into BigQuery on Mac Sync Databricks to BigQuery.