Who Can See the Customer Record? The Shared Login Problem
One account at the counter means every record is only as trustworthy as the least careful person on a busy morning. What a separate identity buys you, what it does not, and why a PIN nobody uses is worse than no PIN.
There is one account at the counter. It is called something like billing, or counter, or shop. Three people share the password, which is written on a slip of paper under the keyboard, or in a note in a phone that everybody can see. On a quiet Tuesday this is a convenience. On the fourteenth of the month, when four people are queuing and the stock count is late and one of them is new, it is the weakest point in the entire system. Every record written that morning carries the same name. Every correction made that afternoon carries the same name. The data is not wrong because anyone lied. The data is weak because the record cannot distinguish between a careful person and a careless one.
This is the first of four articles on data trust — whether a business can rely on its own records after the fact. The other three are about the trail that should let you reconstruct an action, the person who configured the system and then left, and the difference between a backup and a file you actually hold. All four share a shape: something is technically captured, and the capture is too thin to answer the question you will later ask. Here the question is the oldest one in the discipline, and it has a deceptively simple form: who changed this, and when?
The mechanismWhat a shared login actually does to a record
Start with what a record is supposed to be. A customer record is not just a name and a phone number. It is a sequence of events: this enquiry arrived, this person spoke to them, this quote went out, this invoice was raised, this payment came in, this discount was applied, this address was corrected. Each event has an actor and a moment. When the actor is a shared account, every one of those events is attributed to the same actor at every moment. The sequence survives. The attribution does not.
Notice what this does and does not mean. It does not mean the record is fake, and it does not mean the people using it are dishonest. Plenty of businesses run perfectly well on a shared counter login for years. The problem is narrower and more specific than corruption, which is why it survives so long: the record is complete in content and silent in authorship. You can read what happened. You cannot read who did it. Those are different capabilities, and only one of them is usually assumed to be present.
The word for this in access control is attribution, and it is worth separating from two things it is often confused with. Attribution is not the same as authorisation — knowing who did something tells you nothing about whether they were allowed to. And attribution is not the same as detection — you can attribute an action perfectly and still never look at it. A business with named logins and no review habit has better records than a business with a shared login and a daily review, and the second business will often be the one that catches the error, because a person is watching rather than a log.
The benefit, stated preciselyWhat a separate identity buys you
A separate identity per person buys exactly one thing at the record level: an actor field that points at a human being rather than at a counter. That is a real thing and it is not nothing. It changes the shape of every question you can ask afterwards. With a shared login, the only question available is what the record says. With named logins, a second question becomes available: what does the record say about the person who wrote it, and is that consistent with the rest of what we know about how they work?
It also changes the shape of a correction. On a shared login, a correction is an edit — the value was wrong, somebody fixed it, and the previous value is gone. On named logins, a correction is an event that happened to a person: this person changed this field, at this time, and the value before is on the record. This is the difference our own role-based access page describes when it talks about PIN-based staff access and an audit history of what changed and who changed it. That is the whole claim, and it is a narrower claim than most software makes.
The 18% GST figure used in the worked examples below appears only to keep the arithmetic checkable so you can verify the totals by hand. It is not a statement about the rate that applies to your business, and nothing in this article is tax advice. Confirm your rate, your place of supply, and your invoice treatment with your own chartered accountant.
Illustrative: the same day, read two ways. All figures constructed for this article.
| What you want to know | One shared counter login | A login per named person |
|---|---|---|
| Who issued invoice I-2241 at 10:42 | The counter account issued it. No further narrowing is possible. | The record names the individual account that issued it. |
| What the tax-exclusive value was before 10:42 | Not available. The current value is all that exists. | Available, as the prior value on the change event. |
| Was that person permitted to apply that discount | Cannot be answered from the record at all. | Still not answered by the record alone — the permission has to be checked against the role that was configured for that person. |
| If the person disputes it, what happens next | A conversation with three people who all used the same account. | A conversation with one person, plus a change event with a time on it. |
Here is a worked example, constructed for this article, to make the difference visible in money rather than in principle. On a given morning the counter raises two invoices for the same list price. The first carries a discount someone negotiated on the phone. The second is the same item at full price.
Invoice A, constructed: list price 10,000. GST at 18 percent, used only so the arithmetic below is checkable: 10,000 multiplied by 0.18 is 1,800. Total on invoice A: 10,000 plus 1,800 is 11,800.
Invoice B, constructed: the same list price with a discount of 2,000 applied to the taxable value. Taxable value 10,000 minus 2,000 is 8,000. GST on 8,000 is 1,440. Total on invoice B: 8,000 plus 1,440 is 9,440.
The gap between the two invoices is 11,800 minus 9,440, which is 2,360. You can also check it a second way: the discount itself is 2,000, and the GST given up with it is 2,000 multiplied by 0.18, which is 360. 2,000 plus 360 is 2,360. The two routes agree.
Now the question. Two invoices, same morning, same list price, 2,360 apart. Six weeks later a manager wants to know whether that discount was agreed and who agreed it. On a shared login the answer is that the counter issued both invoices, and the only way to resolve the question is to ask three people whether they remember offering it. On named logins the answer is at least narrower: it names the person, it names the time, and it shows the value before the change. Whether that person was authorised to offer it is still a separate question — but it is now a question about a role, rather than a question about memory.
The limit of the claimWhat a separate identity does not buy you
Separate identities do not stop the discount. They do not stop a cancellation, a refund, or a payment being recorded against the wrong invoice. They do not stop somebody from handing their phone to somebody else, or from writing the PIN on a paper under the keyboard — which is a shared login wearing a hat. And they do not stop a well-meaning person from doing something outside their role, because a named account is not a boundary, it is a label.
They also do not solve the review problem, and this is the most commonly skipped part. Populating every event with a real name produces a long list that nobody reads. Attribution without attention is a filing system, not a control. If the answer to who gave the discount is going to be produced in six months, somebody has to have looked at it in the six weeks after, when it would still have been possible to ask the person while they remembered.
Be precise about the third limitation as well. Naming the actor tells you the action happened under that account. It does not by itself tell you the action was permitted, and it certainly does not tell you the action was correct. Permission lives in the role configuration, and correctness lives in the comparison between what was agreed and what was recorded. Those are separate systems, and no amount of login design fuses them.
The control that looks like a controlThe PIN nobody uses is worse than no PIN
There is a specific and very common compromise. The business cannot afford to give every counter person a full login, so it gives them a shared login plus a PIN. The theory is that the PIN identifies the person at the point of sale. In practice the PIN gets typed once at the start of a shift and then left active, because the alternative is to type it on every invoice while a queue is waiting. Nobody is lying. The control has simply been routed around by the only mechanism available: time pressure.
This is worse than having no PIN, and the reason matters. With no PIN, everyone involved knows the system does not know who did what. That is uncomfortable, and discomfort produces a decision. With an unused PIN, everyone believes the system knows who did what, because there is a field on the record with a name in it. The control has been satisfied in appearance while providing nothing in substance. A control that looks present and is not gets no review, because there is nothing to review — and it removes the pressure that would otherwise have produced a real one.
A constructed count makes the shape of the problem visible. Take a counter that issues 412 invoices in a month. It runs two shifts a day for 30 days. Say three people share the device and each authenticates once per shift. Sign-ins for the month: 3 multiplied by 2 multiplied by 30, which is 180. Invoices issued: 412. Invoices issued without a fresh authentication at the point of sale: 412 minus 180, which is 232. Every one of those 232 was attributed to a person who may not have been at the counter when it was raised.
The fix is not a faster PIN entry. It is to move the authentication to somewhere it is not competing with a queue: sign in once per person per shift on a shared device, and lock the session between them rather than at every invoice. The design goal is that the cost of authenticating never sits inside a customer-facing moment. A control that costs a sale is a control that will be bypassed, and a bypassed control that still fills the name field is the specific failure this article is about.
Illustrative: what attribution does and does not settle
It settles who
Which individual account performed an action, and when that action was performed. This is a genuine gain over a shared login and it is the one worth having.
It does not settle whether
Whether the person was permitted to do it. Permission lives in the role configuration and has to be checked separately against the role as it stood at the time.
It does not settle whether anybody looked
A populated actor field produces a list, not a review. Without a recurring habit of reading it, attribution is a filing system rather than a control.
The question to be able to answerThe audit question: who changed this, and when
If you take one thing from this article, take the question. Who changed this, and when. It is short enough to ask at a counter and specific enough to have a real answer. Most businesses cannot answer it for a customer record today. Ask it about an invoice and a surprising number of them cannot answer it either.
The question also has a useful property: it is answerable by someone who is not technical and does not need to know anything about how the system stores anything. If your honest answer to a colleague asking it is that you would need to check with support, you have learned something useful at no cost. That check is the test.
The four questions to ask before you accept an access model
These are the questions that separate a control from a description of one. They are written so that an owner, not an administrator, can ask them.
1. Who performed this specific action, and at what time? Not who has access to the area. Who performed this action. A role is a capability; a named person is an actor. If the answer names a role and not a person, the record is shared.
2. What did this value say before the change? A change with no prior value is an overwrite, not a change. You can see what it says now. You cannot see what it said, which means you cannot see the size or the direction of the edit.
3. Was the person who did it permitted to do it, under the role they had at the time? This is a separate lookup from question 1, and it is the one most often skipped. Roles change. What matters is the role as it stood when the action happened, not as it stands now.
4. When did a person last look at this? Attribution without review is storage. If the answer is that nobody has looked at the actor field since the day it was switched on, the control is present in form and absent in substance — the same shape as an unused PIN.
If all four have real answers, the access model is doing work. If any of them comes back with a shrug, that is the gap — and it is worth closing before adding anything else, because every other record in the system inherits the weakness of its weakest attribution.
One practical note on scope. Separation of duties is a real concept and it is worth understanding before you try to apply it. A person who raises a quote, raises the invoice against it, records the payment, and closes the day has not been checked by anyone, because they have checked themselves. Our glossary page on roles and permissions sets out the vocabulary — role, capability, scope, threshold approval, override, separation of duties, least privilege — in the terms the system actually uses, and it is worth reading before you design anything.
For a business at a counter, the realistic version is smaller than the textbook version. It usually comes down to three things: the person at the counter cannot also be the person who authorises a discount above the ceiling, the person who raises a quote is not the only person who can convert it, and the person who reconciles a payment at day-end is not the person who counted the cash. None of that needs a large team. It needs the decision written down rather than assumed.
A review you can do this week, without changing any software
- List every account that can currently reach customer or invoice data, and mark each one as named to a person or shared. Be honest about the paper under the keyboard.
- For each shared account, count the people who use it. That number is your attribution gap, stated as a fact rather than a worry.
- Pick one invoice from last month and ask who raised it. Write down the actual answer, including the answer that is that you would have to ask around.
- Identify the one action where a silent change would cost you the most — usually a discount, a cancellation, or a payment allocation — and check whether its prior value survives.
- Decide who reviews the actor field, and put it in a diary. A control without a named reviewer is a control that is not running.
- Write down the discount ceiling per role on one page, and check it against what the system is actually configured to allow. Divergence here is the most common finding.
Frequently asked questions
Is a shared counter login actually dangerous, or just untidy?
It is not unsafe in the sense of being breached, and it is more than untidy in one specific respect: it makes attribution impossible. Every action carries the account name, so you can read what happened but not who did it. The risk is that a mistake cannot be traced, so it cannot be corrected, understood, or prevented — and a business that cannot trace a mistake tends to correct it the same way every time.
What does a separate login for each person actually give me?
One concrete thing: an action can be attributed to a named person with a time on it. That lets you ask who changed this and when, and lets a correction carry the value it replaced. It does not tell you whether the person was permitted to act, and it does not tell you whether anyone reviewed it. Both of those are separate work.
We use a PIN at the counter. Is that not the same thing?
Only if the PIN is entered every time an action happens. In practice a PIN typed before a queue arrives stays active for the rest of the shift, and the attribution it was meant to provide does not exist for most of the day's invoices. A PIN that is never used is worse than no PIN, because it leaves a name on the record and gives everyone the impression the system knows who acted.
How do we review this without adding a manager to the process?
Pick the one action where a silent change would hurt most — usually a discount, a cancellation, or a payment allocation — and review only that, once a week, for a few minutes. Narrow scope is what makes a review habit survive contact with a busy week. A review of everything is a review that stops.
Does any of this tell me whether the discount was correct?
No, and it is worth being clear about that. Identity answers who. Permission answers whether they were allowed. Correctness is a third question, answered by comparing what was agreed with what was recorded — which is a different article and a different record.