ERP authorisations decide who can see and change what in the system. In projects they are often left to the end and solved with broad access "so everyone can work at go-live". The result is risks that surface in audits and errors that go unnoticed.
What is segregation of duties (SoD)?
Segregation of duties ensures that no single person controls a transaction from start to finish. Classic examples:
- The person who changes supplier master data should not be able to pay the same supplier
- The person who changes prices on a sales order should not be able to raise the customer's credit limit
- The person who creates a purchase order should not approve both the goods receipt and the invoice for it
These conflicts directly increase the risk of both error and fraud.
Role-based authorisation design
- Define business roles: start from real jobs such as "sales rep", "credit manager", "accountant", not from individuals.
- Link each role to transactions and data: which transactions, for which company codes or sales organisations, display only or change?
- Build the SoD matrix: write down the role and transaction combinations that must not be granted together.
- Assign roles to people: assignments go through an approval flow and are recorded.
Critical authorisations
Some authorisations are risky on their own: resetting every user's password, changing tables directly in production, changing configuration, opening posting periods. These should be held by very few people, logged and reviewed regularly. Temporary "firefighter" users for emergencies should be defined separately, with every use reported.
What about small teams?
In SMEs it is not always possible to give every duty to a different person. Compensating controls then come in: a weekly report of critical master data changes, a second approval for transactions above a set amount, review lists signed off by a manager. What matters is that the risk is known and kept under control.
Regular reviews
- Access for employees who change jobs or leave is updated the same day
- Authorisations are reviewed with process owners at least once a year
- Unused authorisations are removed
- The SoD conflict report runs regularly, with exceptions documented and approved by management
Authorisations and testing
The authorisation design must be tested with real roles during user acceptance testing. Tests run with developer access turn into "no authorisation" errors on day one in production. In S/4HANA, merged transactions such as Business Partner require the old authorisation design to be reviewed.
Authorisation is not a security setting; it is an internal control design. In ERP security and risk analysis work, the quickest win is making existing SoD conflicts visible.
