The familiar name on the wrong account
In this invented example, Maya orders a desk lamp for her apartment on Monday. On Tuesday she orders twenty lamps for Cedar Studio, her employer. The shop recognizes her email address, combines the purchases, and sends the studio an invoice containing Monday's excellent personal taste.
Nothing is wrong with Maya's name. The error is deciding that the human who clicks Buy must be the customer in every transaction. A familiar contact detail has swallowed a business relationship.
Buying supplies the role
Customer means a person or organization purchasing goods or services. That definition leaves room for Maya to buy personally and for Cedar Studio to buy through Maya. The customer role answers who purchases; it does not automatically answer who operates the website, receives the parcel, or reads the invoice.
In an illustrative model, each order names its customer and may separately name a requester or delivery recipient. Those relationships make the distinction visible instead of forcing an email address to explain it later.
The person story explores why one human can appear in several roles. The organization story explains why a business remains itself when its representative changes.
The account is a useful container
A shop might maintain separate customer accounts for personal and studio purchasing. That can support different addresses, terms, or preferences. But an account identifier identifies an account in that system; it does not prove that every account belongs to a different person or organization.
Maya could have two personal accounts after forgetting a password. Cedar Studio could have separate accounts for two purchasing teams. Counting account rows as unique customers therefore makes a claim the data may not support.
The useful question is explicit: are we counting accounts, purchasing parties, or active buyers during a stated period? Each count can be useful. They become misleading when they share a label and quietly exchange denominators.
Let the documents keep their meaning
Cedar's order requests supply. Its invoice requests payment for what was supplied. Those linked records should preserve the intended customer rather than recomputing identity from whichever contact is current today.
From order to invoice follows that document journey. An invoice is not a receipt explains a second trap: becoming an invoiced customer does not itself mean payment has arrived.
Even an ordinary question such as “Who spends the most?” needs its scope. Which transactions, which period, which currencies, and which customer identity? A leaderboard is a surprisingly efficient place to hide several unanswered questions.
Relationships change; history still happened
Six months later, Maya leaves Cedar. Her employment relationship ends, but the studio's purchases remain the studio's purchases. Reassigning its contact should not rewrite those transactions into the next employee's personal history.
The contact story shows why a reachable mailbox can change hands without becoming a new buyer. Separating customer, representative, and contact gives each change a sensible home.
The shop can now recognize Maya warmly without guessing who is purchasing. Monday's lamp belongs to her account. Tuesday's twenty belong to Cedar. Good semantics has achieved something modest and valuable: an invoice that nobody needs to explain over lunch.
