Data Access Z1/Z2/Z3
Data access Z1/Z2/Z3 denotes the three access methods the German tax authority may use during a tax audit to reach tax-relevant data in an ERP system: direct (Z1), indirect (Z2) and by handover of a data carrier (Z3).
Data access Z1/Z2/Z3 denotes the three legally defined access methods the German tax authority may use, during a field audit (tax audit), to reach tax-relevant data kept in electronic form. The legal basis is Section 147 (6) of the German Fiscal Code (AO), made concrete by the GoBD. The abbreviations stand for direct access (Z1), indirect access (Z2) and data carrier handover (Z3).
For companies running an ERP system the topic is central: all three access methods must be available at any time, because the auditor decides at their own discretion which one to use – often a combination. Anyone who fails to meet the requirements risks late-payment penalties, estimated assessments or challenges to the bookkeeping.
At a glance
- Legal basis: Section 147 (6) AO, made concrete by the GoBD
- Z1 = direct read-only access straight inside the ERP system
- Z2 = indirect access: the company runs evaluations to the auditor’s specifications
- Z3 = data carrier handover: structured export of the data
- The tax authority chooses the access method – all three must be ready
The three access methods Z1, Z2 and Z3 in detail
Data access Z1/Z2/Z3 differs by the degree of the company’s involvement and by where the evaluation takes place. The tax authority is free in its choice and may combine the methods; the company must enable each variant technically and organizationally.
Z1 – direct data access
With direct access the auditor works on the company’s IT system themselves. They receive their own read-only account and evaluate the tax-relevant data directly in the software – reading, filtering and sorting, but without write permissions. The company provides a workstation, the access and a brief introduction to the software.
Z2 – indirect data access
With indirect access it is not the auditor but the company (or an authorized third party) that evaluates the data – following the specifications of the tax authority. The auditor names the desired evaluations, the company generates them in the system and presents the result on screen. This variant shields areas that are not tax-relevant from direct inspection.
Z3 – data carrier handover
With data carrier handover the company hands over the tax-relevant data in machine-evaluable form – the auditor analyzes it with their own software (traditionally IDEA) on their own device. The export must be structured and include a description of the data format (record layout) so the data can be interpreted unambiguously.
Why data access Z1/Z2/Z3 matters
The obligation to provide electronic data access has existed since 2002 and was further specified by the GoBD in 2015. It affects every company that keeps records subject to documentation and retention requirements in electronic form – so practically every ERP user. Tax-relevant in particular are financial accounting, fixed-asset accounting, payroll accounting and the data of inventory management, insofar as they feed into taxation.
If a company cannot provide the requested access method, it faces a late-compliance penalty (2,500 to 250,000 euros), in extreme cases the rejection of the bookkeeping and an additional estimated assessment. A well-prepared data access also shortens the audit considerably and reduces follow-up questions – a tangible practical benefit, not just a formality.
Data access Z1/Z2/Z3 in the ERP system
A modern ERP or inventory management system must support all three access methods. Z1 requires a fine-grained authorization concept that allows a pure read-only access to the tax-relevant areas without endangering the data. Z2 requires flexible, traceable evaluation and reporting functions. Z3 requires a standardized data export.
The Z3 export is usually produced in the GoBD/GDPdU format according to the tax authority’s description standard: alongside the actual tables (mostly as CSV) an index.xml is generated that describes the data structure, field types and relationships, so the audit software IDEA can read the data correctly. Many systems offer this export as a standard function or via an interface. Equally important are a complete audit trail and the immutability of posted data (audit-proof storage).
Distinction: GDPdU, GoBD and data access
The terms are often conflated. GDPdU (Principles on Data Access and the Auditability of Digital Documents) was the original German Federal Ministry of Finance directive of 2001 that introduced data access. In 2014 the GDPdU were replaced by the GoBD (Principles for the proper keeping and retention of books, records and documents in electronic form), which regulate the topic more comprehensively – including documents, process documentation and retention.
Data access Z1/Z2/Z3 is therefore one aspect within the GoBD. The formerly common “GDPdU format” for the Z3 export still exists technically, but is correctly called GoBD data export today. The access rights themselves (Section 147 (6) AO) have remained unchanged across both frameworks.
DACH specifics
The Z1/Z2/Z3 model is a German regulation under the Fiscal Code. In Austria, Sections 131 and 132 BAO and the cash register guideline impose similar but independent requirements on data retention and auditability; Austrian law knows no fixed Z1/Z2/Z3 scheme. In Switzerland the Business Records Ordinance (GeBüV) governs audit-proof retention.
Companies operating cross-border within the DACH region should configure their ERP to meet the strictest applicable requirement. The German Z1/Z2/Z3 standard covers the technical core capabilities in practice – read access, evaluation, structured export – well, but does not replace the country-specific review of retention and format obligations.
Preparing data access Z1/Z2/Z3
Anyone who wants a tax audit to go smoothly does not prepare data access only when the audit order arrives. A documented process makes sense: a predefined read-only auditor profile in the ERP for Z1, a collection of common evaluations for indirect access Z2 as well as a tested GoBD export including index.xml for Z3. A trial export run once a year uncovers format errors before they cost valuable audit time in an emergency. It also makes sense to clarify responsibilities early – who sets up the access, who creates evaluations, who coordinates with the tax advisor.
Process documentation is also part of it, describing how tax-relevant data is created, processed and retained. Since these records are subject to a ten-year retention obligation, access to legacy data must remain secured even after a system change – for example through archiving in the original system or a migration-proof export with a complete record layout. Without this access, even the best current ERP configuration is of little help.
Example
Tax audit at a mid-sized wholesaler
A wholesaler with 60 employees receives the audit order for the years 2022 to 2024. The auditor first requests Z1 access: IT sets up a read-only user account in the ERP that only accesses financial and fixed-asset accounting. For a contribution-margin evaluation that does not exist as standard, she chooses Z2 – the controller creates the desired report to her specifications.
For a deeper analysis the auditor finally requests a Z3 export of the posting journals. At the push of a button the ERP generates a GoBD data export with CSV tables and index.xml, which she reads into IDEA. Because the system serves all three access methods cleanly, providing the data is finished after two days instead of two weeks.
Frequently asked questions
Matching ERP systems
Related services
Sources
Questions about Data Access Z1/Z2/Z3 in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.