A tax audit rarely asks about the source code of your middleware. It asks: how did this particular document come into existence, and how did it reach the accounts? The GoBD, Germany's principles for the proper keeping and retention of books and records in electronic form, require clearly structured process documentation for every IT system connected to bookkeeping, showing the content, structure, sequence and results of the procedure completely and coherently (Bundesministerium der Finanzen). It must be understandable and therefore verifiable by a knowledgeable third party within a reasonable time (Bundesministerium der Finanzen). This is exactly where shop-to-ERP interfaces fail in an audit: the shop has documentation, the inventory system has documentation, financial accounting has documentation -- but the path of the document from order completion through middleware and inventory management to the posting is described nowhere. This article shows how to fill the four components of process documentation for interfaces and middleware -- from data flow diagrams through field mapping and document number ranges to logging, restart procedures and retention.
Why the interface becomes the blind spot of an audit
A German tax field audit is not a rare event. In 2024, 12,359 auditors were working in the field audit services of the federal states and established additional tax revenue of around 10.9 billion euros (Bundesministerium der Finanzen). Of the 8,832,707 businesses recorded in the tax offices' register, 140,764 were audited, which corresponds to an average audit rate of 1.6 percent (Bundesministerium der Finanzen). That average is misleading, however: for large enterprises the rate was 29.6 percent, for medium-sized enterprises 18.5 percent (Bundesministerium der Finanzen). Companies that reach a relevant size are generally audited on a recurring basis -- looking back over an audit period averaging 3.3 assessment years for large enterprises (Bundesministerium der Finanzen).
Those three-plus years of hindsight are the core of the problem. The interface that processed the audited period has often already been replaced, migrated or moved to a new API version by the time the audit begins. The team that built it is a different one. The field mapping from back then survives, at best, in a Git history that an auditor can neither read nor is required to read. The auditor's question is not: how does your interface work today? It is: how did it work in the year in which this document was created?
On top of that comes an organisational gap that is structurally built into integration projects. Where bookkeeping or digital document management is distributed across several parties, the overall process generally spans up to three areas of responsibility: the party obliged to keep the books or records, the tax advisory firm, and the IT company (AWV Muster-Verfahrensdokumentation). Each of these areas must be covered either in joint process documentation or in separate documentation. If there is no joint documentation covering the overall process, mutual cross-references are required that take the system and process transitions into account (AWV Muster-Verfahrensdokumentation). Those transitions are precisely the interfaces -- and that is precisely where each of the three individual sets of documentation usually stops.
Three complete sets of documentation still do not make a complete chain
What the GoBD actually require
The authoritative text is the GoBD version dated 28 November 2019 as amended by two subsequent letters (IHK für München und Oberbayern). The Federal Ministry of Finance letter of 11 March 2024 (file reference IV D 2 - S 0316/21/10001 :002) applies from 1 April 2024 (Bundesministerium der Finanzen). In addition, the letter of 14 July 2025 applies, which aligned the GoBD with the German e-invoicing rules (IHK für München und Oberbayern). Anyone citing an older GoBD version as the basis of their documentation is working from an outdated state.
The central requirements for process documentation sit in section 10.1 of the GoBD. Margin number 151 requires clearly structured process documentation for every IT system and makes clear that its scope is determined by what is necessary to understand the procedure, the books and the retained records (Bundesministerium der Finanzen). Margin number 152 describes the subject matter: the organisationally and technically intended process, from the creation of the information through indexing, processing and storage to unambiguous retrieval, machine evaluability, protection against loss and falsification, and reproduction (Bundesministerium der Finanzen). Translated into integration terms, that is a remarkably precise description of what middleware does to a document.
Particularly relevant for interfaces is margin number 66: the process documentation must show how electronic documents are captured, received, processed, output and retained (Bundesministerium der Finanzen). Those five verbs are effectively a table of contents for the interface section of the documentation. In addition, the description of the internal control system is explicitly part of the process documentation (Bundesministerium der Finanzen) -- reconciliation routines, four-eyes approvals and plausibility checks in the middleware therefore belong inside it, not in a separate operations manual.
| GoBD requirement | Reference | What it means for the interface |
|---|---|---|
| Structured process documentation for every IT system | No. 151 | Middleware is an IT system in its own right, not an appendix to shop or ERP |
| Verifiable by a knowledgeable third party within a reasonable time | No. 151 | Business language instead of source code, diagram before configuration file |
| Describe the process from creation to reproduction | No. 152 | Order completion, mapping, handover, posting and archive as one chain |
| Capturing, receiving, processing, output and retention of documents | No. 66 | A ready-made outline for the interface section |
| Description of the internal control system | No. 102 | Document reconciliation, approvals and plausibility checks |
| Program identity and historically traceable changes | No. 154 | Versioned mappings with a change history across the retention period |
Missing documentation does not automatically invalidate the books
The four components, translated to interfaces
Under margin number 153 of the GoBD, process documentation generally consists of a general description, user documentation, technical system documentation and operating documentation (Bundesministerium der Finanzen). These four components are well established for ERP systems; for interfaces they are rarely filled in. Yet each component maps cleanly onto the integration layer.
One point matters here: process documentation does not have to consist of a single self-contained document. It can consist of a combination of documents linked together by an umbrella document (AWV Muster-Verfahrensdokumentation). Essential parts often already exist -- as a work instruction, an organisational instruction, a system description or a workflow description -- without having been created explicitly for this purpose; their label is irrelevant as long as they cover the required content (AWV Muster-Verfahrensdokumentation). In integration projects that means: the API concept, the mapping sheet and the operations manual are already a large share of the work. What is missing is the umbrella document that ties them into one document path.
1. General description
Which channels feed in bookkeeping-relevant documents: own shop, marketplaces, procurement portals, offline orders? Which document types arise: order, invoice, cancellation, credit note, return? Where do the system boundaries run between shop, middleware, inventory management and financial accounting, and who owns which section? This is the layer an auditor reads first.
2. User documentation
What do people do within the procedure? Who releases a document sitting in the error queue? Who may change a mapping, who may cancel a posting? Which screens and roles exist, and which manual steps are foreseen in the event of an error? This is also where you state what explicitly must not be altered by hand.
3. Technical system documentation
Data flow diagram per channel, field mapping with source and target fields, document number ranges and how they are assigned, interface protocols and data formats, idempotency keys, schema versions. This layer is produced by a development team anyway -- usually just not in a form an auditor can read.
4. Operating documentation
How the operation runs: schedules and triggers for transfers, monitoring and alerting, error and restart procedures, handling of the dead letter queue, backups, access rights, retention of raw data. This is where it is decided whether a stranded document gets noticed.
Data flow diagram and field mapping per channel
The single most effective building block is a data flow diagram per channel. Not per system -- per channel. A shop document, a marketplace document and a document from a procurement portal take different routes, carry different number ranges and may end up in different revenue accounts. Merging those routes into a single diagram produces exactly the vagueness that triggers follow-up questions in an audit. How several sales channels can be routed through a shared integration layer is described in our article on marketplace integration via middleware.
Per channel, the diagram should show at least four stations: the triggering event, handover to the middleware, processing in the inventory system, handover to financial accounting. Every edge needs an answer to three questions: what is transferred, when is it transferred, and what happens if the transfer fails? With that, the auditor is already at traceability -- without having seen a single line of code.
- Data flow diagram per sales channel with named systems, directions and triggers
- Field mapping as a table: source field, target field, transformation rule, mandatory yes or no, default value
- Document number ranges per channel and document type, including the issuing point and the check for gapless sequences
- Handling of rounding, currencies and tax codes at the edge to accounting
- Assignment of payment methods and revenue accounts per channel
- Defined sorting and search criteria so that a single document stays findable across all stations
Document number ranges deserve particular attention. As soon as several systems assign numbers -- the shop an order number, the inventory system a sales order number, financial accounting a document number -- the documentation has to show how those numbers map unambiguously onto one another. Without that bridge, a progressive check from document to posting and a retrograde check from posting back to document are barely feasible. How to prepare the field level systematically is shown in our article on data mapping between ERP and shop. For the tax-relevant field level, our article on tax determination in the B2B shop is worth a look as well.
The acid test for every diagram
Cancellations, credit notes and returns
The standard case is rarely the problem. An order is placed, a sales order is created, an invoice is posted -- almost every set of documentation describes that path. The exceptions are what get critical, for one simple reason: they change facts that have already been posted. That is exactly where the principle of immutability applies, and exactly where auditors look.
For each exception, the documentation must show which document is created, which number range it runs in, which system produces it and how it relates to the original document. A cancellation that silently overwrites the original document in the shop is a compliance problem, not a detail. The operational side of returns handling is covered in our article on the RMA process between shop and ERP.
| Case | What must be documented | Typical gap |
|---|---|---|
| Cancellation before posting | Who may cancel, which status is set, whether a document is created | Shop resets the status without the middleware learning about it |
| Cancellation after posting | Cancellation document with its own number range and a link to the original | Original document is overwritten instead of cancelled |
| Credit note | Trigger, calculation basis, tax code, account assignment | Credit note is created manually in the ERP and bypasses the interface |
| Return with value change | Path from goods receipt through the credit note to the posting | Stock posting and value posting are documented without any link |
| Partial return | Allocation logic across line items, shipping costs and discounts | Only the full case is described |
| Payment reversal | Reconciliation between payment method, refund and posting | Payment data is documented separately, with no link to the document |
The payment side is regularly underestimated. If refunds run through a different route than the original payment, the documentation has to describe the reconciliation -- otherwise the audit is left wondering which payment transaction belongs to which document. The fundamentals are covered on our page on payment integration with the ERP.
Logging and immutable logs
The GoBD leave open which technology achieves immutability and name three routes: hardware-based via unalterable media, software-based via safeguards, locks, write-protection, deletion markers, automatic logging, historisation and versioning, or organisational via access authorisation concepts (Bundesministerium der Finanzen). One sentence is decisive and often overlooked in practice: storing data and electronic documents in a file system regularly does not meet the immutability requirements unless additional measures are taken (Bundesministerium der Finanzen).
For interfaces this means: a log directory with rotating text files on an application server is generally unsuitable as evidence. What is needed is logging that keeps both the original content and the fact of a change recognisable. The GoBD state this explicitly: subsequent changes may only be made in such a way that both the original content and the fact that changes were made remain recognisable (Bundesministerium der Finanzen).
Mapping changes are subject to mandatory logging
- Logs with timestamp, triggering identity and a business reference to the document, not just a technical transaction ID
- Record changes to mappings, tax codes and account assignments with before and after values
- Retain incoming raw data in the format received so that every transformation can be recalculated
- Write-protected storage of logs for the duration of the retention period, separate from the application's operating system
- An access authorisation concept describing who may read logs and who could technically delete them
Raw data retention is the underestimated lever here. If the incoming record is preserved in the format received, every transformation can be reconstructed years later -- even without the mapping of the time. Without raw data, only the result remains, and the result does not explain itself. How logging and evaluability can be combined in live operation is described in our article on observability and monitoring of interfaces.
Errors and restart: DLQ documents must not vanish
Every interface has error cases. That is not a defect but a normal state -- a target system is unreachable, a mandatory field is missing, a tax code is unknown. The defect only arises when a bookkeeping-relevant document lands in a dead letter queue and stays there silently. From a completeness perspective that is a missing business transaction, no matter how clean the architecture is otherwise.
The operating documentation therefore has to describe what happens to a document that does not get through. Who is informed, within what deadline, who decides on the restart, and how is it ensured that a repeated attempt does not create a duplicate document? Technically, the answer to the last question is idempotency; in documentation terms it is the description of the key by which a transaction is uniquely identified. Both aspects are covered in our articles on idempotency and retry strategies and on error handling in interfaces.
Escalation with a deadline
Who is informed after what period if a document has not been processed? A queue without a named owner and without a deadline is a dead end in documentation terms.
Restart without double posting
Which key identifies the transaction unambiguously, and what happens on a second attempt? The idempotency key belongs in the documentation in business terms, not only in the implementation.
Evidence of clearance
How do you evidence that the error queue was empty on a given date? A regular reconciliation between orders in the shop and documents in accounting is part of the internal control system.
In a tax audit, an interface is only as good as the answer to the question of what happened to the documents that did not get through. The standard case is rarely of interest -- the exception decides.
A periodic completeness reconciliation has proven useful in practice: count and total of orders in the shop per period against count and total of documents in accounting, documented as a recurring control activity with a named owner (Projekterfahrung). This control is part of the internal control system and therefore explicitly a component of the process documentation (Bundesministerium der Finanzen).
Change history and versioning of the mappings
For integrators, margin number 154 of the GoBD is the most demanding provision of the whole section. For the duration of the retention period it must be ensured and evidenced that the procedure described in the documentation fully corresponds to the procedure actually used in practice; this applies in particular to the program versions deployed, known as program identity (Bundesministerium der Finanzen). Changes to process documentation must be historically traceable; this is satisfied where the changes are versioned and a traceable change history is maintained (Bundesministerium der Finanzen).
For the audit, meaningful and up-to-date process documentation is also necessary, documenting all system and procedural changes without gaps in terms of both content and timing (Bundesministerium der Finanzen). Translated: what counts is not only the current state of the mapping, but the question of which mapping was active on 14 March of the audited year. A Git history satisfies the substantive requirement technically -- it satisfies the requirement of being verifiable by a knowledgeable third party within a reasonable time only if a readable change history with date, reason and business impact sits alongside it.
The AWV recommends a practical split for this: the regular review of changed procedures can be considerably simplified by a smart division of the procedural description into a substantively stable main part and more frequently changing annexes (AWV Muster-Verfahrensdokumentation). For interfaces that means: the document path belongs in the stable main part, the field mapping in a versioned annex. It also applies that the procedure actually carried out must correspond to the documentation and be applied consistently; changes to the procedure or the measures must be documented, which is where the need for versioning comes from (AWV Muster-Verfahrensdokumentation).
Signing off the documentation belongs in the test run
Retention: eight years, ten years and retired interfaces
The retention situation changed on 1 January 2025, and the change is frequently read too broadly. The Fourth Bureaucracy Relief Act shortened the retention period for accounting documents from ten to eight years (Viertes Bürokratieentlastungsgesetz). The Bundestag passed the act on 26 September 2024 and the Bundesrat approved it on 18 October 2024 (Viertes Bürokratieentlastungsgesetz). The shortened period applies to all records whose retention period had not yet expired on 1 January 2025 -- so it covers existing stock as well (Viertes Bürokratieentlastungsgesetz). For companies supervised by the Federal Financial Supervisory Authority, the reduction takes effect one year later (Viertes Bürokratieentlastungsgesetz). According to the federal government, the act relieves the economy by around 944 million euros per year, of which roughly 626 million euros come from the retention shortening alone (Viertes Bürokratieentlastungsgesetz).
For the process documentation, none of this changes anything. It is not an accounting document but counts among the work instructions and other organisational records named in section 147 paragraph 1 number 1 of the German Fiscal Code, which are required to understand the books and records (Abgabenordnung). Those records must be retained for ten years under section 147 paragraph 3 of the Fiscal Code (Abgabenordnung). The period starts at the end of the calendar year in which the last entry was made (Abgabenordnung).
| Record | Period | Legal basis |
|---|---|---|
| Accounting documents, including invoices created by the interface | 8 years | Sec. 147 para. 1 no. 4 and para. 3 AO, since 01/01/2025 |
| Process documentation as an organisational record | 10 years | Sec. 147 para. 1 no. 1 and para. 3 AO |
| Books, records, annual financial statements | 10 years | Sec. 147 para. 1 no. 1 and para. 3 AO |
| Other records of tax relevance | 6 years | Sec. 147 para. 1 no. 5 and para. 3 AO |
| All of the above while the assessment period is open | Period does not expire | Sec. 147 para. 3 sentence 3 AO |
Two rules extend the period beyond the ten years. First, the general suspension: the retention period does not expire insofar and as long as the records are relevant for taxes for which the assessment period has not yet expired (Abgabenordnung). Second, a special rule for process documentation: its retention period does not expire insofar and as long as the retention period has not expired for the records it is needed to understand (Bundesministerium der Finanzen). The AWV adds that the process documentation, with all valid versions, belongs to the records subject to retention (AWV Muster-Verfahrensdokumentation).
A retired interface still has to be documented
From this follows a requirement for archiving that reaches beyond the interface: the raw data and logs must survive the system change too, and in machine-evaluable form. Anyone who migrates only live operations when switching cloud provider or middleware loses exactly the material needed to reconstruct the document path later. Which rights exist when changing provider, and how portability can be secured contractually and technically, is covered in our article on the EU Data Act and the portability of ERP cloud interfaces.
How the documentation emerges in the project
Process documentation written after the project is expensive and imprecise. It has to reconstruct what was decided once already -- usually without the people involved back then. Created alongside the interface, it largely falls out as a by-product: the data flow diagram is the result of the functional concept, the field mapping the result of the implementation, the error and restart procedure the result of the operating concept. They are brought together by an umbrella document that tells the document path and points into the existing parts.
The effort is manageable if it lands at the right moment. In integration projects, the additional effort is typically in the low single-digit percentage range of the project volume, provided the documentation is created in parallel with the implementation rather than afterwards (Projekterfahrung). Done retrospectively, reconstruction costs arise that can considerably exceed the original documentation effort (Projekterfahrung).
A look at the possible consequences puts the effort in perspective. Where cooperation obligations in a field audit go unmet, for audit orders issued from 1 January 2025 the Fiscal Code provides for a qualified cooperation request with a cooperation delay fee of 75 euros per full day for a maximum of 150 calendar days, that is up to 11,250 euros (Abgabenordnung). In particular cases, a surcharge of up to 25,000 euros per calendar day may be imposed (Abgabenordnung). Independently of that, bookkeeping that is not proper may, under section 158 of the Fiscal Code, not be used as the basis for taxation, which can lead to estimated add-backs (IHK für München und Oberbayern). The AWV names, among the possible consequences of a lack of proper bookkeeping, the non-recognition of business expenses, estimated add-backs of business income or profits, coercive measures, fines and, where applicable, tax criminal proceedings (AWV Muster-Verfahrensdokumentation).
An outlook belongs in the planning as well: the GoBD now refer to a standardised digital interface under section 147b of the Fiscal Code; the corresponding statutory ordinance is still pending (IHK für München und Oberbayern). Anyone who describes their data flows cleanly today and keeps raw data in machine-evaluable form is better prepared for such a standardised data request than a business that reassembles its exports for every audit.
The frame for all of this is the integration architecture itself. Whether the documents run through an SAP integration, an inventory system integration or bespoke API development: the documentation requirements are the same, only the references differ. For the handover to accounting, our DATEV integration page and the article on DATEV automation in e-commerce are worth a look. Anyone implementing the German e-invoicing mandate in parallel will find the timeline in our article on the 2027 e-invoicing mandate. Which points to clarify first for your specific system landscape is best sorted out in a conversation about your integration project.
Sources and studies