P2P analysis for SAP ERP toolkit

The P2P Analysis for SAP Robot toolkit is an analytics-as-a-service solution for monitoring purchase to payment (P2P) risk for organizations using SAP ERP systems. It analyzes and reports P2P data from SAP that may indicate fraud, waste or abuse.

The toolkit comes as a pre-configured solution that is applicable to most customers. Once deployed, you can update the analysis robot toolkit with new scripts as we release them. You can further customize it by adding custom scripts to refine the toolkit. The imported data can be output to Results or Excel files.

Note

The P2P Analysis for SAP ERP Robot does not support the following:

  • Analytics Exchange (AX)
  • Robots Cloud Agent for production purposes
  • Custom analytics and data sources
  • Any reporting other than Excel/Results outputs

System and subscription requirements

Ensure that you meet the following subscription and system requirements to use the P2P Analysis for SAP ERP Robot.

Requirement Notes
ACL Robotics Enterprise Edition Robot toolkits are available as add-ons

On-premise Robots Agent version 15

Verify the version to be installed - Unicode or Non-Unicode
ACL for Windows version 15
  • Ensure that the installation uses the same encoding as the Robots Agent(Unicode or Non-Unicode).
  • Having a local installation of ACL for Windows can be helpful for troubleshooting purposes or for developing custom scripts.
SAP ERP Data Integration Robot Ensure that the SAP ERP Data Integration Robot has been successfully deployed into your organization and is currently running.

About the toolkit

The toolkit installs several components in Diligent One.

Component Count Name
Collection 2

P2P Analysis For SAP ERP - Development

P2P Analysis For SAP ERP - Production
Analysis

4
  • Vendor Management (one per Collection)
  • Accounts Payable (one per Collection)
Robot 1 P2P Analysis For SAP ERP
Analytic Tables 25 For more information, see Analytics for SAP ERP.

P2P Analysis For SAP ERP robot

The P2P Analysis For SAP ERP robot is automatically created when the toolkit is installed. This robot contains the following:

  • Analytic scripts - Contains the core scripts to import and process data.

    Note

    You should not modify the analytic scripts. Modifying the scripts may result in failures while running tasks. Any modifications required should be configured in the User Analytic Configuration file or uploaded as custom analytic scripts.

  • (Optional) Custom analytic scripts - Scripts that are manually uploaded to add new customer-specific analytic capabilities to the robot or make a data logic changes. These scripts take precedence over the default analytic scripts and should be thoroughly reviewed.

  • Configuration files - All the configuration files listed in the following table are available in the Input/Output tab of the robot.

    File Name Description Mode
    P2P_SAP_Default_
    Analytic_Configuration.xlsx

    Contains default configurations.

    Note

    You should not modify this file. Modifying the file may result in failures while running tasks. Any modifications required should be configured in the User Analytic Configuration file or uploaded as custom analytic scripts.

    		 Generated automatically by the robot
    Result_Table_IDs.csv Contains the destinations for the tables exported to Results, within the respective Development and Production collections.

    Generated automatically by the robot
    User Analytic Configuration File

    Contains custom configurations that must override configurations provided in the default analytic configuration file.

    Configurations in this file takes precedence over inputs in the default analytic configuration file.

    NOTE: If customizations exceed the capabilities of the User Analytic Configuration file, a custom script may be added.

    		 Manually uploaded when implementing the toolkit

  • Robot task - Executes the default and custom scripts within the robot and contains the following information.

    Parameter Description
    Export to HighBond Results?

    Specifies whether to export imported data to Results. Options available are as follows:

    • Export to Results - Overwrite - Overwrite the data in results tables each time data is exported.
    • Export to Results - Append - Appends data to the results tables.
    • Do not export - Does not export data to Results.
    Export to Excel?

    Specifies whether to export the current results to an Excel file or not. Options available are as follows:

    • Export to Excel
    • Do not export
    HighBond Access Token

    Token required to connect to Results. If exporting to Results is disabled, any random value can be provided for this parameter.

Linked tables

The required shared tables from the SAP ERP Data Integration robot is linked to the P2P Analysis for SAP ERP robot the Input/Output tab. When the analysis robot task runs, it pulls data from the linked tables and uses it to process the core analytic logic defined.

Note

You can create multiple analysis robots and link only the required tables to segregate the robots for specialized tasks or set of tasks.

Analytics for SAP ERP

The analytics for SAP ERP are listed in the following table.

Error logging

Any errors detected while running the task are logged to the Error Log table for each analytic. If the record count is 0, an error message is written to the Error Log table.

Tip

Review the error log after the task runs, even if the analytic returned no exceptions to ensure that the table was not flagged as having 0 records. For example, user input parameters from the User Analytic Configuration file can be ignored if the file is not formatted properly.

What each analytic does

Vendor Management Analytics

Analytic Name Description
P2P01VM_Vendor_
Missing_Phone_Number

This analytic identifies vendors with no primary phone number in the vendor master file.

  • To check for any missing phone numbers in the field LFA1_TELF1, it strips any non-numeric digits from the field and checks the remaining data for any blanks.
  • This analytic does not analyze missing values in the field LFA1_TELF2.

The result table for this analytic is R_P2P01VM_Vendor_Missing_Phone_Number.
P2P02VM_Vendor_
Missing_Banking_Data

This analytic identifies vendors with no bank account number or bank key associated in the vendor master file.

  • To check for missing data in the LFBK_BANKN and LFBK_BANKL fields, it strips any non-alphanumeric characters from the field and checks the remaining data for any blanks.
  • It reports any instance of missing data in the LFBK_BANKN or LFBK_BANKL fields.

The result table for this analytic is R_P2P02VM_Vendor_Missing_Banking_Data.
P2P03VM_Vendor_
Missing_Tax_ID

This analytic identifies vendors with no primary tax ID associated in the vendor master file.

  • To check for any missing tax IDs in the field LFA1_STCD1, it strips any non-alphanumeric digits from the field and checks the remaining data for any blanks.
  • This analytic does not analyze missing values in the field LFA1_STCD2.

The result table for this analytic is R_P2P03VM_Vendor_Missing_Tax_ID.
P2P04VM_Vendor_
PO_BOX_Addresses

This analytic identifies vendors with postal box addresses that may not have a physical address as follows:

  • PO Box field is not blank and has no other address provided.
  • Address field contains a PO Box reference, possibly alongside other address information. These vendors require manual review to determine if the data provided with the PO Box information represents a valid physical address.

The script analyzes the fields LFA1_STRAS and LFA1_PFACH.

  • To check for vendors with a blank street address and only a PO box address in the field LFA1_PFACH, it strips the LFA1_STRAS field of any non-alphanumeric characters before checking for blanks.
  • To check for street addresses that contain references to PO boxes (regardless of the value in the field LFA1_PFACH), the script uses a default parameter filter, which looks for variations of English language words, such as PO Box, Post Office Box, POB, etc.
    • The default parameter filter, v_P2P04VM_pobox, is configured in the Default_Config_Params worksheet of the Default Analytic Configuration File.
    • To overwrite the default parameter, you can edit the expression in the User Analytic Configuration File. Ensure that you follow the format and naming conventions as is from the Default Analytic Configuration File. You can modify the regular expression. For example, you can modify it to search for additional strings in other languages.

The result table for this analytic is R_P2P04VM_Vendor_PO_BOX_Addresses.
P2P05VM_Vendor_
Similar_Names

This analytic identifies vendors having similar names for common company suffixes, such as Inc and Ltd. It uses the FUZZYDUP command to detect similar names, with the user defining parameters, such as the minimum percentage match, Levenshtein distance to be applied, and excluding exact matches on vendor name (optional). By default, exact matches are included in the results.

The results of this analytic are presented in groups of similar or duplicated vendors names and the same vendor may be reported in multiple groups. For information on the processes applied by the FUZZYDUP command, see Fuzzy duplicates analysis.

The vendor country is not considered when checking for duplicates.

Three default parameters are available for this analytic in the Default_Config_Params worksheet of the Default Analytic Configuration File. If the default parameters do not apply, or are incomplete, you can declare the required values in the User Analytic Configuration File. Ensure that you follow the format and naming conventions as is from the Default Analytic Configuration File. You can use the following information to populate the values correctly in the User Analytic Configuration File:

  • v_P2P05VM_levdist - The maximum allowable Levenshtein distance between two strings for them to be identified as fuzzy duplicates and included in the results. The LEVDISTANCE value cannot be less than 1 or greater than 10. Increasing the LEVDISTANCE value increases the number of results by including values with a greater degree of fuzziness.
  • v_P2P05VM_diff_perct - A threshold that limits the difference percentage or the proportion of a string that can be different. The percentage that results from an internal analytic calculation performed on potential fuzzy duplicate pairs must be less than or equal to the DIFFPCT value for the pair to be included in the results. The DIFFPCT value cannot be less than 1 or greater than 99. If DIFFPCT is omitted, the threshold is turned off and difference percentage is not considered while processing the FUZZYDUP command.
  • v_P2P05VM_exact - Includes (T) or excludes (F) exact duplicates in the results.

The result table for this analytic is R_P2P05VM_Vendor_Similar_Names.
P2P06VM_Vendor_
Same_Address

This analytic identifies vendors with same addresses, based on street addresses with generic street suffixes, such as Street, Road, Rd, or Avenue, replaced by a standardized abbreviation.

Addresses are identified as same when they meet one or both of the following criteria:

  • Standardized street address is identical
  • Combined numeric digits in the street address and postal code are identical

Vendors with blank street addresses are not included in the analysis. Vendor addresses that contain only non-alphanumeric characters, such as hyphens (-) are considered as blank.

The results of this analytic are presented in groups of matched addresses with the field c_Match_Type, which identifies whether it is an address match or a numeric match. The field c_Matched_Key identifies the address component matched by the vendors in the group. When vendors match on both criteria, they are reported only once, as an address match.

If the result group of the numeric match has additional vendors that are not matched on street address, both groups are reported in full. A vendor can be a member of more than one result group. For example, Vendor A’s physical address may match that of Vendor B's, and Vendor A’s combined numeric digits may match that of Vendor C.

The result table for this analytic is R_P2P06VM_Vendor_Same_Address.
P2P07VM_Vendor_
Same_Phone_Number

This analytic identifies vendors whose primary or secondary phone numbers match that of another vendor. Telephone numbers are reported as same when their numeric digits are identical after removal of any non-numeric characters, such as hyphens or brackets.

Primary or secondary telephone numbers that are blank are not included in the analysis. Telephone numbers with only non-numeric characters, such as hyphens or brackets are considered blank.

The results of this analytic are presented in groups of matched telephone numbers with the field c_Match_Type that identifies whether a vendor’s primary or secondary phone number is matched. Field c_Matched_Key identifies the telephone number that was matched by the vendors in the group.

A vendor can be a member of more than one result group. For example, Vendor A’s primary phone number may match that of Vendor B's, and Vendor A’s secondary phone number may match that of Vendor C's.

The result table for this analytic is R_P2P07VM_Vendor_Same_Phone_Number.
P2P08VM_Vendor_
Same_Banking_Data

This analytic identifies vendors whose banking information matches that of another vendor and checks the fields LFBK_BANKN and LFBK_BANKL. It reports vendors as potential duplicates when the combination of the two fields match another vendor, after removal of any non-alphanumeric characters, such as hyphens or brackets.

Vendors with blank data in both fields are not included in the analysis. Fields with only non-numeric characters in both fields, such as hyphens or brackets, are considered as blank.

The results of this analytic are presented in groups of matching banking data. Field c_Matched_Key concatenates the matching bank account number and bank branch code, separated by a pipe and strips any non-alphanumeric characters.

A vendor can be a member of more than one result group. For example, Vendor A has multiple bank accounts and an account may match Vendor B on the first bank account and Vendor C on the second bank account.

The result table for this analytic is R_P2P08VM_Vendor_Same_Banking_Data.
P2P09VM_Vendor_
Same_Tax_ID

This analytic identifies vendors whose tax ID matches that of another vendor and verifies the fields LFA1_STCD1 and LFA1_STCD2. It reports the Tax IDs as same when the alphanumeric characters are identical, after removing any non-alphanumeric characters, such as hyphens or brackets.

Blank tax IDs are not included in the analysis. Tax IDs with only non-alphanumeric characters, such as hyphens or brackets, are considered as blank.

The results of this analytic are presented in groups of matched Tax IDs, with the field c_Match_Type identifying whether the value in field LFA1_STCD1 or LFA1_STCD2 is matched. Field c_Matched_Key identifies the tax ID matched by the vendors in the group, after removal of any non-alphanumeric characters.

A vendor can be a member of more than one result group. For example, Vendor A’s tax ID in field LFA1_STCD1 may match Vendor B, and Vendor A’s tax ID in field LFA1_STCD2 may match Vendor C.

The result table for this analytic is R_P2P09VM_Vendor_Same_Tax_ID.
P2P10VM_Vendor_
Employee_Name_Match

This analytic identifies vendors whose company name matches either an employees first name or last name, or both.

For specific scenarios, the analytic matches the names as follows:

  • Uses the last name for employees with only a single letter as the first name or a blank first name.
  • Uses the first name for employees with only a single letter as the last name or a blank last name.
  • Excludes employee records with no first or last name from analysis.

To match a vendor and an employee, the country must be the same (LFA1_LAND1 and PA0006_LAND1).

A vendor may match for more than one employee. For example, vendor Alexander Muller Inc matches employees Alexander Smith and Sarah Muller.

An employee may match for more than one vendor. For example, employee Alexander Smith matches vendors Alexander Muller Inc and Smith Brothers Ltd.

The result table for this analytic is R_P2P10VM_Vendor_Employee_Name_Match.
P2P11VM_Vendor_
Employee_Address_Match

This analytic identifies vendors whose physical address or numeric postal code matches that of an employee in the same country. Addresses of both vendors and employees are standardized prior to comparison by replacing generic street suffixes, such as Street, Road, Rd, and Avenue, with standardized abbreviations.

Addresses are matched when they meet one or both of the following criteria:

  • Standardized street address is identical
  • Combined numeric digits in the street address and the postal code are identical

The analytic does not include vendors and employees with blank street addresses. Addresses that contain only non-alphanumeric characters, such as hyphens, are considered as blank.

The results of this analytic are presented in groups of matched addresses, with vendor and employee fields displayed side by side.

  • Field c_Match_Type identifies whether the match is an address match or a numeric match.
  • Field c_Matched_Key identifies the address component that matched between the vendors and employees in the group.

When vendors and employees match on both criteria, they are reported only once, as an address match.

If the result group of the numeric match has additional vendors or employees that are not matched on street address, it reports both groups in full. A vendor can be a member of more than one result group. For example, Vendor A’s physical address may match Employee A, and Vendor A’s combined numeric digits may match Employee B.

To detect a match between an employee and a vendor, the vendor country and employee country must be the same.

The result table for this analytic is R_P2P11VM_Vendor_Employee_Address_Match.
P2P12VM_Vendor_
Employee_Phone_
Number_Match

This analytic identifies vendors whose primary or secondary phone numbers match that of an employee.

Telephone numbers are reported as same when their numeric digits are identical, after removal of any non-numeric characters, such as hyphens or brackets.

Blank primary or secondary telephone numbers are not included in the analysis. Telephone numbers with only non-numeric characters, such as hyphens or brackets are considered as blank.

The results of this analytic are presented in groups of matched telephone numbers.

  • Field c_Match_Type identifies the vendor phone numbers matched.
  • Field c_Matched_Key identifies the telephone number that matched the employee(s) in the group.

A vendor can be a member of more than one result group. For example, Vendor A’s primary phone number may match Employee B, and Vendor A’s secondary phone number may match Employee C.

To detect a match between an employee and a vendor, the vendor country and employee country must be the same.

The result table for this analytic is R_P2P12VM_Vendor_Employee_Phone_Number_Match.
P2P13VM_Vendor_
Employee_Banking_
Data_Match

This analytic identifies vendors whose banking information matches that of an employee with the same banking country. It compares the vendor fields - LFBK_BANKN and LFBK_BANKL, to the employee fields - PA0009_BANKN and PA0009_BANKL.

To match the vendors, the combined BANKN and BANKL fields must match those of an employee, after removal of any non-alphanumeric characters, such as hyphens or brackets. The vendor and employee master tables are joined on LFBK_BANKS and PA0009_BANKS as well to ensure that the country is same.

Records with blank banking fields are not included in the analysis. Banking fields with only non-alphanumeric characters, such as hyphens or brackets are considered as blank.

The results of this analytic are presented in groups of matched banking fields with field c_Matched_Key identifying the combined banking details of the employee(s) in the group. To detect a match between an employee and a vendor, the banking countries must be the same.

The result table for this analytic is R_P2P13VM_Vendor_Employee_Banking_Data_Match.
P2P14VM_Frequent_
Bank_Account_Changes

This analytic identifies frequent changes made to a vendor's bank account details, based on the count of distinct change documents. Change documents are obtained from the joined table CDHDR_CDPOS, which is filtered on ObjectClass = 'KRED', CDPOS_TABNAME = 'LFBK' and CDPOS_FNAME = 'KEY' as well as using a date range.

To analyze a vendor’s bank account changes, the total distinct document change count must be greater than or equal to the specified parameter threshold. Vendors with company codes that are excluded are not shown in the results.

A default parameter, v_P2P14VM_change_count, is available for this analytic in the Default_Config_Params worksheet of the Default Analytic Configuration File. If the default parameter does not apply, or is incomplete, you can declare the required values in the User Analytic Configuration File. Ensure that you follow the format and naming conventions as is from the Default Analytic Configuration File. You can enter a numeric value without quotes. The unique change document count must be greater than or equal to the specified threshold to be reported.

The result table for this analytic is R_P2P14VM_FREQUENT_BANK_ACCOUNT_CHANGES.
P2P99VM_Vendor_
Summary_Matrix

This analytic obtains vendor counts through the matrix table generated by the enabled analytics. Each matrix table summarizes the results of the analytic to obtain an exception count per unique vendor ID (not counting multiple company codes associated with a vendor).

This analytic accumulates the matrix data from all analytics and cross-tabulates the results across each vendor and analytic. A computed field calculates the total exception counts by vendor across all exceptions, and sorts the results in descending order on total count.

The Vendor Summary Matrix allows for a targeted review of the vendors that have been flagged the most across all analytics. Only those vendors with exceptions in at least one of the enabled analytics are included. Any other enabled analytics without exceptions for the vendor are counted as 0. Vendors with no exceptions in any analytics are not included. If none of the enabled analytics generated any exceptions, there are no vendors to report and the matrix will be empty. This scenario is logged in the Error Log table and identifies the reason for the matrix being empty.

The result table for this analytic is R_P2P99VM_Vendor_Summary_Matrix.

Accounts Payable Analytics

Analytic Name Description
P2P01AP_Duplicate_Transactions

This analytic identifies possible duplication transactions that are likely caused by either the vendor or AP staff error.

A transaction is defined as a line item of an invoice. Duplicate transactions are identified on the basis of 12 different combinations of fields, these are called sub-tests. For more information about the sub-tests, see P2P analysis for SAP ERP toolkit.

Duplicate line items on a single invoice are not reported for analysis and review, because such line items are mostly a scenario of the same item / services intended for different locations or entities. Many of the risks of duplicate invoices such as coding the same purchase to two different vendors or entering an incorrect vendor invoice number do not apply within the same invoice. These line items may be reported if they are duplicates of one or more line items in another invoice.

A same-same different concept is applied to eliminate reporting the same set of flagged transactions multiple times. This is achieved by defining different fields as one or more fields that were identified as duplicates in a prior sub-test.

Example

  • The sub-test P2P01AP_01 flags transactions with duplicate vendor number and vendor invoice number. There may or may not be other duplicates, such as the same invoice date or transaction amount, as this sub-test has no requirement for any other fields being different except document number.
  • The sub-test P2P01AP_02 flags transactions with duplicate vendor number, invoice date, and transaction amount.
    • This transaction would have been flagged already by the first sub-test, if the vendor invoice number was a duplicate. Therefore, the requirement is introduced that the vendor invoice number be different.
    • To reduce the possibility of false positives and find the most likely duplicates, the test also requires a similar vendor invoice number (defined as having an identical sequence of numerical digits after dropping all other characters).

Notes

  • A transaction is not excluded from analysis once it has been matched with another transaction. It is still available to be matched with other transactions on the set of same keys in subsequent sub-tests.
  • The sub-tests testing for duplicates in banking fields or phone numbers may legitimately report the same flagged transactions multiple times. A vendor can have multiple bank accounts as well as a primary and secondary phone number. Each bank account is tested individually, and if two vendors are matched on multiple bank accounts, the potential duplicates are reported for each match. The same is true for phone numbers.
  • The currency of the invoice does not have to be identical for sub-tests that look for same transaction amount (BSIK / BSAK_WRBTR). Flagged transactions with identical amounts but different currencies may highlight AP staff entry error.
  • The company code of the vendors in the flagged duplicates do not have to be identical.
  • The transactions with missing data in any of the same fields will be eliminated from analysis. Missing data in the different fields will continue to be analyzed.
  • The difference in handling of upper and lower case for same and different fields:
    • The same fields are not case-sensitive. For example, in sub-tests looking for duplicates in vendor name, ABC CORP and Abc Corp are treated as duplicates
    • The original different fields are case-sensitive. For example, in sub-tests that require different vendor invoice numbers for transactions to be flagged as duplicates on the same fields, vendor invoice numbers JAN-2021-07 and Jan-2021-07 are treated as being different and transactions matching on the same fields will be flagged.
    • The standardized different fields such as c_Vendor_Name_Sorted are used as defined, which may include conversion to upper case.

Default Parameters Two default parameters, v_P2P01AP_min_threshold and v_delete_P2P01AP, are available for this analytic in the Default_Config_Params and Script P2P01AP_Duplicate_Transactions worksheets of the Default Analytic Configuration File respectively. If the default parameters do not apply, or are incomplete, you can declare the required values in the User Analytic Configuration File. Ensure that you follow the same format and naming conventions as mentioned in the Default Analytic Configuration File.

Result table for this analytic R_P2P01AP_Duplicate_Transactions.
P2P02AP_High_Risk_Keywords

This analytic identifies transactions and vendor details containing high-risk keywords that may indicate errors, waste, or abuse.

The following fields are examined:

  • Invoice description at header level: BKPF_BKTXT.
  • Line item description: BSIK / BSAK_SGTXT.
  • Vendor name field: c_Full_Vendor_Name. The c_Full_Vendor_Name concatenates the fields LFA1_NAME1 through to LFA1_NAME4 in the data preparation script P_LFB1_LFA1_BUKRS. If the vendor table is populated with no records, then only the invoice description and line item description fields are tested.

Several common high-risk keywords are stored in a parameter table in the Default Analytic Configuration File.

  • The default keywords can be replaced with an alternate set by populating the parameter table in the User Analytic Configuration File. Note that if any of the default keywords are to be applied, you must mention them to the User Analytic Configuration File. If a parameter table is provided by the user, then the default parameter table is discarded completely.
  • The keyword search is not case-sensitive.
  • The keyword search identifies partial matches, where the keyword is a sub-string of a word in the search fields, such as keyword Gift being found in the description containing the word Gifts.
  • The keyword search does not identify partial matches when a word or words in the search fields are a sub-string of the keyword. For example: Keyword payment in description containing pay vendors or pay mentioned vendors.

If there is a match of more than one keyword across the three test fields, the analytic concatenates them in a pipe-separated list, which is displayed in the field c_Matched_Keyword_List. In addition, the analytic reports the field Primary_Matched_Keyword, which contains the first matched keyword listed in the parameter table. This functionality assumes that the parameter table is populated with keywords in descending order of criticality.

  • Multiple matches of the same keyword in one or more fields are reported only once.
  • Multiple keyword matches are reported in the order in which they appear in the parameter table.

A default result filter is not available. You can declare the result filters in the User Analytic Configuration File to further refine the results.

Default Parameters A default parameter, v_P2P02AP_min_threshold, is available for this analytic in the Default_Config_Params worksheet of the Default Analytic Configuration File. If the default parameter does not apply, or is incomplete, you can declare the required values in the User Analytic Configuration File. Ensure that you follow the same format and naming conventions as mentioned in the Default Analytic Configuration File.

Result table for this analytic R_P2P02AP_High_Risk_Keywords.
P2P03AP_Outliers_Std_Dev

This analytic identifies unusual transaction amounts for a given vendor that are equal to or greater than a specified number of standard deviations from the median transaction amount of the vendor. These transactions may indicate an error by either the vendor or AP staff.

The following pseudo-code describes the process in detail. Each invoice line item is treated as a transaction.

  • The total transaction count for a given vendor is calculated, regardless of the company code. This field is needed only for reporting purposes.
  • The OUTLIER command is used to report any amounts in local currency (DMBTR) that are at least n standard deviations from the median transaction amount for a given vendor, where n is a configurable parameter. A single currency by vendor is assumed. Varying currencies by company code for the same vendor are not supported.
  • The flagged vendors are joined with the vendor master table (P_LFB1_LFA1_BUKRS) to look up additional reporting fields.

A default result filter is not available. You can declare the result filters in the User Analytic Configuration File to further refine the results, such as the minimum outlier amount to report.

Default Parameters A default parameter, v_P2P03AP_num_std_dev, is available for this analytic in the Default_Config_Params worksheet of the Default Analytic Configuration File. If the default parameter does not apply, or is incomplete, you can declare the required values in the User Analytic Configuration File. Ensure that you follow the same format and naming conventions as mentioned in the Default Analytic Configuration File.

Result table for this analytic R_P2P03AP_Outliers_Std_Dev.
P2P04AP_Outliers_Benford

This analytic identifies unusual transaction amounts based on Benford’s analysis of the leading n digits. These transactions may indicate an error by either the vendor or AP staff.

Initially, all transactions (line items) are examined to evaluate the distribution of the full data set and identify the statistical outliers. Outliers are defined as leading digit combinations whose frequency do not match the expected frequency according to Benford’s formula. This subset of transactions is further filtered down to only those leading digit combinations with a Z-Stat ratio equal to or greater than the user-specified threshold (default is 7).

For each of the resulting flagged leading digit combinations, the vendors with the highest transaction counts are carried forward to the results, as these vendors contribute most to the statistical outliers. Vendors with lower transaction counts are not reported in the results or counted towards the vendor hit matrix.

The following pseudo-code describes the process in detail:

  1. Defines computed field c_Leading_Digits, which captures the leading n digits of every amount in invoice currency (BSIK / BSAK_WRBTR).
  2. Applies the BENFORD command to:
    • Count the actual occurrences of each possible leading digit combination in the transaction data.
    • Compare the actual count to the expected count (calculated using the Benford formula).
    • Display the Z-Stat ratio for each leading digit combination, which is a measurement in standard deviations of the distance between the actual count and the expected count.
  3. Extracts every leading digit combination from the BENFORD output table with a Z-Stat ratio higher than n, where n is a user defined value (default is 7).
  4. Joins the flagged leading digit combinations to the transaction table, field c_Leading_Digits to carry forward only those transactions with at least the specified Z-Stat ratio.
    • Transactions of a given vendor may map to one or more of the flagged combinations, or
    • Transactions of a given vendor may not map to any of the flagged combinations and the vendor is dropped from further analysis.
  5. Summarizes the resulting transactions on vendor and leading digit combination, to obtain a transaction count for combination. The transaction count may reflect line items from one or more invoices.
  6. Sorts the summarized table by the leading digit combination and the transaction count (descending order), so that the highest transaction count appears first for every leading digit combination.
  7. Summarizes the resulting table again, on leading digit combination only, so that only the highest transaction count for each leading digit combination is carried forward.
  8. Joins the full AP transaction table to the summarized table containing the vendors with the highest transaction count per leading digit combination, so that only these vendors are carried forward. The rationale for this step is as follows:
    • These vendors contribute most to the statistical outliers and are the focus of this analysis.
    • Vendors with a lower transaction count are not the focus of this analysis and are dropped from further processing.
  9. Joins the remaining vendors with the vendor master table (P_LFB1_LFA1_BUKRS) to look up additional reporting fields.

A default result filter is not available. You can declare the result filters in the User Analytic Configuration File to further refine the results, such as the minimum transaction amount to report.

Default Parameters Two default parameters, v_P2P04AP_leading_digits and v_P2P04AP_zstat_threshold, are available for this analytic in the Default_Config_Params worksheet of the Default Analytic Configuration File. If the default parameters do not apply, or are incomplete, you can declare the required values in the User Analytic Configuration File. Ensure that you follow the same format and naming conventions as mentioned in the Default Analytic Configuration File.

Result table for this analytic R_P2P04AP_Outliers_Benford.
P2P05AP_SOD_Vendor_AP

This analytic identifies posting patterns that may indicate either the vendor or AP staff error. Specifically, this analytic reports transactions posted by users that have also created the vendor master record in LFA1, LFB1, or both, resulting in potentially inadequate segregation of duties.

It compares the transaction field - BKPF_USNAM to the vendor fields - LFA1_ERNAM and LFB1_ERNAM. In LFA1, only the entry matching the company code of the transaction is examined.

Initially, the full transactions table is examined at the line item level to identify all occurrences. The flagged transactions are then rolled up into a summary level report by user / vendor combination, showing a total transaction count and total transaction amount in local currency.

The summary report carries forward the data from the transaction (line item) with the highest amount in local currency found for each flagged user / vendor combination.

The following pseudo-code describes the process in detail. Each invoice line item is treated as a transaction.

  1. Joins the transaction table with the vendor master to look up the LFA1 and LFB1 users who created the vendor entry.
  2. Sorts the joined table by vendor, user name, and amount in local currency (in descending order), so that the highest transaction amount appears first for every combination.
  3. Filters the sorted table for transactions where:
    • The user who created the transaction is the same user who created the vendor entry in LFA1, or
    • The user who created the transaction is the same user who created the vendor and company code entry in LFB1.
  4. Summarizes the flagged transactions by user and vendor combination to produce a total transaction count and amount in local currency, with the line item fields from the transaction with the highest amount in local currency being carried forward.
    • Vendors are rolled up into a single record regardless of company codes.
    • The local currency for a vendor is assumed to be identical across all company codes when calculating the total amount.
  5. The summarized table is sorted to report the flagged user / vendor combinations in descending order on local amount (regardless of currency).

A default result filter is not available. You can declare the result filters in the User Analytic Configuration File to further refine the results, such as the minimum transaction amount to report.

Result table for this analytic R_P2P05AP_SOD_Vendor_AP.
P2P06AP_Posting_Patterns_Single_User

This analytic identifies posting patterns that may indicate either vendor or AP staff error. Specifically, this analytic reports vendors where, all transactions in the investigation period were posted by the same user across all the company codes of the vendor.

Initially, the full transactions table is examined at line item level to identify all occurrences of the same user posting all the transactions of the vendor. The flagged transactions are then rolled up into a summary level report by vendor, showing a total transaction count and amount in local currency.

The summary report carries forward the data from the transaction (line item) with the highest amount in local currency found for each flagged vendor.

The following pseudo-code describes the process in detail. Each invoice line item is treated as a transaction.

  1. Sorts the transactions table on vendor, user, and amount in local currency, in descending order.
  2. Summarizes the transactions table on vendor number and user name, to produce a table with a list of all users posting transactions for a given vendor.
    • Creates a total amount in local currency for each combination, renamed as c_Total_Trans_Amount_LC_VenUsr. The same currency is assumed across all company codes for the vendor.
    • Renames the count field as c_Trans_Count_VenUsr
    • Carries forward the data from the transaction (line item) with the highest amount in local currency found for each vendor / user combination.
  3. Summarizes the resulting table again, on vendor only, producing subtotals for the vendor as follows:
    • Total of c_Total_Trans_Amount_LC_VenUsr, renamed as c_Total_Trans_Amount_LC.
    • Total of c_Trans_Count_VenUsr, renamed as c_Trans_Count.
    • Carries forward the data from the first transaction (line item) found for each vendor. In the case of a single user, this will be the transaction with the highest amount in local currency due to the previous sort order.
    • Renames the count field as c_Unique_User_Count.
  4. Extracts all fields for those vendors whose unique user count is 1 and whose transaction count is equal to or greater than the specified threshold (default is 10).
  5. Joins the flagged vendors with the vendor master table (P_LFB1_LFA1_BUKRS) to look up additional reporting fields.

A default result filter is not available. You can declare the result filters in the User Analytic Configuration File to further refine the results, such as the minimum transaction amount to report.

Default Parameters A default parameter, v_P2P06AP_min_count, is available for this analytic in the Default_Config_Params worksheet of the Default Analytic Configuration File. If the default parameter does not apply, or is incomplete, you can declare the required values in the User Analytic Configuration File. Ensure that you follow the same format and naming conventions as mentioned in the Default Analytic Configuration File.

Result table for this analytic R_P2P06AP_Posting_Patterns_Single_User.