During an audit, the question about process documentation is rarely the first one, but it does come. It sounds harmless: how does a business transaction become a posting in your company, and what makes sure that nothing is lost or quietly altered between the source document and the posting? Answering with a folder full of screenshots means having a collection, not a documentation. Being unable to produce anything at all means explaining the workflow verbally — which is exactly the situation the rules are meant to avoid. This article describes what belongs in a process documentation under the German GoBD principles, how detailed it needs to be, how it stays current over the years, and how a company without a dedicated department can build it in a manageable amount of time. It does not replace tax or legal advice: assessing a specific case belongs with the tax adviser who knows the actual bookkeeping.
Key takeaways
- Process documentation describes not the software but the path of a document through the company: from creation through capture, checking and posting to retention, each step with a named responsibility and a control.
- It consists of four parts (GoBD): general description, user documentation, technical system documentation and operations documentation. If one is missing, the documentation is formally incomplete even when the workflow itself runs cleanly.
- The yardstick for detail is not completeness at any price but whether a knowledgeable third party can follow the workflow within reasonable time; for a company with few document types this usually takes fewer than thirty pages (project experience).
- The documentation has to carry its own history: for every point within the retention period it must be clear which version applied, which is why older versions are kept with their date and the reason for the change (GoBD).
- It stays current through triggers rather than an annual date: a new or replaced system, a new interface, a new document type, a changed approval path or a new service provider — each of these calls for a new version.
What process documentation is meant to achieve
The German principles for the proper keeping and retention of books, records and documents in electronic form, known by the abbreviation GoBD, require that a business transaction remains traceable from its origin to its settlement. As long as documents were filed on paper, the folder itself was that proof. Once documents are created electronically, travel through systems, are processed automatically and are eventually archived, the path is no longer visible from the outside. Process documentation makes it visible again: it describes what happens to a document between arrival and retention.
The most common misunderstanding lies in the word documentation. What is meant is not the manual collection of the programs in use, but the description of the procedure inside your own company. A manual for a merchandise management system explains which button triggers which function. The process documentation explains who in the company uses that function, in which order, with which check before it and which filing after it. Two companies running the same software have different process documentation because they work differently.
The second purpose is often overlooked and is the more valuable one day to day: the documentation describes the intended state. If it records that an incoming invoice is checked for substance and arithmetic before it is released for payment, then an internal control has been described as well. Without that description, a query can only be answered by recounting current practice, with no way to show that it was a rule. The difference between regulated and customary is precisely where an audit begins.
Three terms that regularly get mixed up
When it is requested and what its absence can mean
It is not requested continuously but on specific occasions — and then at short notice. The best known occasion is a tax field audit. There are others: a cash inspection in businesses handling cash, questions from the tax adviser during the annual accounts, an audit by a statutory auditor in larger companies, questions from an insurer after a claim, and increasingly requirements from customers who ask for evidence about their suppliers' organisation. In every case the mechanism is the same: the documentation should exist before anyone asks for it.
What its absence means cannot be answered in general terms, and nobody should claim otherwise. Factually the following holds: if the documentation is missing, this can affect the formal correctness of the bookkeeping. Whether that leads to an objection or even to an estimate depends on the individual case, particularly on whether the substantive traceability of the transactions actually suffers (GoBD). The practical consequences usually arrive earlier than the tax ones.
- The audit takes longer because workflows have to be reconstructed in conversation instead of being read up
- Queries go to individual people; if they are on holiday or have left, a gap appears
- When a system is replaced, the description of how the old procedure worked is missing even though the data is still retained
- New staff learn the workflow verbally and pick up deviations along with it that nobody ever decided on
- In disputes with customers, suppliers or insurers there is no evidence that a workflow was intended that way
- For funding applications and customer audits, evidence is missing that could have been prepared without any lead time
Companies handling cash face an additional point: the cash register system in use requires its own process documentation covering its setup, operation and safeguarding (German Fiscal Code). Whether and to what extent this affects your own business is something the tax adviser clarifies on the basis of the actual records. Anyone already maintaining a process description for daily work has done part of the job for both purposes.
The four parts at a glance
The structure of a process documentation is pleasantly stable and has been unchanged for years. It consists of four parts (GoBD) that build on one another and look at the same procedure from different angles: from the outside, from the perspective of the people using it, from the perspective of the technology and from the perspective of operations. This division is not a formality but a workable split: each part has different owners and changes at a different pace.
It is sensible to keep the documentation per procedure rather than as a single work covering the whole company. A procedure is, for example, the path of incoming invoices, order processing, payroll, the scanning of paper documents that are then destroyed, or cash handling. Each procedure gets its own version with its own history. Shared content such as the system landscape, the permission concept and the backup regime is written once centrally and referenced from the individual procedures, instead of being written four times and forgotten three times.
General description
The frame: which procedure is described, which areas and document types are affected, where the documents come from, which systems are involved, who carries the functional responsibility and which retention periods apply. This part is short and rarely changes.
User documentation
The workflow itself as the people handling it see it: receive, capture, check, approve, post, file. Plus corrections, cancellations, cover arrangements and exceptions. This part is the longest and the only one those involved read regularly.
Technical system documentation
The technology behind the workflow: systems and versions in use, data paths between them, interfaces with direction, frequency and format, automated checks, logging, failure handling as well as roles and permissions.
Operations documentation
How day-to-day operation is safeguarded: access control and how rights are granted, backup and recovery, handling of changes to systems, outsourcing of tasks to providers and who decides in the event of a disruption.
In practice the first three parts come together quickly because they are known in-house. The fourth is where things stall: backup, recovery and outsourcing are often arranged but written down nowhere, or they sit with the IT provider in a form that was never handed back to the company. That part overlaps with protection against outages and attacks, for which the German federal authority for information security (Bundesamt für Sicherheit in der Informationstechnik, BSI) has published its own approaches. Working on both at once means writing it down once instead of twice.
General description and user documentation in detail
The general description answers the questions that come before the workflow. Which document types exist at all, and where do they come from: as paper by post, as an attachment in an email, as a file through a portal, as a data record through an interface, or as a document produced by your own system. This list is the core of the part, and it is also the best test of completeness: if writing it down reveals a route that was never covered by any rule, that is already a result.
The user documentation describes the path of each document type through the company. The useful level of detail sits between two extremes: a sentence such as invoices are checked and posted is too little, while a click-by-click guide with a screenshot of every screen is too much and goes out of date with the next program update. In between lies a description in steps, each with three details: what happens, who is responsible, and how it is visible that the step is done.
- Receipt: where does the document arrive, who accepts it, how is its arrival recorded
- Capture: which details are taken over, automatically or by hand, and how is automatic recognition checked
- Assignment: which case, cost centre or project does the document belong to, and who decides in case of doubt
- Checking: substantive and arithmetic checks named separately, with responsibilities and value thresholds
- Approval: who approves, from which amount is a second approval required, how is the approval recorded
- Posting and payment: which system posts, at which frequency, how is payment initiated and reconciled
- Filing: where does the document end up, in which format, under which retention class, and who can find it again
- Deviations: correction, cancellation, duplicate document, complaint, cover during absence
These eight steps carry most commercial procedures in a mid-size company. Describing them properly once for the most frequent document type produces a template that can be adapted for further document types in a short time. One note from practice: the description should be read back by the people who carry out the workflow every day. Experience shows that at least one point emerges where practice differs from what management assumed (project experience) — and that point is worth more than the rest of the document.
Technical system documentation and operations documentation
The technical part does not describe the programs but the routes between them. For each system involved, record what it is the leading source for, which data it hands over and which it receives. For each connection between two systems, four details belong in the documentation: direction, frequency, format and behaviour in case of failure. The last point is missing from almost every existing version we come across, even though it is the most important one when something goes wrong. The building blocks of a sound description of a connection are the same ones used when planning interfaces.
The operations part answers the questions that arise when things do not go to plan. How often is data backed up, to where, how long are backups kept, and when was a restore last tested. Who grants permissions, who withdraws them when someone leaves, and how is that tracked. Which tasks sit with a service provider, what is contractually agreed there, and who is the contact in-house. These details are quickly gathered once they are asked for systematically, and they are the part that builds confidence fastest during an audit.
1 General description
1.1 Purpose, scope, areas affected
1.2 Document types and their origin
1.3 Systems involved and responsible people
1.4 Storage locations and retention periods
2 User documentation
2.1 Receipt and capture
2.2 Assignment to a case
2.3 Substantive and arithmetic checking
2.4 Approval, posting, payment
2.5 Filing and retention
2.6 Corrections, cancellations, cover, exceptions
3 Technical system documentation
3.1 System overview and leading systems
3.2 Data paths and interfaces: direction, frequency, format
3.3 Automated checks, logs, failure handling
3.4 Roles and permissions
4 Operations documentation
4.1 Access control and granting of rights
4.2 Backup, retention, recovery
4.3 Changes to systems and workflows
4.4 Outsourcing to service providers
5 Annexes
5.1 Version history with date and reason for change
5.2 Overview of roles and permissions
5.3 Sign-off by the managementThis structure is a scaffold, not a form. Sections that do not apply to your company stay in place with a short explanation rather than disappearing — the statement that no documents originate from a cash register system is itself a piece of information. Creating the structure as a file and filling the sections one after another produces a first version within a short time that is more complete than most collections that have simply grown.
How detailed does it need to be?
The rules name no page count, and that makes sense. The yardstick is that a knowledgeable third party must be able to follow the procedure within reasonable time (GoBD). Knowledgeable means the person understands commercial workflows but not your company. Reasonable means they should be able to read into it, not to investigate. To test your own version, hand it to someone in-house who has nothing to do with the procedure and let them retell the path of a document. Whatever they have to ask about is missing.
The scope follows almost by itself. For a trades business with incoming invoices, outgoing invoices, delivery notes and time sheets, fewer than thirty pages usually cover all procedures together (project experience). A manufacturing company with merchandise management, shop floor data capture, several interfaces and a warehouse will need more, but the growth sits in the technical part, not in the description of the workflow. Scope grows with the number of procedures and systems, not with the number of employees.
| Element | Too thin | Appropriate | Too detailed |
|---|---|---|---|
| Document types | The blanket term invoices | Each type with origin and path | Every individual document named |
| Workflow | We post as we go | Steps with responsibility and control | Click guide with a screenshot per screen |
| Interfaces | Not mentioned at all | Direction, frequency, format, failure case | Full field lists taken from the technology |
| Permissions | Access for everyone involved | Roles and who grants them | Every individual permission per person |
| Changes | No history at all | Version with date and reason | Every wording fix as its own version |
| Maintenance effort | None, because nothing is maintained | A few hours per trigger | So high that maintenance stops |
The right-hand column is the more frequent mistake among companies that want to do it particularly well. Documentation laid out too extensively goes out of date with the first program update and is never touched again afterwards. An outdated version is arguably worse than a brief one that is correct: it describes a procedure that no longer runs that way, and thereby raises exactly the questions it was meant to answer.
A pragmatic build-up in six steps
Companies without a dedicated department rarely fail on content but on getting started: the task looks large, is assigned to nobody and therefore drifts backwards. The countermeasure is mundane and effective: one named person, a limited initial scope and a date for the first version. The first version is allowed to be incomplete. It needs to exist so that the second one has a basis.
The following order has proven itself. It deliberately does not start with the technology but with the workflow, because the workflow determines which technical details are actually needed. For the first procedure the effort typically amounts to two to four working days spread over a few weeks (project experience); every further procedure goes considerably faster because the scaffold is in place.
Step 1: Delimit the procedures and set an order
List which procedures exist: incoming invoices, outgoing invoices, cash, payroll, scanning with subsequent destruction, warehouse. Then tackle the procedure with the highest document volume first, not the most interesting one. The rest follows in the same structure.
Step 2: Record document types and their origin
For the chosen procedure, note every document type with its route in: paper, email attachment, portal, interface, own creation. This list is the basis for everything else and regularly uncovers routes that were never covered by a rule.
Step 3: Write down the workflow with the people doing it
Walk through the path of a real document together with the person who handles it, and take notes while doing so. Not at the meeting table but at the workplace. For each step record what happens, who is responsible and how completion is visible.
Step 4: Add systems, connections and rights
Only now the technical side: systems involved, leading system per data type, connections with direction, frequency, format and failure case, roles and permissions. Request missing details from the IT provider and take them into the documentation in writing.
Step 5: Complete the operations part and the annexes
Backup, recovery, change procedure, outsourcing, overview of permissions. Then create the version history and have the first version signed off by the management — with a date, because the version applies from that date onwards.
Step 6: Have it reviewed and agree the triggers
Give the version to your tax adviser for review and agree in-house which events will trigger a new version in future. Without that agreement the work ends with the first version, and the documentation ages unnoticed.
List which procedures exist: incoming invoices, outgoing invoices, cash, payroll, scanning with subsequent destruction, warehouse. Then tackle the procedure with the highest document volume first, not the most interesting one. The rest follows in the same structure.
For the chosen procedure, note every document type with its route in: paper, email attachment, portal, interface, own creation. This list is the basis for everything else and regularly uncovers routes that were never covered by a rule.
Walk through the path of a real document together with the person who handles it, and take notes while doing so. Not at the meeting table but at the workplace. For each step record what happens, who is responsible and how completion is visible.
Only now the technical side: systems involved, leading system per data type, connections with direction, frequency, format and failure case, roles and permissions. Request missing details from the IT provider and take them into the documentation in writing.
Backup, recovery, change procedure, outsourcing, overview of permissions. Then create the version history and have the first version signed off by the management — with a date, because the version applies from that date onwards.
Give the version to your tax adviser for review and agree in-house which events will trigger a new version in future. Without that agreement the work ends with the first version, and the documentation ages unnoticed.
Taking the third step seriously produces a side effect that often justifies the effort on its own: writing things down reveals duplicate data entry, media breaks and detours that nobody notices in daily work any more. That same recording is the starting point of a process analysis, with the difference that times and volumes are captured there as well. If both are planned anyway, they are best captured in one pass rather than two.
The history: one valid version per point in time
One point is almost universally overlooked while writing and becomes awkward during an audit: the process documentation is itself subject to retention, for as long as the records it refers to (GoBD). For commercial books, inventories and annual accounts that is ten years (German Fiscal Code), and commercial law imposes a corresponding retention duty (German Commercial Code); for accounting vouchers the period has since been shortened, which is why the specific classification belongs with the tax adviser. In practice this means that if an audit looks at a period three years back, the version from that time is the relevant one, not today's.
A simple rule follows: older versions are not overwritten but archived. Each version carries a number, an effective date, the reason for the change in one sentence, and the name of the approving authority. That costs a few minutes per change and is the difference between a documentation and an up-to-date file. Storing versions in a document system with version control produces this history as a by-product; working with a text file means additionally filing every approved version as an unalterable copy.
The history is the part that cannot be made up later
Staying current: triggers instead of an annual date
The most widespread maintenance rule is to review once a year. It sounds reasonable and rarely works, because changes do not occur on the annual date but when a system is swapped or a responsibility is reassigned. Between the change and the review date lie six months on average during which the documentation is wrong. The reverse approach is more effective: triggers instead of an annual date. Certain events prompt a review of the affected sections, regardless of the calendar.
For that to hold, the triggers have to be known where the change originates. In practice this means that whoever procures a new system or commissions an interface has updating the documentation on the acceptance checklist. The annual date does not disappear, it simply takes on a different job: it checks whether all triggers of the past year have been processed.
- A system is introduced, swapped, retired or receives a major update
- An interface is added, changes direction, frequency or format, or is switched off
- A new document type or payment method appears, for instance through a new sales channel
- Responsibilities change, particularly for checking, approval and granting of permissions
- Value thresholds or approval paths are altered
- A service provider takes over a task, hands it back or is replaced
- A site, a warehouse or a line of business is added or discontinued
- An audit or an incident reveals a gap in the existing description
The most workable maintenance rule is the one attached to an existing sign-off. Making the documentation update the final item of every system acceptance removes the need for a calendar reminder — the change itself is the reminder.
Typical gaps in existing versions
In companies that already have something in place, the gaps repeat themselves. Most often the failure case is missing: what happens when everything works is described, but not what happens when a transfer breaks off, a document is illegible or automatic recognition gets it wrong. Just as often the secondary systems are missing — the spreadsheet in which one department keeps a list, the mailbox through which orders arrive, the form on the website. They are part of the procedure but do not appear in the system overview because nobody regards them as a system.
The third gap concerns the past. When a legacy system is replaced, the documentation often ends with the changeover even though the data from the old system is still subject to retention. What is then missing is the description of how the old procedure worked and how the old data is accessed today. Anyone planning a replacement records the state of the legacy system before it is switched off — a fixed part of replacing legacy systems and hard to catch up on afterwards.
The fourth gap is scanning with subsequent destruction of the paper. As soon as paper documents are destroyed after scanning, a separate procedure with its own documentation applies: which document types are affected, who scans, how quality is checked, when destruction happens and how the unalterability of the image file is ensured. Without that description the approach is open to challenge even when it runs cleanly in technical terms. Anyone starting document digitisation therefore writes the procedure description before the first destruction run, not after it.
Practical tip for the first version
Related Articles
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.
Retention periods digitally: schedules, holds, deletion runs
Retention duties and deletion duties only appear to conflict. How to build a filing concept with periods per record type, legal holds and documented runs.