Finding every recurring subscription in your bank statement

You already know about four of them. There is the streaming service, the music one, the cloud storage you top up, and the gym. The reason you are reading this is the suspicion that there are more, and the reason the suspicion is usually correct is that a subscription is designed never to require your attention again.

Scrolling a statement finds the four you already knew about. It misses the rest because the description is different every month, or because the price changed halfway through the year, or because the expensive ones charge you only once. Each of those needs its own pass over the data, and every pass needs the whole period in one place rather than thirteen statements in a folder.

Get thirteen months into one sheet first

An annual renewal appears in exactly one month of the year, and twelve months of statements will usually catch it. Usually, because renewal dates drift. An anniversary that lands on a weekend or a bank holiday posts a day or two late, and a merchant that moves its billing run can shift the date by more.

The drift only costs you anything when it straddles the edge of your window, and then it costs you the whole subscription. Take a renewal charged on 28 July 2025. It comes round 369 days later, on 1 August 2026, four days later in the calendar than the year before. Convert the twelve statement months from August 2025 through July 2026 and neither charge is in the set: the 2025 one fell four days before the window opened, and the 2026 one lands one day after it closed. Every pass below then runs over a year of rows in which that subscription does not exist.

This is a narrow case. It needs the boundary of your window to land inside the few days a particular renewal drifts across, which will not be true of most annual charges in most years. But you cannot know in advance which renewal it will be true of, and the thirteenth statement costs one extra conversion to rule it out, so there is little reason to run the risk.

Convert the whole set into a single sheet with four columns: date, description, amount, and a column naming the source statement so any row can be traced back to a page. If the account is one of several, keeping every account in one workbook with a column identifying which is which is what makes the analysis possible at all.

Normalise the description into a merchant key

The description on a card transaction is assembled by the payment processor. The merchant contributes part of it; the rest is machine generated and changes on every charge. A single subscription can appear in your statement as any of these, in the same year:

• A processor prefix. SQ, TST, PAYPAL, PP, IC and WWW all appear in front of the actual merchant name, usually followed by an asterisk.
• A trailing reference. An authorisation code, a merchant terminal identifier, or a run of digits that means nothing to you.
• An embedded date. Some banks append the transaction date to the narration, so the description literally differs every month by construction.
• A location field. City, state or country code appended after the name, which changes if the merchant's billing entity moves.
• A card fragment. The last four digits of the card used, which changes when a card is reissued.

Build a merchant key in a new column and work from that instead. The recipe is crude and it works: uppercase the description, strip the known processor prefixes, cut the string at the first run of four or more consecutive digits, then truncate what is left to a fixed length and trim the whitespace. There is no correct length to truncate at. Card descriptors put the merchant name at the front and the volatile parts behind it, so anything long enough to separate two similar names and short enough to drop a changing suffix will work; look at your own descriptions, pick a length, and expect to adjust it once.

Then check the keys before you trust them. Build a list of unique keys and read it. You are looking for two failures: one merchant that split into two keys because the prefix list missed a variant, and two merchants that collapsed into one key because the truncation cut before the point where their names diverge. Fix the handful that are wrong by hand. This takes a few minutes once and every later pass depends on it.

Count the distinct months per key

Now count, per merchant key, how many distinct months it appears in across the thirteen. The count is the whole diagnosis.

• Eleven or more months: a monthly subscription, with a gap or two where a payment failed and retried.
• Four or five months: a quarterly billing arrangement, or a monthly one that started partway through the year.
• Two or three months: either a genuine occasional purchase or a subscription that started recently, and the date pattern separates them. Two charges 30 days apart is a new subscription. Two charges seven months apart is not.
• One month: the pile you cannot skip, because every annual renewal is in it, mixed in with every one-off purchase you made all year.

Count distinct months rather than counting rows. A merchant you buy from twice in March and never again racks up a high row count and no recurrence. A subscription charged monthly hits twelve or thirteen distinct months and nothing else does.

The amount pass, and what it catches that the key pass does not

Sort the whole period by amount. Look for values repeated to the cent across distinct months. An amount repeated to the cent in eight or more of the thirteen months is a recurring charge whatever the description says. The bar sits that high because an identical figure is weaker evidence than an identical merchant key: eight of thirteen months means the amount was present for well over half the period, which quarterly billing at four or five months never reaches and two unrelated merchants charging the same price almost never manage either. This pass is how you catch the merchant who switched payment provider in April: the descriptor changed completely, the key pass split it into two five-month merchants that both look like nothing, and the amount pass sees 9.99 in eleven months and flags it.

Two cautions. Common prices collide: 9.99 at two different merchants is not one subscription, so confirm an amount match against the keys before acting on it. And this pass is blind to any subscription whose price rose during the period. A service that went from 11.99 to 13.49 in June appears as two amounts, one with seven occurrences and one with six, and neither reaches eight. That is not a badly chosen threshold so much as an unavoidable one: thirteen months cannot divide into two runs of eight, so any mid-period price change leaves both halves short of a bar set high enough to be worth trusting on an amount alone. The key pass catches that one, because the descriptor did not change when the price did. Neither pass substitutes for the other.

The interval pass

Sort by merchant key, then by date within the key, and compute the difference in days between each charge and the one before it from the same key. The distribution of those gaps is the sharpest signal in the data.

Monthly billing produces gaps of 28 to 31 days, drifting a day either way when the anniversary lands on a weekend. Four-weekly billing produces a hard 28 every time, which is thirteen charges a year rather than twelve, and the difference is a full extra payment that nobody notices. Quarterly produces 84 to 92. Weekly produces 7. Annual needs a wider allowance than any of them: treat anything from 358 to 372 days as a yearly cycle, a year give or take a week.

That width is deliberate, and it is why a band of 364 to 366 is the wrong rule. A monthly charge re-anchors to the same day of the month twelve times a year, so a weekend or a bank holiday moves one payment by a day and the next cycle pulls it back; the drift never accumulates. An annual charge has a single anniversary, so a leap day, a renewal pushed off a weekend, and a merchant shifting its billing run all land inside the same one gap and add up. The renewal in the opening example moves from 28 July 2025 to 1 August 2026, a gap of 369 days, which a 364 to 366 rule would classify as nothing at all. Anything with a consistent gap is a subscription no matter what it is called.

A gap of roughly 60 days inside an otherwise monthly series is worth opening. It usually means one payment failed and the merchant retried the following cycle, and that is either a card that expired or a charge that a bank flagged, both of which are things you want to know about.

What a completed audit looks like

Run the three passes on thirteen months and the result is a short table, with monthly charges expressed at their annual cost so everything is comparable:

The six monthly charges are 15.99, 11.99, 9.99, 4.99, 22.00 and 8.50, which come to 73.46 a month and 881.52 across the year. The three annual charges of 118.80, 79.00 and 240.00 come to 437.80. Together the recurring total is 1,319.32.

Look at what happens if you audit one month instead of thirteen. You find the six monthly charges, multiply by twelve, and conclude you spend 881.52 a year on subscriptions. The real figure is just under half as much again, and the 437.80 you missed sits in three rows out of a year's worth. Those three are also, individually, the largest subscription payments you make, and the hardest to notice because each one arrives eleven months after you last thought about it.

The full procedure

1. 1

   Convert thirteen consecutive statement periods

   Convert the full statement documents into one sheet with date, description, amount and a source column, and confirm each period's balance chain before analysing anything.
2. 2

   Build the merchant key column

   Uppercase, strip processor prefixes, cut at the first run of four or more digits, truncate to a length that suits your own descriptions, trim. Then read the unique key list and fix the ones that split or collided.
3. 3

   Count distinct months per key

   Pivot on the key with a distinct count of months. Anything at eleven or above is monthly, four to five is quarterly, and the single-month group holds every annual renewal.
4. 4

   Sort the single-month group by amount

   Read it top down. Every large one-off debit is either a real purchase you remember or a renewal you did not know about.
5. 5

   Run the amount and interval passes

   Look for cent-exact amounts repeating across distinct months, then compute day gaps within each key to confirm the billing cycle.
6. 6

   Check the card statements too

   Any subscription charged to a credit card appears in the current account only as the monthly card payment. Convert those statements and repeat.

What the list cannot tell you

The audit is only as complete as the rows underneath it, and this is where a converted file has to be checked rather than trusted. If the conversion dropped four rows at a page boundary, four charges are simply absent from every pass above and nothing in the analysis will hint at it. Two checks are available for that, and they are not equally strong.

The weak one is the totals check: opening balance plus the period's movements equals the printed closing balance. It is defeated by any pair of errors that cancel, and a page boundary produces exactly that pair. Lose one 9.99 charge and repeat another 9.99 further down and the period still totals to the penny, while your distinct-month count loses a month for one merchant and gains a phantom second charge for another.

The strong one runs row by row: each row's printed balance plus the next row's amount has to equal the next row's printed balance. The dropped charge breaks that equation on the row immediately after it, and a balance rebuilt from the opening figure stays 9.99 adrift for every row from the loss until the duplicate cancels it, so the pair the totals check swallows is visible here as a run of wrong rows. This is also the version that catches a misread digit, which is the error that would otherwise poison the amount pass: a 9.99 read as 999 fails on the row it sits on. Run it wherever the statement prints a running balance, and be aware that on statements that print none, it is not available at all and the totals check is all you have.

What survives even the row-by-row version is everything outside the amount column, which for this audit is most of what you are working with. It says nothing about dates, so a charge dated 3 March that actually posted on 30 March reconciles perfectly, lands in the wrong month of your distinct-month count, and turns one steady 30 day gap into a short one followed by a long one. It says nothing about descriptions, so a mangled narration that splits one merchant key into two passes untouched. A row whose amount is genuinely zero moves no balance and is checked by nothing, and a balance column misread in a way that agrees with the amount beside it reconciles against itself. Odd gaps are worth opening for that reason as much as for the failed-payment one.

Once the recurring charges are identified, they are the easiest category in the whole year to assign, because a merchant key that bills you monthly gets one category for all thirteen rows. That is the same lookup table the category by category view of a full year is built on, and if the plan is to keep the picture current rather than audit once, the rows go straight into a budgeting app through its file import with the categories already attached.