Best Practices

Filter by date range for large accounts

If you have years of transaction history, always set a Created after date. Pulling all-time data in one run is the leading cause of timeouts. Start with the last 90–180 days and expand from there.

Use Subscriptions with line items for MRR reporting

The standard Subscriptions entity doesn't include plan-level detail. Use Subscriptions with line items when you need to break down revenue by plan tier, add-on, or billing interval.

Set the Status filter for subscriptions

The Subscriptions entity defaults to active only. If your report needs to include churned customers or trials, explicitly set the Status parameter — otherwise you'll silently miss canceled and past_due records.

Divide amounts by 100 in your destination

All Stripe amounts are in the smallest currency unit (cents). Add a calculated column in Google Sheets or a transformation in BigQuery to divide by 100 before building any charts or reports.

Combining Stripe entities

Reconcile payouts with a Join

Add both Payouts and Balance transactions to the same data flow, then use the Join transformation on the payout ID. This is the only reliable way to see which individual charges and fees make up a given bank deposit.

Append charges from multiple Stripe accounts

If you operate multiple Stripe accounts (e.g., for different regions or brands), add each as a separate source in one data flow and use the Append transformation. You'll get a unified charges table without manual copy-pasting.

Join Customers to Subscriptions for CRM reporting

Join on the customer ID field to add email, name, and metadata from the Customers entity to your subscription records. This makes it easy to build customer-level MRR and churn reports.

Common pitfalls

triangle-exclamation

Do

  • Filter by date range to avoid timeouts on high-volume entities

  • Set the Status parameter explicitly for Subscriptions

  • Use the Balance transaction type filter to pull only the transaction types you need

  • Use UTC-aware date boundaries when setting date range filters

  • Use Subscriptions with line items when you need plan-level MRR detail

Don't

  • Assume the Subscriptions entity returns all statuses by default

  • Use raw Stripe amounts in charts without dividing by 100

  • Try to reconcile payouts manually — use a Join with Balance transactions instead

  • Pull Events without an event type filter — the full event log grows quickly and will slow your runs

Last updated

Was this helpful?