Should you pseudonymize data before an analytical review? Yes, as soon as a generative AI or an outside provider enters the loop. A general ledger, an accounting export, a bundle of contracts or a sample of expense reports contains names, IBANs, addresses and sometimes salaries. Passing them as-is to an outside analysis tool exposes the people concerned, the client and the firm all at once.
For audit firms, statutory auditors, accountants and finance departments, pseudonymization is the filter that lets you use AI without turning an engagement into a confidentiality incident. Article 32 of the GDPR names it explicitly among the appropriate security measures.
This guide explains what the law says, when pseudonymization is enough, how to pseudonymize a ledger export or an audit corpus, what evidence to keep and which clauses to require from AI tools. The legal references are French and European; the method applies to any firm handling EU personal data.
The golden rule: before sending accounting records or audited documents to an AI or a provider, remove direct identifiers, keep the data usable, and store the mapping table separately, encrypted and under restricted access.
Key takeaways
| Point | Details |
|---|---|
| Pseudonymizing exempts you from nothing | Pseudonymized data is still personal: the GDPR and professional secrecy continue to apply. |
| Anonymization is rare in accounting | The traceability that audit requires makes irreversible anonymization hard to achieve. |
| Consistency is essential | The same customer or supplier must keep the same alias across the whole corpus, or the analysis is worthless. |
| The contract matters as much as the technique | Data processing agreement (article 28), no-training clause, what happens to derived data. |
| Evidence is what makes compliance | An impact assessment where needed, records, access logs for the table, quality control on a sample. |
Table of contents
- The legal framework: professional secrecy and the GDPR
- The risks of an analytical review without pseudonymization
- Pseudonymization or anonymization: when the first is enough
- What to pseudonymize in financial documents
- Technical methods
- The six-step procedure
- Security measures to check
- Derived data and the clauses to require from AI tools
- Documenting the process for regulators and quality review
- Checklist before sending documents to an AI or an analytical review
- Training the teams
- Safe-doc for audit and accounting firms
- Frequently asked questions
- Further reading
- Sources
- Recommended reading
The legal framework: professional secrecy and the GDPR
Professional secrecy
In France, statutory auditors and chartered accountants are bound by professional secrecy for everything they learn in the course of their work. A breach is a criminal offense under article 226-13 of the French Criminal Code. That secrecy still applies after pseudonymization: pseudonymized data remains confidential client information. The CNIL and EDPB recommendations specify what pseudonymization must guarantee.
Secrecy is not absolute when certain legal obligations apply. Suspicious activity reports to TRACFIN, France's financial intelligence unit, for example, must remain strictly confidential: the professional cannot tell the client about them.
The GDPR
The GDPR applies to all personal data found in financial documents: customer names, supplier contact details, IBANs, employee references, expense reports. This information appears in invoices, journals, general ledgers and the FEC, the standardized accounting export French companies must be able to hand to the tax authorities.
Three obligations come up in every engagement. The first is the data processing agreement under article 28 of the GDPR: as soon as a firm or provider processes personal data on behalf of its client, a contract sets out each party's obligations (security, confidentiality, breach notification, subprocessors). Depending on the engagement, the firm may also act as a controller; that characterization should be put in writing.
The second is the record of processing activities under article 30, which must list every use of an AI tool on personal data. The third is the impact assessment under article 35, mandatory when the processing poses a high risk to individuals, which is common with AI on large volumes.
Retention periods
In France, accounting documents and supporting records must be kept for ten years from the close of the financial year (article L123-22 of the Commercial Code). That period does not override the GDPR: during those ten years, the personal data they contain must stay protected, and after that it must be deleted or anonymized.
What the CJEU ruling of September 4, 2025 changes
In its ruling of September 4, 2025 (EDPS v SRB, C-413/23 P), the Court of Justice of the European Union confirmed that the obligation to inform people about who receives their data is assessed from the controller's point of view, at the time of collection. Even if the recipient only gets pseudonymized data and cannot re-identify anyone, the controller must still mention it.
For a firm, the consequence is concrete: document who receives pseudonymized data, in what context and for how long, and check that the information given to individuals reflects it.
The risks of an analytical review without pseudonymization
Submitting raw identifying data to an analytical review or an AI exposes you to three families of risk.
Legal risk. Undocumented processing of personal data, passed to a third party without a contract or safeguards, is a GDPR breach. If it goes to a consumer tool, it may be a data breach that has to be notified.
Ethics risk. Professional secrecy can be broken as soon as a third party (an AI tool, a subcontractor) accesses client information without a contractual framework.
Technical risk is often underestimated. When data goes through a consumer interface, it may be reused to train a model. At a poorly supervised provider, it can be exfiltrated, or transferred outside the European Union without appropriate safeguards. And a document submitted to an AI can contain hidden malicious instructions that hijack the tool.
There is also an analytical risk: visible identifiers can introduce bias. An auditor who recognizes a name in a sample of expense reports may, consciously or not, let it steer their judgment.
Pro tip: Shadow AI has become one of the leading causes of leaks: according to IBM's Cost of a Data Breach 2025 report, it played a part in one data breach in five. A staff member who pastes a ledger extract into a consumer assistant to save ten minutes engages the firm's liability, even if management knows nothing about it. Offering an approved tool with built-in pseudonymization works better than a ban.
Pseudonymization or anonymization: when the first is enough
Pseudonymization replaces identifiers with aliases, with a mapping table kept separately. Anonymization permanently removes any link to the people concerned. Only anonymization takes data out of the GDPR, but it is rarely achievable with accounting data, where traceability back to the source document is still required.
In audit, controlled reversible pseudonymization is generally the right answer: the auditor must be able to trace back to the original entry or document.
Pseudonymization is generally enough for aggregate analysis and consistency checks on large volumes, for governance indicators, or for anomaly detection on a ledger export.
Stronger measures are needed in three situations: when the corpus contains health data or other sensitive data under article 9 of the GDPR (in expense reports or audited HR files, for example); in litigation, where an opposing party might try to cross-match the data; and for named individual analyses, which come close to monitoring people.
In those cases, combine pseudonymization, statistical aggregation, strict access control and active re-identification tests on a sample.
Do not decide the level of protection on the client's behalf. Discuss it at the start of the engagement and document the reasoning, even for a file that looks low-risk to you.
What to pseudonymize in financial documents
| Data | Recommended method | Example replacement |
|---|---|---|
| Last name, first name | Consistent replacement | Jean Dupont → CLIENT_A |
| Company name | Generic code | Société Martin SAS → COMPANY_001 |
| IBAN, bank details | Tokenization | FR76 3000… → IBAN_001 |
| Email address | Tokenization | j.dupont@example.fr → EMAIL_001 |
| Invoice or contract number | Generic identifier | INV-2024-0042 → INVOICE_017 |
| Company registration number, tax ID | Tokenization | 123 456 789 → REG_NO_004 |
| Amounts | Kept, or generalized into ranges if the combination makes someone recognizable | - |
Amounts deserve some thought. They are essential to the analysis, but an exact salary or an unusual transaction can be enough to identify someone in a small organization. If so, generalize (amount ranges) or aggregate.
Pseudonymizing a ledger export
A full accounting export, such as the French FEC, contains every entry for a financial year. Pseudonymizing it means neutralizing the names, but also the entry descriptions that repeat them, invoice numbers, IBANs and tax identifiers. A properly pseudonymized export keeps its full value for an analytical review or AI-based anomaly detection. When a company is sold, the same data goes through a GDPR-compliant data room.
Pro tip: Entry descriptions are the classic blind spot. An export where the subledger accounts are pseudonymized but the description still reads "Salary transfer Mr. Dupont" is not pseudonymized.
Technical methods
| Technique | Principle | Reversible | Use in audit |
|---|---|---|---|
| Tokenization | Replacement with a random token, mapping table kept separately | Yes | Corpus sent to a provider or an AI |
| Generic codes | Stable neutral labels (CLIENT_001, SUPPLIER_042) | Yes, via the table | Analytical review, working papers |
| Keyed hashing | Fingerprint computed with a key kept separately | Not without the key | Matching across files without revealing values |
| Generalization | Value made less precise (amount → range) | No | Statistics, benchmarks |
| Redaction | Permanent removal | No | Documents shared externally |
A plain hash, without a secret key, does not protect an IBAN or a company registration number: these values are predictable and can be recovered by brute force. Use keyed hashing (HMAC) or tokenization.
Local processing or processing at a provider
| Criterion | Local pseudonymization | Sending directly to an external service |
|---|---|---|
| Control over data | Clear-text data never leaves the firm | Depends on the provider's contract and architecture |
| Compliance | Easier: only the pseudonymized corpus goes out | Contractual and technical safeguards to check |
| Leak risk | Limited to the pseudonymized corpus | Clear-text data exposed if there is an incident |
| AI use | Possible without exposing identities | Direct exposure if nothing is masked before sending |
The practical rule: pseudonymize as close to the source as possible, before the document leaves the firm's workstation or systems.
The six-step procedure
Start by preparing the corpus: scanned documents go through optical character recognition, then hidden metadata (author, history, comments) is removed. Next, classify the data into three families: confidential (contracts, financial statements), personal (names, IBANs, addresses) and public.
Identifier detection combines automatic entity recognition (names, places, numbers) with business rules for the formats of IBANs, company registration numbers or invoice numbers. Substitution must be consistent: each entity gets a stable alias across the whole corpus. If the same person changes alias from one document to the next, matching becomes impossible.
The mapping table is then isolated: encrypted, on a separate medium, with restricted and logged access. The last step is quality control: check a sample by hand and try to identify people from context. If an outside reader can do it, the pseudonymization is not good enough.
Human review is not optional. The pseudonymization guide published by Etalab, the French government's data team, for court decisions shows that even the best automatic engines let errors through without review. Plan a human review of 5 to 10% of the sample at the start of each new document type, re-identification tests to confirm that no simple cross-matching remains possible, and tracking of the detection error rate over time. The Safe-Doc MCP server lets an agent do this without ever seeing the real data.
Pro tip: Appoint a single owner for the mapping table. They approve every re-identification request and keep a log of lookups. That log is one of the first pieces of evidence requested during an inspection.
Automate pseudonymization through an API or a built-in module rather than one-off manual processing. A habit that depends on the memory of a tired colleague on a Friday evening always ends up being skipped. To build it into your tools, see our guide to the document pseudonymization API.
Security measures to check
Article 32 of the GDPR requires security measures suited to the risk. It is an obligation of means: a lack of measures can be penalized even without a leak. The personal data security guide published by the CNIL, France's data protection authority, in 2024 details the measures expected. These come up in every engagement:
| Measure | Evidence expected | Priority |
|---|---|---|
| Individual accounts, no shared accounts | List of accounts | Critical |
| Multi-factor authentication on remote and privileged access | Configuration | Critical |
| Encryption in transit and at rest | Server and workstation configuration | Critical |
| Contracts with subprocessors (article 28) | Signed contracts | Critical |
| Access logging | Timestamped, retained logs | High |
| Tested backups | Restore test reports | High |
| Regular updates | Patch history | High |
| Breach management procedure | Written procedure, incident log | High |
| Staff awareness | Training certificates | Medium |
Derived data and the clauses to require from AI tools
An auditor handles three categories of data, each with a different status:
| Category | Origin | Main risk | Protection |
|---|---|---|---|
| Source data | The client: financial statements, contracts, statements | Unauthorized disclosure | Restricted access, encryption, pseudonymization |
| Operational data | The auditor: notes, analyses, working papers | Excessive retention | Formal retention policy |
| Derived data | The tools: prompt logs, outputs, fine-tuned models | Reuse by the vendor | Explicit contract clause |
The third category is the most exposed. If the contract with an AI vendor says nothing about derived data, the logs of your prompts or the generated outputs may be kept, or even reused. These clauses are covered in our guide to contracts with AI vendors.
The contract must first prohibit using your data to train the vendor's models, and settle what happens to derived data (logs, outputs), with a deletion deadline. It gives the list and location of subprocessors, and grants you an audit right.
Finally, it provides for breach notification within a timeframe compatible with your own obligations, and processing located in the European Union, or appropriate safeguards for any transfer.
Pro tip: Always ask for the list of subprocessors and where they are located. A tool advertised as hosted in Europe may rely on infrastructure elsewhere for some operations.
Documenting the process for regulators and quality review
An auditor or an inspector can only attest to what they can verify. Declaring compliance is not enough.
The impact assessment must describe the purposes of the processing, assess necessity and proportionality, evaluate residual risks after pseudonymization, list the technical and organizational measures, and present the results of robustness tests (GDPR article 35(7)).
The record of processing activities states the scope, legal basis, retention periods, outgoing data flows, signed contracts and data location.
The evidence to keep falls into two groups. On method: the settings of the pseudonymization applied, quality control reports on samples and the results of re-identification tests. On security and framework: the access logs for the mapping table and the signed contracts with each provider.
Responding to an inspection or a breach
In an inspection, first appoint a single point of contact for exchanges with the authority. Quickly gather the records, the data processing agreements and the latest impact assessments, and check that the records actually describe the tools in use. If a breach poses a risk to individuals, the regulator must be notified within 72 hours (GDPR article 33).
Checklist before sending documents to an AI or an analytical review
Before sending, start with the document itself. Direct identifiers (names, IBANs, addresses, numbers) must be replaced, and descriptions, headers, comments and metadata handled too. Pseudonymization must be consistent across the whole corpus, and quality control done on a sample.
Then check the framework. The mapping table is stored elsewhere, encrypted and with logged access. A data processing agreement is signed with the provider, with a ban on training. Hosting meets the client's location requirements, and the processing appears in the records, with an impact assessment if needed.
Training the teams
Most confidentiality breaches at firms do not come from a technical flaw but from an everyday action: a client file sent to an online translation service, an extract pasted into a consumer AI, a report sent by unencrypted messaging. These unsanctioned habits are part of Shadow AI, which is better framed than banned.
Start by explaining why pseudonymization protects both the firm and the client: a rule people understand is applied better than a rule imposed on them. Prefer short reminders each time a new tool is rolled out over an annual session, and keep a clear, up-to-date list of approved and banned tools.
It is also an obligation: since February 2025, article 4 of the EU AI Act requires companies that use AI systems to ensure a sufficient level of AI literacy among their users. Document the training.
Confidentiality is not just a constraint. A client who knows their data is handled rigorously shares their risk areas with the auditor more readily. That is what makes a complete audit possible.
Safe-doc for audit and accounting firms
In an analytical review, you need to remove identities without breaking the matching. Safe-doc gives a supplier or an employee the same alias in every file of a batch, whether PDFs, Word files, spreadsheets or text exports.
Volumes are processed in batches through the API, or directly from an MCP-compatible assistant. Nothing is kept after processing, the mapping table stays at the firm, and the residual risk report adds a document to the working file. See the page for accounting firms.
Frequently asked questions
Should you pseudonymize before an analytical review?
Yes, as soon as the data leaves the firm or goes through an AI tool. Pseudonymization protects the people concerned and professional secrecy, while keeping the data usable for analysis.
Is pseudonymization enough to comply with the GDPR?
It is a security measure recommended by article 32 of the GDPR, but it does not remove the data's status as personal data. Legal basis, informing individuals, retention periods and security are still required.
How long should accounting documents be kept?
In France, ten years from the close of the financial year (article L123-22 of the Commercial Code). After that, the personal data they contain must be deleted or anonymized.
How do you pseudonymize a ledger export?
By replacing names, company names, IBANs, invoice numbers and tax identifiers with stable codes (CLIENT_001, IBAN_001), including in entry descriptions. The mapping table is kept separately, encrypted, with restricted access.
Can you use ChatGPT or Claude on a general ledger?
Yes, if the file is pseudonymized before sending, the tool is covered by a suitable contract (no training, location, deletion) and the use appears in the records. Without those conditions, the firm exposes its clients and its professional secrecy.
What did the CJEU ruling of September 4, 2025 change?
It confirms that the controller must tell individuals who receives their data, even when those recipients only get pseudonymized data. Firms must therefore document every flow of pseudonymized data.
Which clauses should you require from an AI vendor?
No training on your data, what happens to derived data and when it is deleted, the list and location of subprocessors, an audit right and breach notification.
Further reading
- Data rooms and the GDPR: the evidence to require before due diligence
- GDPR compliance for consulting firms: protecting your clients' data
- Document pseudonymization API: the guide for developers and CISOs
Sources
- CNIL: security, risk analysis (in French)
- CNIL: anonymizing personal data (in French)
- Etalab: pseudonymization guide for court decisions (in French)
- IBM: Cost of a Data Breach Report 2025
This article is general information and does not replace advice from a qualified lawyer. Consult a legal professional about your situation before acting on this content.