GDPR and Client Bank Statements: What Accountants Need to Know
A bank statement is about as personal as personal data gets: names, account numbers, salaries, medical payments, memberships, locations. When a client hands you their statements, you become a processor (or controller) of that data under UK and EU GDPR, and how you handle the file matters as much as what you do with the numbers.
This article covers the obligations that actually bite in practice, and the specific risk that statement-conversion tools introduce.
Your obligations in practice
GDPR does not prescribe tools, it prescribes outcomes. For client statements the relevant duties come down to a short list:
- Lawful basis and purpose limitation: use the statements for the engagement, nothing else
- Data minimisation: do not collect or retain more of the statement data than the work requires
- Security of processing (Article 32): protect the files in transit and at rest
- Processor accountability: know which third parties touch the data, and have agreements in place
- Breach notification: if a service you used leaks the file, that is your breach to report
Where statement converters create risk
The typical online "PDF to Excel" converter works by uploading the file to a server, parsing it there, and returning the result. The moment that upload happens, you have engaged a processor: you now need to know where that server is, how long the file is retained, who can access it, whether it is used for model training, and whether the provider will sign a data processing agreement. Most free converters answer none of those questions, and a statement sitting in an unknown server's temp directory is exactly the kind of exposure Article 32 is about.
Emailing statements around has the same problem in a different shape: unencrypted copies proliferate in sent folders, inboxes and backups, and none of them have a retention policy.
Client-side processing changes the analysis
PivotBank takes a different architecture: the PDF is parsed inside your browser using WebAssembly, and the file is never uploaded. There is no server-side copy, no retention question, no sub-processor handling the raw statement, because the statement never leaves your machine. You can verify this yourself: open your browser's network tab during a conversion, or disconnect from the internet after the page loads, and the conversion still runs.
From a GDPR standpoint this collapses most of the risk assessment. The processing happens on hardware you already control under your existing security measures. The only data that ever reaches PivotBank's servers is the extracted transactions of statements you explicitly choose to save to an account, and those can be deleted at any time.
A sensible workflow for firms
A defensible client-statement workflow looks like this:
- Receive statements through a portal or encrypted channel rather than plain email where possible
- Convert locally (client-side) rather than uploading to third-party servers
- Import the converted CSV into your accounting platform, which is already covered by your DPA with that vendor
- Delete working copies of the PDFs per your retention schedule
- Document the flow once in your processing records, so the answer to "where does client statement data go?" is written down