ACL Duplicate Invoices Detection

Overview

Using ACL to detect and report Duplicate Invoices within and between a Rail Entity’s

Ariba procurement, Ellipse AP and Purchase Card ( iCMS ) systems.

ACL Duplicate Invoices Detection Framework

Currently ACL has projects and modules developed for:

• Procurement ( Ariba )

• Accounts Payable ( Ellipse )

• Purchasing Card ( iCMS )

• A cross platform Supplier ( Matching ) Admin project.

• An integrated Excel based Duplicate Invoice Reporting and Management framework.

• These projects have been developed using the “ACL Analytics" ( ACL ), which is the auditor’s “tool of choice” for developing cross systems data acquisition and analysis / testing.

ACL Duplicate Invoices Detection - Functionality

The three ACL projects make up an over arching Invoices database

• Intelligent Duplicate Invoice detection both within and between the systems has been developed

RISKS identified / addressed ( Duplicate Invoices )

• Within Ariba, Ellipse and iCMS there are some native controls, these have been significantly augmented by the ACL tests

Major risks identified / addressed

• There are no existing system controls to detect duplicate invoice payments between Ellipse AP and iCMS.

• A recent test has been added to detect instances where an invoice has been loaded into Ariba and has not yet made it to Ellipse AP for payment, but the same invoice has already been paid via iCMS. This provides the opportunity to avoid a duplicate payment by rejecting the invoice in Ariba.

ACL Duplicate Invoices Detection - Summary

• Duplicate Invoice detection within Ariba Procurement

• Duplicate Invoice detection within Ellipse AP

• Duplicate Invoice payment detection within Purchase Card ( iCMS )

In addition, duplicate invoice detection is performed for invoices duplicated across Ariba, Ellipse and Purchase Card

• Duplicates between Ellipse and Purchase Card ( iCMS )

• Duplicates between Ariba and Ellipse ( special case )

• Duplicates between Ariba and PCard ( iCMS )

The Audit Perspective - 1

• Both the Rail entity Internal Audit department and the NSW Audit Office have audited the entity’s AP & Purchase Card systems and have highlighted the fact that they could assign a higher degree of confidence to their audit reports due to the implementation of the ACL Duplicate Invoice Detection Framework.

• In the case of the NSW Audit Office, they have stated that their Auditing “bill” to the Rail entity is significantly lessened due to the fact that they do not see the need to perform their own full scale invoice data extraction and ACL Duplicates Analysis.

ad hoc repetitive

2424 7 7 365365

continuous

Continuum of Audit Analytics

One-off analysis and testing

Automated analyses and tests

Managed and deployed from a central environment

Continual execution of automated audit and

monitoring tests to identify errors, fraud and

anomalies on a timely basis

The Audit Perspective - 2

Rail entity is here

Duplicate Invoice payments within iCMS - Summary

Detecting and managing duplicate invoice payments within PCard iCMS is more challenging than within Ellipse / Ariba.

This is due to the fact that iCMS is NOT an accounts payable system.

A cardholder using their card to pay an invoice generates an expense record, and they, after the card statement from Westpac is imported into iCMS, fill out more details in the expense record and scan + save the invoices.

Since July 2012, the Rail entity PCard section have implemented some “best practice” business rules to assist the detection of duplicate invoices.

Whereby the cardholder must:

• enter the invoice number, invoice date and invoice amount (as per the invoice)

• in the case of using the one expense payment to pay more than one invoice, the rules for generating “split” records for each invoice must be followed.

• when splitting the invoice across more than one expense payment (card limit), the purpose field should contain descriptive info like “part 1 of 4 “

ACL generates an iCMS Common Format Invoice record with the Normalised Supplier Name (derived from the Westpac Merchant name)

Duplicate Invoice payments within iCMS - ACL Reports

In spite of the new invoice data capture/coding business rules implemented, there are still possibilities for variations, which are catered for in the ACL logic.

The Excel iCMS Duplicate Invoice Report presents a set of “probability” filters combining:

S=Normalised Charge ( supplier ) Name, A=Payment Amount, I=Invoice Id,

D=Invoice Date, N=Employee Name, P=Purpose Description

The filters are: SAIDNP, SAIDN, SAID, SAI, SA & SI

Eg. SAIDNP means the Invoice records share the same values for the above and are highly likely to be a duplicate invoice payment set

The SI filter is a special case where there could be multiple, but different payment amounts for the same Invoice

The admin person processing the report successively applies these Excel filters and eyeballs the results.

This achieves a satisfactory balance between ACL logic not missing possible duplicates and assisting a human in picking out the real ones.

The model developed for detecting duplicate invoices depends on:

• Building a “common format” logical invoice record from: - invoices in the host ERP system Eg. SAP or Oracle Financials

- invoices paid via the iCMS Purchasing Card system

• Building a “Normalised Supplier Name” cross system master table from the ERP Vendor Master and the iCMS Merchants

• Once the above components are built, the existing ACL logic developed for duplicates detection can be applied ( with some tailoring for local business rules )

• This modular ( meta ) approach enables an efficient implementation for new platforms

Duplicate Invoice Detection in other environments