How should I organise source documents for a SARS audit or verification response?

How to use this guide

This article assumes that you have already authenticated the correspondence, identified whether it is a verification or audit, captured the relevant tax type and period, and confirmed the stated due date. If those points are not settled, start with the SARS audit-letter first-response guide. This page owns the document architecture after the evidence set has been identified; it does not decide which records SARS may lawfully require or which substantive position you should take.

Start with a request-to-evidence matrix

Give every request in the SARS letter its own row. Do not paraphrase away qualifiers, dates or limits. A practical matrix can contain:

• request number and the exact wording or a precise cross-reference;
• tax type, period, transaction or issue;
• evidence owner or custodian;
• original source record;
• return, declaration, ledger or schedule entry it supports;
• derived calculation or reconciliation;
• explanation required, if any;
• gap, inconsistency or dependency;
• reviewer and approval state;
• final filename and submission-bundle location; and
• submission status and receipt reference.

The matrix is the control layer. It should let a reviewer answer three questions quickly: Did the pack address every request? Can each material figure be traced back to evidence? Can the exact submitted version be reconstructed later?

Do not mark a row complete merely because a file has been found. A bank statement may prove payment but not the contractual reason, tax treatment or correct period. An invoice may identify a supply but not prove settlement. A spreadsheet may explain a calculation but is not automatically the source record from which its inputs came.

Use a controlled folder architecture

A clear structure is more useful than a large undifferentiated upload folder. One example is:

1. 00 Control: the SARS letter, correspondence history, request matrix, responsibility list and due-date evidence.
2. 01 Authority: taxpayer and representative authority, mandate, registered-representative material and approved communication details.
3. 02 Filed position: the relevant return or declaration, assessment, submitted schedules and the version originally filed.
4. 03 Requested source records: one subfolder per request item or defined transaction group.
5. 04 Reconciliations: return-to-ledger, ledger-to-source and period or transaction reconciliations.
6. 05 Explanations: approved narrative responses cross-referenced to evidence, not mixed into original records.
7. 06 Exceptions: missing records, discrepancies, duplicates, disputed provenance and unresolved questions.
8. 07 Submission copy: only the final files intended for the selected channel, plus the manifest.
9. 08 Receipts and follow-up: upload confirmation, case reference, screenshots where appropriate, later SARS requests and final correspondence.

Use names that remain meaningful outside your own system. A file called scan3-final-new.pdf is difficult to audit. A controlled name might include the request item, tax period, source type, counterparty or account, and a short sequence. Keep names concise enough for the submission channel and do not put unnecessary personal information in filenames.

Preserve originals and provenance

Copy source records into a protected evidence location before preparing extracts, highlights, conversions or merged bundles. Keep the original filename, received date, source system or custodian and, where material, a checksum or export report. Never overwrite the original with a cleaned or annotated version.

For each item, distinguish:

• original source: the record as received or exported from its authoritative source;
• presentation copy: a converted, cropped, redacted or merged copy prepared for review or submission;
• derived working paper: a calculation, mapping, pivot, summary or reconciliation created from source inputs; and
• narrative explanation: the approved text explaining how the records answer the request.

If a record had to be reconstructed, say so. Record who reconstructed it, from which inputs, on what date and why the original was unavailable. Do not backdate, recreate a signature, change a description or present a later schedule as though it existed at the transaction date.

Reconcile the filed position to the evidence

The response pack should tell one consistent story from the filed position to the underlying records. The exact chain depends on the tax type, but useful controls can include:

• return or declaration line to tax computation;
• tax computation to trial balance or ledger account;
• ledger entry to invoice, contract, statement or other source record;
• transaction date to the correct tax period;
• payment entry to bank evidence and allocation;
• VAT output or input amount to the underlying supply and tax invoice;
• payroll declaration to payroll register, employee records and payment; or
• asset movement to acquisition, disposal, valuation and accounting records.

Build a reconciliation schedule that identifies the population, total, exceptions and explanation. Avoid sending a total with no traceable path to the documents. Also avoid forcing records to match by changing them. A difference is an issue to analyse and explain, not a formatting problem to hide.

Create an exception and gap register

Missing or inconsistent evidence should be visible before submission. Record:

• the request affected;
• what is missing or inconsistent;
• why it matters;
• searches or recovery steps already taken;
• alternative evidence available;
• the person responsible for the next action;
• the decision on whether an explanation is required; and
• the reviewer who accepted the treatment.

Silence can make a pack look complete when it is not. An honest, evidence-based explanation of a gap is usually more controllable than an unexplained omission or an invented substitute. Whether alternative material is sufficient is a substantive tax or legal question; the folder system should expose that question rather than answer it automatically.

Separate confidential and potentially privileged material

Do not bulk-export mailboxes, legal files, board folders or auditor working papers directly into the submission bundle. First identify whether the material is within scope, contains third-party personal or commercially sensitive information, or may require legal review.

Potential legal professional privilege is not created by putting a document in a folder marked “privileged.” It depends on the actual communication and purpose. Preserve potentially sensitive material separately and obtain advice before disclosure or redaction where the issue is material. Do not use confidentiality as a reason to ignore a lawful request, and do not waive rights accidentally through an uncontrolled bulk upload.

SARS's current audit-file guide explains that requests for a registered auditor's audit files are not intended to be routine and describes written requests, senior-official approval and ways files may be made available. That specialist process should be handled as its own workstream rather than mixed into a general source-record folder.

Control versions and review status

Use one working location and one named pack owner. A simple status system can distinguish:

• collected but not checked;
• checked for identity and period;
• reconciled;
• explanation drafted;
• technically reviewed;
• approved for submission; and
• submitted with proof.

Do not allow email attachments and personal desktop copies to become competing “final” versions. If a document changes, record the reason and make the old version read-only rather than deleting the history. Freeze the submission bundle before upload and calculate a manifest containing the final filenames, sizes and checksums where proportionate.

Build the final submission bundle

The submission copy should contain only reviewed files. Arrange it in the same order as the request matrix and add a concise cover index if the channel and letter permit one. The index should cross-reference, not replace, the evidence.

Before moving files into the upload folder, check that:

• every requested item has a file, an explanation or a clearly recorded outstanding decision;
• every file opens and is legible;
• periods, taxpayer identity and transaction references are correct;
• derived schedules identify their source inputs;
• no draft comments, hidden sheets or irrelevant pages remain;
• redactions are authorised and do not obscure the point being proved;
• filenames are unique and correspond to the request matrix; and
• the pack fits the current channel's actual file, format and volume limits.

SARS's public verification guidance currently lists accepted formats, a per-file size limit and a maximum number of uploads for that route. Those details can change or differ by tax type and work page, so follow the specific letter and the current upload screen rather than assuming one rule applies to every audit.

Preserve the exact submitted record

Upload is not complete until the channel confirms submission. SARS warns that a verification link can close after submission, so review the complete pack first. Save:

• the frozen submission manifest;
• the exact uploaded files;
• the date, time and channel;
• the submitting user and authority;
• the case or reference number;
• confirmation that “submit” was completed, not only “upload”; and
• the receipt, acknowledgement or other available proof.

Place any later request in a new response cycle. Do not silently add it to the first bundle or overwrite the original record. The final deadline gate covers the last go/no-go review immediately before submission.

This pre-assessment organisation system is not an objection file. If SARS later issues an assessment, move first to the post-assessment document-organisation guide, then use the SARS objection document pack only where that remedy applies.

FAQs

Related Lexuno paths

Related articles