Supplier master + purchase approval
Create or amend a business partner, then raise or approve purchase orders against it. The classic fictitious-supplier route.
Infor LN compliance guide
Infor LN Segregation of Duties
Quick answer: Segregation of duties in Infor LN means no single user can both create and approve a transaction that moves money, stock or master data. LN restricts access through user, role and session authorisations, but it will not tell you where conflicting combinations exist. Finding and evidencing those conflicts is a review exercise, and it is what auditors ask for.
This guide covers the conflict pairs that matter in a manufacturing business, how LN authorisations actually enforce them, why most SoD findings are really master-data and ownership findings, and the evidence pack a proper review should leave behind.
What segregation of duties means in an LN context
Segregation of duties (SoD) is a control principle: the person who initiates a transaction should not be the person who approves it, and the person who maintains the standing data should not be the person who posts against it. In Infor LN that principle has to be expressed through the authorisation model, because LN itself will happily let a correctly authorised user do both halves of a conflict.
LN access control works in layers. Users are linked to roles, roles carry session authorisations, and sessions are the individual LN screens and functions where work actually happens. Company and unit restrictions sit on top. If the role design is clean, SoD falls out of it naturally. If roles have grown organically since go-live, and they usually have, users accumulate session access nobody remembers granting, and the conflicts hide inside that accumulation.
The practical point: SoD in LN is not a setting you switch on. It is the product of role design, session authorisation discipline and periodic review. Most UK manufacturing SMEs on LN have never run that review, which is why it tends to surface first as an audit finding.
Why SoD findings usually appear after go-live
During an implementation, access is granted generously so the project keeps moving. Consultants get wide roles, superusers get everything, and temporary access becomes permanent because nobody owns the removal step. Two years later an auditor extracts the user list and finds a planner who can create suppliers, raise purchase orders and receive goods, or a finance user who can maintain payment details and run the payment batch.
None of that means fraud happened. It means the business cannot show that it could not happen, and that is the finding. The fix is rarely technical. It is deciding who should hold what, documenting the exceptions the business chooses to accept, and putting a mitigating control around each accepted exception.
The conflict pairs auditors check first
Every business tunes its own conflict matrix, but in an LN manufacturing environment these combinations are where a review should start.
Goods receipt + invoice approval
Receive goods in the warehouse and approve the matching supplier invoice. Breaks three-way match integrity.
Payment data + payment run
Maintain supplier bank details and execute or approve the payment batch. The highest-risk pairing in most reviews.
Inventory adjustment + approval
Post stock corrections or cycle-count adjustments and approve them. Hides shrinkage and masks process failure.
Customer master + credit control
Amend customer credit limits or terms and release blocked sales orders for the same accounts.
Master data + transaction posting
Maintain item costs, price books or routings while also posting the production or finance transactions that consume them.
How to run an SoD review on Infor LN
A workable review does not need six months or a GRC platform. It needs the authorisation data, a conflict matrix the business agrees with, and someone prepared to chase the exceptions to a decision.
- Extract the access model. Users, roles, session authorisations and company links, straight from LN. This is the raw evidence everything else builds on.
- Agree the conflict matrix. Sit with finance and operations and agree which session combinations count as conflicts for this business. A borrowed generic matrix produces noise; a tuned one produces findings people act on.
- Map users to conflicts. Cross-reference the extract against the matrix. The output is a named list: which user, which conflict, through which roles.
- Decide each exception. For every conflict: remove the access, redesign the role, or accept it with a documented mitigating control such as a monthly review of that user's transactions.
- Sign it off and diarise it. A conflict register signed by the process owners, plus a repeat date. SoD is a cycle, not a one-off cleanse.
Larger LN estates sometimes license Infor Risk and Compliance or similar tooling to automate the detection step. That helps at scale, but tooling does not replace the decision step, and for a typical single-site UK manufacturer a disciplined extract-and-matrix review reaches the same audit outcome faster.
The evidence pack a review should leave behind
The deliverable is not a slide saying access was reviewed. It is a pack an auditor can reperform: the dated authorisation extract, the agreed conflict matrix, the user-to-conflict register, the decision and mitigating control for each exception, and the sign-off from finance and operations owners. Held together, those five artefacts turn SoD from an annual argument into a controlled routine.
This is the same evidence-first approach covered in the wider Infor LN compliance checklist, and it pairs naturally with migration reconciliation and reporting trust work: the businesses that cannot evidence access usually cannot evidence their numbers either.
FAQs
Does Infor LN have built-in segregation of duties?
LN enforces access through user, role and session authorisations. That restricts what each user can do, but it does not automatically detect conflicting combinations. SoD conflict analysis is a review and design activity, supported by tooling such as Infor Risk and Compliance or a structured authorisation extract.
What are the most common SoD conflicts in Infor LN?
Typical conflicts include creating a supplier and approving purchase orders for it, receiving goods and approving the supplier invoice, adjusting inventory and approving the adjustment, and maintaining master data while also posting the transactions that depend on it.
How do you evidence SoD for an audit in LN?
Extract users, roles and session authorisations, map them to a conflict matrix agreed with finance, list the users who hold conflicting combinations, and document either the fix or the accepted mitigating control for each one. The output is a signed conflict register, not a screenshot.
Can Digital Adaption run an Infor LN SoD review?
Yes. Digital Adaption runs authorisation and SoD reviews for UK manufacturers on LN, producing the conflict matrix, exception register and sign-off evidence that auditors and boards expect.
Research notes and official references
This guide is written for Digital Adaption clients and is grounded in official vendor material plus practical ERP authorisation, audit and reporting delivery experience.
- Infor CloudSuite Industrial Enterprise: Official Infor product context for LN in complex manufacturing environments.
Need an Infor LN SoD review with real evidence?
Start with the authorisation extract and the conflict your auditor already flagged. The register, decisions and sign-off pack follow from there.
View Infor LN consultant UK