Record retention when the records are generated
Record retention used to be straightforward in concept: keep the documents for the required period, in a form that can be produced on request.
Automated accounting complicates it, not because the obligation changed but because the nature of the record did. A figure derived by a system from a document processed under a rule is several artefacts, and it is worth being clear which ones you are actually retaining.
The four things you might be keeping
The source document. The invoice, statement or receipt. This is what retention rules were written for, and it remains the core obligation.
The transaction record. The ledger entry — what was posted, when, to what.
The processing record. The basis for the treatment, the rule or model version, the confidence, the review. This is the newest category and the one most often not considered a record at all.
The derived output. Reports, reconciliations, packs. Usually reproducible from the first three, which is why retaining them matters less — provided they genuinely are reproducible.
Most retention policies address the first two. The third is what makes an automated entry explainable, and the fourth carries a trap.
The trap in "reproducible"
A report is only reproducible if the logic that produced it still exists and still behaves the same way.
If your reporting logic changes — a category redefined, an allocation rule adjusted, a threshold moved — regenerating last year's report may produce a different figure than the one you published. Both are correct under their own rules; they are not the same number.
That matters when someone asks you to reproduce a figure you reported previously: to a lender, to a shareholder, in a filed set of accounts.
The practical protection is to retain the output as published, not just the ability to regenerate it. Keep the actual pack that went to the board, the actual reconciliation as at the date it was signed. They are small files and they settle arguments that are otherwise unresolvable.
The question people forget: what happens when you leave
The most consequential retention issue in automated accounting is system migration.
Your obligation to retain records outlasts almost any software contract. If your processing records live in a vendor's system and you move to another, the transactions migrate — they always do — but the processing records frequently do not, because the new system has no field for the old system's rule versions and confidence scores.
Result: transactions from the retention period that are no longer explainable, because the basis for their treatment stayed behind.
Worth settling before you sign, not at renewal:
- What can be exported, in what format, and does it include the processing records or only the transactions?
- Are source documents exportable in their original form, or only as references?
- How long is data retained after termination, and at what cost?
- Can an export be read without the vendor's software?
That last one is the real test. An export in a proprietary format that requires the vendor's product to interpret is not a retained record in any practical sense.
Documents attached versus documents referenced
A transaction carrying a link to a file in cloud storage is fine until the folder is reorganised, the storage account is closed, or the person who owned it leaves.
For anything within a retention period, the document should be held in a way that survives the reorganisation of everything around it. A reference is a convenience; the document itself is the record.
What to do about all of this
Write down what you retain, where, and for how long — covering all four categories, not just source documents. Most policies were written before the processing record existed as a concept.
Test a restore. Take a transaction from over a year ago and retrieve everything about it: document, entry, basis, review. If any part is unavailable, that is your retention gap, and it is better found now.
Keep published outputs as published. The signed accounts, the board pack, the reconciliation as at the date.
Settle exit terms before signing. Including whether processing records travel.
Check the export is readable independently. Actually open one, in something that is not the vendor's software.
The proportionate view
None of this needs to be elaborate. For most small and mid-sized businesses it is a one-page policy, one test restore a year, and a clear answer from the vendor about export.
The failure mode is not excessive retention — storage is cheap. It is discovering, at the point of a query about an old transaction, that the part which would have explained it was never considered a record and therefore was never kept.
Common questions
What records need keeping with automated accounting?
Four categories rather than the traditional one: the source document, the transaction record, the processing record covering the basis for the treatment and the rule version and confidence and any review, and the outputs as they were published. Most retention policies address the first two, while the third is what makes an automated entry explainable and is frequently not considered a record at all.
Should I keep reports if the system can regenerate them?
Keep the versions as published. Regenerating a report later produces a figure under today's logic, which may differ from what was published if a category, allocation rule or threshold has since changed — both figures are correct under their own rules but they are not the same number. Retaining the actual pack that went to the board settles disputes that are otherwise unresolvable.
What happens to my records if I change accounting systems?
Transactions almost always migrate, but processing records frequently do not, because the new system has no field for the previous system's rule versions and confidence scores. That leaves transactions within the retention period that can no longer be explained, which is why export terms — including whether processing records are included and whether the export is readable without the vendor's software — are worth settling before signing rather than at renewal.
Is a link to a stored document sufficient?
Not for anything within a retention period. A reference to a file in cloud storage survives only until the folder is reorganised, the account is closed or the owner leaves, so the document itself should be held in a form that outlasts the reorganisation of everything around it. A reference is a convenience; the document is the record.
Related: the compliance case for full traceability · backing up your business data · where does your business data go
Read next
See what you could build
Start a free trial and describe what your business needs in plain language — SmartB Studio builds the module for you.
Start free trial