How reliable is evidence the client uploads?

Why a document a client uploads through a request link is client-provided evidence, what the upload trail proves, and when to go to a third party.

By Achekam · 11 October 2026 · 6 min read · For Accountants & audit firms in South Africa, Nigeria, Kenya

On Monday the senior sends the year-end request. By Tuesday the client's bookkeeper has uploaded a PDF of the December bank statement, a signed lease and a spreadsheet of debtors, and the request shows as answered. It is tempting to treat those items as evidence and move on. But the route a document took into your file says nothing about where it started. A bank statement the client exported, saved and then uploaded has passed through the client's hands, and so has every copy of a supplier invoice they send you.

ISA 500 asks the auditor to consider the relevance and reliability of information used as audit evidence, and the source of a document is one of the strongest influences on its reliability. This article looks at how much weight a client upload can carry, what the upload record proves, and when the same information has to come from someone outside the client.

Where a document comes from decides its weight

The application material to ISA 500 offers some broad generalisations, each with exceptions:

• Evidence from independent sources outside the entity is more reliable than evidence from within it.
• Evidence generated internally is more reliable when the related controls, including those over its preparation and maintenance, are effective.
• Evidence the auditor obtains directly is more reliable than evidence obtained indirectly or by inference.
• Documentary evidence is more reliable than oral evidence.
• Original documents are more reliable than photocopies, facsimiles or documents filmed, digitised or otherwise transformed into electronic form.

A client upload sits awkwardly across these lines. A supplier's invoice is external in origin, but the copy you hold came through the client. A debtors listing is internal, and it is only as reliable as the sales-ledger controls behind it. Neither was obtained directly by the auditor. The honest label for most uploads is "client-provided": useful, often sufficient for lower-risk assertions, and never stronger than the records and controls that produced it.

Originals, copies and scans

Almost everything that arrives through a link is a transformed document: a scanned contract, a photographed delivery note, a statement downloaded from internet banking. Its reliability depends on how it was produced and kept.

ISA 240 allows the auditor to accept records and documents as genuine unless there is reason to believe the contrary, and requires further investigation when conditions suggest a document may not be authentic. Conditions that should stop the team include:

• fonts, alignment or spacing that change partway down a statement;
• running balances that do not follow from one line to the next;
• document properties showing it was created long after the date it bears;
• a signature that looks pasted rather than written;
• a client-prepared letter that reads like a third party's confirmation.

When any of these appear, asking the client for "a clearer copy" does not solve the problem. The response is to go to the source, or to inspect the original yourself.

What the upload record does and does not prove

In Achekam, the client opens a request from a personal e-mailed link without an Achekam account, and the firm can also require a one-time code sent to the client's e-mail address. On the request page the client uploads files or folders and answers questions, and what they send is filed in that client's folder in the Document Centre, the vault where staff keep versions and archive or restore documents with a reason.

Staff accept or reject each item and can return the request saying what is still missing. Each request carries a timeline of e-mails, opens, clicks, uploads and answers. Some details matter when you read that timeline as an auditor:

• Executable file types are blocked, and each file is limited to 100 MB by default.
• Files are virus-scanned only when the server operator has configured ClamAV; otherwise structural checks run and the record says so.
• Opens are detected with a tracking image, so an "opened" entry is an indication, not proof.

That trail is good evidence of a process: which request went to which address, when an item arrived and who accepted it. It is not evidence that the document is what the bank, the landlord or the customer actually issued. It answers "how did this reach us?", not "is this genuine?".

When the same fact must come from outside

Where risk is higher, get the information from the third party rather than through the client.

In Achekam, third-party evidence runs through External Confirmations, not the client request console. Staff plan confirmations and prepare the requests, a different person approves them, and each respondent answers through a single-use link. Achekam does not send the requests itself: the team sends them and records how. Keep that separation. A balance the client uploads and a balance the bank confirms through its own link are different kinds of evidence, and the file should never let them blur. Cash is the clearest case, covered in auditing bank and cash balances.

Keeping evidence with the step it supports

Evidence helps a reviewer only when it is clear what it was used for. Each work item lists the procedures to perform and the documents required, and a step is marked done only with a written response and its documents, or set aside with a reason. Steps are never deleted.

Use the written response to state the source and the reliance placed on it. A worked example in words: the step reads "Agree the year-end loan balance to the lender's statement". A response of "agreed" tells the reviewer nothing about reliability. A useful response says whether the statement came from the client's upload or from the lender, whether the copy showed any sign of alteration, and whether the lender's confirmation also covered the balance. If the client's copy was the only source and the loan is material, the response is where the team explains why that was enough, or raises the gap.

Documents signed through Achekam's own e-signing are a stronger case. When everyone has signed, Achekam produces the signed PDF with a completion certificate listing each signer's e-mail, times, IP address and browser and the document's fingerprint, and files it in the client's 'Signed documents' folder. That is better evidence of who signed and when than a scanned signature page, though it still describes only the signing process, not the truth of what was signed.

A reliability checklist for uploads

1. Label each key document: external, internal, or external but received through the client.
2. Note on the step whether you saw an original, a scan or a system export.
3. Look for signs of alteration before relying on any copy.
4. For material balances and significant risks, obtain the information directly from the third party.
5. Record the source and the reliance in the written response, not just in the file name.
6. Reject an item that does not answer the request, and say what is missing.

How clients reach the request page in the first place is explained in requesting documents without a client login. For a wider view, the ACCA's technical article on examining evidence explains the difference between audit procedures and audit evidence and how to judge which evidence is relevant in different circumstances.

Before the next year-end request

Open the request template your team sends at year end and mark each line: will we rely on this as it arrives, or corroborate it elsewhere? Putting that judgement into the template costs little; finding at review that a material balance rests on a PDF nobody questioned costs far more.

General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.