Duty Segregation in Infor LN: How to Protect Your Business from Fraud and Compliance Failures

A single employee who can create a supplier, approve a purchase order, and release a payment in your ERP is a fraud risk – regardless of how trustworthy they appear. In Infor LN, the controls that prevent this scenario from existing are built around a principle called duty segregation, and getting them right is not optional for any organisation subject to financial audit or compliance oversight.

This article explains what duty segregation means in an Infor LN environment, how the system’s role-based security model enables it, where the most common conflicts occur in practice, and the steps needed to establish – and maintain – a defensible control framework.

What Duty Segregation Actually Means in an ERP Context

Duty segregation – also referred to as Separation of Duties (SoD) – is an internal control that prevents any single person from having end-to-end control over a sensitive business process. The logic is straightforward: if completing a fraudulent transaction requires two people, the risk of it happening drops considerably.

The concept is codified in the Committee of Sponsoring Organizations (COSO) Internal Control Framework, which is the baseline standard used by auditors worldwide to assess whether an organisation’s financial controls are adequate. For companies subject to the Sarbanes-Oxley Act (SOX), Section 404 specifically requires management to assess and certify the effectiveness of internal controls over financial reporting – and SoD gaps are one of the first things external auditors examine.

According to the Association of Certified Fraud Examiners (ACFE) 2024 Report to the Nations, organisations lose an estimated 5% of annual revenue to occupational fraud. The median loss per case across all industries was $145,000 – but cases involving override of internal controls had a median loss more than twice that figure.

In an ERP like Infor LN, where a single user session can touch procurement, finance, and logistics simultaneously, the risk is particularly acute. The same system that enables operational efficiency also creates the conditions for fraud if access rights are not structured correctly.

How Infor LN’s Security Model Supports Duty Segregation

Infor LN manages access through a layered role-based security architecture. Understanding this architecture is essential before you can assess where SoD gaps might exist.

Users and User Groups

Every LN user is assigned to one or more user groups, and each group is granted access to specific sessions – the individual screens and transactions within the system. A session might be as granular as “Enter Purchase Orders” or as broad as “Accounts Payable Administration.” Access at the session level is the first layer of SoD control.

Authorisation Roles

Beyond session access, Infor LN uses authorisation roles to define what a user can do within a session. A user might have access to open the purchase order session but only be authorised to view records, not to create or approve them. These roles map directly to business functions and are where SoD logic is primarily enforced.

Central Persons and Employee Links

LN connects ERP users to Central Persons, which link a login to an employee record. This matters for SoD because it allows the system to identify when the person approving a transaction is the same person who initiated it – something that should be flagged and blocked where applicable.

For organisations running Infor LN alongside other Infor products, it is worth noting that access governance across the wider Infor ecosystem – including how user roles are provisioned and monitored – is a core concern when designing integrations. If you are exploring how LN connects to other systems, the Sama team covers these architectural considerations as part of our broader Infor LN consulting services.

Common Duty Segregation Conflicts in Infor LN

In practice, SoD conflicts in Infor LN tend to cluster around a handful of high-risk areas. These are the ones that appear most frequently in compliance audits and internal reviews.

Procure-to-Pay (P2P)

The most common and highest-risk conflict zone. An SoD failure here typically means one user can create a supplier in the vendor master (bptmd1200m000), raise a purchase order, and then process the invoice and payment. Each of these steps should sit with a different authorisation role. The supplier creation and maintenance function, in particular, should be restricted to a data governance role with no payment processing rights.

Order-to-Cash (O2C)

In the sales cycle, risk arises when the same user can create a customer, raise a sales order, adjust pricing, and process credit notes or refunds. The ability to issue a credit note is especially sensitive because it can be used to reverse revenue without a corresponding return of goods.

Financial Posting and Reconciliation

In the Finance module, users who can create and post journal entries manually should not also have access to approve those entries or to reconcile accounts. The tfgld1500m000 (integration transactions) session is worth reviewing specifically – access to this session without proper controls allows a user to directly influence GL balances.

System Administration Access

This is often overlooked: LN system administrators who can modify user roles and permissions should not simultaneously have transactional access to sensitive business processes. An admin who can assign their own session rights is, by definition, a SoD risk regardless of the integrity of individual transactions.

ISACA’s Control Objectives for Information and Related Technologies (COBIT) framework identifies privileged access management as one of the highest-priority areas for ERP governance – and system administrator SoD conflicts are specifically cited as a material control weakness.

Setting Up and Enforcing SoD Controls in Infor LN

Establishing SoD controls in Infor LN is not a one-time configuration task. It requires an initial design phase, technical implementation, and an ongoing review cadence.

Step 1: Map Your Critical Business Processes

Before touching anything in the system, document the end-to-end flow of your highest-risk processes – P2P, O2C, and financial close are the starting points. For each process, identify every step and the LN session that executes it. This creates your process-to-session matrix, which becomes the foundation for role design.

Step 2: Define Incompatible Role Combinations

Using your process-to-session matrix, identify which session combinations represent a conflict. These are your SoD rules. A typical ruleset for a mid-size manufacturer running LN might include 40to80 individual conflict rules across P2P, O2C, and Finance. Each rule should be documented with the business rationale (e.g., “A user who can create a vendor must not have access to approve vendor payments”).

Step 3: Configure Role-Based Access in LN

With your ruleset defined, design user group structures in LN so that incompatible sessions fall into separate groups. Resist the temptation to bundle everything into a small number of “super roles” for convenience – this is where SoD debt accumulates fastest, particularly in organisations that grew quickly or went through ERP implementations under time pressure.

If your LN environment was implemented several years ago without a structured SoD design, a clean-up exercise – sometimes called a role remediation – is almost certainly warranted. This is also relevant for organisations migrating from Baan, where session-level security was handled differently. The approach to role design during an ERP implementation or upgrade is something we have covered in depth, and it connects directly to how Infor LN handles data integrity and financial controls across your ERP platform.

Step 4: Run Periodic SoD Conflict Reviews

Once controls are in place, they require a review cycle – at minimum quarterly, and before any major role change is pushed to production. In practice, SoD drift happens when:

• A user’s role is temporarily expanded to cover for a colleague and never reverted
• A new LN session is created for a process change without updating the SoD ruleset
• An implementation or upgrade introduces new session IDs that bypass existing role restrictions
• Staff changes mean a user inherits a role they held previously but which now conflicts with their current function

SoD and Audit Readiness: What Auditors Actually Look For

When external auditors – whether for SOX, GDPR, or a sector-specific framework – review your Infor LN environment, they are not just checking whether SoD rules exist. They want evidence of three things.

First, documented controls. A written SoD policy mapped to your LN role structure. If your role design is undocumented, auditors will assume it is uncontrolled.

Second, evidence of monitoring. User access reports run at defined intervals, with evidence that conflicts were reviewed and either remediated or formally accepted through a compensating control. The LN user role reports (accessible via the Security Management sessions) provide the raw data; the review activity needs to be documented separately.

Third, timely revocation. Terminated employees and role changes should be reflected in the system promptly. Auditors will cross-reference HR records against active LN users. An ex-employee with an active login – even one with limited access – is a finding.

A 2023 survey by Protiviti and NC State’s Enterprise Risk Management Initiative found that ERP access control failures were among the top five technology risks identified by compliance and internal audit leaders at large organisations – cited by 38% of respondents.

Infor LN’s native reporting tools provide adequate data for SoD monitoring at most organisations. For those with more complex requirements – particularly multi-site deployments or organisations using LN alongside other Infor products – automated SoD monitoring tools that sit above the ERP layer may be appropriate. Infor ION, which acts as the middleware layer across Infor applications, can play a role in surfacing access events for monitoring. You can read more about how ION handles cross-system data flows in the step-by-step guide to getting started with Infor ION.

Compensating Controls: When Full SoD Is Not Feasible

In smaller organisations, full SoD is sometimes structurally impossible – there simply are not enough people to separate every sensitive function. This is a recognised reality in the COSO framework and in SOX guidance for smaller reporting companies.

Where a conflict cannot be eliminated, a compensating control must be documented and consistently applied. Compensating controls in an Infor LN context typically include:

• Supervisory review of all transactions posted by users with conflicting access, evidenced by a dated sign-off
• Exception reporting configured in LN or Infor Birst to flag high-risk transactions (e.g., new vendor creations followed by payments within 30 days) for management review
• Physical segregation – a second person approves the output of sensitive transactions via a non-ERP process (signed paper authorisation, email approval trail), even if both parties have ERP access

Compensating controls must be documented in your SoD policy and reviewed as part of the same audit cycle as your primary controls. An undocumented compensating control carries the same risk as no control at all from an auditor’s perspective.

Keeping SoD Controls Current as Your Infor LN Environment Evolves

SoD is not a configuration you complete once at go-live. Infor LN environments change – new modules are added, business processes are restructured, users change roles, and system upgrades introduce new sessions and security objects.

The most effective way to keep controls current is to embed SoD review into your change management process. Any change request that touches user access, role configuration, or process design should trigger a SoD impact assessment before the change reaches production. This is particularly important in organisations running complex multi-module LN environments, where a change in one module can introduce an unintended conflict in another.

For organisations considering a migration to Infor CloudSuite or an LN upgrade, the role design work done ahead of the migration is an opportunity to reset SoD controls from a clean baseline rather than carry forward years of accumulated access drift. The Infor CloudSuite implementation considerations covered by Sama address this as part of the broader upgrade planning process.

Key Takeaways

Duty segregation in Infor LN is not a theoretical compliance exercise. It is a practical control that protects against fraud, satisfies auditor requirements, and reduces the risk of costly errors reaching your financial records.

The core steps are clear: map your sensitive processes to LN sessions, define incompatible role combinations, configure your user group structure accordingly, and establish a recurring review cycle. Where full SoD is not achievable, document and apply compensating controls consistently.

If your LN environment was implemented without a structured SoD design – or if it has grown in complexity over time without corresponding access governance – a formal SoD review is likely overdue. Sama Consulting’s team has deep experience in Infor LN security design and compliance readiness across manufacturing, aerospace, and distribution environments.

To discuss your current LN access structure or to scope an SoD review, contact the Sama Consulting team.