Stripe's New Agent Feature Can Explain Your Churn in Plain English. It Also Hands the Agent Two Different Ways to Calculate the Number.
Stripe's Nov 5 release lets Claude or Cursor query your billing data directly. Freeform SQL and Stripe's own MRR metric can give you different answers.
Stripe put out a short blog post on November 5 that's easy to skim past: connect an AI agent to your Stripe account, and it can build you a dashboard, reconcile a payout, or explain why revenue moved — all from a plain-English question. The examples in the post read like a wish list for anyone who's ever exported a CSV to answer a board member's question: "how did our new promotion affect revenue," "track MRR and attribute the change to upgrades, downgrades, churn, and reactivation," "find customers who clicked a button and later churned." That last one is explicitly called out as a churn-analysis use case in Stripe's own announcement. The catch isn't that the feature doesn't work. It's that Stripe gives the agent two structurally different ways to answer the same question, and only one of them is guaranteed to match the number already sitting in your Dashboard.
What actually shipped on November 5
The mechanism is a plugin that configures Stripe's Model Context Protocol (MCP) server for agents that support it — Claude, ChatGPT, Cursor, and anything else built on the standard. You sign in, grant three read-only permissions (Data > Metrics, Data > Queries, Data > Reports), and then just ask. The agent decides which Stripe tool fits your question and runs it, sometimes asking you to approve the call first. Stripe's own worked examples go well beyond a single metric: reconciling three months of payouts against payments, refunds, disputes, fees, and transfers in one pass; grouping failed payments by decline reason; setting up a Slack alert when fraud rates cross a threshold; exporting past-due invoices to Excel. It's a genuinely wide surface, and none of it required a developer to write an integration.
What makes this different from Stripe's earlier data tooling is the entry point. We've covered Stripe's Data Pipeline sync to a warehouse and its newer real-time Postgres destination — both of those are things a data team deliberately sets up once, then builds models on top of. This is the opposite shape: anyone on the team can type a question with no setup beyond the initial connection, and get an answer back in seconds. That's the whole appeal, and it's also where the risk sits — a deliberate warehouse build gets code review; a question typed into a chat window usually doesn't.
Three ways to ask, three different guarantees
Stripe actually ships three separate data products behind this one feature, and they don't all answer a question the same way. The agent picks one depending on how you phrase things, and it's worth knowing which one you're getting.
| Stripe data product | What it returns | Matches the Dashboard number? | Where it can diverge |
|---|---|---|---|
| Analytics API (metric_query) | Stripe-defined metrics — MRR, ARR, usage revenue — as a single JSON value | Yes, by definition | Only if Stripe revises a metric’s definition and your call is still pinned to an older metric version |
| Reports API | Prebuilt datasets — balance, payouts, activity, tax, revenue recognition — as CSV | Yes, same source Stripe uses internally | Doesn’t include a ready-made churn or MRR figure, just the raw rows behind one |
| Queries API (freeform SQL) | Whatever the SQL the agent writes computes, against raw reporting tables | No — only as accurate as that specific query | Test-mode rows, FX conversion timing, mid-cycle proration, usage-based line items, canceled-but-still-active subscriptions |
Compiled from Stripe's Analytics API and "Analyze your data with AI" documentation (Nov 2026).
The Analytics API is the safe lane. Ask it for revenue.mrr or revenue.arr by name and you get back the same number Stripe already computed for your Dashboard — because it's the same underlying metric, just exposed synchronously as JSON instead of rendered as a chart. The Queries API is the one that invites trouble, because a freeform SQL query against raw reporting tables is a brand-new calculation every time it runs. It's also, not coincidentally, the tool best suited to the exact kind of open-ended question people actually ask an agent — "why did churn go up" doesn't map cleanly to a single prebuilt metric, so the agent reaches for the flexible tool, which is also the one with no built-in guarantee of matching Stripe's own definition of anything.
Why "ask an agent" and "query the metric" aren't the same request
This isn't a hypothetical gap. Stripe's own documentation distinguishes the three products specifically because they solve different problems: the Analytics API for "a small set of prebuilt metrics on demand," the Reports API for "a bulk export of raw transaction data on a schedule," and the Queries API for "full SQL flexibility on top of your underlying data." Flexibility and correctness trade off against each other by design — that's not a bug Stripe needs to fix, it's the reason three separate products exist instead of one.
Churn math is a good example of where that trade-off bites. Computing a churn rate correctly from raw Stripe tables means handling subscriptions that are canceled but still inside a paid-through period, subscriptions that are paused rather than canceled, usage-based line items that zero out without a cancellation event, multi-currency accounts converted at a specific exchange-rate snapshot, and test-mode data that has to be filtered out before any of the real numbers mean anything. Our piece on logo churn vs revenue churn walks through how two technically correct formulas — one counting accounts, one counting dollars — can tell opposite stories from the same underlying cancellations. An agent writing SQL on the fly has to get every one of those edge cases right simultaneously, with no review step unless you add one yourself. Stripe's Analytics API sidesteps all of it because the metric definition is baked into Stripe's own systems, not reconstructed by whatever query got generated for your specific question that day.
The same gap shows up in Stripe's own NRR math. Our guide to net revenue retention benchmarks spells out the formula — starting MRR plus expansion, minus contraction, minus churn, divided by starting MRR — and it's exactly the kind of multi-step calculation that's easy to get subtly wrong in a one-off query: miscount which MRR change counts as "expansion" versus "reactivation," and the output still looks like a plausible percentage. Nothing about a wrong NRR number looks wrong on its face. It just looks like an NRR number.
Source: Hebbia, survey of 509 U.S. finance professionals (Mar 2026)
That second figure is the more interesting one. Almost two-thirds of finance professionals say they'd trust an AI tool over a human coworker to catch an error in a model — formula mistakes, broken links, inconsistent assumptions. Stripe's agent feature leans on exactly that instinct: ask it to check your own work, and it probably will, reliably. The gap is between checking a model for internal consistency and generating a brand-new number from raw data with no existing answer to check against. Those are different tasks wearing the same interface.
Where this actually matters for a cancel flow, not just a board deck
A wrong board-deck number gets caught eventually, usually by whoever has to defend it in the room. A wrong churn segmentation feeding a retention decision is quieter and more expensive, because nobody's job is to double-check it before it changes what you build next. If an agent-generated query miscounts which cancellations were voluntary versus payment failures, or double-counts a subscription that paused and resumed within the query window, the "insight" it hands back — "churn spiked among your annual customers last month" — can point an entire retention push at the wrong segment. Our guide to cohort retention curves covers how easy it is to get a directionally wrong signal from a technically-not-false calculation; an agent that's confident, fast, and wrong in a new way every time it's asked makes that failure mode easier to hit, not harder.
None of this is a reason to skip the feature. Stripe built in the right safeguard — every query the agent runs can be inspected and edited, which is more transparency than a human analyst's mental math ever offers. The practical fix is just to use that safeguard on purpose, not treat it as optional:
- Ask for the named metric, not the calculation. "What's our MRR" routed through the Analytics API beats "sum up all the active subscription amounts," because the first one can't drift from your Dashboard and the second one is a fresh SQL query every time.
- Treat Queries API output as a first draft. When the question genuinely needs freeform SQL — segmenting churn by a custom field, joining billing against product usage — ask to see the query before you act on the number, not after someone asks where it came from.
- Spot-check one period against the Dashboard. Before you trust an agent-built churn dashboard for a full quarter, pick one month and confirm it against the number Stripe's own Dashboard already shows. One match doesn't prove every month is right, but one mismatch tells you immediately that something in the query needs fixing.
- Keep test-mode data out of the question entirely. If your Stripe account has any sandbox or test-mode history, say so explicitly when you ask — a freeform query has no instinct for which rows were never real revenue.
The upside of connecting an agent to your billing data is real — most of Stripe's own examples, like reconciling a quarter of payouts or flagging a spike in a specific dispute reason, are tasks that used to eat an afternoon and now take a prompt. Churn specifically is just a worse category to freelance on than most, because the moment you act on a wrong number here, the action is a retention offer shown to the wrong subscribers, or a feature built for a segment that was never actually the one leaving. If you're already running a cancellation flow, the one number you don't want built on a shaky query is the cancel-reason breakdown feeding your save offers — that data is worth getting right before any agent touches it, and our churn calculator is a fast way to sanity-check whatever figure comes back against the math you already trust.
Frequently asked questions
What is Stripe's new AI agent feature for analyzing billing data?+
Announced on Stripe's blog on November 5, 2026, it's a way to connect an AI agent — Claude, ChatGPT, Cursor, or any client that supports the Model Context Protocol — directly to your Stripe account's analytics data. Once connected, you can ask it things like "why did revenue change this quarter" or "build a dashboard explaining our churn," and the agent picks the right Stripe tool (Metrics, Reports, or a freeform SQL query) to answer. Stripe says the Queries API is free for all users through January 31, 2027, and the Reports API stays free permanently.
Does an AI agent's calculated MRR or churn rate match the number on Stripe's own Dashboard?+
Only if it asked for the number the right way. Stripe's Analytics API returns Stripe-defined metrics — the exact same MRR, ARR, and usage-revenue figures shown on your Dashboard — as a single JSON value. The Queries API instead runs freeform SQL against your raw reporting tables, and a query the agent writes on the fly can sum subscription amounts differently than Stripe does internally: it can miss proration adjustments, mid-cycle plan changes, multi-currency conversion timing, usage-based line items, or test-mode records that need to be explicitly excluded. Both numbers are technically correct answers to different questions; only one of them matches what your board deck already says.
Is Stripe's new Queries API free?+
Yes, through January 31, 2027. Stripe's blog post announcing the feature states usage-based pricing begins February 1, 2027, charged per credit of API usage with no monthly subscription fee. The Reports API, which returns prebuilt datasets rather than freeform queries, remains free on an ongoing basis.
Can I see what SQL or calculation the AI agent actually ran against my Stripe data?+
Yes — Stripe's announcement specifically notes that every analysis the agent produces can be checked by inspecting the underlying SQL, and you can edit that query yourself if something looks off. That transparency is the actual safeguard here, but it only works if someone on your team is the kind of person who checks. Most people who ask an agent "why is churn up" are asking because they don't want to write the SQL themselves, which is exactly when the inspection step tends to get skipped.
Stop losing subscribers today
One script tag. One function call. A live cancellation flow in under 10 minutes.
Start free trial →