Access in a small business runs on shared logins. The owner creates one admin account, everyone uses it, and the password goes round on a sticky note. It works until the day an invoice is cancelled, a rate is changed or a salary figure is seen by the wrong person — and nobody can say who did it.
The access problem nobody solves with a new password
The usual response is to change the password and tell people to be careful. That changes nothing about how access actually works:
- Everyone sees everything. The storekeeper can open payroll, and the billing clerk can edit the ledger.
- Branches are mixed together. A user at one branch can change stock at another.
- Sensitive actions have no owner. Anyone with the login can cancel an e-invoice.
- The record of changes is weak. Even where a log exists, nobody trusts that it was not edited.
- Setup lives in one person's head. Numbering, templates and financial years were set once and never written down.
The gap is not carelessness. It is that the business was never set up with its structure inside the system.
What changes when the organization is set up properly
Branches with their own warehouses
Each branch is a physical location — an office, store or plant — with its own address and staff. Each branch can have one or more warehouses linked to it, so stock is tracked by location. Reports can then be run branch by branch for sales, stock and finance.
Departments that group people
Departments such as Sales, HR, Production and Accounts group employees by function. Each department has a colour code for quick identification across calendars, reports and dashboards.
Roles made of permissions
A role is a job — Sales Manager, HR Admin, Accountant — and it is a set of permissions, which are single actions like creating an invoice or viewing a report. One user can hold more than one role. Permissions go down to individual actions such as raising an e-invoice, so a junior operator can raise a bill without holding the compliance action.
Access per user and per branch
Access is set per user and per branch. A storekeeper at one plant works on that plant's warehouses, and an accountant can reach the ledger without opening payroll.
A log that cannot be quietly rewritten
Every change is written to a hash-chained audit log. Because each entry is chained to the one before it, the record of who changed what is tamper-evident — an edited entry would break the chain.
Settings that keep every module consistent
Organization settings hold the rules the other modules follow:
- Financial years from April to March, with opening balances.
- Document numbering — prefixes, series and auto-numbering for every document type.
- Templates — print formats, document layouts and terms and conditions.
- Shifts, holiday calendar, leave types and work week for HRMS.
- Batch rules and prefixes for stock.
- Status workflows and lead stages for CRM.
- Import and export of data, for moving masters in and out.
What this looks like in practice
Consider a manufacturer with a head office in Ahmedabad, a plant in Vapi and a sales depot in Pune.
The owner sets up three branches, links the Vapi plant to its raw material and finished goods warehouses, and creates departments for Sales, Production, Stores, Accounts and HR. Then roles are created:
- Storekeeper, Vapi — inward stock, bins and cycle count, for the Vapi warehouses only.
- Billing clerk, Pune — sales documents for the Pune depot, without e-invoice cancellation.
- Accountant — ledger, journals, tax and reports, without payroll or pricing.
- HR executive — prepares payroll; a director releases it.
Three months later, a customer disputes a rate change on an invoice. The audit log shows who changed it, when, and from which role — and because the log is hash-chained, nobody questions whether it was edited afterwards.
Nothing here makes the team work faster. What it does is replace one shared login with a structure people can trust — which is where most internal disputes quietly start.
Where this meets the rest of the business
Organization is included with every module, not sold separately, because every other module depends on it.
- Stock: warehouses belong to branches, and batch rules come from settings.
- Sales and purchase: document numbering and templates come from settings.
- Accounts: the financial year and period locking start here.
- HRMS: departments, shifts, holidays and leave types are set here.
- Your CA: a login can reach the ledger, tax and reports without opening payroll or pricing.
A note on security
Data moves over encrypted connections, backups are taken on a regular schedule, and access is controlled by role. Single sign-on with SAML or OAuth2 is not available today — users sign in with their own credentials. Unnati holds no security certification today and does not claim one.
The Why Unnati page explains the maker-checker controls and the hash-chained audit trail, and the security page sets out the full position on data and access.
Key takeaways
- A shared login makes it impossible to say who did what.
- Roles should be built from single actions, not from whole modules.
- Access set per user and per branch keeps each location's data separate.
- Sensitive actions like cancelling an e-invoice need their own permission.
- A hash-chained audit log makes the record of changes tamper-evident.
- Numbering, templates and financial years should be set once, in one place.