A property of the dataset, not of the line
Look at a single bank transaction and there is no way to tell whether it will happen again next month. The amount, the date, the payee — none of them carry that information. A twelve-pound payment to a software company looks exactly the same whether it is a one-off or the ninth of an indefinite series.
This is why subscriptions accumulate. Each individual charge is small enough to ignore and looks like every other line around it. The pattern only exists across time, and a statement in date order is precisely the arrangement that hides patterns across time.
Rearranging by payee makes them appear immediately. That rearrangement is the feature: not clever analysis, but putting the data in the shape where the thing you are looking for is visible.
What the pattern actually looks like
Three things together make a recurrence, and each on its own is meaningless.
| Signal | Strong when | Weak when |
|---|---|---|
| Same payee | Description is stable month to month | A processor prefixes its own reference |
| Regular interval | Dates land within a few days each time | A human pays invoices whenever they get to them |
| Similar amount | Fixed price plan | Usage-based billing that varies widely |
The interval is the strongest of the three and the most forgiving. A subscription whose price changed is still a subscription; a subscription whose name is written differently is still a subscription; but a payee appearing at random intervals is genuinely not one, whatever the amount suggests.
This ordering matters because it decides what happens in ambiguous cases. Weighting the amount too heavily splits one usage-based service into a dozen unrelated payments; weighting the interval correctly keeps them together.
Four intervals, four difficulties
Monthly is the common case and the easiest. Three months is enough to suspect, six to be confident.
Four-weekly produces thirteen payments a year and periodically puts two into one calendar month. Anything that assumes monthly reads this as a double charge followed by a missing one, and generates a false alarm every few months.
Quarterly needs a year of data to be recognisable at all, and is frequently mistaken for a series of unrelated one-off payments — which is exactly how quarterly insurance and service contracts escape review.
Annual is the most valuable and the most demanding: two years of statements minimum, because one occurrence is not a pattern. These are also the largest individual amounts and the ones most likely to renew unnoticed, which is a poor combination.
The practical implication is simple. If you only convert this year, you will find your monthly subscriptions and miss the annual renewals entirely — and the annual ones are usually where the money is.
Name variants
The same company rarely appears identically twice. Banks truncate long descriptions, card processors prepend their own reference, and some merchants include an order number that changes every time.
Matching therefore works on the stable portion of the description rather than on an exact string. Where the variants are ambiguous, they are grouped and shown together rather than merged silently — because a wrong merge is worse than an unmerged pair. Two entries you can join in a click cost you a click; one wrong join produces a number you will trust and should not.
The confirmation is a decision you make once per payee. After that it holds, which is what turns a one-hour first pass into a five-minute monthly routine. The same principle governs transaction categorisation: correct a payee once, not every month.
One case deserves attention: a merchant who changes payment processor mid-year. The description changes completely, and the pattern appears to stop and a new one to begin. It is worth checking new payees against recently ended ones for exactly this reason.
Amounts that move
A fixed price makes everything easy. Real subscriptions rarely stay fixed, and how the variations are treated decides whether the output is trustworthy.
A step change — same amount for months, then a new amount that persists — is a price rise or a plan change. It stays one subscription, and the change is worth flagging in its own right, because a price rise that nobody noticed is one of the more common findings in this exercise.
Gradual drift suggests per-user or usage-based pricing. Still one subscription, but its trajectory is the interesting part: a tool that costs half again what it did a year ago deserves a look regardless of whether it is used.
Wild variation at a regular interval is usually a consumption-based service — cloud hosting is the classic. It is recurring in the sense that it will happen again, and unbudgetable in the sense that the amount is unknown, which makes it a different management problem despite looking similar in the data.
A single outlier that returns to normal is typically an annual add-on, a proration or a one-off overage — worth showing next to the pattern rather than allowing it to redefine the baseline.
How it works
1 · Convert everything
Every account and card, ideally two years. Up to 100 files at once; older scans go through OCR first.
2 · Check completeness
Closing balances recalculated and the series checked for gaps — a missing month breaks a pattern and looks like a cancellation.
3 · Group by payee
Name variants collapsed onto the stable part of the description, ambiguous ones surfaced rather than merged.
4 · Measure the interval
Monthly, four-weekly, quarterly or annual, with tolerance for weekends and holidays.
5 · Track the amount
Typical value, step changes and outliers kept distinct, so a price rise is a flag rather than a new subscription.
6 · Export
One row per recurring payment: payee, interval, typical amount, first seen, last seen, annualised total.
What you get back
One row per recurring payment, with the columns that make a decision possible.
| Column | Why it earns its place |
|---|---|
| Payee | The stable name, with variants recorded |
| Interval | Monthly, four-weekly, quarterly, annual |
| Typical amount | The current level, not the average across a price rise |
| Annualised total | The number that actually prompts a decision |
| First seen | How long this has been running |
| Last seen | Whether it is still live |
| Account | Which card or account it sits on |
| Occurrences | How much evidence the pattern rests on |
The annualised total is the column that changes behaviour. A modest monthly figure invites a shrug; the same subscription shown as its yearly cost gets cancelled or renegotiated. Sorting by that column is the single most useful thing you can do with the output.
“First seen” is the quiet one. A subscription running for four years that nobody can explain is a different conversation from one started last quarter, and the date is the only thing that distinguishes them.
Where the human comes in
The pattern is found automatically. What it means is not, and this boundary is deliberate rather than a limitation to be engineered away.
A supplier invoiced monthly for a similar amount is indistinguishable from a subscription in bank data. Rent looks like a subscription. A repayment schedule looks like a subscription. The data genuinely cannot tell them apart, and a tool that guessed would produce a confident list that is quietly wrong.
So the output is a list of things that repeat, sorted by annual cost, with the evidence attached. Classifying them — and deciding what to cancel — takes a person perhaps twenty minutes, which is the fastest twenty minutes of cost saving available in most businesses.
The same reasoning applies to the incoming side: a customer who stopped paying might have churned or might be late, and the difference matters enormously. That is treated on our failed payment and churn signals page.
Money out and money in
The same pattern logic runs in both directions, and the two uses feel entirely different despite being the same operation.
Outgoinganswers “what are we paying for”. It is a cost exercise, it is usually done once and then annually, and it almost always pays for itself the first time.
Incominganswers “who pays us regularly”. It is a revenue exercise, it needs doing every month, and its value is in the customers who stop rather than the ones who continue — the full treatment is on recurring revenue from bank statements.
Businesses that do both find the incoming side more valuable over time and the outgoing side more satisfying immediately. Starting with outgoing is the usual advice for that reason: it produces a result in the first session.
How much evidence is enough
A pattern is a claim about the future made from a handful of past events, and it is worth being explicit about how much confidence each amount of evidence actually justifies.
Two occurrences is a coincidence with a plausible interpretation. Two payments a month apart might be a subscription or might be two unrelated purchases from the same supplier. Worth surfacing, not worth acting on alone.
Three to five at a consistent interval is a working pattern. This is where most monthly subscriptions become unambiguous, and where a review can proceed without checking each one against a contract.
Six or more is settled, and the interesting question shifts from whether it recurs to whether it should. That is a business question rather than a data one.
Which is why the occurrence count appears in the output. A row backed by twelve payments and a row backed by two deserve different levels of confidence, and hiding that distinction behind a single “recurring” label would make the weak rows look as solid as the strong ones.
Worth stating what all of this rests on: none of it works if the underlying series has holes. A missing statement removes several months of a pattern, and the effect is not a gap you notice — it is a subscription that appears to have been cancelled and restarted, or one that never reaches enough occurrences to be recognised at all. That is why statement continuity is checked before any pattern work begins, and why a series with a known gap is flagged rather than quietly analysed. A confident list built on incomplete data is worse than an honest gap.
Where it gets used
The annual subscription audit
One session a year, sorted by annualised cost. Almost everyone finds something nobody can explain.
Building next year's budget
Recurring costs are the baseline a budget is built on — see the budget-building guide for where this fits.
Monthly revenue review
Which customers paid, which did not, and who reduced their amount before cancelling.
Due diligence and handovers
Taking over a set of books, the recurring list tells you what the business is committed to far faster than reading contracts.
For budgeting specifically, the recurring list is the cleanest possible starting baseline — the method is in the budget-building guide, and tracking against it afterwards on budget versus actual.
What it will not do
It will not cancel anything. It produces a list; the cancelling is a series of logins and emails that nobody can automate for you.
It will not tell you whether a subscription is used. Usage data lives in the tool itself, not in the bank, and a payment says nothing about whether anyone opened the thing being paid for.
It will not distinguish a subscription from a regular supplier invoice, because the data does not contain that distinction. The pattern is surfaced with its evidence; the classification is yours.
And it cannot find annual patterns in a single year of data. That is not a shortcoming to be improved — one occurrence is not a pattern, and any tool claiming otherwise is guessing.