ERPHow-to guide
Roles, permissions and change history when several companies share one ERP
Running several companies in one ERP saves a lot of duplicated work: one product list, one set of processes, one place to see the group. It also raises a fair question from every accountant and manager involved: who can see and change what? The answer should not depend on trust or memory. It should be visible in the configuration, enforced by the system and easy to review. This guide walks through the decisions in the order that keeps them simple.
Decide what a company boundary means
Each legal entity has its own tax identifier, invoice series, chart of accounts, bank accounts and fiscal obligations. Those must stay separate. Other things are often shared on purpose: the product catalogue, customer records used by several companies, price lists or a central warehouse. Write down which records belong to one company and which are shared, before anyone creates a user.
The boundary is enforced through permissions scoped to a company, not through separate logins or naming conventions. A user who works for two companies has one account with access to both, and every document they open shows which company it belongs to. That keeps the history attached to a real person instead of a shared login.
Design roles from tasks, not job titles
Job titles vary between companies in the same group, and people change jobs. Tasks are more stable: issuing invoices, approving supplier orders, posting bank statements, adjusting stock. Build roles around these tasks and give each person the combination they need, scoped to the companies where they do that work.
Separate creating from approving wherever money or stock leaves the business. The person who registers a supplier should not be the only one who can change its bank account. The person who posts a payment should not be the one who approves it. A small table like the one below is usually enough to agree the first version with the finance lead.
| Role | Can | Cannot |
|---|---|---|
| Sales operator | Create quotations, orders and invoices for assigned companies | Change prices below the approved list or post accounting entries |
| Purchasing operator | Raise purchase requests and supplier orders | Approve their own orders or edit supplier bank details |
| Warehouse | Receive, issue and transfer stock in assigned warehouses | Change item valuation or delete posted movements |
| Accountant | Post entries, reconcile banks, close periods for assigned companies | Approve payments they have prepared |
| Group controller | Read all companies, run consolidated reports | Edit operational documents |
Set approval limits that follow the money
Approval rules work best when they depend on amount, company and document type rather than on who happens to be in the office. A supplier order under a set value might need one approval; above it, a second approver from finance. Approval limits can differ per company, which matters when a smaller entity in the group has tighter cash flow than the parent.
Plan for absence from the start. Every approver needs a named deputy, and delegation should be time-limited and recorded, so a holiday does not turn into a shared password or a stack of orders waiting a week.
Handle shared services and intercompany work
Groups often have one finance team or one warehouse serving several companies. Give those people access to each company explicitly, rather than a group-wide role that also opens companies they do not serve. When one company sells to another, the sales invoice in the first and the supplier invoice in the second should be linked records, so both sides agree on amount and date and the intercompany balance can be checked at month end.
Make change history part of normal reviews
A full change history records who changed which field, from what value to what value and when. It is only useful if someone looks at it. Build a few views into regular routines instead of opening the log only after a problem.
Keep the history read-only for everyone, including administrators, and keep it for as long as the accounting records it relates to.
- Changes to supplier and customer bank details in the last month, with who approved them.
- Posted documents that were cancelled or amended, grouped by user and company.
- Price or discount changes on approved orders.
- Role and permission changes, including temporary delegations.
- Periods reopened after closing, with the stated reason.
Run a quarterly access review
Access tends to grow quietly: a temporary permission that was never removed, a person who moved from sales to purchasing and kept both roles, an external accountant whose engagement ended. A short review each quarter, owned by the finance lead and the managers of each company, keeps the picture accurate.
Export the list of active users, their roles and the companies they can access. Each manager confirms or removes the lines for their team. Accounts that have not been used for a defined time are disabled, and changes are made in the system so they appear in the history. The review itself is recorded, which is often what an auditor asks to see first.
How RDCopilot sets this up
RDCopilot ERP runs several companies in one system, with roles and permissions scoped per company, approval rules by amount and document type, and a full change history on master data and posted documents. The same roles carry into RDCopilot CRM, accounting, HR and reports, so a user who cannot see a company’s ledger does not see it in a dashboard either. Mobile apps for sales or warehouse teams use the same accounts and permissions, and integrations use scoped access rather than an administrator login.
During implementation we agree the company boundaries, the role table and the approval limits with your finance lead, configure them, and run a test review together before go-live. The implementation is a one-off fee; a monthly subscription covers EU hosting, updates and support; extra work is billed at a fixed hourly rate. If you already have a list of users and what each one does, bring it to the first call and we will turn it into a first role design.
Inside the product
ERP
Follow the references
Sources & inspiration
AuditGuardX
Devpost project by Patrick Ejelle-Ndille
Independent compliance project with role-based access, organisation-scoped data isolation and audit logging; inspiration for company-scoped roles and reviewable history.
This independently created project is credited as inspiration. The workflow and implementation guidance in this article are RDC’s analysis.
Put the guide to work
Start with your workflow.
Tell us what your team needs to do, which systems are involved and where the current process slows down.