Shared logins at the till: why every member of staff needs their own account

Plenty of businesses have one: the single PIN everyone knows. It is convenient. A new temp can start straight away, nobody has to create an account late at night, and in the Friday-evening rush no one wants to stop and ask. That is exactly why the habit is so persistent – it solves a real problem.

It just creates a different one. Everything your till records about a transaction hangs on who triggered it. If that “who” is the same for everybody, the record only ever gives you half an answer.

What a shared account hides

Most transactions at a till are uncontroversial: goods in, money out, receipt printed. It gets interesting with the interventions alongside them – cancellations, discounts, price overrides, reopened tabs. These are entirely normal and happen legitimately every day. They are simply the points where someone might ask questions later.

With individual accounts there is an answer to that question: name, time, reason. With a shared account there is none – not because anything was deleted, but because it was never recorded in a way that could tell people apart. For a tax inspection that is an obvious place to start, and it is just as awkward for you internally: you cannot work out where a discrepancy came from either.

What DiKAS records for every transaction

In DiKAS every receipt carries the operator who created it – by number and by name. For a cancellation, more is added:

• The cancellation creates its own receipt referencing the original. Nothing is overwritten.
• It records who cancelled – and, separately, who booked the original tab.
• A reason for the cancellation goes with it.

These details also reach the DSFinV-K export an inspector asks for: it carries an operator ID and name per transaction. That is where it is decided whether your records make a statement or merely supply a number. (For how DSFinV-K and the TSE fit together, see our article on the TSE requirement.)

The cancellation level: a safeguard that only works with individual accounts

DiKAS has three cancellation levels, set per member of staff:

• none – cannot cancel,
• own – can only cancel receipts they booked themselves,
• all – typically shift leads and owners.

The middle one is the interesting one: for most businesses it is the right setting for front-of-house staff. And it stands or falls with individual accounts. “Own receipts only” is checked against the operator stored on the receipt – if everyone works under the same account, every receipt belongs to everyone. The level is then formally set and practically useless, without anything producing an error message.

The same goes for the other till permissions: discounts, cash drawer, day-end close, viewing turnover. Assigning rights per member of staff only makes a difference if there is an account per member of staff.

Why people share anyway – and how to remove the obstacle

The reason is almost never carelessness; it is speed. If switching between two operators is a nuisance, the short cut wins. So in DiKAS switching is deliberately quick:

• Operator switch on the same device: pick your colleague from the list, enter the PIN, carry on. No signing out, no restarting the till.
• Staff card: tap the card instead of typing – the same card also clocks working time.
• Short names instead of full names: the operator list shows what the team says anyway.

When switching takes two seconds, there is no reason left for the shared PIN. That is the real lever – not the reminder, but the obstacle removed.

Offboarding: disable, don’t delete

The second half of the problem is the ending: someone leaves and their access stays open. In hospitality, with its staff turnover, that quickly adds up to a handful of accounts nobody can account for – with PINs still in circulation.

One thing matters here: disable, do not delete. A disabled account cannot get in any more, but all past transactions stay attributable. That is exactly what you need – for traceability as much as for payroll’s final monthly close. Deleting a member of staff would destroy the very answer the individual accounts have just given you.

Don’t save the disabling for the day someone leaves – that day is usually busy. Do it when the notice is on your desk and things are calm.

A short checklist

1. One account per person – including temps, including for two weeks.
2. Set the cancellation level deliberately: “own” for front-of-house, “all” for shift leads.
3. Don’t pass PINs around – the operator switch is quicker than explaining the shared PIN.
4. Disable the account when someone leaves, don’t delete it.
5. Review the staff list once a quarter: who is still listed, who still works here?

Conclusion

Shared logins are not a paperwork slip, they are a blind spot: they make the record your till keeps anyway useless for the one case in which you need it. The effort to change is modest – one account per person, a suitable cancellation level, a disabled account at the farewell. The difference only shows when someone asks. Then it shows clearly.

Want to see how permissions, operator switching and reports work together in DiKAS? Try DiKAS for free or take a look at the feature overview.