ACL Duplicate Invoices Detection Overview Using ACL to

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 ( i. CMS ) systems.

ACL Duplicate Invoices Detection Framework Currently ACL has projects and modules developed for: • Procurement ( Ariba ) • Accounts Payable ( Ellipse ) • Purchasing Card ( i. CMS ) • 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 i. CMS 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 i. CMS. • 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 i. CMS. 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 ( i. CMS ) In addition, duplicate invoice detection is performed for invoices duplicated across Ariba, Ellipse and Purchase Card • Duplicates between Ellipse and Purchase Card ( i. CMS ) • Duplicates between Ariba and Ellipse ( special case ) • Duplicates between Ariba and PCard ( i. CMS )

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.

The Audit Perspective - 2 Continuum of Audit Analytics Rail entity is here § 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 anomalies on a timely basis 24 7 365 ad hoc repetitiv e continuo us

Duplicate Invoice payments within i. CMS - Summary Detecting and managing duplicate invoice payments within PCard i. CMS is more challenging than within Ellipse / Ariba. This is due to the fact that i. CMS 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 i. CMS, 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 i. CMS Common Format Invoice record with the Normalised Supplier Name (derived from the Westpac Merchant name)

Duplicate Invoice payments within i. CMS - 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 i. CMS 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.

Duplicate Invoice Detection in other environments 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 i. CMS Purchasing Card system • Building a “Normalised Supplier Name” cross system master table from the ERP Vendor Master and the i. CMS 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