Trend analysis

Audit Technology and Data Analytics

Analytics can test a whole population rather than a sample. It still tests only what was recorded, and the extract itself must first be proved complete.

Data analytics has changed how audit evidence is obtained. Where sampling once tested a selection of transactions, software can now interrogate an entire population. That is a real advance in coverage. It is not a change in what an audit is for, in the auditor's responsibilities, or in the standard of evidence required — and management that understands the distinction gets more out of the audit and spends less time in it.

What the current standards require

It helps to be precise about what is already mandatory, because much of what is presented as innovation is the application of long-standing requirements using current tools.

The Malaysian Institute of Accountants adopts International Standards on Auditing as issued by the IAASB, and its published register records each standard and its effective date. Three are directly relevant here.

  • ISA 240 requires the auditor to test the appropriateness of journal entries and other adjustments made in preparing the financial statements. That requirement applies irrespective of the auditor's assessment of the risk of management override; it is not a procedure that can be reasoned away. Analytics is a means of discharging it more completely, not the reason it is performed.
  • ISA 315 (Revised 2019), effective for audits of financial statements for periods beginning on or after 15 December 2021, requires the auditor to understand the entity's information system, including the IT environment, and to identify risks arising from the entity's use of IT and the related general IT controls. An entity's systems are therefore in scope whether or not analytics is applied to them.
  • ISA 500 requires the auditor to consider the relevance and reliability of information used as audit evidence, including information produced by the entity. A data extract is exactly that kind of information.

None of this is new, and none of it is optional. What analytics changes is the practicable scope of the work, not its foundation.

Full-population testing changes the questions, not the burden of proof

Testing every journal entry rather than a sample means exceptions are identified more completely. It does not mean every exception is an error.

The practical consequence for management is that queries may be more numerous and more specific than in previous years: unusual posting times, round-sum entries, postings by unexpected users, entries with blank or generic descriptions, transactions recorded just before or just after a period end, and entries reversed shortly afterwards. Most will have ordinary explanations — a system default, a year-end accrual, a correction, one person covering for another.

What matters is being able to give those explanations with contemporaneous evidence. An entity whose records support a clear answer resolves such queries in an exchange or two. One that cannot spends the audit reconstructing them, usually at the point in the timetable when it can least afford to.

It is also worth understanding what an exception is. The auditor sets criteria that flag items with a particular characteristic, and a flag is a prompt for enquiry rather than a finding. A large exception count is not itself evidence of a weak control environment, and a small one is not evidence of a sound one. The informative figures are how many required follow-up and what that follow-up established.

Analytics tests the record, and the record itself must be proved

This limitation tends to be lost when the technique is described enthusiastically.

Analytics examines what was recorded. It cannot confirm that recorded inventory exists, that a customer is a real party, that goods were received, or that a contract says what the entry assumes. Physical verification, external confirmation, inspection of documents and enquiry of people outside the finance function remain necessary. A transaction that is perfectly consistent within the ledger may be wholly unsupported outside it — internal consistency is precisely what a fabricated entry is constructed to achieve.

Nor can analytics supply the professional judgement that determines whether an exception matters. Judgements about materiality, about whether an explanation is plausible, and about whether a pattern points to something the entity has not disclosed belong to the auditor and cannot be delegated to a tool.

A further point often catches management unprepared: the extract itself is subject to audit judgement. Before any analysis carries weight, the auditor has to establish that the data extracted is complete and accurate — that it reconciles to the trial balance, that no ledger, period, entity or entry type has been omitted, and that the extraction did not transform the data on the way out. Where completeness cannot be established, the analysis carries correspondingly less weight and other procedures have to fill the gap. That is why an extract request which looks purely administrative is not, and why sending a partial file to save time creates work rather than saving it.

Data quality on the entity's side determines whether it works

Analytics depends on the consistency of the underlying records. Where a chart of accounts has been restructured part-way through the year, where material adjustments are prepared on spreadsheets outside the system and posted as single unexplained totals, where descriptions are inconsistent or absent, or where several people share a posting login, the analysis is limited and the audit falls back on other procedures.

This is a reason for management to care about master data discipline for its own sake. The qualities that make a ledger analysable — consistent coding, individual user accounts, descriptions that mean something, adjustments recorded with their basis — are the same qualities that make internal reporting reliable during the year. The audit benefit is a by-product of running the finance function properly, which is the right order of priority.

A scheduled change worth knowing about

One development is concrete rather than speculative, and management with December year ends should note the timing.

MIA's register records ISA 240 (Revised), issued in July 2025, as effective for audits of financial statements for periods beginning on or after 15 December 2026. It revises the auditor's responsibilities relating to fraud, including the emphasis given to the use of automated tools and techniques in testing journal entries and in evaluating accounting estimates for indicators of management bias.

Two practical implications follow. The direction of travel is towards more, and more specific, enquiry about journals and estimates rather than less. And the assumptions underlying accounting estimates will bear closer scrutiny, so the basis for each is better documented when the estimate is made than when it is challenged. Confirm the requirements applying to a particular period against MIA's own published standards, since effective dates and their scope are where planning errors usually originate.

The firm's quality management and confidentiality obligations apply

Where an audit firm uses analytics, its system of quality management under ISQM 1 — effective from 15 December 2022 — extends to the technological and intellectual resources the firm relies upon and to the appropriateness of the outputs obtained from them. The tool forms part of the engagement's evidence chain and is treated accordingly.

Client data extracted for analysis attracts the same confidentiality obligations under the MIA By-Laws as any other client information. Where an extract contains personal data — payroll records, customer or employee details — obligations under the Personal Data Protection Act 2010 rest with the organisation holding that data and are not displaced because it was provided to an auditor. It is reasonable, and useful, for management to establish at planning stage how extracted data will be transferred, where it will be held, who will have access to it, and when it will be disposed of.

What this does not require management to buy

Analytics is a technique applied within an audit, not a product management needs to procure, and several things follow from that.

Management does not need analytics software of its own to be audited well. An entity with a modest transaction volume, consistent coding and few manual journals may face very few queries and need nothing beyond its ordinary records. Where the finance team can already explain its own postings, no additional support is warranted.

Nor is a separate pre-audit readiness engagement a general requirement. Where records are in reasonable order, the more effective and cheaper response is internal: tighten the chart of accounts, stop posting adjustments as unexplained totals, give each person an individual login, and retain the working papers behind estimates as they are prepared. Those steps cost management time rather than fees, and they address the cause rather than the symptom.

Whether an entity requires a statutory audit at all is a separate question, and it is not determined solely by company law. Lenders, grant conditions, shareholder or joint-venture agreements, regulators, tender requirements and counterparties may each call for audited financial statements. The statutory position should be checked against SSM's own current guidance against the company's own circumstances.

Questions to ask, and what to have ready

Where analytics forms part of the audit approach, useful questions for management and those charged with governance include which populations were tested in full rather than sampled; what data was extracted and how its completeness was established; what the exception criteria were and how many exceptions required follow-up; and what analytics could not address, so remained subject to other procedures. The last of these is the most informative and the least often asked.

On the entity's side:

  1. Maintain consistent coding and chart-of-accounts discipline through the year, and avoid restructuring mid-period without a mapping.
  2. Record manual adjustments in the system, with a description and a reference to the supporting working, rather than outside it.
  3. Use individual user accounts for posting and approval so that entries can be attributed.
  4. Document the basis for each accounting estimate at the time it is made.
  5. Agree the data extract specification early, and reconcile the extract to the trial balance before sending it.
  6. Establish how extracted data will be transferred, stored, accessed and disposed of.
  7. Treat recurring exception themes as internal control information for the coming year, not merely as audit queries to close.

General-information limitation

This article is general information, not audit advice for a particular entity, and it does not determine the audit approach, procedures, evidence or conclusions appropriate to any engagement, nor whether any entity requires an audit. Effective dates and requirements should be confirmed against MIA's own published standards for the period concerned. Obtain fact-specific advice where the matter is material.

To discuss your circumstances, contact Saifudin & Co.

Related service

START WITH SCOPE

Define the requirement before the work begins.

Tell us the entity, reporting period, applicable requirement and intended use. We will confirm fit, scope and the next evidence needed.

Discuss the engagement