The income you cannot describe
There is a stage most subscription businesses pass through where the revenue is real, the customers are loyal, and nobody can produce a number. Invoices go out from a spreadsheet or a template. Payments come in by transfer or standing order. The bank statement is the only place where the whole picture exists, and it exists as a list of two hundred lines in date order.
In that state, simple questions are surprisingly hard. How many customers paid this month? Which ones paid last month and not this one? Is the total up because we won someone, or because an annual renewal happened to land? Each of those takes an afternoon of scrolling, so none of them gets asked.
Rearranging the same data by payer rather than by date answers all three at once. That is the whole idea, and it is genuinely most of the value — before any calculation, simply seeing the same customers as rows and the months as columns.
Cash is not revenue, and the gap matters
This has to come early, because everything else on this page is only useful if the distinction is clear.
Bank data tells you what money arrived and when. Revenue is what you earned in a period, which is a different thing entirely. A customer who pays a year up front in March gives you one bank line in March and twelve months of revenue. A customer on thirty-day terms pays in February for January.
| Situation | Bank shows | Revenue is |
|---|---|---|
| Monthly subscription, paid on time | One payment a month | The same — these agree |
| Annual plan paid up front | One large payment | Spread across twelve months |
| Invoiced on 30-day terms | Payment a month late | Recognised when earned |
| Customer stops paying, still using | Nothing | Arguably still accruing |
| Refund issued | Money out | Reduction of earlier revenue |
Row two is the one that misleads people most. A business with a mix of monthly and annual plans will see wild swings in bank income that have nothing to do with how the business is performing, and reading those swings as growth or decline is a mistake that gets made repeatedly.
None of this makes the cash view useless — it makes it a cash view. Label it as such, use it for what it is good at, and take the revenue question to your accountant or to a proper billing system when the mix gets complicated.
Who actually has this problem
Not companies with Stripe wired into a dashboard. The businesses this describes have recurring income that never passes through a system that understands recurrence.
Service businesses on retainer. Agencies, bookkeepers, consultants, maintenance contracts. The revenue is as recurring as any SaaS, and it is invoiced from a template and paid by transfer.
Membership organisations. Clubs, associations, trade bodies. Often hundreds of small recurring payments, frequently by standing order, and almost never in a system that reports on them.
Landlords and property managers.Rent is the purest recurring revenue there is, and the question “who has not paid this month” is the entire job.
Early SaaS before billing is wired up. The first customers pay by invoice because they asked to, and the founders discover eighteen months later that nobody knows the retention rate.
Grouping repeat payers
The core operation, and the one that requires judgement rather than a rule.
A bank statement identifies a payer by whatever text the sending bank produced. The same customer can appear as their trading name one month and their registered name the next, or with a reference number appended, or abbreviated because a field ran out of characters.
Grouping those variants into one customer is a decision. Made once per customer, it holds thereafter — which is exactly why it should be recorded rather than redone each month. This is the same discipline described on our transaction categorisation page, applied to payers rather than to expense categories.
Expect the first pass to take an hour and every subsequent month to take minutes. Most of the work is in the long tail of customers who pay irregularly; the twenty that pay every month settle immediately.
Reading the rhythm
Once payers are grouped, the interval tells you what kind of customer each one is — and the intervals are more varied than people expect.
Monthly on a fixed date is the easiest to read and usually a standing order or direct debit. A gap in that pattern is a strong signal, because the payment normally happens without anyone deciding.
Monthly but drifting means a human is paying an invoice. The date wanders with weekends and holidays, so a payment arriving on the 3rd instead of the 28th is not a late payment — it is the same payment.
Four-weekly produces thirteen payments a year and periodically puts two in one calendar month. Read as monthly, it looks like a double payment followed by a missing one, and it generates a false churn signal roughly every quarter.
Annual is the one that hides. A customer who paid last March and nothing since is not churned — until next March passes without a payment, at which point they are, and nobody noticed because there was never a monthly gap to see.
Separating one-offs
Recurring revenue is only meaningful if it excludes what is not recurring, and this is where most home-made trackers quietly go wrong.
A setup fee, a one-off project, an equipment sale, a refunded amount coming back — these all appear as money in from a customer, and lumping them into recurring income inflates the figure in a way that will not repeat.
The practical test is whether you expect it again next period. It is a judgement, not a calculation, and it should be recorded against the transaction so that next month’s comparison is not distorted by a decision nobody remembers making.
Keep the one-off income visible in its own column rather than deleting it. It is real money and it belongs in a cash view — it simply does not belong in the number you use to judge whether the recurring base is growing.
When the amount changes
A customer paying a different amount is the most informative event in the whole dataset, and the one a naive tracker handles worst.
An increase may be a price rise, an upgrade, or additional users. All three are good news and all three should continue at the new level — so the new amount becomes the baseline.
A decrease is the signal worth acting on. A customer who reduces rather than cancels is telling you something while there is still a relationship to save, and this shows up months before a cancellation would.
A single odd amount that returns to normal afterwards is usually a part payment, a credit applied, or a currency difference. Treating it as a change rather than an exception produces a wrong retention figure.
Whichever it is, the important thing is that the customer is still recognised as the same customer. Treating a price change as a churn plus a new sale is the single most common way a home-made retention number ends up flattering or damning without reason.
The customer who stopped
This is the question the whole exercise exists to answer, and it is almost impossible to see in a date-ordered statement. Nothing appears when a payment does not happen. There is no line, no alert, no gap you can look at — only an absence among two hundred present things.
Arranged as payers down the side and months across the top, the absence becomes a blank cell, and blank cells are visible instantly. That single change of layout is worth more than any calculation performed on the data.
What a blank cell means still needs a human. It might be churn. It might be a failed card, a changed bank account, an invoice that never arrived, or a customer on holiday. The treatment of that question — and what to do about it — is covered on our failed payment and churn signals page.
The value is in the timing. A blank cell noticed in the first week of a month is a phone call. The same blank cell noticed at the year end is a write-off, and by then whatever caused it has usually become permanent.
How it works
1 · Convert the statements
Every account, as far back as you have. Up to 100 files at once; scans go through OCR first.
2 · Completeness checked
Closing balances recalculated from the rows and the series checked for gaps, so a missing month is a flag rather than an apparent drop in income.
3 · Group the payers
Merge the name variants into one customer. An hour the first time, minutes thereafter.
4 · Mark what recurs
Recurring, one-off, or refund. A judgement recorded once per transaction type, not remade each month.
5 · Pivot to payers by month
Customers down, months across. Blank cells become visible, which is the entire point.
6 · Export
Excel or CSV with fixed columns, so the sheet you build this month still works next month.
Three numbers worth having
Resist building a metrics dashboard. Three figures, tracked consistently, tell you more than twelve tracked erratically.
| Number | What it answers | Watch out for |
|---|---|---|
| Paying customers this month | Is the base growing | Annual payers look absent for eleven months |
| Recurring cash collected | Is the money arriving | Annual plans distort the monthly shape |
| Payers who dropped out | Who needs a phone call | A late payment is not a churn |
The third is the only one that prompts an action, which makes it the most valuable despite being the least impressive. The first two describe; the third asks someone to do something this week.
Compare each against the same month last year as well as the previous month — the mechanics are on our period comparison page, and the same discipline about consistent categories applies here to consistent payer grouping.
Payment processors are a different problem
If your customers pay by card through Stripe, PayPal, GoCardless or a similar processor, the bank statement will not help you directly, and it is worth understanding why.
What reaches your bank is a payout: one line, covering many customers, net of fees, on the processor’s own schedule. The individual customer payments are invisible, and no amount of pattern analysis will recover them from a single aggregated figure.
For that you need the processor’s own statement, which is a separate document with a separate structure — our payout statement converterhandles that side. The bank statement then serves a different and still useful purpose: confirming that the payouts actually arrived and reconciling them against the processor’s figures.
Many businesses have both — some customers on card, others paying by transfer because they asked to. Those need to be combined deliberately, and the mismatch in timing between a card charge and a payout is a real complication rather than a rounding difference.
How often to run it
Monthly, in the first week, and always on the same working day. The date matters more than the speed: a report that appears predictably becomes part of how the business runs, and one that appears occasionally is treated as a curiosity.
The exception is the drop-out list, which is worth looking at more often if your payments cluster around a particular date. Where most customers pay on the 1st, checking on the 5th catches problems three weeks earlier than a month-end review would.
Do not chase real time. Daily monitoring of recurring revenue produces noise — payments arrive over several days for entirely mundane reasons, and reacting to a single day’s figures means reacting to weekends.
Six mistakes
Calling bank income revenue
Right for monthly plans, badly wrong the month an annual renewal lands — and one such month costs the figure its credibility.
Counting one-off income as recurring
A setup fee inflates a number that is supposed to be a promise about next month.
Treating a price change as churn plus a new sale
The most common way a home-made retention figure ends up meaningless.
Missing four-weekly payers
Thirteen payments a year produce a false churn signal roughly every quarter.
Forgetting annual customers exist
They look absent for eleven months, and their actual disappearance goes unnoticed for a year.
Reading a single late payment as a lost customer
The blank cell is a question, not an answer — the phone call is what turns it into one.
What this is not
It is not a billing system. It does not invoice, take payments, retry failed cards or manage plans. It reads what already happened, which is a useful thing to do and a different thing entirely.
It does not apply revenue recognition. Spreading an annual payment across twelve months is an accounting decision, and it belongs with your accountant — see the month-end close checklist for where that sits in a normal close.
It does not decide who counts as a customer. Grouping payers, merging name variants and judging what recurs are all decisions you make; the data makes them visible and quick, not automatic.
And it will not tell you why someone left. It will tell you that they did, early enough that asking them is still possible — which is generally the more useful of the two.