3 examples of what you can do once your Stripe data is in a data warehouse

Michael Pirumov
By Michael Pirumov
4 min read
Stripe data flowing into BigQuery and Claude, then into collections emails, mismatch review, a NetSuite queue and change alerts.

Maybe at some point during your career you had to deal with a bunch of spreadsheets from Stripe and frankenstein a report. Or you needed to export Stripe invoice line items (which I still don't know how to do without Sigma). What I came across years back are tools called Fivetran and Airbyte - they actually move almost all of the data from Stripe into your data warehouse.

From there, with a little bit of SQL or some Claude tokens - you can build any report you want without any limits, as long as you can figure out the business logic.

You could technically use the Stripe MCP in Claude for this, but you'll eventually hit a wall if you want to build on large chunks of data or make large reports. The Stripe MCP is great for quick lookups - but if it needs to download large tables, join them and then produce reports repeatedly: one, you are going to burn a lot of tokens, and two, it's going to be slow and not scalable - at least for now.

1. A daily past-due list by customer

For example, you can have a daily AR aging report by customer. Stripe does not make this easy, unless you pay for Stripe Revenue Recognition. Even then, its data runs about 3 to 4 hours behind. Comparing one day to the next is even harder.

Here is how we use the warehouse with customers. Every morning we get a list of who we need to reach out to. The list is always up to date, so you are not exporting to Excel and fixing it later. The data is as fresh as your Fivetran sync allows.

Here is the AR aging report in BigQuery. It has one row per customer and how much sits in each aging bucket.

A BigQuery table of open Stripe invoices with one row per customer and the amount in each aging bucket.
The AR aging report in BigQuery, one row per customer (demo data).

Every morning we ask Claude for all past-due invoices with their Stripe payment links, grouped by customer.

You can chart it too. This is the total in each bucket.

A bar chart in BigQuery of the past-due total in each aging bucket: not due, 1-30, 31-60, 61-90 and over 90 days.
Total past due in each aging bucket (demo data).
Bonus tip

Claude can draft the emails too. Here is a prompt to start with:

@Claude Which customers do we need to follow up with for payment? List each one with their unpaid invoices and draft a follow-up email for each.

Here is the ask in Slack.

A Slack message asking Claude which customers need a payment follow-up.
The ask in Slack.

And then Claude posts the list back, grouped by customer, so we're not sending three emails to the same person.

Claude's Slack reply listing unpaid Stripe invoices grouped by customer, with amounts and days past due.
Claude's list, grouped by customer (demo names).

For the straightforward cases, I just asked it to draft the follow-up emails.

A Slack message asking Claude to draft the follow-up emails.

And it put the drafts right in Gmail, one per customer with the pay links, so all we do is look them over and hit send.

Gmail drafts folder with one past-due reminder per customer, each with Stripe pay links.
One Gmail draft per customer, with the Stripe pay links.

2. Stripe vs your books, showing only mismatches

I'm sure it probably happened to you at some point: you sent a follow-up email to a customer that already paid the invoice, and they wrote back, "I ALREADY PAID THIS INVOICE."

That typically happens with checks or wires. Depending on whether you record it first in NetSuite or Stripe, those two systems could be out of sync, even with a Stripe <> NetSuite integration. If Stripe doesn't have it marked paid, it can keep sending reminders, and your team might keep following up even if everything's paid.

For that, you can set up a way in BigQuery to check your Stripe and NetSuite records - compare all the invoice statuses before you send out follow-up emails.

A BigQuery query comparing Stripe and NetSuite invoices, showing two invoices paid in NetSuite but still open in Stripe.
Only the mismatches: paid in NetSuite, still open in Stripe (demo data).

If you're using Claude to draft your emails, on top of that, you can ask it to check your NetSuite data before it even drafts the emails.

Claude in Slack flagging two invoices that are paid in NetSuite but still open in Stripe.
Claude checks NetSuite before it drafts.

3. Catching late payers before they're late

One of the more interesting use cases we found is catching late payers before they become late payers. If a customer keeps paying late based on their past payment dates, you can take a few steps:

  • Prioritizing them
  • Reaching out to them early, before the due date
  • Giving them an extra call

Signals to watch:

  • Customers who pay late each month
  • Repeat card declines
  • Partial payments with open balances
  • Invoices with no card on file
  • Past chargebacks
  • Prior past due invoices
Claude in Slack listing customers with a late-payer score of High, Medium or Low and the signals behind each score.
A late-payer score built from those signals (demo names).

How the data gets there

There are many ways to get information from Stripe into BigQuery. There are things like Stripe's own Data Pipeline, which connects directly to Snowflake, BigQuery and Redshift. Stripe also works with Airbyte, Fivetran, and many other ETL tools.

An Airbyte connection syncing Stripe to BigQuery, with the sync history.
Stripe to BigQuery with Airbyte.

I personally just like using Airbyte because it's pretty cheap and straightforward to set up. I like using Fivetran if I need something a little more real time. I know some people don't like Fivetran, but it's been pretty easy for me to use. There are probably dozens of other tools that do this as well. Some may be better, but that's what I use.

Needless to say, give your Claude read-only access to Stripe, so it doesn't start changing things in Stripe without an approval process.


Get new posts by email

Share this articleLinkedInX

About the author
Michael Pirumov

Michael Pirumov

I run Let's Ledger, an accounting firm in Brooklyn. My team works with companies that have a large volume of transactions. I've worked in accounting and finance operations since 2014 and have an M.S. in Accounting from Baruch College.

LinkedIn profile