Access Governance Inside the ERP

The question is why access governance becomes urgent only after the ERP is already live. Most teams know roles matter. They know permissions should map to job function. They know segregation of duties should be monitored. But the actual access model often grows through implementation shortcuts, urgent requests, reporting needs, temporary fixes, and exceptions that become permanent.

What is at stake is not only security. It is operational truth. If a user can create, edit, approve, post, and report across too many parts of the system, the organization loses the ability to explain who can do what. If an AI assistant summarizes exceptions without checking the live ERP, the team may lose confidence in the close process. Both issues come from the same first principles problem: the system of record must remain the source of authority.

A recent weekly status review made this visible in practical terms. The team reviewed a comprehensive ERP roles-and-permissions audit tool, discussed how to redesign access around job function and transaction patterns, and checked progress on intercompany eliminations, fixed asset depreciation, and intangible amortization. The details were operational. The lesson was architectural.

Access is an operating model, not a settings page

ERP access control is often treated as configuration. Someone creates roles. Someone assigns users. Someone adjusts permissions when a ticket comes in. The work feels administrative.

But access is really an operating model. It defines how work moves through the company. It determines who can initiate transactions, who can modify them, who can approve them, and who can observe them. It also defines the evidence trail that finance, IT, audit, and management rely on when something goes wrong.

That is why a useful access review cannot stop at a list of roles. It needs to answer four practical questions:

• What permissions exist in the ERP?
• Which roles contain those permissions?
• Which users inherit those permissions through assigned roles?
• Where do combinations of permissions create risk?

The audit tool discussed in the status call was valuable because it addressed all four. It did not simply list users and roles. It created a working model of access across the ERP.

A reusable permissions audit tool

The team walked through a spreadsheet-based audit artifact designed to be reused, extended, and eventually productized. Its value came from connecting multiple views of the same access data.

Role impact scoring

Each role was scored based on the impact of its underlying permissions. A role with broad edit or full access across sensitive transaction areas receives a higher risk profile than a narrow view-only role.

This matters because role names can be misleading. A role called executive reporting may sound harmless. But if that role includes edit or full permissions across operational areas, the name no longer describes the actual power granted.

Impact scoring helps teams move past labels and inspect substance. It gives finance and IT a way to prioritize review work instead of debating every role from scratch.

User-level permission counts

The tool also counted permissions at the user level. This view answers a different question: not what does this role contain, but how much effective access does this person have?

That distinction is important. Users often hold multiple roles. Each role may be reasonable in isolation. Together, they may create broad or conflicting access.

A user-level count can surface patterns such as:

• Users with unusually high full-access permissions
• Users with both operational and approval permissions
• Reporting users who can also edit source transactions
• Former project users who retained temporary implementation access
• Executives with broader access than needed for oversight

This does not mean every high-count user is a problem. It means they deserve explanation.

Conflict matrix for segregation of duties

The tool included a conflict matrix to identify segregation-of-duties issues. This is where access governance becomes more than cleanup.

A segregation-of-duties violation occurs when one person can perform incompatible actions. For example, a user may be able to create a vendor and approve a payment. Or enter a journal and approve the same type of entry. Or modify master data and execute related transactions.

The risk is not theoretical. These combinations weaken control design. They make it harder to detect errors. They increase the chance that a process depends on trust rather than structure.

A conflict matrix helps by making these combinations explicit. It creates a repeatable method for reviewing risk, rather than relying on memory or ad hoc judgment.

Interactive lookup by user and permission level

The most operational feature was an interactive pivot table. It allowed the team to select a user and quickly answer: what can this user actually do, and at what level?

Permission levels such as view, create, edit, and full are more useful when they can be inspected in context. During a review, the team does not want to search through raw exports. They need a fast way to move from a person to their effective access.

This changes the conversation. Instead of asking whether a role seems appropriate, the team can ask whether the user needs each capability to perform their current job.

Permission definitions need a trusted source

One important design choice was to pull permission definitions from the ERP vendor help center. That may sound minor, but it is central to making the audit durable.

Access reviews fail when terminology becomes local folklore. One person thinks a permission allows viewing only. Another believes it allows transaction changes. A third remembers how it worked in a prior release.

Vendor definitions are not perfect, but they provide a baseline. They reduce ambiguity. They help consultants, finance leaders, IT administrators, and auditors interpret the same permission in the same way.

For a productizable audit artifact, this matters. The tool should not depend on one expert being in the room. It should carry enough definition, lineage, and structure that another team can use it later and reach the same conclusions.

Redesign access around work, not history

The review surfaced a familiar issue: the current executive reporting role had more access than necessary. It appeared to include edit and full permissions across many areas that were not clearly related to reporting.

This is common. During implementation, broad access helps leaders test, troubleshoot, and review. After go-live, the same access remains. Over time, the role becomes normalized.

The team agreed to use the audit as a foundation for redesigning access controls. The target model would be segmented by job function and informed by current transaction patterns.

That approach is important. Job function provides the intended design. Transaction patterns provide evidence of actual use. Together, they help avoid two weak outcomes:

• Over-restricting access based on a theoretical model that does not match daily work
• Preserving broad access because no one has evidence to remove it safely

A practical redesign should begin with role families. Reporting users need visibility. Operators need transaction capability. Approvers need review and approval rights. Administrators need elevated access, but with tighter monitoring. Exceptions should be documented and time-bound.

The goal is not a perfect access model. The goal is an explainable one.

AI in the close needs verification discipline

The same status discussion included a separate but related lesson. An AI assistant flagged residuals in intercompany reconciliation. At first, this seemed useful. The assistant appeared to identify an exception that needed attention.

But the flagged residuals turned out to be false positives. The assistant had answered from memory instead of pulling live ERP data.

This is a clean cautionary tale. AI can help summarize, compare, draft, and investigate. But in a close process, it must be tied back to the system of record. If the answer is not grounded in current ERP data, it is not close evidence. It is a suggestion.

The issue is not that AI made a mistake. People make mistakes too. The issue is whether the workflow requires verification before the output is trusted.

For finance teams, this means AI-assisted close work needs clear controls:

• Identify which data source the AI used
• Confirm whether the query reached live ERP data
• Preserve links back to source transactions or reports
• Treat ungrounded answers as drafts or hypotheses
• Require human review for close-critical judgments

AI should reduce manual effort. It should not create a second reality beside the ERP.

The close process still depends on fundamentals

The team also confirmed progress on intercompany eliminations, fixed asset depreciation, and intangible amortization. These are familiar close workstreams, but they are where governance becomes real.

Intercompany eliminations depend on accurate entity-level activity and reconciliation discipline. Depreciation depends on asset records, lives, methods, and posting logic. Intangible amortization depends on schedules, assumptions, and repeatable review.

Access governance affects each of these areas. AI verification affects each of these areas. If users have excessive rights, close entries can be changed without proper separation. If AI flags exceptions from stale or remembered data, the team may spend time chasing issues that do not exist.

This is why the operational status call is a useful management mechanism. It ties system configuration, controls, close execution, and contract planning into one cadence. The three-month extension approved in the discussion gives the team time to finish the redesign and move from analysis to operating control.

From artifact to operating cadence

The best version of the permissions audit tool is not a one-time spreadsheet. It is a recurring control.

A mature cadence might include:

• Monthly review of new users and role changes
• Quarterly review of high-impact roles
• Periodic segregation-of-duties testing
• Comparison of assigned permissions against actual transaction usage
• Exception review with named owners and expiration dates
• Documentation of permission definitions and control rationale

This is how an artifact becomes governance. The spreadsheet is useful because it organizes the data. The operating cadence is useful because it keeps the data from drifting.

The same principle applies to AI. A useful AI workflow is not a prompt someone remembers to use. It is a controlled process with grounding, review, and evidence. The output becomes valuable when the team knows where it came from and how it was checked.

Ultimately, the lesson is that ERP governance is built in small, observable mechanisms. A role score. A user permission count. A conflict matrix. A pivot table. A source link. A live data check. None of these is dramatic. Together, they create trust.

What this means for finance and technology leaders is simple: do not separate access governance from process performance. The same ERP that runs the close also defines who can influence the close. The same AI that accelerates review can mislead the team if it is not grounded in live data.

The takeaway is to make authority visible. Know what each user can do. Know why they can do it. Know when AI is reading the system of record and when it is only producing a plausible answer. That is the practical work of making the ERP dependable.