Two requirements meet in the same body of data and appear to contradict each other. German commercial and tax law requires certain records to be retained for years, kept legible and produced on request during an audit. Data protection law requires personal data to be erased once the purpose has been fulfilled and no legal basis remains. In many companies this conflict ends in a tacit decision: keep everything, because nobody wants to take responsibility for a deletion and because storage has become cheap. Convenient, but not permissible. This article describes how both sides come together in a single filing concept: a retention schedule per document type, legal holds for pending cases, and deletion runs that are logged. It is written for companies that have already digitised their paper filing or are preparing to, and it adds the organisational side to the technical side of document digitisation. The explanations below are general and do not replace legal advice; assessing a specific case belongs in expert hands, usually those of a tax adviser and, for personal data, a data protection specialist.
Key takeaways
- Retention duties and deletion duties only conflict as long as the data is treated as a single block; broken down by document type, every record can be given a clear answer on how long it stays and when it disappears.
- The basic tax periods are ten years for books, inventories and annual accounts, eight years for accounting vouchers and six years for commercial and business letters, each starting at the end of the calendar year in which the record was created (German Fiscal Code).
- Keeping everything is not the safe option but a breach in its own right: the storage limitation principle requires erasure once the purpose is met, and a retention duty only justifies the records it actually names (GDPR).
- Legal holds keep individual cases out of the deletion run while an audit, a dispute or another proceeding is pending; they are set with a reason, a date and a responsible role, and are released with the same documentation.
- A deletion run only counts once it is logged and covers the copies as well: mailboxes, spreadsheets on shared drives, legacy systems and backups fall under the same rule as the leading archive.
Two duties, one body of data
The retention duty comes from commercial and tax law. It addresses the company as a merchant and taxpayer and says, in substance: certain records must remain available long enough for a knowledgeable third party to follow the course of business within a reasonable time. This covers books and records, inventories, annual accounts, accounting vouchers and the commercial and business letters received and sent. Electronic retention adds a second requirement: the records must stay unalterable, legible and machine-readable, and the way this is achieved must be described. That description is the process documentation required under the German principles for the proper keeping and retention of books (GoBD).
The deletion duty comes from data protection law and targets something different: not records, but personal data. The storage limitation principle requires data to be kept in a form that allows identification of a person only for as long as the purpose demands (GDPR). Once the purpose falls away and no other legal basis applies, a deletion duty arises. Data subjects can also request erasure themselves, and the company then has to check whether one of the statutory exceptions applies, such as an existing retention obligation.
The apparent contradiction dissolves as soon as the data stops being treated as one mass. An outgoing invoice contains personal data and is subject to a retention duty: it stays until the period expires and is deleted afterwards. An unsuccessful application also contains personal data but carries no retention duty: it goes once the process has ended and the period for possible claims has passed. An access log in the document archive serves traceability and needs its own, usually shorter, retention period. The question is never whether to retain or to delete, but for how long, starting when, and what happens afterwards.
A retention period is not a minimum term for everything
Why "keep everything just in case" does not hold up
Keeping everything looks low-risk because it avoids one visible failure: a missing record during an audit. In exchange it creates failures that are less visible and only surface when somebody asks. The storage limitation principle is not a matter of discretion but a requirement whose observance the company must be able to demonstrate. Anyone without a deletion rule cannot produce that demonstration, regardless of whether harm ever occurred. On top of that comes the record of processing activities, which has to state the envisaged deletion periods (GDPR). A record whose entry reads "indefinite" is of little help when questions arrive.
The second objection is economic. A growing data set costs attention rather than storage. Every subject access request, every search for a case and every migration into a new system has to cover the entire holding. A company carrying twenty years of filing migrates twenty years at the next system replacement and searches twenty years for every request. The effort behind a single access request rises with every location where something might still be sitting.
The third objection concerns security. Data that no longer exists cannot leak. The German Federal Office for Information Security explicitly recommends limiting data holdings to what is necessary and maintaining deletion concepts (BSI). An old personnel folder on a network drive that nobody has opened for years is just as exposed in an incident as the current customer file, but no longer produces any benefit.
- Not demonstrable. Without a documented deletion rule, compliance with storage limitation cannot be evidenced, and the burden of proof sits with the company (GDPR).
- Not answerable. Anyone who does not know where everything sits can neither give complete information nor carry out a complete erasure.
- Expensive at every replacement. Every system replacement and every migration drags the legacy holding along unless it is cleared first.
- Larger attack surface. Holdings without a purpose increase potential damage without delivering anything in return (BSI).
- Risky internally. Old personnel and application data in open filing raises employment and data protection questions that could have been avoided.
Which period applies to which record
The basic tax periods are manageable. Ten years apply to books and records, inventories, annual accounts, management reports and the opening balance sheet. Accounting vouchers also carried ten years; in 2024 this was reduced to eight, with a transitional rule for vouchers whose period was still running at that point and a separate rule for certain financial service providers (German Fiscal Code). Six years apply to commercial and business letters received, to copies of those sent, and to other records where they matter for taxation. Commercial law follows the same structure for merchants (German Commercial Code).
Alongside these sit periods from other areas of law that are more often overlooked. Payroll accounts must be kept until the end of the sixth calendar year following the last entry (Income Tax Act). Records of working time must be kept for at least two years (Working Hours Act), as must the records required under the Minimum Wage Act. Social insurance records follow their own logic tied to the audit cycle. And regardless of any retention duty, it can make sense to keep contract records for as long as claims can be brought from them; the standard limitation period is three years and starts at the end of the year in which the claim arose (German Civil Code).
| Type of record | Usual period | Basis | Afterwards |
|---|---|---|---|
| Annual accounts, books, inventory | 10 years | Fiscal Code, Commercial Code | Deletion unless another reason applies |
| Accounting vouchers, invoices | 8 years | Fiscal Code (2024 reduction) | Deletion, check transitional cases |
| Commercial letters, quotations that led to an order | 6 years | Fiscal Code | Deletion, in the mailbox as well |
| Payroll accounts and related vouchers | 6 years from last entry | Income Tax Act | Deletion after the audit closes |
| Working time records | 2 years | Working Hours Act, Minimum Wage Act | Deletion, no collective archive |
| Applications without a hire | short, after the process ends | GDPR, periods for possible claims | Deletion, talent pool consent kept separate |
| Access and change logs in the archive | short to medium, purpose-bound | GDPR, GoBD | Deletion after a defined duration |
The table works as a starting point, not as a decision. How a specific record is classified depends on its content, not on its file name: a quotation without a subsequent order is something different from a quotation that became the basis of a contract. That is precisely why the retention schedule is drawn up together with the tax adviser and reviewed once a year.
When the period starts and when it does not expire
The second mistake after the wrong period is the wrong starting point. Tax retention periods do not begin on the date of the record but at the end of the calendar year in which the last entry was made, the voucher was created or the record was completed (German Fiscal Code). An invoice from February 2026 therefore only starts its period on 31 December 2026. For contracts with a term, it also has to be settled whether the last entry coincides with signature or with the final settlement arising from it. Configure the starting point incorrectly and you either delete too early or carry an extra year.
More important still is the suspension of expiry. The period does not end insofar as the records matter for taxes whose assessment period has not yet expired (German Fiscal Code). In practice this means that a tax audit under way, a pending appeal or a provisional assessment extends retention for the affected records beyond the basic period. A deletion run that works strictly by year can remove records that are still needed in such a situation. Every filing concept therefore needs a second mechanism alongside the period: the legal hold.
Together the two produce a simple rule for the technical side: deletion happens when the period has expired and no hold is set and no other retention reason applies to the same record. All three conditions have to be representable in the system, otherwise the deletion run stays manual work that lapses at the first staffing bottleneck.
Document type | Period | Starts | Hold possible | Location
---------------------+---------+---------------------+----------------+-------------------
Outgoing invoice | 8 years | 31 Dec invoice year | yes | Archive, entity A
Incoming invoice | 8 years | 31 Dec voucher year | yes | Archive, entity A
Annual accounts |10 years | 31 Dec closing year | yes | Archive, entity A
Quotation with order | 6 years | 31 Dec order year | yes | Archive, sales
Quotation, no order | 2 years | 31 Dec quote year | no | Archive, sales
Working time record | 2 years | 31 Dec record year | yes | HR filing
Application rejected | 6 months| end of the process | yes | HR filing
Access log |12 months| date of the event | no | System filing
Note: each line also names a responsible role and the date of the last
review. Without those two entries the schedule ages silently.The retention schedule as the core of the concept
A filing concept does not start with folder structures but with a list of document types. For the daily work of a mid-size company, 20 to 40 types are usually enough to cover the vast majority of the volume (project experience). Anything beyond that falls into a catch-all category that is deliberately kept small and reviewed regularly. Each type gets four entries: the period, the point at which it starts, whether a hold can be set, and the location where the leading version sits. Only then comes the question of what the filing looks like technically.
The location is the part that decides whether the concept works. A retention schedule that only covers the archive system, while the same records also sit in mailboxes, on shared drives and in a legacy system, describes a wish rather than a state. The stocktake therefore has to include an honest survey of every place where documents arise and stay, and a decision on which place is the leading one. All other versions are either abolished or explicitly declared as copies subject to the same deletion run. That decision then belongs in the process documentation so that it survives a change of staff.
Document types, not file formats
Sorting follows what a document is in business terms, not the format it arrives in. An incoming invoice stays an incoming invoice whether it enters as a structured data set, an image file or on paper.
A start date the system can derive
The starting point has to follow from a field that is maintained anyway: voucher date, order year, leaving date. A start date that somebody has to type in by hand ends up maintained incompletely once volume rises.
The hold as its own attribute
A legal hold is not a comment field but an evaluable attribute with a reason, a date and a responsible role. Only then can you later answer why a case exceeded the basic period.
One leading location
Exactly one location is designated as leading per document type. Copies elsewhere are permitted but fall under the same deletion rule and are named in the concept rather than tolerated in silence.
Legal holds for pending cases
A legal hold takes a defined part of the holding out of the next deletion run because there is a reason to keep it longer. Typical reasons are an announced or ongoing tax audit, a dispute or a seriously threatened one, an open warranty matter, a pending administrative proceeding, or a data subject request still being processed. The hold is thus the counterpart to the period: the period governs the normal case, the hold covers the exception, and together they produce a decision that can be justified.
For a hold to carry weight it needs four entries: scope, reason, date and the person or role that set it. Scope is the hardest of the four. Set it too narrowly and records belonging to the same matter go missing later. Set it too broadly and the hold becomes a substitute for the deletion concept, letting the holding grow without limit through the back door. What works well is to define scope by matter rather than by time span: all records relating to one customer case, one construction project, one employment relationship.
Releasing a hold matters as much as setting one. A hold that nobody lifts turns into a silent permanent archive. Every hold therefore carries a review date on which the responsible role confirms whether the reason still applies. Once the proceeding ends, the hold is lifted and the affected records either join the next regular deletion run or, if their period expired long ago, are picked up immediately. The release is logged just as the hold was.
A legal hold without a review date is not a hold but a decision never to decide again.
The documented deletion run
The deletion run is the point at which a concept turns into practice. In most companies one or two runs a year are enough, sensibly placed after the annual accounts and after any pending audits have closed (project experience). What matters is less the frequency than the repeatability: the run has to be described well enough for a different person to carry it out, and it has to leave behind a result that can be produced later.
A proven sequence works in two stages. First the system produces a proposal list: every record whose period has expired and for which no hold exists, grouped by document type and year. That list goes to the responsible roles for approval, not for an item-by-item content review but to confirm that no known reasons stand in the way. Deletion only follows approval. The log records what was deleted, in what quantity, under which rule, when and by whom. It deliberately contains volumes and identifiers rather than content, so that it does not build up a new personal data holding of its own.
The forgotten copies
A cleanly executed deletion run in the archive system achieves little while the same records sit untouched in four other places. Those places are the same in almost every company: personal and shared mailboxes holding invoices and contracts as attachments; drive folders with printouts, interim versions and spreadsheets; legacy systems left readable "just in case" after a replacement; and backups preserving a state that no longer exists in the business.
For mailboxes and drives the answer is organisational: they are named in the concept as filing locations and receive the same rule as the archive. Where an automatic rule is not technically possible, a recurring task takes its place, carried out and logged in the same rhythm as the deletion run. For legacy systems the answer is a decision: either the records subject to retention are transferred into a legible and machine-readable format, or the system stays in place with a stated purpose and restricted access. Both are defensible, quietly leaving it running is not; this point belongs early in any project to replace legacy systems.
Backups are a special case that often causes uncertainty. A backup serves recovery after a failure and is overwritten on a fixed cycle. It is common practice not to remove deleted data retroactively from existing backup sets, but instead to ensure that the backup itself has a limited retention cycle and that deletions are re-applied after a restore. What matters is that this handling is described rather than left as an unresolved gap; the assessment in a specific case should be checked by a specialist.
The copies are the real holding
Access, traceability and process documentation
Besides duration, a filing concept also governs access. Records subject to retention must stay legible and machine-readable throughout the period, and changes to them must be recognisable (GoBD). In practice that means three things: an archived document is not overwritten but supplemented by a new version; access is governed by role so that not every person can open every personnel file; and the formats in use are chosen so that they can still be opened in eight or ten years.
The second part concerns the description itself. Process documentation records how documents enter the company, how they are captured, indexed, filed, secured and deleted, and who is responsible for each step. It is not an end in itself but the answer to the question an audit actually asks: how do you ensure that things run the way you describe them? A retention schedule without process documentation remains a statement of intent. The reverse also holds: documentation that does not match the actual workflow does more harm than none, because it evidences a deviation.
Where scanning is involved, the handling of the paper original belongs in the same document. Whether and when paper vouchers may be destroyed after scanning depends on the type of voucher and on how the scanning process is set up, and it forms part of the same documentation. That decision should be taken before the first scanning batch and agreed with the tax adviser rather than afterwards.
From stocktake to first run in four weeks
The effort for a first workable concept is smaller than the people involved usually expect, as long as the scope stays clearly bounded. Four weeks with a few hours of involvement per week are enough in a mid-size company to get from the stocktake to the first deletion run (project experience). The order matters: record first, decide second, implement third. Start with the technology and you build a rule for a holding you do not yet know.
It also helps to keep the first run small. A single document type with a clear period and an unambiguous starting point, such as quotations that never became orders, works well as a test case. It shows whether the proposal list is right, whether approval works and whether the log contains what it should. Only afterwards come the areas with holds and multiple filing locations.
Week 1: record document types and locations
Which types of document arise in the business, where do they arise and where do they end up? The survey follows the workflows, not the folder structure. The result is a list of types, volumes and locations.
Week 2: set periods and starting points
For each document type, enter the period, the starting point and whether a hold is possible, then agree it with the tax adviser. Unclear cases are marked rather than estimated, so that open questions stay visible.
Week 3: settle holds and responsibilities
Who may set a legal hold, who releases it, how often is it reviewed? The same step defines which roles approve the proposal list and what happens if an approval does not arrive.
Week 4: test run with one document type
Produce the proposal list, obtain approval, delete, log. The test run exposes the gaps the concept did not show, above all copies in mailboxes and on shared drives.
Afterwards: annual review
Once a year the retention schedule is re-read, open holds are checked and new document types are added. Without that appointment the concept ages silently and the first deletion run stays the only one.
Which types of document arise in the business, where do they arise and where do they end up? The survey follows the workflows, not the folder structure. The result is a list of types, volumes and locations.
For each document type, enter the period, the starting point and whether a hold is possible, then agree it with the tax adviser. Unclear cases are marked rather than estimated, so that open questions stay visible.
Who may set a legal hold, who releases it, how often is it reviewed? The same step defines which roles approve the proposal list and what happens if an approval does not arrive.
Produce the proposal list, obtain approval, delete, log. The test run exposes the gaps the concept did not show, above all copies in mailboxes and on shared drives.
Once a year the retention schedule is re-read, open holds are checked and new document types are added. Without that appointment the concept ages silently and the first deletion run stays the only one.
A starting point in one morning
Related Articles
Data protection when digitising processes: in practice
Data protection in a digitisation project: the record of processing, a legal basis per operation, processor contracts, access rights, deletion and measures.
GoBD-compliant storage: immutability and evidence
Immutability, traceability, machine analysability: what the German GoBD mean for digital document storage and what belongs in the process documentation.
Digital personnel files: access, retention, evidence
Which section of a personnel file carries which retention period, who may access it, what gets logged, and how inspection and access become routine cases.