Anzeigen

Anbieter von Lösungen zur elektronischen Steuerprüfung
hmd Solftware
Verfahrensdoku
DATEV eG
GISA
Caseware
Home

Maschinell auswertbare Daten im Sinne der GdPdU und revisionssichere Belege im Sinne des HGB sind zweierlei

Replik auf Peter Eller, Rainer Böhle und Stefan Müller (OFD-München) zu Online-Kontoauszügen

Von Raoul Kirmes


Raoul Kirmes

Raoul Kirmes ist Produktmanager bei der mentana-claimsoft AG, einem auf Signaturlösungen spezialisierten Softwareentwickler. Er ist Mitautor des Buches „Digitale Signaturen in der Praxis“ und Verfasser von zahlreichen Fachbeiträgen zum Thema Beweiskraft elektronischer Dokumente.

Der hier geführte Diskurs offenbart mit zunehmendem Fortgang, dass sich einige der vorliegenden Differenzen allein darauf zurückführen lassen, dass die Begriffe „Daten" und „Belege" so ungenau verwendet werden, dass es bei der Frage der Abgrenzung, welche Daten „auswertbar" dem Zugriff des Finanzamtes zur Verfügung zu stellen sind und der Frage, wie elektronische Belege aufzubewahren sind bzw. was überhaupt ein elektronischer Beleg ist, einiges durcheinander geht.

Ausgangspunkt der Diskussion war die Auffassung der OFD München, dass ein Online Kontoauszug als Datei per se nicht die Anforderungen an einen Beleg erfüllen kann. Dieser Punkt ist zunächst völlig getrennt von der Frage zu behandeln, ob und welche Daten dem Zugriff des Prüfers (GdPdU) zur Verfügung zu stellen sind. Die Belegfunktion ist nämlich nach wie vor zwingend und neben den Verpflichtungen zum Datenzugriff zu erfüllen. Nachfolgend soll deshalb den einzelnen Vorschlägen insbesondere unter diesem Geschichtspunkt nachgegangen werden.

Und um die Diskussion zusätzlich mit etwas Praxis aufzuladen und um die eine oder andere ketzerische Bemerkung zu beantworten, füge ich dem Beitrag einen Online-Bankbeleg bei, der den gesetzlichen Anforderungen entsprich, da dieser mit einer qualifizierten elektronischen Signatur versehen wurde, die kostenlos über www.signaturportal.de verifiziert werden kann.

Hinweis: Zur vollständigen Anzeige des Online-Bankbelegs ist der Acrobat-Reader / Adobe Reader ab Version 6 erforderlich.

Auch finden sich auf dem Beleg diverse Kommentare, die an den Beleg angefügt wurden, um darzustellen, dass auch Buchungsvermerke, Kontierungen oder auch inhaltliche Anmerkungen (z.B. im Rahmen einer Rechnungsprüfung) mit einem solchen elektronischen Dokument problemlos verbunden werden können. Die Inhalte der Kommentierungen werden sichtbar durch einfaches doppelklicken mit der Maus auf das Symbol.

Zu den einzelnen Vorschlägen:

Herr Eller schlägt vor, drei Gruppen von Kontoauszügen zu unterscheiden.

  1. DFÜ- Datenübertragung
  2. Klassische Bankauszüge, die per Post kommen oder am Bankdrucker erstellt werden und
  3. Online Kontoauszüge (es gibt nur den elektronischen Beleg)

Gruppe 2

Dabei ist zur Gruppe 2 wohl nichts strittig, denn es handelt sich eben um Papierbelege, für die sich kein Problem hinsichtlich der Revisionssicherheit ergibt und für die auch eine Auswertbarkeit für IDEA nicht gegeben sein kann.

Gruppe 1

Allerdings ist auch die Gruppe 1 kein Kontoauszug im Sinne eines Beleges, sondern es handelt sich vielmehr „nur" um Daten. Wenn solche Datenströme per DFÜ oder als auswertbares Datenformat (z.B. XML, iDoc, BAPI u.v.a.m.) übermittelt werden, dann ersetzen diese nicht einen Beleg. Sie sind nützlich und in vielen Branchen unabdingbares Werkzeug, um sinnvolle elektronische Prozesse zu gestalten. Sie sind jedoch nicht geeignet, einen „Beleg" im Rechtssinn zu ersetzen, wo dieser gesetzlich gefordert ist. Als Paradebeispiel für die zwingende Belegpflicht kann wohl §14 UStG genannt werden.

Neben dieser Datenübertragung ist also entweder ein Papierbeleg oder ein revisionssicheres elektronisches Dokument zusätzlich zu übermitteln. Bei Verwendung von XML- Dokumenten kann "Datenstrom" und „Beleg" auch in einer Datei zusammenfallen, sofern diese qualifiziert elektronisch signiert ist. Dies ändert aber nichts an der rechtlichen Trennung zwischen Belegfunktion und Datenfunktion, die dann letztlich auch darüber entscheidet wie diese „Zwitter-Datei" aufzubewahren und zu behandeln ist.

Diese richtige und strikte Funktionstrennung gibt der Gesetzgeber deshalb auch vor. So werden im BMF- Rundschreiben-- zur Umsetzung der Richtlinie 2001/115/EG (Rechnungsrichtlinie) und der Rechtsprechung des EuGH und des BFH zum unrichtigen und unberechtigten Steuerausweis durch das Zweite Gesetz zur Änderung steuerlicher Vorschriften (Steueränderungsgesetz 2003 - StÄndG 2003) Aktz. GZ IV B 7 - S 7280 - 19/04 vom 29.01.2004-- besondere Regeln für den Datenaustausch (EDI) im einzelnen geregelt. Hier unter dem Gesichtspunkt der Umsatzsteuer. Ganz selbstverständlich wird eben neben dem Datenstrom ein sog. „Sammelbeleg" (Rdn.20) gefordert. Dieser, und nur dieser, ist dann steuerrelevant und muss revisionssicher als „Beleg" aufbewahrt werden. Nichts anderes kann für eine Übermittlung von Kontodaten per DFÜ gelten. Neben den per DFÜ- übermittelten Daten ist ein Beleg erforderlich.

Insofern ist die Feststellung von Herrn Böhler, dass eine reduntante Speicherung keinen Sinn macht, richtig und fast selbstverständlich. Der Datenstrom selbst wird weder redundant noch sonst wie aufzubewahren oder zu archivieren sein. Er wird schlicht vom Empfängersystem „konsumiert" und ist dann Bestandteil dieses Systems und folgt dann auch nur den für dieses System einschlägigen Archivierungspflichten (also ggf. Zugriff per IDEA auf die konsumierten Daten). Die OFD verlangte allerdings auch keine überflüssige Speicherung, sondern einen revisionssicheren Beleg, wo dies gesetzlich gefordert wird. Und das ist dann der „Kontoauszug" wie er bislang in der Diskussion stand und dieser muss nicht mehr zwingend ein Papierbeleg sein, und genau hier liegt doch der gewaltige Kostenvorteil für die Institute. Die Einsparungen durch elektronische Beleg- und Rechnungserzeugung und Übermittlung sind millionenschwer, weshalb sich jede eingehende Beschäftigung mit dem Thema lohnt.

Zusammenfassend kann man also konstatieren, dass dieser zusätzliche Beleg wenn er elektronisch erzeugt und übermittelt werden soll, in die Gruppe 3 oder wenn er als Papierauszug versendet wird in die Gruppe 2 gehört, für die dann die normalen Regeln gelten.

Gruppe 3

Zunächst ist klarzustellen, dass die Ansicht eines Onlinekontoauszuges, also eine schlichte Kontoübersicht (HTML- Seite im Browser) steuerlich nicht relevant ist.

Entscheidend ist, ob der Kunde einen elektronischen Beleg erhält. Dies wird also auch eine elektronische Übermittlung voraussetzen per Mail oder per Download.

Und theoretisch könnte dass auch, wie von Eller genannt, eine HTML- Datei sein. Auch diese könnte mit einem Zeitstempel oder durch externe PKCs7- Signatur revisionsfest gemacht werden und dadurch Belegfunktion erhalten. Allerdings würde niemand auf eine solche Idee kommen, da das HTML- Datenformat für diese Anwendung völlig unhandlich wäre. Klassicherweise werden die Daten nur für die Anzeige als HTML- Content im Browser zur Verfügung gestellt, und das hat zunächst keine steuerliche Relevanz. Will der Kunde den Beleg dann downloaden, wird er regelmäßig eine PDF-Datei erhalten. Diese trägt dann, um die Belegfunktion im Rechtssinn zu erfüllen, eine Signatur oder einen Zeitstempel im Sinne des SigG.

Eine zusätzliche Auswertbarkeit für IDEA ist für diese Belege im Normalfall nicht gefordert und auch nicht sinnvoll.

Abschließend auch noch ein Wort zum Sanktionsapparat bei Missachtung der Vorschriften für die Erzeugung elektronischer Belege. Es ist wohl unstrittig, dass der steuerliche Sanktionsapparat durch die elektronischen Belege nicht schärfer geworden sein kann. Wie sollte dass auch zu begründen sein. Insofern gilt für Zuschätzungen oder andere Sanktionen alles das, was auch bisher galt, wenn die Buchführungs- oder Steuervorschriften nicht genau eingehalten wurden. Aber wer will schon über die Rechtsfolgen diskutieren? Es muss doch bereits vermieden werden, gesetzliche Regelungen überhaupt zu verletzen, und hier liegen die Risiken auch noch in anderen Bereichen.

Es gilt auch weiterhin der Grundsatz „Keine Buchung ohne Beleg!" und damit ist das Feld der Probleme eröffnet.

Insbesondere Unternehmen mit Testierungspflicht riskieren die Versagung des Testats oder jedenfalls einen unangenehmen Einschränkungshinweises, wenn sie Ihre Jahresabschlüsse auf Belege stützen wollen, die keine Belege im Rechtssinne sind. Und dabei sind ja Online- Kontoauszüge eine bislang kaum vorkommende Spezies. In großem Umfang unbeachtet bleibt dieses Problem bei elektronischen Rechnungen, die nach wie vor auch in großem Stil und allen gesetzlichen Regelungen zum Trotz ohne elektronische Signatur versendet werden.

Offensichtlich sind sich die Rechnungsempfänger nicht bewusst, dass Ihnen der Vorsteuerabzug für solche „nicht beleghaften Rechnungen" verloren geht und sie sich jederzeit dem Risiko einer Vorsteuerrückforderung aussetzen. Sonst wäre diese Praxis kaum denkbar.

Aber auch die Versender von unsignierten Rechnungen riskieren leichtfertig die Ordnungsmäßigkeit ihrer Bücher. Kein Wirtschaftsprüfer kann über einen derartigen Mangel sowohl in umsatzsteuerrechtlicher Hinsicht als auch aus Sicht einer ordnungsgemäßen Buchführung hinweggehen. Hier liegt das eigentliche Problem und das Risiko für die Unternehmen. Und der Beratungsbedarf in diesem Bereich ist ungebrochen hoch, wie ich aus meiner täglichen Praxis berichten kann. Kaum ein betroffenes Unternehmen hat sich diese Risiken jemals vor Augen geführt und die Verfügung der OFD München zeigt ja überdeutlich, dass sich die Finanzbehörden inzwischen fit gemacht haben, was die elektronischen Medien betrifft. Ich denke also, dass eine Verharmlosung des Problems nicht angezeigt ist. Die Unternehmen, die sich elektronischer Medien bedienen sind vielmehr gefordert, auch die rechtlichen Rahmenbedingungen einzuhalten. Lösungen gibt es inzwischen in großer Zahl und für jeden Geldbeutel. Das Argument, der Gesetzgeber würde Dinge fordern die man nicht erfüllen kann, trägt nicht.

Newsletter
 hier abonnieren
Raoul Kirmes: Maschinell auswertbare Daten im Sinne der GdPdU und revisionssichere Belege im Sinne des HGB

18.03.2024

powered by webEdition CMS
powered by webEdition CMS