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.
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 and
anomalies on a timely
basis
24
7
365
ad hoc
repetitive
continuous
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.
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 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