Segregation of duties across spares, service acceptance and payment

Topics: ERP segregation of duties, role conflict matrix ERP, procure to pay access controls, compensating controls oil and gas

In oil and gas operations, procure-to-pay (P2P) and maintenance-to-settlement workflows rarely live inside a single software screen. A reliability engineer raises a work order in a CMMS, a buyer or contract administrator issues a purchase order or call-off in the ERP, a wellsite supervisor accepts work on a mobile ticket or Service Entry Sheet (SES), a storekeeper books spares into a remote warehouse, and accounts payable matches and pays the vendor invoice. When an access review inspects only standard ERP role names, it misses the two largest sources of control failure: cross-system identity masking (where an integration user posts field acceptances on behalf of whoever clicked approve in the portal) and unmonitored emergency or small-site composite roles.

The core operational decision in ERP segregation of duties is to build an action-pair conflict matrix across all connected operational and financial systems, enforce end-to-end user-ID propagation on every interface, and replace informal "management oversight" with hard pre-payment holds wherever remote staffing forces a compensating control. Sourcing, service-acceptance, and invoice-blocking workflows in SAP S/4HANA Sourcing and Procurement and SAP S/4HANA Cloud Service Entry Sheet Approval define how purchase orders, service acceptances, and invoice releases interact, while NIST SP 800-82 Rev. 3 establishes role-based access control and boundary protection between operational systems and enterprise networks. Specific internal-control, statutory-audit, and regulatory requirements must be confirmed with your internal audit, legal, and information-security authorities.

Four toxic action pairs in oil and gas spares and service workflows

Rather than starting with hundreds of abstract transaction codes, operations and finance owners should anchor their conflict matrix on four high-consequence action pairs where one person could otherwise originate and conceal an erroneous or fraudulent transaction:

1. Chain C1 — Vendor Master / Bank-Account Maintenance + Payment Run or Invoice Entry: If a user can create a supplier or alter bank-account details and also enter an invoice or release a payment batch, an unverified bank destination can be inserted and paid before month-end reconciliation.
2. Chain C2 — Purchase Order / Call-Off Creation + Service Entry Sheet (SES) or Goods Receipt Approval: In oilfield services, the accepted SES is the commercial trigger that opens the 3-way match gate. Frequently, a field contract engineer creates a call-off PO in the ERP and then approves the contractor's field ticket in an external portal. If the middleware posts the ERP SES under a technical user (RFC_INTEGRATION), standard ERP SoD checks see two different users (ENGINEER_01 and RFC_INTEGRATION) even though the same human performed both steps.
3. Chain C3 — Spares Goods Receipt (GRN) + Inventory Count / Write-Off Adjustment: At remote onshore fields or offshore platforms, giving the same storekeeper unrestricted rights to post purchase-order receipts and approve physical-inventory shrinkage adjustments allows short deliveries or missing high-value spares to be written off as routine stock variance.
4. Chain C4 — Invoice Tolerance Block Release + Outgoing Payment Execution: When an invoice automation or three-way match workflow blocks a vendor invoice for a price or quantity variance, the person who overrides or releases that block must never be able to execute the outgoing bank disbursement run.

1. 1. Propagate human identity across APIsRequire every CMMS or field-portal payload to pass the authenticated human approver's unique employee ID into the ERP document header alongside the technical integration user.
2. 2. Evaluate same-actor rules at acceptanceCheck at Service Entry Sheet or Goods Receipt release whether the accepting employee ID matches the PO creator or recent PO modifier on that transaction.
3. 3. Enforce hard splits or pre-payment holdsRemove toxic permission pairs for headquarters and standard sites; for authorised remote-site exceptions, automatically route self-paired transactions to an onshore supervisor hold queue before invoice match.
4. 4. Audit executed transaction pairs quarterlyRun quarterly SQL/audit-log joins across PO, SES, GRN, inventory adjustment, and payment tables to verify zero unapproved same-user execution pairs.

Review boundary: Role matrices, Firefighter/emergency access logs, and audit thresholds require sign-off from internal audit, finance, and cybersecurity owners ([O053](O053-service-entry-sheet-evidence.md), [O063](O063-invoice-automation-pilot.md)).

Worked example: Auditing 180 user accounts and ₹42.50 crore of quarterly P2P spend

All user counts, transaction volumes, and rupee figures below are illustrative teaching examples demonstrating how cross-system transaction analysis exposes hidden role conflicts.

Suppose an oil and gas operator reviews 180 active user accounts across its ERP and field service-management portal during a quarterly access audit covering 1,420 procure-to-pay and inventory transactions worth ₹42,50,00,000 (₹42.50 crore).

Initially, an ERP-only role check flags just 9 user accounts (C1 and C4 inside finance). When the audit team joins the ERP purchase-order, goods-receipt, and inventory-adjustment logs against the field portal's Actual_Approver_ID log (behind the API_SES_SYNC technical account), the total number of conflicted user accounts rises to 34 accounts (18.89% of the 180 users), affecting 68 executed transactions worth ₹3,84,00,000 (9.04% of quarterly spend):

1. Chain C1 (Vendor Bank Edit + Payment Release):
   • Audit finding: 4 accounts held a legacy post-migration support role permitting both vendor bank maintenance and payment proposal release; 6 transactions totalling ₹78,00,000 were processed by these IDs during the quarter.
   • Remediation: Hard permission removal on all 4 accounts (0 exceptions allowed). All 6 historical payments (₹78,00,000) were verified against independent bank-confirmation callbacks.
2. Chain C2 (PO Call-Off Creation + Portal/ERP Service Entry Acceptance):
   • Audit finding: 14 field contract engineers and supervisors created call-off POs in the ERP and approved the corresponding service tickets in the field portal, which posted 31 ERP Service Entry Sheets worth ₹1,92,00,000 via API_SES_SYNC.
   • Remediation:
     • For 11 onshore/regional engineers, portal-to-ERP identity propagation was enabled with a hard rule blocking SES approval whenever Portal_Approver_ID == PO_Creator_ID.
     • For 3 remote offshore night-shift supervisors (where staffing on the installation has only one supervisor per discipline on shift), a governed compensating control was configured: the system permits emergency night-shift call-off logging but automatically sets a Payment Block (Block Code: SOD-R) on the resulting SES until the onshore maintenance superintendent reviews and signs off the evidence pack within 48 hours.
3. Chain C3 (Spares Goods Receipt + Inventory Write-Off Adjustment):
   • Audit finding: 11 satellite storekeepers held composite warehouse roles allowing both MIGO goods receipt and MI07 physical-inventory variance posting, accounting for 22 transactions worth ₹69,00,000.
   • Remediation: Hard role split on all 11 accounts: storekeepers retain MIGO receipt and MI04 count-entry rights, while MI07 difference posting is restricted to the central materials controller and plant finance.
4. Chain C4 (Blocked Invoice Release + Outgoing Payment Execution):
   • Audit finding: 5 AP accounts held both MRBR invoice-block release and F110 payment-run execution rights, covering 9 transactions worth ₹45,00,000.
   • Remediation: Hard role split on all 5 accounts: MRBR variance release is restricted to procurement/finance controllers, while AP analysts execute F110 only on unblocked items.

Total Conflicted Accounts = 4 (C1) + 14 (C2) + 11 (C3) + 5 (C4) = 34 of 180 users (18.89%)

Structurally Remediated Accounts = 4 + 11 + 11 + 5 = 31 accounts (with 3 offshore accounts under hard pre-payment hold)

Total Exposed Quarterly Spend = ₹78,00,000 + ₹1,92,00,000 + ₹69,00,000 + ₹45,00,000 = ₹3,84,00,000 across 68 transactions

Total Conflicted Users34 of 180 users (9 ERP-only + 25 exposed by cross-system/storeroom join)

Exposed Spend Audited₹3,84,00,000 across 68 transactions (9.04% of ₹42.50 Cr quarterly spend)

Hard Role Splits Applied31 of 34 accounts (91.18% of conflicts eliminated structurally)

Governed Remote Exceptions3 offshore shift accounts (gated by mandatory onshore pre-payment hold)

Spend breakdown: ₹78.0 L (C1: 6 txns) + ₹192.0 L (C2: 31 txns) + ₹69.0 L (C3: 22 txns) + ₹45.0 L (C4: 9 txns) = ₹3,84,00,000 across 68 transactions.

Observable acceptance tests for cross-system SoD controls

Before closing an ERP/CMMS access remediation project, run three acceptance tests in a pre-production environment:

• ACT-O081-01 (Cross-system identity propagation & same-actor block): Create a purchase order in the ERP under user ENG_USER_04 and attempt to approve the corresponding field service ticket in the external portal under the same user ENG_USER_04 (transmitted to the ERP via the API_SES_SYNC integration account). Pass condition: The ERP receives Portal_Approver_ID = ENG_USER_04, detects that it matches PO_Creator_ID = ENG_USER_04, rejects automatic SES release, and routes the service entry to an independent supervisor's approval queue.
• ACT-O081-02 (Remote-site compensating-control payment block): Using one of the 3 authorised offshore exception accounts (OFFSHORE_SUP_02), log an emergency call-off and field receipt during a simulated night shift. Pass condition: The system records the operational receipt so work can proceed, but automatically applies payment block SOD-R on the accounting document so the vendor invoice cannot be included in an F110 payment proposal until the onshore superintendent clears SOD-R with a timestamped review note.
• ACT-O081-03 (Storeroom count vs write-off separation test): Log in as a remote storekeeper (STORE_USER_07), post a purchase-order goods receipt (MIGO), enter a physical-inventory count (MI04), and attempt to post the resulting inventory variance write-off (MI07). Pass condition: The system permits MIGO and MI04 entry but blocks MI07 execution with an authorisation error, routing the variance document to the central materials controller.

Summary and next actions

Move your access review from static role names to verified cross-system transaction boundaries:

1. Instrument every CMMS, field-portal, and invoice-automation interface to write the authenticated human actor's ID into a dedicated ERP header field alongside the technical integration account.
2. Run a quarterly SQL or GRC join across executed POs, Service Entry Sheets, Goods Receipts, inventory adjustments, and payment runs to identify any transactions where the same employee ID executed both sides of Chains C1 through C4.
3. Strip MI07 inventory write-off, MRBR invoice-unblock, and vendor bank-activation permissions out of composite operational and support roles immediately.
4. Replace paper-based "compensating control memos" at remote sites with automated ERP payment blocks (SOD-R) that hold settlement until an onshore authority reviews the self-paired transaction.