The short answer

ISA 230 requires your working papers to record what you tested, what you found, and how you reached your conclusions - so that an experienced auditor with no prior connection can pick up the file and follow it end-to-end. ISA 230 is the IAASB standard for audit documentation, and it applies to every audit performed under the ISAs.

That means documenting procedures and evidence while the work is still fresh, not weeks later from memory. The final file needs to be assembled ordinarily within 60 days of your report, and kept for at least five years after. Miss any of that, and the audit documentation won't hold up under review, no matter how good the testing was.

What is ISA 230 audit documentation?

ISA 230, short for International Standard on Auditing 230, is the IAASB's standard governing your audit documentation. It requires working papers that record what you tested, what you found, and why you reached that conclusion. This documentation of the audit process provides a path that an experienced auditor can follow, later on, from a number in the financial statements back to the evidence behind it.

The standard applies to every audit performed under the ISAs, and it works alongside documentation rules built into other standards, like risk assessment under ISA 315 and quality management under ISA 220. The core logic travels internationally, even though the specific requirements or deadlines vary in some details. For reference, the table below lists out the naming of the standard in different countries.

What is the "experienced auditor" test?

An experienced auditor is an individual (whether internal or external to the firm) who has practical audit experience and the understanding of the audit process, ISA, the business environment that the entity operates in, and the auditing and financial reporting issues relevant to the industry. Having no previous connection to the audit, this experienced auditor should be able to pick up your file and understand the process. That means the document needs to show:

•     The nature, timing, and extent of the procedures you ran.

•     The results of those procedures, and the evidence behind them.

•     The significant matters, the judgment calls, and how you got to your conclusion.

•     Who did the work and when, who reviewed it and when, and the extent of such review.

Here's what that looks like in practice. Say you tested revenue by matching a sample of invoices to shipping documents and cash receipts. The workpaper needs to show which invoices you picked and how, what you matched them against, what didn't tie out, and how you resolved it. A reviewer who wasn't in the room should be able to reconstruct exactly what you did without calling you to ask.

Why audit documentation matters

The IAASB is direct about the objective: your documentation has to give a sufficient and appropriate record of the basis for the audit report, and evidence that the audit was planned and performed in line with the ISAs and any legal or regulatory requirements. Every later review, inspection, or reperformance sits on that foundation. If the file doesn't hold together, none of those can happen properly.

A working audit trail also does real work during the engagement itself, not just after it. It's what lets the team plan and perform the audit in the first place, lets whoever's supervising direct and review the work properly, and gives the team something they can be held to. It's what a reviewer, a monitoring inspector, or next year's team actually relies on. Skip it, and a quality review stops being a review of the audit and becomes a reconstruction of it.

What ISA 230 actually requires

The standard's test is simple to state but harder to pass consistently. Here's what it actually asks for.

Timely preparation

Write the documentation while the work is still fresh, not reconstructed weeks later. Notes prepared after the fact are consistently less accurate than notes prepared at the time the work was done, and late documentation leaves less time to review the evidence properly before the report goes out. If you're documenting a procedure from memory a month later, you've already lost the point of the requirement.

Documentation of procedures and evidence

In practice, this means audit programs, risk assessments, schedules, checklists, and correspondence on anything significant. For every procedure, the file records what was tested, who did the work and when, and who reviewed it and when. That means you can trace any piece of work in the file back to what was done, who did it, and who reviewed it.

Significant conversations belong in the file too. If something significant came up with management or those charged with governance, record what was discussed, when, and with whom. If evidence turned up that contradicted your final conclusion on something significant, show how you addressed the contradiction, not just where you landed.

Two more situations are worth flagging directly. If you depart from a specific ISA requirement, the file needs to show the alternative procedures you used, why they meet the same objective, and why the departure was necessary. And if new evidence or a new conclusion comes up after the report date, document what happened, what you did about it, how it changes the report, and when and by whom the resulting changes were made and reviewed.  

Assembly of the final audit file

Audit documentation gets assembled into an audit file: one or more folders or storage media, physical or electronic, holding the engagement's records. Assembly means collating and cross-referencing working papers, confirming everything's included, and signing off on completion checklists for the process itself. All the evidence the team already discussed and agreed on before the report date should already be documented by this point; assembly isn't where new conclusions get drawn.

Two deadlines follow. Assembly: you ordinarily have 60 days after the date of your report to finish putting the final file together. This is administrative. No new procedures, no new conclusions. Retention: once assembled, the file is kept for at least five years from the date of the report, or five years from the date of the report on the group financial statements if a group audit is involved, whichever is later.

Once the final file is assembled, nothing gets deleted or discarded before the five-year retention period ends. If you need to modify or add to the file after the assembly is completed, document three things: the specific reason for the change, when it was made, and by whom it was made and reviewed. Clarifying documentation after comments from a monitoring review or an external inspection is a common example.

Your checklist before sign-off:

This is usually where documentation problems surface, right before the report goes out and there's no time left to fix them properly. Five things worth checking before you sign:

•     Every significant judgment has its reasoning attached, not just the conclusion. A reviewer should see why, not only what.

•     Contradicting evidence is addressed, not quietly dropped. If something didn't fit the conclusion, the file should say how you resolved it.

•     Review notes are cleared, not just closed. An open point marked “discussed” with nothing showing what was discussed isn't documentation.

•     Cross-references actually resolve. A tick mark pointing to a schedule that isn't in the file is a gap an inspector will find before you do.

•     Any departure from an ISA is explained, with the alternative procedure and the reasoning for it on file, not just in someone's memory.

If you're finding these gaps at sign-off, they were probably created weeks earlier, when the work was fresh and easy to write down properly. That's the actual cost of late documentation: it doesn't show up until the moment you can least afford it.

What audit working papers look like in practice

ISA 230 doesn't prescribe a format. Documentation can sit on paper, on electronic media, or on other media, as long as it meets the experienced auditor test. The standard names examples like:

•     Audit programs

•     Analyses

•     Issues memoranda

•     Summaries of significant matters

•     Letters of confirmation and representation

•     Checklists

•     Correspondence, including email, on significant matters

You can also include abstracts or copies of the entity's own records, like significant contracts, as part of the file. Audit documentation is never a substitute for the entity's own accounting records, and it shouldn't try to be.

In practice, the format matters more than the standard lets on. A file built from spreadsheets, email threads, and standalone Word documents can technically meet every ISA 230 requirement and still fail the experienced auditor test, because nothing in it points to anything else. Cross-references break when files get renamed. Sign-off happens in an inbox instead of on the working paper. None of that is a documentation failure the standard anticipated; it’s a coordination problem that the standard has no opinion on.

Where RobotX fits in

Most of the friction in ISA 230 compliance doesn't come from the standard itself. It comes from documentation getting rebuilt after the fact, or scattered across schedules, correspondence, and spreadsheets that don't reference each other and don't carry traceable evidence.

RobotX builds the working paper as the procedure runs, not after it. Evidence, testing, and conclusions land in the file in real time, cross-referenced as they're created, so there's nothing left to reconstruct the week before sign-off. Every AI-generated answer stays reviewable by the auditor before it's part of the file: the system only shows what is automated and links it back to the source. Nothing gets added without the auditor’s confirmation, so the judgment calls are still yours; the record of them just doesn't depend on someone remembering to write it down later.