Few things make a finance director more uncomfortable than an audit management letter that says: “Segregation of duties within the ERP system is inadequate.”
It is one of the most common findings for organizations running Dynamics GP. Not because GP lacks the tools, but because security was often set up quickly during implementation, with broad access to keep things moving, and then never revisited. Over the years, people change roles, small teams cover for each other, and access only ever grows.
In this article, we will explain what segregation of duties means in practical terms, the specific conflicts auditors look for in GP, and how to tighten your controls without making daily work impossible.
What Segregation of Duties Means
Segregation of duties (SoD) is a simple principle: no single person should be able to carry out every step of a sensitive process on their own. If one person can create a supplier, enter an invoice and pay it, there is nothing to stop an error or a fraud from going unnoticed.
Typically, a process is split into four kinds of activity:
- Authorization: approving a transaction
- Recording: entering it in the system
- Custody: handling the related asset, such as cash or stock
- Reconciliation: checking the results independently
Good control means these sit with different people, or that a strong compensating control exists where they cannot be separated.
How Security Works in Dynamics GP
To fix SoD issues, it helps to recognize how GP security is built. Dynamics GP uses role-based security with three layers:
- Operations: individual windows, reports and SmartLists.
- Tasks: groups of operations, such as “Enter payables transactions”.
- Roles: groups of tasks that match a job, such as “AP Clerk”.
Roles are then assigned to each user, per company, in User Security Setup. A user can have several roles, and their access is the combined total of all of them.
That last point matters. Most SoD conflicts are not caused by a single badly designed role. They appear when two reasonable roles are given to the same person.
The Conflicts Auditors Look For
These are the combinations we see questioned most often in GP audits.
1. Vendor maintenance and payables processing
This is the conflict auditors focus on first. If one person can create or change a vendor, including bank details, and also enter invoices or produce payments, they could set up a fictitious supplier or redirect a genuine supplier’s payments to their own account.
We would emphasize vendor bank details in particular. Changes to EFT information are a frequent route for payment fraud, both internal and through fake emails from “suppliers”.
2. Entering and posting payables batches
If the same person enters invoices and posts the batch without any review, there is no independent check before the ledger is updated.
3. Customer maintenance and cash receipts
A user who can create customers, change credit limits or issue credit notes, and also record cash receipts, could hide misappropriated cash by crediting the customer account.
4. Cash receipts and bank reconciliation
The person who records money coming in should not be the person who reconciles the bank account, because the reconciliation is the control that would detect missing receipts.
5. Journal entry and approval
Manual general ledger journals are a classic area of risk. Auditors expect journals, especially large or unusual ones, to be reviewed by someone other than the person who prepared them.
6. Purchasing and receiving
If one user can raise a purchase order and also record the goods receipt, they could approve and “receive” goods that never arrived.
7. Inventory adjustments and stock custody
Warehouse staff who handle stock should not also be able to post inventory adjustments, as these can hide losses.
8. Payroll setup and payroll processing
Creating employees, changing pay rates and running payroll should be separated, with an independent review of changes before each run.
9. Security administration and transactions
Anyone who can change security can give themselves any access they want. Security administrators should not perform day-to-day finance transactions.
10. The POWERUSER role and shared logins
This is the one auditors almost always ask about. The POWERUSER role gives unrestricted access to everything in a company. It is often assigned “temporarily” during implementation and never removed.
Auditors will also ask about:
- The sa and DYNSA accounts, which have full rights over the GP databases and should be used only for administration.
- Shared or generic logins, such as “accounts1”, which make it impossible to know who did what.
- Leavers’ accounts that are still active.
How to Find the Conflicts in Your System
Before changing anything, you need a clear picture of current access. Here is a practical approach:
- List users and roles per company: GP’s security reports, and SmartList or SQL queries against the security tables, can show which roles each user has in each company.
- Check for POWERUSER: Identify every user with this role, in every company.
- Build a simple conflict matrix: List the key activities down one side and across the top, and mark which combinations are not allowed.
- Compare users against the matrix: Highlight anyone holding conflicting access.
- Review with managers: Some conflicts will be genuine requirements in a small team. Others will be leftover access that nobody needs.
Analyzing access this way usually reveals that a large share of conflicts can simply be removed, because the person no longer needs the access.
How to Fix Them in GP
Redesign roles around real jobs
Create roles that match how your team actually works, such as AP Clerk, AP Supervisor, Credit Controller and GL Accountant, rather than relying on the standard roles, which are often broader than needed. Keep vendor maintenance and customer maintenance in their own roles, so they can be given to a small number of people.
This level of customization is normal and recommended. Microsoft’s default roles are a starting point, not a final design.
Remove POWERUSER from everyday users
No regular finance user should have POWERUSER. Replace it with proper roles. Keep administrative accounts separate from personal accounts used for daily work.
Use batch approval
GP can require batch approval before posting in many modules. This means one person enters the batch and another approves it, creating a clear review step.
Use Workflow for approvals
GP’s built-in Workflow module can require approval for payables transactions, purchase orders, general ledger batches and new or changed vendors. Approvals are recorded in GP, which gives auditors clear evidence. Our article on Dynamics GP modules you may own but not use explains Workflow in more detail.
Turn on Activity Tracking and audit trails
Activity Tracking records logins, file access and posting activity. Field-level audit trails can record who changed sensitive fields, such as vendor bank details or credit limits, and when. Use these sparingly on the fields that matter, as excessive tracking can affect performance.
Close the obvious gaps
- Remove or deactivate leavers promptly.
- Replace shared logins with named users.
- Restrict sa to IT administrators and protect its password.
- Review access every quarter or every six months, and keep evidence of the review.
When the Team Is Too Small to Separate Duties
Many GP customers have finance teams of two or three people. Full segregation is not always possible, and auditors understand that. What they expect is compensating controls, such as:
- A manager reviewing a monthly report of new and changed vendors and customers
- Independent review of the payment run before it is released
- A senior person reviewing all journals above a set value
- Bank reconciliations reviewed and signed off by someone else
- Regular review of the Activity Tracking or audit trail report
The key is that the review is documented. A control that happens but leaves no evidence is, from an auditor’s point of view, a control that did not happen.
A Note on Licensing
Some organizations share logins to save on GP license costs. This is understandable, but it undermines segregation of duties completely, because nobody can tell which person carried out a transaction. If concurrent licenses are tight, it is usually better to review user counts with your partner than to share accounts. Our Dynamics GP pricing team can help.
Looking Ahead to Business Central
If your organization is planning a Dynamics GP to Business Central migration, this is an excellent moment to get security right. User permissions do not migrate automatically, so you will design them afresh in Dynamics 365 Business Central. The SoD matrix you build for GP today becomes the blueprint for your Business Central permission sets.
How Nevas Technologies Can Help
Nevas Technologies has worked with Dynamics GP since version 7.0 and regularly helps clients prepare for audits. We can:
- Review your GP security and produce a clear conflict report through our Dynamics GP support services
- Redesign roles and tasks around your team’s real responsibilities
- Set up Workflow, batch approval, Activity Tracking and audit trails
- Train your administrators on security management with Dynamics GP training
- Bring older systems onto a supported version with a Dynamics GP upgrade
Summarizing the Key Points
- Segregation of duties means no one person controls a sensitive process from start to finish.
- Top conflicts: vendor maintenance with payables, customer maintenance with cash receipts, journal entry without approval, and POWERUSER access.
- Find conflicts by listing users, roles and companies against a simple conflict matrix.
- Fix them with focused roles, batch approval, Workflow, audit trails and regular access reviews.
- In small teams, use documented compensating controls.
With a clear security design and a few well-chosen controls, your next audit can be a much more comfortable conversation.
If you would like a segregation of duties review of your GP system, contact Nevas Technologies and our GP specialists will be glad to help.
Frequently Asked Questions
What is the most common SoD finding in Dynamics GP?
Users who can both maintain vendors and process payables, followed closely by everyday users with the POWERUSER role.
Can Dynamics GP prevent conflicting access automatically?
GP does not block conflicting role combinations on its own. You need to design roles carefully and review assignments regularly.
How can I track changes to vendor bank details?
Use field-level audit trails on the relevant fields and, where possible, Workflow approval for vendor changes.
How often should GP access be reviewed?
Most auditors expect at least an annual review, and many organizations review quarterly or every six months, with documented evidence.
