ACL ESSENTIALS - Amazon S3 · ACL ESSENTIALS | PROCURE TO PAY - ACCOUNTS PAYABLE |...

ACCOUNTS PAYABLE

ACL ESSENTIALSGet insight into your ERP process health,

compliance & financial exposure

Page Analytic Name

Duplicate paymentsAP Analytic 01

Duplicate invoicesAP Analytic 02

Duplicate invoices using vendor’s numeric invoice valuesAP Analytic 03

Duplicate invoices sub analyticsAP Analytic 04

Future dated invoicesAP Analytic 05

Recurring sundry expense reviewAP Analytic 06

Invoices for one-time vendorsAP Analytic 07

Vendor payments made over a weekendAP Analytic 08

Invoices captured over a weekendAP Analytic 09

Invoices greater than a thresholdAP Analytic 10

Purchase order date after the invoice dateAP Analytic 11

Vendor paid by both purchase order and sundry expense AP Analytic 12

Invoices greater than approved purchase ordersAP Analytic 13

Manually released invoices (no 3-way match)AP Analytic 14

Version 6.1.0 –2018/08

Page Analytic Name

Three way match re-performanceAP Analytic 15

Outlier invoicesAP Analytic 16

Early payment of invoicesAP Analytic 17

Version 6.1.0 –2018/08

Identifies all potential duplicate payments to the same vendor for the same amount made within a configurable time period

ACL ESSENTIALS – ACCOUNTS PAYABLEPAGE 3

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 vendorinvoices being submitted for payment with details similar to an original valid invoice. Thismay result in overpayment to vendors or irrecoverable financial losses.

ProcedureIdentifies potential duplicate payments made to the same vendor for the same amountwithin a configurable time period (e.g. 14 days, 30 days).

Analytic LogicExtracts payments within a user-determined period of days and identifies potentialduplicate 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.

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

ACL ESSENTIALS | PROCURE TO PAY - ACCOUNTS PAYABLE | AP_ANALYTIC_01_APCS102 PAGE 4

Example

VENDOR_ID VENDOR_NAME_1 ACCOUNTING_DOC_NUMBER DOCUMENT_DATE AMT_DOC_CURRENCY

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

Identifies potential duplicate invoices after stripping out any special characters in the invoice numbers


RiskThe same vendor invoice is presented twice for payment or fictitious/invalid vendorinvoices are paid. This may result in either overpayment or incorrect payment to vendorsand often irrecoverable financial losses from fraudulent and/or invalid invoices beingpaid.

ProcedureIdentifies duplicate paid invoices for the same amount after stripping out any specialcharacters in the invoice numbers.

Analytic LogicExtracts all paid invoices and removes/strips out special characters (e.g. ~!@#$%) fromthe invoice number field (which is normally a free text field in the ERP system). Thereafterthe script performs a duplicates test using the stripped invoice number and invoice valuefields.

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


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


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


Identifies potential duplicate invoices after converting invoice numbers to numeric values


RiskThe same vendor invoice is presented twice for payment or fictitious/invalid vendorinvoices are paid. This may result in either overpayment or incorrect payment to vendorsand often irrecoverable financial losses from fraudulent and/or invalid invoices beingpaid.

ProcedureIdentifies duplicate paid invoices for the same amount after converting the invoicenumbers 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 invoicenumber and invoice value fields.


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



Showing value over time


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


Identifies potential duplicate invoices using various sub analytics


RiskThe same vendor invoice is presented twice for payment or fictitious/invalid vendorinvoices are paid.

ProcedureIdentifies duplicate paid invoices by analysing for duplicates based on the ten variations inthe table below.

Analytic LogicExtracts all paid invoices and performs a duplicates test based on the ten variations in thetable below, for example identifying duplicate invoices where the vendor number andinvoice number are the same.


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


ACL ESSENTIALS | PROCURE TO PAY - ACCOUNTS PAYABLE | AP_ANALYTIC_04_APCS613.1 to AP_ANALYTIC_04_APCS613.10 PAGE 8

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.

Extracts all invoices with invoice dates in the future


RiskNon-payment of invoices due to incorrect invoice date capturing resulting in unnecessaryinterest or penalties, or premature invoicing of services that have not been rendered, orpotentially fictitious invoices.

ProcedureExtracts all invoices with invoice dates in the future. The invoice date is manually inputtedand not system-generated. They are susceptible to human error during capturing andincorrect 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.


Company Code Company Name Vendor ID Vendor Name

Debit / Credit Indicator

Amount in Reporting Currency

Report Currency Amount in Document Currency


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

ACL ESSENTIALS |PROCURE TO PAY - ACCOUNTS PAYABLE | AP_ANALYTIC_05_APCS341 PAGE 10

Identifies all repetitive sundry invoices from the same vendor for the same amount


RiskUnauthorised invoices could be paid because less stringent procurement controls existfor sundry expenses. This has the potential to result in unauthorised, invalid, excessive orpotentially fraudulent payments.

ProcedureIdentifies all repetitive sundry invoices to the same vendor for the same amount. Thesevendors should be reviewed to understand why repetitive invoices are paid as sundryexpenses, rather than through procurement, when there is an evident continuing businessrelationship.

Analytic LogicExtracts and filters invoices for sundry expenses using a unique invoice identifier (definedin scoping), and performs a duplicate analysis using the vendor ID and value to provide alisting of all multiple sundry expenses.


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


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


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

Extracts all invoices made to one-time vendors

ACL ESSENTIALS – ACCOUNTS PAYABLEPAGE13

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 lossesfrom fraudulent/invalid invoices being authorized and paid.

ProcedureExtracts all invoices made to one-time vendors classified as such on the vendor masterfile. Through interpretations and visualizations, validation of one-time vendor invoicescan proceed, raising exceptions for further examination.

Analytic LogicExtracts all invoices from companies classified as one-time vendors in the ERP vendormaster data, in a given period.


Company Code Company Name Vendor ID Vendor Name Debit / Credit Indicator


Report Currency

Amount in Document Currency Accounting Document NumberDocument Currency

Document Date Vendor Invoice Number Vendor Stripped Invoice Number Release User Released User Name


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


Identifies where the payment release date falls on a weekend


RiskPotentially invalid or fraudulent vendor transactions which may result in overpayment tovendors 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 aSaturday or Sunday whereby it will be listed as an exception.


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



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


Vendor Invoice Number

Identifies where invoices were captured over a weekend

ACL ESSENTIALS – ACCOUNTS PAYABLEPAGE17

RiskPotentially invalid or fraudulent vendor transactions which may result in overpayment tovendors or often irrecoverable financial losses.

ProcedureIdentifies where invoices were captured over a weekend. All invoices captured in the ERPsystem 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 thisanalytic.

Analytic LogicExtracts where the entry/capture date of invoices fall on a Saturday or Sunday whereby it

will be listed as an exception.




Report Currency


Document Date Vendor Invoice Number Vendor Stripped Invoice Number Release User

Released User Name


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


Day of Week

Date Document Entered

Produces a list of invoices paid above a configurable threshold to determine authorization process for testing


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 transactionsshould 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).


Company Code Company Name Vendor ID Debit / Credit Indicator

Release User


Report Currency Amount in Document Currency Document Currency Accounting Document Number

Document Date Vendor Invoice Number Vendor Stripped Invoice Number


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


Identifies where the invoice date precedes the purchase order approval date


RiskIneffective procurement due to finance and procurement procedures not being followedwhich 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 thepurchase order approval date.


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


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


Identifies the most recent instances where vendor invoices are paid by both a purchase order and by a sundry expense


RiskUnauthorised invoices outside the scope defined in the purchase order could be paidbecause less stringent procurement controls exist for sundry expenses. This may result inunauthorized, invalid, excessive or potentially fraudulent payments.

ProcedureIdentifies the most recent instances where vendor invoices are paid by both a purchaseorder and by a sundry expense. These vendors should be reviewed to understand whythey are being paid as both a procurement and sundry expense when it is expected alltransactions should be in line with a purchase order for a repetitive vendor.

Analytic LogicSummarizes vendors' invoices to extract the latest transactions where vendor invoiceswere processed through both a sundry expense and a purchase order.




Report Currency


Document Date Vendor Invoice Number Vendor Stripped Invoice Number Release User

Released User Name


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


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

Extracts all invoices exceeding the value of the related approved purchase orders


RiskInvoices exceeding purchase orders could be caused by unauthorised changes to theinitially 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 aconfigurable threshold value and above.

Analytic LogicExtracts and compares the value on the invoice to the total value of the approvedpurchase order and identifies instances where invoice value exceed the purchase order bythe 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 addedto the purchase order value before comparison is done.

VariableMinimum acceptable variance.


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


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


Example

Difference

VENDOR_NAME PO_NUMBERPO_TOTAL_AMT_INCL_VAT_DOC_CURR

INV_AMOUNT_DOC_CURRENCY

DIFFERENCE

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)

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


ACL 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 apayment 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 whichhave been manually released for payment (either before or after payment).


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


Three-way-match violations,

grouped by releasing user

PAGE 28

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

Re-performs the three way match using purchase order and invoice amounts and purchase order, goods received

and invoice quantities

ACCOUNTS PAYABLE



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 orderamount differ as well as where a three-way-match, between the invoice, purchase orderand goods received note quantities did not occur.

Analytic LogicExtracts all invoices and highlights transactions without correct three-way-matchbetween purchase order, good received note and invoice quantities and invoice andpurchase order amounts.


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


Total amount differences between invoice amounts and purchase order amounts

PAGE 30

Amount in Document Currency Incl VAT

Purchase Order Quantity

GR Document Number Invoice Number

PO Line Number

Reason for Exception

Identify invoice amounts greater than x standard deviations from the median amount of that vendor

ACCOUNTS PAYABLE



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 thatdeviate significantly from the expected amounts posted to a vendor.

Analytic LogicExtracts all invoice amounts greater than a configurable number of standard deviationsfrom the median amount for that vendor.

VariableNumber of standard deviations.

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 30

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

Identify invoices that were paid after the discount dictated in the payment terms and calculate the value of

those missed discounts

ACCOUNTS PAYABLE



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 andcalculate the lost opportunity of missing out on that discount.

Analytic LogicExtracts all invoices that were paid after the discount as per the payment terms andcalculates the discount that could have been claimed had the invoice been paid within thediscount payment terms.


Company Code Company Name Vendor ID Vendor Name Debit/ Credit Indicator

Report Currency

Amount in Document Currency


Document CurrencyVendor Stripped Invoice Number

Vendor Invoice Number

Invoice Amount Reporting Currency

Payment Terms Code


PAGE 30

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

ACL ESSENTIALS - Amazon S3 · ACL ESSENTIALS | PROCURE TO PAY - ACCOUNTS PAYABLE |...

Documents

Transcript of ACL ESSENTIALS - Amazon S3 · ACL ESSENTIALS | PROCURE TO PAY - ACCOUNTS PAYABLE |...