Most subscription trackers start the same way: "Connect your bank." It's the obvious route, because every charge is in your transactions. We went the other way and built Subscriptrack around email receipts. This post is about why, and what it took.

The app with a sample account: the monthly total, a trial's cancel steps, cheaper plans and the full list.
Why receipts instead of a bank feed
Three reasons.
Coverage. Bank-data aggregators are country by country. A tracker built on one is often limited to a single market, or charges extra per connected account. Receipts look the same everywhere, in any currency.
Detail. A bank line says APPLE.COM/BILL or PAYPAL *. A receipt says "Adobe Lightroom, Photography plan, £9.98, renews 3 December". For a subscription list, the receipt is the better source: it names the actual service, the plan and the renewal date.
Trust. Asking someone for their bank login, even through a regulated provider, is a big request for an app they found yesterday. Email is still sensitive, so we keep it narrow: we read only receipt-like messages, and the person decides which inboxes we see.
The trade-off is real: a subscription that never sends an email won't show up by itself. That's why statement upload and manual entry exist alongside email.
Getting email in
There are two ways in, and "connect your email" covers both.
Outlook and Microsoft 365 connect with OAuth through Microsoft Graph, using a read-only mail scope. Microsoft's mail scopes don't need a third-party security assessment, so this could ship first.
Gmail and every other inbox work by forwarding. Each account gets a private address, and the person sets an auto-forward rule (we give Gmail filter steps that only forward receipt-like mail). Inbound mail arrives through SendGrid Inbound Parse. Large PDF invoices can exceed what a serverless function will accept in one request, so the webhook lands in a Supabase Edge Function first and is relayed to the app.
Gmail one-click is the obvious next step, but Gmail's read scopes are "restricted": Google requires a security assessment every year before an app can use them. Until there's demand to justify that, forwarding does the job.
Extraction: a fixed schema, not free text
Each receipt goes to Claude with a strict output schema: merchant, plan, amount, currency, billing period, next renewal date, and whether it looks like a trial. Asking for a fixed shape instead of prose makes failures obvious. A missing field stays empty; it isn't invented.
What works well: well-formatted receipts from big services, App Store and Google Play receipts (which name the app inside a generic sender), and multi-currency amounts.
What needs care: emails that mention a price without being a receipt (marketing, "your price is changing" notices), and invoices where the renewal date is implied rather than stated. Every extracted row can be edited, and later receipts never overwrite the person's own edits.
Merging: exact repeats vs likely duplicates
The same subscription shows up many times: monthly receipts, forwarded copies from two inboxes, a statement line for the same charge. Exact repeats (same merchant, amount and date) merge automatically. "Probably the same thing" cases are only flagged, and the person decides. Silently merging two genuinely different plans would be worse than showing a duplicate.
Reminders that respect people
The useful moment is before money moves: a reminder before a renewal, and before a free trial turns into a charge. Bank-based tools only see a trial once it has already charged. Receipts usually state the trial end date up front.
Two deliberate limits:
- We never cancel anything on the person's behalf. We link to the company's own cancel page and steps, each sourced from its help pages with the date we checked.
- Once someone cancels, the overview shows what that saves each month and so far, as an estimate it labels as one, counting only changes made after they joined.
What we'd do differently
- Treat the forwarding setup as part of the product. Supporting "any inbox" through forwarding was right, but setting up a forwarding rule is the step most likely to lose people, so its instructions matter as much as the AI.
- Design for "not a receipt" from day one. A lot of the work is deciding what to ignore.
- Show the source. Linking every extracted subscription back to the email it came from does more for trust than any privacy page.
We built this into Subscriptrack. It's free for 5 subscriptions, no card: subscriptrack.com
Top comments (0)