How do auditors audit financial data and related management data with theuse of IT?

1Executive summary

The Commission of Audit of Macao S.A.R. (“the Commission”) intends to propose a uniform data interface for financial systems and management systems of all auditees so that data can be exported in required format, and ultimately connected to a network, so that the Commission can access the required on-line. To put the ideas into practice, lot of effort will be needed and lot of issues including technical, security, administrative, and political issues have to be ironed out. The question is, does it worth to do so? Should we carefully consider all the procedures and relevant obstacles that we have to go through, we shall see significant benefits from the implementation of the above idea.

Well, when it comes across the issue of computer audit, people normally focus on what auditors can do with the use of IT, from reprocessing of the data to more sophisticated modeling or relation database, and seldom discuss about what auditors “can’t” with the use of IT.

There are two major types of technical obstacles that make computer audit unfeasible and should be considered in the very first instance. The first obstacle is “Required data cannot be obtained”, which is affected by the systems auditees chosen to use, the availability of right IT people in the auditees, availability of good system documentations, availability of source code etc. The second obstacle is “Data integrity of data does not meets the audit requirements”, including how the data was captured, stored and delivered to the hands of auditors, which without due considerations, auditors may end up wasting lots of resources for worthless results. This is the main issue, which the Commission intends to solve with through the implementation of the above idea.

Back to “what auditors can do with the use of IT”, at the resent moment, the fundamental audit methodologies remained the same whether manual audit or computer audit. The only difference is that with the used of nowadays advance IT certain methodologies have become more cost effective and even feasible and thus new options are made available.

Thus, in respect of auditing electronic data in Macao and many other places, there may be more structural problems that cannot be solved in the short run than what people normally taken for granted, and one of the ways the Commission proposed to cut down these obstacles is to standardize the systems and to improve the system environments.

2Introduction

2.1Scope of discussion

The sub-theme “How do auditors audit financial data and related management data with theuse of IT” can be separated into two aspects: “The audit of non-electronic data with the use of IT” and “The audit of electronic data with the use of IT”. To simplify, this paper will discuss only on the audit of electronic data with the use of IT, which represents the most commonly faced aspect and also more cost effective in nature.

Also, the scope is limited to the audit of data but not the system itself as this subject will be covered under another sub-theme.

The audit of electronic data can further be diagnosed into a chain of small procedures or points as listed below, beginning with “The availability of electronic data” and end with “Whether the findings can be served as legitimate and effective audit evidence”.

(i)The availability of electronic data;

(ii)Identify data that can be provided by the system;

(iii)Clarify the definitions of data, which we are interested and can be provided by the system;

(iv)Verify data integrity;

(v)Select method of accessing/obtaining target data;

(vi)Design and implement audit approach; and

(vii)Whether the findings can be served as legitimate and effective audit evidence.

However, in this paper, we are going to concentrate on the procedures or points between the beginning and the end of the chain rather than the beginning and the end themselves. This is simply because “The availability of electronic data” is much subject to the degree of computerization of the auditees as well as what sort of data they have decided to keep, rather than something that the auditors can have much control on, at least in the short and medium run.

At the other end of the chain, the legitimacy of electronic evidence may varies depends on the legislations from countries to countries and will only concern us, as supreme audit institutions, should we plan to bring the case to the court. Whereas in the real practice and in the vast majority of our audits, we are only required to present to the management of the auditees, or their supervisory bodies, that firstly, our observations are nothing but the fact and secondly, our conclusions and opinions are fair and appropriate. Besides usually, more effort and concern are demanded to persuade the management to correct or improve accordingly.

Thus, point (ii) to point (v) are grouped under the key point “What procedures and methods do auditors adopt to access the financial system or management system for data to be audited” and point (vi) is put under the key point “What methods do auditors use in data examination” that are provided in the Guide on Preparation of Papers.

2.2Objective

The objective of this paper is not to study all concerns, obstacles, and solutions in respect of the subject, as in practice there are so many factors to be considered, so many possibilities in respect of the situations and the IT itself just advances every day. This paper only cover main application concerns of the subject and the examples of obstacles, solutions and audit approaches will only be served as demonstration of the concept or pointers to the direction for further studies and considerations.

3What procedures and methods do auditors adopt to access the financial system or management system for data to be audited

3.1Present situation in Macao

Just before analyzing the procedures and methods to be adopted, I would like to briefly introduce to all of us, the present situation in Macao. All the auditees are medium, small or tiny in size. In terms of financial system, roughly 70% of the auditees have been computerized; in terms of operation or management system, roughly 60% of the auditees have been computerized. Among those that have computerized, vast majority of the systems do not have proper system documentations, quite some of the programmers who wrote the application systems have been located to other governmental departments, a few of the auditees have the system development out-sourced and some of the auditees do not have the source codes.

These have created some difficulties for computer audit and the obstacles will be analyzed in the following starting from 3.2.

Despites of the above problems, there are some achievements recent years by setting up an electronic data interchange (EDI) system connecting among different departments including custom, The Economic Services (for import/export documents and certificate of origin) and The Statistics and Census Services, that allows these departments to process the transaction and update records on-line.

3.2Main concerns

To access system for data simply means to obtain required data from the system. As suggested in the above, the whole process may include (1) Identify data that can be provided by the system(s); (2) Clarify precise definitions of data, which we are interested and can be provided by the system(s); (3) Verify data integrity; and finally (4) Select method of accessing/obtaining target data. These four steps may sound simple and straight forward, but should we really pay attention on when we carry out these procedures? Or put it in order words, what are the main concerns behind these?

Well, let us see if we can have a better view of the picture if we stand a step backward. In this case, I suggest that we can consider whether we should audit the data with the use of IT in the very first instance. To accomplish this, we have to consider (a) the cost effectiveness; (b) the technical feasibility; and (c) the ability of producing effective audit evidence, in respect of the adoption of the audit approach in concern.

The estimation of direct costs involved is subject to the results of the study on “How we are going to access and examine the data”. The direct and indirect benefits of the audit may not be easily quantified at this stage and it highly depends on the expected findings as well as the importance of the subject, which are quite subjective, or shall we say judgmental, in practice. As the components of the analysis of cost effectiveness are either a dependent of or irrelevant to “How we are going to obtain the data from the system”, this will not affect our study of the subject and thus, “technical feasibility” and “Ability to produce effective audit evidence” should be the only two main concerns.

3.3Step One - Identify data that can be provided by the system

The main objective of this step is to identify relevant data not only contained in the system, but those that can also be provided or generated by the system.

This may look very simple at the first glance, as we are only required to shave a brief understanding of the system, search for data that we are interested and consider whether the data can be exported by the system. In an ideal world situation, we will meet someone who has a thorough understanding of the system, including the database of course, who can tailor made and provide you with all data required even though the original application cannot do so, and who is very cooperative and understand what we say as well. Then objective can be easily accomplished.

Of course, there will be no need to discuss about the technical feasibility if there are no technical obstacles at all. Let us imagine ourselves in the situation where there is someone who just know how to operate a small part of the system, there is no operation menu or any system documentations, the system cannot generate and export the data that you required, the programmer who wrote the application is either unknown or not contactable, no source code is available, the database has a complicated structure yet the structure is not disclosed, and the worst is, the database is encrypted and no one know how to decrypt the database. Should we find ourselves in such situation, that is hardly anything we can do except for giving up.

In the real world, we are more like to find ourselves in the situation where we may encounter one or few of the above obstacles rather than the two extreme. Accordingly, we are going to cover the some of the main situations in the following.

3.3.1Situation One – Need to study the data contained in the database

The circumstance

There is no one who can tell whether all data that we required are contained inside the database and at the same time, system menu is not available. One of the usual examples will be the case where the auditee has developed their own system, current users of the system are only familiar with their own areas, which some of the functions and report have never been used or generated by these users, the person who developed the system is not anymore with the auditee and leaving only little or no documentation about the system.

The study

The study may need to identify all data inputted into the system, including direct access to the database and search for data inside the database besides the usual studies of all enquiry and report generating functions inside the application program. The study of inputted data will be a good start should the studies of all enquiry and report generating functions and relevant output do not satisfy us, as generally, the database should contained except for data generated based on the processing of inputted data. One thing that needed to be double check to the database not to be taken for granted is that not all inputted data will be stored in the database as application program will not keep the transaction records after processing.

The results of the study should be able to tell us what data is stored inside the database and what data can be provided to us in the existing application program. Should the existing application program cannot generate electronic data in required format, even if relevant data available from the database, the process has to go Situation Two or Situation Three to complete.

3.3.2Situation Two – Need to edit existing application program to generate electronic data in a required format

The circumstance

This is a typical situation where the auditors have easily identified data contained in the system yet the existing application program cannot generate electronic data in required format, provided if the system does contain data that is needed by us. In some cases, the application program can only generate all or part of the data in few or more tables, which sufficient link between the records of the tables is not available, instead of a single table that we required. In other cases, the application program is able to generate data in required format, however, the program can only print the data but not able to “export” the data in electronic format.

At this stage, we are only interested to find out whether this can be done, as we need to confirm the feasibility of the audit approach, prior to the production of all sorts of required data files.

Pre-conditions

Of course, this can be done provided if: source code is available; there is a programmer who understands the system and what we need; and we (including the auditees) are able to meet the time and financial constraints as longer time may be needed and extra costs required, especially when external software house is involved.

In this situation, whether the data is encrypted or not will not be the concern.

3.3.3Situation Three – Directly access the database without the use of existing application program

The circumstance and pre-conditions

Both the circumstance and pre-conditions are similar to Situation Two except that the database is not encrypted or there is someone who is able to decrypt the database. In such a case, this is only an alternative to Situation Two and normally adopted when it is considered more efficient to write new and small program or use other software to directly extract data from the system rather than editing existing program. Of course, should the source code is not available, there leaves only one choice.

Unavailability of source code and the architecture of the database

In addition, should the source code is not available and should the programmer or IT guy involved is not familiar with the relationship within the database, or say, does not know how the data were stored in the first instance, this may be a difficult task and much time has to be spent to figure out the architecture of the database (structure and the relationship inside the database). In practice, database may be made up of more than a hundred tables and data we required is widely spread among the different tables and mixing with data that is not required or even unknown. The task indeed sounds more like playing “Master Mind”, only with more parameters and possibilities in hands.

Same as Situation Two, at this stage, we are only interested to find out whether this can be done, as we need to confirm the feasibility of the audit approach, prior to the production of all sorts of required data files.

3.4Step Two - Clarify the definitions of data, which we are interested and can be provided by the system

Main concern

The objective of this step is to confirm the precise definition of the target data, i.e. to know precisely what it means, prior to the confirmation of the feasibility of the audit approach. Normally, one of the aspects that would affect the definition most is “how” the data was capture, including how the data was processed before it was stored in the current stage.

In practice, this step can be performed simultaneously with Step One, during the study of what is stored inside the database.

This is much to the details but crucial, especially for certain critical data, as it will be risky to start the audit work, taken for granted that the data should mean what it supposed to be or what it appear to be, and ending up declaring the audit approach is not feasible or the results is misleading and creating a lot of embarrassment, after valuable time and resources on the work.

Example

For example, in a regulatory compliances audit, it is required to check that certain procedures were completed prior to the approval of a particular type of expenditures. A data file containing records of details of roughly sixty thousand relevant expenditures approved during the year together with other data files containing the time of completing relevant procedures for different projects were generated after tremendous effort has been spent on works described in Situation Two. Then, cross-matches had been performed comparing data field “date of approval” (of projects) with data field “date of completion” (of procedures) and a list of roughly nine thousand cases of non-compliance has been generated.