ACL duplicate-payment test and three vendors sharing one bank account
At a listed fertiliser company, an audit trainee extracts the full FY20X5 vendor payment data from SAP into ACL: 480,000 line items. She runs a duplicate-payment test matching on vendor number, amount and payment date within a 30-day window. ACL flags 1,150 pairs, a potential leakage of Rs 310 million. The accounts payable manager says most are false positives, because one payment run can settle several invoices for the same vendor, credit memos are posted as negative items, and two vendors are subsidiaries of the same group. The trainee also notices that three different vendor codes share the same bank account number, and that one of those vendors was created six weeks before a Rs 9.8 million payment to it. She has two days before the report goes to the audit committee, and she has not yet retained the extract or the script.
1. Redesign the duplicate-payment test. What keys, exclusions and evidence would you use?
Read the worked answer
The current test answers the wrong question. Matching vendor, amount and a 30-day window identifies repeated same-amount payments, not duplicate payments. A duplicate exists when the same invoice, credit note or payment reference is settled more than once.
The reliable keys are invoice number, invoice date and amount within vendor, or the payment reference plus amount. The test should join the payment line to the invoice line (in SAP, the payment document to the invoice document via the clearing document, rather than a flat extract) so that each payment is tied to a specific invoice. Exclusions: credit memos and negative postings, which are not payments; reversals and cancelled cheques; and legitimate part-payments where the invoice is settled in instalments, which should be matched as a total rather than line by line.
The 30-day window should be dropped. True duplicates can occur months apart, and the window also creates false positives by catching unrelated recurring invoices such as monthly rent. Instead, test the full population for the same invoice number appearing in more than one payment. For the flagged population, obtain the invoice, purchase order, goods receipt and bank statement, and confirm with the vendor where necessary. Present results in tiers: confirmed duplicates, probable duplicates requiring evidence, and cleared false positives with the reason. Retain the ACL script, the extract with date and row count, and the results file before anything else.
2. Three vendor codes share one bank account, and one vendor was created shortly before a Rs 9.8 million payment. What can the trainee conclude, and what should she do next?
Read the worked answer
She cannot conclude fraud. She can conclude that a red flag exists that warrants investigation, and she must be careful to describe it that way in the report. Shared bank accounts have innocent explanations: a group treasury arrangement where subsidiaries are paid through a central account, a factor or agent, or a data-entry error in the vendor master.
The pattern becomes more serious because of the combination: three separate vendor codes, one newly created vendor, and a large payment soon after creation. That is the classic profile of a fictitious or shell vendor. The next steps are evidence-gathering, not accusation. She should inspect the vendor master records for the three codes: creation date and user, bank details, address, tax number, contact person and any change history. She should compare addresses and phone numbers with employees and existing vendors, and check whether the vendor was approved under the normal workflow or created with emergency access. She should obtain the purchase order, goods receipt and delivery evidence for the Rs 9.8 million, confirm the bank account directly with the vendor through an independent channel rather than a number supplied by the creator, and check whether the same bank account appears in the employee payroll file.
If the explanations do not hold, the matter goes to the Head of Internal Audit and, depending on the evidence, to forensic investigation. The report should state the facts and the risk, with a recommendation to suspend further payments pending verification.
3. The AP manager offers to provide a sample of 30 cleared invoices to show the process is fine. How should the trainee respond, and how should the findings be reported?
Read the worked answer
A sample of 30 invoices chosen by the manager who is being tested does not address the question. The whole advantage of the ACL extract is that the population is available: the test can be run on all 480,000 line items, so sampling error need not be introduced. The trainee should explain politely that the data analysis already covers the full population, and that what she needs is documentation for the specific exceptions, not a sample to prove the general process.
In reporting, the key discipline is to separate what was found from what it might mean. The report should state the population tested, the period, the source system and extract date, the test logic, and the row counts, so the reader can see the coverage. Findings should be tiered: confirmed exceptions with evidence; probable exceptions awaiting evidence; and cleared items with reasons, including the AP manager's explanations where they were verified. The Rs 310 million should not be presented as a loss - it is the gross value of flagged pairs before false positives are removed. Presenting it as leakage would destroy the report's credibility when the committee learns that most pairs are legitimate.
Recommendations should be control-focused: match on invoice number in the duplicate test, restrict vendor master creation and bank-detail changes, require independent verification of bank details for new vendors, and run the duplicate test monthly rather than annually. The ACL script, extract and results should be retained as audit evidence, and the shared bank account matter should be cross-referenced to the investigation rather than closed in the same report.