Data Analytics in Internal Audit: Organisational Role and Applications

The most concrete expression of data analytics in internal audit lies in these areas. What the controls below have in common is that none of them can be detected by reviewing documents within any reasonable timeframe. All of them are detected in minutes with data.

Segregation of duties violations

Segregation of duties simply means this: The person requesting a payment and the person approving it must not be the same. The same user opening a supplier record and then approving payment against it is the classic breach of that principle.

The problem is usually not that the authorisation matrix is badly designed. On paper the matrix is correct; the violation arises through temporary permissions, delegation arrangements, and roles or duties left open after someone leaves. An audit that looks at the authorisation table cannot see this.

The analytical approach intersects the authorisation table with transaction logs. The question asked is not “who has permission” but “who actually did what”. The gap between those two answers is, in most companies, where nobody is looking.

Duplicate and erroneous payments

The same invoice number recorded under different supplier codes, the same amount on different dates, the same IBAN under different account names. Scanned across the full population using fuzzy matching — because records are rarely identical.

This is usually not a fraud finding but a process and master data quality finding. Because the cash impact is direct, it is the area where management acts fastest, and it is generally where an analytics programme produces its first concrete return.

The source of these findings is often the data itself. Multiple records opened for the same customer, supplier or stock item are both the cause and the indicator of duplicate payment. Before data analytics can be applied, the data must be cleaned and made fit for testing; this is not a step that can be squeezed inside the analytics work, but a separate exercise requiring specialist effort.

Approval limits circumvented by split orders

If the approval limit is TRY 100,000, a TRY 180,000 requirement can be pushed through as two separate TRY 90,000 orders to the same supplier on the same day. Each order complies with the rules individually. The violation is visible only when they are viewed together.

The analytics: clustering by supplier–date–amount, and examining the amount distribution around approval thresholds. Abnormal clustering just below a threshold is a strong indicator on its own, and usually points to a control design problem.

Source: Teolupus

Dealer and franchise network audits

On-site auditing across a geographically distributed dealer network is expensive and sampling-based by nature. Comparative analysis by dealer of revenue declarations, stock turnover, return rates and discount usage directs the on-site team to dealers selected by data. Audit cost falls; hit rate rises.

Benford analysis — and its limits

Benford’s Law rests on the observation that in naturally occurring number sets, the distribution of leading digits follows a particular pattern. Deviation is a signal of an anomaly worth investigating.

It is worth being honest here: Benford analysis does not detect fraud, it flags anomalies requiring investigation. Non-conformity has innocent explanations — price thresholds, rounding policies, approval limits. Conformity, meanwhile, does not prove the absence of fraud.

EXPERT NOTE

Benford analysis cannot be applied to every data set, and misapplied it damages the credibility of the internal audit report.

Volume: ISACA recommends 1,000 records or more for a reliable result; below roughly 500 records the false-positive rate rises to an unusable level.

Data it does not apply to: values generated by formula or assignment (invoice numbers, account codes, sequence numbers), values bounded by a floor or ceiling (hourly wages), and values concentrated in a narrow band. The data must span several orders of magnitude.

Choice of test: the widespread use of the chi-square test in this field is criticised for its excessive sensitivity to sample size; the SSD (Sum of Squared Deviations) measure is preferable (Kossovsky, Stats, 2021).

Benford appears in no IIA standard. It should be presented as “a widely accepted analytical technique”, not as “the method the standards prescribe”.

Let us follow how a single analytical test works within the purchasing process at a mid-sized packaging manufacturer. (The scenario below is an anonymised composite drawn from several projects.)

Question: Are the approval limits actually working? This example shows how data analytics operates within a single test.

Data: 14 months of purchase orders — approximately 31,000 rows. Fields extracted: order number, date, supplier code, amount, requester, approver, approval date.

Test: Examination of the amount distribution around approval thresholds; then identification of order groups placed with the same supplier within 72 hours whose combined total exceeds the next threshold.

First run: 240 flagged groups. Most turn out to be legitimate — recurring orders under framework agreements, same-day line-item splits.

Calibration: Suppliers under framework contracts and stock replenishment orders are excluded. The flagged group count falls to 19.

Finding: 11 of the 19 groups concentrate in a single purchasing officer and four suppliers. The root cause is not fraud but a control design gap: the system does not aggregate orders placed with the same supplier at short intervals, so the threshold effectively operates per order rather than per person.

Action: A cumulative threshold control is defined in the ERP. Audit converts the rule into an indicator to be run monthly.

The point this example makes is this: the value analytics produces lies not in the fraud it catches but in making an invisible control design error visible. Fraud findings are the exception; design errors are the rule.

This distinction is the one most often confused, and it is decisive from a governance perspective.

Continuous monitoring is management’s responsibility. It is the control itself; it is established and operated by the unit that runs the process. In the Three Lines Model it is the work of the first and second lines.

Continuous auditing is internal audit’s responsibility. It independently tests whether management’s controls are working. It is the work of the third line.

The mistake in practice arises like this: Internal audit establishes an analytical rule set, reports the findings to management, and over time operating that rule set becomes audit’s routine task. At that point internal audit ends up auditing a control it built itself, and loses its independence.

This distinction bears directly on how the enterprise risk management structure is built. The correct arrangement has three steps: Internal audit develops the rule, proves its effectiveness, and hands operational running to the relevant unit. Audit returns to testing that the rule is being operated. Every continuous auditing programme established without that handover turns into an independence problem within a few years.

EXPERT NOTE

The Three Lines Model terminology has been updated. The IIA dropped the phrase “lines of defence” in 2020. The 2020 document is itself no longer current: on 8 July 2026 the IIA published a new Statement of Position on the Three Lines Model, replacing the earlier text. The new text identifies the board as its primary audience. A position statement on internal audit’s role in enterprise risk management was renewed on the same date.

On the control framework side there are two separate references. COSO Internal Control — Integrated Framework (2013) comprises five components and 17 principles. COSO Enterprise Risk Management — Integrating with Strategy and Performance (2017) contains five components and 20 principles. The component lists must not be merged. The 2017 text is not titled Integrated Framework; that title belongs to the 2004 version.

The raw material of data analytics sits in the ERP. That has two consequences.

First, master data quality sets the ceiling for analytics. If the same firm is recorded under four different codes in the supplier master data, duplicate payment analysis will not work. The realistic first phase of an analytics project is not building a model but mapping master data and processes. Projects that skip this phase produce outputs that are technically correct and operationally meaningless.

Second, ERP implementation and migration projects are the cheapest moment to embed controls. If the authorisation matrix, approval hierarchy, mandatory field definitions and logging policy are designed during rollout, the cost is low. When the same controls are added later to a live system, the cost of process change and user resistance is added on top.

In Türkiye, ERP projects carry an additional compliance dimension. The e-Transformation applications — e-Invoice, e-Archive, e-Waybill, e-Ledger — directly shape system design under Revenue Administration requirements and leave an auditable trail. That trail is a ready-made data source for analytics.

For this reason, having the internal audit perspective at the table at the start of an ERP project (a migration to a new ERP, a version upgrade on an existing one) is markedly more economical than a compliance exercise carried out afterwards.

Why data gets dirty: master data ownership

Dirty data is not the result of carelessness. It is the result of authorisation design.

In most companies no master data owner is defined. The rights to open accounts, create records and change definitions are distributed across different people and different departments, operating independently of one another. The result is multiple records opened for the same customer, supplier or stock item — and this picture is not the exception but the norm.

Data cleansing is therefore not a step that can be dissolved into an analytics project; it is a separate, careful exercise requiring specialist expertise. Nor is it sufficient on its own: mechanisms preventing the data from becoming contaminated again must be established and actually operating. Without those mechanisms, the same cleansing exercise is repeated two years later.

Source: Teolupus

A manager does not need to go into technical detail to decide on a data analytics programme. But four questions do need answering.

How will the data come out?

There are three routes, and their costs differ. Manual export is cheapest and least repeatable — every run requires human intervention. Scheduled report output is the middle path; it produces periodic files through the ERP’s own reporting layer. A direct database connection or API is the cleanest, but requires authorisation and security work on the IT side.

The decision criterion is this: Will the analytics run once a year, or produce a monthly indicator? If monthly, manual export becomes unsustainable quickly. Or will some data need to run weekly, daily or in real time?

Which tool category?

There are three categories, and the choice depends on the company’s maturity.

Source: TeoLupus

The common mistake is starting with the third category. When the software is bought the rule set does not yet exist, and the licence sits unused. That said, with the right outsourcing arrangement the picture can improve considerably. TeoLupus’s data analytics, artificial intelligence and autonomous artificial intelligence services in this field offer value-adding solutions for your organisation.

Build, buy, or co-source?

This is a headcount decision, not a technology decision. A company building in-house must hire and retain someone with an audit data analyst profile. In a mid-sized company that role usually does not run at full capacity.

The co-source model solves this: methodology and rule set are established externally, while operation stays in-house. Knowledge transfer is part of the project’s output.

What determines the cost?

Not the complexity of the analytics, but the state of the data. The three main factors that extend a project are: data access being queued on the IT side, master data disorder, and the absence of process documentation. Writing rules is measured in days; making data reliable is measured in weeks.

For that reason, the right question when evaluating a proposal is not “how many tests will be performed” but “is data quality validation in scope”.

EXPERT NOTE

For analytics output to qualify as audit evidence, it must be repeatable. In practice that means: the extraction query, the filters applied, the exclusion rules and the transformation steps must be recorded in the working papers; the same input must reproduce the same output.

Evidence of reconciliation between the source data and the ERP must also be on file — at the level of row counts, period totals and critical field totals. Without that evidence, the origin of the finding is open to challenge.

Version control of the rule set matters separately: when a rule is calibrated, it must remain traceable which version produced the findings of a prior period. A rule set without version tracking invalidates period-on-period comparison.

Data analytics programmes progress through roughly four levels. Knowing which level a company occupies allows it to set a realistic target.

Level 1 — On demand. Analytics is performed once, for a specific audit engagement. The rule set is not permanent; the output is person-dependent.

Level 2 — Repeatable. Rules are documented, run periodically, and results are comparable across periods.

Level 3 — Integrated. Analytics is an input to the risk-based internal audit plan. Data decides which process gets audited.

Level 4 — Continuous. Operational running of the rule set has been handed to the relevant units; internal audit tests that the rule is being operated and monitors the indicators.

Most mid-sized companies sit at Level 1, and the realistic first target is Level 2. Setting Level 4 as the first target exhausts the programme during the calibration phase.

Source: Teolupus

The obstacles to raising the maturity level are not technical. The ways analytics programmes fail are predictable, and four of them recur.

False-positive fatigue. The first run produces a high number of exceptions. Without calibration, process owners stop taking the list seriously and the programme dies quietly. Calibration is not a delay; it is a mandatory phase of the project. Expert support matters here.

Data access becoming internal resistance. Audit’s request for raw data can be slowed down by IT or the process owner. This is usually organisational rather than technical resistance. The remedy is defining data access rights once, at audit committee or senior management level.

Analytics theatre. Impressive dashboards are produced, but no control design changes. The test is this: Did a control change at the end of the analytics work? If not, what was produced is a report, not assurance.

The rule set going stale. The process changes, the ERP is updated, the rule stays the same. A year later the rule either produces no exceptions or meaningless ones. The rule set must be reviewed periodically; that is part of the programme. Continuous maintenance of the analytics structure is essential.

Running data analytics on ERP data means processing personal data in most cases. Payroll records, user transaction logs, and customer and supplier contact details all fall within scope.

Performing fraud detection or a segregation of duties test does not by itself constitute a lawful basis for processing. The basis must be determined in advance, and the data scope narrowed accordingly.

EXPERT NOTE

Under Türkiye’s Personal Data Protection Law No. 6698 (KVKK, 2016), running audit analytics on ERP data gives rise to the following obligations:

Lawful basis (Art. 5). In internal audit practice the basis relied on is Art. 5/2-(ç) (legal obligation of the data controller) and/or Art. 5/2-(f) (legitimate interest). Note that sub-paragraphs follow the Turkish alphabet — legitimate interest is sub-paragraph (f), not (e). Employee consent is not a reliable basis, given the power imbalance in the employment relationship.

Proportionality (Art. 4/2-(ç)). Data must be “relevant, limited and proportionate to the purpose for which it is processed”. Extracting fields not required for the audit purpose is itself a violation.

Notification (Art. 10) and data security measures (Art. 12) apply in addition. The KVKK’s Personal Data Security Guide (January 2018) prescribes an authorisation matrix, access policies and regular log retention — meaning the logging infrastructure analytics depends on is already a data protection requirement.

 

The Board’s decisions on the processing of employee data by employers are instructive in this area. A properly designed internal audit analytics project treats data protection compliance not as a clause added afterwards, but as part of the design of the data scope.

This is the objection heard most often in mid-sized companies. Three observations answer it.

Data volume is not an obstacle; it is an advantage. Because the internal control structure in SMEs and mid-sized companies is simpler than in large institutions, analytics is also established faster. 40,000 rows of purchasing data are analytically easier to manage than millions of rows. The reason projects run long in large institutions is not analytics itself but system fragmentation and organisational complexity. A mid-sized company operating on a single ERP gets its first meaningful result within weeks.

A separate team is not required. Capacity is acquired not by building headcount but through the co-source model. For a mid-sized company this is markedly more suitable than an internal audit data analyst position.

Scope starts narrow. A data analytics programme does not begin with every process. It begins with the single process with the highest cash impact and the cleanest data — usually purchasing or payments — produces a result, and then expands.

It is true that the global audit networks have offered this capability for a long time. That it is out of reach is not true. The difference lies not in the method but in the economics of the engagement.

TeoLupus is an Istanbul-based assurance services and management consulting firm, serving clients across Türkiye. We design internal audit and enterprise risk management engagements together with data analytics. A typical analytics project runs as follows:

Phase 1 — Scope and data inventory. Which process, which ERP module, which tables, which fields. The data protection scope is defined in this phase. What we need from you: one person from the process side and one from IT, for a limited time.

Phase 2 — Data quality validation. Reconciliation of the extracted data with the source system. Skip it and every subsequent finding becomes open to challenge.

Phase 3 — Rule set development and calibration. The false-positive rate is high on the first run; rules are narrowed with feedback from the process owner.

Phase 4 — Evaluation of findings and reporting. Not a list of anomalies, but root cause and control design recommendations.

Phase 5 — Handover and repeatability. Documentation of the rule set, definition of responsibility for periodic runs, and determination of indicators.

For a single-process scope, the work up to Phase 4 is generally measured in weeks. No continuous full-time resource is required from the company; the load sits in Phases 1 and 2.

What the boutique model means here is this: The rule set is written around your sector’s process structure, the work is carried out by a specialist team under partner supervision, and the scope is set and run according to your company’s size, digital maturity level and organisational culture. The methodology is TeoLupus’s own and carries the systematic rigour of global discipline; what differs is that each company’s needs are defined on a boutique basis and matched to a mid-market budget by the quality a capable team delivers.

Source: Teolupus

To discuss how your current internal audit approach could be strengthened with analytics, get in touch with us.

In a company that has, or plans to build, a data analytics programme, the audit committee or board can establish whether the programme is real by asking the following:

1. Were the findings in the last audit report produced across the entire population, or from a sample?
2. How representative, varied and deep are the analytics scenarios for your sector?
3. What control design changed at the end of the analytics work?
4. Who operates the rule set — internal audit, or the process owner? (If audit operates it, there is an independence question.)
5. Was data quality validation performed, and is the evidence on file?
6. Is the lawful basis and scope limit defined for the personal data used?

The answers to these six questions reveal an analytics programme’s maturity level without any technical review.

Data analytics in internal audit is not a tool but a change of method that alters the level of assurance. The move from sampling to full population changes the quality of the answer internal audit gives the board.

The obstacle to this transformation is not technology. The obstacles are generally three: Master data quality, the failure to establish the governance distinction between continuous auditing and continuous monitoring, and the exclusion of data protection scope from the design. All three can be addressed at the start of a project; addressed afterwards, they are expensive.

The starting point in data analytics is not a software choice but a single question: Today, for which of your processes can you prove that the controls are working? Every process you cannot prove is a starting point for data analytics.

Does data analytics require a separate software investment?

A separate software investment is not mandatory for the initial stage. Early-stage work can be carried out on data extracted from the existing ERP. Dedicated internal audit analytics software becomes relevant once the programme is permanent and the number of recurring tests has grown. Starting with the software is a common mistake; a licence bought before the rule set exists sits unused. In later stages of data analytics, projects such as advanced analytics, artificial intelligence and autonomous artificial intelligence can be planned.

Our ERP is old, or we use more than one system. Is it still possible?

Data analytics is possible with an old or fragmented ERP structure, but the data quality validation phase takes longer. What matters is not that the system is new, but that the data can be exported and reconciled with its source. With a fragmented system landscape, limiting the initial scope to a single system is advisable; widening the scope is the next step. Particular attention must be paid to data cleansing and organisation.

We have no internal audit team. Is this work still meaningful?

Data analytics work is meaningful in companies without an internal audit team. In such companies the analytics exercise is often the first structured control test, and it lays the groundwork for establishing the function. Co-source and outsource models are designed precisely for this situation. In Türkiye, internal audit is not a broad legal requirement for private companies; it is a management choice. For publicly held companies, however, alongside various regulations, Article 378 of the Turkish Commercial Code requires the establishment of an early detection of risk committee.

Does examining our employees’ data create legal risk?

Analytics work carried out on employee data creates legal risk when the scope is not properly defined. Under data protection law, the lawful basis for processing must be determined, the data scope limited to the audit purpose, and the notification obligation satisfied. These are part of the project design, not a formality added afterwards. For an assessment specific to your company, working alongside your legal counsel is appropriate.

Will findings turn into disciplinary proceedings for employees?

Whether findings turn into disciplinary proceedings is the company’s policy choice, not audit’s decision. Analytics output shows the control weakness; assessment of individual responsibility is a separate process requiring separate procedural safeguards. Clarifying that distinction at the start of the project also makes the findings easier to accept within the organisation.

How long does an analytics exercise take?

For a single-process scope, where data quality is reasonable, the first meaningful set of findings is measured in weeks. The main factor extending the timeline is not the complexity of the analytics but data access and master data disorder. When evaluating a proposal, it is advisable to check whether data quality validation is included in the scope.

Who are the findings reported to?

Internal audit findings are reported to the board or the audit committee, as independence requires; the executive is not the recipient of that report but its subject. Action plans and owner assignments are made on the executive side, while follow-up auditing is carried out by audit.