ACL Duplicate Invoices Detection

1
ACL Duplicate Invoices Detection

• Overview
• Using ACL to detect and report Duplicate Invoices
  within and between a Rail Entitys Ariba
  procurement, Ellipse AP and Purchase Card ( iCMS
  ) systems.

2
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 auditors tool
  of choice for developing cross systems data
  acquisition and analysis / testing.

3
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.

4
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 )

5
The Audit Perspective - 1

• Both the Rail entity Internal Audit department
  and the NSW Audit Office have audited the
  entitys 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.

6
The Audit Perspective - 2
Continuum of Audit Analytics
Rail entity is here
7
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)

8
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
• SNormalised Charge ( supplier ) Name, APayment
  Amount, IInvoice Id,
• DInvoice Date, NEmployee Name, PPurpose
  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.

9
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