Transaction evidence checklist.
Use this checklist to test whether another authorised person can understand a transaction and retrieve its evidence without relying on the original operator's memory. It covers capture, confirmation, exceptions and retrieval.
Written by the Fundamental View editorial team. Updated 28 October 2026. This operational aid is not a statutory retention schedule, accounting standard or investment recommendation. Adapt it with the responsible professionals.
Before an entry is saved
- Identify the entity. Is the record attached to the right structure? If several entities are involved, is their relationship explicit?
- Define the date. Does the field mean transaction, document, settlement or another date? Is the source clear?
- Check original amount and currency. Do they match the evidence? Keep reporting conversion separate.
- Confirm counterparty context. Is it supported, and is uncertainty visible?
- Connect evidence. Does the entry contain a stable, access-controlled reference to the right source?
- Complete human review. What was confirmed, what remains unresolved and who owns the next action?
Exception checklist
| Situation | Required check | Evidence of resolution |
|---|---|---|
| Unreadable or incomplete source | Mark affected fields unconfirmed | Replacement source and reviewer decision |
| Repeated submission | Compare stable ID, source and transaction details | Duplicate linked or rejected through the agreed process |
| One source supports several rows | Identify each relevant movement or amount | Every row retrieves the same source with distinct context |
| Correction after review | Follow the configured history and approval path | Current value plus available correction context |
| Missing FX rate | Preserve original amount and open an exception | Rate, source, date and override reviewer where applicable |
| Crypto reference | Check network, full identifier and relevant movement | Explorer reference plus separate business context |
Test retrieval, not just storage
Ask another authorised reviewer to start from the register entry and find the source. Can they explain amount, entity, date and unresolved questions? Verify access under the agreed permission model without creating a public share link. Repeat with a read-only role and, where appropriate, confirm that an unauthorised account cannot retrieve the file.
Record the test date, synthetic record ID, role used and outcome. Do not paste confidential evidence into a public testing log.
Illustrative review
Entry: EXAMPLE-2026-0001; Example Holding A; EUR 1,250.00. Source: fictional invoice EXAMPLE-2026-0001-invoice.pdf. Question: invoice date and transaction date differ. Next action: the assigned reviewer establishes what the transaction-date field represents before confirming the entry. Do not alter either date simply to make them match.
Turn repeated failures into workflow changes
- Repeated missing fields may require a clearer intake rule or field definition.
- Broken references may indicate a storage, naming or access problem.
- Repeated recognition corrections may show that a document class needs different handling.
- Unowned exceptions indicate an operating-responsibility gap, not necessarily a software defect.
- Successful retrieval by an unauthorised role indicates an access-control failure that must stop operational use of that test path.
Copyable blank review record
Record ID: [synthetic ID] · Entity: [fictional entity] · Source reference: [private test reference] · Original amount/currency: [value] · FX status: [status] · Reviewer: [role] · Exceptions: [open items] · Retrieval test: [pass/fail] · Access test: [pass/fail] · Review date: [actual date].
Use only synthetic or properly redacted examples in a shared checklist. The blank structure is a starting point, not a secure repository by itself. Always store operational copies only in the approved, access-controlled workspace. Download the blank CSV register with one clearly marked fictional row.
Related guides
- Define transaction fields and states
- Connect documents to records
- Review crypto-specific evidence
- Include exceptions in acceptance testing
Discuss your workflow
Describe the record-keeping problem you want to solve. Please do not include confidential financial information or documents in the enquiry.
Discuss implementation