Question 1

Which Stripe objects can I load into BigQuery?

Accepted Answer

The parts of Stripe people actually report on: customers, subscriptions and subscription items, invoices and invoice line items, charges, payment intents, payment methods, refunds, disputes, credit notes, coupons, discounts, products, prices, plans, balance transactions, payouts and events. Between them that covers recognised revenue, failed payments and churn, which is most of what finance and growth teams come asking for.

Question 2

How does Stripe metadata land in BigQuery?

Accepted Answer

As a native record on current connections, so the custom keys your application writes into Stripe metadata stay queryable with dot notation rather than being flattened or dropped. This is one of the nicer things about BigQuery as a target for Stripe, since metadata is often where your own identifiers live. Connections made before a 2024 change write structured values as JSON instead, which still works but reads differently in SQL.

Question 3

Are Stripe amounts converted to currency units?

Accepted Answer

No, and it is deliberate. Stripe holds amounts as integers in the smallest currency unit, so a ten pound charge is 1000, and that is exactly how it arrives. Dividing is a modelling decision you make downstream where you can also handle currencies with different minor units. Timestamps become proper timestamp columns, so date filtering and partitioning both work normally.

Question 4

Can I backfill full Stripe history into BigQuery?

Accepted Answer

Yes. The first run pages through each object from the beginning rather than starting on the day you connected, so historic invoices and charges come across. That matters more for Stripe than for most sources, because revenue analysis is inherently backward looking and a billing dataset that starts this month is useless for cohort or retention work. After that, incremental runs use Stripe events for the objects that emit them and page the rest.

Question 5

Why load Stripe into BigQuery?

Accepted Answer

Because revenue questions nearly always need a join. Connecting subscription changes to product usage, or failed payments to support tickets, needs billing data sitting beside everything else. Stripe reports on Stripe and knows nothing about the rest of your business. Once ETL has landed it in a data warehouse you can model revenue to your own definitions rather than accepting whatever the dashboard decided, and keep a history that does not move.

Sync Stripe to BigQuery

Sync Stripe to BigQuery with Polytomic

Metadata keeps its shape

Full history on first run

The whole billing picture

Or sync BigQuery to Stripe

Trusted by businesses worldwide

Step-by-step integration guide

Connect Stripe in Polytomic

Connect BigQuery in Polytomic

Create a sync between Stripe and BigQuery

Map fields and enable the sync

Frequently asked questions

The sync and ETL platform that does it all

Powerful data sync

Advanced analytics

Enterprise security

Easy setup

Ready to connect Stripe with BigQuery?