ASSURANCE APPROACH AND

SOFTWARE TOOLS
AUDIT WORK ON INFORMATION PRODUCED BY THE
ENTITY

JANUARY 2016 / ISSUE 05 - FOR INTERNAL USE ONLY

Introduction
ISA 500, para. 9 states, “When using information produced by the entity [(IPE) as audit evidence during the execution phases of the
audit], the auditor shall evaluate whether the information is sufficiently reliable for the auditor’s purposes, including, as necessary in the
circumstances:
a. Obtaining audit evidence about the accuracy and completeness of the information; and
b. Evaluating whether the information is sufficiently precise and detailed for the auditor’s purposes.”

All IPE used as audit evidence is to be documented and evaluated. The documentation will include identification of the procedures
the particular IPE will be used in, related IT systems and approach to assessing the reliability of the IPE (whether testing controls or
substantively) and is to be completed regardless of the audit phase during which the IPE is identified and received.
This guidance focuses on approaches to gaining assurance over the reliability of system-generated IPE. Other procedures may be
performed over other types of IPE.
The amount of testing required to assess whether the IPE is ‘sufficiently reliable’ depends on two main factors:
1. Assurance planned from the audit procedure in which the IPE is being used; and
2. The IPE’s inherent reliability based on its characteristics.

At least a minimal level of work has to be performed for any IPE used as audit evidence.
The amount of assurance we plan to obtain from an audit test that uses the IPE, combined with the inherent reliability of the IPE that
we are using, will impact how much testing we consider necessary to perform on the IPE to evaluate whether it is sufficiently reliable
for our purposes.
H

H
Amount of IPE Testing to be Performed

Amount of IPE Testing to be Performed

Minimal Procedures Minimal Procedures

L
L

L Assurance Planned from Audit Procedure H H Inherent Reliability of IPE L

 2

Examples of minimal procedures that could be performed for system generated IPE may include the following (if appropriate):
• Completeness checks (agreeing to other reports / support; ensuring rows / columns / sheets are not missing);
• Observe IPE production or reproduce the IPE to ensure the report mechanics work and that the relevant data has been captured in
the report;
• Review selection criteria used to produce the report (to verify that the relevant accounting period, date and population were used);
• Compare IPE to the previous year (by inquiry or by comparison to the previous year’s received report);
• Perform recalculations (of the report as a whole or of a sample of relevant fields);
• Review system reliability checks / reports.
For example, when IPE is a standard report from an off-the-shelf application, appropriate testing of the reliability of the IPE may be to
perform a completeness check and reproduce the IPE ourselves.
For assessing the amount of assurance planned for the audit procedure that uses the IPE, the relevant R factor or assurance to be
obtained from the procedure is needed.
For example, where IPE is used in an Other Substantive Procedure (OSP), the amount of assurance obtained from that OSP can vary,
thus influencing the level of reliability needed from the IPE. If the FSA and assertion have a Significant RMM Level, and no other
procedures are planned for that FSA and assertion other than the OSP which uses the IPE, then the planned assurance level from that
OSP is 3.0. In contrast, if Tests of Controls (TOCs) or Substantive Analytical Procedures (SAPs) are planned to achieve an assurance
level of 2.0 on that FSA and assertion, then the assurance required from the OSP that uses the IPE is 1.0. The higher the assurance we
want to obtain from the test, the more reliable IPE needs to be.

Characteristics that Influence the Inherent Reliability of IPE

i. Nature of the System Used to Generate the IPE
(‘Off the Shelf’, ‘Customised’ or ‘Bespoke Systems’)
The inherent reliability of the IPE is higher if the application used to produce the IPE was developed in a more standard and
controlled environment with few client specific updates (e.g. off the shelf software); the inherent reliability of the IPE decreases
if the application was developed in a highly customised environment.
ii. Type or Source of the Report
The reliability of IPE decreases if the report includes more specially tailored development and configuration characteristics:

• Standard report - a built in report produced from a commercial off-the-shelf application that end users cannot
change or customise;
Reducing IPE
Reliability

• Vendor customised report - a report from a commercial off-the-shelf application that was customised specially
for the client (e.g., fields were added / removed, value lists populated);
• Client customised report - a custom built report according to user predefined requirements; or
• User customised report - Reports produced by the client using Report Writing and Design Tools or Query
Language (e.g., SQL queries).

iii. Report Complexity

A simple report that merely presents a general overview of the data in the system (e.g., accounts receivable listing) has a
relatively high inherent reliability. More complex system-generated reports (e.g., forecast reports, exception reports, margin
analysis, aging analysis, inventory movements) that are dependent on both logic within the system and logic in the report (that
may override logic in the system) would typically lead us to conclude that these reports have a lower reliability profile.
iv. Fraud Risk Affecting IPE
When there are no fraud risks affecting the generation of IPE, it has higher inherent reliability. If fraud risks are identified that
may affect the underlying data or report, IPE has less inherent reliability.
v. Competence and integrity of individuals responsible for the input, maintenance or provision of IPE
Reliability of IPE decreases if it is prepared by staff with lower competence or integrity.
vi. IT General Controls (ITGCs)
If an assessment of Relevant ITGCs (RITGCs) is performed, deficiencies in the design and implementation of those RITGCs need
to be considered in assessing the reliability of impacted IPE and in designing additional procedures to assess that reliability. Such
deficiencies may directly influence the completeness and accuracy of system produced information, as they are addressing the
integrity of data and report production as well as interfaces operating between systems.
Where RITGCs are not identified and / or evaluated, the procedures performed to evaluate the reliability of IPE would be based
upon substantive procedures and would not consider the entity’s ITGCs over such system-generated IPE to reduce the extent of
substantive procedures performed on the reliability of IPE.
 3

vii. Experience of Prior Audits

When the same IPE is used during each year’s financial statement audit, when planning our work in this area during the current
period’s audit, the audit team would consider its conclusions regarding reliability over the IPE from prior periods. Note that the
team cannot rely solely on work done on IPE in prior periods, but it can use the results of prior period testing to help determine
the nature and extent of the current period’s work.
In each case, as the inherent reliability of the IPE decreases, the amount of work to test the reliability of the IPE increases.
Nature of Tests over IPE Reliability
In many cases, it will be most efficient to test the reliability of IPE substantively. However, there may be some instances where this is
not possible, for example when there is a lack of visible audit trail over the transactions; in such cases, ITGCs and application controls
relating to the IPE must be tested.
Where additional procedures over and above the minimal testing have to be performed in order to assess IPE reliability, the following
procedures can be considered:
Some level of
TOCs work must be
performed
a. ITGCs relevant to the production of IPE and management of the underlying data included in IPE.
b. Controls designed to maintain appropriate segregation of duties over the performance of sensitive system transactions, such as
manual posting of journal entries, financial period maintenance, general ledger accounts maintenance and others that might
influence the financial records completeness, accuracy and validity.
c. Controls over the output - designed to validate report completeness and accuracy. Such controls may include reviews and
reconciliations.
d. Automated application controls over data input and processing.
When taking a TOCs approach to testing the reliability of IPE, we would typically also perform some substantive work to ensure
that the data underlying the report is reliable. In many cases, this would be covered by other substantive audit tests already being
performed (for example, substantive tests on sales or receivables that are already planned would give us some assurance that the data
underlying an accounts receivable aging report is valid). However, in other cases, additional substantive work may be necessary if no
other substantive tests addressing the reliability of the data underlying the report have been performed (e.g. a gross margin report on
data subsequent to year end that has not been tested at all). In such cases, it may be more efficient to test the reliability of this IPE
substantively.
OSPs
a. Manually sample and test a number of transactions that are expected to be included in the report back to underlying data.
b. Perform recalculations (of the report as a whole or of a sample of relevant fields) and review the Excel formulas in use, where
applicable.
c. Agree data to information sources that are external to the system that produces and manages them, this may include:
i. Agreeing the report / data against external balance confirmations.
ii. Comparing reports and data against operational data managed in a separate system.
iii. Tracing a sample of transactions to and from original source documents.
d. Determine whether the report logic has changed compared to last year (if, in the prior year, the reliability of the report has already
been determined). Specifically address whether all relevant information is included in the report logic, and whether any specific
data categories are excluded from the report logic.
e. Check the source data, perform completeness and exception checks and re-perform the logic applied to generate a report. The use
of CAATS may require the involvement of an IS Audit Specialist to assist with:
i. Calculation tests.
ii. Completeness tests (such as gap analysis, duplicates, sequence validations).
iii. Exceptions checks (such as null or blank data fields, illogical values).
iv. Verifying data used for calculations, against standing data or outside sources.
v. Report simulation.
f. For IPE with a high risk of being unreliable, the audit team may consider performing the following procedures (these procedures
may require the involvement of an IS Audit Specialist):
i. Development process - For newly developed reports, or reports derived from newly developed systems, or special purpose
reports designed specifically for the audit, assess the report development process, including user requests, parameters and the
appropriateness of user acceptance tests.
ii. Parallel run - Reports that provide simulations and forecasts designed for planning and preparation of financial estimates can
be tested by re-running the model that provides the report based on actual data or by a parallel run in a similar system (if
available).
 4

iii. Test data - input test transactions or data for which we can predict the outcome and match this to the actual report (e.g. by
creating exceptions that should be captured in an exception report).
iv. Code review of report queries to analyse the report logic and other parameters.
To assist audit teams in summarising IPE used as audit evidence, an optional form was provided in the October 2015 APT
library (document 3.01.02, Summary of Information Produced by the Entity)(APT BDO World pages). Work performed to assess the
reliability of the IPE is documented in appropriate places in the CAW and cross-referenced to this summary. A link of this optional
form is provided for your convenience.

CONTACT
Questions related to this publication are to be directed to your Regional Audit Adviser (RAA) or submitted via email to
audit@bdo.global.

ASSURANCE APPROACH AND SOFTWARE TOOLS

Assurance approach and software tools are issued by the Global Assurance Department and distributed to the International A&A
Coordinators and APT Champions.

© Brussels Worldwide Services BVBA