Data Analytics Skills for Auditors: Where to Start

Why the skills question is wrong

Most auditors who search "data analytics skills for auditors" expect a list. Python, SQL, Power BI, Tableau, IDEA, ACL. That list exists on every Big 4 careers page and tells you almost nothing about what matters on your next engagement. It's a curriculum, not a toolkit. And curriculum without context produces consultants, not practitioners who deliver files.

The question that produces results is different. What can I do with data that produces audit evidence a reviewer will sign off on?

Everything else is a hobby until it produces a workpaper. ISA 500.A2 doesn't mention Python. ISA 520.5 doesn't require you to write SQL. What the standards require is that you obtain evidence that is sufficient and appropriate, and that your analytical procedures at planning establish expectations against which you can identify unusual fluctuations. The method is your choice. The evidence quality is not.

This distinction matters because the analytics tools you pick should be driven by two factors: what your client's data looks like, and what procedure you're trying to perform. A mid-tier Dutch firm auditing a logistics company with 400,000 SAP transactions has different needs from a firm auditing a retail chain running QuickBooks. Both need analytics. Neither needs the same toolkit.

The four skills that produce audit evidence

Not every analytics skill matters equally. Four capabilities cover roughly 80% of what non-Big 4 audit teams actually use on engagements. If you learn these first (and skip everything else until they're solid), you'll produce work that passes review.

Full-population journal entry testing

ISA 240.32(a) requires procedures to test the appropriateness of journal entries recorded in the general ledger. Most non-Big 4 firms still do this by selecting a sample of manual entries. Running the full population through a set of risk-based filters (weekend postings, round-number entries, entries posted by unusual users, entries with no description, entries to seldom-used accounts) is the single fastest analytics win available.

You need one skill for this: the ability to import a trial balance or GL export into a tool that can filter and flag entries against criteria you define. Excel handles this for populations under 50,000 rows. Beyond that, you need either IDEA, ACL, or a scripting language.

Three-way analytical review

ISA 520.5 requires analytical procedures at planning (to identify risk areas) and ISA 520.6 requires them near the end of the audit (to confirm whether the financial statements are consistent with the auditor's understanding of the client). The skill here isn't building a chart. It's building a comparison across four data points (current period, prior period, the client's own budget, and your independently developed expectation) then explaining every material variance.

Most teams do two-way comparisons (current vs. prior). The third element (the independent expectation) is where the analytical procedure gains its evidentiary weight under ISA 520.A5. That expectation might come from industry data, from the client's budget (if you've tested budget reliability), or from your own calculation based on known operational changes.

Stratified sampling with documented rationale

ISA 530 governs audit sampling. When you can't test the full population (confirmations, physical counts, detailed vouching), you sample. The analytics skill that matters here isn't statistical theory. It's the ability to stratify a population by a relevant characteristic (transaction value, account type, location, posting date) and then select items from each stratum in a way that your workpaper defends.

Monetary Unit Sampling (MUS) is the standard approach for substantive testing of balances, and ISA 530.A13 specifically mentions stratification as a means to improve efficiency. The practical skill is building a stratification table that a reviewer can read in under 30 seconds.

Data matching and reconciliation

The least glamorous skill on this list, and the one that catches more misstatements than any chart. Matching two data sets (the client's sub-ledger to the general ledger, the GL to the bank statement, the payroll register to the P&L expense) and isolating every unmatched item is a core audit procedure under ISA 500. The skill requirement is joining two data sets on a common key and investigating differences.

In Excel, this is VLOOKUP or INDEX/MATCH with a separate column for match status. SQL handles it with a LEFT JOIN and a WHERE clause for nulls. With Python, it's a pandas merge. The concept is identical. The execution scales with data volume.

Where this skill becomes powerful is in fraud-adjacent testing. ISA 240.A44 mentions transactions with related parties in unusual conditions. If you can match the client's vendor master file against the employee address file, you've just built a related-party screening test that takes ten minutes and produces a workpaper reference for ISA 550.11. Most non-Big 4 teams don't do this because they've never thought of it as "analytics." It's data matching. It belongs in the same skill set.

Journal entry testing: the fastest win

If you're starting from zero, start here. Journal entry testing under ISA 240.32(a) is the single procedure where analytics replaces sampling most directly, where the evidence quality is visibly higher, and where the reviewer sees immediate value.

Here's what you need to produce a defensible journal entry analysis on your next engagement.

First, get the data. You need a complete GL export for the period under audit. Every journal entry, every line, with at least these fields: date posted, date entered, user who posted, account code, description, debit amount, credit amount. Most accounting systems export this as CSV or Excel. SAP exports it from transaction code FBL3N. Exact Online and Twinfield both have single-click GL export functions, as do QuickBooks and Xero.

Second, define your risk criteria. ISA 240.A44 provides guidance on characteristics that may indicate fraudulent entries. Your criteria should include entries posted on non-business days, entries with round amounts above a threshold you define (say €10,000), entries where the posting user is outside the normal finance team, entries with blank descriptions, entries to accounts that had zero activity in the prior period, and entries posted after the reporting date but dated within the period.

Third, run the filters. In Excel (for smaller populations), use a filtered pivot table or conditional formatting. In IDEA or ACL, build a script that flags each criterion. The output is a list of flagged entries. This is your selection population for detailed testing.

Fourth, document the selection rationale. Your workpaper needs to state: the total population (all GL entries for the period), the criteria applied, the number flagged, and the items selected for testing. ISA 240.33 requires you to determine the timing of those tests. If you only test year-end entries, state why in the workpaper.

This isn't complicated work. It's systematic work. The difference between a journal entry analysis that generates a review note and one that clears review is documentation. Every criterion needs a documented rationale tied to an identified fraud risk.

Where Excel stops and scripting starts

Excel is not the enemy. For clients with under 50,000 GL entries (roughly €10M revenue, depending on transaction volume), Excel handles every analytics procedure described above. Most non-Big 4 Dutch clients fall in this range. The auditor who can build a solid journal entry analysis in Excel is already ahead of most peers at comparable firms.

Excel stops working when any of these conditions apply. The GL export exceeds 100,000 rows. You need to repeat the same analysis across multiple entities in a group engagement under ISA 600. The client's data sits across two systems that need joining before you can analyse it. You need to run the same procedure monthly or quarterly for an ISAE 3402 engagement. Or the client is growing, and the data volume this year might tip past what Excel handles reliably even though last year's file was fine.

When you hit those limits, you have two realistic paths for a working auditor who doesn't have time for a computer science degree.

Path one is IDEA or ACL (now Diligent). These are purpose-built audit analytics tools. They handle large data sets, have pre-built audit tests (Benford's analysis, gap detection, duplicate detection, stratification), and produce output your firm's methodology probably already references. The learning curve is real but focused. Most auditors can run a useful journal entry analysis in IDEA within a week of starting. The cost is the licence, which your firm pays for. If your firm already owns IDEA, this is the obvious starting point because the audit-specific templates remove most of the setup friction.

Path two is Python with pandas. This is a general-purpose programming language with a data analysis library that handles everything IDEA does, plus anything IDEA doesn't. The learning curve is steeper initially but the ceiling is considerably higher. Python is free. A script you write for one engagement can be adapted for the next with minimal changes. If your firm doesn't have an IDEA licence and won't buy one, Python is your path. The trade-off is clear: IDEA gets you to a usable output faster, Python makes you more capable over time.

SQL sits alongside both options. You don't need to become a database administrator. You need to know four commands: SELECT, FROM, WHERE, and JOIN. Those four commands cover roughly 90% of what an auditor needs to extract and combine data. If your client's data sits in a database (rather than a flat file), basic SQL is the access layer.

You don't need all of these. One path that works for your client base and your available time is enough. Pick one. Get competent. Expand later.

Worked example: Hendriksen Transport B.V.

Client: Hendriksen Transport B.V., a Dutch road freight company with €38M revenue, 210,000 GL entries, and a 31 December year-end. The audit team consists of one manager, one senior, one associate, and a partner who reviews remotely. They have access to IDEA but nobody on the team has used it beyond running a pre-built Benford's test.

Step 1: Obtain the GL export

From Exact Online, the senior exports the complete GL for the period 1 January to 31 December. The export contains 210,472 journal entries with columns for date, entry number, user, account code, description, and debit/credit amounts.

Documentation note: record the export date, source system, period covered, and total record count in the working paper. Tie the GL export total to the trial balance. For Hendriksen: total debits €394,218,644, total credits €394,218,644, matching the TB.

Step 2: Define fraud risk criteria

The engagement team identified revenue recognition and management override of controls as the presumed fraud risks under ISA 240.26. Based on these risks, the team sets the following journal entry criteria:

1. Entries posted on Saturdays or Sundays (Hendriksen's dispatch office operates Monday to Friday)
2. Entries with round amounts exceeding €5,000 posted to revenue accounts (account codes 8000-8999)
3. Entries posted by users outside the finance department (finance team: user IDs FIN01 through FIN04)
4. Entries with blank description fields posted to accounts 8000-8999 or 4000-4999 (revenue and cost of sales)

Documentation note: link each criterion to the identified fraud risk. Criterion 1 and 2 address management override. Criteria 2 and 4 address revenue recognition. State why the €5,000 threshold was chosen (10% of performance materiality, set at €50,000).

Step 3: Run the IDEA analysis

In IDEA, the senior imports the GL export, applies each filter separately, and produces four exception reports. Results: 847 weekend entries (0.4% of population), 23 round-amount revenue entries, 1,204 non-finance-user entries, 412 blank-description entries in target accounts.

Documentation note: record the number of entries flagged per criterion. Calculate flagged entries as a percentage of total population. For Hendriksen: 2,486 total flagged entries (some overlap), representing 1.2% of the GL population.

Step 4: Select items for detailed testing

From each exception list, the senior selects items using a combination of largest value and random selection. Total items selected for vouching: 40 entries across all four criteria. Each selected entry is traced to supporting documentation (invoice, contract, bank statement, or management authorisation).

Documentation note: state the selection method for each criterion. Record the results of detailed testing. For Hendriksen: 38 of 40 entries fully supported. Two weekend entries (both posted by FIN02) had approval documentation filed after the posting date but were otherwise supported. The team discussed these with management and documented the explanation.

The output is a workpaper that shows the complete population was tested against defined criteria, exceptions were investigated, and the results support the conclusion on ISA 240.32(a). A reviewer sees the logic from fraud risk to criterion to exception to conclusion in a single file.

Your first 90 days learning plan

This is a checklist you can start on Monday, not a reading list.

1. Week 1-2: Export the GL from your current client's accounting system. Open it in Excel. Build a pivot table that shows total debits and credits by month, by account group, and by posting user. Compare the current year to the prior year. Flag any month where the variance exceeds 15% and write one sentence explaining why. This is ISA 520 analytical review at its most basic, and it's already more than many non-Big 4 files contain. Show the result to your senior or manager. Their reaction tells you how far ahead of your firm's baseline you already are.
2. Week 3-4: Build a journal entry filter in Excel for the same client. Apply the four criteria from the Hendriksen worked example above (weekend entries, round amounts, unusual users, blank descriptions). Document what you find. Even if nothing unusual turns up, the file is stronger for having the analysis documented. At this point, you've produced two workpapers that didn't exist before. Neither required any tool beyond Excel.
3. Week 5-8: If your firm has IDEA or ACL, spend two hours per week running the pre-built tests on the same client's data. Start with the journal entry analysis module and the duplicate payment detection module. If your firm doesn't have IDEA, install Python and pandas (both free) and follow a tutorial specifically aimed at audit data analysis.
4. Week 9-12: Package your journal entry analysis into a repeatable template. Standard GL import format, standard criteria, standard output. Save it. Re-use it next busy season.
5. Measure your progress against one question: on my last engagement, did the analytics I performed produce evidence that I cited in a workpaper conclusion? If yes, you're building a real skill. If no, you're practising in isolation. The gap between those two states is documentation. Close it.

Common mistakes

• Running a Benford's analysis because the software has a button for it, without linking the output to a specific risk or assertion. The AFM's 2023 thematic review on audit quality noted that analytical procedures performed without a clear link to identified risks produce evidence of low persuasive value. Benford's is a screening tool, not a conclusion.
• Producing analytics output in a standalone file that sits disconnected from the audit file. If the journal entry analysis isn't cross-referenced to the ISA 240 fraud risk assessment and the overall conclusion on management override, a reviewer has no way to evaluate whether the procedure was responsive to the risk. Link the output to the relevant risk in the audit file structure. A working paper reference from the risk assessment to the analytics output is the minimum connection.

Related Ciferi content

Related career guides:

Put audit concepts into practice with these free tools:

Frequently asked questions