Z1, Z2, Z3: der Datenzugriff bei der Betriebsprüfung

Die drei Arten schließen einander nicht aus; ein Prüfer kann sie kombinieren. Wofür sich dein Betrieb entscheidet, gehört in die Verfahrensdokumentation — etwa in der Form: „Z2 und Z3 über die Steuerberatung; ein Lesezugriff Dritter auf das Rechnungsprogramm wird nicht eingerichtet.“ Eine Festlegung, die vor der Prüfung getroffen wurde, ist leichter zu vertreten als eine, die unter Zeitdruck entsteht.

Die Rechtsgrundlage der Datenüberlassung ist § 147 Abs. 6 AO. Wichtig ist der Zusatz, den man leicht überliest: Der Datenzugriff ist auf den Rahmen der jeweiligen Außenprüfung begrenzt (GoBD Rz. 159). Er umfasst also nicht automatisch alles, was in deiner Software liegt.

Der Zuschnitt hat einen zweiten Vorteil, der bei der ersten Fassung des Exports noch fehlte: Das Änderungsprotokoll folgt den Belegen, nicht dem Kalender. Wird ein Beleg aus dem Prüfungszeitraum später storniert, steht diese Änderung mit im Paket — obwohl sie nach dem Zeitraum passiert ist. Andersherum wäre das Protokoll unvollständig, und der Prüfer hielte es für vollständig.

Unter Exporte wählst du einen Zeitraum — er darf mehrere Jahre umfassen, was ein Prüfungszeitraum in der Regel tut — und lädst ein ZIP-Paket herunter. Anders als der DATEV-Buchungsstapel braucht es keine Angaben deiner Steuerkanzlei und funktioniert ab dem ersten Beleg. Die Datei heißt Datenueberlassung_Fakturierung_…zip, nicht „Prüferexport“: Der Name soll nicht mehr behaupten, als geliefert wird.

• Die Kundenangaben am Beleg sind eingefroren. Sie stammen aus der Momentaufnahme vom Tag der Festschreibung, nicht aus der heutigen Kundenzeile — sonst widerspräche die Tabelle dem PDF, das danebenliegt.
• Bei E-Rechnungen ist die XML das Original. Das PDF ist die Leseansicht. Das steht auch so im Paket, damit niemand das falsche Dokument für maßgeblich hält.
• Die Prüfsummen wurden beim Packen geprüft. Jede beigelegte Belegdatei wurde gegen den beim Festschreiben gespeicherten Wert gehalten.
• Format ohne Überraschungen. UTF-8 ohne Bytemarke, Semikolon als Feldtrenner, Komma als Dezimaltrennzeichen, CRLF am Zeilenende. Jede Datei hat eine Kopfzeile; die Daten beginnen in Zeile 2, und genau das steht auch in der index.xml.

Ein Prüferpaket, das mehr verspricht als es hält, ist schlimmer als ein knappes: Ein Prüfer, der es für vollständig hält, zieht falsche Schlüsse. Deshalb benennt das Paket seine eigenen Lücken.

• Journal, Kontenplan, Sachkonten, Kreditoren, Anlagenspiegel. Diese Software erfüllt die Grundaufzeichnungsfunktion eines Vorsystems (GoBD Rz. 85, 87). Journal und Kontenrahmen liegen im Hauptsystem der Steuerberatung und sind dort anzufordern. Sie hier zu erfinden wäre schlimmer, als sie wegzulassen.
• Abschlags- und Schlussrechnungen samt Anzahlungen. Sie bildet die Software nicht ab (§ 14 Abs. 5, § 22 Abs. 2 Nr. 2 UStG). Das Paket sagt ausdrücklich, dass ihr Fehlen eine Eigenschaft der Software ist und keine Aussage über deinen Betrieb — nachzulesen unter Abschlagsrechnung und Schlussrechnung.
• Soll- oder Ist-Versteuerung. Ob dein Betrieb nach § 20 UStG versteuert oder nicht, kennt das Datenmodell nicht — dabei entscheidet das darüber, ob das Rechnungsdatum oder der Zahlungseingang den Voranmeldungszeitraum bestimmt, und ist typischerweise eine der ersten Fragen. Die Antwort gehört in deine Verfahrensdokumentation.
• Die DTD des Beschreibungsstandards. Sie liegt dem Paket nicht bei, weil sie unter fremdem Urheberrecht steht. Die index.xml ist wohlgeformtes XML und ohne sie lesbar; das Paket nennt den Bezugsweg.

Jeder festgeschriebene Beleg trägt eine Prüfsumme und die seines Vorgängers. Die Kette läuft aber über alle festgeschriebenen Belege deines Betriebs, auch über Angebote und über Belege vor dem Prüfungszeitraum. In einem Auszug fehlen deshalb zwangsläufig Kettenglieder: Ein Vorgängerhash, der auf ein Angebot oder einen älteren Beleg zeigt, findet im Paket keinen Partner.

1. Zugriffsart und Umfang klären. Welche Art, welcher Zeitraum, welche Daten? Halte fest, was verlangt wurde — das ist zugleich der Maßstab dafür, was du herausgibst.
2. Steuerberatung einbinden. Journal, Kontenplan und Buchführung kommen von dort, nicht aus dem Rechnungsprogramm. Wer beides in einem Aufwasch liefert, spart eine Nachforderung.
3. Paket erzeugen. Unter Exporte Zeitraum wählen und Prüferexport herunterladen. Die Sortierung der Tabellen ist festgelegt: Derselbe Zeitraum liefert dieselben Zeilen in derselben Reihenfolge. Zwei Exporte lassen sich damit gegeneinanderhalten, falls später jemand fragt, ob wirklich dieselben Daten geliefert wurden.
4. Kettenprüfprotokoll beilegen. Ein Klick unter Unverfälschtheit prüfen, eine Textdatei mehr im Ordner.
5. Übergabe dokumentieren. Wann, an wen, welcher Zeitraum, welche Dateien. Der Vermerk gehört zu deiner Verfahrensdokumentation.

Die Rechnungssuite kennt eine eigene Rolle für die Steuerberatung. Sie darf lesen und die Exporte selbst herunterladen — den DATEV-Buchungsstapel, das Belegpaket und den Prüferexport —, aber nichts anlegen, ändern, festschreiben oder stornieren. Durchgesetzt wird das nicht nur in der Oberfläche, sondern zusätzlich in der Datenbank: Auch ein Zugriff, der die Anwendung umginge, käme nicht weiter.

Damit lässt sich ein Z2-Weg praktisch abbilden, ohne dass jemand aus deinem Betrieb jedes Mal exportiert. Ob du darüber hinaus einem Prüfer einen eigenen Lesezugang einrichtest, ist deine Entscheidung — und eine, die begründet in der Verfahrensdokumentation stehen sollte.