In a great many Nepali businesses, every employee with a login can see almost everything. The sales executive can open the payroll screen and read what every colleague earns. The new warehouse assistant can view the cost price of goods and work out the margin on every sale. A junior accountant can change a posted transaction from last month and nobody is the wiser. This is not because the owner wants it that way - it is because the software was set up with one level of access for all, and tightening it never reached the top of the list. Role-based access control is the discipline that fixes this: each person sees and does only what their role requires, and nothing more.
The cost of open access is quiet but real. Salary information leaking across the office breeds resentment and resignations. Cost prices and customer credit limits visible to everyone are exactly the data a departing employee carries to a competitor. And a system where anyone can edit anything has no real accountability, because when a number changes there is no way to say who changed it or whether they were allowed to. Limiting access is not about distrust - it is about giving each person a clean, focused view of their own work and protecting the sensitive data that has no business being on every screen.
Role-based access control turns a vague intention to restrict data into a structure the business can actually run. Instead of setting permissions person by person, you define roles - accountant, sales, warehouse, HR, management - decide once what each role may see and do, and assign people to roles. When someone joins, leaves, or moves teams, you change their role, not a tangle of individual settings, and the right access follows automatically.
What Role-Based Access Control Actually Is
Role-based access control ties permissions to roles rather than to individuals. A role is a named bundle of what a kind of user may do: the accountant role can create and view vouchers, run financial reports, and reconcile the bank; the sales role can raise quotations and invoices and see customer balances but not cost prices; the warehouse role can record stock movements but cannot touch payments. You define these bundles once. Then every person is assigned a role, and they inherit exactly that role's permissions - no more, no less.
The power of this is in how it scales and how it stays correct over time. Setting permissions one person at a time works until you have ten staff and then becomes impossible to keep straight - nobody can say with confidence what any given user can actually see. With roles, the answer is always clear: a person's access is whatever their role grants. When a salesperson is promoted to sales manager, you move them to the manager role and their access changes in one step. When someone leaves, you disable the account and the access goes with it. The structure does the remembering, so access does not silently drift out of line with what people actually need.
Good access control works at two levels. The first is the screen or module - whether a role can even open payroll, or purchasing, or the financial statements. The second, finer level is the individual field - whether a role that can open a screen can also see a particular value on it, such as a salary figure or a cost price. Both levels matter, and the difference between them is where most of the practical value of access control actually lives, as the next sections show.
Role-based access control attaches permissions to roles, not people. You define what each role may see and do once, then assign people to roles, so access scales cleanly and stays correct as staff join, move, and leave - you change a role, not a tangle of individual settings.
Why Limiting Access Is Both Security and Compliance
Restricting access protects the business on two fronts at once. On security, every screen a person can reach is a place data can leak from - copied, photographed, or simply remembered and carried elsewhere. The fewer people who can see salaries, margins, customer lists, and credit limits, the smaller the surface from which that sensitive information can escape. This is the principle of least privilege: give each person the minimum access their job needs, and a careless action or a departing employee can do far less damage because there is far less within their reach.
On compliance and control, separation of duties is a core safeguard against fraud and error. The person who creates a payment should not be the only person who can approve it; the person who records stock should not also control the financial postings unchecked. Role-based access lets you enforce these separations by design rather than by trust, so that no single role can carry a transaction end to end without another role's involvement. Auditors look for exactly this, and a business that can show clean role separation has a far easier audit than one where everyone could do everything.
The common Nepali setup, where one accounting login is shared and all staff effectively have the same access, undermines both the IRD audit trail and the separation of duties expected under the Company Act 2063 for proper books. When a tax assessment or a statutory audit asks who recorded or amended a transaction, a shared login can only answer "someone in the office". Distinct roles with named users, each scoped to what their job requires, mean the books can show who did what, in both the Bikram Sambat and AD record, which is what stands up when the IRD or an auditor asks.
Least privilege shrinks the surface from which sensitive data can leak, and separation of duties stops any single role from carrying a transaction end to end unchecked. Together they make access control both a security safeguard and a compliance requirement, not a convenience.
A Starting Role Matrix for a Nepali Trading Business
Here is a practical starting point. The matrix below maps five common roles in a Nepali trading business against the data areas that most need control. Treat it as a template to adjust to your own structure, not a fixed rule - a small business may merge HR into management, while a larger one may split accounts into entry and review roles. The aim is that each role sees what it needs to work and is kept clear of what it does not.
| Data Area | Accountant | Sales Staff | Warehouse | HR | Management |
|---|---|---|---|---|---|
| Sales invoices and quotations | View and edit | Create and edit | No access | No access | View all |
| Purchase bills and payments | Create and edit | No access | No access | No access | View and approve |
| Product cost price and margin | View | Hidden | Hidden | Hidden | View all |
| Customer credit limits | View and edit | View only | No access | No access | View and set |
| Stock levels and movements | View | View available | Create and edit | No access | View all |
| Salary and payroll data | View totals only | No access | No access | Create and edit | View all |
| Employee records | No access | No access | No access | Create and edit | View all |
| Financial statements | View and build | No access | No access | No access | View all |
| User and access settings | No access | No access | No access | No access | Full control |
Notice how often the right answer is "hidden" rather than "no access". Sales staff need to open the sales screen and the product list to do their job, so blocking the whole screen is wrong - but they have no reason to see the cost price sitting on that same screen. That is field-level control, and it is the difference between a role that can work freely and one that is also kept clear of data it should never see. A matrix that only thinks in whole screens cannot express this, and ends up either over-exposing data or blocking people from doing their jobs.
Five roles - accountant, sales, warehouse, HR, management - cover most Nepali trading businesses. Start from a matrix like the one above and adjust to your structure, and notice how much of the value comes from hiding specific fields like cost price within a screen a role still needs to use.
Field-Level Security and an Honest Audit of Access
Field-level security is what makes access control precise instead of blunt. Whole-screen permissions force a crude choice: either a person can open a screen or they cannot. But real work rarely divides that cleanly. A salesperson needs the product screen to raise an invoice, yet should not see the cost price printed beside each item. A junior in accounts may need to enter vouchers but should not see the running profit on the dashboard. Field-level control answers this by hiding or making read-only the specific values a role should not have, while leaving the rest of the screen fully usable. The person does their job without friction, and the sensitive number is simply not there for them.
The other half of accountability is the record of who accessed and changed what. An access log captures the action - this user opened this record, edited this field, ran this report, at this time - so that when a figure is wrong or a dispute arises, there is a clear answer rather than a shrug. This is accountability, not surveillance, and the distinction matters for how it lands with staff. The point is not to watch people's every move; it is that the system can answer the question "who changed this?" when it needs to. Telling the team plainly that the system keeps this record, and that it exists to protect everyone by removing the guesswork when something goes wrong, turns it from a thing done to staff into a normal part of how a trustworthy business runs.
Put together, role-based access, field-level security, and an honest access log give a business control without paranoia. People get a clean view of their own work, sensitive data stays with the roles that genuinely need it, and when a question of who did what comes up, the system answers it. That is a long way from the shared login where everyone sees everything and no change can be traced - and it is reachable by any business willing to define a few roles and stick to them.
Field-level security hides specific values like salary or cost price within screens a role still needs, and an access log answers "who changed this?" without watching every move. Framed and communicated as accountability rather than surveillance, the two give control without breeding distrust.
Frequently Asked Questions
Start with the smallest set of roles that captures real differences in what people do - for most Nepali trading businesses that is the five in the matrix above: accountant, sales, warehouse, HR, and management. A very small firm might merge HR into management and run with four. The mistake to avoid is the opposite extreme of one role per person, which recreates the unmanageable person-by-person setup that roles are meant to replace. Roles should describe kinds of work, not individuals. Add a new role only when a genuinely distinct set of duties appears - for example, splitting accounts into a data-entry role and a review-and-approve role as the team grows.
No, and the difference is what makes access control usable. Blocking a screen stops a person opening it at all, which is right when the role has no business there - a warehouse user has no reason to open payroll. Hiding a field keeps the screen open and working but removes specific values from view, which is right when the role needs the screen but not everything on it. A salesperson must open the product list to raise an invoice, yet should not see the cost price beside each item. Field-level hiding lets them work normally while the sensitive number simply is not shown, where blocking the whole screen would stop them doing their job.
That depends entirely on how it is introduced. An access log is there to answer "who changed this?" when a figure is wrong or a dispute arises - it is accountability, not monitoring of how hard someone is working. The way to keep it from feeling like surveillance is to be open about it: tell the team the system keeps a record of changes, explain that it protects everyone by removing guesswork when something goes wrong, and apply it evenly to all roles including management. Handled this way it reads as normal professional practice, the same reason a bank records transactions. Handled secretly, any monitoring breeds suspicion, so the openness is the point.
Access Scoped to the Role, Down to the Single Field
MISAC is built so access control reaches the individual field, not just the screen. Every form, field, and dropdown can be hidden or made read-only for a user group through configuration, so a sales role can work the invoice screen freely while the cost price beside each item is simply not shown, and a payroll figure stays visible only to HR and management. Because this is config-driven, an administrator sets it up without a developer, and the matrix you design for your business - the five roles above or your own variant - is something you can actually put in place and adjust as the team changes. New roles and new restrictions are a settings change, not a software project.
Because MISAC is accounting-first, every transaction posts a complete double-entry journal under a named user, and the full audit trail records who created, edited, approved, or returned each voucher and when. That turns the access log from an add-on into a natural by-product of how the system works - the answer to "who changed this posting?" is always there. The Nepal compliance built into the platform means this stands up where it counts: distinct named users with role separation give the IRD and a statutory auditor a clear trail of who recorded and amended each transaction, in both Bikram Sambat and AD, rather than the "someone in the office" that a shared login leaves behind.
MISAC Intelligence Pvt. Ltd. has set up role structures and field-level access for Nepali trading, distribution, and multi-branch businesses, mapping each role to how the team actually works and keeping sensitive data with the roles that genuinely need it. Reach us at mis.ac to design the access matrix for your business and put it in place without touching code.
Ready to See MISAC in Action?
If everyone in your business can still see salaries, margins, and every transaction, see how role-based access and field-level control give each person only the data their job needs.