Skip to content

Use cases/Financial services/Audit evidence matching

Audit evidence matching for Australian audit firms

Audit evidence matching means a model reads the documents a client sends in and matches each one to the sample item it supports. It lists every difference from the ledger. The auditor reviews every match and makes every judgement. What goes is the chasing, the page turning and the rebuilding of last year's workpapers.

Talk to our team →
Supports
Audit senior
Reads
Trial balance, General ledger, Prior year file, Source documents, Bank confirmations
Runs on
Your servers, on premises
Connects to
Caseware, Caseware IDEA, DataSnipper, TeamMate+
Decides
A person, every time

Architecture

Everything runs on your servers

We build it on an open-weight model such as Llama or Mistral, served with vLLM on NVIDIA GPUs in your server room, data centre or colocation. Retrieval runs on PostgreSQL with pgvector, and the system reads from the ledger, the trial balance and your audit software. No client file goes to a public AI service.

  1. SourcesTrial balance / General ledger / Prior year file / Source documents / Bank confirmations
  2. Your serversAgree to trial balance → Match to sample → Write the workpaper
  3. ReviewAudit senior
  4. OutputEvidence requests from last year / Source documents matched to samples / Populations, samples and journals / Everything in the workpaper

It takes four jobs off the audit senior

  1. 01

    Evidence requests from last year

    Each client's request list is built from last year's file and the audit plan. The system chases outstanding items on a schedule in your wording.

  2. 02

    Source documents matched to samples

    Invoices, contracts, bank confirmations and minutes are matched to each sample item with the supporting page cited. Differences from the ledger are listed for the auditor.

  3. 03

    Populations, samples and journals

    Populations are agreed to the trial balance and samples are selected by the method the auditor sets. Journals are tested against the criteria the engagement team writes.

  4. 04

    Everything in the workpaper

    Each selection, match, flag and reviewer is recorded in the workpaper, which supports ASA 230 documentation. The record shows what the system did and who reviewed it.

It goes live in five steps

  1. Step 01

    Collect last year's files

    Request lists, workpapers, templates and the ledger exports from past engagements, structured and attached to the engagement they came from.

  2. Step 02

    Test against past engagements

    Run the matching over files you have already signed off and compare. You see which matches the system gets wrong and on what type of document, and that sets the review rules.

  3. Step 03

    Match and list differences

    Source documents are matched to sample items with the supporting page cited. Differences from the ledger are listed first.

  4. Step 04

    Auditor reviews every match

    The senior confirms or rejects each match and decides what a difference means for the audit. Nothing enters the file without a reviewer.

  5. Step 05

    Record it in the workpaper

    The population, the selection method, each match and each reviewer are written to the workpaper in your template, with logs kept for the file.

Software or a custom build

If you audit smaller entities with clean ledgers, buy a product first. DataSnipper works inside Excel to match documents to sample items, and Caseware IDEA covers full population analysis and exception testing. A custom build earns its cost when client documents arrive in many formats, when your methodology sets its own selection rules, or when no client file can leave your environment. We will say in discovery if a product already does the job.

Caseware / Caseware IDEA / DataSnipper / TeamMate+ / CCH iFirm / Xero / MYOB / SharePoint

In practice

The build sits inside your audit methodology. The system prepares and indexes evidence, and the engagement team decides whether it is sufficient and appropriate.

Documentation is the part that shapes the design. ASA 230 requires the final audit file to be assembled on a timely basis, ordinarily not more than 60 days after the date of the auditor's report. It also bars deleting audit documentation before the end of its retention period. We keep the log of every match, selection and flag so that it can sit in the file. Client documents hold personal information. The OAIC guidance on commercially available AI products advises against entering personal information into public AI tools, and says a system deployed locally or on premises is likely to be more privacy preserving.

The method is in the library. Read RAG on private infrastructure for how retrieval works on your servers and where to put the human for the review step. Our private AI and LLM integration and RAG services cover the build, and the wider picture is on the audit page.

Questions

Does the AI form the audit opinion?

No. It matches documents to sample items, lists differences and flags journals for review. The engagement partner forms the opinion and signs the audit report, and a reviewer signs off each workpaper.

How does it record what it did?

Every match, selection and flag is written to the workpaper with its source document, the method used and the reviewer. This supports your ASA 230 documentation. We also keep a log of each model call with OpenTelemetry so you can show what ran.

Can it select samples?

Yes, by the method and size the auditor sets. The system agrees the population to the trial balance first and then applies your selection rule. The auditor reviews the selection and its basis before any testing starts.

We already use Caseware or DataSnipper. Do we need to change?

No. What we build reads from and writes back to the audit software and ledgers you already run.

Tell us where your hours go.

We map the work, size the hardware and price what is worth automating.

Talk to our team →