| Type | What it does | Best fit |
|---|---|---|
| Generalized audit software (GAS) | Software that reads the client’s data files and runs the auditor’s own procedures — extraction, stratification, ageing, duplicates, gaps, re-computation. Excel with discipline, IDEA and ACL/Diligent are the classic examples; scrutiny engines are its modern form. | Substantive testing over data the auditor controls a copy of |
| Test data | The auditor feeds dummy transactions into the client’s system and checks whether controls accept, reject or flag them — a purchase above the approval limit, a duplicate invoice number, a backdated entry. | Testing automated controls in the client’s application |
| Parallel simulation | The auditor re-performs the client’s processing independently — recompute depreciation, interest, TDS or GST on the full file and compare against the books. Differences are exceptions by construction. | Re-computation at population scale |
| Embedded audit modules / SCARF | Audit code living inside the client’s system, tagging transactions that meet audit criteria as they happen — continuous auditing’s ancestor. | Ongoing monitoring in high-volume environments |
The honest hierarchy in Indian practice: Excel on a Tally export is the CAAT ninety percent of firms actually run; GAS tools add power at the cost of setup; full-population engines remove the setup and the sampling compromise together. Whichever layer you use, the SA 230 rule from the FAQ below applies: re-runnable, or it isn’t evidence.
Two working papers turn CAAT output into an audit file: the journal-entry testing paper (SA 240) for the population screens, and the per-ledger scrutiny checklist for the account-by-account read.
CORAA runs the full-population battery on Tally books natively — every voucher, every check, exceptions explained. See transactional scrutiny or start free: your first audit is on us.
Computer Assisted Audit Techniques are any use of software to perform audit procedures directly on the client’s data or systems — extracting and analysing full data files, re-computing balances, testing automated controls with dummy data, or embedding monitoring code. They exist because manual methods cannot read modern transaction volumes; the standards (SA 315/330 and ICAI’s automated-environment guidance) treat them as ordinary means of obtaining evidence, not a special category.
Most Indian audits already use CAATs without the label: Tally exports analysed in Excel (pivots, duplicate checks, ageing), day-book dumps tested for gaps in voucher sequences, TDS and GST re-computations across the full ledger, and dedicated tools like IDEA or ACL in larger firms. Purpose-built audit platforms take the same idea further — running a battery of deterministic checks across every voucher rather than a hand-built spreadsheet per test.
No standard mandates a tool. What SA 315 and SA 330 do require is responses that match the risk — and in an automated environment with lakhs of transactions, a purely manual approach often cannot deliver sufficient appropriate evidence in the time available. ICAI’s guidance on auditing in automated environments points the same way: understand the system, test what the system does, use the data.
Classic CAATs still ended in a sample: extract, stratify, select, vouch. Full-population testing inverts it — every transaction passes through every check (sequence gaps, duplicates, round sums, period-end patterns, tax applicability, related parties), and only exceptions reach the auditor. Sampling then survives where it belongs: substantive detail testing of the exceptions and the material items, not as the coverage strategy.
Same SA 230 discipline as any procedure, plus the tool specifics: what ran, on which data extract (source, date, record counts), the parameters, the exceptions raised and their disposition. Keep the extract or its hash — a reviewer should be able to re-run the procedure and land on the same exceptions.
