Statutory Record Retention: Keeping the Records Is the Easy Half
Retention gets discussed as a storage question, which is why it is usually answered badly. Storage is the cheap half. Every market that sets a retention period is really asking something harder: that on some date years from now, you can put in front of an inspector what this looked like then — not a fresh query over data that has been corrected eleven times since. Those are two different obligations, they wear the same word, and most operations systems satisfy the first one by accident and the second one not at all.
This post is about the second one. It is also, deliberately, the first article in this corpus to make a reporting argument for a region rather than for a method guide — because the reason a retention rule is interesting is that it differs by market, and the reason it is uncomfortable is that the difference lands on a part of the system nobody demos.
Three things differ by market, and only one of them is the number
Buyers ask "how many years". That is the least variable part of the answer. Across the markets we operate in, three separate things move, and a business trading in three countries can be holding one invoice under three different rules at once.
When does the clock start on a document?
Date of the transaction
The simplest convention and the easiest to compute: the document's own date plus N years. It is also the one that gives you the shortest holding period, which is why it is rarely the only rule that applies.
End of the financial year the document fell in
Very common, and it quietly adds up to a year to everything. An invoice dated 4 January is held almost twelve months longer than the identical invoice dated 20 December — and if your year does not end in December, see the fiscal-year post, because your own boundary is the one that governs.
Date the return that used it was filed
Shifts the clock onto a downstream event the document itself does not know about. A late-filed return extends the retention of every record behind it, which no system computes for you because no system knows the filing date.
Date the assessment, dispute or audit is settled
Open-ended by construction. Under this convention a document under query has no expiry date until the query ends, which is the practical reason a legal hold has to be a real feature rather than a policy in a handbook.
A single business can sit on more than one of these at once, because the company law period and the tax law period are frequently different lengths measured from different starting points — for the same piece of paper. That is not an African peculiarity; it is close to universal. What differs by market is which pair you get.
The second variable is which record. Almost no market sets one period for everything. Payroll and employment records, VAT and invoice records, statutory books and registers, customs and import documentation, and correspondence about a dispute are commonly held for different lengths — and the longest of them usually governs how you have to build, because a system cannot easily keep one class and not another.
The third is what counts as the record. Some regimes accept an electronic reproduction outright. Some accept it on conditions — that it is complete, legible, and reproducible in a form the authority can read. Some still want the original for particular document classes. This is the variable most likely to make a purely digital process non-compliant while every number in it is correct.
We are not printing a table of country retention periods, and that is deliberate
It would be the most linkable part of this article and we are not doing it. Every statutory figure this site publishes carries a dated source and sits under a drift review, because a number without provenance is a compliance claim we cannot stand behind on the day it changes. Nothing equivalent exists for retention periods yet. Until it does, the honest version of this article describes the shape of the obligation and sends you to your auditor for the number — and says so, rather than quietly leaving a gap where a table should be.
What actually governs deletion in this system
Before the interesting question, the boring one, because buyers ask it and vendors answer it vaguely: does the software delete your records on a schedule? Here it does not. What it does delete is a list you can read.
Layer by layer, what expires and what does not
Business records
Invoices, purchase orders, quotations, journals, payslips, assets, projects, stock movements. Not one retention policy targets any of them. They are kept until a person deletes them, and a deletion puts them in Trash rather than removing them. This is the correct default and it is worth stating plainly, because "the system tidies up after itself" is a feature elsewhere and a liability here.
Soft-deleted records in Trash
These do expire — a purge runs on a schedule, with a per-record-type retention you set and a minimum floor. This is also the one place a legal hold applies: a held record cannot be permanently deleted, and the attempt is refused rather than logged and allowed.
The audit log
Who changed what, when, from where. Ships at 730 days, then deleted — or anonymised, which strips the actor, the email and the IP and leaves the event. Two years is shorter than the statutory retention period in most markets, so on defaults the evidence about a record expires while the record itself is still being held.
The activity log
The lighter-weight trail. One year by default, and the same observation applies with more force.
Report runs and export files
Every report you run leaves a row recording that it ran, with what filters, how long it took and how many rows came back. Every export leaves a file. Both default to a year. The consequence of that is the whole second half of this article.
Sessions, jobs, webhooks, scans, notifications
Thirty to 365 days depending on the table. Nobody wants a five-year-old queue-job row and no regime asks for one.
The ceiling on a non-trash policy is 3,650 days — ten years — so if your market needs the audit trail held for seven, you can set it. The point is not that this is impossible. It is that nobody does it, because the default is invisible and the day you discover it is the day somebody asks for a trail that has already gone.
A legal hold stopped the record being destroyed. It did not stop the log of who touched it being swept. Those were two different code paths and only one of them checked for a hold.
Read out of the retention service, 12 August 2026 — fixed the same day
That asymmetry was the sharpest thing we found writing this, and we found it in our own code rather than in a support ticket. The trash purge consulted legal holds and refused. The data retention sweep — the one that prunes the audit log — had no legal-hold check in it at all. So if a matter was under query and you had held the underlying records, the trail describing them was still on a two-year timer.
Corrected 12 August 2026, the day this was published
The gap described above is closed. The retention sweep now resolves the active holds for a tenant and withholds any row it can attribute to a held record — across the audit log, the activity log and the trash lifecycle events — for both record-scope and type-scope holds. The nightly run reports how many rows a hold withheld, and the count goes into the evidence entry, so a purge that comes back smaller than its cutoff says why. We have left the paragraph above in the past tense rather than deleting it. The argument it makes does not depend on our having got it wrong, and a post that quietly turned into a description of a working feature would be the exact move this corpus exists to refuse. What is still true: a hold protects what can be attributed to it, and a log row carrying no subject reference cannot be attributed to anything.
The harder obligation: can you reproduce the report?
Now the part that retention conversations never reach. Suppose you have kept everything, for the right number of years, in an accepted format. An auditor asks for the stock position at the close of a year three years ago, or the receivables ageing that supported a filed return. What do you do?
The instinct is to re-run the report with the date filter set to then. That produces a document, it looks right, and for anything that can be corrected after the fact it is not what the report said at the time. A credit note raised later, an expense reclassified, a supplier invoice matched against a different order, a line deleted — all of them change what a backward-looking query returns without leaving a mark on the output. You have not reproduced the report. You have produced a new report about an old period, and the difference is invisible on the page.
There are only three honest ways to answer, and it is worth knowing which one you have for each thing you might be asked for.
Which of the three you actually have, by record class
| Record class | Kept until you delete it | Retention period you can set | Reconstructable as at a past date |
|---|---|---|---|
| Invoices, POs, journals, payslips, assets | Yes | No | No |
| Stock on hand and stock valuation | Yes | No | Yes |
| An approved and locked payroll period | Yes | No | Yes |
| Soft-deleted records in Trash | No | Partly — configurable by you | No |
| The audit log of who changed what | No | Partly — configurable by you | No |
| Report runs and export files | No | Partly — configurable by you | No |
Built and maintained Configurable by you, not maintained by us Not built
A cross in the middle column of the first two rows is not a gap. Nothing purges your invoices or your stock movements, so there is no retention period to configure — the absence of a setting is the reason the first column is a tick. Read those two rows together or the block says the opposite of what is true.
Two rows in that table earn their tick in the last column and they earn it in completely different ways, which is the useful part.
Stock: reconstructed, not stored
Ask for stock as at a date and the system does not look up a snapshot, because there is no snapshot. It takes today's balance and reverses every movement recorded after that date — the receipts come off, the issues go back on — and shows you the arithmetic result. That is a genuinely strong design: it cannot drift out of step with the movement ledger, because it is the movement ledger, and it costs nothing to store.
It also inherits one limitation exactly, and we would rather write it down than have you find it. The movement rows carry no separate movement date — only the moment the row was created. So the reconstruction is anchored to when it was keyed, not when the goods moved. A delivery received on the 28th and entered on the 2nd sits in the wrong period for every as-at query anyone ever runs, and nothing on the screen indicates it. If your receiving is same-day, this never bites. If your branches key up a backlog on Mondays, it bites every month-end and always in the same direction.
Payroll: frozen, not reconstructed
The opposite approach and the right one for its problem. A timesheet period is approved, then locked, and payroll consumes a frozen snapshot rather than a live query. Correcting an attendance record afterwards does not silently rewrite what was paid. This is the pattern the rest of reporting does not have, and it is the pattern worth asking every vendor about — including us.
Everything else: a file, and a receipt for a file
For every other report, the frozen artefact is the export you took at the time. That works — an exported PDF or spreadsheet is exactly the "complete, legible, reproducible" thing most regimes describe. But note what is and is not stored. A report run records the filters, the row count, the duration and whether it succeeded. It does not store the rows. The only copy of the output is the export file, and the record pointing at it is on a one-year default policy.
There is one small, real consolation in that, and it is worth using. Because the row count is kept, you can re-run an old report and compare the count against what the original returned. If they differ, you have proof the underlying data moved — which is better than the usual position of not knowing. It will not tell you what changed. It will tell you that the reproduction is not the original, which is the fact an auditor actually needs.
Five questions worth asking any vendor, including us
Show me a report as it stood on a date two years ago. Not a report about that period — the report as it was.
What a good answer sounds like
Either a stored artefact, or an honest "we re-run it with a date filter and here is what that does and does not mean".
What a bad one tells you
The failure mode is a demo that re-runs the query, shows a plausible page, and never mentions that a correction made last week would have changed it. If nobody raises the distinction, they have not thought about it.
Which of my records does your retention policy delete, and can you show me the list?
What a good answer sounds like
A list, on screen, per record type, with the period against each one.
What a bad one tells you
"Nothing is ever deleted" is almost never true — something prunes the logs. A vendor who does not know what their own defaults sweep cannot tell you whether the trail will outlive the record.
How long is the audit trail kept, by default, and what is the maximum?
What a good answer sounds like
Two numbers.
What a bad one tells you
If the default is shorter than your statutory period — and it usually is — then the setting matters on day one of your implementation, not in year three when somebody asks.
If I place a legal hold on a record, what exactly is held?
What a good answer sounds like
A precise scope: the record, its attachments, its audit trail, or some subset — named.
What a bad one tells you
This is where we found our own gap. Holds are usually built against deletion of the record and not against the pruning of everything that describes it, because those are different subsystems written at different times.
Does a stock or ledger figure carry the date it happened, or only the date it was entered?
What a good answer sounds like
A direct answer, and ideally both fields on the record.
What a bad one tells you
One column decides whether every period-end figure you will ever produce is right for late entries. It is invisible in a demo and permanent in a schema.
What AWRA OpsHub does today
- Business records are never swept. All 32 default retention policies govern logs, sessions, queue jobs, webhook payloads, notifications, workflow runs, scan events and trash — none of them an invoice, order, journal, payslip or asset.
- Retention is configurable per record type, per organization, up to 3,650 days, with a dry-run mode and an audit entry written for every sweep that runs.
- Legal holds on trashed records, enforced as a refusal on permanent delete rather than a warning, behind their own permission.
- Legal holds that reach the trail as well as the record. Since 12 August 2026 the retention sweep withholds the audit log, activity log and trash lifecycle events belonging to a held record, for record-scope and type-scope holds alike, and reports the number of rows it withheld into the evidence entry for the run.
- True as-at reconstruction for stock on hand and stock valuation, in the on-screen report, the export and the PDF.
- Locked payroll periods that consume a frozen snapshot, so a later attendance correction does not rewrite what was paid.
- A run record for every report — filters, row count, duration, outcome — which is enough to prove that a reproduction differs from the original.
What it does not do
- Any as-at reconstruction outside inventory. A financial or receivables report run for a past period is a query over current data, and nothing on the output says so.
- Stored report output. Runs keep the filters and the row count, not the rows; the only frozen copy is an export file you took at the time.
- A movement date distinct from the entry date on stock movements, so a back-dated receipt sits in the period it was keyed in rather than the one it belongs to.
- A hold on anything a log row cannot be attributed to. The sweep matches rows by the record they name; a log entry carrying no subject reference is not protected by any hold, because nothing connects it to one.
- An archive action. A policy can delete or anonymise; asking it to archive is accepted at the form and reported as unsupported when it runs.
- Anonymisation anywhere except the audit log. Every other table ignores the setting and removes nothing.
- Any retention period keyed to a statutory rule for any country. The periods are numbers you choose; nothing here knows what your regulator asks for.
Not ours, by choice
- We publish no country-by-country retention table and do not intend to until it can carry dated sources under the same review our tax figures sit under. Nothing in this article is legal advice, and the question of what binds you is your auditor's.
- We are not a document archive or an e-invoicing archive service, and where a market requires records lodged with or retained by an accredited provider, that provider is not us.
The smallest gap in that list is no longer in it. A legal hold that also suspends the retention sweep was named here as a defect repair rather than a feature, on the grounds that the behaviour surprised the person who set the hold — and it was repaired on 12 August 2026, the day this was published. What remains is genuinely larger. A movement date separate from the entry date on stock movements is a column, a form field and a migration, and it makes every as-at figure correct for back-dated entry. Stored report output — freezing the rows of a run, not just its filters — is a real build with a real storage cost, and it is the one worth scoping properly rather than bolting on: which reports, retained how long, and reproducible by whom. Beyond that, a retention profile pinned to a named market's requirements is a build we would quote for, and it starts with your adviser telling us the periods rather than us guessing them. The precedent that market-specific work gets finished here is Kenya, where a live tax-authority integration and a maintained statutory payroll engine are both ours to run and maintain.
The legal-hold asymmetry was found by reading our own retention service against this article's argument, not because anyone reported it. It never caused a support ticket, which is exactly what you would expect from a gap whose symptom is a record quietly not being there in three years' time — and it is the reason we would rather find these by writing than by waiting. Published and fixed on 12 August 2026; both dates are on this page deliberately.
Retention behaviour is one of the easier things to build to a requirement
Most of what is missing above is missing because no customer has yet put a specific statutory requirement in front of us in writing. That is a different situation from a product that cannot accommodate one.
A hold scoped the way your matter is
Holds now reach the trail as well as the record. What is not built is a hold defined by anything other than a record or a record type — a date range, a customer, a project, a matter reference — which is how a hold is usually described when it arrives from a lawyer.
Frozen report output
Storing the rows of a run, not only its parameters, for the report classes you actually get asked to reproduce.
Effective date on movements
A movement date distinct from entry date, so period-end figures survive a backlog being keyed late.
A retention profile for your market
Periods per record class, set from what your adviser tells us your regime requires, with the sweep evidenced in the audit log.
We do not promise roadmap dates. You describe the requirement, we return a written scope, timeline and cost, and you decide before anything starts.
Tell us what your regulator actually asks forThe short version
Keeping the records is the easy half and almost every system passes it. The half that decides whether an audit goes well is whether you can put back what the report said at the time — and for most reports, in most systems including this one, you cannot, you can only re-ask the question. Know which of your reports are reconstructable, which are frozen in an export you took, and which are neither. Then check what your audit trail's default retention is, because two years is the industry default and it is shorter than almost every statutory period it is supposed to evidence.
Working out what your retention obligations mean operationally
Bring us the periods your auditor gives you and we will tell you which parts of them this system already satisfies, which are a setting, and which are a build. If the answer is that we are not ready for your regime yet, we would rather say so before an implementation than after one.
See plans & pricingFrequently asked questions
How long do I have to keep accounting records?
It depends on your market, on which record you mean, and on when the clock is treated as starting — and in many countries the company law period and the tax law period are different lengths for the same document. We deliberately publish no country-by-country table of retention periods, because we have not verified one to the standard we hold our published tax figures to. Your auditor or adviser is the right source for the number that binds you.
Does AWRA OpsHub delete my invoices or payroll records after a period?
No. The retention engine ships 32 default policies and not one of them touches a business record. Every default governs logs, sessions, queue jobs, webhook payloads, notifications, workflow runs, scan events and trash. Invoices, purchase orders, journals, payslips and assets are kept until somebody deletes them.
Can I run a report as it stood on a past date?
For stock on hand and stock valuation, yes — those two reconstruct the balance as of a date by reversing the movements recorded after it. Everywhere else, re-running a report with a date filter gives you today's data filtered to a past period, which is not the same thing if anything in that period has since been corrected.
How long is the audit trail kept?
The default is 730 days for the audit log and 365 for the activity log, and both are settable up to 3,650 days. The default matters because it is shorter than the statutory retention period in most markets — so on default settings the evidence about a record expires years before the record does.
Does a legal hold stop the audit log being purged?
It does now. When this post was published on 12 August 2026 it did not: holds gated the trash purge, and the separate sweep that prunes the audit log had no hold check in it at all. That was fixed the same day. A hold now withholds the audit trail, the activity log and the trash lifecycle events belonging to the held record, and the nightly run records how many rows it withheld and why.
