Is there one screen that lists everything subscribed to my email?

No, and no tool can offer one. Google and Apple each show only the subscriptions billed through their own billing system, and your bank shows only the charges that ran through its cards. Every list you can pull is a slice. A usable inventory is the union of the slices, plus the items that appear in only one of them.

Where do subscriptions hide so that email search never finds them?

Three places. Charges billed through an app store appear on the store receipt, not always in a SaaS-branded email. Trials that converted without a confirmation still charge, but the only trail is the card statement. And a subscription on a personal card or a shared team address is invisible from whichever mailbox you happen to be searching.

How does SaaSClerk read my mailbox without touching it?

It asks for the gmail.readonly OAuth scope, reads 12 months of mail for billing events, and stores nothing but the extracted line for each service: name, amount, interval, next renewal, and which address received it. The email body is not stored, and the access credential is kept encrypted with AES-256.

What is the cheapest way to keep the list current after building it once?

A recurring reminder, not a recurring spreadsheet. Anything still active gets an email 14 days before it renews, which is the only window in which cancelling is still a decision rather than a refund request.

SaaSClerk Blog · SaaS subscription visibility

How Can I See Every Subscription Linked to My Email Address?

Short answer: there is no single screen that holds the whole list, because a subscription leaves traces in three different places at once — the mailbox that receives the receipt, the payment instrument that gets charged, and the login that proves you still use it. Walk all three and union the results. The mailbox is the only one with a renewal date on it, so it is the right place to start; a read-only scan of 12 months of billing email turns that step into one list instead of an afternoon of search operators.

Why one search box can't answer this

Each provider's list is scoped to what it billed. Google Play and the App Store show subscriptions that ran through store billing. Microsoft and Apple show theirs. Your bank shows every charge that touched its cards, regardless of who sent it. None of those views knows about the others, so a complete inventory is the union of four or five partial ones plus whatever only one of them can see.

That union is the honest target. A list you built from one source is not wrong — it is a share of the real total, and the missing share is usually the part that keeps renewing quietly.

Trace one: the mailbox

Billing mail is the densest source because it carries the renewal date, which nothing else does reliably. Search the mailbox for the words vendors actually use, not the word "subscription": receipt, invoice, your plan renews, payment failed, trial ended, renewal. Sort newest first and take one line per vendor.

Expect the sweep to miss items on purpose. A trial that converted without a confirmation email, an app-store charge that lands as a store receipt rather than a vendor-branded one, and anything bought on a card whose receipts go to a different address all sit outside this mailbox.

Trace two: the money side

Pull the last 12 months of statements for every card and payment account that could touch a software charge — company card, personal card, PayPal, and any store credit that auto-replenishes. Mark recurring merchants. Then diff against the mailbox list in both directions:

Charged but no email: the receipts go to a colleague, a shared alias, or an address you no longer check. This is where duplicate team plans hide.
Email but no charge: a cancelled plan whose "renews on" language predates the cancellation, or a charge that failed and got retried under a different descriptor.

Trace three: the login side

A password manager vault and single-sign-on history both answer a different question from the first two — not what you pay for, but what you still open. An item that renews monthly and has no login in the last quarter is the one to cancel first. An item with no billing trace and an active vault entry is a subscription on someone else's card, and you are the user.

Turn three sweeps into one list

Whatever method you used, the row is worth keeping only if it carries five columns: service, amount, interval, next renewal date, and who owns the credential that renews it. The owner column is the one that makes the list actionable — a renewal you know about a fortnight early is a decision, and a renewal you find on a statement is a refund request.

SaaSClerk builds the first four columns from one mailbox, read-only, and flags the fifth by recording which address received each billing event. Items still active get an email 14 days before they renew. The scan itself is free against one mailbox; keeping the alerts running is the paid part.

Source	What it can prove	What it structurally cannot see
Mailbox (12 months)	Amount, interval, next renewal date, receiving address	Receipts sent to another address; conversions with no email
Card and store statements	That money actually left, including app-store and failed-payment retries	Renewal dates, service names behind opaque descriptors
Vault and SSO history	Whether anyone still logs in, and under whose credential	Price, billing date, and any charge not tied to a stored login

Do the free pass before you build a process

Try the audit first: scan one mailbox free at saasclerk.app. It returns one line per service with an amount and a renewal date next to it. Then run the card diff by hand against that list — the rows only the statement shows are the ones worth the next hour.