Access is a licence, not ownership
Financial records live in places you rent. The accounting system, the bank's portal, the document store, the payroll service, the expense app — each holds part of the picture, and each grants access on terms that end.
While the relationship continues this is invisible and entirely fine. It becomes visible at exactly one moment: when the relationship ends. Then the practical question is not who owns the data but who can reach it, and the answer is frequently nobody on your side.
The uncomfortable part is the timing. You need those records for years — for filing, for review, for a lender, for a question nobody has asked yet. Access commonly ends within weeks of cancelling. That mismatch is the whole subject of this article.
The windows that close, and how fast
Different relationships end differently, and the speed varies more than people expect.
A cancelled subscription. Some providers offer a read-only period, some retain data for a stated window, some remove access promptly. The only reliable approach is to read the specific terms of the specific provider — assuming that one service behaves like another is how people get surprised.
A closed bank account. The hardest edge. No login, no download, no feed, ever again. Statements become a written request with a waiting time you do not control and cannot accelerate for a deadline.
A professional relationship ending. An accountant or bookkeeper holds working papers, reconciliations and sometimes documents that exist nowhere else. Handover is normal and expected, and its speed depends heavily on asking while the relationship is still warm.
A person leaving.The most overlooked. Records in someone's mailbox or personal storage vanish the moment their access is revoked, and nobody realises until something is needed.
Retention obligations versus practical access
Record-keeping requirements generally run for years — the exact period and rules depend on your jurisdiction, your entity type and what the records are, so check what applies to you rather than assuming a number.
What is universal is the shape of the problem. Your obligation to produce records outlasts your access to the systems that held them, often by a long way. The obligation does not transfer to the provider, and "the software we used deleted it" is not an answer anyone accepts.
So the archive has to be yours. Not a login to somebody's platform, not a promise in a terms page, but files you hold, in formats you can open, somewhere you control.
The framing that makes this easy to prioritise
What to take
Work through the categories deliberately, because an export that looks complete is usually only the first two.
| Category | Take | Why it matters later |
|---|---|---|
| Transactions | Full ledger and bank transaction data | The working record you will actually query |
| Statements | The institution's own PDF documents | The evidence, with printed balances |
| Attachments | Every scanned invoice, receipt and document | Usually the biggest gap in an export |
| Reports | Trial balance, P&L, balance sheet per period | Lets you check the data reproduces the figures |
| Reconciliations | Completed reconciliations with dates | Proves cash was verified to a point in time |
| Master data | Customers, suppliers, chart of accounts | Without it the transactions lose meaning |
| Settings and rules | Categorisation rules, mappings, templates | Rebuilding these from memory is slow |
| Correspondence | Anything agreed in messages or notes | The reasoning behind judgements |
Take reports as well as data even though they are derivable, because they let you check that the exported data actually reproduces the numbers that were reported at the time. If it does not, you want to know that now.
The attachments problem
If there is one thing to take from this article, it is this. A typical export produces transaction and ledger data as files. The documents attached to those entries — the scanned invoices, the receipts, the contracts — are frequently not included.
The reason is structural. Attachments are stored separately from the records that reference them, and exporting them means packaging potentially thousands of files with a mapping back to entries. Many exports do not attempt it, and the omission is easy to miss because the data export looks complete.
The consequence is severe. Transaction data proves that money moved; the attachment proves what it was for. Lose the attachments and you have retained the part that is easiest to reconstruct while losing the part that is impossible to reconstruct — because the original supplier document exists nowhere else once the platform has gone.
So check specifically. Not "did the export include everything" but "open the export and find the invoice attached to a transaction you can name". If you cannot, you need a separate route for documents before you cancel anything.
Which format to ask for
The general rule is the most raw and portable form available. Anything readable only by the product you are leaving is not an archive; it is a hostage.
For statements, take the institution's own PDF. It is the document of record, it carries the printed opening and closing balances that make completeness provable, and it is what a reviewer or lender expects to see. A screen export is convenient and is not the same artefact.
For ledger and transaction data, take CSV or another open format. Where a structured statement format is available, take that alongside — it carries labelled fields rather than positional columns, as described in CAMT.053 explained.
For documents, the original files as uploaded, not re-rendered versions. A re-rendered document has been through a transformation you did not choose and cannot inspect.
And take both a data form and a document form where both exist. Data is what you will work with; the document is what you will produce if a figure is ever questioned.
What exports commonly leave out
Check each of these explicitly rather than assuming the export covers them. Every one is a thing people discover afterwards.
| Often missing | Why it is omitted | What to do |
|---|---|---|
| Attachments | Stored separately from records | Export by a separate route, verify by opening one |
| Audit trail and edit history | Considered internal metadata | Ask; take reports as a substitute if refused |
| Notes and internal comments | Not part of the data model exported | Extract manually if they carry reasoning |
| Categorisation rules | Configuration rather than data | Screenshot or document them before leaving |
| Draft and unposted items | Only posted records are exported | Post or delete deliberately first |
| Archived or deactivated records | Filtered out by default | Re-activate or ask for a full export |
| Multi-year history | Export defaults to a recent range | Set the range explicitly to everything |
| Links between entries | Relationships flatten in a file export | Keep the reports that show them |
The last one is subtle and matters. A payment allocated against three invoices is a relationship, and a flat file export can lose which payment settled which invoice while retaining both. Keep the reports that show allocations.
Verify before you cancel, not after
An export you have not opened is not an export. Verification is the step that gets skipped, and it is the only thing standing between a downloaded file and an archive you can rely on.
Count. Compare the number of records in the export with what the system says it holds. A truncated export — capped at some number of rows, or defaulting to a recent date range — looks entirely normal until counted.
Reconcile. Take a period whose figures you know and confirm the exported data reproduces them. If the export gives a different total from the report you filed, you need to know while you can still ask.
Check the statement series. Each closing balance should equal the next opening balance, and each document should balance internally. Those two tests together prove no statement is missing and no rows are missing from any statement — described in the missing month problem.
Open something. Pick a transaction you remember, find it in the export, and open its attachment. This ten-second check catches the attachments gap that counting never will.
The read-only offer
Some providers offer continued read-only access after cancellation, sometimes free and sometimes at a reduced rate. Take it where it is available, and understand what it is.
It is insurance against something you discover later — a document you did not realise you needed, a figure you want to check. That is genuinely valuable, and a paid read-only tier is often cheap relative to the cost of reconstructing something.
It is not an archive. It is still access on someone else's terms, with an end date, subject to their pricing decisions and their continued existence as a business. Building your retention strategy on it reproduces exactly the exposure you were trying to remove.
So do both: export properly, and keep the read-only access as a safety net for the mistake you have not found yet.
A bank you are leaving
The hardest version, because the closure is absolute. Once an account is closed there is no login, no download and no feed — and no automatic connection can be established retrospectively to an account that no longer exists.
Download everything the bank offers before closing: the current financial year, the prior year, and as much older history as the portal exposes. Take the bank's own PDF statements rather than screen exports, for the reasons above.
Then obtain the final closing statement after the last movement. It is the single document proving the account ended at zero, it is issued only after closure, and it is the one people most often fail to chase.
The wider bookkeeping around a bank change — the transfer that gets counted as income, the split month, the mandates that did not move — is covered in switching banks mid-year.
When a professional relationship ends
An accountant or bookkeeper holds things that exist nowhere else: working papers, the reasoning behind judgements, completed reconciliations, and sometimes original documents.
Ask early and in writing, and ask specifically. The finalised accounts for each year they acted. The trial balance at the handover date. The last completed reconciliation for every bank account, with its date. Any documents they hold that you do not. A note on any judgement that is not obvious from the ledger.
Handover between professionals is normal and expected, and most of the friction is practical rather than principled — the request competes with everything else on someone's desk. Asking while the relationship is still cordial is worth a great deal.
What you receive determines how expensive the next engagement is. The receiving side of exactly this problem — being handed a year and having to establish what you actually know — is in closing a year you inherited.
When a person leaves
The quietest version of this problem, because nothing is cancelled and no account is closed. Someone leaves, their access is revoked correctly and promptly, and whatever lived only in their mailbox or personal storage goes with them.
In finance this bites specifically. Supplier correspondence agreeing a price. Invoices sent to an individual rather than a shared inbox. A spreadsheet that reconciled something. The context behind a decision, which existed only as messages.
The fix belongs in offboarding: retrieving what the organisation needs should be a step alongside removing access, and it has to happen first. Afterwards it depends on goodwill from someone who no longer works there.
The structural fix is better — shared inboxes, shared storage, documents attached to records rather than to people — but it is a longer project, and the checklist works today.
When the provider is the one who leaves
Everything so far assumes you choose the moment. Sometimes you do not. A provider is acquired and the product is retired, a service shuts down, a company ceases trading, or a plan you rely on is discontinued and the replacement does not carry your history forward.
These situations share an uncomfortable property: the notice period is set by someone whose priority is winding something down, and it usually arrives when you have other work. A migration you planned takes as long as it takes; a migration announced to you takes as long as you are given.
They also tend to arrive with a deadline that sounds generous and is not. Weeks is ample for exporting data and entirely insufficient for discovering that the attachments were not included, finding another route, verifying the result, and doing it across several years.
The defence is not vigilance about any particular vendor — you cannot predict which one. It is having an archive that is already mostly current, so an unexpected shutdown means topping up a few months rather than extracting a decade under time pressure.
Which turns this from an event you respond to into a habit you maintain, and that habit is cheap enough to be worth it purely as insurance against a notice you have not received yet.
The habit that removes the panic
Doing this once, urgently, at the end of a relationship is the expensive version. Doing a little of it regularly is barely work and removes the deadline entirely.
Statements as they are issued. Download each one when it arrives rather than assembling the year later. Almost every missing statement was available when nobody needed it, and this single habit prevents most of what goes wrong at year end.
A periodic full export.Quarterly is enough for most organisations, annually at minimum. It costs an hour, it keeps the archive close to current, and — usefully — it means you have already discovered what your provider's export does and does not include, long before that answer is urgent.
Documents attached to records, not to people.A structural fix rather than a habit, and the one that pays back most. Anything living in an individual's mailbox is one departure away from being gone.
The compound effect is that leaving anything — a platform, a bank, a bookkeeper, an employee — stops being a data project. It becomes an administrative decision, which is what it should have been all along.
Where to put it
Three properties matter, and one common choice fails all of them.
Backed up. A single copy on one machine is not an archive. Records you are answerable for should survive a failed disk and a lost laptop.
Reachable by more than one person. An archive that only one individual can access has recreated the leaving-employee problem inside your own organisation.
Independent of any single vendor.The whole point of the exercise is not to depend on one provider's continued goodwill, so putting the entire archive inside the next platform you might leave is a circular solution.
Ordinary organised file storage with a backup is entirely sufficient. This does not need to be sophisticated — it needs to exist, and to be findable by someone who is not you.
One organising decision is worth making deliberately: structure the archive by source and period rather than by export date. A folder per system, then per year, is immediately navigable by someone who has never seen it. A folder named after the day you happened to run the export is meaningless within months, including to you.
And keep the archive separate from working files. An export that sits in the same place as documents people edit will eventually be edited, moved or tidied away by someone acting entirely reasonably. The archive is a record, not a working set, and treating it as read-only from the moment it lands protects it from ordinary helpfulness.
Keeping it usable, not just kept
An archive nobody can interpret is only marginally better than no archive. Two small habits make the difference, and both cost minutes.
Write a short note that lives with the files: what system this came from, what period it covers, what is included, what is known to be missing, and the date of the export. The person who needs this may be a colleague, a successor, or you in five years with no memory of the decision.
Keep originals unmodified. If a question arises later, the only way to establish whether an error came from the source or from subsequent processing is to go back to the file as it arrived — which turns an unresolvable argument into a test.
And remember that PDF statements are evidence rather than data. When you actually need to work with them — a query, a review, a reconstruction — they convert readily, and a statement carries its own completeness proof in its printed balances. Storing the document rather than a spreadsheet loses you nothing and preserves the stronger artefact.
The checklist
In order. Cancelling is deliberately last.
| Step | Do | Common failure |
|---|---|---|
| 1 | List what the system holds, by category | Exporting only what the export button offers |
| 2 | Set the date range to everything | Defaulting to a recent period |
| 3 | Export data in open formats | A format only the old product reads |
| 4 | Export the original documents and PDFs | Keeping only derived data |
| 5 | Retrieve attachments by a separate route | Assuming they were included |
| 6 | Take period reports as well as data | No way to check the data reproduces the figures |
| 7 | Count records against what the system claims | A silently truncated export |
| 8 | Check statement continuity and per-document balance | A missing period discovered at year end |
| 9 | Open one attachment from one named transaction | The attachments gap, found too late |
| 10 | Store somewhere backed up and shared | One copy, one person, one machine |
| 11 | Write the note that explains the archive | Files nobody can interpret |
| 12 | Only then cancel | Working to someone else's clock |
Key takeaways
Owning your data and being able to reach it are different things, and they separate on a date somebody else sets. Your obligation to produce records outlasts your access to the systems holding them, usually by years.
Attachments are the usual casualty. Data exports look complete while leaving behind the scanned invoices and receipts that prove what the money was for — the part that cannot be reconstructed. Check by opening one, not by trusting the export.
Verify before cancelling: count records, reproduce a period's figures, check statement continuity, open an attachment. Then store the archive somewhere backed up, shared and independent of any one vendor — and cancel only after all of that is done.
Frequently asked questions
Statements in the archive, data when you need it
Keep the PDFs — they are the evidence, and they carry the balances that make completeness provable. When you need to work with them, convert the lot in one run, with every document checked against its own arithmetic.