Employee permissions on the register: who may cancel and refund

Employee permissions on the register should be set by action, not by seniority or trust. A regular seller makes sales and fixes a simple mistake. A manager approves an exceptional discount, a cancellation and a refund. The business owner keeps data export and permission changes for themselves. For every sensitive action, define a threshold, a recorded reason and the identity of who did it and who approved it.

Why a shared manager account is an operational problem

In a small shop everyone knows everyone, so it is easy to leave the register open under one user or give employees a shared manager code. It is convenient in the stressful moment, but later it is hard to answer basic questions: who canceled a transaction, who opened the drawer without a sale, who approved a discount and who changed a price manually. The problem is not necessarily a lack of trust. It is the lack of any way to reconstruct an event and fix a process.

Employee permissions on the register should separate identity, action and approval. Every employee has a personal user. Every role has actions it is allowed to do. And sensitive actions have a defined approver. That way a new seller does not depend on a password going around a messaging group, a shift manager does not need to come over for every small fix, and the business owner can check an exception without guessing who stood at the station.

Build a permissions map by action

Do not start with employee names. Start with the list of actions that happen at the counter, then decide which role does each action and when approval is needed. A simple split could look like this:

• Seller or cashier: opening a shift under a personal user, a regular sale, adding items, accepting payment methods and fixing mistakes before the transaction ends.
• Shift supervisor: approving a discount above the threshold you set, canceling a completed transaction, a refund according to the business's policy, opening the drawer without a sale and handling a difference during the shift.
• Branch manager: viewing the reports needed to manage the branch, checking exceptions, managing users at the branch and approving actions with a bigger impact.
• Business owner or system administrator: changing permissions, exporting data, setting up payment methods, changing business-wide rules and access to reports from several branches.

This is only a template. In a family bakery the same person may fill two roles, and in a small chain there may be a separate manager for each branch. What matters is not the number of roles but a clear line between a regular action, an exceptional action and a system change.

In KupaLi every employee logs in with their own code, and you decide what each role may do. On every plan.

Tell apart a correction, a cancellation and a refund

The words sound similar, but the operational risk is different. Correcting an item before completing the sale is a natural part of work at the counter. A cancellation after the transaction is completed changes a transaction that has already been recorded. A refund creates a money movement to the customer. So there is no reason to give all three actions the same permission.

Write a short definition the team understands for each action. For example: a "correction" is allowed as long as the transaction has not been closed. A "cancellation" requires a reason and in some cases approval. A "refund" is made according to the business's policy and in line with the original payment method and what the system can do. If the law, the card processing agreement or the business's policy requires different handling, they take precedence over the example.

The same distinction is needed for discounts too. A discount from a defined promotion is not the same as a manual price change, and a fixed employee discount is not the same as an improvised discount for a complaining customer. Define in advance what applies automatically, what is allowed up to a certain threshold and what requires approval. Do not use manager permission to override an outdated price again and again. If the same exception keeps coming back, fix the source of the price.

Opening the cash drawer without a sale deserves its own rule. Sometimes it is needed to make change or to count, but it is worth requiring a reason and keeping the employee's identity. That way the event does not look like an unexplained shortage after the fact.

Set an approval threshold you can work with

A good permission is not a wall that forces you to call a manager over every shekel. It is a decision path. Set a threshold that suits the prices, the profit margins and the shift structure of the business. You could, purely as an example, allow a cashier a small discount up to a certain rate and require approval above it. Do not copy a number from another business: ten percent may be marginal in one shop and a full loss in another.

For every sensitive action, define four things: who does it, who approves it, what the threshold is and which reason is recorded. The reason should be a useful choice, not a free-text field that always gets "other". A short list such as typing mistake, damaged product, outdated shelf price or service exception lets you spot a pattern. Leave "other" only with an explanation.

Also check what happens when the approver is not around. If only the business owner can approve a refund, the business will get stuck in the evening or at the weekend. You can define a backup shift supervisor and a lower threshold, or decide that the action waits for proper handling, as long as the customer gets a clear answer and the process is in line with the law and the business's policy.

Avoid approval by handing over a code. The approver needs to identify with their own user, not whisper a password to the seller. Otherwise the action log seems to show the right user, but not the person who really did the action.

An action log should answer questions, not just pile up lines

The NIST SP 800-53 Revision 5 control framework, whose publication page shows an update from 27 August 2025, includes control families for access and for audit and accountability. The framework is meant for systems and organizations of different kinds and is not a mandatory list for a register in Israel, but the principle is useful: limit access, identify users and keep records that make it possible to understand what happened.

In a small business, a useful log should let you connect an action, a user, a time, a station, a transaction, a reason and an approver. Not every employee needs to see the whole log, but whoever checks exceptions needs to get a sufficient picture. Searching by hand through receipts, messages and screenshots is no substitute for orderly records.

Set a short, regular check. Once a week, or according to how busy you are, go through cancellations, refunds, exceptional discounts, price changes and drawer openings without a sale. The goal is not to "catch" employees, but to spot a training mistake, a price that was not updated, a problematic product or a permission rule that does not fit reality.

Check an exception in context. An employee with three cancellations on a busy shift is not necessarily a problem. There may be an unclear screen or a duplicate barcode. On the other hand, a pattern that repeats near the end of a shift justifies a check. First collect the facts, then draw a conclusion.

Connect permissions to closing the day

Permissions are not separate from counting the till. If it is not clear who may cancel, refund or open the drawer, even a small difference at the end of a shift turns into an argument. The article on closing the register at the end of the day without fighting details how to separate the numbers and check gaps. A good permissions map adds the question of who did it and who approved it.

At every close, first check the known exceptions: refunds, cancellations, exceptional discounts, drawer openings and payment method changes. If an event is recorded with a reason and an approver, there is no need to reconstruct it from memory. If a reason is missing, flag it for follow-up while the shift is still fresh.

Do not turn the close into an interrogation in front of the whole team. The shift manager checks the data, asks for a focused clarification and records the fix. When the check is consistent and transparent, employees know in advance what will be checked and what is expected of them.

Joining, changing roles and leaving

On the first day of work, open a personal user with the limited role needed right now. Do not give permissions "just to be safe". After training and practice you can widen a role in a recorded way. The employee needs to know not only which buttons are available to them, but also when to stop and call an approver.

When a role changes, do not add a new layer without removing the old one. An employee who moved from one branch to another, from sales to management or from temporary shifts to a permanent role needs a permission that fits the new situation. Check the user themselves, not just the name of the group they belong to.

When someone leaves, block access at the end of their work and change any shared login details that still exist. Also check the tablet, a saved browser, the app and file exports. Revoking access for an employee who left is a small step that is easy to forget, especially when the working day is busy.

Assign a person who does this closing step. "The manager will take care of it" is not enough if there are several managers. A name, a date and a short checklist turn an intention into an action.

A short permissions check in a working business

Pick a quiet hour and a real station. Do not settle for reading the settings screen. Try the process the way an employee does it.

1. Log in as a regular cashier and try a sale, a correction before payment and a regular discount.
2. Try an action that is supposed to be blocked, such as a refund, an exceptional price change or an export, and make sure real approval is required.
3. Log in as the approver and check that their name, the time and the reason appear in the records.
4. Open the exceptions report or the action log and find the transaction without relying on memory.
5. Block a test user and make sure it is impossible to log in again from another device or from a session that was left open.
6. Write down one problem to fix, a person responsible and a date to check again.

Also check a pressure scenario: a long queue, the supervisor on a break and a customer asking for a refund. If the official process is too slow, employees will find a shortcut. The solution is not to open all permissions, but to shorten the approval path, define a backup or make clear which action may be done in the meantime.

Repeat the check after taking on an employee, a role change, opening a branch, a change in refund policy or a significant system update. Once a quarter it is worth going through the user list even when nothing special happened. A permission nobody checks tends to stay long after the need is gone.

What to take to work today

• Give every employee a personal user, not a shared manager code.
• Split permissions by action and role, not by general seniority.
• Tell apart a correction, a cancellation, a refund, a discount and a price change.
• Set a threshold, a reason and an approver for every sensitive action.
• Check exceptions in context and connect them to closing the shift.
• Revoke access immediately on a role change or when someone leaves.
• Practice the permissions at a real station and not only on the settings screen.

This is a general operational explanation, not legal advice or an information security assessment.