Two people were paying me twice for the same thing, one of them for five months. I found both in a single afternoon, sorting a spreadsheet by email domain.
That afternoon happened because I had told a partner I had 412 customers. The figure came from a query that counted rows in the table where accounts live. Once I had read every row myself, the honest answer was somewhere near 340.
Nobody lied to me. I counted accounts and said customers, and those are separate things that happen to live in the same column.
One source, and still the wrong number
There is a familiar version of this where your analytics reports one figure, your payment processor reports another, and a Saturday disappears into deciding which is lying. Usually neither is.
This is the quieter problem. One system. One query. Nothing on screen disagrees with anything else. The count is exactly right for the thing it counted, and the thing it counted was logins.
Your database stores accounts because accounts are what it was built to store. You meant people, or companies. The query is fine. The label is wrong.
The four shapes a duplicate takes
The first is one person with two addresses. They signed up with a work email in March, lost access to it, signed up again with a personal one in November. Two rows, one human, and no field anywhere connects them.
The second is a small company. A three person design studio where the designer, the account manager and the owner each keep their own login, and the invoice goes to a bookkeeper who has never opened the product. One payer. Four rows.
The third runs the opposite way, which is why people miss it. A household shares one subscription on one card. Your account count says one. The number of people who would complain if you switched it off is four.
The fourth is time. Somebody cancelled in January, came back in August with a fresh signup, and nothing in your system had reason to check whether it had met them before. They exist twice now, filed once as churned and once as new.
Which direction your error runs
Most small businesses have more accounts than people, so the customer count sits too high. That is the flattering direction, which is why it goes unchallenged for years.
Shared subscriptions flip it. If what you sell gets passed around a family or a small team, your accounts undercount the humans, and you will underestimate how much noise a price rise makes.
You do not get to assume which way it goes. Go and look.
Churn breaks first
Churn is computed per account in every tool I have used, and per account is almost never the unit you care about.
So the four seat design studio decides to tidy up and consolidate to a single login. Nothing about the relationship changed. The same money arrives next month. Your churn report shows three cancellations and your month looks bad.
I have written separately about the mechanics of churn, the denominator you divide by, gross against net, and why the rate is a smoke alarm rather than a diagnosis. That still stands. This sits one level beneath it. A rate can be calculated perfectly on a unit that has nothing to do with your question.
The average that quietly deflates
Average revenue per customer is revenue divided by customer count. Inflate the denominator by 15% with duplicates and the average lands 15% low.
Then you hold that against whatever figures other people in your industry publish, decide you are underpriced, and act on it. The revenue in the top half of that fraction is real, because money is money whoever sent it. The bottom half is the part you made up.
Lifetime value inherits the same fault, and payback periods inherit it from lifetime value.
A retention curve that flatters you
This is the sneakiest of them.
Someone leaves, comes back six months later with a new email, and your cohort table records a brand new customer in August. The August cohort looks strong. The January cohort looks like it lost a member. Neither is true.
Returning customers are the cheapest revenue a small business has, and counting them as new makes them structurally invisible. You cannot decide whether win back is worth doing when every winner is filed under acquisition.
I had a second month retention figure that looked unusually good for longer than I want to admit. Part of it was people I had already counted.
Segments built on the wrong atom
Segments inherit all of it. A firm with five logins lands in five buckets or in one, depending on how those logins happened to be created, and the answer changes as staff come and go.
The real trap in segmentation is slicing until the groups are too small to say anything reliable, which I still believe. Counting the wrong unit gets you there faster, because it splits customers you already had into fragments.
Pick the unit, then say which one you picked
The usual advice is to build a single unified customer record, choose a canonical identifier, and resolve every identity in your database. For two hundred customers that is a quarter of your year spent on something an hour and a spreadsheet answers.
The useful move is a decision rather than a project.
For money questions, count billing entities. Who pays you, one card, one invoice, one company. Revenue per customer, churn, lifetime value, all of it belongs on the thing capable of stopping payment.
For usage questions, count logins. How many people opened it this week, which features get touched, where people give up. A firm with four active users is four users, and flattening that to one throws away the only signal you had.
Then write both numbers down with different words attached and stop trying to reconcile them. I have roughly 340 billing entities and around 600 logins. Both are true. Putting them on one page with two labels took ten minutes.
Keeping a definition steady after you choose it is a separate discipline. The question here is which unit to choose at all, and that follows from the decision in front of you.
An hour with a sorted spreadsheet
Sort by email domain. Everyone at the same company lands together and the firms buying four times under four names appear in one glance. Highest yield sort there is.
Normalise addresses before comparing them: lowercase everything, strip dots from the part before the at sign, cut anything after a plus sign.
Sort by name and actually read the list rather than scanning it. People are consistent about how they type their own name.
Sort by the last four digits of the card if your processor exposes them. One card behind two accounts is either one customer or somebody paying for a friend, and both are worth knowing.
Check your cancelled list against everyone who signed up in the last six months. That is where the returners hide, and nothing goes looking unless you tell it to.
Duplicates are the highest impact cleanup a small business can do to its own data, and the durable fix belongs at the point of entry. That is true and it is also slow. These five sorts are what you do this afternoon while the durable fix waits.
One warning if you go past sorting. The moment you join your customer list onto anything else, count the rows before and after. A key you assumed held one row per customer, when it actually holds one row per login, multiplies every figure downstream and nothing errors.
Count them by hand and stop apologising for it
Here is the position I get argued with about. Under a few hundred customers, sit down once a quarter and count them by hand. Open the list, read every row, decide who is who. Three hundred rows takes under an hour once sorted.
People find this beneath them. They will tell you it does not scale, which is true and irrelevant, because you do not have a scale problem. You have four hundred rows and a wrong number.
The people who refuse are reliably the ones quoting figures that are off by a fifth. Automation is what you build once the manual version is understood and dull. It does not replace having looked.
The count is the smallest thing the hour gives you. That same afternoon turned up a company I had filed as one small account, which was four people at a firm I should have been speaking to directly, and a largest customer by revenue who was two accounts I had never connected because the names were spelled differently.
The tidy up that cost me a year of dates
When I found my first pile of duplicates I cleaned them the obvious way. Same person twice, keep the newer record, delete the older one.
That was wrong, and it took a month to surface.
The older record held the original signup date. Deleting it moved that customer’s start forward by about a year. My average customer age shortened. A cohort from the previous year lost a member retroactively, so a retention chart I had screenshotted in March no longer matched the same chart in April, and I could not tell which of my numbers had moved underneath me.
The repair is dull. Delete nothing. Add a column, give the surviving record a label, put the same label on the duplicate, leave both rows exactly where they sit. Count distinct labels when you want people. Count rows when you want accounts.
Merging destroys information. Tagging keeps it. I lost a year of honest signup dates learning a distinction I could have read in a paragraph.
The ones that never resolve
Some cases have no correct answer and I have stopped pretending otherwise.
An agency buying five subscriptions for five of its own clients is one payer and five businesses. If the agency walks, five businesses walk with it, so counting them as one hides a concentration risk. Counting them as five hides who holds the relationship. I count both ways and note which one I used.
Resellers are worse. So is a founder paying on a personal card for a company that will want a proper invoice in six months.
And I have no idea how many people sit behind the shared logins, because asking is intrusive and everything else is a guess. More plain English walkthroughs on the numbers a small business runs on are at dataresearchanalysiscollection.com.
Get new guides and videos first — join the Telegram channel.