THE PLAYBOOK · CHAPTER 1
BIS Configuration Guide
Rules, thresholds, and detection logic for deploying Business Integrity Screening in an electrical distribution environment -- written for the audit-to-IT handoff.
Key takeaways -- read this first
- BIS is frequently licensed and dormant. Activation is a configuration task, not a development project. The first conversation is about whether it is licensed -- not whether it can be built.
- Starting with three to five rules in the highest-risk area is the right deployment posture. Volume before discipline produces exception queues no one reviews.
- Every rule in this guide has three components that must be defined before configuration begins: the detection condition, the threshold that makes an exception actionable, and the owner who resolves it.
- The pricing leakage detection rule -- identifying transactions where a generic material number was used when a catalog item was available -- is one of the highest-return rules in an electrical distribution environment. It requires cross-referencing material master data with billing records, which BIS can do natively once the rule logic is configured.
Detection rules
9 in guide
Across procurement, GL, pricing, and vendor integrity
Format
Handoff-ready
Formatted for IT configuration teams
Deployment
3 phases
From activation through ML enhancement
Reading time
25 min
SAP S/4HANA reference implementation
This guide uses SAP Business Integrity Screening in S/4HANA as the reference implementation. The detection logic, rule categories, and threshold design principles apply to equivalent anomaly detection modules in other ERP platforms. Configuration paths and transaction codes are SAP-specific.
Before IT Can Configure -- What Audit Must Define
BIS configuration starts with audit, not IT. IT can activate the module, set up the system connection, and deploy pre-built rules. But the threshold values, the scope parameters, and the exception workflow all require audit input before configuration begins. A BIS deployment that starts with IT and asks audit for requirements later produces rules that generate noise rather than findings.
1
Detection condition
What specific data pattern constitutes an exception worth reviewing? The condition must be precise enough that a developer can translate it into a BIS rule without interpretation. Generic conditions produce generic results.
2
Threshold
What value, count, or score makes the condition actionable rather than informational? Thresholds must be set before go-live, not after the first exception list generates fifty items no one can review.
3
Exception owner
Who receives the alert, reviews it, makes the disposition decision, and documents the outcome? Ownership defined before go-live -- exceptions without owners age without resolution.
The Rule Library -- Nine Detection Rules
Each rule is written in the format required for the audit-to-IT handoff: detection condition, data sources, threshold guidance, false positive filters, and the expected exception output.
The nine rules below cover the highest-risk areas for an electrical distribution environment.
AP Transaction Monitoring
Accounts payable transaction monitoring -- including duplicate payment detection -- is not covered in this guide. In environments where AP activity spans multiple systems (ERP, expense management platforms, and bank-managed card programs), SAP-native BIS rules can only detect duplicates within the SAP dataset. A cross-platform analysis tool is required for comprehensive AP duplicate detection. See the AP monitoring note in the ERP Audit Universe for guidance on the cross-platform approach.
R-02
Vendor-Employee Address or Bank Account Match
Vendor Integrity
Detection condition
Vendor master bank account number, street address, or email domain matches an active employee record in the HR system.
Data source
LFA1 (vendor master), LFB1 (vendor bank), employee master data (cross-system join required if HR is in a separate platform such as Workday)
Threshold guidance
Any match, regardless of amount. Match on bank account number is highest priority; address match is secondary.
False positive filters
Exclude vendors that are known employee reimbursement vendors with approved exception documentation. Exclude relocation or benefits vendors by vendor category.
Expected output
Vendor number, vendor name, matching field, employee ID, employee name, department, and any recent payment activity to the vendor.
Audit use
Vendor fraud / conflict of interest finding. Note: if HR data is in Workday, this rule requires a scheduled extract from Workday to a BIS-accessible staging table or a third-party cross-system tool.
R-03
Purchase Order Created After Goods Receipt
Procurement
Detection condition
A purchase order creation date is later than the goods receipt date for the same material document, indicating a retroactive PO.
Data source
EKKO (PO header, creation date), MSEG (goods movement, posting date), EKBE (PO history)
Threshold guidance
Flag all instances. Filter to amounts above a materiality threshold (e.g., $5,000) for initial deployment to manage volume.
False positive filters
Exclude emergency procurement exceptions with documented approval. Exclude inter-company transfers.
Expected output
PO number, PO creation date, GR document number, GR posting date, days between GR and PO creation, material, quantity, vendor, and purchasing group.
Audit use
Retroactive PO / procurement bypass finding. Systemic patterns by purchasing group indicate a training or enforcement gap.
R-04
Split Purchase Order Sequence
Procurement
Detection condition
Two or more POs to the same vendor, created within a configurable time window (default: 7 days), each below the competitive bid threshold, with a combined value above that threshold.
Data source
EKKO (PO header), EKPO (PO line items)
Threshold guidance
Set the individual PO threshold at 80% of the competitive bid threshold to catch near-miss splits. Set the look-back window at 7 days initially; extend to 14 if false positive rate is acceptable.
False positive filters
Exclude blanket orders and scheduling agreements (document type LP, LPA). Exclude POs where a framework agreement number is referenced.
Expected output
Both PO numbers, vendor, creation dates, individual amounts, combined amount, competitive bid threshold in effect, and purchasing group.
Audit use
Procurement control bypass. Escalate to buyer and purchasing manager for explanation.
R-05
Off-Hours GL Posting by Privileged User
GL
Detection condition
A journal entry posted outside standard business hours (configurable -- default: before 6:00 AM or after 8:00 PM local time, or on weekend) by a user with posting access beyond their normal transaction profile.
Data source
BKPF (accounting document header -- posting time, user), USR02 (user last logon, role assignment)
Threshold guidance
Flag all off-hours postings above a dollar threshold (e.g., $10,000). Lower threshold for users with broad posting authorization or system admin roles.
False positive filters
Exclude automated posting users (batch jobs, system users). Exclude known period-end close activities if the close schedule is documentable.
Expected output
Document number, posting date and time, posting user, user role profile, amount, GL account, cost center, and whether a reference document exists.
Audit use
Unauthorized manual entry / internal fraud indicator. High-risk when combined with round amounts or accounts with limited transaction activity.
R-06
Manual Journal Entry Without Reference Document
GL
Detection condition
A manual journal entry (document type SA or similar manual type) posted without a reference document number in the reference field (BKPF-XBLNR is blank or contains a generic placeholder).
Data source
BKPF (document header), BSEG (document line items)
Threshold guidance
Flag all manual entries without references above a materiality threshold (e.g., $25,000). No threshold for entries to specific high-risk accounts (intercompany, suspense, retained earnings).
False positive filters
Exclude system-generated documents (batch input, interface postings with known document types). Exclude entries where the text field contains a documented explanation that matches a pre-approved pattern list.
Expected output
Document number, posting date, user, amount, GL account, cost center, profit center, text field content, and whether a matching document exists in the referenced period.
Audit use
Unsupported journal entry finding. Cross-reference with period-end timing to identify whether entries are concentrated near close dates.
R-07
Inactive Vendor Payment
Vendor Master / Controls
Detection condition
A payment issued to a vendor whose master record has been flagged as blocked for payment or marked as inactive within the 90 days prior to the payment date.
Data source
LFA1 (vendor master, blocking indicators), BSEG (payment document), BKPF (document header)
Threshold guidance
Any amount. Vendor blocking status and payment should not coexist.
False positive filters
Exclude vendors blocked due to automatic credit hold that was subsequently released through the standard credit release transaction (F.28). Document the release approval as the exception basis.
Expected output
Vendor number, vendor name, blocking flag and date set, payment document number, payment date, payment amount, and the approver of the payment run.
Audit use
Vendor master integrity / payment control bypass finding.
R-08
SoD Conflict -- PO Creation and Approval by Same User
Procurement
Detection condition
A purchase order where the same user ID appears in both the creator field (EKKO-ERNAM) and the approval workflow history (SWWWIHEAD or equivalent workflow table).
Data source
EKKO (PO header, creator), workflow approval history tables
Threshold guidance
Any amount. SoD violation is binary -- the conflict exists regardless of dollar value.
False positive filters
Exclude emergency approval scenarios with documented dual-approval override. Exclude test system activity.
Expected output
PO number, creator user ID, approver user ID (matching), approval date, PO amount, vendor, and the authorization roles held by the user at the time of the transaction.
Audit use
SoD violation / procurement authorization finding. Cross-reference with GRC Access Control conflict register if active.
R-09
Inventory Adjustment Without Reason Code
Inventory / MM
Detection condition
A goods movement of type 551 (scrapping), 561 (initial stock entry), or 562 (reversal of initial stock) posted without a valid reason code in the movement reason field (MSEG-GRUND is blank).
Data source
MSEG (material document), MKPF (material document header)
Threshold guidance
Flag all occurrences regardless of quantity or value. Reason code discipline is binary.
False positive filters
Exclude system-generated movements from automatic replenishment processes (movement types generated by MRP, not by manual entry).
Expected output
Material document number, posting date, posting user, material number, quantity, value, plant, storage location, and movement type.
Audit use
Inventory control discipline / potential shrinkage indicator. Systemic missing reason codes indicate a process training or system enforcement gap; isolated missing codes in high-value materials indicate higher-risk investigation targets.
R-10
Pricing Leakage: Generic Material Number Used When Catalog Item Available
Pricing
Detection condition
A billing document line item uses a generic or placeholder material number (identifiable by material type UNBW, NLAG, or a configurable list of generic material prefixes) where the item description text contains a keyword match to an active catalog material with a valid condition record in the pricing tables.
Data source
VBRP (billing document line items), MARA (material master, material type), MVKE (sales data), A004/A005 (condition tables for customer/material pricing), KNA1 (customer master)
Threshold guidance
Flag all instances where a price difference exists between the billed amount and the applicable condition record price for the matched catalog item. Secondary threshold: flag all generic material line items above $500 regardless of price comparison if no condition record match can be performed.
False positive filters
Exclude non-stock items that are legitimately special-order and have no catalog equivalent (verify against purchasing info records). Exclude items where the order explicitly references a customer-authorized substitution.
Expected output
Billing document number, line item, generic material number used, matched catalog material number (if found), billed price, condition record price, price variance, customer number, sales order number, and the creating user.
Audit use
Pricing leakage / margin erosion finding. This is the highest-value rule in an electrical distribution environment. Generic material usage that bypasses the condition record pricing structure results in direct margin leakage at every affected transaction. Systemic patterns by branch, sales rep, or customer indicate a monitoring gap in the pricing control environment. Note: this rule requires configuration by someone with knowledge of your material master structure and generic material number naming conventions.
Deployment Phasing
BIS deployment is most effective when sequenced rather than launched at full scale.
Phase 1 — Months 1–2
Activation and First Rules
- IT activates BIS module and configures the system connection and data scope (company codes, document types)
- Deploy R-06 (Manual JE Without Reference) and R-09 (Inventory Adjustment Without Reason Code) as the first two rules -- high confidence, well-understood failure modes, and manageable exception volume. Both rules operate on SAP data natively with no cross-system dependencies.
- Establish the exception review workflow: assign reviewer, define disposition categories, set review cycle length
- Run for 60 days and measure false positive rate before adding rules
Phase 2 — Months 3–4
Core Rule Set
- Add R-03 (Retroactive PO), R-05 (Off-Hours GL Posting), and R-09 (Inventory Adjustment Without Reason Code)
- Calibrate thresholds based on Phase 1 learning -- adjust dollar thresholds if exception volume is too high or too low
- Begin documenting findings generated by BIS output for inclusion in the risk assessment
- Activate the BIS machine learning layer to begin establishing baseline transaction patterns
Phase 3 — Months 5+
Advanced Rules and ML Enhancement
- Add R-10 (Pricing Leakage) -- requires the most configuration effort due to material master cross-referencing; sequence it after the team has BIS operational experience
- Add R-02 (Vendor-Employee Match), R-04 (Split PO), R-07 (Inactive Vendor Payment), R-08 (SoD Conflict) as volume and review capacity allow. Note that R-02 requires a cross-system data join if HR is managed in Workday -- confirm the data availability before scheduling this rule for deployment.
- Enable ML-enhanced predictive scoring on high-volume rules to reduce false positives
- Connect BIS alert data to SAP Analytics Cloud dashboard for leadership visibility
The IT Handoff Package
The rules and thresholds in this guide are written to be handed to an IT GRC configuration team directly. Each rule contains the SAP table references, field names, and logic required for BIS rule configuration. What the IT team will need in addition: the specific company codes and document type scope to apply, the threshold values confirmed by audit, the exception owner names and routing logic for the alert queue, and the testing plan for validating each rule against historical data before going live.
What audit must provide before IT can configure each rule:
- Confirmed company code scope
- Document type inclusions and exclusions
- Dollar or quantity threshold value with documented rationale
- Exception owner name and role
- False positive filter list (any known legitimate patterns specific to your organization)
- Acceptance testing criteria (what constitutes a successful rule test)
The end-to-end monitoring workflow -- from data access configuration through exception closure