Essentials: Procure to Pay
Transcript of Essentials: Procure to Pay
Essentials:
Procure to Pay
Version 6.2.0 –2019/04
Supply chain risk is often a top strategic risk. It doesn’t matter the type of organisation you’re in, government, retail,
hospitality, services, manufacturing, healthcare, utilities, or otherwise, all organisations procure goods and services. The
Procure-to-Pay (P2P) process covers the most material risk areas, including requisitions, procurement, vendors,
receiving, invoicing and payables.
PAGE 3Accounts Payable
Don’t let anything slip through the cracks.
Sampling and manual cross- matching
purchase orders (POs) with invoices simply
doesn’t provide adequate risk oversight over
this
material process. Assess 100% of your
payables dataset to know with certainty
whether your requisitions and vendor billing
processes are healthy and accurate
Sample Analytics:
• Identify instances of PO date
occurring after invoice date
• Identify invoices paid greater than the
PO amount approved
• Identify instances if vendor paid by both
PO and sundry expense
PAGE 39Purchase Order ManagementTrack purchasing patterns and trends to
monitor the adherence of company policies,
keep expenses low, and illuminate
problematic sub-processes
Sample Analytics:
• Identify split POs with same vendor/ same
material / same creator, within X days
• Find duplicate POs with same vendor /
Same material / same quantity
• Identify goods received vouchers that are
30 days past PO approval date
PAGE 62Vendor ManagementEnsure that vendors are approved and have
been vetted for compliance against your
organisation’s vendor management take-on /
registration process
Sample Analytics:
• Matching of vendor and employee bank
accounts
• Vendors with the same bank accounts
• Vendors with similar names
PAGE 100Cash DisbursementsEnsure your cash disbursement controls
such as access, authorisation and
segregation of duties (SOD) are effective,
and that payments are made accurately
when due.
Sample Analytics:
• Review large vendors with large
disbursements in a specific time frame
• Duplicate cash disbursements
Version 6.2.0 – 2019/04
ContentsPage Analytic Name
5 Duplicate paymentsAP Analytic 01
7 Duplicate invoicesAP Analytic 02
9 Duplicate invoices using vendor’s numeric invoice valuesAP Analytic 03
11 Duplicate invoices sub analyticsAP Analytic 04
13 Future dated invoicesAP Analytic 05
15 Recurring sundry expense reviewAP Analytic 06
17 Invoices for one-time vendorsAP Analytic 07
19 Vendor payments made over a weekendAP Analytic 08
21 Invoices captured over a weekendAP Analytic 09
23 Invoices greater than a thresholdAP Analytic 10
25 Purchase order date after the invoice dateAP Analytic 11
27 Vendor paid by both purchase order and sundry expense AP Analytic 12
29 Invoices greater than approved purchase ordersAP Analytic 13
31 Manually released invoices (no 3-way match)
AP Analytic 14
Version 6.2.0 – 2019/04
ContentsPage Analytic Name
33 Three way match re-performanceAP Analytic 15
35 Outlier invoicesAP Analytic 16
37 Early payment of invoicesAP Analytic 17
Duplicate PaymentsAP_ANALYTIC_01_APCS102
Identifies all potential duplicate payments to the same vendor for the same amount made
within a configurable time period
ACCOUNTS PAYABLE
Essentials – Accounts Payable Page 5
ContextHigh volumes of payments from all areas of the business are processed through the Finance function every day or payment cycle. It is vital to closely and continuously monitor these payments to detect potential fraud or errors.
RiskA vendor is paid twice or more, often through administrative errors or fictitious vendor invoices being
submitted for payment with details similar to an original valid invoice. This may result in overpayment to
vendors or irrecoverable financial losses.
ProcedureIdentifies potential duplicate payments made to the same vendor for the same amount within a
configurable time period (e.g. 14 days, 30 days).
Analytic LogicExtracts payments within a user-determined period of days and identifies potential duplicate payments to
the same vendor (using system vendor ID) with the same value (using document/original currency), while
excluding reversed transactions.
VariablesPeriod (number of days) for payment analysis.
Duplicate Payments
Output Results Fields
Company Code Company Name Vendor ID Vendor Name 1 Vendor Name 2
Accounting Document Number Clearing Document Number
Item Description Debit / Credit Indicator Amount in Reporting Currency Report Currency
Output Visualization Example
Line Item Account Document Number
Document Currency Document Type Document Date
Clearing Date
Day Document Entered
Pay User ID
Pay User Name
Amount in Document Currency
Duplicate payments grouped by user
Essentials | Procure To Pay - Accounts Payable | AP_ANALYTIC_01_APCS102 Page 6
Example
VENDOR_ID VENDOR_NAME_1 ACCOUNTING_DOC_NUMBER DOCUMENT_DATE AMT_DOC_CURRE
NCY
100000523 ABC Inc 1500080094 1/11/2017 1000
100000523 ABC Inc 1500080841 15/11/2017 1000
100000479 XYZ Ltd 1500081862 2/11/2017 5000
Fields used for analytics logic
Exc
ep
tio
n
Duplicate InvoicesAP_ANALYTIC_02_APCS103
Identifies potential duplicate invoices after stripping out any special characters in the
invoice numbers
ACCOUNTS PAYABLE
Essentials – Accounts Payable Page 6
RiskThe same vendor invoice is presented twice for payment or fictitious/invalid vendor invoices are paid.
This may result in either overpayment or incorrect payment to vendors and often irrecoverable financial
losses from fraudulent and/or invalid invoices being paid.
ProcedureIdentifies duplicate paid invoices for the same amount after stripping out any special characters in the
invoice numbers.
Analytic LogicExtracts all paid invoices and removes/strips out special characters (e.g. ~!@#$%) from the invoice
number field (which is normally a free text field in the ERP system). Thereafter the script performs a
duplicates test using the stripped invoice number and invoice value fields.
Duplicate Invoices
Output Results Field Names
Company Code Company Name Vendor ID Vendor Name Vendor Invoice Number
Document Currency Amount in Document Currency
Accounting Document Number
Document Date
Release User
Release User Name
Output Visualization Example
ContextOften the same invoice is captured multiple times despite preventive system validation and controls being in place. Administrative errors or application control circumvention results in additional and/or changed characters to the invoice number, causing duplicate invoice capturing that would otherwise be undetectable.
Showing value over time
Essentials | Procure To Pay - Accounts Payable | AP_ANALYTIC_02_APCS103 Page 7
Vendor Stripped Invoice Number
Amount in Reporting CurrencyReport Currency
Example
Debit/Credit Indicator
VENDOR_NAME VENDOR_INV_NO STRIPPED_VENDOR_INV_NO DOCUMENT_DATE AMOUNT_DOC_CURRENCY
Vendor A IN001 IN001 1/11/2017 1000.00
Vendor A IN001$ IN001 15/11/2017 1000.00
Fields used for analytics logic
Duplicate Invoices Using
Vendor’s Numeric Invoice
ValuesAP_ANALYTIC_03_APCS601
Identifies potential duplicate invoices after converting invoice numbers to numeric values
ACCOUNTS PAYABLE
Essentials – Accounts Payable Page 8
RiskThe same vendor invoice is presented twice for payment or fictitious/invalid vendor invoices are paid.
This may result in either overpayment or incorrect payment to vendors and often irrecoverable financial
losses from fraudulent and/or invalid invoices being paid.
ProcedureIdentifies duplicate paid invoices for the same amount after converting the invoice numbers to numeric
values.
Analytic LogicExtracts all paid invoices and converts the invoice number from the invoice number field (which is
normally a free text field in the ERP system) to a numeric value (e.g. “INV101a” to “101”). Thereafter the
script performs a duplicates test using the numeric invoice number and invoice value fields.
Duplicate Invoices Using Vendor’s Numeric Invoice Values
Output Results Field Names
Company Code Company Name Vendor ID Vendor Name 1 Debit/Credit Indicator
Vendor Invoice Number Vendor Stripped Invoice Number Amount in Document CurrencyDocument Currency
Report Currency Amount in Reporting Currency Accounting Document Number Document Date
Output Visualization Example
ContextOften the same invoice is
captured multiple times despite
preventive system validation and
controls being in place.
Administrative errors or
application control circumvention
results in additional and/or
changed characters to the invoice
number, causing duplicate
invoice capturing that would
otherwise be undetectable.
Showing value over time
Essentials | Procure To Pay - Accounts Payable | AP_ANALYTIC_03_APCS601 Page 9
Release User Release User Name
Example
VENDOR_NAME VENDOR_INV_NO STRIPPED_VENDOR_INV_NO DOCUMENT_DATE AMOUNT_DOC_CURRENCY
Vendor A IN001 001 1/02/2017 4000.00
Vendor A INv001 001 15/02/2017 4000.00
Fields used for analytics logic
Duplicate Invoices Sub
AnalyticsAP_ANALYTIC_04_APCS613.1 TO AP_ANALYTIC_04_APCS613.10
Identifies potential duplicate invoices using various sub analytics
ACCOUNTS PAYABLE
Essentials – Accounts Payable Page 10
RiskThe same vendor invoice is presented twice for payment or fictitious/invalid vendor invoices are paid.
ProcedureIdentifies duplicate paid invoices by analysing for duplicates based on the ten variations in the table
below.
Analytic LogicExtracts all paid invoices and performs a duplicates test based on the ten variations in the table below,
for example identifying duplicate invoices where the vendor number and invoice number are the same.
Duplicate Invoices Sub Analytics
Output Results Field Names
Company Code Company Name Vendor ID Vendor Name 1 Debit/Credit Indicator
Vendor Invoice Number Amount in Document Currency
Document Currency
Accounting Document Number Document Date
ContextOften the same invoice is
captured multiple times despite
preventive system validation and
controls being in place.
Administrative errors or
application control circumvention
results in additional and/or
changed characters to the
invoice number, causing
duplicate invoice capturing that
would otherwise be undetectable.
Essentials | Procure To Pay - Accounts Payable | AP_ANALYTIC_04_APCS613.1 to AP_ANALYTIC_04_APCS613.10 Page 11
Duplicate Payment Sub-analytic Variations
Vendor Address Vendor Postal Code
Vendor Tax Number
Vendor RegionVendor City
Vendor Bank Account Number Vendor Bank Account Holders Name Analytic Description
@ - the duplicate analytic is run on these fields i.e. when these fields are the same.
Future Dated InvoicesAP_ANALYTIC_05_APCS341
Extracts all invoices with invoice dates in the future
ACCOUNTS PAYABLE
Essentials – Accounts Payable Page 12
RiskNon-payment of invoices due to incorrect invoice date capturing resulting in unnecessary interest or
penalties, or premature invoicing of services that have not been rendered, or potentially fictitious
invoices.
ProcedureExtracts all invoices with invoice dates in the future. The invoice date is manually inputted and not
system-generated. They are susceptible to human error during capturing and incorrect dates, including
dates in the future, may be captured.
Analytic LogicExtracts all invoices that have invoice dates in the future; for any date more than x days/ months after
the date the analytic is run will become an exception.
VariablesNumber of months.
Future Dated Invoices
Output Results Field Names
Company Code Company Name Vendor ID Vendor Name
Debit / Credit Indicator
Amount in Reporting Currency
Report Currency Amount in Document Currency
Accounting Document Number
Document Currency
Document Date
Vendor Invoice Number Vendor Stripped Invoice Number
Release User
Release User Name
Output Visualization Examples
ContextInvoices are expected to have a
date subsequent to the provision
of goods or services. Invoices
captured with dates far into the
future indicates either
administrative errors or
premature invoicing of services
not yet provided.
Analysis of dates per user
Count grouped by user
Essentials |Procure To Pay - Accounts Payable | AP_ANALYTIC_05_APCS341 Page 13
Recurring Sundry Expenses
ReviewAP_ANALYTIC_06_APCS108
Identifies all repetitive sundry invoices from the same vendor for the same amount
ACCOUNTS PAYABLE
Essentials – Accounts Payable Page 14
RiskUnauthorised invoices could be paid because less stringent procurement controls exist for sundry
expenses. This has the potential to result in unauthorised, invalid, excessive or potentially fraudulent
payments.
ProcedureIdentifies all repetitive sundry invoices to the same vendor for the same amount. These vendors should
be reviewed to understand why repetitive invoices are paid as sundry expenses, rather than through
procurement, when there is an evident continuing business relationship.
Analytic LogicExtracts and filters invoices for sundry expenses using a unique invoice identifier (defined in scoping),
and performs a duplicate analysis using the vendor ID and value to provide a listing of all multiple sundry
expenses.
Recurring Sundry Expenses Review
Output Results Field Names
Company Code Company Name Vendor ID Vendor Name Amount in Reporting Currency Report Currency
Amount in Document Currency Document Currency Document DateAccounting Document Number
Document Type Vendor Invoice Number Vendor Stripped Invoice Number Release User Released User Name
Output Visualization Example
ContextSundry expenses are incurred
on a once-off or ad hoc basis,
and don’t require a purchase
order. These expenses
require less processing and
attract less controls and are
not expected to be repetitive
and should be analysed
further to discover if they need
to follow the full procurement
processes and attract greater
controls.
Value over time by vendor
Essentials | Procure To Pay - Accounts Payable | AP_ANALYTIC_06_APCS108 Page 15
Example
VENDOR_NAME ACCOUNTING_DOC_NO DOC_CURRENCY DOCUMENT_DATE INV_AMOUNT_DOC_CURRENCY
Sundry Inc. 1900165432 USD 5/08/2017 21 000.00
Sundry Inc. 1900175489 USD 15/08/2017 15 000.00
Unique sundry invoice identifier
Invoices For One-time VendorsAP_ANALYTIC_07_APCS302
Extracts all invoices made to one-time vendors
ACCOUNTS PAYABLE
Essentials – Accounts Payable Page 16
RiskInvoices for one-time vendors could be invalid because the controls are less stringent. This may result in
unauthorized payment to vendors or irrecoverable financial losses from fraudulent/invalid invoices being
authorized and paid.
ProcedureExtracts all invoices made to one-time vendors classified as such on the vendor master file. Through
interpretations and visualizations, validation of one-time vendor invoices can proceed, raising
exceptions for further examination.
Analytic LogicExtracts all invoices from companies classified as one-time vendors in the ERP vendor master data, in a
given period.
Invoices For One-time Vendors
Output Results Field Names
Company Code Company Name Vendor ID Vendor Name Debit / Credit Indicator
Amount in Reporting Currency
Report Currency
Amount in Document Currency Accounting Document NumberDocument Currency
Document Date Vendor Invoice Number Vendor Stripped Invoice Number Release User Released User Name
Output Visualization Example
ContextVendors are created with an
expectation of a multi-transaction
relationship. Creation of a vendor
in the ERP system requires
supporting documentation and
vetting prior to transacting
(controls).
One-time vendors do not require
such stringent vendor creation
procedures. Abuse or overuse of
one-time vendors could represent
control circumvention and/or
fraud.
Data distribution of vendors for invoice value
Count by user
Essentials | Procure To Pay - Accounts Payable | AP_ANALYTIC_07_APCS302 Page 17
Vendor Payments Made Over
A WeekendAP_ANALYTIC_08_APCS112
Identifies where the payment release date falls on a weekend
ACCOUNTS PAYABLE
Essentials – Accounts Payable Page 18
RiskPotentially invalid or fraudulent vendor transactions which may result in overpayment to vendors or often
irrecoverable financial losses.
ProcedureIdentifies where the payment release date falls on a weekend. Release dates are utilized as this is the
point of authorization and are expected to take place during normal business hours; occurrence on a
weekend could indicate unusual or unauthorized transactions.
Analytic LogicAnalyses all payment release dates in the system and indicates if this date falls on a Saturday or
Sunday whereby it will be listed as an exception.
Vendor Payments Made Over A Weekend
Output Results Field Names
Company Code Company Name Vendor ID Vendor Name Accounting Document Number Day of Week
Document Date Debit / Credit IndicatorClearing Date
Report Currency Amount in Document Currency Document Currency Pay User ID Pay User Name
Output Visualization Examples
Amount in Reporting Currency
ContextVendor payments, being a
standard and regular
organizational process, are
expected to be executed during
normal business hours.
Payments over weekends may
indicate fraudulent or suspicious
activity and should be reviewed
for such.
Weekend values group by user
Percentage values per vendor
Essentials | Procure To Pay - Accounts Payable | AP_ANALYTIC_08_APCS112 Page 19
Vendor Invoice Number
Invoices Captured Over A
WeekendAP_ANALYTIC_09_APCS301
Identifies where invoices were captured over a weekend
ACCOUNTS PAYABLE
Essentials – Accounts Payable Page 20
RiskPotentially invalid or fraudulent vendor transactions which may result in overpayment to vendors or often
irrecoverable financial losses.
ProcedureIdentifies where invoices were captured over a weekend. All invoices captured in the ERP system will
have an automatic entry/capture date attached which cannot be amended. The invoice date (as printed
on an invoice by a supplier) is not the date used for this analytic.
Analytic LogicExtracts where the entry/capture date of invoices fall on a Saturday or Sunday whereby it will be listed
as an exception.
Invoices Captured Over A Weekend
Output Results Field Names
Company Code Company Name Vendor ID Vendor Name Debit / Credit Indicator
Amount in Reporting Currency
Report Currency
Amount in Document Currency Accounting Document NumberDocument Currency
Document Date Vendor Invoice Number Vendor Stripped Invoice Number Release User
Released User Name
Output Visualization Examples
ContextInvoice capturing, being a
standard and regular
organizational process, is
expected to be executed during
normal business hours.
Capturing over weekends may
indicate fraudulent/suspicious
activity and should be reviewed
for such.
Heatmap showing the user and
quantity
Values grouped by vendor
Essentials | Procure To Pay - Accounts Payable | AP_ANALYTIC_09_APCS301 Page 21
Day of Week
Date Document Entered
Invoice Greater Than A
ThresholdAP_ANALYTIC_10_APCS110
Produces a list of invoices paid above a configurable threshold to
determine authorization process for testing
ACCOUNTS PAYABLE
Essentials – Accounts Payable Page 22
RiskInappropriately reviewed and authorized transactions which could be caused by a lack of, or outdated,
level of authority.
ProcedureProduces a listing of invoices paid above a configurable minimum and maximum threshold (financial
value) to determine authorization process for testing. These transactions should be tested for accuracy,
validity and approval.
Analytic LogicExtracts invoices greater than the client-configured thresholds to create a listing for level of authority
testing by audit, for example, all invoices greater than $2 500 and up to $5 000.
VariablesMinimum and maximum threshold value (for selecting invoices).
Invoice Greater Than A Threshold
Output Results Field Names
Company Code Company Name Vendor ID Debit / Credit Indicator
Release User
Amount in Reporting Currency
Report Currency Amount in Document Currency Document Currency Accounting Document Number
Document Date Vendor Invoice Number Vendor Stripped Invoice Number
Output Visualization Examples
Release User Name
ContextAll vendor invoices should be
approved in terms of the correct
level of authority for the
organization. Differing levels of
authority are required for
purchases or invoices above
certain levels; more senior people
in the organization approve
higher value and materially
significant transactions.
Value of transactions by vendor
and releaser
Quantity and value of transactions by
vendor
Essentials | Procure To Pay - Accounts Payable | AP_ANALYTIC_10_APCS110 Page23
Invoice DateAP_ANALYTIC_11_APCS111
Identifies where the invoice date precedes the purchase order approval date
ACCOUNTS PAYABLE
Essentials – Accounts Payable Page 24
RiskIneffective procurement due to finance and procurement procedures not being followed which may
result in the payment of invalid or unapproved purchases.
ProcedureIdentifies where the invoice date precedes the purchase order approval date.
Analytic LogicExtracts invoices and related purchase orders where the invoice date is before the purchase order
approval date.
Purchase Order Date After The Invoice
Date
Output Results Field Names
Company Code Company Name Vendor ID Vendor Name Vendor Invoice Number
Accounting Document Number Document Type Purchase Order Creation DateDocument Date
Purchase Order Number Purchase Order User Name Purchase Order User ID Amount in Reporting Currency
Output Visualization Examples
Days Difference
Report Currency Amount in Document Currency Incl VAT Document Currency
ContextBest practice procurement
procedures dictate that purchase
order approvals should precede
an invoice. Any purchase orders
approved after an invoice should
be reviewed and examined to
understand the reasons and if
there was a control breakdown.
Date and materiality comparison
Days difference analysis by vendor
Essentials | Procure To Pay - Accounts Payable | AP_ANALYTIC_11_APCS111 Page 25
Vendor Paid By Both Purchase
Order And Sundry ExpenseAP_ANALYTIC_12_APCS109
Identifies the most recent instances where vendor invoices are paid by both a purchase
order and by a sundry expense
ACCOUNTS PAYABLE
Essentials – Accounts Payable Page 26
RiskUnauthorised invoices outside the scope defined in the purchase order could be paid because less
stringent procurement controls exist for sundry expenses. This may result in unauthorized, invalid,
excessive or potentially fraudulent payments.
ProcedureIdentifies the most recent instances where vendor invoices are paid by both a purchase order and by a
sundry expense. These vendors should be reviewed to understand why they are being paid as both a
procurement and sundry expense when it is expected all transactions should be in line with a purchase
order for a repetitive vendor.
Analytic LogicSummarizes vendors' invoices to extract the latest transactions where vendor invoices were processed
through both a sundry expense and a purchase order.
Vendor Paid By Both Purchase Order & Sundry Expense
Output Results Field Names
Company Code Company Name Vendor ID Vendor Name Debit / Credit Indicator
Amount in Reporting Currency
Report Currency
Amount in Document Currency Accounting Document NumberDocument Currency
Document Date Vendor Invoice Number Vendor Stripped Invoice Number Release User
Released User Name
Output Visualization Example
ContextVendor payments are expected to
be as a result of a transaction in
either the procurement system
(via purchase order) or a sundry
expense. A vendor should be
processed through either process
but not both. Sundry expenses
require less processing and
attract less controls.
Count of transactions by
vendor
Essentials | Procure To Pay - Accounts Payable | AP_ANALYTIC_12_APCS109 Page 27
Example
Document Type
VENDOR_NAME ACCOUNTING_DOC_NO STRIPPED_INV_NO DOCUMENT_DATE AMOUNT_DOC_CURRENCY
ABC Inc. 1899786258 INV00234 01/02/2017 21 000.00
ABC Inc. 5100196587 INV00245 15/02/2017 15 000.00
Different document numbers indicate PO
and sundry
Invoices Greater Than
Approved Purchase OrdersAP_ANALYTIC_13_APCS106
Extracts all invoices exceeding the value of the related approved purchase orders
ACCOUNTS PAYABLE
Essentials – Accounts Payable Page 28
RiskInvoices exceeding purchase orders could be caused by unauthorised changes to the initially agreed
upon services or goods. This may result in unauthorised spending, overspending or potentially fraudulent
spending.
ProcedureExtracts all invoices exceeding the value of the related approved purchase order from a configurable
threshold value and above.
Analytic LogicExtracts and compares the value on the invoice to the total value of the approved purchase order and
identifies instances where invoice value exceed the purchase order by the configurable threshold value,
for example invoices greater than a purchase order from $50 and above.
In some countries, the effect of VAT or Sales tax can be removed from the invoice or added to the
purchase order value before comparison is done.
VariableMinimum acceptable variance.
Invoices Greater Than Approved Purchase Orders
Output Results Field Names
Company Code Company Name Vendor ID Vendor Name Purchase Order Amount in Document Currency
Invoice Amount in Document Currency Excl VAT Invoice Amount in Document Currency Document Currency
Purchase Order Number Purchase Order Creation Date Purchase Order User ID
Purchase Order User Name
Output Visualization Example
Invoice Number
ContextA vendor invoice should not
typically exceed the value
approved in the purchase order
as the underlying procurement
process has vetted the vendor at
a predetermined price.
Showing quantity grouped by the user
Page 29
Example
Difference
VENDOR_NAME PO_NUMBERPO_TOTAL_AMT_INCL_VAT_DOC
_CURR
INV_AMOUNT_DOC_CURRENC
YDIFFERENCE
Fake Corp 5105634213 7 650.00 8 250.00 (600.00)
Real Industries 5105768923 45 000.00 50 000.00 (5000.00)
Believe Ltd 5105891342 213 500. 00 220 000.00 (6 500.00)
Essentials | Procure To Pay - Accounts Payable | AP_ANALYTIC_13_APCS106 Page 29
Manually Released Invoices
(No 3-way Match)AP_ANALYTIC_14_APCS101
Identifies manually paid invoices where the three way match with the purchase order and
goods received note did not result in an automatically released payment, or where the
payment was manually released
ACCOUNTS PAYABLE
Essentials – Accounts Payable Page 30
Essentials | Procure To Pay - Accounts Payable | AP_ANALYTIC_14_APCS101
ContextA three-way-match is performed
between a purchase order, goods
received note and invoice to
ensure details are correct before
making payment to the vendor. A
payment should not be
automatically made unless this
match is performed and
reconciliation achieved.
RiskFictitious, invalid or incorrect payments are caused by a user manually releasing a payment to a vendor
and not relying on the automatic payment from a successful three-way-match.
ProcedureIdentifies manually released invoices (paid and unpaid) where a three-way-match, between the invoice,
purchase order and goods received note did not occur.
Analytic LogicExtracts all invoices and highlights transactions without correct three-way-match which have been
manually released for payment (either before or after payment).
Manually Released Invoice (No 3 Way Match)
Output Results Field Names
Company Code Company Name Vendor ID Vendor Name Amount in Reporting Currency Report Currency
Amount in Document Currency Document Currency Accounting Document NumberDocument Date
Vendor Invoice Number Vendor Stripped Invoice Number PO Number Release User Released User Name
Output Visualization Example
Three-way-match violations, grouped
by releasing user
Example
VENDOR_NAME PO_NUMBER INV_AMOUNT_DOC_CURRENCY RELEASE_USER RELEASE_USER_NAME
ABC Inc. 5105634256 250.00 JSOAP Joe Soap
DEF Ltd 5105768925 100.00 ADOE Anne Doe
JHI Corp 5105891356 2 500.00 KSMART Ken Smart
Released by users indicate that not automatically released
Page 31
Three-way-match
Re-performanceAP_ANALYTIC_15_APCS602
Re-performs the three way match using purchase order and invoice amounts and
purchase order, goods received and invoice quantities
ACCOUNTS PAYABLE
Essentials – Accounts Payable Page 32
Essentials | Procure To Pay - Accounts Payable | AP_ANALYTIC_15_APCS602
ContextA three-way-match is performed
between a purchase order,
goods received note and invoice
to ensure details are correct
before making payment to the
vendor. A payment should not be
made unless this match is
performed and reconciliation
achieved.
RiskFictitious, invalid or incorrect payments made on transactions not correctly matched.
ProcedureIdentifies invoices (paid and unpaid) where the invoice amount and purchase order amount differ as
well as where a three-way-match, between the invoice, purchase order and goods received note
quantities did not occur.
Analytic LogicExtracts all invoices and highlights transactions without correct three-way-match between purchase
order, good received note and invoice quantities and invoice and purchase order amounts.
Three-way-match Re-performance
Output Results Field Names
Company Code Company Name Vendor ID Vendor Name Amount in Reporting Currency
Report Currency
Invoice Amount in Document Currency Excl VAT
Purchase Order Amount In Document Currency Excl VAT
Document Currency
DifferenceInvoice Quantity Good Received Quantity
PO Number
Purchase Order Creation Date
Output Visualization Examples
Total amount differences between invoice amounts and purchase order amounts
Page 33
Amount in Document Currency Incl VAT
Purchase Order Quantity
GR Document Number Invoice Number
PO Line Number
Reason for Exception
Outlier InvoicesAP_ANALYTIC_16_APCS611
Identify invoice amounts greater than x standard deviations from the median amount of
that vendor
ACCOUNTS PAYABLE
Essentials – Accounts Payable Page 34
Essentials | Procure To Pay - Accounts Payable | AP_ANALYTIC_16_APCS611
ContextAn outlier is an observation point
that is distant from other
observations. Transactions
outside the norm with vendors
are generally not expected, but
could go unnoticed if high
volumes of transactions are
processed.
RiskFictitious, invalid or incorrect payments made to vendors.
ProcedureIdentifies outlier invoices by using standard deviations to determine amounts that deviate significantly
from the expected amounts posted to a vendor.
Analytic LogicExtracts all invoice amounts greater than a configurable number of standard deviations from the median
amount for that vendor.
VariableNumber of standard deviations.
Outlier Invoices
Output Results Field Names – Summary by Vendor
Company Code Company Name Vendor ID Vendor Name Invoice Count
Maximum Invoice Number
Number of invoices with same max value
Number of invoices with same min value
Minimum Invoice Number
Maximum Invoice Date
Average Invoice AmountMinimum Amount
Invoice Amount in Document Currency Total
Standard Deviation
Page 35
Maximum Amount
Minimum Invoice Date
Output Results Field Names – Outliers
Company Code Company Name Vendor ID Vendor Name Document Date Item Text
Invoice Amount in Document Currency Vendor Stripped Invoice Number
Early Payment of InvoicesAP_ANALYTIC_17_APCS612
Identify invoices that were paid after the discount dictated in the payment terms and
calculate the value of those missed discounts
ACCOUNTS PAYABLE
Essentials – Accounts Payable Page 36
Essentials | Procure To Pay - Accounts Payable | AP_ANALYTIC_17_APCS612
ContextMany suppliers offer discounts in
order to encourage early
settlement of their invoices.
Taking advantage of these
discounts presents an opportunity
to improve cash flow.
RiskOpportunity cost arising from missing out on the discount.
ProcedureIdentifies invoices that were paid after the discount dictated in the payment terms and calculate the lost
opportunity of missing out on that discount.
Analytic LogicExtracts all invoices that were paid after the discount as per the payment terms and calculates the
discount that could have been claimed had the invoice been paid within the discount payment terms.
Early Payment Of Invoices
Output Results Field Names
Company Code Company Name Vendor ID Vendor Name Debit/ Credit Indicator
Report Currency
Amount in Document Currency
Accounting Document Number
Document CurrencyVendor Stripped Invoice Number
Vendor Invoice Number
Invoice Amount Reporting Currency
Payment Terms Code
Output Visualization Examples
Page 37
Document Date
No Days Lapsed Days Overlapped
Amount Eligible for cash discount in Document Currency
Cash Discount Amount
Released User Released User NamePayment Terms Description
Cash discounts missed by vendor
ContentsPage Analytic Name
40 Split purchase ordersPO Analytic 01
42 Duplicate purchase ordersPO Analytic 02
44 Purchase orders created and approved by the same userPO Analytic 03
46 Goods received voucher before purchase order datePO Analytic 04
48 Goods received voucher is 30 days past the purchase orders approval datePO Analytic 05
50 Price differences between purchase order items with the same vendorPO Analytic 06
52 Same user created the purchase order and receipted the goods received voucherPO Analytic 07
54 Purchase orders report by monthPO Analytic 08
56 Split purchase requisitionsPO Analytic 09
58 Compare purchase orders to purchase requisitionsPO Analytic 10
60Purchase orders with no purchase requisitionsPO Analytic 11
Version 6.2.0 – 2019/04
Split Purchase OrdersPO_ANALYTIC_01_PMCS101
Identifies split purchase orders where the same material was ordered from the same
vendor by the same creator within a configurable number of days
ACCOUNTS PAYABLE
Page 40Essentials – Purchase Order Management
Essentials | Procure to pay - Purchase Order Management | PO_ANALYTIC_01_PMCS101
ContextIdentifies possible incorrect or
fictitious purchase
transactions that should be
investigated. Additionally, less
stringent approvals are
applied to lower value
purchase orders.
RiskIncorrect or fraudulent purchase transactions resulting in a possible financial loss.
ProcedureIdentifies split purchase orders where the same material was ordered from the same vendor
by the same creator within a configurable number of days.
Note: In some businesses, separate purchase orders are created for delivery of the same
materials to different locations. These orders may look like split purchase orders.
Analytic LogicExtracts all approved purchased orders for the period under review to determine potential split
purchase orders where the order is for the same vendor for the same material by the same
creator within a determinable number of days of each order. The quantity may differ between
orders.
VariablesNumber of days.
Split Purchase Orders
Output Results Field Names
Output Visualization Examples
Page 41
Net price by description
for a vendor
Grouping PO Number PO Line Number Line Description Quantity Date
Group 1 23586 01 Steel sheet 2 21/03/2018
Group 1 23587 01 Steel sheet 3 24/03/2018
Group 1 23589 01 Steel sheet 5 25/03/2018
Example
PO Vendor ID Vendor Name
PO Creator
Material Line DescriptionMaterial Number
PO Creator Name
PO Document Date PO Number
PO Line Net Price PO Line Net Price CurrencyPO Line Quantity
PO Line Number
Company Code Company Name Plant code for PO Line Plant name for PO
Results Grouping
Duplicate Purchase OrdersPO_ANALYTIC_02_PMCS102
Identifies duplicate purchase orders where the same quantity of material was ordered from
the same vendor within a configurable number of days
ACCOUNTS PAYABLE
Page 42Essentials – Purchase Order Management
ContextIdentifying possible incorrect
or fraudulent orders placed.
RiskIncorrect or fraudulent purchase transactions resulting in a possible financial loss.
ProcedureIdentifies duplicate purchase orders where the same quantity of material was ordered from the
same vendor within a configurable number of days.
Note: In some cases purchase orders may be the same but are for staggered delivery dates
and are intended to be raised as such.
Analytic LogicExtracts all approved purchase orders for the period under review to determine potential
duplicate purchase orders where the order is for the same vendor for the same material and the
same quantity within a determinable number of days of each order. The orders can be created
by different users.
VariablesNumber of days.
Duplicate Purchase Orders
Output Results Fields
Output Visualization Example
Essentials |Procure To Pay - Purchase Order Management | PO_ANALYTIC_02_PMCS102 Page 43
Company Code Company Name Plant code for PO Line Plant name for PO PO Vendor ID Vendor Name
PO Document Date PO Number
PO Line Net Price PO Line Net Price Currency PO CreatorPO Line Quantity
PO Material DescriptionMaterial NumberPO Line Number
PO Creator Name
Bar chart analysis by PO
amount, material number
and user
Example
Results Grouping
Grouping PO Number Po Line Number Line Description Quantity Date
Group 1 24621 01 Hard drives 2 21/03/2018
Group 1 24985 01 Hard drives 2 24/03/2018
Group 1 24257 01 Hard drives 2 25/03/2018
Fields used for analytics logic
Purchase Orders Created And
Approved By The Same UserPO_ANALYTIC_03_PMCS103
Identifies where the same user created and approved the purchase order
ACCOUNTS PAYABLE
Page 44Essentials – Purchase Order Management
RiskIncorrect or fraudulent purchase transactions resulting in a possible financial loss.
ProcedureIdentifies where the same user created and approved the purchase order.
Analytic LogicExtracts the creator and approver of all purchases orders to detect where the creator is the
same as the approver of the purchase order.
Purchase Orders Created And Approved By The Same User
Output Results Field Names
Output Visualization Example
ContextGood business practice
requires adequate
segregation of duties
between the creation and
approval of purchase orders
to ensure accuracy and
validity of purchase orders.
Essentials | Procure To Pay - Purchase Order Management | PO_ANALYTIC_03_PMCS103 Page 45
Company Code Company Name Plant code for PO Line Plant name for PO Approved PO Number
PO Line Number PO Creator PO Creator Name
PO Document Date PO Line Description PO Product NumberVendor NamePO Vendor ID
PO Approver NamePO Approver ID
PO Line QuantityPO Line Net Order Value
Total amount of exceptions by
vendor
Example
PO Number PO Approver ID PO Approver Name PO Creator ID PO Creator Name
23586 1234 Joe Soap 1234 Joe Soap
23587 2562 Jane Doe 2562 Jane Doe
23589 1485 Mark Smith 1485 Mark Smith
Fields used for analytics logic
Goods Received Voucher
Before Purchase Order DatePO_ANALYTIC_04_PMCS104
Identifies where the goods received voucher is before purchase order date
ACCOUNTS PAYABLE
Page 46Essentials – Purchase Order Management
.
Goods Received Voucher Before Purchase Order Date
Output Results Field Names
Output Visualization Example
ContextGoods should be ordered and
received only after the
purchase order is created and
approved. Instances where
the receipt date of goods is
before the date the purchase
order is created should be
investigated to determine the
validity and accuracy of the
transaction.
PAGE 10
RiskIncorrect or fraudulent purchase transactions resulting in a possible financial loss.
ProcedureIdentifies where the goods received voucher is before purchase order date.
Note: In some businesses there is a need for emergency or last minute purchases that are
necessary to keep operations running. In these cases, a purchase order may be raised after
the services or goods are received.
Analytic LogicExtracts the date of the goods receipt and the approval date of the purchase order and
compare where goods were received before the PO.
Company Code Company Name Goods Received Plant Goods Received Plant Name
Goods Received Document Number Goods Received Reference Document Number Goods Received Quantity
Goods Received Creator Name
PO Line Number PO Vendor ID Vendor NamePO NumberPO Document Date
Goods Received Posting DateGoods Received Document Date
Product Code
PO Description PO Quantity PO Line Net Price PO Price Currency PO Creator
PO Creator NameDays Difference Between PO Date and GR Date
Exceptions by days difference, GR
posting and vendor name
Example
GR Doc Number GR Doc Date PO Number PO Doc Date Day Diff PO GR
15875 27/12/2016 23685 04/01/2017 8
16958 02/03/2017 24697 14/03/2017 12
17542 19/05/2017 25894 29/05/2017 10
Fields used for analytics logic
Essentials | Procure To Pay - Purchase Order Management | PO_ANALYTIC_04_PMCS104 Page 47
PAGE 11
Goods Received Voucher Is 30
Days Past The Purchase Order
Approval DatePO_ANALYTIC_05_PMCS105
Identifies where the goods received voucher is 30 days past the purchase order approval date
Essentials – Purchase Order Management Page 48
RiskPossible delay in service delivery experienced.
ProcedureIdentifies where the goods received voucher is 30 days past the purchase order approval date.
Note: Goods that are imported or known to take a long time to deliver based on the vendor or
nature of stock may result in false positives for this analytic.
Analytic LogicExtracts the date of goods receipts that is more than 30 days after the approval date of the
purchase order.
Goods Received Voucher Is 30 Days Past The
Purchase Order Approval Date
Output Results Field Names
Output Visualization Example
ContextTurnaround time between
ordering goods and receiving
goods should be kept to a
minimum. Instances where
order and receipt of goods
are 30 days and more apart
should be investigated.
PAGE 12
Company Code Company Name Goods Received Plant Goods Received Plant Name
GRN Number GRN Reference Document Number Goods Received Quantity GRN Date
PO Number PO Line Number
PO Vendor ID
PO Approval NumberGRN Creator NameGRN Creator
GRN Posting Date
Vendor NamePO Line Material Number PO Line Description PO Line Net Order Value
PO Creator PO Creator Name Days Difference Between PO Date and GRN Date
Bar chart of exceptions by number of days, GR
posting date and vendor
Example
GR Doc Number GR Doc Date PO Number PO Approval Date Day Diff PO GR
15875 01/06/2017 23685 27/04/2017 35
16958 03/07/2017 24697 28/05/2017 40
17542 24/08/2017 25894 15/07/2017 40
Fields used for analytics logicThis date is 30 days or more past the PO
approval date
Essentials | Procure To Pay - Purchase Order Management | PO_ANALYTIC_05_PMCS105 Page 49
PAGE 13Essentials – Purchase Order Management
Price Differences Between
Purchase Order Items With The
Same VendorPO_ANALYTIC_06_PMCS107
Identifies price differences between purchase order items with the same vendor
Page 50
RiskDecreased profit margins due to incorrect capturing or ineffective supplier management.
ProcedureIdentifies price differences between purchase order items with the same vendor.
Note: If this analytic is run for a period that is a relatively long cycle for a business, differences
may occur because of inflation or expected price increases. The period for analysis is key to
obtaining relevant results. For example, if this analytic is run for a month, it is not expected
that there would be material differences.
Analytic LogicExtracts the materials purchased from the same vendor and compares the per unit price (per
the stock system) between orders for the period under review to identify where prices are
different for the same material between orders.
Price Differences Between Purchase Order
Items With The Same Vendor
Output Results Field Names
Output Visualization Example
ContextPrice differences with the
same vendor should be
investigated as this could be a
result of incorrect capturing. It
could also be used to manage
supplier performance and
service delivery.
PAGE 14
Company Code Company Name PO Plant Code PO Plant Name PO Vendor ID Vendor Name
PO Document Date PO Number
PO Line Net Price PO Line Net Price Currency PO CreatorPO Line Quantity
PO Line DescriptionPO Line Material NumberPO Line Number
PO Creator Name
Total amount of exceptions by
creator
Example
Vendor Name PO Material NO PO Doc Date PO Line Text PO Line Net Price
Abc Supplies 2001254 06/01/2017 Red pens 1.5
Abc Supplies 2001254 12/02/2017 Red pens 8.5
Abc Supplies 2001254 07/04/2017 Red pens 4.0
Fields used for analytics logic
Price differs for
same item
Essentials | Procure To Pay - Purchase Order Management | PO_ANALYTIC_06_PMCS107 Page 51
PAGE 15Essentials – Purchase Order Management Page 52
Same User Created The
Purchase Order And Receipted
The Goods Received VoucherPO_ANALYTIC_07_PMCS108
Identifies where the same user created the purchase order and receipted the goods received
voucher
RiskIncorrect or fraudulent purchase transactions resulting in a possible financial loss.
ProcedureIdentifies where the same user created the purchase order and receipted the goods received
voucher.
Analytic LogicExtracts the user ID of the creator of a purchase order and the user ID of who receipted the
goods and extracts records where it is the same user ID.
Same User Created The Purchase Order
And Receipted The Goods Received Voucher
Output Results Field Names
Output Visualization Example
ContextGood business practice
requires adequate
segregation of duties between
the person creating the
purchase order and the
person receiving goods
ordered to ensure accuracy
and validity of the purchase
transaction.
PAGE 16
Company Code Company Name Goods Received Plant PO Plant Name Goods Received Plant Name
GRN Document Number GRN Reference Document Number Goods Received Quantity
PO Creator PO Creator Name
PO Document Date
Goods Received Creator NameGoods Received CreatorGRN Posting Date
GRN Document Date
PO Number
PO Line Material Number
PO Line Description
PO Vendor IDPO Line Number
PO Line Quantity
Vendor Name
PO Line Net Price CurrencyPO Line Net Price
Total amount of exceptions
by creator
Example
PO Number PO Creator ID PO Creator Name GR Creator ID GR Creator Name
23586 1245 Sarah Jane 1245 Sarah Jane
23587 2595 Jennifer Roberts 2595 Jennifer Roberts
23589 1467 Tom Harris 1467 Tom Harris
Fields used for analytics logic
Essentials | Procure To Pay - Purchase Order Management | PO_ANALYTIC_07_PMCS108 Page 53
PAGE 17Essentials – Purchase Order Management Page 54
Purchase Orders Report By
MonthPO_ANALYTIC_08_PMCS301
Report of purchase orders per item per month
RiskIneffective planning and performance management.
ProcedureReport of purchase orders per item per month.
Analytic LogicExtracts orders of materials from underlying purchase orders and present the data by month
and by material.
Purchase Orders Report By Month
Output Results Field Names
Output Visualization Examples
ContextManagement information
used to analyze performance
and identify variations from
expected/budgeted
performance. Deviations
should be investigated and
results used as input for future
planning.
Company Code PO Line Material Number PO Material Description PO Line Quantity by Month
Total amount of PO line quantity
by material number and
description
Total quantity by material
Summary table of PO quantity
by material and month
Essentials | Procure To Pay - Purchase Order Management | PO_ANALYTIC_08_PMCS301 Page 55
PAGE 19Essentials – Purchase Order Management Page 56
Split Purchase RequisitionsPO_ANALYTIC_09_PMCS611
Identifies split purchase requisitions where the same material is requested by the same
creator within a configurable number of days
ContextIdentifies possible incorrect or
fictitious purchase
transactions that should be
investigated.
RiskIncorrect or fraudulent purchase transactions resulting in a possible financial loss.
ProcedureIdentifies split purchase requisitions where the same material is requested by the same
creator within a configurable number of days.
Analytic LogicExtracts all approved purchased requisitions for the period under review to determine
potential split purchase requisitions where the requisition is for the same material by the same
creator within a determinable number of days of each requisition. The quantity may differ
between requisitions.
VariablesNumber of days.
Split Purchase Requisitions
Output Results Field Names
Recommended Vendor ID
Output Visualization Example
Material Unit PriceMaterial Quantity
Material Item NumberPR Line Item Number
Material items which are split
in requisitions
Company Code Company Name
Purchase Requisition Number
Example
Results Grouping
Purchase Requisition Plant Code
Purchase Requisition Approver Name
Purchase Requisition Date
Unit of Measure
Purchase Requisition Plant Name
Recommended Vendor Name Requisitioner User ID
Material Description
Grouping PR Number PR Line Number Line Description Quantity Date
Group 1 78569 01 Exam pads 2 21/04/2018
Group 1 78575 01 Exam pads 3 24/04/2018
Group 1 78582 01 Exam pads 6 25/04/2018
Fields used for analytics logic
Essentials | Procure To Pay - Purchase Order Management | PO_ANALYTIC_09_PMCS611 Page 57
PAGE 21Essentials – Purchase Order Management Page 58
Compare Purchase Orders To
Purchase RequisitionsPO_ANALYTIC_10_PMCS612
Identifies any purchase orders where there are differences between the purchase order and
purchase requisition quantities and items
ContextOrders that are placed by
procurement should be based
on the item and quantities
requested by end users from
the purchase requisition
submitted.
RiskIncorrect items or quantities ordered resulting in possible over stocking.
ProcedureIdentifies where there are differences between the purchase order and purchase requisition
material item and quantity.
Analytic LogicExtracts all purchase order and purchase requisition information where the purchase
requisition material item description and quantity differs from the purchase order material item
and description.
Compare Purchase Orders To Purchase Requisitions
Output Results Field Names
PO Vendor ID Vendor Name
Output Visualization Example
PAGE 22
PO Document Date PO Number
Purchase Requisition Material Quantity Difference
PO Line QuantityPO Material DescriptionPO Material Number
Differences between
total purchase orders
and purchase
requisitions
Company Code Company Name
Example
Purchase Requisition Number
Purchase Requisition Date PO Creator Name
Purchase Requisition Approver Name
PO Number PO Line Description PO Qty PR Number PR Line Description PR Qty
25698 Red pens 10 17854 Red pens 8
25369 Exam pads 20 17853 Exam pads 12
25487 Post It Flags 5 17652 Post It Flags 2
Fields used for analytics logic
Essentials | Procure To Pay - Purchase Order Management | PO_ANALYTIC_10_PMCS612 Page 59
PAGE 23Essentials – Purchase Order Management Page 60
Purchase Orders With No
Purchase RequisitionsPO_ANALYTIC_11_PMCS613
Identifies those purchase orders that have been created without a purchase requisition
ContextBefore a purchase order for a
particular item can be
generated, the need for the
item needs to be
communicated to the
procurement department.
This is generally done by
means of a purchase
requisition.
RiskIncorrect items or quantities ordered resulting in possible over stocking.
ProcedureIdentifies any purchase orders that have been created without having a purchase requisition
that initiated the order.
Analytic LogicExtracts all purchase order information where there is no purchase requisition linked to that
purchase order.
Purchase Orders With No Purchase Requisitions
Output Results Field Names
PO Vendor ID Vendor Name
Output Visualization Examples
PAGE 22
PO Document Date PO Number
PO Material Description PO Line Net PricePO Line QuantityPO Line Material NumberPO Line Number
Purchase orders by vendor with no purchase requisitions
Company Code Company Name
PO Line Net Price Currency PO CreatorPO Creator Name
Essentials | Procure To Pay - Purchase Order Management | PO_ANALYTIC_11_PMCS613 Page 61
ContentsPage Analytic Name
64 Vendors with similar namesVM Analytic 01
66 Vendors with the same addressVM Analytic 02
68 Vendors with the same phone numbersVM Analytic 03
70 Vendors with the same bank accountsVM Analytic 04
72 Vendors with the same Sales Tax registration numbersVM Analytic 05
74 Vendors with the same business numberVM Analytic 06
76 Frequently changed vendor bank account detailsVM Analytic 07
78 Matching of vendor and employee namesVM Analytic 08
80 Matching of vendor and employee physical addressVM Analytic 09
82 Matching of vendor and employee primary phone numbersVM Analytic 10
84 Matching of vendor and employee bank accountsVM Analytic 11
86 Vendors with the no business numberVM Analytic 12
88 Vendors with the no Sales Tax registration numbersVM Analytic 13
90 Blank critical data: Telephone numbersVM Analytic 14
92 Blank critical data: Bank detailsVM Analytic 15
94 Vendors with only postal box addressesVM Analytic 16
Version 6.2.0 –2019/04
ContentsPage Analytic Name
Vendors with a single posterVM Analytic 17
Vendor hit matrixVM HIT MATRIX
Version 6.2.0 –2019/04
Vendors With Similar NamesVM_ANALYTIC_01_VMCS101
Identifies vendors with similar names
ACCOUNTS PAYABLE
Essentials – Vendor Management Page 64
Essentials |Procure To Pay - Vendor Management | VM_ANALYTIC_01_VMCS101
ContextVendor data should be
accurate to enable correct
processing and accurate
reporting. Identifying duplicate
vendors prevents possible
incorrect/duplicate and/or
fraudulent vendor
transactions/payments.
RiskPossible fictitious/incorrect vendor accounts created, resulting in fraudulent/incorrect vendor
transactions and payments.
ProcedureIdentifies vendors with similar names using the cleaned vendor names (i.e. removing
company suffixes). The results of this analytic are presented in groups of similarly named or
duplicate vendors.
Note: In an ERP system with various units/branches, plants and/or cost codes, a single
vendor often needs to be created and managed per location and these multiple vendors can
come through as false positives.
Analytic LogicExecutes the Fuzzy Duplicates ACL Function which analyses cleaned vendor names to
assess their similarity and group vendor names that are similar.
Vendors With Similar Names
Output Results Field Names
Company Code Company Name Group Full Vendor Name Vendor Number
Marked for Deletion
Output Visualization Examples
Page 65
Heatmap of vendors with
similar names
Count of exceptions of
vendors with similar
names
Stripped Vendor Name Last Invoice Number
Last Invoice Amount in Document Currency
Last Transaction Date
Last Invoice Document Currency
Vendors With The Same
AddressVM_ANALYTIC_02_VMCS103
Identifies vendors with the same address
ACCOUNTS PAYABLE
Essentials – Vendor Management Page 66
RiskPossible fictitious/incorrect vendor accounts created, resulting in fraudulent/incorrect vendor
transactions and payments.
ProcedureIdentifies vendors with the same address. Note: If a company is part of a group of companies,
they can operate out of a single location and all companies in the group will have the same
registered address causing some false positive results. In a system with various branches,
plants and/or cost codes, a single vendor often needs to be created and managed per location
and these multiple vendors can come through as false positives.
Analytic LogicCompares the physical address of vendors in the vendor master file.
Vendors With The Same Address
Output Results Field Names
Company Code Company Name Vendor Number Full Vendor Name Vendor Street Address
Vendor City Vendor Postal Code Marked For Deletion
Output Visualization Examples
ContextDifferent vendors from a
common address is not a
usual occurrence, and could
indicate either fictitiously
created vendors and/or
incorrect vendor master data.
Vendor data should be
accurate to enable correct
processing and accurate
reporting.
Essentials | Procure To Pay - Vendor Management | VM_ANALYTIC_02_VMCS103 Page 67
Heatmap of
exceptions
Count of exceptions
grouped by address
Last Invoice Number
Last Invoice Amount in Document CurrencyLast Transaction Date Last Invoice Document Currency
Vendors With The Same Phone
NumbersVM_ANALYTIC_03_VMCS125
Identifies vendors with the same phone numbers
ACCOUNTS PAYABLE
Essentials – Vendor Management Page 68
RiskPossible fictitious/incorrect vendor accounts created, resulting in fraudulent/incorrect vendor
transactions and payments.
ProcedureIdentifies vendors with the same phone numbers.
Note: In a system with various branches, plants and/or cost codes, a single vendor often needs
to be created and managed per location and these multiple vendors can come through as false
positives.
Analytic LogicCompares vendor phone numbers in the vendor master file to detect those which are the same.
Vendors With The Same Phone Numbers
Output Results Field Names
Company Code Company Name Vendor Number Full Vendor Name Vendor Telephone Number 1
Vendor Telephone Number 2
Output Visualization Examples
ContextDifferent vendors with
common contact details are
not expected and could
indicate either fictitiously
created vendors and/or
incorrect vendor master data.
Vendor data should be
accurate to enable correct
processing and accurate
reporting.
Essentials |Procure To Pay - Vendor Management | VM_ANALYTIC_03_VMCS125 Page 69
Count of exceptions by
vendor name and phone
number
Heatmap of exceptions
by vendor name and
phone number
Last Invoice Number
Last Invoice Amount in Document Currency
Last Transaction Date
Last Invoice Document Currency
Vendors With The Same Bank
Account DetailsVM_ANALYTIC_04_VMCS118
Identifies vendors with the same bank account details
ACCOUNTS PAYABLE
Essentials – Vendor Management Page 70
RiskPossible fictitious/incorrect vendor accounts created, resulting in fraudulent/incorrect vendor
transactions and payments.
ProcedureIdentifies vendors with the same bank account details. Note: In a system with various
branches, plants and/or cost codes, a single vendor often needs to be created and managed
per location and these multiple vendors can come through as false positives.
Analytic LogicCompares captured bank account details of vendors in the vendor master file to detect those
which are the same.
Vendors With The Same Bank Account Details
Output Results Field Names
Company Code Company Name Vendor Number Full Vendor Name Vendor Bank Account
Vendor Bank Branch CodeVendor Bank Country Code
Output Visualization Examples
ContextDifferent vendors with
common bank account details
are not expected and could
indicate either fictitiously
created vendors and/or
incorrect vendor master data.
Vendor data should be
accurate to enable correct
processing and accurate
reporting.
Essentials | Procure To Pay - Vendor Management | VM_ANALYTIC_04_VMCS118 Page 71
Heatmap of vendors with
the same bank account
Count of vendors with the
same bank account
Last Invoice Number
Last Invoice Amount in Document Currency
Last Transaction Date
Last Invoice Document Currency
Vendors With The Same
Sales Tax Registration NumberVM_ANALYTIC_05_VMCS126
Identifies vendors with the same sales tax numbers
ACCOUNTS PAYABLE
Essentials – Vendor Management Page 72
RiskPossible fictitious/incorrect vendor accounts created, resulting in fraudulent/incorrect vendor
transactions and payments.
ProcedureIdentifies vendors with the same sales tax registration numbers.
Note: In a system with various branches, plants and/or cost codes, a single vendor often
needs to be created and managed per location and these multiple vendors can come through
as false positives.
Analytic LogicCompares captured sales tax registration numbers of vendors in the vendor master file and
analyses for duplicates.
Vendors With The Same Sales Tax Registration Number
Output Results Field Names
Company Code Company Name Vendor Number Full Vendor Number Vendor VAT Number
Marked for Deletion
Output Visualization Examples
ContextCommon sales tax
registration numbers across
multiple vendors are not
expected and could indicate
either fictitiously created
vendors and/or incorrect
vendor master data.
Essentials | Procure To Pay - Vendor Management | VM_ANALYTIC_05_VMCS126 Page 73
Heatmap of exceptions
Count of exceptions
Last Invoice Number
Last Invoice Amount in Document Currency
Last Transaction Date
Last Invoice Document Currency
Vendors With The Same
Business NumberVM_ANALYTIC_06_VMCS301
Identifies vendors with same business number
ACCOUNTS PAYABLE
Essentials – Vendor Management Page 74
RiskPossible fictitious/incorrect vendor accounts created, resulting in fraudulent/incorrect vendor
transactions and payments.
ProcedureIdentifies vendors with same business number.
Note: In a system with various branches, plants and/or cost codes, a single vendor often
needs to be created and managed per location and these multiple vendors can come through
as false positives.
Analytic LogicCompares captured business numbers (or equivalent corporate tax reference numbers) of
vendors in the vendor master file and analyses for duplicates.
Vendors With The Same Business Number
Output Results Field Names
Company Code Company Name Vendor Number Full Vendor Name Vendor Tax Number 1
Vendor Tax Number 2 Vendor Address Vendor City Marked for Deletion
Output Visualization Examples
ContextCommon business numbers
across multiple vendors are
not expected and could
indicate either fictitiously
created vendors and/or
incorrect vendor master data.
Essentials |Procure To Pay - Vendor Management | VM_ANALYTIC_06_VMCS301 Page 75
Heatmap of vendors with a
common tax number
Count of vendors with a
common tax number
Last Invoice Number
Last Invoice Amount in Document CurrencyLast Transaction Date Last Invoice Document Currency
Frequently Changed Vendor
Bank Account DetailsVM_ANALYTIC_07_VMCS119
Identifies frequently changed vendor bank account details
ACCOUNTS PAYABLE
Essentials – Vendor Management Page 76
RiskPossible fictitious/incorrect vendor accounts created, resulting in fraudulent/incorrect vendor
transactions and payments.
ProcedureIdentifies frequently changed vendor bank account details.
Analytic LogicExtracts and analyzes all changes made to a vendor's bank account details and highlights
records that changed more than twice in a defined period.
Frequently Changed Vendor Bank Account Details
Output Results Field Names
Vendor Number Vendor Name 1 Change Document Number Changed Table Changed Field Name
Vendor Creator User IDUser ID Full Name Vendor Management Account Group Change Date
Output Visualization Examples
ContextVendors do not frequently
amend their banking facility.
Frequently changed vendor
master data, especially
banking information, should
be investigated as this may
indicate suspicious activity.
Essentials | Procure To Pay - Vendor Management | VM_ANALYTIC_07_VMCS119 Page 77
Count by date of bank
accounts frequently
changed
Pie chart of changes
per vendor
Matching Of Vendor And
Employee NamesVM_ANALYTIC_08_VMCS122
Identifies where names match between employees and vendors
ACCOUNTS PAYABLE
Essentials – Vendor Management Page 78
RiskPossible fictitious/incorrect vendor accounts created, resulting in fraudulent/incorrect vendor
transactions and payments.
ProcedureIdentifies where names match between employees and vendors, using cleaned vendor
names. Employee vendors are sometimes created for paying out reimbursed expenses
through accounts payable and not through payroll, so there may be false positives for these
employee vendors.
Analytic LogicExtracts cleaned names of vendors in the vendor master file and compares to first and last
names of employees in the employee master file.
Matching Of Vendor And Employee Names
Output Results Field Names
Company Code Company Name Vendor Number Full Vendor Name Marked For Deletion
Personnel AreaEmployee Status Employee Personnel Number Employee Full Name
Output Visualization Examples
ContextInstances where the
employee and vendor names
match should be investigated
as these could possibly
indicate fraudulent
transactions and/or incorrect
vendor master data.
Essentials | Procure To Pay - Vendor Management | VM_ANLYTIC_08_VMCS122 Page 79
Count of employee and
vendor name match
Pie chart of employee
and vendor name match
Matching Of Vendor And
Employee Physical AddressVM_ANALYTIC_09_VMCS123
Identifies where physical addresses match between employees and vendors
ACCOUNTS PAYABLE
Essentials – Vendor Management Page 80
RiskPossible fictitious/incorrect vendor accounts created, resulting in fraudulent/incorrect vendor
transactions and payments.
ProcedureIdentifies where physical addresses match between employees and vendors.
Employee vendors are sometimes created for paying out reimbursed expenses through
accounts payable and not through payroll, so there may be false positives for these employee
vendors.
Analytic LogicExtracts captured physical or registered addresses of vendors in the vendor master file and
compares to physical addresses of employees in the employee master file.
Matching Of Vendor And Employee Physical Addresses
Output Results Field Names
Company Code Company Name Vendor Number Full Vendor Name Vendor Address
Marked for Deletion Personnel Area Employee Personnel Number Employee AddressEmployee Full Name
Output Visualization Examples
ContextInstances where the
employee and vendor
addresses match should be
investigated as these could
possibly indicate fraudulent
transactions and/or incorrect
vendor master data.
Essentials | Procure To Pay - Vendor Management | VM_ANALYTIC_09_VMCS123 Page 81
Count of employee-vendor
address match
Pie chart of employee-
vendor address match
Last Invoice Number Last Invoice Amount in Document CurrencyLast Transaction Date Last Invoice Document Currency
Matching Of Vendor And
Employee Primary Phone
NumbersVM_ANALYTIC_10_VMCS124
Identifies where primary phone numbers match between employees and vendors
ACCOUNTS PAYABLE
Essentials – Vendor Management Page 82
RiskPossible fictitious/incorrect vendor accounts created, resulting in fraudulent/incorrect vendor
transactions and payments.
ProcedureIdentifies where primary phone numbers match between employees and vendors.
Employee vendors are sometimes created for paying out reimbursed expenses through
accounts payable and not through payroll, so there may be false positives for these employee
vendors.
Analytic LogicExtracts the main phone number of vendors in the vendor master file and compares to the
personal phone numbers of employees in the employee master file.
Matching of Vendor & Employee Primary Phone Numbers
Output Results Field Names
Company Code Company Name Vendor Number Full Vendor Name Vendor Telephone Number 1
Marked for DeletionPersonnel Area Employee Status Employee Full NameEmployee Personnel Number
Employee Telephone Number
Output Visualization Examples
ContextInstances where the employee
and vendor telephone
numbers match should be
investigated as these could
possibly indicate fraudulent
transactions and/or incorrect
vendor master data.
Essentials | Procure To Pay - Vendor Management | Vm_analytic_10_vmcs124 Page 83
Count of exceptions by
phone number
Heatmap of exceptions by
employee & vendor
Last Invoice Number
Last Invoice Amount in Document Currency
Last Transaction Date Last Invoice Document Currency
Matching Of Vendor And
Employee Bank AccountsVM_ANALYTIC_11_VMCS117
Identifies where bank accounts match between employees and vendors
ACCOUNTS PAYABLE
Page 84Essentials – Vendor Management
RiskPossible fictitious/incorrect vendor accounts created, resulting in fraudulent/incorrect vendor
transactions and payments.
ProcedureIdentifies where bank accounts match between employees and vendors.
Employee vendors are sometimes created for paying out reimbursed expenses through
accounts payable and not through payroll, so there may be false positives for these employee
vendors.
Analytic LogicExtracts captured bank account details of vendors in the vendor master file and compares to
bank accounts details of employees in the employee master file to detect those which are the
same.
Matching Of Vendor And Employee Bank Accounts
Output Results Field Names
Company Code Company Name Vendor Number Full Vendor Name Vendor Bank Account Branch Code
Employee Company Code Personnel Area Employee Full NameEmployee Personnel Number
Employee Bank Account Number Employee Bank Branch Code
Employee Status
Output Visualization Examples
ContextSegregation of employee and
vendor payments should
always exist. Ordinarily,
employees should not be
created as vendors which
would avoid mixing these
payment types. If correctly
applied, this would ensure
that no vendor banking details
will match employee banking
details.
Essentials | Procure To Pay - Vendor Management | VM_ANALYTIC_11_VMCS117 Page 85
Heatmap of vendors and
employee bank
accounts
Exceptions by vendor
name and employee
bank account
Vendor Bank Branch Code Last Invoice Number
Last Invoice Amount in Document CurrencyLast Transaction Date Last Invoice Document Currency
Vendors With No Business
NumberVM_ANALYTIC_12_VMCS120
Identifies vendors with no business number
ACCOUNTS PAYABLE
Essentials – Vendor Management Page 86
RiskPossible fictitious/incorrect vendor accounts created, resulting in fraudulent/incorrect vendor
transactions and payments.
ProcedureIdentifies vendors with no business number.
Analytic LogicExtracts and analyses the business number, or equivalent corporate tax registration number,
field in the vendor master file to detect blank fields.
Vendors With No Business Number
Output Results Field Names
Company Code Company Name Vendor Number Full Vendor Name Vendor Tax Number 1
Vendor Tax Number 2 Vendor Country Key
Output Visualization Examples
ContextComplete and accurate
vendor master data requires
the vendor’s business number
to be captured. If the number
is not captured it could
indicate incomplete vendor
master data and/or a fictitious
vendor.
Essentials | Procure To Pay - Vendor Management | VM_ANALYTIC_12_VMCS120 Page 87
Count of vendors with
blank details
List of vendors with
blank details
Count of vendors with
blank details
Last Invoice Number
Last Invoice Amount in Document Currency
Last Transaction Date
Last Invoice Document Currency
Vendors With No Sales Tax
Registration NumberVM_ANALYTIC_13_VMCS121
Identifies vendors with no sales tax registration number
ACCOUNTS PAYABLE
Essentials – Vendor Management Page 88
RiskPossible fictitious/incorrect vendor accounts created, resulting in fraudulent/incorrect vendor
transactions and payments.
ProcedureIdentifies vendors with no sales tax registration number.
This analytic depends on the data quality of vendor master data. If this detail is not captured or
even asked of vendors, then there will be a high volume of blanks.
Analytic LogicExtracts the sales tax registration number or equivalent registration number for the purposes
of indirect sales tax and highlights all vendors with no sales tax registration number.
Vendors With No Sales Tax Registration Number
Output Results Field Names
Company Code Company Name Vendor Number Full Vendor Name Vendor VAT Number
Output Visualization Examples
ContextComplete and accurate
vendor master data requires
the vendor’s sales tax
registration number to be
captured. If the sales tax
registration number is not
captured it could indicate
incomplete vendor master
data and/or a fictitious vendor.
Essentials | Procure To Pay - Vendor Management | VM_ANALYTIC_13_VMCS121 Page 89
Count of exceptions
grouped by vendor
Count of exceptions
grouped by vendor
Last Invoice Number
Last Invoice Amount in Document CurrencyLast Transaction Date Last Invoice Document Currency
Blank Critical Data: Telephone
NumbersVM_ANALYTIC_14_VMCS515
Identifies vendors with no telephone number in the vendor master file
ACCOUNTS PAYABLE
Essentials – Vendor Management Page 90
RiskPossible fictitious/incorrect vendor accounts created, resulting in fraudulent/incorrect vendor
transactions and payments.
ProcedureIdentifies vendors with no telephone number in the vendor master file.
Data quality will always be a risk with this analytic and extracting false positives but given such
a key field, these exceptions should be investigated.
Analytic LogicExtracts and analyzes the telephone number field of the vendor master file and highlights all
those without a telephone number.
Blank Critical Data: Telephone Numbers
Output Results Field Names
Company Code Company Name Vendor Number Full Vendor Name Vendor Telephone Number 1
Output Visualization Examples
ContextComplete and accurate
vendor master data requires
the vendor’s telephone
number(s) to be captured. If
the contact details are not
captured it could indicate
incomplete vendor master
data and/or a fictitious vendor.
Essentials | Procure To Pay - Vendor Management | VM_ANALYTIC_14_VMCS515 Page 91
Count of blank
telephone number fields
Pie chart of blank
telephone number fields
Last Invoice Number Last Invoice Amount in Document CurrencyLast Transaction Date Last Invoice Document Currency
Blank Critical Data: Bank
DetailsVM_ANALYTIC_15_VMCS516
Identifies vendors with no bank account number in the vendor master file
ACCOUNTS PAYABLE
Essentials – Vendor Management Page 92
RiskPossible fictitious/incorrect vendor accounts created, resulting in fraudulent/incorrect vendor
transactions and payments.
ProcedureIdentifies vendors with no bank account number in the vendor master file.
Analytic LogicExtracts and analyses the bank account number field of the vendor master file and highlights
all those without a bank account number.
Blank Critical Data: Bank Details
Output Results Field Names
Company Code Company Name Vendor Number Full Vendor Name Vendor Bank Account
Vendor Bank Branch CodeVendor Bank Country Code
Output Visualization Examples
ContextComplete and accurate
vendor master data requires
the vendor’s bank details to
be captured. If the information
is not captured it could
indicate incomplete vendor
master data and/or a fictitious vendor.
Essentials | Procure To Pay - Vendor Management | VM_ANALYTIC_15_VMCS516 Page 93
Pie chart of blank bank
vendor details
List of blank bank vendor
details
Last Invoice Number
Last Invoice Amount in Document Currency
Last Transaction Date
Last Invoice Document Currency
Vendors With Only Postal Box
AddressVM_ANALYTIC_16_VMCS102
Identifies vendors with only a postal box address
ACCOUNTS PAYABLE
Essentials – Vendor Management Page 94
ContextVendors without a physical
address may be fictitious and
lead to fraudulent
transactions. Vendor data
should be accurate to enable
correct processing and
accurate reporting.
RiskPossible fictitious/incorrect vendor accounts created, resulting in fraudulent/incorrect vendor
transactions and payments.
ProcedureIdentifies vendors with only postal box addresses.
Those vendors without a physical address may represent incomplete data or may be fictitious.
Although a lot of exceptions will come from poor data quality, a false positive does not really
exist as all vendors should have a registered physical address.
Analytic LogicExtracts vendor data and analyses for vendors without a physical address loaded.
Vendors With Only Postal Box Address
Output Results Fields
Company Code Company Name Vendor Number Full Vendor Name Vendor PO Box Vendor City
Output Visualization Examples
Vendor PO Box Postal Code
Essentials | Procure To Pay - Vendor Management | VM_ANALYTIC_16_VMCS102 Page 95
Exceptions listed by
both vendor and city
Count of exceptions
grouped by the vendor
Last Invoice Number
Last Invoice Amount in Document Currency
Last Transaction Date Last Invoice Document Currency
Vendors With a Single PosterVM_ANALYTIC_17_VMCS612
Identifies vendors that have a single user posting to that vendor over a certain period of
time
ACCOUNTS PAYABLE
Essentials – Vendor Management Page 96
ContextIf a single user is posting
transactions to a particular
vendor, this could indicate a
potential relationship between
the poster and the vendor or
a bias towards that particular
vendor.
RiskPossible collusion between an employee and a vendor.
ProcedureIdentifies any vendor with more than X transactions at more than Y amount over Z period of
time that have only a single user posting to the vendor.
Analytic LogicExtracts vendors with more than a configurable number of transactions, more than a
configurable amount over a configurable time period, that only have a single user poster to the
vendor.
Vendors With a Single Poster
Output Results Fields
Company Code Company Name Vendor Number Full Vendor Name Vendor Invoice Number
Document DateInvoice Amount Document Currency
Essentials | Procure To Pay - Vendor Management | VM_ANALYTIC_17_VMCS612 Page 97
Results Grouping Parked User ID
Released User ID
Parked User Name
Released User Name
Vendor Hit MatrixVM_HIT_MATRIX
Hit matrix of all vendors with exceptions from the analytics in this analysis app
ACCOUNTS PAYABLE
Essentials – Vendor Management Page 98
ContextThe vendor hit matrix allows
you to better analyse
exceptions from this analysis
app. It provides a report of all
exceptions by vendor and by
analytic. This will assist in
directing efforts to verifying
the validity of those vendors
with the most hits.
RiskVendors with many hits for missing data could potentially be fictitious vendors or an indication
of poor data quality.
ProcedurePresents vendors by exceptions, i.e. shows the number of hits per vendor per analytic to
identify high risk vendors.
Analytic LogicCollates all exceptions noted in all the analytics in this analysis app by vendor and by analytic.
Vendor Hit Matrix
Output Results Fields
Vendor Number Vendor Name Vendor Name 2 Marked for deletion Total hits VM_Analytic_01
Output Visualization Examples
Essentials | Procure To Pay - Vendor Management | VM_HIT_MATRIX Page 99
VM_Analytic_02 VM_Analytic_03 VM_Analytic_04 VM_Analytic_05 VM_Analytic_06 VM_Analytic_07
VM_Analytic_08 VM_Analytic_10VM_Analytic_09 VM_Analytic_11 VM_Analytic_12 VM_Analytic_13
VM_Analytic_14 VM_Analytic_15 VM_Analytic_16
Vendor Hit Matrix
ContentsPage Analytic Name
101 Cash disbursements by vendorCD Analytic 01
103Summary of cash disbursements by vendorCD Analytic 02
105Duplicate cash disbursementsCD Analytic 03
107Vendors with large numbers of cash disbursementsCD Analytic 04
Version 6.2.0 – 2019/04
Cash Disbursements By
VendorCD_ANALYTIC_01_CDCS101
Extracts all cash disbursements by vendor
ACCOUNTS PAYABLE
Page 101Essentials – Cash Disbursements
Essentials | Cash Disbursements | CD_ANALYTIC_01_CDCS101
ContextCash disbursements refers to
the outflow or payment of
money to settle financial
obligations during a particular
period in order to carry out
business activities.
RiskCash disbursements made to the incorrect vendor.
ProcedureIdentifies all cash disbursements by vendor.
Analytic LogicExtracts disbursements with vendor information.
Cash Disbursements By Vendor
Output Results Field Names
Company Code Company Name Vendor ID Vendor Name Accounting Document Number
Output Visualization Examples
Page 102
Line Item Accounting Document Number Report Payment Amount Report Currency
Document Date Clearing Document Number Clearing Date Pay User Name
Item Description
Pay User ID
Total net price of cash
disbursements by
vendor & type
Net price by description
for a vendor
Summary Of Cash
Disbursements By VendorCD_ANALYTIC_02_CDCS102
Summarizes cash disbursements by vendor
ACCOUNTS PAYABLE
Page 103Essentials – Cash Disbursements
ContextCash disbursements refers to
the outflow or payment of
money to settle financial
obligations during a particular
period in order to carry out
business activities.
RiskCash disbursements made to the incorrect vendor.
ProcedureSummarizes cash disbursements by vendor.
Analytic LogicExtracts, summarizes and aggregates disbursements by vendor.
Summary Of Cash Disbursements By Vendor
Output Results Fields
Output Visualization Examples
Essentials | Cash Disbursements | CD_ANALYTIC_02_CDCS102 Page 104
Company Code Company Name Vendor ID Vendor Name 1 Amount in Reporting Currency
Report Currency
Summary of cash disbursements by vendor
Total payment amount in report currency by vendor
Duplicate Cash DisbursementsCD_ANALYTIC_03_CDCS103
Extracts duplicate cash disbursements by vendor
ACCOUNTS PAYABLE
Page 105Essentials – Cash Disbursements
RiskOverpayment to vendors and potential irrecoverable financial loss.
ProcedureIdentifies duplicate cash disbursements by vendor.
Analytic LogicExtracts duplicate payments from the disbursements listing using the vendor number and
value of the payment.
Duplicate Cash Disbursements
Output Results Field Names
Output Visualization Examples
ContextProcessing high volumes of
payments from all areas of the
business may result in
potential duplicate cash
disbursements going
undetected.
Essentials | Cash Disbursements | CD_ANALYTIC_03_CDCS103 Page 106
Company Code Company Name Vendor ID Vendor Name Accounting Document Number
Line Item Accounting Document Number Amount in Reporting Currency
Document Date Clearing Document Number
Report Currency Item Description
Clearing Date Pay User IDPay User Name
Total amount of postings by
posting date and posting user
Total amount of exceptions by PO Creator
Name and Vendor
Statistics of duplicate cash disbursements
Vendors With Large Numbers
Of Cash DisbursementsCD_ANALYTIC_04_CDCS104
Extracts vendors with large numbers of cash disbursements
ACCOUNTS PAYABLE
Page 107Essentials – Cash Disbursements
RiskFictitious and/or invalid vendor payments.
ProcedureIdentifies vendors with large numbers of cash disbursements.
Analytic LogicExtracts a summary of disbursements by vendor and adds a count for each vendor, which is
sorted in descending order on the count to highlight vendors with a high value of cash
disbursements.
Vendors With Large Numbers Of Cash Disbursements
ContextFictitious or incorrect vendor
payments may not be easily
detected when a large
number of cash
disbursements are made to a
particular vendor.
Essentials | Cash Disbursements | CD_ANALYTIC_04_CDCS104 Page 108
Output Results Field Names
Output Visualization Examples
Company Code Company Name Vendor ID Vendor Name Amount in Reporting Currency
Report Currency Count
Exceptions by total
amount and vendor
Exceptions by total
amount, quantity and
vendor