|
|
Total Number of Subscribers: 451 |
|
|
|
||
|
|
||
|
Date: 22nd July 2008 |
Compiled by Mr. M. Sathya Kumar |
|
|
|
Continuous Auditing Introduction : David Pinto had joined an Indian multinational after working 15
years in the US. He had seen the changes in the audit function in the US over
the last two decades and had imbibed the changes in his working. He had
successfully transformed the Internal Audit function at Lambada Corporation,
USA from a traditional focus to a COSO-based audit approach and also guided
the organisation in meeting the SOX requirements. He had introduced the
latest audit tools in his team and had productively used them for
enhanced performance. Returning to India as planned, he had decided to transform the
audit function in his new organisation. The Audit Committee in their first
interaction had outlined to David that they were looking at a more
comprehensive coverage, while keeping costs at an affordable level and
without increase in manpower. They were also concerned on repetitive audit
issues which were transactional in nature, despite an integrated software
already implemented in the company. David knew that he could achieve the same only by using a
General Audit Software (GAS) like IDEA, ACL, Active Data and that too by
automating tasks. Further, he considered fixing the repetitive audit issues
through identifying exception reports in the software and also establishing
validation checks in the software. Methodology : Audit Reports of the last 4 quarters were reviewed for
identifying repetitive issues. These issues were taken for discussion
with the concerned auditees and were classified into 2 categories — ‘User training issues,’ and ‘Exception reporting Issues.’ Further, IT had expressed its inability to develop certain
reports due to different priorities. David sought to use a GAS for such
cases. The organisation had an existing GAS and incidentally it was the same
tool which he was using in the US. However, it was an older version and he
first upgraded the tool to the latest version, as he wanted to take the
benefits of all new functionality added in the tool. He then established certain audit objectives that were
standardised and based on records that were also not prone to changes. While he could use the tool to run routines as required, he
wanted to automate the routines. He used the task schedule functionality
available in the GAS. Gist of observations and recommendations : User Training Issues : Stores Issue Slip was neither authorised by person requesting,
nor acknowledged by recipient. Raw Material Stores Issue Slip was not
prepared at times or prepared for a week at a time. The following were
emphasised : 1. preparing a daily slip 2. establishing location codes for stores items. 3. entries for cash to be made every day rather than clubbing of
cash transactions resulted in several instances of negative cash balance. 4. fixing of paid stamp on all supplier’s invoices supported by purchase order and material receipt
note. There were various other stock items, where records were not
updated in the software. Items were not segregated properly leading to difference during
verification which led to waste of time on ‘reconciling’
the
differences. Exception reporting issues with Alerts : Inventory was sought to be managed by obtaining the status on
e-mails whenever the levels were breached. Instead of waiting for a periodic
analysis, the auditor sought to play a proactive role by identifying
instances where the stock levels have been exceeded or stocks have not been
moving beyond the established norms. A System was developed whereby ‘alert
report’ was generated for the storekeeper and copy was automatically sent
to the internal auditor. Algorithm was established by which the system would work out the
items for perpetual inventory verification using the movement pattern, value,
volume of items and its criticality status. Software integrity matters were sought to be checked by ensuring
that there is no negative stocks on hand. An ‘alert’ for negative stocks was instituted. Cash Balance breaches : Daily Cash Balance limits were
established. In case of any deviations, the deviation was sought to be reported
to the Chief Accountant and CFO based on percentage deviation. Insurance Limits were sought to be controlled : The stock
value of insurance was entered and compared with the valuation — branchwise and in totality. Any deviations were to be
reported. Surprise Check of Cash and Stocks An auto alert was established for a surprise check. Surprise
check was to be carried out by the personnel from the Internal Audit
department or personnel not connected with the location. Bank Reconciliation : Bank reconciliation based on electronic bank statements which
could be uploaded for verification. Each cheque instrument entry was
separately made. The pay-in slip was then compiled as a list and given to the
banker. Delays of more than 2 months and in value of more than Rs.20000 were
to be automatically reported for review. Staff Settlements
: Staff settlements not done within 30 days to be reported. The following statements were also to be generated for periodic
reviews : 1. Pending orders where deliveries were delayed or materials
short delivered 2. Materials not received from suppliers on due date or short
received. Task Scheduling using
General Audit Softwares : Using Scripts, the scripting language bundled with GAS, auditors
designed to schedule a complete system, specifying data requirements and
audit tests to automatically generate audit evidence in support of a
continuous audit opinion. These scripts were scheduled to run on a daily,
weekly or monthly basis at a specific time of the day or night. The
scheduling was done using the Windows Task Scheduler. Scripts (macros) were created for various audits and schedules
established. Scheduled Tasks is an option available under the Control Panel
in Windows. Enter the name of your script. Select the frequency you want the
script to run. Enter additional details based on the selection you made in
the previous screen. Enter the name of the user that will run the task. One
example of a user account is : domain name/user name. If the scheduled
task requires administrator permissions to run, then this account must be a
member of the Administrators group. A user can view the scheduled tasks
anytime by double-clicking the Scheduled Tasks in the Control Panel. Although most of the tests could be scheduled using Windows Task
Scheduler, certain kinds of data import into GAS were not possible, and
therefore, were not included. The following tests were scheduled for running
at monthly, quarterly, half-yearly and annual intervals. Accounts
receivable : Transaction totals to the balance on each account were sought to
be recalculated. Debtors were sought to be profiled using numeric stratification
to see the number of large debts and what proportion of value is in the
larger items. For these Debtors, an aged debt analysis was obtained. This was
taken up for specific discussions with the Customer Service Department/Sales
Department. The balance on an account was sought to be compared with the
turnover with the specific customer to ascertain what percentage of turnover
was outstanding on a particular day. Balances were compared with credit limits and ‘report’ exceptions (i.e., accounts with balances in
excess of their credit limits or accounts with no credit limits, etc.). The sales transactions were also matched with the customer
master information to identify sales to new or unauthorised customers. This was
done with the objective of regularising unauthorised transactions and bring
out instances of ‘Internal control’ lapses in case of
debtors. Accounts payable : Test for duplicated invoices using value and supplier code as
the key fields for one test and purchase order number for another. The second
processing of invoices was used to establish fraudulent payments, if any, and
the impact of such payments on the ‘operational
results’ of the company. Tests were established to identify payments made on holidays, or
not on ‘payment days’. On David’s advice the management had
fixed one day a week for clearing suppliers’ payments. Tests were also established to ascertain whether amounts are
being approved at or just below break points in authority level by a value
distribution across the whole ledger. Instances where ‘authority level’ had been exceeded were listed for
discussion and revision if required. Look for split invoices — part payments — to enable approval to be kept by an individual. Extract all invoices within
90% of an approved limit (preferably for a suspected manager or department)
and search for all invoices from that supplier. Sort by approving manager,
department and date to identify possible split invoices or summarise payments
by invoice number to determine how many part-payments have been made for each
invoice. Conclusion : Based on the efforts put in by David and his team, the audit
effort was not only streamlined but routine audit issues that were
transaction based were significantly reduced. Auto alerts forced the ‘process owners’ — those in charge — to initiate timely corrective action. This helped
the managers and internal auditors in providing an assurance to the
management of adequacy of ‘internal controls’. With scheduling of
tasks, the audit team was able to free time for complex assignments and
identity new audit areas. Overall, the Audit Committee appreciated the
efforts of David and his team. Source
: The Bombay Chartered Accountants Society |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
Rewards waiting for feedback at |
|
|
|
|
|
|
|
||
|
|
|
|
|
|
Disclaimer: We believe that the information contained in this e-zine is true. If you do not wish to receive Smart Trainee please click here. |
|
|
|
||
|
|
|
|
|
|
Click here to contact us, if you are unable to view the content properly |
|
|
|
|
|
