Your pricing refresh cannot start until someone knows what is actually in the Stripe account, and right now nobody does. It grew by accretion: a product named "Test product (DO NOT USE)" that you suspect something still bills against, prices nobody remembers creating, and customers whose descriptions were last true in 2023. The prices multiply on their own: Stripe never lets you edit a price's amount, only supersede it, so every adjustment since launch left the old object behind. Nobody broke it. Accounts that take real money for years all end up like this. The census itself is what blocks you: Stripe gives you no single view where the junk announces itself, and clicking through the Dashboard list by list is the project everyone keeps not starting.
The fix is to stop running the audit inside Stripe. Pull every customer, product, price, subscription, and invoice down as local files, point the AI agent you already use at the folder, and let it run the census: orphaned prices, duplicate products, naming drift, empty metadata, each finding with the record IDs attached. You get a report, not a changed account. The fixes still happen in Stripe, by your hand, and on this page that is the feature, because the AI in this loop never holds a key to your billing at all.
Your options for the census
Clicking through the Dashboard
For the fixes, the Dashboard is the right place, and this page will keep saying so: a customer page shows that customer's subscriptions and invoices together, and archiving a product is 2 clicks. As a census tool it is the project that never finishes. Lists page along slowly, the filters are built for support lookups rather than audits, there is no bulk archive for products or prices, and the cross-object questions, which prices nothing references, which products are near-duplicates, are not questions a list view can ask. You end up with 30 tabs and a notes file. That is counting traffic from the roadside.
Stripe Sigma and SQL
Stripe Sigma is read-only SQL over your Stripe data, inside the Dashboard, with scheduled queries, and read-only is the right posture for an audit. If you live in SQL, it will find your orphaned prices. Three limits matter here. It is a paid add-on in live mode, priced by charge volume, starting around $10 to $15 a month and climbing from there; sandboxes are free, and there is a 30-day trial. Most tables run about 3 hours behind, some derived ones far longer. And SQL stops at the rows: it can list 2 products with similar names, but it cannot tell you they are the same product after 4 years of drift. That call needs a reader.
CSV exports and a spreadsheet
Free and familiar, and for a one-object question, say how many customers have no description, a sort and a filter get you there. The audit is a cross-object job, and that is where this route thins out. Stripe's exports grew up around payments, and the edges show: customer CSV exports leave metadata out unless you name the exact fields you want, key by key, and knowing which keys exist is the question the audit was supposed to answer. The joins are yours to rebuild, prices to products, subscriptions to prices, file by file, lookup formula by lookup formula. By the third VLOOKUP you are doing the agent's job, slower.
An agent on a restricted API key
Stripe's own recommendation for AI agents, and it is good advice: a restricted key grants per-resource read or write permissions, a read-only key cannot write no matter what the agent decides, and Stripe's MCP server scopes its tools to the key. Access is solved. The work is not. Every question becomes API calls through the agent's tool loop, list endpoints return at most 100 records per page, and the census of a years-old account is thousands of sequential reads narrated one call at a time, spending the agent's context on pagination instead of judgment. Stripe also meters reads by your charge volume, with a floor of 10,000 a month on a quiet account, so the census draws down a real budget. The same agent, handed the data as files, skips all of that.
Scratch, read-only by design
Scratch pulls your customers, with name, description, and metadata, plus products, prices, subscriptions, invoices, payment intents, and charges, into files on your laptop, over a connection that cannot write. Your agent never sees a key. It greps, joins, and scripts the census at file speed and writes a findings report with record IDs. The trade-off is the same fact read from the other side: Stripe is read-only in Scratch today, publish-back is on the roadmap, so Scratch cannot make the fixes for you. You walk the report into the Dashboard and clear it by hand. For most jobs on this site that would be a limitation. For an audit of the system that bills your customers, it is the spec.
| Option | Full census | Judgment calls | Can it write to Stripe | Price |
|---|---|---|---|---|
| Dashboard clicking | One list page at a time | Yours alone | Yes, per record | Free |
| Stripe Sigma | Yes, hours behind | Finds rows, not drift | No | Paid add-on in live mode |
| CSV exports | Per object, metadata capped | Bring your own | No | Free |
| Agent on a restricted key | Yes, at API pace | Yes | Only what the key allows | Your agent plan |
| Scratch | Yes, as local files | Yes, your agent | No, by design | Free to try |
How the audit works on your account
- Scratch pulls your Stripe account into files. Every customer, product, price, subscription, invoice, payment intent, and charge lands as its own file in a folder on your laptop. The pull happens once, at Stripe's pace; 12,000 customers is 120 list pages, and invoices multiply that. After it, every question is a file read that returns before a single API call would. Nothing in Stripe has changed, and through this connection nothing can.
- Your AI runs the census. Point Claude, Codex, Cursor, or Copilot at the folder and give it the brief. Find every price with no active subscription behind it, every product whose name contains test, old, or do not use, products that look like duplicates with drifted names, and customers whose description or metadata is empty or contradicts their invoices. Cite record IDs for everything. The grep-able offenders surface in the first minute. For the rest, the agent writes scripts: joining prices to products, scoring product names for similarity, counting metadata keys across every customer. That is 99% of the audit, done without the agent ever holding a credential.
- You get a report, not a changed account. The deliverable is a findings file, ordered by safety: products to stop selling, prices to archive, customers to correct, each with IDs, evidence, and the trap to check before acting. The last 1%, deciding what gets archived in a live billing account, stays with you, in the Dashboard, where it belongs.
Start with products and prices. It is the smallest census with the biggest payoff for a pricing refresh, and what you learn there sharpens the customer pass.
Why the fixes stay manual
Stripe's cleanup actions are sharper than they look, which is the strongest argument for separating the finding from the fixing. You cannot delete most products or prices, only archive them, and archiving a price deactivates any payment link still using it, even though existing subscriptions keep billing. Deleting a customer is permanent and cancels their active subscriptions on the spot. Duplicate customers cannot be merged at all; Stripe's guidance is to pick the most complete record and move on. A good findings report names these traps next to each item, the to-be-archived price that may still have a payment link on it, the duplicate customer whose subscription is live, so the hand making the change is the slow, informed one. If your cleanup needs the loop to publish fixes back to Stripe someday, tell Curtis. Publish-back is on the roadmap, and your job moves it up.
Questions people ask
Does the AI get write access to my Stripe account?
No. There is no write path to grant. Scratch's Stripe connection is read-only, the agent works on local files, and it never holds an API key of any kind. The strongest version of agent safety here is not a carefully scoped key. It is no key.
Can Scratch fix the problems it finds?
No. Stripe is read-only in Scratch today; publish-back is on the roadmap. The report gives you record IDs, evidence, and suggested actions, and you make the changes in the Dashboard yourself. For the system that bills your customers, that is the order of operations we are comfortable shipping.
Can I just delete the junk products and prices?
Mostly, no. Stripe deletes a price only if it has never been used, and a product only if no prices are attached to it. Everything else archives, which sets it inactive and keeps it forever. Part of the audit's job is telling you which is which before you start clicking.
Will archiving a price break anything?
It can. Subscriptions already on an archived price keep billing until they are canceled, but any payment link using that price stops working the moment you archive it. That is exactly the warning the report attaches: before archiving any price, check its payment links on the price page in the Dashboard.
Can I merge duplicate customers?
No. Stripe does not support merging customers at all. The guidance is to pick the most complete record and use it going forward. The report can rank the candidates by completeness and activity; the pick stays yours.
Is a restricted API key not enough?
It helps. Stripe recommends restricted keys for agents, and a read-only key genuinely cannot write. What the key does not change is the shape of the work: the agent still answers every question through paginated API calls instead of grep on local files, and the list endpoints cannot filter by metadata at all, so finding the customers missing a key means listing everything anyway. Files give the same agent more power with less access.
What does the findings report contain?
A checklist. Each finding carries the record IDs, the evidence behind it, a suggested action, and the trap to check first in the Dashboard, such as payment links on a price or live subscriptions on a customer. Every line can be checked against the file it came from.
What leaves my laptop?
Nothing. Scratch has no built-in AI and sends your Stripe records to no model itself. The agent you bring reads the folder under your own account and plan, the way it reads any folder you open with it. Which model sees your billing data stays your call, and because the connection cannot write, nothing travels back to Stripe either.
Do I need to know SQL or Python?
No. You write the brief in plain English; the agent writes whatever scripts the census needs and hands you findings, not code. If you do live in SQL, Sigma stays useful for recurring metrics. This loop is for the judgment passes a query cannot make.
See it on your own Stripe account
The fastest way to know what is in the account is to look. See it run on your Stripe account →, or download Scratch free, connect Stripe read-only, and grep your own product names for "test" as soon as the product pull lands. Scratch is free to try, and the AI is whichever agent you already pay for.