GoBD Compliance im SAP Umfeld – Speziell Archivierung

(Last Updated On: 16. Juli 2018)

Seit dem 01.01.2002 darf das Finanzamt gemäß § 147 Abs. 6 Abgabenordnung (AO) auf die steuerrechtliche relevanten Datenverarbeitungssysteme der steuerpflichtigen Organisation zuzugreifen. Dadurch soll es dem Wirtschaftsprüfer oder Steuerauditor ermöglicht werden, die  Erfüllung der Grundsätze ordnungsgemäßer Buchführung in elektronischer Form zu überprüfen.

Die zu erfüllenden Grundsätze wurden hierbei in den Grundsätzen zur ordnungsgemäßgen Führung und Aufbewahrung von Büchern, Aufzeichnugnen und Unterlagen in elektronischer Form sowie zum Datenzugriff (kurz GoBD) zusammengefasst.

Auch wenn das GoBD-Schreiben den Grundsatz der Wirtschaftlichkeit erwähnt, ist dies kein Freibrief für Unternehmen, sich mit dem Argument der Wirtschaftlichkeit von Ihren Pflichten im Rahmen der ordnungsgemäßen Buchführung frei zu kaufen. Der Grundsatz der Wirtschaftlichkeit darf nicht dazu führen, dass Grundprinzipien wie die Revisionssicherheit oder der unmittelbare Datenzugriff der Finanzbehörde verletzt werden. Insbesondere darf nur wegen des Kostenfaktors keine Software eingesetzt werden, die den Mindestanforderungen der GoBD nicht genügt.

Datenzugriff für die Finanzbehörde

Gemäß den neuen Regelungen müssen Sie der Finanzbehörde Zugriff auf Ihr finanzbuchhalterisches DV-System gewähren. Dabei unterscheidet man zwischen

  • dem unmittelbaren Zugriff. Hier bekomt der Aussenprüfer im Endeffekt direkten Zugriff auf das System
  • dem mittelbaren Zugriff. Hier verlangt der Auditor, dass der Steuerpflichtige oder ein Beauftragter Dritter die Daten in einem Nur-Lese-Zugriff auswertet.
  • der Datenträgerüberlassung auf maschinell verwertbaren Datenträgern. Der Aussenprüfer kann verlangen, dass ihm die Daten auf einem Datenträger zur Verfügung gestellt werden. Dies gilt auch für Systeme, die in der Cloud ansässig sind. Daher muss an dieser Stelle unbedingt untersucht werden, ob der jeweilige Cloud-Anbieter diese Funktion bietet.

Dabei müssen Sie alle elektronisch erzeugten Unterlagenim System, soweit diese steuerrechtlich relevant sind, unverzüglich in lesbarer und maschinell auswertbarer Form vorhalten und bereitstellen können. Grundsätzlich gilt hierbei die 10-jährige Aufbewahrungsfrist gem. § 257 Abs. 1 HGB und § 147 Abs. 1 i. V. m. 3 AO.

Diese Frist tickt nicht ab dem Erfassungszeitraum eines elektronischen Datensatzes oder Dokumentes, sondern ab dem Tag, an welchem Sie das Dokument steuerrechtlich im Rahmen Ihrer Steuererklärung geltend machen. Die Aufbewahrungsfrist in der Praxis also häufig länger als 10 Jahre. Doch Vorsicht: Diese 10 Jahre können durch außersteuerliche Regelungen (z. B. aufgrund von HGB, §§ 41 ff. GmbHG, § 55 Versicherungsaufsichtsgesetz) übersteuert werden und in der Praxis höher ausfallen.

Das Datenzugriffsrecht ist in der Abgabenordnung (AO) geregelt. Die Gesetzesgrundlagen im Einzelnen umfassen die §§ 146 AO, 147 AO, 200 AO und §14 bzw. 14b UStG.

Datenführung im Ausland

Mit dem Jahressteuergesetzt 2010 ist es dem Unternehmen grundsätzlich gestattet, steuerrechtlich relevante elektronische Daten auf Systemen außeralb der BRD zu führen.  DAfür müssen jedoch bestimmte Bedingungen gemäß § 146 Abs. 2a Satz 1 Abgabenordnung (AO) erfüllt werden und ein schriftlicher Antrag beider Finanzbehörde gestellt werden. Das ist insbesondere beim Thema Cloud wichtig.

Demnach müssen Sie der Steuerbehörde den Standort des Datenverarbeitungssystems mitteilen und diesen auch in Ihrer Verfahrensdokumentation (siehe unten) festhalten. Der Datenzugriff muss weiterhin unverzüglich möglich sein und die Besteuerung darf hierdurch nicht beeinträchtigt werden.

Die Daten überhaupt erst einmal finden

Damit Sie Daten auf Anfrage der Finanzbehörde zur Verfügung stellen können, müssen Sie sie selbst erst einmal finden. Dabei haben Sie im SAP-Umfeld klassischerweise mit einer zentralen Herausforderung zu kämpfen: Wie verknüpfe ich meine SAP-Daten mit den Papierdokumenten, die ich im Rahmen meiner Wertschöpfungsprozesse generiere? Verknüpfe ich sie nicht, kann das an verschiedenen Stellen zu Problemen führen. Ein Beispiel.

Sie erhalten Rohstoffe von einem Lieferanten. Der Wareneingang wird im SAP-System gebucht, Sie erhaltenseparat dazu Rechnung, Leferschein und ein Qualitätszertifikat Ihrer Ware. In der QA-Abteilung werden die eingehenden Rohstoffe auf Übereinstimmung mit den Angaben auf dem Qualitätszertifikat untersucht.

Dieses Qualitätszertifikat wird daraufhin im Anschluss digitalisiert und landet in einem internen Fileshare der QA-Abteilung. Die Rechnung landet im Steuersystem der Steuerberatung, der Lieferschein im Lagermanagement. Sammeln Sie jetzt einmal all diese Dokumente zusammen, wenn das Finanzamt nach den Dokumenten zu diesem Geschäftsvorgang fragt.

Es wird quasi unmöglich, alle Dokumente, die zu den Daten im SAP-System gehören, durch die alleinigen Bemühungen eines einzelnen Mitarbeiters zu finden. Vielmehr stößt er eine Schnitzeljagd an, mit der sich ganze Abteilungen beschäftigen müssen. Das muss nicht sein.

Best Practice ist es daher, die SAP-Geschäftsdaten direkt mit den entsprechenden Dokumenten zu verknüpfen. Das geschieht in Form eines SAP-integrierbaren Dokumenten Management Systems (DMS).

Die GoBD fordert ohnehin von Ihnen, dass Sie zusammenhängende Daten (also beispielsweise SAP-Anwendungsbelege, dazu gehörige PDF-Dateien und eventuelle Geschäftsbriefe) unter einem gemeinsamen Index verwalten.

Daher macht es Sinn, in diesem Zusammenhang auf die SAP-Standardfunktionalitäten zurückzugreifen. Was das für Ihren Speicherplatzbedarf und für die Anforderungen an die Revisionssicherheit bedeutet, dazu kommen wir weiter unten zu sprechen.

Die Revisionssicherheit

Des Weiteren müssen Sie hierbei die sogenannte Revisionssicherheit beachten. Daten dürfen also während dieser Zeit nicht gelöscht werden. Wenn ein Datensatz oder ein elektronisches Dokument durch eine neue Version überschrieben wird (etwa weil bei der Ursprungsversion ein Fehler im Rechnungskopf gemacht wurde), muss die Ursprungsversion immer noch elektronisch vorgehalten werden.

Sie sind also dafür in der Verantwortung, dass die gesamte Versionshistorie sämtlicher elektronischer Unterlagen wiederherstellbar ist. Und wenn Sie sich nur beim Nachnamen des Kunden in der Rechnungsanschrift vertippt haben – diese Version muss zurückgesichert werden können.

Grundsätzlich können Sie eine Unverändbarkeit von durch hardwareseitige Maßnahmen (bspw. WORM-Drive oder -Datenträger), softwareseitige Maßnahmen (z. B. SAP Tabellenprotokollierung und audit-Logs) sowie durch organisatorische Maßnahmen sicherstellen. Den Wirtschaftsprüfer interessiert in diesem Zusammenhang die Effektivität des Prozesses.

Revisionssicherheit in den SAP-Tabellen

Im SAP-Umfeld lösen Sie dies in der Praxis durch drei grundlegende Maßnahmen. Die erste Maßnahme ist die, in jedem aufzeichnungswürdigen SAP-System die Tabellenprotokollierung über den Parameter rec/client anzuschalten.

Als aufzeichnungswürdiges SAP-System gilt hierbei in der Regel nicht nur das Produktivsystem, sondern auch das System, in welchem Customizing durchgeführt wird. Denn im Produktivsystem kommt immer nur die Endversion einer Customizing-Einstellung an, die in einen Transportauftrag gepackt wurde.

Sämtliche Zwischenstände, die bei der Erstellung dieses Transportauftrags erzeugt wurden, können einzig und allein auf dem Entwicklungsssystem nachvollzogen werden, in dem das Customizing angefasst wurde. Nur so können Sie revisionssicher die einzelnen Customizing-Stände des SAP-Systems wiederherstellen.

Sie sollten also die Tabellenprotokollierung sowohl im DEV- als auch im P-System aktivieren. Wichtig: Auch bei einer Mandantenkopie können Sie nicht auf die Tabellenprotokollierung im Quell-Mandanten verzichten, da bei der Mandantenkopie keine Änderungen aufgezeichnet werden.

Grundsätzlich besteht die Möglichkeit den Parameterwert rec/client = all festzulegen. Damit werden in allen Mandanten des Systems Tabellenprotokollierungen vorgenommen. Aus Performancegründen sollten Sie die Aufzeichnung jedoch auf konkrete produktive Mandanten beschränken.

Sie können deshalb in diesem Profilparameter auch eine Whiteliste an zu protokollierenden Mandnaten festlegen, um beispielsweise einen Test- bzw. Konsolidierungs-Mandanten von der Protokollierung auszunehmen. Voraussetzung ist hierfür, dass in diesem Mandanten keine Änderungen am Customizing vorgenommen werden.

Tabellenprotokollierung in SAP Transporten und Kundentabellenim Z-Namensraum

Einzige Alternative, um sich die Tabellenprotokollierung im Quellsystem zu sparen: Sie aktivieren die Tabellenprotokollierung in Transporten. Dazu setzen den Parameter r3transoptions = reccleint=“<Mandantennumer>“ im Profil der Transportsteuerung.

Wenn Sie kundeneigene Z-Tabellen erstellt haben bzw. bestehende Standard-Tabellen ergänzt haben, sollten Sie noch einmal sicherstellen, dass alle Daten, die rechnungs- und steuerrelevant sind, der Tabellenprotokollierung unterliegen.

Hierzu begeben Sie sich in die Transaktion SE11, geben den Namen der Tabelle ein und wählen den Button Änderung. Wählen Sie im Folgebildschirm Springen -> Technische Einstellungen und stellen Sie sicher, dass das Ankreuzfeld Datenänderungen protokollieren aktiv ist. Weitere Informationen finden Sie in SAP Note 1916.

Neben diesen Möglichkeiten bieten die einzelnen Datenbankmanagement-Systeme, darunter SAP HANA, eine Möglichkeit, Tabellen revisionssicher vorzuhalten. Dass es noch ein wesentlich bedeutenderes Level an revisionssicherer Datenhaltung in Form von der Methodik des „Event Sourcing“ gibt, habe ich in einem vergangenen Beitrag schon einmal aufgezeigt.

 

In den Archivdateien

Die Revisionssicherheit müssen Sie darüber hinaus nicht nur in den SAP-Tabellen aufrecht erhalten, sondern auch in Ihrem Archivsystem. In Ihrem SAP-Archivsystem (ich berichtete damals) unterhalten Sie grundlegend die folgenden Dokumente

  • SAP Anwendungsdokumente (Application Documents) machen in der Regel den Großteil Ihres Archivvolumens aus. Sie bestehen aus Datensätzen in den Kopf- und Positionstabellen des SAP-Systems.
  • elektronische Papierdokumente (häufig gespeichert in Form von .pdf-Dateien, aber durchaus auch gerne in Form von Microsoft Office Dokumenten abgespeichert). Das sind im Endeffekt papierne Dokumente, die entweder digitalisiert wurden oder nur noch digitalisiert verschickt werden wie beispielsweise Lieferscheine und Rechnungen
  • DART-Extrakte für Wirtschaftsprüfungen und Steuer-Audits. Seit neuestem auch im XML-basierten Format SAF-T. DART-Extrakte müssen Sie erstellen, bevor Sie die zugehörigen SAP-anwendungsdokumente archivieren, da die SAP-Standardfunktionalität nicht dazu in der Lage ist, aus Archiven zu lesen.
  • Drucklisten, beispielsweise als Ergebnisliste eines ABAP Reports. Auch diese können mitunter steuerlich relevant sein, insbesondere dann, wenn die Drucklisten von einem finanzbuchhalterischen ABAP-Programm erstellt wurden.

Speichern Sie SAP-Archivdateien einem Write Once Read Many (WORM) Drive

Um die Revisionssicherheit der Archivdateien sicherzustellen, müssen diese auf einem revisionssicheren Medium abgelegt werden. Da es nicht praktikabel ist, mit Blu Rays, Magnetbändern und CDs zu jonglieren, empfiehlt sich eine Ablage auf einem WORM-Storage. Dies sind Storage Devices, die mehrere Plattentöpfe in einem Content-Addressed Storage (CAS) vereinen. Insbesondere ist der SAP Content Server, den viele Kunden zur Speicherung von Archivdateien verwenden, oder Speicherung auf Dateisystemebene (etwa in einem NFS-Share) nicht GoBD-konform.

Jede Information, die auf dem WORM-Drive abgelegt wird, bekommt eine eindeutige Adresse, die nicht mit einer neuen Information überschrieben werden kann. Wird also beispielsweise eine Archivdatei nochmal erneut in das Archivsystem abgelegt, bekommt diese neue Version  – trotz gleichem Dateinamen und Ablagepfad auf Dateisystemebene – eine vollkommen eigenständige Content Adresse. Die alte Version bleibt dabei immer noch über ihr zugewiesene Content Adresse lesbar.

Das Problem bei WORM-Drives, insbesondere in Zusammenhang mit der EU-DSGVO: Die Informationen, die sich im WORM-Drive befinden, müssen irgendwann gelöscht werden. Denn Ihre Archivdateien enthalten im Geschäftsalltag unweigerlich personenbezogene Daten.

Pflegen Sie zu diesen Personen keine aktive Geschäftsbeziehung mehr und  haben diese keine rechtliche Relevanz mehr, müssen Sie die Daten entweder löschen oder anonymisieren. Aus diesem Grund haben neuere WORM-Storages eine sogenannte Retention Policy implementiert. Hier können Sie festlegen, dass bestimmte Adressbereiche nach einem bestimmten Alter gelöscht werden. Dabei können Sie häufig sogenannte „Haltemarken“ setzen, um beispielsweise Dokumente, die aufgrund eines Gerichtsverfahrens noch relevant sind, am Leben zu erhalten. Wichtig in diesem Zusammenhang ist, dass die verwendete WORM-Lösung und das damit eingesetzte Löschverfahren zertifiziert ist.

Im Dokumenten-Management-System (DMS)

Weiter oben haben wir bereits die Wichtigkeit eines SAP-integrierten Dokumenten Management Systems im Zusammenhang mit dem Datenzugriff der Finanzbehörde hergestellt. Nun wollen wir noch einmal an dieser Stelle fest halten, dass die im DMS abgelegten Dokumente natürlich auch revisionssicher abgelegt werden sollten. Mit Hilfe des SAP Dokumentenverwaltungssystems (SAP DVS) können Sie die entsprechenden Dokumente, darunter PDF-Dokumente und E-Mails, direkt mit dem zugehörigen SAP-Anwendungsbeleg verknüpfen.

Problem bei der Sache mit dem SAP DMS/ SAP DVS-Konstrukt ist: Alle Dokumente, die Sie im SAPOffice-Umfeld mit einem SAP-Anwendungsbeleg verknüpfen, werden über den Knowledge Provider (KPRO) innerhalb der SAP-Datenbank (Tabelle SOFFCONT1) gespeichert. Dort verbrauchen Sie wertvollen Speicherplatz. Zum Anderen kostet es einiges an Performance, diese SAP-Tabellen mit derart großen Binärdateien im Gepäck revisionssicher zu halten.

Deshalb ist es für Sie besser, wenn Sie gleich einen entsprechenden Workflow implementieren, nachdem SAPOffice-Objekte gleich bei Ihrer Ablage ins Archiv wandern. Dort wandern Sie dann entsprechend in das WORM-Drive und sind damit revisionssicher abgelegt.

Hierzu erstellen Sie in der transaktion SKPR08 einen Eintrag für die Speicher-Kategorie SOFFPHIO. Entsprechende Hilfestelungen bekommen Sie in den SAP Hinweisen 668271, 386971, 2571570, 530792,1975846 und 530792.

Bereits in der Vergangenheit gespeicherte Dokumemnte können Sie nachträglich über die Hinweise in den SAP-Hinweisen 389366 (bis SAP Basis Release 6.10) und 1634908 archivieren. Sofern Ihr SAP Basis Release älter ist als 7.40, müssen Sie statt dem Report RSGOS_RELOCATE_ATTA den Report  RSIRPIRL aus SAP Hinweis 2459712 verwenden.

elektronische Papierdokumente revisionssicher in einen PDF/A3-Container packen

elektronische Papierdokumente müssen abhängig davon, wie sie erstellt wurden, immer in Zusammenhang mit den Quelldaten abgelegt werden. Das bedeutet beispielsweise, dass wenn Sie Ihre Rechnung nicht über das SAP-System selbst erstellen, sondern beispielsweise über Microsoft Office, dass es in der Regel nicht ausreicht, wenn Sie einfach nur die final erzeugte .pdf-Datei archivieren. Anderes Beispiel: Die Reisekostenabrechnung wird in Ihrem Unternehmen über eine Microsoft Excel-Vorlage abgewickelt.

Dann muss der Verlauf der Rechnungskorrektur nachvollziehbar sein. Entweder revisionieren Sie dazu die Word-Datei, oder Sie revisionieren die PDF-Datei und hängen im Container die ursprungsversion sowie die neue Version der PDF-Datei sowie die E-Mail mit der ursprünglich fälschlich versandten Rechnung an.

Aufzubewahren sind die Dokumente außerdem immer dann, wenn sie eine qualifizierte elektronische Signatur beinhalten. Das kann sowohl bei Office-Dokumenten, als auch bei E-Mails und Faxen der Fall sein.

Wenn Sie jedoch Rechnungen nur noch als PDF- bzw. Bild-Datei vorhalten und die Word-Datei danach wegwerfen, müssen Sie darauf achten, dass die maschinelle Auswertbarkeit erhalten bleibt (siehe anderer Abschnitt). Insbesondere die Volltextsuche sollte danach noch erhalten bleiben. Die PDF-Datei sollte also durchsuchbar sein, eine Bild-Datei mit entsprechenden OCR-Daten angereichert werden, um dies zu gewährleisten.

Die GoBD fordert an dieser Stelle von Ihnen, dass Sie auch die Quelldatei, also beispielsweise die Word-Datei bzw. das Excel-Sheet, mit archivieren. In der Praxis packt man die .docx-Datei mit dem PDF-Dokument zusammen in einen PDF/A-3 Container. Mit diesem Dateiformat können Sie das Quelldokument integrieren. Dabei sollten Sie jegliche Zwischenversion des Word-Dokumentes in das Archiv inkludieren. Ändert sich also die .docx-Datei, kommt die neue Version zusätzlich zur Ursprungsversion ins PDF/A-3.

Im PDF/A-3 Container muss auch die .pdf-Datei in dem Zustand enthalten sein, in dem Sie an den Geschäftspartner verschickt wurde. Wenn Sie ein OCR-Verfahren auf eine gescannte Bild- oder PDF-Datei anwenden, sind die entnommenen OCR-daten ebenfalls ergänzend aufzubewahren. Zwar könne diese auch in einer anderen Datei gespeichert werden, jedoch empfiehlt es sich, diese entweder direkt in die PDF-Datei oder als Bestandteil des Containers zu integrieren.

Erstellen Sie die Rechnung hingegen über ein anderes ERP-/CRM-System, beispielsweise Salesforce oder Microsoft Dynamics, müssen Sie auch hier darauf achten, dass die entsprechenden Datensätze (Kunden, Geschäftsvorfälle) ebenfalls revisionssicher abgelegt sind. Daher ist es wichtig, auch für diese Systeme eine revisionssichere Archivierungsstrategie zu haben.

Auch wenn die Rechnungslegung inerhalb von SAP von statten geht, aber die Kundendaten von einem externen CRM-System kommen, ist dieses im Sinne der GoBD als „Vor- oder Neben-System“ zu bezeichnen. Somit sind auch die Daten aus diesem System steuerrechtlich relevant und somit revisionssicher aufzubewahren.

Als Nebensystem können durchaus auch E-MAil-erver, KAssensysteme, Middleware-Komponeten für EDIFACT und IDOC-Austausch (PI/PO, Seeburger), Lizenzverwaltungssyssteme (SAP Solution Manager), Systeme zur Reisekostenabwicklung (z. B Concur), Zeiterfassungssysteme (z. B. SuccessFactors), Dokumenten-Management-Systeme und Faktura-Systeme auserkoren werden. Sie sehen also: Eine Einschränkung ist hier nicht einfach. Es kommt immer auf die Daten und  und die jeweils durchgeführt Außenprüfung an.

Übrigens: Der elektronische Rechnungsaustausch ohne qualifizierte Signatur (etwa als Mailanhang im PDF-Format) ist natürlich weiterhin erlaubt. Sie müssen Ihre Rechnungen an die Endkunden also nicht im PDF/A-3 Format zu stellen. Dafür sorgt die Empfehlung 94/820/EG der Kommision vom 19. Oktober 1994. Voraussetzung hierfür ist allerdings, dass die Echtheit der Herkunft, die Unversertheit Ihres Inhalts sowie die Lesbarkeit der Rechnung gewährleistet ist. Für alle diese Voraussetzungen tragen Sie im Unternehmen Verantwortung. Die Revisionssicherheit leistet dazu einen entscheidenden Beitrag.

in IDOCS

Im SAP-Umfeld geschieht die Kommunikation mit Aussensystemen häufig in Form von IDOCs. Beispielsweise wird im Rahmen der elektronischen Rechnungsstellung häufig eine eingehende EDIFACT-Nachricht in ein IDOC umgewandelt. Dabei dient häufig eine Middlware-Komponente wie PI/PO zur Entgegennahme der EDIFACT-Nachricht und leiten diese in Form eines IDOCS an das empfangende SAP ERP-System weiter.

Hierbei kann es dazu kommen, dass das IDOC „hängen bleibt“. Etwa wenn die Mengenangaben im IDOC nicht zum Mengengerüst in der Lagerverwaltung passen. In der Praxis wird das eingehende IDOC hierbei häufig kopiert und dessen Inhalt an die Datenhaltung des ERP-Systems angepasst. Danach wird dieses neue IDOC verarbeitet und das Backend beginnt zu arbeiten.

Sie können sich sicher vorstellen, dass dieser Arbeitsfluss natürlich nicht gerade der Vorstellung von „revisionssicherem Arbeiten“ entspricht. Die Handlungsempfehlung, die ich Ihnen an dieser Stelle geben kann, ist, alle Versionen der IDOCs und der eingehenden Originaldaten (Z. B. EDI-Dateien) aufzuheben und zu archivieren. Denn es muss für den Aussenprüfer nachvollziehbar sein, wie die einzelnen IDOCs zustande gekommen sind. Da die GoBD von IHnen fordert, dass Ursprungsdaten unddaraus konvertierte Daten über einen einheitlichen index geführt werden, müssen Sie das Original-EDI, das ursprünglich daraus erzeugte IDOC und das Kopie-IDOC miteinander logisch verknüpfen. Dazu gehört natürlich auch eine revisionssichere Aufbewahrung dieser Dokumente.

IDOC-Daten sind nicht in einem DART-Extrakt enthalten. Ein Wirtschaftsprüfer, der ursprünglich nur mit einem DART-Extrakt zufriedenzustellen ist, braucht im Falle einer IDOC-Integration also auch diese Daten. Damit  hier eine saubere NAchverfolgung möglich ist, sollten Sie eine Verknüpfung zwischen dem FI-Beleg und dem entsprechenden IDOC herstellen.

Systemumstellungen im SAP-Umfeld

Unter einer Systemumstellung versteht man im SAP-Umfeld allgemein die folgenden Tätigkeiten

  • Buchungskreiszusammenführung
  • Währungsumstellung
  • Eine Kontennummernkonvertierung
  • Eine Kontenplanharmonisierung
  • Migration auf das neue Hauptbuch im SAP-Umfeld

All diese tätigkeitne haben zur Eigenheit, dass hier Datensätze auf Datenbankebene derart geändert werden, dass kein Rückschluss mehr auf die ursprünglichen Werte möglich ist. Da hilft auch die Tabellenprotokollierung auf SAP-Ebene nicht mehr, weil sich hier die Primär- und Fremdschlüsselwerte ändern.

Daher ist es empfehlenswert, DART-Extrakte sowohl vor als auch nach der Systemumstellung zu generieren und ein Backup vom Datenstand vor der Systemumstellung so lange revisionssicher aufzubewahren, bis die steuerliche Relevanz nicht mehr gegeben und die Aufbewahrungsfrist vorüber ist.

folgende Daten müssen Sie aufbewahren

Nur damit wir alles bei einander haben: Folgende Daten sind beakntermaßen in § 147 Abs. 1 AO festgelegt und müssen daher revisionssicher aufbewahrt werden

  • Bücher und Aufzeichnungen, Inventare, Jahresabschlüsse, Lageberichte, Eröffnungsbilanzen sowie zum Verständnis erforderliche Arbeitsanweisungen und sonstige Organisationsunterlagen. Hier ist wieder das Stichwort SAP DVS bzw. SAP DMS wichtig
  • Empfangene Handels- und Geschäftsbriefe. Dies schließt E-Mail-Verkehr, Mahnungen, Saldenbestätigungen, Bankkontoauszüge, Afutragsbestätigeungen, Bestellungen/Aufträge, Angebote und Rechnungen mit ein. Auch dies können Sie mitunter über das SAP DVS lösen, oder über eine automatische Archivierung Ihrer E-Mails über ein Enterprise Content Management System wie SAPERION. Nicht zu den Handelsbriefen gehören Unterlagen, die nicht zum Abschluss eines Handelsgeschäfts geführt haben.
  • Buchungsbelege
  • Unterlagen nach Artikel 15 Abs. 1 und Artikel 163 des Zollkodex der Union (unionszollkodex UZK). In diesem Zusammenhang ist SAP GTS, insbesondere in Zsuammenhang mit der Archivierung durch die Archivierungsobjekte SPL_AT und CUHD.
  • sonstige Unterlagen, insbesondere aus Vor- und Neben-Systemen, soweit sie für die Besteuerung von Bedeutung sind.

Mit folgenden Aussenprüfungen müssen Sie rechnen

Wenn Sie die oben genannten Daten aufbewahren, sollten Sie für die Prüfungen, die Sie erwarten, bestens gerüstet sein. Damit Sie trotzdem nichts vergesen, kommt hier noch einmal eine erschöpfende Liste der möglichen Betriebsprüfungen, in denen Ihr SAP-System involviert sein kann.

  • Die allgemein Betriebsprüfung. Sie umfasst die Einkommensteuer, Gewerbesteuer, Körperschaftsteuer, den Solidaritätszuschlag sowie die Umsatzsteuer.  Insbesondere werden hier die Gewinn- und Verlustrechnung (GuV), die Konten im Hauptbuch, Debitoren- und Kreditorenbuchhaltung, Anlagenbuchhaltung, die Versicherungsbuchhaltung sowie Wertpapiere und Depotfinanzströme auditiert
  • Lohnsteueraußenpürfung. Sie bezieht sich auf sämtliche Lohnkonten und beinhaltet damit die zugehörigen Gehalts- und Reisekostenabrechnungen. Auch hier werden wieder Bilanz und GuV sowie die Konten der Hauptbuchhaltung unter die Lupe genommen. Insbesondere geht er hier um Aufwendungen in Bezug auf Mitarbeiter, darunter Betriebsveranstaltungen, Bewirtungsleistungen, Mitarbeitergeschenke usw.
  • Umsatzsteuersonderprüfung. Hierbei geht es um die Prüfung der Umsatzsteuer- und Vorsteuerkonten sowie der dazu relevanten Ertragskonten.
  • Bei der Zollprüfung werden vor allen Dingen Einfuhrabgaben für Beschaffungen aus dem Ausland, die zollamtliche Überwachung sowie Marktordnungsprüfungen nach §44 Außenwirtschaftsgesetz durchgeführt.
  • Die Verbrauchssteuerprüfung befasst sich mit Strom-, Mineralöl-, Alkohol- und anderen Verbrauchssteuerabgaben, die im Rahmen der Unternehmensführung entstanden sind.

Die maschinelle Auswertbarkeit und die Aufbewahrungspflicht

Der Grundsatz der maschinellen Auswertbarkeit besagt einfach ausgedrückt, dass alle elektronischen Unterlagen, die für ein Steueraudit relevant sind, in einem maschinell auswertbaren Format vorgehalten werden sollen. So ist es beispielsweise zulässig, ein PDF-Dokument in eine HTML-Datei zu konvertieren, jedoch ist fraglich, ob das Dokument als Screenshot in Form einer Bilddatei abgelegt werden kann. Eine Interpretation scheitert hier durch den Mangel an Referenzbeispielen. Jedoch spricht die GoBD immer wieder die Volltextsuche als Möglichkeit der maschinellen Auswertbarkeit ein, weswegen Bilddateien daher eher vermieden werden sollten.

Anders sieht es unter Umständen aus, wenn Sie beispielsweise Papierdokumente zunächst als Bilddatei einscannen und im Anschluss darauf eine OCR-Erkennung laufen lassen. Dann wäre das Bild bei einer guten Trefferquote der OCR-Software wieder maschinell auswertbar. Im SAP-Umfeld gibt es diverse Lösungen zur OCR-Erkennung in Verbindung mit der Digitalisierung von Papierdokumenten.

Erstellen von DART-Extrakten

Wie bereits schon erklärt, sind DART-Extrakte hochgradig relevant für Aussenprüfungen und sollten erstellt werden, bevor die betroffenen SAP-Anwendungsbelege in das Archivsystem verschoben werden. Denn die SAP-Standardfunktionalität kann die DART-Extrakte nicht aus Daten erstellen, die bereits archiviert worden sind. Freilich gibt es hierfür Drittanbieterlösungen oder die Möglichkeit, die Archivdateien durch eine Eigenentwicklung auszulesen, aber diesen Aufwand muss man sich nicht ins Haus holen. Grundsätzlich sollten Sie DART-Extrakte im Rahmen des Geschäftsjahresabschlusses mit abwickeln.

Grundsätzlich schwebt bei der Erstellung von DART-Extrakten die Frage im Raum, welche Daten denn notwendig sind. Die DSAG erstellt hierfür den sogenannten DSAG-Feldkatalog. Dieser wird regelmäßig mit der SAP und durch Fragen an die Finanzverwaltung angepasst. Der DSAG-Feldkatalog stellt also eine gute Datenbasis dar, wenn es um die Datenselektion für einen DART-Extrakt geht. Jedoch sollten Sie als Kunde den DSAG-Feldkatalog an die Bedürfnisse Ihrer jeweiligen Branche anpassen. Sie extrahieren nur die Bewegungsdaten aus dem Zeitraum, die Sie auswählen. Dies beinhaltet die damit verbundenen Stammdaten, Erklärdaten, abhängige Tabellen (z. B. SAPScript-Texte) und die Änderungsbelege. Sie können jedoch Stamm- und Bewegungsdaten auch getrennt extrahieren. Dazu wählen Sie in der FTWP die Stammdatensegmente zur Extraktion.

Vorsicht: Ein DART-Extrakt wird stnadarmdäßig in der Sprache des Users erstellt, der den Job zum DART-Extrakt einplant. Vorleigen sollte der Extrakt jedoch in der Amtssprache der Finanzverwaltung.

Hierzu können Sie sich zunächst in der Transkation FTWCS die DARt-Datensegmente und die zugehörigen Tabellen ansehen, die in den DART-Extrakt standardmäßig einfließen. Die Transaktion FTWCF bietet dann einen Einblick auf die in jeem Datensegment enthaltenen Datenfelder. Wenn Sie nun kundeneigene Strukturen, Z-Tabellen und Appends haben, die steuerrechtlich relevante Daten enthalten, können Sie diese als „Customer Includes“ in den Feldkatalog aufnehmen.

In diesem Sinne macht es durchaus Sinn, sofern Sie die Möglichkeit dazu haben, die DART-Version auf Ihrem System durch regelmäßiges Einspielen von Support Packages auf dem aktuellen Stand zu halten. Grundsätzlich kann man es Ihnen aber nicht negativ auslegen, wenn Sie noch eine veraltete DART-Version auf Ihrem SAP-System vorliegen haben. Sie machen sich die Arbeit bei der Zusammenstellung des DART-Extraktes damit aber einfacher. Meistens ist es jedoch möglich, eine aktuelle DART-Version auch durch Einspielen eines SAP-Hinweises zu implementieren, ohne gleich einen neuen Support Package Stack einzuspielen zu müssen.

Ein DART-Extrakt kann höchstens aus 1.058 Dateien a 2 GB, also insgesamt 2,1 TB groß sein. Wenn Sie also ein komplettes Wirtschaftsjahr sauber extrahieren wollen und aber das Datenaufkommen in Ihrem System in einem Jahr größer ist, sollten Sie bereits unterjährig DART-Extrakte durchführen. Günstige Zeitpunkte hierfür sind Monats- oder Quartalsabschlüsse bzw. die Sperre der jeweiligen Periode über die Tabelle T001B. Vorsicht: Öffnen Sie die Periode wieder und führen Buchungen im vormals gesperrten Zeitraum durch, müssen Sie den Extrakt erneut erstellen.

Damit die unterjährige Extraktion per DART nicht die Jobeinplanung Ihrer Archivierung durcheinander bringt, können Sie die DART-Extraktion über die Transaktion SCMA einplanen. Dadurch können Sie die Ausführung von Archivierungsjobs per Prozesskette an die erfolgreiche Beendigung eines DART-Extraktes verknüpfen. Dabei ist es auch möglich, in dieser Prozesskette die Prüfsummen , die Kontrollsumen und die Datenintegrität des DART-Extraktes zu orüfen, bevor dieser archiviert wird.  Wenn Sie noch einen Schritt weiter gehen, können Sie daraufhin einen Job einplanen, welcher den DARt-Extrakt aus dem Archiv wird importiert, erneut die Prüfsummen testet und erst dann die Jobs für die Datenarchivierung frei gibt.

Wenn Sie unterjährig mehrere DART-Extrakte erstellen, sollte darauf geachtet werden, dass Sie diese Extrakte immer mit der selben DART-version erstellen, damit der Aussenprüfer eine einheitliche Sicht auf die Unternehmensdaten erhält. Wenn Sie eine DARt-Aktualisierung unterjährig nicht vermeiden können (aus Gründen des PAtch Managements in Ihrem Hause), sollten Sie bei der Erstellung der DART-View in der Selektion der Extrakte diese nach Erstellungsdatum absteigend durchführen. Beim Auswerten der DART-View setzen Sie außerdem den Schalter DDIC-Strukturen verwenden. Durch diese zwei Maßnahmen wird garantiert die aktuelle Version der Strukturen verwendet.

Aufgrund der performanceintensiven Detailselektion extrahieren Kunden häufig buchungskreisübergreifend alle Daten in einen einzigen DART-Extrakt. Grundsätzlich sollte jedoch ein Extrakt immer nur die Buchungskreise einer legalen Einheit enthalten.  Daher empfiehlt es sich, buchungskreisspezifisch zu extrahieren.

Bei der Erstellung von DART-Extrakten können Sie zwischen verschiedenen Formaten wählen. Ein DART-Extrakt stellt dabei einen Snapshot des Zustandes der SAP-Datenbank zum Zeitpunkt der Extrakterstellung dar. Da sich die Anforderungen an einen DART-Extrakt unterscheiden, gibt es verschiedene sogenannte Datenträgerformat. So gibt es beispielsweise ein Format für Deutschland (DE-Datenträger) und eins für die USA (US-Datenträger). Im Zweifel lässt sich die Option „alle Datenträger“ auswählen. Um einem Buchungskreis einem Datenträgerformat zuzuordnen, begeben Sie sich in die Transaktion FTWSCC.

Wie wir an anderer Stelle noch erörtern werden, empfiehlt es sich immer, einen DART-Extrakt vor und nach einer sogenannten Systemumstellung (beispielsweise Währungsumstellung oder Buchungskreiszusammenführung) durchzuführen. Prüfen Sie nach einer Extraktion immer das Extraktionsprotokoll über die Trnaskation FTW1A, um eine Vergleichsbasis zu erhalten. Stellen Sie hierbei sicher, dass beim Extrakt der Haken „Datenprüfsumme berechnen“ gesetzt ist.

Vergleichen Sie nach einem DART-Extrakt immer die Datenprüfsummen. Hierbei müssen die Buchungssummen des Belegkompaktjournals RFBELJ00 bzw. die Buchugnssummen des REports RFBUSU00 innerhalb des Selektionszeitraum gleich mit den Extrakt-Summen aus den Transaktionen FTWE bzw. FTWE1 sein. FTWE sind die Kontrollsummen für FI-Belege, FTWE1 alle Kontrollsummen des Extraktes an sich – notwneidg immer dann, wenn in einem Extrakt mehrere Buchungskreise enthalten sind.

Da es in der Vergangenheit Probleme mit der Perfomrance von DART-Extrakten bei großen Systemen gab, hat die SAP eine Reihe von SAP-Hinweisen veröffentlicht. Sie sollten daher die folgende Liste auf Relevanz in Ihrem System prüfen

  • 896894
  • 992803
  • 1012235
  • 1225592
  • 2059237
  • 2237433

Haben Sie außerdem eine DART-Version >= 2.5 im Einsatz, können Sie die seit 2.4 nicht mehr benötigten View-Indizes über den Report RTXWDELI löschen. Dies reduziert die Größe der extrakte um bis zu 30%. In diesem Zuge lohnt es sich auf, auf die DART version >= 2.8 zu aktualisieren, da diese eine Kompression von DART-Extrakten im ARchivsystem unterstützt. Dies reduziert die Größe um weitere 10-15%. Mit der DART Version >=2.6 wurde zudem eine Logik für DART-Views ausgeliefert, die nicht mehr den temporären Speicher eines SAP-Prozesses belastet.

Aus Berechtigungssicht empfiehlt es sich, den Anwendnern nur das Erstellen von Extrakten für bestimmte Buchungskriese erlauben. Hierfür ist jedoch entweder eine Dart-Version >=2.6e oder der Report RTXWLOG_ADJUST_COMPCO notwendig. Dann können Sie entsprechende bcuhungskreisspezifische Berechtigungen vergeben.

Wenn Sie nun eine Anfrage vom Aussenprüfer erhalten, die einen DART-Extrakt beinhaltet, werden Sie darum gebeten, eine DART-View zu erstellen (TX FTWY). Für diese erstellung sind Kenntnisse in SAQP-Query bzw. ABAP notwendig. Wenn Sie in den DART-Extrakt kundeneigene Strukturen, Appends und Z-Tabellen integriert haben, solletn Sie die Standardview kundenseitig ergänzen. Dies geht seit DART Version 2.5 über die tnraskation FTWYR. Dazu sollten Sie die 1SAP*-Stadnardviews in den Z-Namensraum kopieren und eise dann von dort anpassen.

Wichtig: Beim Übertragen von DART-Extrakten zwischen *NIX-basierten Betriebssystemen wie Linux oder AIX und der Windows-Welt ist darauf zu achten, dass Datenübertragungswege genutzt werden, welche die Zeilenumbrüche der Datei nicht verändert. Vermischen sich hier die Zeilenumbrüche mehrerer Betriebssytemwelten, kann der Aussenprüfer den DART-Extrakt nicht mehr in seiner Pürfersoftware (bspw. IDEA) einlesen. Wenn Sie beim Download der View-Datie nicht über die Transkation FTWN gehen, sondern direk tüber das austauschverzeichnis, lfassen Sie nur die View-Datei an und nicht ide dateien mit der endung _MT. Diese enthalten Steuerungsinformationen für die SAP-ALV-Anzeige.

Mit der Umstellung auf SAP S/4HANA werden einige formals getrennte Anwendungsbelege vereint, beispielsweise in der Tabelle ACDOCA. Damit der Zugriff sowohl aus Sicht der alten SAP ERP-Welt als auch aus Sicht der neuen Welt möglich ist, stellt die SAP Kompatibilitäts-Views zur Verfügung. Nähere Informationen hierzu sind im Hinweis 2237125 verfügbar.

Länderspezifika bei DART-Extrakten

Neben der Möglichkeit, DART-Extrakte im SAP Audit Format zu erstellen, können Sie die Extrakte auch im SAF-T Format zur Verfügung stellen. Diese Workflows sind derzeit mitunter binden für ide LÄnder Luxemburg und Portugal und optional für Österreich.

Für die LÄnder Polen, Frankreich und Ungarn gibt es länderspezifische DART-Erweiterungen, die bei einer Aussenprüfung der entpsrechenden Finanzverwaltugnen berücksichtigt werden müssen.

Branchenspezifika bei DART-Extrakten

Sofern das Vertragskontokorrent bzw. Massenkontokorrent (FI-CA) genutzt wird, kann für die Branchenlösung IS-RETAIL durch den Hinweis 1892650 die Möglichkeit zur Extraktion der Belegkette hinzugefügt werden. Für die Branchenlösungen IS-T, IS-U, FS-CD, IS-M und IS-PS gibt es dergänzend zu DART spezielle Extraktoren für Geschäftspartnerdaten, Custoizing und SD-Belege.

Für die Module IS-M-AM (Medien – Werbemanagement) und IS-M-SD (Medien – Vertrieb) müssen durch die Liste der folgenden SAP-Hinweise entsprehcende Erwetierungen in den DART-Standard integriert werden.

  • 573140
  • 600208
  • 605074
  • 609952
  • 680925
  • 748353
  • 853775
  • 857512

Human Capital Management

Das Äquivalent des DART-Extraktes in der SAP HCM Welt ist die Interface Toolbox (Transaktion PU12). Das Reisekostenmodul (FI-TV) hingegen sit wiederum in dem DART-Standard integriert und wird daher über DART berietgestellt.. Die Daten aus dieser transaktion werden vor allen Dingen in Lohnsteueraussenprüfungen angefordert. Das von SAP ausgeliferte Beispielformat DA00 muss hierbei häufig im Rahmen der Lohnsteueraußenprüfung angepasst werden. Die DSAG spricht hierbei eine EMpfehlung der zusätzlich aufzunehmenden Iinfotypen aus.

Hinwiese bezüglich der Berechtigungskonzeption des Prüfers und des Actions Logs finden Sie in den SAP Notes 445148, 529251 und 662805.

Im Zuge des PU12-Extraktes müssen HR-Tabellen in einer Struktur vordefiniert werden.  Aus diesen Daten wird dann ein ausführbares Programm generiert, welches auf die Struktur zugreift. Wie schon bei DART gilt hier wieder der Grundsatz: Sie müssen den Datenextrakt erstellen, bevor Sie die eigentlichen Anwendungsbelege auf SAP-Ebene archivieren.

Der Extrakt der Daten besteht in der Regel aus vier Bestandteilen. Neben den eigentichen Datendateien finden Sie eine Index.XML mit Metadaten zu den DAtendateien, einer .DTD-Datei zur Datendefinition der Index.xml und ein Beschirebungsdokument zu den einzelnen Dateien. Mehr zum Extrakt finden Sie im SAP Hinweis 1355616.

Zusätzlich ist seit 01. Januar 2018 die Bereitstellung der Daten über die Digitale Lohnschnittstelle (DLS) verpflichtend. Diese muss nach einer Standard-Installation entsprechend eingerichtet werden.

Die Grundsätze der Aufbewahrung nach GoBD

Die GoBD und die GoBS fordern in diesem Zusammenhang auch die Definition einer Organisationsansweisung zum Scannen von Papierdokumenten. Hierbei sollen verschiedene Punkte beschrieben sein, darunter

  • Welche Mitarbeiter dürfen scannen
  • zu welchem Zeitpunkt (etwa nach dem Abschluss eines Geschäftsprozesses oder Teilschrittes) ein Dokument gescannt wird
  • welche Dokumente gescannt werden
  • in wie weit eine bildliche Übereinstimmung mit dem Original erforderlich ist
  • Wie die Lesbarkeit, Vollständigkeit und Richtigkeit des Dokumentes sichergestellt wird
  • und wie mit der Protokollierung von Fehlern verfahren wird.

Sofern es aus betrieblichen Gründen notwendig ist, die Daten in einem Format vorzuhalten, welches schlecht maschinell auswertbar ist, so ist diese Prozedur zwar erlaubt, jedoch sind die Daten zusätzlich im maschinell auswertbaren Quellformat aufzubewahren. Doppelte Datenhaltung also.

Enthält eine E-Mail  eine qualifizierte Signatur, mit der diese unterschrieben wurde, muss auch diese erhalten bleiben.

Die GoBD definiert in diesem Zusammenhang einige grundsätze

  • eingehende Handels- oder Geschäftsbriefe und Buchungsbelege müssen im Format aufbewahrt werden, in dem sie empfangen worden (Kontoauszüge z. B. im PDF-Format aus dem Online Banking, E-Mails als .msg-Datei usw.)
  • Im DV-System erzeugte elektronische Unterlagen, z. B. SAP-Anwendungsbeleg, müssen im Ursprungsformat aufbewahrt werden (also als SAP-Archivdatei oder Tabellenexstrakt, so dass der Anwendungsbeleg im SAP-System wiederhergestellt werden kann)
  • In DV-Systemen erzeugte Dokumente wie etwa als Textdokumente erstellte Ausgansrechnungen, elektronisch abgeschlossene Vertärge, Handels- und Geschäftsbriefe, verafhrensodkumentationen usw. müssen im Ursprungsformat aufbewahrt werden.
  • Falls es nicht zumutbar ist, kann die Finanzbehörde es nicht negativ beanstanten, wenn der Steuerpflichtige seine elektronisch erstellten und anschließend in Papierform verwendeten Handels- und Geschäftsbriefe nur noch in Papierform aufbewahrt und nicht mehr digital. Der Zumutbarkeitsgesichtspunkt ist hierbei wichtig
  • Bei Einsatz von Kryoptgrafie-Techniken ist sicherzustellen, dass verschlüsselte elektronsiche Unterlagen im DV-System unverschlüsselt zur Verüfgung stehen
  • Die Umwandlung der Original-Dokumente in ein neues Version ist weiterhin die Originalversion aufzubewahren, beide Versionen miteinander über einen einheitlichen Index zu verwalten und zu verknüpfen und die konvertierte Version als solche zu kennzeichnen.

Was ist in diesem Zusammenhang mit verschlüsselten Dateien, beispielsweise verschlüsselten Datenbank-Backups? Nun, zunächst einmal ist ein Backup ja primär nicht dafür da, um die Daten für ein Steuer-Audit zu liefern. Von daher greift zu aller erst die Regelung, dass es erlaubt ist, Daten in ein verschlüsseltes Format zu konvertieren, solange die Quelldaten in maschinell auswertbarer Form noch vorliegen. Solange Sie also noch die Daten in Ihrem System haben, ist alles gut.

Was jedoch, wenn die Daten verloren gegangen sind und Sie auf das Backup zurückgreifen müssen? Nun, auch hier mangelt es etwas an Präzedenzfällen, jedoch fordert die GoBD ja eine unverzügliche Bereitstellung (an anderer Stelle auch unverzügliche Lesbarkeit) der Informationen. Wenn es also mehrere Tage dauert, ein TeraByte umfassendes Datenbank-Backup zu entschlüsseln und einzuspielen, kann nicht mehr von unverzüglicher Lesbarkeit gesprochen werden. Abhilfe kann hier entweder eine Daten-Replikation an einen Sekundärknoten oder das  regelmäßige Einspielen des Backups auf einem Cold Standby System helfen, auf welchem zur Herstellung des aktuellen Datenstandes danach nur noch eine Redo Logs eingespielt werden müssen.

Die GoBD  spricht in diesem Zusammenhang in einem Ihrer Aufbewahrungsgrundsätze davon, dass beim Einsatz von fKryptografie-Techniken sichergestellt werden muss, dass die verschlüssleten Unterlagen im DV-System selbst in entschlüsselter Form zur Verfügung stehen. Werden zudem Signaturprüfschlüssel verwendet, müssen diese so lange aufbewahrt werden, bis die gesetzliche Aufbewahrungspflicht der entsprechenden Daten endet.

Wenn der Aussenprüfer verlangt, dass Sie ihm die steuerrechtlich relevanten Information in Form einer Datenträgerüberlassung zur Verfügung stellen, dürfen die Daten auf diesem Datenträger selbstverständlich verschlüsselt sein, solange der Auditor dazu in der Lage ist, diese Daten in angemessenem Aufwand zu entschlüsseln.

Im Zusammenhang mit der maschinellen Auswertbarkeit von elektronsichen Dokumenten wurde das Format der ZUGFeRD-Rechnung etabliert. Auch wenn das Dokument aktuell in Deutschland noch kein bindender Rechnungsstandard ist, kann der Standard schon heute genutzt werden.

Eine ZUGFeRD-Rechnung besateht aus einem PDF/A-3 Dokument und einer im Container eingebetteten .xml-Datei. Das PDF/A-3 ist dabei die bildhafte Darstellung des Dokumentes, das XML-Dokument dient zur maschinellen Weiterverarbeitung der Rechnung. Des Weiteren sind in der XML-Datei die umsatzsteuerrechtlichen Pflichtangaben als Pflichtfeld definiert.

Grundsätzlich empfiehlt sich, um die maschinelle Auswertbarkeitder Daten in Ihrem Archivsystem zu gewährleisten, ein eigenständiges Enterprise Content Management System mit eigenständiger Suchoption und eigenständigem Index (neben der TAOX-basierten indizierung im SAP-System) oder alternativ SAP ILM einzuführen. Dies stellt sicher, dass eine Auswertung der Daten auch dann noch möglich ist, wenn das eigentliche archivierte SAP-System bereits stillgelet wurde.

Ersetzendes Scannen

Durch die Regelung des ersetzenden Scannens gibt der Gesetzgeber dem Steuerzahler die Möglichkeit, Oiriginal-Papierbelege zu entsorgen, wen diese revisionssicher digital abgelegt sind . Hierbei gelten jedoch folgende Grundsätze:

  • der Inhalt der Belege darfdurch die Digitalisierung nicht verfälscht werden
  • der Inhalt muss vollständig und lesbar sein
  • es gibt keine steuerliche oder rechtliche Aufbewahrungspflicht für den Original-Papierbeleg (dazu kommen wir gleich)
  • die Beweiskraft des Beleges bleibt nach der Digitalisierung erhalten

Es gibt diverse Simulationsstudien, die bewerten, in wie weit Gerichte digitalisierte Belege als Beweismittel akzeptieren. Auch wenn die Ergebnisse grundsätzlich gut aussehen, kann ich an dieser STelle keine grundsätzliche Empfehlung zur Vernichtung von Original-Papierbelegen aussprechen.

Die folgenden Original-Papierbelege dürfen Sie auf keinen Fall vernichten, da für diese eine steuerliche oder rechtliche Aufbewahrungspflicht herrscht

  • Zollbelege, insbesondere Ausfuhr- und Einfuhrbelege
  • Rechnungen mit ausländischer Vorsteuer, da einige ausländische Finanzämter Originalbelege verlangen
  • Rechnungen, die einer Betriebsstätte im Ausland zuzurechnen sind
  • Steuerbeschieinigungen und Steuerquittungen, insbesondere zu Dividendenausschüttungen, Kapitalerträgen und ausländischen Quellensteuerbescheinigungen

Dokumentationspflicht

im Rahmen der GoBD sind Sie als Steuerpflichtiger unter Anderem dafür verantwortlich, eine Verfahrensdokumentation zu erstellen, die folgende Punkte enthält:

  • Beschreibung aller steuerrechtlich relevanten DV-Syteme, darunter auch Vor- und Nebensysteme, sowohl aus technischer als auch betriebswirtschaftlicher Sicht
  • Beschreibung von Inhalt, Aufbau, Ablauf und Ergebnisse der Datenverarbeitung. Dazu gehört eine Darstellung der internen Verarbeitungslogik, beispielsweise durch Programmablaufdiagramme, Struktogramme, Netzdiagramme und Schnittstellenbeschreibungen.
  • Aufführen der Datenstruktur, darunter Tabellen und Felder, aber auch beispielsweise Dokumentstrukturen und die Verknüpfungen der einzelnen Datenquellen untereinander. Eine Verknüpfung ist hierbei beispielsweise das Zusammenspiel aus den Kopf- und Positionsdaten der jeweiligen Tabellen im SAP-System.
  • Nennen der Kontrollmechanismen beim Verändern oder Löschen, die die Revisionssicherheit bzw. Unveränderbarkeit der Daten gewährleisten sollen.
  • Aufzeigen der Prozesse zum Empfang, zur Erfassung, Verarbeitung, Aufbewahrung und der Reproduktion von Buchungsbelegen in elektronischer Form. Unter Anderem sollen hier auch kundeneigen genutzte ABAP-Reports geschildert und dem Auditor zugänglich gemacht werden, wenn diese unternehmensintern verwendet werden.
  • Erklären der automatischen und halbautomatischen Buchungsvorgänge bei Dauersachverhalten, die nicht mehr manuell durch Menschenhand abgewickelt werden
  • Präsentieren der getroffenen Maßnahmen zur Erstellung und Wiederherstellung einer Datensicherung.
  • Skizzieren des prozesses zur Digitalisierung von Papierdokumenten (darunter auch die Punkte, die weiter oben schon in diesem Zusammenhang genannt wurden)
  • Glossar mit allen wichtigen Abkürzungen und Symbolen des Datenverarbeitungs-Systems
  • Protokollieren aller wichtigen System- und Verfahrensänderungen
  • Eine Anwenderdokumentation
  • Eine Betriebsdokumentation. Dazu gehören Betriebsprozesse im Regelbetrieb (warten, Aktualisieren), zum Notbetrieb, zur Datensicherheit, zu Migrationen und zum Berechtigungskonzept einschließlich Benutzerverwaltung
  • Schilderung der etabliertne Kontrollprozesse, beispielsweise interne Audits, Internes Kontrollsystem (IKS), Change Management Verfahren usw.

Auch diese Dokumentation ist dabei revisionssicher zu führen und aufzubewahren. Zur Protokollierung aller wichtiger System- und Verfahrensänderungen helfen Ihnen die entsprechenden Protokollierungs- und Änderungsmanagementlösungen, die im SAP-Umfeld verfügbar sind.

Dazu zählen etwa ChaRM, die diversen Standard-Logs des SAP NetWeaver, die oben angesprochene Tabellenprotokollierung (u. U. auch in Transportaufträgen), sowie eigene  revisionsischer abgelegte Auditberichte, die im Zuge von internen Audits entstanden sind.

Die Verknüpfungsinformationen der Tabellenfelder sind Bestandteil eines DART-Extraktes. Daher ist es empfehlenswert, dass Sie in vorauseilendem Gehorsam DART-Extrakte erzeugen und revisionssicher ablegen, bevor Sie auf die Daten des jeweiligen Geschäftslaufs einen Archivierungslauf starten. Denn einen DART-Extrakt können Sie nur auf Daten anwenden, die noch nicht über die SARA in ein externes Archivierungssystem verschoben wurden (Ausnahme: Einige Drittanbieter-Tools bieten diese Möglichkeit).

Der Datenschutzaspekt

Nein, wir sprechen jetzt nicht auf einmal über die EU-DSGVO. Vielmehr geht es darum, dass ein Aussenprüfer, der Daten aus Ihren DV-Systemen im Zuge einer Aussenprüfung entnimmt, nicht dafür haftet, dass er im Zuge seiner Tätigkeit Betriebs- und Berufsgeheimnisse ersehen kann. Auch die Finanzverwaltung ist hierbei kein helfendes Organ. Allein Sie sind dafür verantwortlich, dass dem Aussenprüfer nur die Daten zur Verfügung gestellt werden, die er zur Erfülung seines Auftrages benötigt. Sollte der Aussenprüfer durch den Zugriff auf Transkationen und Daten, die nicht steuerrechtlich relevant sind, auf Infromationen stoßen, können Sie sich als Unternehmen nicht per se auf ein Verwertungsverbot stützen.

Das ganze geht noch weiter, wenn auf den Systemen entsprechende elektronische Patienten-, Mandanten- oder Personalakten hinterlegt sind. In diesem Zusammenhang befassen sich Kunden mit den Möglichkeiten des Data Maskings und Subsettings im SAP-Umfeld durch Drittanbieterlösungen, SAP- oder Datenbank-Mittel. Data Masking und Subsetting ist dabei für Datensätze in der Datenbank sinnvoll, digitales schwärzen für digitalisierte Papierdokumente (die beispielsweise im PDF-Format vorliegen).

Wählt der Aussenprüfer die Zugriffserteilung der Datenträgerüberlassung, müssen Sie ihm selbst einen Datenträger zur Verfügung stellen. Die Übergabe des Datenträgers sollte protokolliert werden, denn die Mitnahme des Datenträgers aus der Sphäre des Steuerpflichtigen ist grundsätzlich erlaubt. Deswegen sollten die Daten auch in Absprache mit dem Auditor verschlüsselt abgespeichert werden.

Um dies zu gewährleisten, implementiert man in der Regel Maßnahmen für digitales Schwärzen oder Digital Rights Managemen. Auch simple Datenschutzthematiken wie etwa die Begrenzung des Zugriffszeitraums sind hier wichtig. Auch eine Protokollierung des Prüferzugriffs ist an dieser Stelle angebracht. Grundsätzlich sollten Sie hierbei neben dem technisch orientierten Security Audit Log und dem SQL Audit Log das sogenannte Action Log aktivieren.  Dieses kann im Anschluss über die Transaktion SLG1 ausgewertet werden.

Viele Kunden implementieren in diesem Zusammenhang das SAP NetWeaver Read Access Logging (RAL) sowie das UI Logging. Des Weiteren ermöglichen Tools wie SECUDE Halo Core die detaillierte Zugriffsprotokollierung und Zugriffskontrolle auf Datensatzebene. Es empfiehlt sich, das Action Log im Anschluss über den Report CA_TAXLOG als Druckliste und über das Archivierungsobjekt BC_SBAL als Anwendungsbeleg zu archivieren. Nach der Archivierung löschen Sie das Action Log über die SLG2.

Ein erster Schritt ist außerdem die Entwicklung einer kundeneigenen Auditor-Rolle, die auf der SAP-Standardrolle SAP_AUDITOR_TAX_* basiert. Vergessen Sie nicht, diese Rolle regelmäßig abzugleichen, da die SP für diese Rolle regelmäßig Änderungen durchführt.  Um einen Abgleich Ihrer Z-Rolle mit der SAP-Standardrolle nach Einspielen eines support Packages durchzuführen, stehen Ihnen die Transaktionen S_BCE_68001777 (Report RSUSR050) bzw. ROLE_CMP zur Verfügung.

Insbesondere benötigt aus Sicht der DSAG ein Aussenprüfer keinen Zugriff auf die Transaktionen SE16, SE16N, den Data Browser zur Anzeige von Tabelleninhalten, SE17 sowie SA38. Freilich braucht der Aussenprüfer aber eine Übersicht über die vom SAP-Anwender erstellten Eigenentwicklungen auf dem System. Um zu verhindern, dass der Prüfer das Benutzermenü der Auditor-Rolle auf das SAP-Standardmenü umschaltet, können Sie in der Tabelle USERS_SSM einen entsprechenden Schalter setzen. Einen Überblick der für einzelne Transkationen nötigen Berechtigungsobjekte bekommen Sie über die SU22 oder einen entsprechenden Berechtigungstrace über STAUTHTRACE.

Hierzu steht die Transkation COAT zur Verfügung. Um das versehentliche Löschen von COAT-Änderungsbelegen zu verhindern, sollten Sie sicher gehen, dass der Eintrag COAT_TOOLBOX_TREE – CDOC_DELETE_REMOVE mit X besetzt ist. Die sElektion relevanter Namensräume wird über die Einträge in den Tabellen TRNSPACET/TRNSPACETT festgelegt. Eine ausführliche Dokumentation zu cOAT finden Sie im SAP Hinweis 1783942. Sofern in diesen Eigenentwicklungen steuerrelevante Daten enthalten sind, sollten entsprechende Z-Transaktionen erstellt und in die SAP-Benutzerrolle für den Aussenprüfer aufgenommen werden. Eine Anpassung dieser Rolle ist beispielsweise auch nowtendig, wenn Sie in Ihrem System einen Special Ledger eingerichtet haben und der Aussenprüger darauf Zugriff benötigt. Für die Gewährung der Zugriffe Z1 und Z2 steht außerdem der zentrale SAP-Hinweis 445148 zur Verfügung. Dieser wird stetig angepasst und sollte daher regelmäßig gesichtet werden.

Wenn Sie noch ein älteres release auf Ihrem SAP-System haben, ist die SAP_AUDITOR_TAX_*-Sammelrolle wahrschienlich veraltet. Sie können jedoch die aktuellen Änderungen aus den Jahren 2013 bis 2015 in die Rolle integrieren, indem Sie die folgende Liste an SAP-Hinweisen einspielen.

  • 2212390
  • 2267794
  • 2269076
  • 2289254
  • 2289271

Als nächster Schritt sollten Sie einen sogenannten  Prüfungszeitraum festlegen.  Dieser legt den Zeitraum fest, in welchem der Prüfer BEwegungsdaten im SAP-System sehen kann. Bewegungsdaten außerhalb dieser Periode bekommt der Auditor dann nicht zu Gesicht. Doch Vorsicht: In den Prüfungszeitraum fallen auch offen Posten, die zwar vor der Prüfperiode entstanden sind, aber zum zeitpunkt der Prüfperiode noch offen waren. Außerdem gilt diese Einschränkung nicht für Stammdaten.

Legen Sie zunächst in der Transaktion TPC2 für den Benutzer des Prüfers eine DART-Benutzergruppe fest. Diese können Sie frei definieren. Häufig repräsentiert eine DART-Benutzergruppe eine bestimmte Aussenprüfung (z. B. Zollprüfung, Umsatzsteuer-Prüfung, Verbrauchssteuerprüfung usw.)

In der Tabelle TPCPROGS finden Sie SAP-Standardprogramme, die eine Logik für eine SAP-Zeitraumprüfung implementiert haben. Sie können auch kundeneigene Z-Programme so ausgestalten, dass sie eine derartige Logik implementiert haben. Diese müssen Sie dann in diese Tabelle  über die SM31 entsprechend eintragen.

Im Anschluss pflegen Sie in der Transaktion TPC4 alle Programme, die explizit der Aussenprüfer für seine Zeitraumprüfung nutzen darf. Diese Programme werden dann in die Tabelle TCPPROG (ohne S) eingetragen. Diese stellt also eine Untermenge der Tabelle TPCPROGS dar. Zu guter letzt verbinden Sie in der Transkation TPC6 die Programme mit Zeitraumprüfungslogik mit der DART-Benutzergruppe und geben einen Prüfzeitraum an. Alle Benutzer, die in dieser DART-Benutzergruppe sind, dürfen damit alle Programe nutzen, die der jeweiligen Applikationsgruppe (z. B. Anlagenbuchhaltung FI-AA) zugeordnet sind, um Stammdaten sowie Bewegungsdaten aus diesem Zeitraum einzusehen. Falls Sie in den Applikationsgruppen einen Eintrag für das MM-Modul vermissen: Diese Daten werden über die Gruppe FI-FI abgedeckt.

PRoblematisch wird der Datenschutzaspekt bei den NEbensystemen, darunter SAP CRM bzw. C/4HANA, SAP SRM und SAP PI/PO. Für all diese Systeme sind keine STandardrollen für Aussenprüfer verfügbar. Es müssen daher kundeneigene Lösungen realisiert werden, um dem Aussenprüger einen Nur-Lesen-Zugriff auf ausschließlich steuerrelevante Daten zu ermöglichen. Für SAP IS hingegen sind im Bereich FI-CA stndardmäßig Prüferrollen und FI-CA-eigene Extrkationsprogramme enthalten.

Zwar darf der Aussenprüfer zwar die Daten aus dem Auswertesystem auf den ihm zur Verfügung gestellten client-PC herunterladen, es ist ihm jedoch nicht gestattet, die Daten auf eigenen eigenen USB-Stick zu überspielen. Dies können Sie mit einem Digital Rights Management auch entsprechend forcieren, um hierfür auch eine technische Hürde zu schaffen.

Des Weiteren führen Sie im Unternehmen ja durchaus auch Daten, die nicht unbedingt steuerrechtlich relevant sind. Ein Zugriff das Wirtschaftsprüfers auf diese Daten ist daher nicht notwendig. Sie als Unternehmen sind jedoch selbst dafür verantwortlich, wenn Sie eine solche Trennung wollen. Im Rahmen der sogenannten Erstqualifikation bestimmten Sie, welche Daten aus dem System für die steuerrechtliche Bewertung des Außenprüfers notwendig sind. In der zweiten Linie sind dann auch Sie dafür verantwortlich, dass der Auditor nur auf diese Daten zugreifen kann. Einen guten Anhaltspunk für die relevanten Daten aus dem SAP-System können die Verknüpfungsinformationen aus einem DART-Extrakt liefern.

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren …

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.