Best Practices
Recommended setup
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
Pulling all-time data on large accounts will cause timeouts. Always use date range filters for entities like Charges, Invoices, and Balance transactions if your account has significant transaction volume. Narrow the window first, confirm the run succeeds, then adjust.
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?
