POS and ERP User Permissions: How to Reduce Fraud, Mistakes and Unauthorized Changes

Why one shared administrator account is dangerous

Shared accounts remove accountability. When several people use the same username, management cannot reliably identify who changed a price, deleted a payment, adjusted stock or edited a customer balance.

A separate login is the minimum requirement, but it is not enough. The user must also have a role with clearly defined permissions.

Start with a role-and-task matrix

List the main roles in the business and the transactions each role should perform. Common roles include:

• Owner or director
• System administrator
• Branch manager
• Cashier
• Salesperson
• Storekeeper
• Purchase officer
• Accountant
• Auditor
• Support or implementation user

For every task, decide whether the role may view, create, edit, approve, cancel, export or delete.

Separate system administration from business approval

A technical administrator may need to create users or configure settings. That person should not automatically have authority to approve payments, discounts or stock write-offs.

Likewise, the business owner should not need unrestricted technical access for daily reporting. Separating these responsibilities reduces accidental and intentional misuse.

Control price and discount changes

Cashiers may need to select approved discounts without changing the product master or permanent selling price. Larger discounts can require a manager PIN or digital approval.

Useful controls include:

• Maximum discount by role
• Reason required for manual price override
• Approval above a defined amount
• Report of all overridden prices
• Restriction on below-cost sales

Protect sales cancellation and returns

Cancelled invoices and returns can be used to hide cash differences. The software should preserve the original transaction, record the reason and identify the user who requested and approved the action.

A return after the original shift or after payment settlement may need higher approval than a same-day correction.

Restrict stock adjustment

Stock adjustment changes the quantity without a normal purchase or sale. It should therefore be limited, categorized and reviewed.

Require users to choose a reason such as damage, expiry, physical-count difference, internal consumption or correction. High-value adjustments should require approval.

Use segregation of duties

One person should not control every stage of a sensitive process. For example:

• The requester creates a purchase request.
• A manager approves the purchase.
• The store receives the goods.
• Accounts verifies the supplier invoice.
• An authorized person releases payment.

Small businesses may not have enough staff for complete separation. In that case, use owner approval, exception reports and regular review.

Control backdated transactions

Backdating can change historical stock, cash and financial reports. Most users should work only in the current operational period.

Where backdating is genuinely required, define the permitted date range, require a reason and record the action in the audit log.

Limit data export

Exporting customer lists, prices, supplier records or financial reports may create confidentiality risk. Give export permission only to roles that need it.

Where possible, log exports and avoid exposing unnecessary fields.

Protect master data

Products, units, tax settings, customer credit limits and chart-of-account mappings affect many transactions. Limit who can change these records after go-live.

Changes to units and conversions deserve special care because they can affect stock quantity and valuation across the entire system.

Use branch and warehouse restrictions

A branch cashier should not normally view or alter another branch's cash transactions. A storekeeper may need access to one warehouse but not company-wide financial reports.

Multi-branch software should support both location-specific access and consolidated management reporting.

Review inactive and temporary accounts

Disable access promptly when an employee leaves, changes role or completes temporary work. Developer and support accounts should not remain permanently active without a clear reason.

Perform a quarterly access review and compare current permissions with actual job responsibilities.

Secure owner and administrator accounts

Use strong unique passwords and suitable multi-factor authentication where available. Do not share the owner password through informal messages.

Keep recovery email addresses and phone numbers under company control.

Build useful audit reports

An audit trail should answer:

• Who performed the action?
• What record changed?
• What was the previous value?
• What is the new value?
• When did it happen?
• Which branch or device was used?
• Was approval required?

Focus management review on high-risk events rather than trying to read every log entry.

Recommended exception reports

• Invoices cancelled after payment
• Discounts above the normal limit
• Negative stock sales
• Backdated entries
• Manual stock adjustments
• Edited customer credit limits
• New administrator accounts
• Transactions outside normal business hours
• Repeated failed logins
• Exports of sensitive data

Test permissions before go-live

Create sample accounts for each role and ask real staff to complete their daily work. Confirm that legitimate work is possible and restricted actions are blocked.

Permission design should be part of software evaluation and implementation, not an afterthought.

Do not rely on software alone

Access control supports management discipline but cannot replace physical stock counts, cash reconciliation, bank verification or independent review. Strong control combines software permissions with real operational checks.