Finance leaders are under constant pressure to cut costs, and automation is the fastest lever available. IT teams are asked to hand AI agents more autonomy every quarter, and in many workflows that autonomy now stretches across the full transaction lifecycle: an agent reads customer or financial data, produces a recommendation, approves it, executes the action through an API, and writes the log entry that documents what happened.
No serious organization would hand a single employee that combination of powers without a control wrapped around every step. Yet that is precisely the architecture some companies are building today, one agent deployment at a time, often without anyone deciding to do so on purpose. This piece walks through why that pattern is a genuine segregation of duties problem, what Sarbanes-Oxley actually requires when an agent touches a financially relevant process, and what a control owner can do about it in practice.
Here's the uncomfortable part nobody says out loud in a GRC conference room. AI is not replacing risk managers, compliance officers, auditors, cyber teams, controllers, or sustainability experts. It's replacing the manual review work that used to justify half of those job descriptions. What's left after that work disappears is judgment, and judgment is either your biggest career asset right now or the skill you never actually built because the manual work always came first.
Every one of these six professions is being pulled through the same transformation at the same time, just wearing different clothes. Risk teams are using AI to process larger volumes of exposure data faster than any analyst could by hand. Audit is automating the routine testing that used to eat most of fieldwork season. Cyber teams are automating alert triage and first-line response. Compliance is watching AI surface policy conflicts across thousands of documents in the time it used to take to review one contract. Controllers are automating reconciliations and close procedures. Sustainability teams are automating ESG data extraction and disclosure drafting.
None of that is a headcount story on its own. It becomes one for the people who don't adapt, because the professionals who can validate AI outputs, challenge exceptions, and decide where a human still has to sign off are becoming the only ones a board actually needs in the room.
Why Privilege Creep Kills SAP Migrations Before the First Production Transaction Runs
Your
migration to SAP S/4HANA is six months out. The project team is focused
on data migration, Fiori tile configuration, and cutover planning.
Meanwhile, 847 user roles built across eight years of organizational
changes, job transfers, emergency firefighter access, and M&A
integrations are being lifted wholesale into the new system. Nobody has
reviewed them. Nobody has mapped them against the new S/4HANA
authorization model. And your external auditors are already asking for
the SoD conflict report.
This is the standard failure mode. And it is expensive to fix after go-live.
Migrating unremediated ECC
roles into S/4HANA production does not just inherit old access risk. It
amplifies it. S/4HANA's simplified data model, new Fiori authorization
objects, and transaction replacements create net-new SoD conflicts from
role content that was previously clean.
This article gives you the technical remediation
workflow to stop that from happening. It covers the SAP-native tools,
the sequencing logic, the role design architecture that prevents
re-accumulation, and the automated tooling that makes the process viable
at enterprise scale.
Auditing
an SAP Human Capital Management (HCM) environment is one of the most
consequential engagements an internal auditor or external reviewer can
undertake. Payroll errors, unauthorized access to employee records, and
misconfigured benefit plans can expose an organization to financial
loss, regulatory penalties, and reputational damage, all traceable to
configuration decisions buried deep in a system that most auditors never
fully explore.
This guide walks you through the major audit domains in SAP HCM in a logical, field-ready sequence. For each area,
you will find the specific transaction codes (T-codes) to use, the
tables and objects to examine, what to look for as a potential finding,
and practical recommendations you can bring back to management. Whether
you are new to SAP audits or refining an existing program, this guide
gives you a structured, repeatable approach that covers configuration,
authorization, and reporting controls.
A note on terminology: throughout this guide, references to the IMG mean the Implementation Guide, accessed via SPRO (System Customizing Implementation Guide).
The IMG is where nearly all SAP configuration lives, and access to it
is itself a significant control risk. Every section will remind you to
check who can get in there, because the person who can change
configuration often does not need to.
A
compliance officer asked an LLM to analyze a vendor contract for GDPR
obligations. The prompt included the full contract text. The contract
contained employee names, personal email addresses, salary data from an
embedded compensation schedule, and a confidential arbitration clause.
All of it went into a third-party API. The compliance officer received a
helpful analysis. The organization received a data privacy incident.
Nobody
planned for this. The compliance officer was doing good work. The tool
produced a useful output. And the organization now had regulated
personal data sitting in an external system with no data processing
agreement, no retention controls, and no way to request deletion.
That
is the paradox of LLMs in GRC. The same capability that makes them
powerful for regulatory analysis, risk assessment, and audit automation
makes them dangerous when deployed without guardrails. An LLM will
process whatever you feed it. It does not distinguish between public
regulatory text and confidential personal data. It does not know that
the regulation it cited does not exist. It does not understand that the
risk score it generated was influenced by training data biases that
systematically underweight emerging market vendors.
A
compliance analyst at a mid-tier financial institution spent 14 hours
last week reading regulatory updates. She flagged three items as
potentially relevant to her business. She missed two others that
directly affected the firm's cloud outsourcing arrangements. One of
those triggered an enforcement action against a peer institution six
weeks later.
That story repeats across thousands of GRC teams
every week. The volume of regulatory change, vendor risk signals,
control evidence, and incident data has exceeded human processing
capacity. Not because the people lack skill. Because the volume is
physically impossible to cover manually with the rigor the work demands.
AI
changes this equation. Not by replacing human judgment, but by
compressing the time between a risk signal appearing and a qualified
human evaluating it. The 10 use cases in this post are not theoretical.
GRC leaders at financial institutions, technology companies, and
manufacturing firms are running three to five of these today, cutting
manual hours by 30-60% while improving coverage across the full risk
population.
Each use case includes the practical workflow, the
authoritative framework it maps to, and the implementation path you can
follow starting this week.
How
to Use SAP S/4HANA Audit Tools, Data Analytics, RPA, and GRC Solutions
Most SAP audits still leave value on the table. The
team knows the controls. The team knows the transactions. The team can
walk a process and sample documents. But they still work too manually.
They ask for too much evidence from the business. They spot issues late.
They test samples where they could test populations. They rely on
screenshots where SAP already stores the answer.
That is where audit tools, analytics, continuous monitoring, and automation change the game.
I
have seen relatively small audit teams outperform larger ones simply
because they knew how to use the SAP Audit Information System, how to
interrogate the data model, how to run direct analytics against real
transactions, and how to automate evidence collection and control
testing where it made sense. The difference was not talent alone. It was
method.
This article sets out a practical framework for using SAP
S/4HANA audit tools and techniques to improve speed, consistency, and
insight. It covers the Audit Information System, direct data analysis,
the SAP data dictionary, process mining, SAP GRC products, continuous
auditing and monitoring, and RPA. As requested, I include transaction
codes, tables, and key technical field references where they matter.
Audit Controls for the SAP S/4HANA Forecast-to-Stock Cycle
Inventory audits are rarely just about counting boxes. They
are about trust. Trust that the quantities in SAP S/4HANA reflect
physical reality. Trust that movements are valid. Trust that scrapped
material is actually scrapped. Trust that stock in transit exists. Trust
that inventory valuation is right, period cutoffs are right, and
adjustments are not hiding mistakes or theft.
That is why the
forecast-to-stock cycle matters so much, even when most audit work in
this area ends up focusing on inventory management rather than
forecasting.
I have seen inventory environments where the count
procedures looked disciplined but the underlying movement controls were
weak. The result was predictable. Repeated write-offs. Unexplained
adjustments. Warehouse frustration. Management arguing over whether the
issue was process, system, or people. I have also seen the reverse.
Well-designed movement controls, cycle counting discipline, material
master governance, and better reporting reduced inventory noise sharply
before year-end counts ever began.
This article gives you a
practical framework for auditing the SAP S/4HANA forecast-to-stock
cycle, with emphasis on inventory management. It covers the key S/4HANA
changes, enterprise structure, material master, movement types,
security, configurable controls, and the most useful audit reports. As
requested, I include transaction codes, key tables, technical field
names, and practical implementation guidance throughout.
Practical Audit Controls for the SAP S/4HANA Purchase-to-Pay Cycle
Few audit areas get management’s attention faster than purchase-to-pay. The
reason is simple. Cash is leaving the company. When controls are weak,
the damage is usually visible in money, not theory. Duplicate payments.
Overpayments. Invalid vendors. Missed discounts. Manual payments.
Invoice blocks cleared too easily. Purchase orders changed after
approval. Those are not abstract control concerns. They are operating
losses.
That is why a strong SAP S/4HANA purchase-to-pay audit can be one of the most valuable reviews in the annual plan.
I
have seen organizations recover meaningful cash just by tightening
duplicate invoice checks, vendor master controls, and release strategy
gaps. I have also seen teams focus too narrowly on invoice processing
and miss the actual cause of the problem, which often sits earlier in
the flow. In vendor setup. In purchasing info records. In source lists.
In movement types. In tolerance settings. In who can create, approve,
receive, and pay.
This article gives you a practical framework for
auditing the SAP S/4HANA purchase-to-pay cycle. It covers the S/4HANA
changes that matter, enterprise structure, master data, security, common
configurable controls, and high-value reports. As requested, it
includes transaction codes, relevant tables, authorization objects, and
full technical names where they help the work become actionable.
Practical Audit Controls for the SAP S/4HANA Order-to-Cash Cycle
Revenue problems rarely begin in the income statement.
They
begin earlier. In customer master data. In pricing conditions. In
credit limits. In copy control. In blocked deliveries that no one
resolves. In incomplete sales documents that sit too long. In manual
overrides that looked harmless at the time.
That is why a strong
SAP S/4HANA order-to-cash audit is never just a sales process
walkthrough. It is a control review across sales, shipping, billing,
receivables, customer master data, pricing, credit management, and the
handoff into financial accounting.
I have seen organizations with
healthy top-line growth discover margin leakage only after audit tested
pricing overrides and free-of-charge processes in detail. I have also
seen teams with good commercial discipline still struggle because
customer business partner data, incompleteness procedures, or credit
checking were only partially configured. The process looked fine on
paper. The exceptions told a different story.
This article gives
you a practical framework for auditing the SAP S/4HANA order-to-cash
cycle. It covers new S/4HANA features, enterprise structure, master
data, security, common configurable controls, high-value reports, and
the technical details needed for a serious audit or GRC review. As
requested, I include transaction codes, tables, authorization objects,
and field-level references where they are relevant.
Practical Audit Controls for the SAP S/4HANA Record-to-Report Cycle
Most finance audits focus on the final reports. That is too late. If
you want reliable financial reporting in SAP S/4HANA, you need to look
earlier. At posting periods. At journal entry controls. At field status
logic. At validation rules. At asset settings. At master data. At who
can post, who can reopen a period, and who can change document fields
after the fact. The balance sheet only tells you the ending story. The
controls tell you whether the story can be trusted.
I have seen
finance teams with excellent close discipline still struggle because SAP
S/4HANA was left at default settings that did not match the business. I
have also seen the opposite. A well-configured environment cut
period-end stress sharply because errors were prevented before they
became close issues. That is the real promise of a strong
record-to-report design. Fewer surprises. Better evidence. More
confidence in the numbers.
This article sets out a practical
framework for auditing the SAP S/4HANA record-to-report cycle. It covers
statutory and managerial reporting, enterprise structure, master data,
security, common configurable controls, useful reports, and the
technical details auditors and GRC teams actually need. As requested, I
include transaction codes, relevant tables, key technical field names,
and plain-language descriptions.
Audit Guide for SAP S/4HANA IT General Controls, Basis Settings, and Security
A
minimum password length of 4 characters. SAP_ALL assigned to 11 dialog
users. Table logging disabled in production. The system change option
set to modifiable. And the client lock on the production client removed
six times during the audit period with no documentation explaining why.
That
was a single SAP S/4HANA audit. One client. One system. And every one
of those findings existed because nobody checked the foundational layer
before testing the business process controls sitting on top of it.
Here
is the problem. Organizations spend weeks testing purchase order
release strategies, three-way match configurations, and payment approval
workflows. They validate that configurable controls are set correctly
and that users follow documented procedures. Then an auditor discovers
that a developer had debugging access in production, that the system was
unlocked for modification three times in the last quarter, and that RFC
connections from the development system point directly at production
data. Every business process control conclusion becomes unreliable
because the foundation was never validated.
ITGCs and Basis
security settings are that foundation. If they fail, everything above
them in the audit pyramid becomes suspect. This post covers the complete
audit approach for IT General Controls, Basis settings, transport
controls, logging frameworks, profile parameters, and the SAP
authorization concept, with every T-code, table, field, and parameter
you need to execute a thorough review.
SDLC Controls, Data Migration Verification, and Every T-Code You Need
I
once watched an organization go live with SAP S/4HANA after 14 months
of implementation effort, a $22 million investment, and exactly zero
documented control design decisions. The system worked. Transactions
processed. Reports generated. And the first post-go-live audit produced
47 findings, 11 of which required configuration changes that cost more
than $1.8 million in rework.
The implementation team had built exactly what was specified. The specifications never included controls.
Auditing
an SAP S/4HANA implementation is fundamentally different from auditing a
production system. You are evaluating a moving target. Design decisions
change weekly during agile sprints. Data migration scripts run and
rerun across environments. Security roles evolve as functional teams
discover new requirements. The controls you need to test are not just
the future-state business process controls. They include the SDLC
controls governing the implementation itself, the program governance
structures supporting decision-making, the data migration procedures
protecting data integrity during transition, and the security controls
safeguarding non-production environments that contain real
organizational data.
This post covers the complete audit approach
for SAP S/4HANA implementations and upgrades, with specific T-codes,
tables, fields, and testing procedures for each control category.
Whether you are performing a concurrent audit during the implementation
or a retrospective review shortly after go-live, every technique here
applies.
Every T-Code, Table, and Design Technique You Need Before Go-Live
The most expensive SAP S/4HANA audit findings are the ones discovered after go-live. Every one of them.
I
have watched organizations spend $200,000 remediating a segregation of
duties problem that would have cost $5,000 to configure correctly during
the explore phase. I have seen a chart of accounts redesign triggered
by a post-implementation audit finding that required a partial
reimplementation. And I have seen implementations where the system
integrator delivered exactly what was specified, but the specifications
never included internal controls, so the organization went live with a
perfectly built system that had no preventive controls over vendor
payments.
These situations are avoidable. Every single one.
This
post walks through the complete methodology for building controls into
your SAP S/4HANA implementation from day one. It covers the
control-conscious implementation team structure, the control design
framework with specific T-codes and table references, the audit
involvement model, and the SDLC controls that protect the implementation
itself. If your implementation is already underway, skip to the section
covering your current phase. If you are planning your next
implementation, read everything.
Most
SAP S/4HANA audits fail before fieldwork even begins. The planning is
shallow, the scope misses entire control layers, and the team lacks the
technical depth to distinguish a real finding from a false positive. I
have seen audit reports with 40 findings that missed the three issues
that actually mattered. That is expensive failure.
Getting the SAP
S/4HANA audit right matters because the system sits at the center of
financial reporting, procurement, inventory management, and dozens of
other processes that carry real organizational risk. A weak audit gives
false assurance. A strong audit identifies quantifiable business impact
and drives measurable control improvement.
This post walks through
the complete SAP S/4HANA audit framework, from IT General Controls
through business process validation, with every T-code, table, and
configuration parameter you need to execute at a high level. Each
section includes implementation tips drawn from field experience across
financial services, manufacturing, and public sector engagements.
SAP audits slow down for a simple reason. The team asks good control questions, but they pulls evidence the hard way. That
is expensive. It is also risky. When GRC teams run IT General Controls
reviews, Basis reviews, security assessments, and compliance testing
without a clear SAP HANA evidence model, they miss population-level
issues, they over-rely on screenshots, and they burn weeks reconciling
exceptions that should have been identified in hours.
I have seen
this firsthand. In one global SAP program, the audit team had strong
control design knowledge but no HANA-native audit approach. They
extracted data into spreadsheets, sampled manually, and escalated dozens
of false positives. The rework took three extra weeks. The actual root
cause was not weak audit judgment. It was weak technical evidence
strategy.
Post by Prof. Hernan Huwyler, MBA, CPA, CAIO AI GRC Director | AI Risk Manager | Quantitative Risk Lead Speaker, Corporate Trainer and Executive Advisor
Top 10 Responsible AI and Risk Management by Thinkers360
Risk is a pervasive force across all business activities. Every
strategic and operational decision depends on producing reliable
information about the probability and impact of different outcomes.
Assurance services exist to enhance the quality and credibility of this
information, enabling leadership to make well-founded decisions with
confidence.
The AICPA Special Committee on Assurance Services,
commonly known as the Elliott Committee, articulated this principle in
its 1997 report, establishing that assurance improves the reliability of
information for decision makers. Since then, the scope of assurance has
expanded well beyond statutory financial reporting to encompass ESG
disclosures, cybersecurity attestations, data privacy compliance, and
emerging areas such as AI governance.
The Institute of Internal Auditors defines assurance as the
objective examination of evidence for the purpose of providing an
independent assessment of governance, risk management, and control
processes. This assessment adds credibility to both financial
and non-financial information, from audited financial statements to
environmental and social reports. In practical terms, assurance delivers
the confidence that what needs to be controlled is actually being
controlled.
Boards
bear ultimate responsibility for ensuring that robust internal control
arrangements exist across the entire organization, making assurance a first-order governance obligation rather than a purely operational concern.
Most
corporate governance frameworks reinforce this expectation. The UK
Corporate Governance Code, NYSE listing requirements, King IV in South
Africa, and the EU Corporate Sustainability Reporting Directive all
require the board to attest to the effectiveness of internal control and
risk management systems. In the United States, SOX Section 404
specifically mandates that management assess and report on the
effectiveness of internal controls over financial reporting.
Without
a structured approach to coordinating assurance across these
requirements, boards risk blind spots, redundant coverage, and
misallocated resources. These are precisely the conditions that erode
stakeholder trust and invite regulatory scrutiny.
What Is an Assurance Map and Why It Matters
An assurance map
is a visual coordination tool that links assurance activities from all
providers to the risks threatening organizational objectives. Structured
as a matrix, it plots key risks or sequential process steps along the
vertical axis against assurance activities along the horizontal axis.
The assurance activities are typically organized according to the IIA Three Lines Model, which was updated in 2020 to replace the former Three Lines of Defense terminology. Under this model, the first line consists of operational management, which owns and manages risk and controls. The second line encompasses risk management, compliance, and other oversight functions that provide expertise, monitoring, and challenge. The third line
is internal audit, which delivers independent and objective assurance.
Some organizations extend the framework to incorporate external audit
and regulatory or board-level oversight as additional assurance layers,
though these extensions fall outside the IIA formal model.
The strategic value of an assurance map lies in four dimensions. First, it provides board-level visibility through a consolidated, single-page view of risk coverage across the enterprise. Second, it promotes consistency by establishing a common methodology and language for management, oversight, and reporting. Third, it fosters cross-functional collaboration by making interdependencies between departments visible and actionable. Fourth, it drives cost efficiency by revealing redundancies and enabling reallocation of assurance resources toward areas of genuine exposure.
Keys to Making Decisions on Assurance
Assurance
mapping is only as valuable as the decisions it informs. The following
principles are critical to leveraging these maps effectively.
Identify Gaps and Eliminate Redundancies
The
primary objective of assurance mapping is to detect areas where
assurance is absent or unnecessarily duplicated across departments. A
well-constructed map reveals the true level of oversight for each risk
area, enabling leadership to reduce low-value and redundant efforts
while strengthening coverage where it is most needed.
Standardize the Risk Methodology
For
assurance mapping to deliver a coherent enterprise-wide view, the
underlying risk methodology must be standardized. This includes the risk taxonomy, exposure modeling, and risk appetite thresholds.
A common risk language is what enables meaningful coordination and
interaction between business owners and assurance providers across all
three lines. Without standardization, the map becomes a patchwork of
incompatible assessments rather than a reliable decision-making tool.
Align Assurance Effort to Risk Exposure
Link
the risk exposure of each process to its current assurance coverage to
determine whether assurance costs are proportionate to the
organization's risk tolerance. This is the practical application of the
concept of reasonable assurance. When excessive
assurance concentrates on a single process, leadership should
investigate the root causes, such as historical incidents, regulatory
mandates, or organizational inertia, before redistributing controls and
responsibilities.
Update Governance Documents
When
assurance programs are combined or activities reassigned, the governing
documents must reflect these changes. This includes organizational
policies, the internal audit charter, and departmental
mandates. The assurance map is a coordination and visualization tool. It
is not a policy instrument in itself and should not be treated as one.
Maintain Information Flow Across All Lines
Consolidating
or reassigning assurance responsibilities does not eliminate the need
for information sharing. Even when a department no longer directly
assures a process, it should continue to receive relevant reporting
about the reliability of related controls and the quality of associated
outputs. Effective remediation depends on transparent communication of issues and action plans across all functions involved.
Leverage Technology for Continuous Assurance
Modern
GRC platforms and data analytics capabilities enable real-time
monitoring and continuous assurance, moving organizations beyond
periodic point-in-time assessments. Integrating automated controls,
exception-based reporting, and interactive dashboards into the assurance
map strengthens both coverage and responsiveness. Organizations that
embed technology into their assurance architecture gain a significant
advantage in the speed and reliability of their risk oversight.
An Assurance Map in Practice
To illustrate the concept, consider a simplified financial month-end closing process
at a company operating on SAP. The process-based map below plots
process steps and their associated risks along the vertical axis against
assurance providers organized by the Three Lines Model along the
horizontal axis. It consolidates controls from each line to assess the
extent and adequacy of coverage, designed for alignment with SOX Section 404 requirements and the COSO Internal Control Integrated Framework.
Each cell in the map reflects the quality and depth of evidence
provided by the relevant assurance function, assessed according to three
levels.
H stands for High Assurance. Assurance
is detailed and performed on a recurring cycle. The depth of audit
evidence reduces residual risk to an acceptable level, for example by
maintaining low material misstatement risk in accounting processes.
Controls are in place and adequately mitigate identified risks. Policies
are documented and communicated throughout the organization. IT and
business intelligence tools automate controls and flag exceptions for
follow-up. Performance metrics are actively monitored by management.
M stands for Medium Assurance.
Assurance is not performed on a regular cycle. Controls are not in
place to cover all relevant risks. Policies are incomplete or not fully
communicated to the responsible parties. Manual controls that could be
automated remain in their current state, increasing the likelihood of
human error.
L stands for Low Assurance. Little
or no assurance is provided over the process. Significant concerns exist
regarding the adequacy of controls relative to the risk profile. Few
governing policies are documented or enforced.
The governance case for assurance mapping
In
the United States, boards oversee risk management and internal control,
while management is responsible for establishing, maintaining, and
assessing those controls. This governance distinction is important. It
would be inaccurate to say that boards directly operate or certify every
control across the enterprise. Their role is to oversee whether the
organization has an effective system of internal control and risk
management, and whether that system is supported by credible reporting
and challenge.
That oversight burden has grown significantly.
Public companies face Sarbanes Oxley requirements for internal control
over financial reporting. Regulated sectors face heightened scrutiny
over operational resilience, model risk, privacy, third party
dependencies, and cyber controls. Sustainability reporting is also
increasing expectations around governance, controls, and attestable
data. As complexity rises, boards and executive committees need a
clearer and more integrated view of assurance coverage.
Recognized
frameworks support this approach. The Institute of Internal Auditors
Three Lines Model clarifies the roles of management, oversight
functions, and internal audit. The COSO Internal Control Integrated
Framework remains the leading basis for evaluating the design and
effectiveness of internal control. COSO Enterprise Risk Management links
risk oversight to strategy and performance. ISO 31000 provides a widely
accepted foundation for risk management principles and governance.
Together, these frameworks reinforce the same point. Assurance should be
coordinated, risk based, and tied to decision making.
How Assurance Mapping Creates Management Value
The strongest reason to implement assurance mapping is not administrative efficiency. It is better risk oversight.
A
well designed assurance map helps leadership answer questions that are
often difficult to resolve through fragmented reporting. Which
enterprise risks receive strong and recurring challenge. Which critical
processes depend too heavily on self assessment or management judgment.
Where are multiple teams reviewing the same controls with similar
methods. Which material risks are supported by evidence based assurance
and which rely on assumptions. Where does remediation stall because
findings remain within one function instead of moving through a common
governance process.
These insights matter because organizations
rarely fail due to a total absence of controls. More often, they fail
because risk ownership is unclear, challenge is inconsistent, and
fragmented assurance gives leadership a false sense of confidence.
What a Strong Assurance Map Should Include
A
useful assurance map begins with the business objectives, risk
universe, and critical processes that matter most to the enterprise. The
goal is not to map everything. The goal is to make visible the quality
and sufficiency of assurance where failure would materially affect
performance, compliance, resilience, or reporting integrity.
The
structure usually starts with a defined scope such as financial
reporting, cybersecurity, third party risk, privacy, revenue,
procurement, product quality, or end to end operational processes. For
each area, the map should identify the principal risks, the key controls
or oversight mechanisms, the functions providing assurance, the nature
of that assurance, the frequency of review, the degree of independence,
the quality of evidence, and the current assessment of coverage.
This
does not require an overly complex model. In fact, one of the most
common mistakes is overengineering the framework to the point that it
becomes difficult to maintain. The best assurance maps are disciplined,
comparable, and practical enough to support real decisions.
From Assurance Mapping to Strategic Confidence
Assurance
mapping is not an end in itself. It is a means of translating
fragmented risk oversight into boardroom confidence and organizational
resilience. When executed with disciplined methodology, standardized
risk language, and genuine cross-functional commitment, it becomes one
of the most powerful tools available to the GRC leader.
The goal is never to eliminate risk entirely. The goal is to ensure that the organization's assurance architecture is proportionate to its risk profile, coordinated across all lines, and transparent to the stakeholders who depend on it.
In an era of expanding regulatory expectations, proliferating risk
domains, and heightened scrutiny from investors and regulators alike,
the organizations that master assurance coordination will be the ones
that earn and sustain trust.
Get the latest in corporate governance, risk, and compliance on Twitter
Post by Prof. Hernan Huwyler, MBA, CPA, CAIO AI GRC Director | AI Risk Manager | Quantitative Risk Lead Speaker, Corporate Trainer and Executive Advisor
Top 10 Responsible AI and Risk Management by Thinkers360
Corporate Criminal Liability And The Regulatory Case For Risk Mapping
The
Spanish Criminal Code, as reformed by Organic Law 1/2015, establishes
specific requirements for corporate compliance programs that regulate
the criminal liability of legal entities. Article 31 bis sets out the
conditions under which an organization may be exempted from or receive a
reduction in criminal liability, provided it demonstrates that an
effective compliance program was in place before the offense occurred.
Among the program requirements enumerated in Article 31 bis paragraph 5,
the organization must identify the activities within whose scope
criminal offenses that must be prevented are likely to be committed.
This requirement is, in substance, a mandate for criminal compliance
risk mapping.
The Spanish framework shares a common logic with the
U.S. Federal Sentencing Guidelines for Organizations under Chapter 8 of
the USSG, which recognize an effective compliance and ethics program as
a mitigating factor at sentencing. Similarly, the DOJ Evaluation of
Corporate Compliance Programs guidance evaluates whether the
organization has conducted a bona fide risk assessment that informs the
design and resourcing of its compliance program. In both jurisdictions,
the core principle is the same: demonstrated and adequate oversight
efforts to prevent compliance breaches can materially reduce penalties
and, in the Spanish case, provide a complete defense.
The Circular
1/2016 of the Spanish Attorney General's Office provides additional
interpretive guidance on the elements of an effective compliance program
under Article 31 bis, reinforcing that a meaningful risk assessment is
foundational rather than optional. Organizations operating in Spain
should also consider alignment with UNE 19601, the Spanish national
standard for criminal compliance management systems, which provides a
structured framework for implementing these requirements.
The Strategic Purpose Of A Compliance Risk Map
Building
a compliance program that achieves high business values requires the
chief compliance officer to address criminal, regulatory, and ethical
risks in a coordinated and systematic manner. A compliance risk map is
the instrument that makes this possible. It assesses business activities
that may result in criminal offenses or, more broadly, in regulatory,
legal, contractual, or ethical breaches.
The risk map serves two
fundamental purposes. First, it guides prevention actions such as
targeted training programs, the development of policies and procedures,
and the design of internal controls proportionate to identified risks.
Second, it informs contingency and response actions such as incident
management, internal investigations, regulatory notifications, and
remediation planning. Without a well-constructed risk map, the
compliance program lacks a defensible basis for how it allocates its
resources and prioritizes its activities.
Defining The Risk Mapping Scope
The
foundation of any credible compliance risk map is a comprehensive risk
universe. This universe should encompass all criminal offenses
applicable to the organization under the relevant jurisdiction,
including those enumerated under Article 31 bis of the Spanish Criminal
Code, together with applicable regulations, contractual obligations,
voluntary commitments such as industry codes of conduct, and known fraud
schemes relevant to the organization's sector.
This risk universe
allows the compliance function to classify risk factors in a way that
facilitates both mitigation planning and communication to leadership.
The compliance risk landscape should address industry-specific
regulations, counterparty-related requirements such as anti-money
laundering and sanctions obligations, and general regulatory frameworks
including data protection, competition law, environmental standards, and
occupational health and safety.
For multinational organizations,
the risk universe must account for the jurisdictional complexity
inherent in operating across multiple legal systems. A practical
approach is to group compliance risk domains by general topic, such as
bribery and corruption, fraud, data privacy, trade controls, or
environmental compliance, and then map each topic to the specific local
requirements applicable in each jurisdiction. This structure enables
both enterprise-level aggregation and local operational relevance. The
compliance requirement inventory should be validated by subject matter
specialists from the compliance, legal, and where appropriate,
regulatory affairs departments.
Integrating The Compliance Risk Map Into Enterprise Risk Management
A
compliance risk map should not exist in isolation. It should be built
upon and integrated into the organization's existing enterprise risk
management framework. While ERM practices and internal audit risk
assessments are not specifically designed to identify legal and
regulatory compliance risks, they can be combined, calibrated, or linked
to a compliance-specific risk map. The objective is to ensure that
compliance risks are visible within the broader risk governance
structure rather than siloed in a parallel process.
Following a
global ERM policy ensures that the compliance risk map can be readily
integrated into the organization's GRC management and reporting
architecture. It also ensures that the risk taxonomy, rating scales,
likelihood and impact definitions, and risk appetite thresholds are
consistent across functions, enabling meaningful comparison and
aggregation.
Assessing the financial impact of compliance risks is
particularly important. A risk map that relies exclusively on
qualitative categories without quantifying potential exposure, including
regulatory fines, litigation costs, remediation expenses, and
reputational harm, will struggle to compete for leadership attention and
resource allocation against commercially quantified risks.
The
methodological framework should be supported by recognized international
standards. ISO 31000 provides the overarching principles and guidelines
for risk management. ISO 37001 establishes requirements for
anti-bribery management systems. ISO 37301, which replaced the former
ISO 19600 in 2021, sets out requirements for compliance management
systems. Alignment with these standards strengthens both the credibility
and the defensibility of the risk assessment methodology.
Planning The Risk Assessment From The Top Down
Developing
a comprehensive compliance risk map across a large or multinational
organization can be time-consuming and resource-intensive. A pragmatic
approach is to plan the assessment in phases, beginning at the
enterprise level and progressively expanding into greater operational
detail.
The chief compliance officer should perform an initial
top-down risk assessment to identify the highest-priority risk domains
and the organizational units, jurisdictions, and transaction types that
warrant the most detailed analysis. This initial assessment should draw
on available internal and external data sources to direct effort toward
areas of greatest exposure.
The following is a simplified example
of how a multinational organization might plan the phased expansion of
its compliance risk mapping.
This initial framework can be progressively enriched with additional
data from compliance exception reports, detailed whistleblowing and
ethics hotline statistics, external audit and tax audit findings,
transactional records, regulatory examination results, client
complaints, employee surveys, and where relevant, social media and
adverse media monitoring data.
Ensuring Broad Coverage And Operational Proximity
An
effective compliance risk map must cover the actions and decisions of
all individuals who act on behalf of or in connection with the
organization, including board members, directors, managers, executives,
employees, consultants, agents, and suppliers. Article 31 bis of the
Spanish Criminal Code specifically addresses offenses committed by
senior officers and by individuals subject to their authority or
supervision, making breadth of coverage a legal requirement as well as a
best practice.
The assessment process should involve personnel at
multiple organizational levels, across jurisdictions and functional
areas, to limit the cognitive and positional biases that inevitably
arise when risk assessments are conducted exclusively by headquarters
functions. Capturing perspectives from both senior leadership and
operational staff ensures that the map reflects both strategic and
ground-level risks. Performing assessments close to operations, at the
site, business unit, or country level, significantly increases the
probability of identifying the most relevant and material risks rather
than generic or theoretical ones.
Clear ownership of each
compliance risk must be established to facilitate the management of
action plans, the tracking of remediation, and the escalation of issues
through the governance structure. The chief compliance officer must
maintain a comprehensive understanding of the full spectrum of
compliance requirements and emerging issues across the organization's
operating footprint. External legal advisors and specialized consultants
can provide valuable support, particularly for jurisdictional-specific
requirements and novel risk areas.
Building Trust To Surface Genuine Risks
The
quality of a compliance risk assessment depends directly on the
willingness of risk owners and operational managers to disclose their
genuine risks and vulnerabilities. This willingness is a function of
trust. Risk owners will provide candid and complete information only
when they have confidence in the integrity and competence of the
individuals conducting the assessment and believe that the process will
lead to constructive action rather than punitive consequences.
Involving
locally recognized and respected leaders in the risk mapping process is
essential. Their participation signals organizational commitment and
encourages open engagement from operational teams. Introducing the risk
mapping initiative through compliance training sessions also creates a
positive working environment and ensures that participants understand
the purpose, methodology, and expected outcomes before they are asked to
contribute.
Compliance risks must be
followed up dynamically and with a frequency proportionate to their
exposure. This ongoing process includes reviewing the results of action
plans against defined milestones, producing and monitoring key risk
indicators, and escalating emerging or deteriorating risks to the
appropriate risk committees, executive leadership, or the board.
The
compliance risk landscape is not static. New risks emerge continuously
from regulatory changes, enforcement trends, strategic decisions such as
market entry or acquisitions, organizational restructuring,
technological change, and the evolving sophistication of cybercrime and
fraud schemes. A compliance risk map that does not evolve with the
organization and its environment will rapidly become obsolete and will
fail to provide the defensibility that the legal framework requires.
The
dynamic follow-up of compliance risks and action plans is what
transforms a risk map from a static inventory into a living instrument
of the compliance culture. It is this ongoing discipline, visible to
employees at all levels, that demonstrates the organization's genuine
commitment to ethical and lawful conduct.
References
Spanish Criminal Code, including the framework relevant to legal entity liability and Article 31 bis
US Federal Sentencing Guidelines for Organizations
US Department of Justice. Evaluation Of Corporate Compliance Programs
ISO 31000 Risk Management Guidelines
ISO 37001 Anti Bribery Management Systems Requirements With Guidance For Use
ISO 37301 Compliance Management Systems Requirements With Guidance For Use
Committee
of Sponsoring Organizations of the Treadway Commission. Enterprise Risk
Management Integrating With Strategy And Performance
Get the latest in corporate governance, risk, and compliance on Twitter
Post by Prof. Hernan Huwyler, MBA, CPA, CAIO AI GRC Director | AI Risk Manager | Quantitative Risk Lead Speaker, Corporate Trainer and Executive Advisor
Top 10 Responsible AI and Risk Management by Thinkers360
The most visited post in my blog covers the 20 most critical conflicts that you may find in SAP auditing, SOX testing and user security controls. After several years of fine-tuning the user conflict matrix and having SAP HANA released, I expand this post by listing the 100 most critical and frequent segregation of duties incompatibilities. This list helps in simplifying the user reviews by internal auditors, functional roles and access security professionals while explaining the risk which may result in operational fraud.
This is the list which you are welcome to get as a MS Excel file,
VA01 Create Sales Order and XD01 Create Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VA01 Create Sales Order and XD02 Change Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
F.80 Mass reversal of documents and F-60 Maintain Table: Posting Periods are incompatible since the user may open accounting periods previously closed and make postings after month end.
VA01 Create Sales Order and VD01 Create Customer (SD) are incompatible since assets may be disposed at less than the true value.
VA01 Create Sales Order and VD02 Change Customer (SD) are incompatible since assets may be disposed at less than the true value.
VA01 Create Sales Order and FD02 Change Customer (FI) are incompatible since assets may be disposed at less than the true value.
VA01 Create Sales Order and FD01 Create Customer (FI) are incompatible since assets may be disposed at less than the true value.
VA02 Change Sales Order and XD01 Create Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VA01 Create sales order and F-30 Post with clearing are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
F.80 Mass reversal of documents and OB52 C FI Maintain Table T001B are incompatible since the user may open accounting periods previously closed and make postings after month end.
VL02N Change outbound delivery and F-22 Enter customer invoice are incompatible since the user may create/change a delivery and create/change an invoice.
XK01 Create Vendor (Centrally) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
XD01 Create customer (centrally) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
VA02 Change Sales Order and XD02 Change Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VA01 Create sales order and VL02N Change outbound delivery are incompatible since the user may create/change sales orders and deliveries to hide the misappropriation of goods.
VF01 Create Billing Document and XD01 Create Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VL01N Create outbound delivery with order ref and F-22 Enter customer invoice are incompatible since the user may create/change a delivery and create/change an invoice.
VA01 Create sales order and F-32 Clear customer are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
XK01 Create Vendor (Centrally) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
XD02 Change customer (centrally) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
MIGO Goods Movement and MM01 Create Material are incompatible since the user could create or change a fictitious receipt and create/change a material document to hide the deception.
Why SAP Segregation Of Duties Still Matters
Segregation
of duties remains one of the most fundamental control disciplines in
SAP environments. Despite advances in ERP architecture, workflow
automation, analytics, and access governance tools, the underlying risk
has not changed. When a single user can initiate, modify, approve, and
complete incompatible activities across a transaction flow, the
organization increases its exposure to fraud, error, financial
misstatement, unauthorized transactions, and control override.
This
is especially relevant in SAP environments that support core business
processes such as order to cash, procure to pay, record to report,
treasury, inventory management, and master data administration. In these
processes, poorly designed access can allow users to create fictitious
counterparties, manipulate transaction records, bypass approvals,
conceal unauthorized activity, or distort financial reporting.
For
internal audit, SOX teams, and SAP security professionals, the
challenge is not simply identifying technical access overlaps. It is
determining which combinations create meaningful business risk and which
should be prioritized for remediation, monitoring, or compensating
controls.
Why Many SoD Matrices Are Too Large To Be Useful
One
of the recurring issues in SAP access reviews is that segregation of
duties matrices become too broad, too technical, or too disconnected
from real business risk. Some organizations maintain thousands of rule
combinations, many of which are theoretically incompatible but
operationally low risk. The result is predictable. Access reviews become
difficult to explain, remediation efforts lose focus, and the business
begins to treat SoD alerts as administrative noise rather than control
signals.
A more effective approach is to focus on critical and
frequent conflicts that create a credible path to unauthorized
transactions, concealment, asset misappropriation, or financial
reporting distortion. This does not mean reducing rigor. It means
prioritizing conflicts that matter most.
That is why a curated
list of critical incompatibilities can be so valuable. It helps internal
auditors, role owners, access governance teams, and control testers
simplify reviews and focus attention on combinations that are both
common in practice and meaningful from a fraud and controls perspective.
What Makes An SAP SoD Conflict Truly Critical
Not
every incompatible transaction pair carries the same risk. A conflict
becomes especially important when it allows a user to control multiple
points in a process where one action can create or modify the object and
a later action can approve, settle, invoice, receive, clear, or conceal
it.
In practice, the highest risk conflicts often involve one or
more of the following conditions. The user can create or change master
data and then execute transactions against that data. The user can
initiate a commercial or accounting transaction and then post, clear,
reverse, or conceal the financial result. The user can create
operational activity and then generate the related billing, payment, or
inventory movement. The user can reopen periods, reverse postings, or
alter records after normal controls should have locked the transaction
history.
This is the lens that matters. The risk is not the
transaction code itself. The risk is the business capability created
when incompatible access is combined in one user profile.
Why SAP HANA Does Not Eliminate SoD Risk
The
move to SAP HANA and more modern SAP landscapes has improved reporting
speed, data access, and system capability, but it has not removed
segregation of duties risk. In fact, transformation programs can
sometimes increase access risk temporarily because role redesign,
migration pressure, emergency access, and hybrid landscapes create new
complexity.
This is an important point for audit and controls
teams. SoD risk is not a legacy SAP ECC issue only. It remains relevant
across modern SAP environments, including S4HANA, especially where
organizations have not fully redesigned business roles, cleaned up
inherited access, or integrated SoD governance into transformation.
How To Use A Critical Conflict List Properly
A
list of critical incompatibilities should be used as a prioritization
tool, not as a substitute for process understanding. The same conflict
can present different levels of risk depending on workflow design,
approval automation, system configuration, organizational structure, and
the presence of compensating controls.
For example, a conflict
involving customer master maintenance and order processing may be highly
sensitive in a decentralized commercial model with weak approval
evidence, but less severe where master data changes are tightly workflow
controlled, monitored, and independently reviewed. Likewise, a
transaction pair involving invoice entry and goods movement may be
materially more dangerous in a high volume manual environment than in
one with embedded three way match controls and exception reporting.
This
is why the best SoD programs do not stop at identifying conflicts. They
assess business context, user activity, role necessity, mitigating
controls, and whether the access creates a realistic fraud or error
scenario.
Detailed Explanation Of Critical And Frequent SAP SoD Incompatibilities
Below
is a refined sample of the types of conflicts that commonly warrant
close attention in SAP access reviews. The wording has been adjusted to
better reflect the underlying business risk.
VA01 Create Sales
Order and XD01 Create Customer Centrally should generally be segregated
because a user who can create both customer master data and sales orders
may be able to establish a fictitious or inappropriate customer and
initiate unauthorized sales transactions. The risk is not simply
disposal of assets below true value. It also includes fictitious sales
activity, misdirection of goods, and concealment of unauthorized
commercial arrangements.
VA01 Create Sales Order and XD02 Change
Customer Centrally should generally be segregated because the user may
alter customer master data and then create sales orders using
manipulated terms, addresses, or related customer attributes. This can
enable unauthorized transactions, diversion schemes, or improper pricing
arrangements.
VA01 Create Sales Order and VD01 Create Customer
Sales And Distribution should generally be segregated because a user
with both capabilities may create a customer in the sales domain and
then process sales transactions against that customer without sufficient
independent review.
VA01 Create Sales Order and VD02 Change
Customer Sales And Distribution should generally be segregated because
changing customer sales data and creating orders can allow the user to
manipulate commercial terms, shipping attributes, or controls relevant
to the sale.
VA01 Create Sales Order and FD01 Create Customer
Finance should generally be segregated because customer creation in
finance combined with order processing can enable unauthorized sales and
downstream receivable activity tied to improperly established
customers.
VA01 Create Sales Order and FD02 Change Customer
Finance should generally be segregated because the combination can allow
manipulation of finance relevant customer attributes and subsequent
order activity that may not reflect legitimate commercial intent.
VA02
Change Sales Order and XD01 Create Customer Centrally should generally
be segregated because a user may create customer records and then modify
sales orders in ways that obscure unauthorized transactions or alter
commercial terms after initiation.
VA02 Change Sales Order and
XD02 Change Customer Centrally should generally be segregated because
control over both customer master updates and sales order changes
creates a broader ability to manipulate the transaction lifecycle.
VA01
Create Sales Order and VL02N Change Outbound Delivery should generally
be segregated because a user who controls both order initiation and
outbound delivery changes may be able to divert goods, conceal shipment
irregularities, or manipulate fulfillment records.
VL02N Change
Outbound Delivery and F 22 Enter Customer Invoice should generally be
segregated because the user may control both shipment related activity
and customer invoicing, creating a risk of unsupported billing,
duplicate billing, or concealment of unauthorized deliveries.
VL01N
Create Outbound Delivery With Order Reference and F 22 Enter Customer
Invoice should generally be segregated because control over both
delivery creation and invoice entry creates a risk that sales
fulfillment and billing records can be manipulated without independent
challenge.
VF01 Create Billing Document and XD01 Create Customer
Centrally should generally be segregated because a user may establish
customer master data and generate billing against that customer,
increasing the risk of fictitious receivables or unauthorized billing
activity.
XD01 Create Customer Centrally and F 30 Post With
Clearing should generally be segregated because the user may create
customer records and then post and clear incoming payments, which can
facilitate concealment of unauthorized transactions or manipulation of
receivable balances.
XD02 Change Customer Centrally and F 30 Post
With Clearing should generally be segregated because a user may alter
customer data and then apply or clear payments in a way that obscures
the true nature of receivable activity.
VA01 Create Sales Order
and F 30 Post With Clearing should generally be segregated because the
user may initiate sales activity and then influence how cash is posted
or cleared, creating risk in the order to cash cycle.
VA01 Create
Sales Order and F 32 Clear Customer should generally be segregated
because a user may create or influence sales transactions and later
clear customer items, increasing the risk of concealment of collection
issues or receivable manipulation.
XK01 Create Vendor Centrally
and XD01 Create Customer Centrally should generally be segregated
because the same user should not normally be able to create both vendors
and customers without oversight. This may allow related party style
schemes, circular transactions, or use of fictitious entities on both
sides of the ledger.
XK01 Create Vendor Centrally and XD02 Change
Customer Centrally should generally be segregated because the ability to
create vendors and alter customers can support fictitious or
manipulative counterparty structures that are difficult to detect
through ordinary transaction review.
MIGO Goods Movement and MM01
Create Material should generally be segregated because a user may create
or maintain material records and then process goods movements that
support fictitious inventory activity, conceal shrinkage, or distort
stock records.
F 80 Mass Reversal Of Documents and OB52 Maintain
Posting Periods should generally be segregated because a user may reopen
accounting periods and reverse postings after close, which increases
the risk of unauthorized post close adjustments and financial reporting
manipulation.
The original post referred to F 60 Maintain Table
Posting Periods in one example. That wording is inaccurate. F 60 is
generally used for entering vendor invoices, while posting period
control is more appropriately associated with OB52 or related
configuration level access. Correct transaction references matter
because weak technical precision can undermine the usefulness of an SoD
rule set.
How To Use This Reference
This list identifies the most
critical and frequently encountered segregation of duties conflicts
across core SAP business processes, organized by process area and risk
category. For each conflict, the incompatible transaction code pair is
identified along with a description of the specific fraud or error risk
that the combination creates.
The complete list of 100 conflicts
is available for download as a structured spreadsheet for integration
into access review programs, GRC platform rulesets, and audit work
papers.
The conflicts in this reference should be treated as a
starting point rather than a definitive and universal ruleset. Every
organization must tailor its SoD matrix to its specific business
processes, organizational structure, industry, and risk appetite. A
conflict that is critical in one operating environment may be mitigated
in another through compensating controls, organizational design, or
process-specific safeguards.
Why Business Risk Descriptions Matter More Than Transaction Pairing Alone
A
common weakness in SAP SoD documentation is that the stated risk is too
generic, too narrow, or simply wrong. For example, saying that creating
a customer and creating a sales order means assets may be disposed at
less than true value captures only one possible scenario and not the
most likely one in many environments.
The business risk
description should explain the realistic control failure that the
combination enables. Depending on the process, that may include
fictitious counterparties, unauthorized sales, duplicate billing,
diversion of inventory, unsupported payments, inaccurate financial
reporting, manipulation of period end results, or concealment of
exceptions.
This matters because the quality of the risk narrative
determines whether business owners, auditors, and control committees
will take the conflict seriously. Technical access rules alone rarely
drive remediation. Business relevant risk articulation does.
How Internal Audit And SOX Teams Should Prioritize Review
For
internal audit and SOX testing, high value SoD review should focus
first on combinations that affect financially significant processes,
master data integrity, period end financial controls, payment authority,
and inventory movement. It should also consider whether the user
actually executed both sides of the conflict, whether emergency or
firefighter access was involved, whether the conflict is concentrated in
sensitive populations, and whether compensating controls are formal,
evidence based, and consistently performed.
This is also where
analytics can improve assurance. Access risk should be connected to
usage data, transactional evidence, exception history, and post close
activity rather than assessed only through static role design.
What A Mature SAP Access Risk Program Looks Like
A
mature SAP access risk program does not treat segregation of duties as a
one time remediation project. It treats SoD as part of a wider access
governance model that includes role design, provisioning controls,
emergency access management, periodic access review, transaction level
monitoring, and alignment with financial control objectives.
It
also recognizes that some conflicts may be unavoidable in smaller
populations or specialized roles. In those cases, the key question
becomes whether the risk is transparent, approved, monitored, and
mitigated through credible compensating controls.
Additional SAP Segregation of Duties Conflicts
Expanded Critical Conflict List
The
following conflicts are organized by business process area. Each entry
identifies the incompatible transaction code pair by its full SAP name,
describes the specific business risk the combination creates, and
explains why the access should generally not be assigned to the same
user. These conflicts supplement the 21 already published and are drawn
from practices documented in SAP GRC Access Control standard rule sets,
ISACA SAP audit programs, and widely applied internal control
frameworks.
Procure to Pay
This process area
consistently produces the highest concentration of critical SoD
conflicts because it involves the creation of counterparties, the
commitment of organizational funds, the confirmation of goods or
services received, the entry of invoices, and the release of payments. A
single user with access across multiple steps in this chain can create
fictitious vendors, generate unauthorized purchase commitments, confirm
goods never received, enter unsupported invoices, and direct payments to
accounts they control.
22. ME21N Create Purchase
Order and XK01 Create Vendor (Centrally) should generally be segregated
because a user who can create vendor master data and issue purchase
orders may establish a fictitious vendor and direct procurement spend to
that entity without independent verification.
23.
ME21N Create Purchase Order and XK02 Change Vendor (Centrally) should
generally be segregated because the user may alter vendor master
attributes such as bank details, payment terms, or pricing agreements
and then create purchase orders that exploit those changes.
24.
ME21N Create Purchase Order and FK01 Create Vendor (Accounting) should
generally be segregated because creating a vendor in financial
accounting and issuing purchase orders against that vendor combines
counterparty creation with procurement commitment in a way that bypasses
standard approval separation.
25. ME21N Create
Purchase Order and FK02 Change Vendor (Accounting) should generally be
segregated because changing vendor financial attributes such as bank
routing information and then processing purchase commitments creates a
path to payment diversion.
26. ME21N Create
Purchase Order and MK01 Create Vendor (Purchasing) should generally be
segregated because creating a vendor in the purchasing view and issuing
orders against that vendor allows a single user to control both
counterparty setup and procurement activity.
27.
ME21N Create Purchase Order and MK02 Change Vendor (Purchasing) should
generally be segregated because a user may modify vendor purchasing data
such as order currency, incoterms, or planned delivery time and then
create orders that benefit from those modifications.
28.
ME21N Create Purchase Order and MIRO Enter Incoming Invoice (Logistics
Invoice Verification) should generally be segregated because a user who
can both commit the organization to a purchase and approve the related
invoice controls two of the three elements in the standard three-way
match, weakening the control over unauthorized or fictitious
procurement.
29. ME21N Create Purchase Order and
MIGO Goods Movement should generally be segregated because a user may
create a purchase order and then confirm receipt of goods or services
without independent verification, enabling fictitious receipt schemes.
30.
ME21N Create Purchase Order and F-53 Post Outgoing Payments (Vendor)
should generally be segregated because the user may create a procurement
commitment and directly process payment, bypassing invoice verification
and payment approval controls.
31. ME21N Create
Purchase Order and F110 Automatic Payment Program (Parameters) should
generally be segregated because a user who can create purchase
commitments and configure or execute automatic payment runs may direct
funds to unauthorized vendors or accelerate payments outside normal
processing cycles.
32. ME51N Create Purchase
Requisition and ME21N Create Purchase Order should generally be
segregated because a user who can both request and approve a purchase
bypasses the core separation between demand origination and procurement
commitment.
33. ME21N Create Purchase Order and
ME29N Release Purchase Order should generally be segregated because a
user who can both create and release a purchase order effectively
self-approves procurement transactions, eliminating the independent
review that purchase order release is designed to provide.
34.
MIRO Enter Incoming Invoice (Logistics Invoice Verification) and F-53
Post Outgoing Payments (Vendor) should generally be segregated because a
user who can enter vendor invoices and process payments may create and
pay fictitious or inflated invoices without independent review.
35.
MIRO Enter Incoming Invoice (Logistics Invoice Verification) and F110
Automatic Payment Program (Parameters) should generally be segregated
because the user may enter invoices and then configure or trigger
payment runs that process those invoices automatically, bypassing
payment approval workflows.
36. XK01 Create
Vendor (Centrally) and MIRO Enter Incoming Invoice (Logistics Invoice
Verification) should generally be segregated because a user may create a
vendor and immediately enter invoices against it, supporting a
fictitious vendor and invoice scheme.
37. XK01
Create Vendor (Centrally) and F-53 Post Outgoing Payments (Vendor)
should generally be segregated because the user may create a fictitious
vendor and directly process payments to it.
38.
XK01 Create Vendor (Centrally) and F110 Automatic Payment Program
(Parameters) should generally be segregated because a user who can
create vendors and configure or execute automatic payments may establish
fictitious payees and trigger disbursement without manual intervention.
39.
FK01 Create Vendor (Accounting) and F-53 Post Outgoing Payments
(Vendor) should generally be segregated because the combination allows
vendor creation in the accounting view and direct payment processing,
bypassing procurement and invoice verification entirely.
40.
FK01 Create Vendor (Accounting) and F110 Automatic Payment Program
(Parameters) should generally be segregated because a user may create
vendor accounting records with specific bank details and then process
automatic payments directed to those accounts.
41.
MIGO Goods Movement and MIRO Enter Incoming Invoice (Logistics Invoice
Verification) should generally be segregated because a user who can
confirm goods receipt and approve the related invoice controls two
verification points in the procurement cycle, weakening the control that
independent confirmation is designed to provide.
42.
ME22N Change Purchase Order and MIGO Goods Movement should generally be
segregated because a user may modify purchase order quantities, prices,
or delivery terms and then confirm receipt against the altered order,
concealing discrepancies.
43. MR8M Cancel Invoice
Document and MIRO Enter Incoming Invoice (Logistics Invoice
Verification) should generally be segregated because a user who can
cancel and reenter invoices may manipulate invoice records to alter
amounts, redirect payments, or conceal duplicate processing.
44.
XK02 Change Vendor (Centrally) and F-53 Post Outgoing Payments (Vendor)
should generally be segregated because the user may change vendor bank
details and then process payments to the revised account, enabling
payment diversion fraud.
45. XK02 Change Vendor
(Centrally) and F110 Automatic Payment Program (Parameters) should
generally be segregated because changing vendor payment attributes and
triggering automatic payments creates a risk of undetected payment
redirection.
46. ME22N Change Purchase Order and
MIRO Enter Incoming Invoice (Logistics Invoice Verification) should
generally be segregated because a user may alter purchase order terms
and then enter invoices that match the revised terms, concealing
unauthorized modifications to procurement commitments.
Record to Report and Financial Accounting
Financial
accounting conflicts create risk when a user can both generate
accounting entries and control the infrastructure that governs how those
entries are processed, reversed, reclassified, or reported. Period
management, document reversal, and general ledger master data
maintenance are among the most sensitive capabilities in SAP financial
accounting.
47. FB01 Post Document and FB08
Reverse Document should generally be segregated because a user who can
both post and reverse accounting entries may create and then conceal
unauthorized transactions, manipulate account balances, or alter the
financial record after the fact.
48. FB01 Post
Document and FS00 Edit G/L Account Centrally should generally be
segregated because a user who can create or modify general ledger
accounts and post journal entries may establish accounts designed to
hide unauthorized activity or misclassify transactions.
49.
F-02 Enter G/L Account Posting and FB08 Reverse Document should
generally be segregated because the combination allows a user to post
and reverse general ledger entries, creating the ability to manipulate
balances temporarily or permanently.
50. F-02
Enter G/L Account Posting and FS00 Edit G/L Account Centrally should
generally be segregated because the user may modify the chart of
accounts structure and then post entries that exploit those
modifications.
51. FB01 Post Document and OB52
Maintain Posting Period Variants should generally be segregated because a
user who controls both posting capability and period access may reopen
closed periods and make unauthorized post-close entries that affect
financial reporting.
52. F-02 Enter G/L Account
Posting and OB52 Maintain Posting Period Variants should generally be
segregated because the combination creates the same period manipulation
risk as the previous conflict, applied to manual general ledger
postings.
53. FB50 Enter G/L Account Document and
OB52 Maintain Posting Period Variants should generally be segregated
because the simplified posting transaction combined with period control
allows unauthorized entries into periods that should be locked.
54.
F-43 Enter Vendor Invoice and F-53 Post Outgoing Payments (Vendor)
should generally be segregated because a user who can enter vendor
invoices directly in financial accounting and process payments controls
both sides of the disbursement process.
55. F-43
Enter Vendor Invoice and F110 Automatic Payment Program (Parameters)
should generally be segregated because the user may enter invoices and
then trigger automatic payment processing, bypassing manual payment
review.
56. FK01 Create Vendor (Accounting) and
F-43 Enter Vendor Invoice should generally be segregated because a user
may create a vendor in financial accounting and immediately enter
invoices against it without procurement involvement.
57.
F-44 Clear Vendor and F-43 Enter Vendor Invoice should generally be
segregated because the user may enter vendor invoices and clear open
items in a way that conceals discrepancies, duplicate payments, or
unauthorized charges.
58. F-28 Post Incoming
Payments and FD01 Create Customer (Accounting) should generally be
segregated because a user who can create customer records and post
incoming payments may manipulate receivable balances or misapply cash
receipts.
59. F-28 Post Incoming Payments and
FD02 Change Customer (Accounting) should generally be segregated because
changing customer financial attributes and posting payments creates a
path to receivable manipulation and misapplied collections.
60.
FB08 Reverse Document and OB52 Maintain Posting Period Variants should
generally be segregated because a user may reopen accounting periods and
reverse previously posted documents, directly undermining period-end
financial controls and the integrity of closed-period financial
statements.
61. FB01 Post Document and F.80 Mass
Reversal of Documents should generally be segregated because a user who
can post accounting documents and perform mass reversals may
systematically alter financial records at scale, creating significant
financial reporting risk.
Asset Management
Asset
accounting conflicts create risk when a single user can control the
creation of asset master records and the transactions that acquire,
transfer, revalue, or retire those assets. The primary concern is that
assets may be created fictitiously, retired prematurely, transferred
without authorization, or disposed of at manipulated values.
62.
AS01 Create Asset Master Record and ABAVN Asset Retirement by Scrapping
should generally be segregated because a user who can create asset
records and retire assets by scrapping may record fictitious assets and
then write them off, or prematurely retire legitimate assets to conceal
misappropriation.
63. AS01 Create Asset Master
Record and ABAON Asset Retirement from Sale with Customer should
generally be segregated because the user may create asset records and
process asset sales, creating a path to dispose of assets at manipulated
values or to fictitious buyers.
64. AS02 Change
Asset Master Record and ABAVN Asset Retirement by Scrapping should
generally be segregated because modifying asset master attributes and
then retiring assets allows manipulation of asset values, useful life,
or location data to conceal unauthorized disposals.
65.
AS01 Create Asset Master Record and AB01 Create Asset Transaction (Post
Asset Transaction) should generally be segregated because a user who
can create asset records and post asset transactions may record
fictitious acquisitions, transfers, or revaluations.
66.
AS02 Change Asset Master Record and ABAON Asset Retirement from Sale
with Customer should generally be segregated because the user may alter
asset values or categorization and then process asset sales that do not
reflect the true condition or worth of the asset.
67.
AS01 Create Asset Master Record and F-90 Acquisition from Purchase with
Vendor (Asset Posting from Purchasing) should generally be segregated
because the user may create asset records and post acquisition
transactions tied to vendor invoices, enabling fictitious asset
capitalization.
Order to Cash Additional Conflicts
The
existing list covers many core order-to-cash conflicts. The following
additional combinations address billing manipulation, cancellation and
re-creation schemes, and payment processing risks that are commonly
encountered in sales environments.
68. VA01
Create Sales Order and VF01 Create Billing Document should generally be
segregated because a user who controls both order initiation and billing
document creation may generate invoices that do not correspond to
legitimate sales activity or that reflect manipulated terms.
69.
VA02 Change Sales Order and VL02N Change Outbound Delivery should
generally be segregated because a user who can modify both sales orders
and deliveries may alter quantities, delivery addresses, or terms across
both documents to conceal diversion or unauthorized shipments.
70.
VF01 Create Billing Document and F-28 Post Incoming Payments should
generally be segregated because a user who controls both billing and
cash receipt posting may generate invoices and apply payments in ways
that conceal collection issues or misapply customer funds.
71.
VF01 Create Billing Document and F-30 Post with Clearing should
generally be segregated because the user may bill customers and then
clear the resulting receivable items, concealing the true status of
collections or manipulating aging reports.
72.
VF01 Create Billing Document and VD01 Create Customer (Sales and
Distribution) should generally be segregated because a user may create
customers in the sales domain and generate billing documents against
them, supporting fictitious revenue schemes.
73.
VF01 Create Billing Document and VD02 Change Customer (Sales and
Distribution) should generally be segregated because the user may modify
customer sales data and then create billing documents that exploit
those modifications.
74. VF01 Create Billing
Document and FD01 Create Customer (Accounting) should generally be
segregated because combining billing authority with customer financial
master creation increases the risk of fictitious receivable activity.
75.
VF01 Create Billing Document and FD02 Change Customer (Accounting)
should generally be segregated because the user may alter customer
financial terms and generate billing that reflects those altered
conditions.
76. VF11 Cancel Billing Document and
VF01 Create Billing Document should generally be segregated because a
user who can cancel and recreate billing documents may manipulate
invoice records, alter billing amounts, or conceal credit and rebilling
activity.
77. VF02 Change Billing Document and
F-28 Post Incoming Payments should generally be segregated because the
user may modify billing records and then apply payments in a manner that
conceals the changes or misrepresents the collection status.
Inventory and Warehouse Management
Inventory
and warehouse transaction conflicts are especially important in
manufacturing, distribution, and retail environments where physical
goods movement represents a significant portion of organizational assets
and cost of goods sold.
78. MB1A Goods Issue and
MB1C Other Goods Receipts should generally be segregated because a user
who can issue goods out of inventory and record goods receipts may
manipulate stock balances, conceal shrinkage, or create fictitious
inventory movements.
79. MB1A Goods Issue and
MM02 Change Material (Master) should generally be segregated because the
user may alter material master attributes such as valuation class,
price, or unit of measure and then issue goods using the manipulated
data.
80. MIGO Goods Movement and MM02 Change
Material (Master) should generally be segregated because modifying
material master records and processing goods movements creates a risk of
inventory valuation manipulation and concealment of unauthorized stock
changes.
81. MB1B Transfer Posting and MM01
Create Material (Master) should generally be segregated because a user
may create material records and then process transfer postings to move
inventory between locations or valuation areas without proper
authorization.
82. MB1A Goods Issue and MIGO
Goods Movement should generally be segregated in environments where MIGO
is used for goods receipt because a user who can both issue and receive
goods may execute circular inventory movements to conceal shortages or
misappropriation.
Human Resources and Payroll
Human
resources and payroll conflicts are among the most sensitive in any
organization because they directly involve employee compensation. A user
who can modify employee master data and influence payroll processing
may create ghost employees, alter compensation, redirect payments, or
manipulate tax and benefit deductions.
83. PA30
Maintain HR Master Data and the country-specific payroll transaction
(such as PC00_M10_CALC Run Payroll for the United States or the
equivalent for other country versions) should generally be segregated
because a user who can change employee bank details, pay rates, or tax
data and also run payroll calculations may alter compensation and
process payments without independent review.
84.
PA40 Personnel Actions and the country-specific payroll transaction
should generally be segregated because a user who can execute personnel
actions such as hiring, termination, or organizational reassignment and
also process payroll may create or terminate employees and manipulate
the related payroll activity.
85. PA30 Maintain
HR Master Data and F110 Automatic Payment Program (Parameters) should
generally be segregated because a user who can modify employee bank
account information in HR master data and also configure or execute
automatic payment processing may redirect payroll disbursements.
86.
PA30 Maintain HR Master Data and PU00 Delete Payroll Results should
generally be segregated because a user who can alter employee data and
delete payroll calculation results may conceal evidence of unauthorized
compensation changes.
87. PA30 Maintain HR Master
Data and FB01 Post Document should generally be segregated because
combining HR master data maintenance with general ledger posting
capability may enable a user to create or alter employee records and
post related accounting entries without separation between the HR and
finance functions.
Basis and Security Administration
Basis
and security conflicts are fundamentally different from business
process conflicts because they involve access to the infrastructure that
controls all other access. A user with combined basis and security
capabilities may grant themselves or others unauthorized access, modify
system behavior, alter data directly at the table level, or undermine
the integrity of the authorization framework itself. These conflicts are
relevant to IT general controls under SOX and to the access governance
requirements of virtually every audit and compliance framework.
88.
SU01 Maintain Users (User Maintenance) and PFCG Role Maintenance should
generally be segregated because a user who can both create or modify
user accounts and design or assign authorization roles can effectively
grant any level of access to any user, including themselves, without
independent review.
89. SU01 Maintain Users (User
Maintenance) and SE16 Data Browser should generally be segregated
because a user who can modify user accounts and directly browse database
tables may access sensitive data across the entire system without
application-level authorization controls.
90.
SU01 Maintain Users (User Maintenance) and SM30 Maintain Table Views
(Call View Maintenance) should generally be segregated because the
combination allows a user to modify access controls and directly alter
configuration or master data at the table level, bypassing all
transaction-level controls.
91. SU01 Maintain
Users (User Maintenance) and SA38 Execute ABAP Reporting (ABAP
Reporting) should generally be segregated because a user who can
maintain user accounts and execute ABAP programs may run reports or
utilities that bypass standard authorization checks.
92.
SU01 Maintain Users (User Maintenance) and SE38 ABAP Editor should
generally be segregated because the combination allows a user to modify
user access and alter program code, creating a path to embed
unauthorized logic or bypass controls within the system.
93.
SE38 ABAP Editor and SA38 Execute ABAP Reporting (ABAP Reporting)
should generally be segregated because a user who can modify programs
and immediately execute them may alter system behavior, extract data, or
bypass controls without detection.
94. PFCG Role
Maintenance and SU10 Mass User Maintenance (User Mass Maintenance)
should generally be segregated because a user who can design roles and
assign them in bulk may grant widespread unauthorized access rapidly,
undermining the entire authorization model.
95.
SE16 Data Browser and SM30 Maintain Table Views (Call View Maintenance)
should generally be segregated because a user who can both view and
modify table data directly has the ability to alter virtually any system
record — including financial data, master data, and configuration —
without using controlled transactions.
96. SU01
Maintain Users (User Maintenance) and SCC4 Client Administration should
generally be segregated because a user who controls user access and
client-level settings may modify client parameters that affect system
behavior across the entire environment.
97. STMS
Transport Management System and SE38 ABAP Editor should generally be
segregated because a user who can modify program code and transport
changes into production may introduce unauthorized system changes
without independent technical review.
98. SM37
Background Job Overview (Job Overview) and SA38 Execute ABAP Reporting
(ABAP Reporting) should generally be segregated because a user who can
schedule and manage background jobs and execute programs may run
unauthorized processes outside of normal business hours or monitoring
visibility.
99. SE16N General Table Display and
SU01 Maintain Users (User Maintenance) should generally be segregated
because SE16N in some system configurations permits data modification at
the table level, and combining this with user maintenance creates the
same infrastructure-level risk as SE16 combined with SU01.
100.
SU01 Maintain Users (User Maintenance) and SM21 System Log Analysis
should generally be segregated because a user who can modify user
accounts and access or manage system logs may alter access and then
suppress or manipulate the log evidence that would normally detect the
change. While SM21 is primarily a display transaction, in some
configurations and when combined with other basis access, it can be part
of a broader pattern of evidence management risk.
Technical References and Authoritative Sources
The
following references support the conflict identification and risk
descriptions in this list. Organizations building or validating their
own SoD rule sets should consult these sources for detailed technical
guidance.
SAP GRC Access Control Rule Set. SAP
delivers a standard segregation of duties rule set with its GRC Access
Control product. This rule set contains predefined risk definitions,
functions, and conflict rules organized by business process. It serves
as the baseline for most SAP SoD programs and is documented in the SAP
Help Portal under SAP GRC Access Control configuration guides.
Organizations should review and tailor this rule set to their specific
environment, as the standard rules may not reflect all
organization-specific risks.
SAP Security and Authorizations (SAP Press).
The SAP Press publication on SAP security provides detailed guidance on
authorization object design, role construction, user administration,
and segregation of duties. It is widely used by SAP security teams and
auditors as a technical reference for understanding how SAP
authorization checks operate and how access conflicts arise at the
authorization object level, not just the transaction code level.
SAP Help Portal — Transaction Code Documentation.
SAP maintains official documentation for each transaction code,
including its purpose, associated authorization objects, and
configuration prerequisites. This documentation is the authoritative
source for confirming the correct full name of each transaction code and
understanding its functional scope. It is accessible through the SAP
Help Portal and through transaction SE93 (Maintain Transaction Codes)
within the SAP system itself.
ISACA — IT Audit Framework and SAP Audit Programs.
ISACA publishes audit and assurance programs for ERP environments,
including SAP-specific guidance on access controls, segregation of
duties, and IT general controls. These programs are widely referenced by
internal audit functions and external auditors performing SOX testing
and operational audits of SAP environments.
COSO — Internal Control — Integrated Framework (2013).
The COSO framework establishes the foundational principles for internal
control design, including the principle that organizations should
segregate incompatible duties or implement alternative controls where
segregation is not practicable. This framework provides the conceptual
basis for SoD requirements and is referenced by the SEC and PCAOB in the
context of internal control over financial reporting.
PCAOB Auditing Standard AS 2201 — An Audit of Internal Control Over Financial Reporting.
AS 2201 requires auditors to evaluate the design and operating
effectiveness of internal controls, including IT general controls and
application controls in ERP systems. Segregation of duties is a core
component of this evaluation, particularly for financially significant
processes and systems such as SAP.
IIA Global Technology Audit Guides (GTAGs).
The Institute of Internal Auditors publishes technology audit guides
that address IT governance, access management, and application controls.
GTAG 8 on auditing application controls and GTAG 1 on information
technology risk and controls are directly relevant to SAP SoD
assessments.
SAP Note References. SAP publishes
notes and knowledge base articles that address specific authorization
risks, critical authorization objects, and recommended segregation
practices. Key notes related to critical authorizations include SAP Note
manufacturers publish security notes and authorization guides that
should be reviewed as part of SoD program maintenance. The SAP Security
Notes index and the SAP Community Wiki on GRC best practices provide
additional practitioner-contributed guidance.
Final Perspective
The
most effective SAP SoD matrices are not the largest. They are the ones
that best translate technical access conflicts into meaningful business
risk. For internal auditors, SOX teams, and SAP security professionals,
the goal should be to identify the combinations that create the clearest
path to fraud, error, or reporting distortion and to focus remediation
where it matters most.
A refined list of critical and frequent
conflicts can be a powerful tool for that purpose, but only when it is
maintained carefully, technically accurate, and grounded in real process
risk rather than generic access theory.
If useful, this list can
also be structured into an Excel based conflict matrix for review, rule
maintenance, and testing support.
References
AP Help Portal: official transaction, process, and authorization documentation for SAP ECC and SAP S/4HANA SAP GRC Access Control documentation: ruleset and access risk analysis concepts SAP PRESS publications on SAP Security, Authorizations, and GRC Access Control COSO Internal Control – Integrated Framework for segregation of duties and control design principles Institute of Internal Auditors (IIA) guidance on fraud risk and internal controls ISACA guidance on access governance, SoD, and control monitoring PCAOB and SOX internal control expectations relevant to financial reporting and access risks Internal SAP system analysis using SUIM, PFCG, SU24, STAUTHTRACE, and transaction usage reviewSAP transaction and authorization design practices relevant to SoD and access governance
Institute of Internal Auditors guidance on internal controls and fraud risk
Committee of Sponsoring Organizations of the Treadway Commission. Internal Control Integrated Framework
US Securities and Exchange Commission and PCAOB expectations relevant to internal control over financial reporting under SOX
Access governance and SoD practices commonly used in SAP security and audit programs
Get the latest in corporate governance, risk, and compliance on Twitter
XD01 Create customer (centrally) and VL02N Change outbound delivery are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
XD01 Create customer (centrally) and F-32 Clear customer are incompatible since the user may create a customer and then post payments against the customer.
VA01 Create sales order and VL01N Create outbound delivery with order ref are incompatible since the user may create/change sales orders and deliveries to hide the misappropriation of goods.
VF01 Create Billing Document and XD02 Change Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VA02 Change Sales Order and VD01 Create Customer (SD) are incompatible since assets may be disposed at less than the true value.
FK01 Create Vendor (FI) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
VA02 Change Sales Order and VD02 Change Customer (SD) are incompatible since assets may be disposed at less than the true value.
VA01 Create sales order and F-26 Incoming payments fast entry are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
VA02 Change Sales Order and FD02 Change Customer (FI) are incompatible since assets may be disposed at less than the true value.
XD01 Create customer (centrally) and VL01N Create outbound delivery with order ref are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
XD02 Change customer (centrally) and VL02N Change outbound delivery are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
XK01 Create Vendor (Centrally) and VD01 Create Customer (SD) are incompatible since assets may be sold to non-existent or fraudulent customers.
XD01 Create customer (centrally) and F-29 Post customer down payment are incompatible since the user may have the ability to enter or modify down payments for customers and the user may have the ability to create or modify customer account information should be segregated. If the same person can process both items, unauthorized changes could be made and possibly not detected. Th.
XD02 Change customer (centrally) and F-32 Clear customer are incompatible since the user may create a customer and then post payments against the customer.
VD01 Create customer (sales) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
FK02 Change Vendor (FI) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
XK01 Create Vendor (Centrally) and VD02 Change Customer (SD) are incompatible since assets may be sold to non-existent or fraudulent customers.
XD01 Create customer (centrally) and F-26 Incoming payments fast entry are incompatible since the user may create a customer and then post payments against the customer.
XK01 Create Vendor (Centrally) and FD02 Change Customer (FI) are incompatible since assets may be sold to non-existent or fraudulent customers.
VD02 Change customer (sales) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
FD02 Change customer (accounting) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
VA02 Change Sales Order and FD01 Create Customer (FI) are incompatible since assets may be disposed at less than the true value.
MK01 Create Vendor (MM) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
FK01 Create Vendor (FI) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
VF01 Create Billing Document and VD01 Create Customer (SD) are incompatible since assets may be disposed at less than the true value.
VA02 Change sales order and F-30 Post with clearing are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
XD02 Change customer (centrally) and VL01N Create outbound delivery with order ref are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
ME21N Access to Create Purchase Order and ABAA Unplanned Depreciation are incompatible since assets may be acquired at an overvalued or undervalued price and then depreciated. Unplanned depreciation, manual depreciation, and asset value write-ups are processed incorrectly or without authority to proceed.
MK02 Change Vendor (MM) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
VF01 Create Billing Document and VD02 Change Customer (SD) are incompatible since assets may be disposed at less than the true value.
VF01 Create Billing Document and FD02 Change Customer (FI) are incompatible since assets may be disposed at less than the true value.
XD02 Change customer (centrally) and F-29 Post customer down payment are incompatible since the user may have the ability to enter or modify down payments for customers and the user may have the ability to create or modify customer account information should be segregated. If the same person can process both items, unauthorized changes could be made and possibly not detected.
XK01 Create Vendor (Centrally) and FD01 Create Customer (FI) are incompatible since assets may be sold to non-existent or fraudulent customers.
VA01 Create sales order and F-51 Post with clearing are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
FK02 Change Vendor (FI) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
XK02 Change Vendor (Centrally) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
F.80 Mass reversal of documents and SCMA Schedule Manager: Scheduler are incompatible since the user may open accounting periods previously closed and make postings after month end.
XD02 Change customer (centrally) and F-26 Incoming payments fast entry are incompatible since the user may create a customer and then post payments against the customer.
FD01 Create customer (accounting) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
VD01 Create customer (sales) and VL02N Change outbound delivery are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
VF02 Change Billing Document and XD01 Create Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VD02 Change customer (sales) and VL02N Change outbound delivery are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
MK01 Create Vendor (MM) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
VD01 Create customer (sales) and F-32 Clear customer are incompatible since the user may create a customer and then post payments against the customer.
FD02 Change customer (accounting) and VL02N Change outbound delivery are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
ME21N Access to Create Purchase Order and ABZU Write-up are incompatible since assets may be acquired at an overvalued or undervalued price and then depreciated. Unplanned depreciation, manual depreciation, and asset value write-ups are processed incorrectly or without authority to proceed.
XD01 Create customer (centrally) and F-51 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
VD02 Change customer (sales) and F-32 Clear customer are incompatible since the user may create a customer and then post payments against the customer.
MK02 Change Vendor (MM) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
VF01 Create Billing Document and FD01 Create Customer (FI) are incompatible since assets may be disposed at less than the true value.
FD02 Change customer (accounting) and F-32 Clear customer are incompatible since the user may create a customer and then post payments against the customer.
VA02 Change sales order and VL02N Change outbound delivery are incompatible since the user may create/change sales orders and deliveries to hid the misappropriation of goods.
FK01 Create Vendor (FI) and VD01 Create Customer (SD) are incompatible since assets may be sold to non-existent or fraudulent customers.
XD01 Create customer (centrally) and F-39 Clear customer down payment are incompatible since the user may have the ability to enter or modify down payments for customers and the user may have the ability to create or modify customer account information should be segregated. If the same person can process both items, unauthorized changes could be made and possibly not detected. Th.
VA01 Create sales order and FBCJ Cash journal are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
XK02 Change Vendor (Centrally) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
ME21N Access to Create Purchase Order and ABMA Manual Depreciation are incompatible since assets may be acquired at an overvalued or undervalued price and then depreciated. Unplanned depreciation, manual depreciation, and asset value write-ups are processed incorrectly or without authority to proceed.
VA02 Change sales order and F-32 Clear customer are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
FK01 Create Vendor (FI) and VD02 Change Customer (SD) are incompatible since assets may be sold to non-existent or fraudulent customers.
VD01 Create customer (sales) and VL01N Create outbound delivery with order ref are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
VF02 Change Billing Document and XD02 Change Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VA01 Create sales order and F-52 Post incoming payments are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
FK01 Create Vendor (FI) and FD02 Change Customer (FI) are incompatible since assets may be sold to non-existent or fraudulent customers.
FD01 Create customer (accounting) and VL02N Change outbound delivery are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
VA01 Create sales order and FF/4 Interface for check deposit data entered externally are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
VD02 Change customer (sales) and VL01N Create outbound delivery with order ref are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
VA01 Create sales order and F-04 Post with clearing are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
VD01 Create customer (sales) and F-29 Post customer down payment are incompatible since the user may have the ability to enter or modify down payments for customers and the user may have the ability to create or modify customer account information should be segregated. If the same person can process both items, unauthorized changes could be made and possibly not detected. Th.
FD02 Change customer (accounting) and VL01N Create outbound delivery with order ref are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
VA01 Create sales order and FB05 Post with clearing are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
VA01 Create sales order and FF/5 Post check deposit data entered externally are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
FK02 Change Vendor (FI) and VD01 Create Customer (SD) are incompatible since assets may be sold to non-existent or fraudulent customers.
VL02N Change outbound delivery and F-30 Post with clearing are incompatible since the user may create fictitious/incorrect delivery and enter payments against these, potentially misappropriating goods.
FD01 Create customer (accounting) and F-32 Clear customer are incompatible since the user may create a customer and then post payments against the customer.
VD01 Create customer (sales) and F-26 Incoming payments fast entry are incompatible since the user may create a customer and then post payments against the customer.
XD01 Create customer (centrally) and FBCJ Cash journal are incompatible since the user may create a customer and then post payments against the customer.
XD02 Change customer (centrally) and F-51 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
VD02 Change customer (sales) and F-29 Post customer down payment are incompatible since the user may have the ability to enter or modify down payments for customers and the user may have the ability to create or modify customer account information should be segregated. If the same person can process both items, unauthorized changes could be made and possibly not detected.
A risk-based approach to SAP segregation of duties The top 100 most critical segregation of duties conflicts in SAP Segregation of Duties Fraud Risks & Solutions Security SOD Segregation of Duties SOD Conflicts and Role Based Authorization in SAP SAP Segregation of Duties SOX 404 and Risks
