Picture two stores with identical reports. Same monthly revenue, same average basket, same units sold, same top ten products in the same order. Every screen either owner opens matches the other almost line for line.

One of them has 200 customers who come five times a month. The other has 1,000 who come once and are never seen again.

Those are not two versions of the same business. The first has a base, and it can grow by selling a little more to people who already trust it. The second is on a treadmill, recruiting a thousand strangers a month to stay level, and it will stall the moment its acquisition slows. Nothing in either point-of-sale system distinguishes the two.

That is not a reporting gap you can close by exporting more data or paying for a better dashboard. It is structural, and it does not originate in your software. It originates in what a receipt is legally required to contain.

Your POS answers a different question than the one you're asking

A point-of-sale system is, at heart, an accounting instrument. It exists to record that goods left the store and money came in, to keep inventory honest, and to produce a document that satisfies a tax authority. It is exceptionally good at all three.

Its unit of record is the transaction. Every figure it reports to you is a sum, an average, or a ranking computed over transactions: units moved, revenue by category, sales by hour, stock remaining. Ask it anything whose subject is a thing and it answers immediately and correctly.

Ask it anything whose subject is a person and it goes quiet. Not because the answer is buried in a submenu, but because the transaction record has no column that points at a human being. There is nothing to group by.

This is worth sitting with, because it reframes the problem. Your reports are not wrong, and you are not failing to find the right screen. You are asking a question the data model cannot represent.

The receipt has no field for the buyer

The reason the transaction record ignores the customer is that the receipt was specified by tax authorities, and they had no reason to care who the buyer was.

Under EU VAT law, a full invoice must carry, in the words of Article 226(5) of the VAT Directive, "the full name and address of the taxable person and of the customer." But a retail sale over the counter is not issued as a full invoice. It is issued as a simplified invoice, and Article 226b lists what those must contain: the date of issue, identification of the supplier, identification of the type of goods or services, and the VAT amount or the means to calculate it.

Read that list again. The customer is not on it. Not their name, not their address, not any identifier at all. The regulation is entirely satisfied by a document that names the seller and describes the goods.

The same pattern holds outside Europe. Saudi Arabia's tax authority defines a Simplified Tax Invoice, the form used for retail, in its Detailed E-Invoicing Guideline as an invoice "generally issued for a B2C (business to consumer) transaction and does not generally include the buyer's details." The lone exception it carves out is for private education and private healthcare supplied to Saudi citizens, which exist for a VAT-treatment reason and prove the rule.

Two independent regulatory regimes, the same conclusion. The receipt is a document about the seller and the goods. The buyer is present at the counter and absent from the record.

Your POS implements that specification faithfully. It is not withholding customer data. It was never asked to collect any.

The card doesn't identify anyone either

The obvious objection is that most sales are paid by card, and a card is attached to a named human. Why can't the payment identify the customer?

Partly because the law says it cannot appear. In the United States, 15 U.S.C. § 1681c(g) states that "no person that accepts credit cards or debit cards for the transaction of business shall print more than the last 5 digits of the card number or the expiration date upon any receipt provided to the cardholder at the point of the sale or transaction." The one durable identifier passing through your counter is required to be truncated before it reaches the paper.

Some processors do expose a persistent token for a card, and where that exists it is genuinely useful. But it identifies an instrument, not a person. A customer with a debit card and a credit card is two customers. A card shared across a household is one customer who is several people. Someone who pays cash on Tuesday and by card on Friday is two strangers. And that token usually lives in your payment provider's systems rather than in the customer table your POS reports read from.

Cash removes the question entirely. Whatever share of your sales it still accounts for, every one of those transactions is anonymous by construction, and no amount of reporting will recover a name that was never captured.

Four questions your reports structurally cannot answer

Sort what you want to know by whether the subject is a thing or a person, and the line becomes obvious. Your POS is complete on one side of it and silent on the other.

Is this person new or returning? The single most important thing about a sale, and the transaction record does not know it happened to a repeat visitor.
What did they buy last time? Requires linking two transactions to one person. There is no key to link them with.
How often does a typical customer come back? Requires counting transactions per person, not per day.
Who has stopped coming? Requires knowing someone existed in order to notice their absence. An anonymous customer cannot lapse, because they were never present in the data to begin with.

Each of these is a question about a person. Each is unanswerable not because your reports are shallow but because the entity the question is about does not exist in the record.

Why the best-seller list can point the wrong way

Here is where the blind spot stops being abstract and starts costing money.

Take a range review, the routine decision of which products to keep. Suppose product A sells 400 units a month and product B sells 120. The best-seller report ranks A far above B, and if you are cutting, B looks like the obvious candidate.

Now add the customer dimension the report cannot see. Product A's 400 units went to 380 different people who each bought it once. Product B's 120 units went to 30 people who each bought it four times.

A is a commodity that anyone might pick up and nobody returns for. B is the reason thirty people choose your store over the one down the road. Cut B and you do not lose 120 units of revenue. You risk losing thirty regulars and everything else they put in the basket while they were in for it.

The arithmetic in that example is illustrative rather than measured, but the shape of it is not unusual, and the important part is this: both products produce the same kind of row in the same report, and the report gives you no way to tell them apart. Product-level truth and customer-level truth can point in opposite directions, and the tool on your counter only ever shows you the first one.

What changes when the sale carries a name

The fix is not a better report. It is a change to what gets recorded, and it is a small one: attach an identifier to the sale at the moment it happens.

Once a transaction carries a customer, every question in the previous two sections becomes ordinary. New versus returning is a lookup. Purchase history is a filter. Visit frequency is a count divided by a count. The reports do not need to be more sophisticated; they need one more column.

This is the side effect of sending receipts to a phone number rather than printing them. To deliver a receipt digitally you need a way to reach the customer, and the moment you have that, the sale is attached to a person. Waraqa is built on that sequence: the receipt is the thing the customer wants, and the customer record is what the store gets in return for delivering it.

From there the merchant dashboard reports on people instead of transactions: demographics, shopping patterns, top customers, and new customers per month. If you want the specific numbers worth watching and where each one comes from, we covered them in the six customer metrics every store owner should track.

What identity still won't give you

Attaching a customer to the sale removes a structural limitation. It does not make your data perfect, and a few things stay true afterward.

Coverage is never total. Some customers decline, some are in a hurry, and some transactions will stay anonymous no matter how good your process is. Plan on reading a representative sample of your customers rather than a census of them.

History does not backfill. The day you start is the day your customer data starts. Cohort questions that need a year of history need a year of waiting, which is the main argument for starting sooner rather than at a more convenient moment.

A phone number is a household as often as a person. Shared numbers merge several shoppers into one record, which quietly inflates frequency and flattens the demographic picture.

And identity tells you who and when, never why. It will show you that a regular stopped coming in March. It will not tell you whether they moved, were served badly, or found a shop closer to home. That part still requires talking to people.

Where to start

Do not begin by choosing metrics. Begin by checking whether the question you most want answered has a person as its subject. If it does, no amount of work on your existing reports will produce an answer, and you can stop looking for the screen that has it.

The concrete first step is to pick one question you have genuinely wondered about, in the "how many of my customers came back this month" family, and try to answer it from the reports you have today. The exercise takes ten minutes and it is unusually clarifying, because you will hit the wall in a specific place rather than a vague one, and you will know precisely what has been missing.

Waraqa turns receipt delivery into that missing column, so the answer exists the next time you go looking for it. New stores start with $5 in free credit, which is enough to see your own customers in the data before you decide anything.