Stripe is widely used for capturing payments, subscriptions, credits, and refunds with precision.
But if you want to use data from Stripe to get better insights into operational questions like revenue health, customer usage, and routine finance reviews, it is anything but easy.
The data is readily available, but it's spread across events, schemas, and identifiers that make consistent analysis hard to share across teams.
To solve this, we built a custom lightweight pipeline that pulls billing data from Stripe, normalizes it using n8n, and outputs a shared dataset in Google Sheets. We wanted to share how we did it, including some unexpected challenges and solutions.
How we turned billing events into something usable
Stripe billing events arrive with different schemas, timing semantics, and identifiers. Revenue figures depend on grouping decisions that are rarely obvious and often context-dependent. Even minor inconsistencies in how records are joined or filtered can introduce uncertainty and slow down analysis.
For finance and operations, this means time spent verifying these numbers before they can be used with confidence. When you're trying to answer questions like "Did our Q3 promotion actually drive renewals?" or "What's our effective revenue per customer this month?", you need more than raw event logs.
Instead of starting with a polished dashboard, we focused on producing an output that could be closely examined and reconciled when questions came up — a set of flat tables in Google Sheets with one row per charge, normalized across Stripe's event schema. That led to a simple, inspectable internal pipeline built around three tools: Stripe's Search API as the data source, n8n to handle orchestration and normalization, and Google Sheets as the shared output.
With Stripe as the system of record for billing events, we used n8n automations to handle orchestration, normalization, and aggregation. Google Sheets served as the final output, which was intentionally straightforward and easy to inspect.
The aim here was not to automate everything or to present a refined interface. It was to establish a repeatable process that turned raw events into a shared reference point. The resulting tables were easy to review, easy to question, and easy to trace back to their sources.
This approach gave us something valuable: transparency. If someone questions a number or revenue event, we could walk through the exact transformations that produced it.
Where most of the effort actually went
Most of the work went into deciding how events should be grouped and reconciled once they entered the pipeline.
Questions about what constitutes a new customer, how credits should be counted over time, or which identifiers reliably link records across systems all carried practical implications. These decisions sit at the intersection of business logic and technical implementation, and they tend to surface first as engineering problems.
For example, a customer might have multiple Stripe customer IDs due to account changes or migrations:
- Do you treat these as separate entities or consolidate them?
- What happens when a subscription is paused and resumed?
- How do you attribute credits that were issued in one period but consumed in another?
Using n8n helped make these choices visible. The workflow showed how data moved through each step, where it was transformed, and how intermediate results were combined. That visibility made it easier to reason about the output and adjust it as requirements evolved.
What this solution enables for our team
Now, our teams can start conversations from a shared set of numbers without revisiting how those numbers were produced. Finance can review revenue trends. Operations can look at promotion usage and customer behavior patterns. Engineering can trace specific figures back through the workflow when questions arise.
This reduces friction in routine analysis and shifts more attention toward decisions rather than validation. Instead of spending meeting time debating whether a number is correct, teams can focus on what that number means and what actions to take.
The system also makes it easier to spot anomalies early. When the data pipeline runs daily, irregular patterns become visible quickly, whether that's an unexpected spike in refunds or a drop in credit consumption. In our case, the pipeline surfaced that payments from enterprise customers were never appearing in our internal records at all — they had been added as credits manually, leaving no payment trail.
What we haven't solved yet
The pipeline handles charge-level reconciliation well, but there are gaps we haven't closed yet.
We still can't cleanly attribute revenue when a customer upgrades mid-cycle. The pipeline captures charge-level data from Stripe, but it doesn't map charges back to the subscription state at the time of payment, so tier-level breakdowns still require manual reconciliation.
On the workflow side, n8n has no concept of workflow dependencies. When we added a column to normalize subscription types, a downstream workflow started failing silently because it expected a row that no longer matched. We caught it by hand.
If we were starting this today, we'd wire up error alerting on day one. The Slack alerts channel for n8n went live two weeks after the pipeline did. Failures in that window went unnoticed.
The mapping between billing events and business questions is engineering work. If it's explicit, the pipeline holds up. If it's not, you're back to quarter-end spreadsheet reconciliation.
