Das komprimierte PDF ist zwar immer noch ein gültiges PDF, aber kein PDF/A-3 mehr. Der Kompressionsvorgang komprimiert im wesentlichen die beiden eingebettetet Font-Files (Arial-Bold und Arial) und entfernt dabei auch gleich sämtliche XMP-Metadaten. Die eingebetteten XML-Dateien bleiben erhalten. Damit ist das Ganze weder PDF/A-3 noch ZUGFeRD konform. Ein ZUGFeRD-Extraktror würde deshalb auch dieses File ablehnen, weil keinerlei Identifikation auf ZUGFeRD enthalten ist.
FAQs
Sorry, this entry is only available in Deutsch.
Ein “einheitliches Rechnungsdatenformat für den elektronischen Rechnungsaustausch”, das in einer PDF/A3-Datei eingebettet die menschenlesbare Rechnung und den dazugehörigen maschinen-lesbaren Datensatz vereint. Das jedoch setzt voraus, dass der Rechnungssender ZUGFeRD-PDFs erstellen kann bzw. der Empfänger diese verarbeiten kann. Es ist gedacht für alle Anwendungsbereiche oder Branchen, in denen EDI nicht etabliert ist, z.B. Verwaltung oder Kleinstbetriebe.
In der Konsumgüter-Branche ist der Standard für den Austausch von strukturierten = maschinen-lesbaren Daten ist seit langem schon EDIFACT, das quasi von jedem “EDI-fähigen” Handelspartner gesendet bzw. empfangen und verarbeitet werden kann.
Pranke bietet die Technologie, um ZUGFeRD in EDIFACT zu konvertieren und/oder umgekehrt aus EDIFACT-Daten das ZUGFeRD-Format zu erstellen, um alle Handelspartner zu bedienen. So ergänzt ZUGFeRD den bewährten EDI-Austausch für die Elektronische Rechnung.
Sorry, this entry is only available in Deutsch.
Auf der Basis von EDI
In einem Umfeld, in dem per EDI schon Stammdaten, Lieferscheine und Bestellungen ausgetauscht werden, liegt er nahe: der papierlose Versand bzw. Empfang von Rechnungen per EDI. Eine (zusätzliche) PDF-Version dieser Rechnung dient nicht Versand oder Austausch, sondern einzig dazu, die Rechnungsdaten für die Archivierung bzw. Prüfung menschenlesbar zu machen.
Aufbereitung & Validierung während des Versands
Über die eGate-Server läuft aller EDI-Datenverkehr der Pranke-Kunden: Hierüber gehen INVOIC-Nachrichten vom Sender zum Empfänger. Weiterhin werden diese INVOIC-Nachrichten nach Versand bzw. vor Empfang zunächst auf Vollständigkeit validiert und dann als „menschenlesbares“, langzeitarchivierbares PDF aufbereitet – inklusive der darin eingebetteten EDIFACT-Originaldatei.
Die Details zur Technik
Ein ZUGFeRD-PDF/A3-Container mit Comfort-Profil-Validierung...
Der erzeugte “Archiv-Container” ist standardmäßig eine PDF/A3-Datei. Diese enthält eingebettet das EDIFACT-INVOIC-Original und weiterhin die Index-Informationen nach dem ZUGFeRD-XML-Datenmodell. PDF/A3 ist der PDF-Standard für die Langzeit-Archivierung (ausführliche Beschreibung bei Wikipedia in neuem Fenster öffnen) und technisch so konzipiert, dass nicht nur Dateien, sondern auch z.B. Schriftarten eingebettet werden. Weiterhin ist ein solches PDF nach der Erstellung standardmäßig schreibgeschützt. All diese Maßnahmen gewährleisten, dass der PDF-Inhalt auch in zehn Jahren wie am ersten Tag aussieht und nicht verändert werden konnte. Die ZUGFeRD-Informationen stellen dabei Index und Nutzdaten zugleich für das archivierende Dokumenten-Management-System dar, welches somit jede Information aus der Rechnung verwenden kann. Damit das Archivsystem nur gültige Rechnungen erhält, wird jedes Dokument bei Pranke gegen die Regeln des ZUGFeRD-Comfort-Profil validiert. Bei unvollständigen Rechnungen wird der Service-Nutzer benachrichtigt, um je nach Fall die Rechnung neu anzufordern bzw. korrigiert zu versenden. Mit jedem gängigen, aktuellen Dokumenten-Management-System (offline oder in der Cloud) erfüllt der Service-Nutzer somit ohne weitere Konfiguration die steuerrechtliche Anforderung, sowohl das Rechnungsoriginal (INVOIC) sowie die dazugehörige menschenlesbare Version revisionssicher zu archivieren.
Pflichtangaben-Prüfung nach § 14 Abs. 4 UStG
Jegliche gültige Rechnung – ob Papier oder elektronisch – muss Pflichtangaben enthalten. Vor der Aufbereitung der Archiv-PDF/A3-Daten werden diese Angaben geprüft. Sollten Angaben fehlen und die Rechnung damit nicht zum Vorsteuerabzug berechtigen, wird diese daher angehalten und der Service-Nutzer per Mail benachrichtigt
Fehlerfall und Benachrichtung
Zusammengefasst: Schlägt die ZUGFeRD-Comfort-Validierung fehl oder fehlen UStG-Pflichtangaben in der INVOIC, wird daraus kein Archiv-Paket erstellt. Der Service-Nutzer erhält eine detaillierte Fehlermeldung mit Angaben zum Dokument und zum Fehler selbst, um daraufhin Kontakt mit dem Handelspartner aufzunehmen. Die INVOIC innerhalb des gewohnten EDI-Nachrichtenstroms an den Empfänger bleibt unbeeinflusst, da diese vor der obigen Validierung & Prüfung abgezweigt wird: Dies entspricht übrigens dem Vorgehen wie beim “Papieroriginal mit INVOIC”, wenn z.B. im Gegensatz zu den EDI-Daten der Brief nicht ankam, oder wenn eine neue Rechnung nach einer manuellen Prüfung nötig wäre.
Entworfen für beide Rechnungs-Beteiligten
Eine Umstellung weg von Papier auf eine elektronische Rechnungsabwicklung ist nur sinnvoll und rechtlich einwandfrei, wenn beide Seiten das jetzt zum Original erhobene EDIFACT-Dokument archivieren. Hat ein Handelspartner des Service-Nutzers selbst noch nicht die Möglichkeit, das EDI-Rechnungsoriginal direkt zu archivieren (oder müsste hierfür erst interne Entwicklung betrieben werden), können die “Archiv-Container” = PDF/A3-DAteien auch jener Gegenseite zugestellt werden. Archiviert die jeweilige Gegenseite bereits selbst und bestätigt das idealerweise schriftlich, muss dort nichts weiter unternommen werden. Der Gegenüber sendet/empfängt wie (bisher) gewohnt die INVOIC-Nachrichten.
Versand über den bekannten SMTP-Kanal
Rechnungssender und -empfänger müssen keinen separaten Übertragungsweg wie z.B. FTP einrichten, um überhaupt INVOIC-Nachrichten verschicken zu können. Die Rechnung wird als EDIFACT-INVOIC wie gewohnt nur einmal über den etablierten EDI-Weg versandt, zusätzlich zu PRICAT, DESADV etc… Rechnungssteller, die den Service nutzen, müssen somit keine neuen Workflows oder Abzweige z.B. im ERP-System oder im Konverter einrichten.
Bereitstellung in zweitem eGate-Mailkonto für POP3-Abholung
Zusätzlich zum für EDI-Nachrichten genutzten eGate-Account (z.B. 2800001946@egate.pranke.com) erhält jeder Service-Nutzer eine zweite Adresse in Form eines Unter-Accounts (z.B. 2800001946.111@egate.pranke.com). An jene Adresse werden die Archiv-Container = PDF/A3-Dateien gesendet. Egal ob auf Sender- und/oder Empfängerseite: Das Archivsystem ruft diese Adresse des Unter-Accounts regelmäßig über einen normalen POP3-Zugriff ab und erhält so unkompliziert die Daten. Es muss kein FTP-Empfang z.B. auf der Firewall konfiguriert werden. Die normalen EDI-Nachrichten inklusive der INVOIC werden weiterhin über die Haupt-Accounts des Senders an den Empfänger zugestellt, parallel zu PRICAT, DESADV usw.
Abrechnung gewohnt volumenbasiert
Das Gesamtvolumen für die Abrechnung ergibt sich beim Service-Nutzer aus bestehendem Haupt-Account (EDI-Nachrichten) und Archiv-Unteraccount (Archiv-Pakete). Alle Details zu Preisen inklusive Rechenbeispielen finden Sie unter der Frage “Was kostet die Elektronische Rechnung?”
Sorry, this entry is only available in Deutsch.
Sorry, this entry is only available in Deutsch.
Fallstudien im Modehandel
Die vermeintlich Kleinsten zeigen eindrucksvoll, mit welchen durchaus unterschiedlichen Zielen die Elektronische Rechnung eingeführt wurde und wie es sich gelohnt hat:
(Deutsch) Geschickte Prozessverbesserung im Modehandel
e-Invoice, Case Study, Case Study eInvoice(Deutsch) Einführung der Elektronischen Rechnung im Modehandel
e-Invoice, Case Study, Case Study eInvoicePranke Elektronische Rechnung
Sorry, this entry is only available in Deutsch.
Das komprimierte PDF ist zwar immer noch ein gültiges PDF, aber kein PDF/A-3 mehr. Der Kompressionsvorgang komprimiert im wesentlichen die beiden eingebettetet Font-Files (Arial-Bold und Arial) und entfernt dabei auch gleich sämtliche XMP-Metadaten. Die eingebetteten XML-Dateien bleiben erhalten. Damit ist das Ganze weder PDF/A-3 noch ZUGFeRD konform. Ein ZUGFeRD-Extraktror würde deshalb auch dieses File ablehnen, weil keinerlei Identifikation auf ZUGFeRD enthalten ist.
Sorry, this entry is only available in Deutsch.
Ein “einheitliches Rechnungsdatenformat für den elektronischen Rechnungsaustausch”, das in einer PDF/A3-Datei eingebettet die menschenlesbare Rechnung und den dazugehörigen maschinen-lesbaren Datensatz vereint. Das jedoch setzt voraus, dass der Rechnungssender ZUGFeRD-PDFs erstellen kann bzw. der Empfänger diese verarbeiten kann. Es ist gedacht für alle Anwendungsbereiche oder Branchen, in denen EDI nicht etabliert ist, z.B. Verwaltung oder Kleinstbetriebe.
In der Konsumgüter-Branche ist der Standard für den Austausch von strukturierten = maschinen-lesbaren Daten ist seit langem schon EDIFACT, das quasi von jedem “EDI-fähigen” Handelspartner gesendet bzw. empfangen und verarbeitet werden kann.
Pranke bietet die Technologie, um ZUGFeRD in EDIFACT zu konvertieren und/oder umgekehrt aus EDIFACT-Daten das ZUGFeRD-Format zu erstellen, um alle Handelspartner zu bedienen. So ergänzt ZUGFeRD den bewährten EDI-Austausch für die Elektronische Rechnung.
Sorry, this entry is only available in Deutsch.
Auf der Basis von EDI
In einem Umfeld, in dem per EDI schon Stammdaten, Lieferscheine und Bestellungen ausgetauscht werden, liegt er nahe: der papierlose Versand bzw. Empfang von Rechnungen per EDI. Eine (zusätzliche) PDF-Version dieser Rechnung dient nicht Versand oder Austausch, sondern einzig dazu, die Rechnungsdaten für die Archivierung bzw. Prüfung menschenlesbar zu machen.
Aufbereitung & Validierung während des Versands
Über die eGate-Server läuft aller EDI-Datenverkehr der Pranke-Kunden: Hierüber gehen INVOIC-Nachrichten vom Sender zum Empfänger. Weiterhin werden diese INVOIC-Nachrichten nach Versand bzw. vor Empfang zunächst auf Vollständigkeit validiert und dann als „menschenlesbares“, langzeitarchivierbares PDF aufbereitet – inklusive der darin eingebetteten EDIFACT-Originaldatei.
Die Details zur Technik
Ein ZUGFeRD-PDF/A3-Container mit Comfort-Profil-Validierung...
Der erzeugte “Archiv-Container” ist standardmäßig eine PDF/A3-Datei. Diese enthält eingebettet das EDIFACT-INVOIC-Original und weiterhin die Index-Informationen nach dem ZUGFeRD-XML-Datenmodell. PDF/A3 ist der PDF-Standard für die Langzeit-Archivierung (ausführliche Beschreibung bei Wikipedia in neuem Fenster öffnen) und technisch so konzipiert, dass nicht nur Dateien, sondern auch z.B. Schriftarten eingebettet werden. Weiterhin ist ein solches PDF nach der Erstellung standardmäßig schreibgeschützt. All diese Maßnahmen gewährleisten, dass der PDF-Inhalt auch in zehn Jahren wie am ersten Tag aussieht und nicht verändert werden konnte. Die ZUGFeRD-Informationen stellen dabei Index und Nutzdaten zugleich für das archivierende Dokumenten-Management-System dar, welches somit jede Information aus der Rechnung verwenden kann. Damit das Archivsystem nur gültige Rechnungen erhält, wird jedes Dokument bei Pranke gegen die Regeln des ZUGFeRD-Comfort-Profil validiert. Bei unvollständigen Rechnungen wird der Service-Nutzer benachrichtigt, um je nach Fall die Rechnung neu anzufordern bzw. korrigiert zu versenden. Mit jedem gängigen, aktuellen Dokumenten-Management-System (offline oder in der Cloud) erfüllt der Service-Nutzer somit ohne weitere Konfiguration die steuerrechtliche Anforderung, sowohl das Rechnungsoriginal (INVOIC) sowie die dazugehörige menschenlesbare Version revisionssicher zu archivieren.
Pflichtangaben-Prüfung nach § 14 Abs. 4 UStG
Jegliche gültige Rechnung – ob Papier oder elektronisch – muss Pflichtangaben enthalten. Vor der Aufbereitung der Archiv-PDF/A3-Daten werden diese Angaben geprüft. Sollten Angaben fehlen und die Rechnung damit nicht zum Vorsteuerabzug berechtigen, wird diese daher angehalten und der Service-Nutzer per Mail benachrichtigt
Fehlerfall und Benachrichtung
Zusammengefasst: Schlägt die ZUGFeRD-Comfort-Validierung fehl oder fehlen UStG-Pflichtangaben in der INVOIC, wird daraus kein Archiv-Paket erstellt. Der Service-Nutzer erhält eine detaillierte Fehlermeldung mit Angaben zum Dokument und zum Fehler selbst, um daraufhin Kontakt mit dem Handelspartner aufzunehmen. Die INVOIC innerhalb des gewohnten EDI-Nachrichtenstroms an den Empfänger bleibt unbeeinflusst, da diese vor der obigen Validierung & Prüfung abgezweigt wird: Dies entspricht übrigens dem Vorgehen wie beim “Papieroriginal mit INVOIC”, wenn z.B. im Gegensatz zu den EDI-Daten der Brief nicht ankam, oder wenn eine neue Rechnung nach einer manuellen Prüfung nötig wäre.
Entworfen für beide Rechnungs-Beteiligten
Eine Umstellung weg von Papier auf eine elektronische Rechnungsabwicklung ist nur sinnvoll und rechtlich einwandfrei, wenn beide Seiten das jetzt zum Original erhobene EDIFACT-Dokument archivieren. Hat ein Handelspartner des Service-Nutzers selbst noch nicht die Möglichkeit, das EDI-Rechnungsoriginal direkt zu archivieren (oder müsste hierfür erst interne Entwicklung betrieben werden), können die “Archiv-Container” = PDF/A3-DAteien auch jener Gegenseite zugestellt werden. Archiviert die jeweilige Gegenseite bereits selbst und bestätigt das idealerweise schriftlich, muss dort nichts weiter unternommen werden. Der Gegenüber sendet/empfängt wie (bisher) gewohnt die INVOIC-Nachrichten.
Versand über den bekannten SMTP-Kanal
Rechnungssender und -empfänger müssen keinen separaten Übertragungsweg wie z.B. FTP einrichten, um überhaupt INVOIC-Nachrichten verschicken zu können. Die Rechnung wird als EDIFACT-INVOIC wie gewohnt nur einmal über den etablierten EDI-Weg versandt, zusätzlich zu PRICAT, DESADV etc… Rechnungssteller, die den Service nutzen, müssen somit keine neuen Workflows oder Abzweige z.B. im ERP-System oder im Konverter einrichten.
Bereitstellung in zweitem eGate-Mailkonto für POP3-Abholung
Zusätzlich zum für EDI-Nachrichten genutzten eGate-Account (z.B. 2800001946@egate.pranke.com) erhält jeder Service-Nutzer eine zweite Adresse in Form eines Unter-Accounts (z.B. 2800001946.111@egate.pranke.com). An jene Adresse werden die Archiv-Container = PDF/A3-Dateien gesendet. Egal ob auf Sender- und/oder Empfängerseite: Das Archivsystem ruft diese Adresse des Unter-Accounts regelmäßig über einen normalen POP3-Zugriff ab und erhält so unkompliziert die Daten. Es muss kein FTP-Empfang z.B. auf der Firewall konfiguriert werden. Die normalen EDI-Nachrichten inklusive der INVOIC werden weiterhin über die Haupt-Accounts des Senders an den Empfänger zugestellt, parallel zu PRICAT, DESADV usw.
Abrechnung gewohnt volumenbasiert
Das Gesamtvolumen für die Abrechnung ergibt sich beim Service-Nutzer aus bestehendem Haupt-Account (EDI-Nachrichten) und Archiv-Unteraccount (Archiv-Pakete). Alle Details zu Preisen inklusive Rechenbeispielen finden Sie unter der Frage “Was kostet die Elektronische Rechnung?”
Sorry, this entry is only available in Deutsch.
Sorry, this entry is only available in Deutsch.
Fallstudien im Modehandel
Die vermeintlich Kleinsten zeigen eindrucksvoll, mit welchen durchaus unterschiedlichen Zielen die Elektronische Rechnung eingeführt wurde und wie es sich gelohnt hat:
(Deutsch) Geschickte Prozessverbesserung im Modehandel
e-Invoice, Case Study, Case Study eInvoice(Deutsch) Einführung der Elektronischen Rechnung im Modehandel
e-Invoice, Case Study, Case Study eInvoicePranke Elektronische Rechnung
Sorry, this entry is only available in Deutsch.
Wieso EDI die beste Grundlage für Elektronische Rechnungen ist…
jetzt umsteigenWer vom postalischen Versand von Papierrechnungen auf den elektronischen Versand der Abbildungen von Papierrechnungen (= PDF) umsteigt, verlagert lediglich den manuellen Bearbeitungsaufwand, zumindest auf Empfängerseite. Das ist unattraktiv. Zudem muss die Echtheitsprüfung etabliert und dokumentiert werden.
Der Einsatz von EDI-Rechnungen hingegen hat zwei signifikante Vorzüge:
- Rechnungsversand per EDI ist per se elektronisch; die beiden Kriterien Echtheit und Herkunft der Rechnungen (INVOIC), so das Gesetz, sind unbestreitbar.
- Die Rechnungsdaten liegen bereits in strukturierter Form vor und können in normiertem Format auf einem bereits etablierten Weg ohne Medienbruch übertragen und in die verarbeitenden Systeme ebenfalls ohne Medienbruch importiert werden. Letzteres ermöglicht einen schnellen Abgleich mit ohnehin schon digital vorhandenen Bestell- und Lieferdaten – auch hier sogar automatisiert.
einfach lösenDie Pranke-Lösung für den elektronischen Rechnungsaustausch über EDI bietet noch mehr, um alle Bedingungen für die Anerkennung des Vorsteuerabzugs zu erfüllen (außer der inhaltlichen Prüfung, die der Empfänger jedes Mal selbst vornehmen muss, sofern nicht wie oben beschrieben automatisiert):
- Visualisierung der Rechnung durch Erzeugung eines PDF-Dokuments (im für die Langzeitarchivierbarkeit geschaffenen Format PDF/A3)
- Einbettung der Rechnungsdaten im XML-Format gemäß dem ZUGFeRD-Profil Comfort, sodass gängige Archivsysteme die Rechnungen abholen und ohne weitere Konfiguration importieren können
Steuerprüfung relaxedKommt einmal der Finanzprüfer, findet er umgehend das INVOIC-Original mitsamt einer menschenlesbaren Fassung. Damit auch Rechnungsaussteller und -empfänger möglichst wenig vermeidbare Arbeit bei der Prüfung haben, enthält der Pranke-Service noch folgende Elemente:
- Überprüfung der nach §14 UStG erforderlichen Rechnungsfelder auf Vorhandensein
- Validierung der INVOIC gegen das ZUGFeRD-Profil Comfort:
Mitteilung in einem Fehlerfall an den Service-Nutzer, um eine Korrektur der Rechnung zu veranlassen.
Sorry, this entry is only available in Deutsch.
Elektronische Rechnung – Checkliste und Praxistipps, um anzufangen
Da Sie eine bestehende Prozesslandschaft (EDI) nur um eine Funktion (Pranke Elektronische Rechnung) erweitern wollen, liegt die Hürde niedrig. Checken Sie Ihre Infrastruktur gegen die Anforderungen und schaffen Sie die organisatorische Voraussetzung. Unsere Checkliste berücksichtigt technische Kriterien, gesetzliche Anforderungen und gibt erste Praxistipps.
1. Themenbereich: EDI-Nutzung und INVOIC-Nachricht
- INVOIC als EDI-Nachrichtentyp wird schon (parallel zur Papierrechnung) genutzt.Ja: Prima, weiter zum nächsten Punkt.
Nein? Gerne beraten wir Sie hinsichtlich einer Hinzunahme der INVOIC in Ihre EDI-Prozesse. Praxistipp: Wenn DESADV, PRICAT usw. schon eingerichtet sind, ist es erfahrungsgemäß weniger Aufwand als gedacht: Das ERP-/Warenwirtschafts-System und die Schnittstelle müssen in der Regel nur erweitert/konfiguriert und nicht programmiert werden. Im eBiss-Konverter werden bestehende Abläufe prinzipiell mit wenig Aufwand “geklont”.
- INVOIC im D.96A-Format werden gemäß des Pranke-WWS-Profils #17 gesendet bzw. empfangen.
Dieses Profil (siehe Kasten rechts) deckt die Pflichtfelder des §14 Abs. 4 UStG ab.Ja: Somit ist von technischer Seite alles startklar.
Nein bzw. unsicher? Praxistipp: Die Unterschiede zum herkömmlichen INVOIC-Profil sind minimal und primär für die Aufbereitung der Archiv-PDFs wichtig. Häufig werden die zusätzlich notwendigen Felder sowieso schon geschickt. Andernfalls sind die Anpassungen nur geringfügig. Im Profil #17 für elektronische Archivierung (siehe grauer Kasten rechts) sind die Unterschiede farblich gekennzeichnet. INVOIC-Nachrichten, die schon jetzt vom Empfänger (parallel zur Papierrechnung verarbeitet werden, erfüllen diese Voraussetzung fast immer.
2. Themenbereich: Archivierung
- Ein DMS (Document Management System) bzw. Archivsystem zur revisionssicheren Ablage ist vorhanden.
Ja: Prima, weiter zum nächsten Punkt.
Nein? Praxistipp: Ist die Archivierungsfrage noch ungelöst, so sind schnell eingerichtete, kostengünstige Einstiegslösungen nur für Elektronische Rechnungen in der Cloud über einen Partner von Pranke verfügbar. Sprechen Sie uns an! - Dieses DMS/Archivsystem kann Nachrichten (= E-Mails) per POP3 abholen und die Anhänge (= PDF/A3-Dateien) vereinnahmen.
Ja: Prima, weiter zum nächsten Punkt.
Nein? Praxistipp: Der schon vorhandene eBiss-Konverter wird in diesem Fall um einen Mini-Workflow erweitert, um dort per POP3 abzuholen und die PDF/A3-Dateien anschließend in dasjenige Laufwerk/Verzeichnis zu schreiben, von dem das Archivsystem importiert. - Das System kann ZUGFeRD-PDF-Inhalte gemäß ZUGFeRD-Comfort-Profil einlesen (dies wird zur Archiv-Indexierung genutzt).
Ja: Prima, weiter zum nächsten Punkt.
Nein? Praxistipp: Benötigt das Archivierungssystem ein eigenes Index-Format, so kann der eGate-Zusatzdienst dem System die zu archivierenden Daten mit einer Indizierungsdatei im spezifischen Format bereitstellen. In diesem Fall werden EDIFACT-INVOIC (Rechnungsoriginal), PDF und Indexdatei als Mailanhang versandt. Erfahrungsgemäß ist der einmalige Entwicklungsaufwand für die Erstellung des entsprechenden Mappings auf das Archiv-Indexformat gering – fragen Sie danach!
Mehr zum Thema finden Sie unter der Frage “Wie funktioniert die Elektronische Rechnung bei Pranke technisch?”
- Sie haben eine EDI-Vereinbarung mit Ihren Partnern geschlossen.
Ja: Prima, weiter zum nächsten Punkt.
Nein: Praxistipp: Tun Sie das! Zwar reicht schon konkludentes Handeln, indem bereits eine/die erste digital erhaltene Rechnung bezahlt wird, um die Zustimmung zum elektronischen Rechnungsaustausch vom Handelspartner eingeholt zu haben.
Aber: Lassen Sie sich lieber explizit bestätigen, dass auch Ihr Partner die Original-INVOIC-Nachrichten archiviert. Wird beim Sender nur ein PDF archiviert oder beruft man sich darauf, die Daten jederzeit nochmals aus dem ERP exportieren zu können, entspricht dies jeweils nicht dem gesetzlich geforderten Rechnungsoriginal. Ebenso ist ein Ausdruck eines PDFs oder des Bildschirminhalts der INVOIC kein Rechnungsoriginal. Ausschließlich jenes Original muss bei einer finanzamtlichen Prüfung zugänglich gemacht werden. Eine Mustervereinbarung gibt es z.B. auf der Webseite von GS1 Germany (externer Link).
3. Themenbereich: Rechnungsinhalte
Prinzipiell muss eine für den allein elektronischen Austausch vorgesehene Rechnung genau dieselben Bestandteile aufweisen wie jede andere Rechnung auch, also gemäß §14 UstG…
- Rechnungsdatum, Wert
- Tatsächlicher Lieferungszeitpunkt, Wert
- Art der Steuernummer des Verkäufers
- Artikelbezeichnung
- Datum, Format
- Dokumentenart (Freitext)
- Firmierung/Name des Käufers*
- Firmierung/Name des Verkäufers*
- Menge, berechnet
- Rechnungsnummer
- Rechnungssumme ohne USt.
- Steuerprozentsatz
- Währung
… sodass hier kein Handlungsbedarf bestehen sollte.
*Zulässig ist die Nutzung ausschließlich der 13-stelligen GLN, die nur an Unternehmen vergeben wird und ein solches weltweit zweifelsfrei identifiziert.
Praxistipp 1: Mittels der GLN ist die geforderte eindeutige Identifizierung des Namens und der Anschrift beider Seiten möglich, da zu jeder weltweit einmaligen GLN immer eine eindeutige Adresse nachgeschlagen werden kann. Die Eindeutigkeit der Herkunft ist dadurch gegeben.
Praxistipp 2: Achten Sie darauf, dem „Käufer“ (= Rechnungsempfänger) und der ggf. abweichenden Lieferadresse die jeweils richtigen GLNs zuzuordnen. Hieraus entstehen die meisten Nachfragen, wenn z.B. der Lieferant Filial-GLNs fälscherlichweise im Feld der Käufer/Empfänger-GLN nutzt, und so die Identifizierung des Käufers falsch wäre.
Sorry, this entry is only available in Deutsch.
So spielen etablierte Systeme, Technologien und Formate zusammen…
Schematischer Ablauf der Elektronischen Rechnung für Rechnungsempfänger
https://www.youtube.com/watch?v=y4WpxFta1Kg
DOWNLOAD des Schemas als PDF (230kb)
Sorry, this entry is only available in Deutsch.
So spielen etablierte Systeme, Technologien und Formate zusammen…
Schematischer Ablauf der Elektronischen Rechnung für Rechnungssteller
https://www.youtube.com/watch?v=3DJSgBtoSMk
Sorry, this entry is only available in Deutsch.
Was will das Finanzamt?
Anforderungen an (elektronische) Rechnung und Archivierung:
Rund um die Elektronische Rechnung gibt es eine große Unsicherheit, was von Seiten der Behörden gefordert wird. Grundsätzlich unterscheidet man zwischen zwei Fragestellungen:
- Frage A: Welche Faktoren definieren eine (elektronische) Rechnung, die zwischen zwei Geschäftspartnern ausgetauscht wird?
- Frage B: Sofern jene Faktoren zutreffen und eine Rechnung einen Geschäftsvorgang abgeschlossen hat, wie muss man sie (elektronisch) aufbewahren, damit sie später geprüft werden kann?
Zu Frage A:
Seit dem 1. Juli 2011 sind in Deutschland gemäß Steuervereinfachungsgesetz 2011, mit dem die EU-Richtlinie 2010/45/EU umgesetzt wurde, elektronische Rechnungen und klassische Papierrechnungen gleichgestellt, um Geschäftsprozesse einfacher und effizienter zu machen. Für die Praxis heißt das vor allem: Bei Rechnungen innerhalb Deutschlands ist keine elektronische Signatur nötig. Zudem sind gerade beim Austausch über EDI die “Echtheit der Herkunft” sowie die “Unversehrheit” bereits gewährleistet, im Gegensatz zu anderen elektronischen Dateiformaten und Übertragungswegen (siehe Schreiben Seite 6/11).
Rechnungen, die Pranke-Kunden somit als EDI-INVOIC austauschen (sofern alle Pflichtangaben enthalten sind – es gelten die gleichen wie auf Papier), sind somit gerade aufgrund des EDI-Verfahrens direkt vorsteuerabzugsberechtigt.
Zu Frage B:
Ist die Rechnung bezahlt, muss sie archiviert werden, denn: Im Fall einer Umsatzsteuernachschau kann der Prüfer Einsicht in Rechnungen verlangen, deren Ausstellung bis zu zehn, elf oder gar zwölf Jahre zurück liegt. Es gilt in diesem Fall nicht nur, dem Prüfer angefragte Rechnungen ohne Weiteres vorlegen zu können, sondern auch nachzuweisen:
- dass diese nach einem dokumentierten Prozess archiviert wurden (§ 147 Abgabenordnung (AO) und GoBD)
Die vorgelegte Rechnung möchte der Prüfer auch nach diesen vielen Jahren noch
- lesen können…
…und sichergehen können, dass es sich
- um echte Rechnungen („Original“)
- mit seit Ausstellung unverändertem Inhalt handelt.
Jede Rechnung muss
Zu guter letzt muss eine elektronisch empfangene Rechnung
- elektronisch archviert werden: Ein Ausdruck auf Papier stellt nicht mehr das Original dar. Das gilt auch Rechnungen, die nur als PDF ausgetauscht werden.
- (Umgekehrt darf unter bestimmten Voraussetzungen eine Papierrechnung gescannt, digital archiviert und das Papier entsorgt werden)
ALLE diese Voraussetzungen sind mit dem Pranke-Zusatzdienst Elektronische Rechnungen erfüllt:
- Pranke-Kunden senden oder empfangen EDI-Rechnungen, die per se zum Vorsteuerabzug berechtigen…
- …und archivieren dieses Original in von Pranke daraus aufbereiteten, langzeitarchivierbaren PDF/A3-Dateien in ihrer DMS-/Archivsoftware, die vor ihrer Erstellung auf inhaltliche Vollständigkeit geprüft wurden.
- Die technische Konfiguration der Vorgänge innerhalb dieser Software von Abholen bis Ablage ist im Mindesten die Basis der geforderten Prozessdokumentation.
Sorry, this entry is only available in Deutsch.
Vorteile die Pranke-Kunden nennen…
Warum sollte man die Elektronische Rechnung einführen? Mehr als 70% aller kleinen, mittleren und großen Unternehmen, die Rechnungen elektronisch bearbeiten, sehen die größten Vorteile in den Ersparnissen bei Porto und Materialkosten sowie in der deutlich schnelleren Bearbeitung und Bezahlung aller Rechnungen (Quelle: Whitepaper Elektronische Rechnungsbearbeitung, yambs.eu)
Das ist aber nicht nur schöne Theorie. Diverse Pranke-Kunden, die schon länger die Elektronische Rechnung nutzen, berichten von teils massiven Prozess-Verbesserungen, 100%iger Transpararenz und Geschwindigkeits-Gewinnen (siehe hierzu auch die Fallstudien):
Ersparnis von Zeit, Versand- und Personalkosten
Der langwierige papierbasierte Rechnungsprozess, vom Druck bis zum postalischen Versand, entfällt ganz. Personal, das bisher mit der Rechnungsstellung betraut war, kann andere, betriebswirtschaftlich wichtigere Tätigkeiten übernehmen. Das Unternehmen kann sich wieder auf sein Kerngeschäft konzentrieren und braucht keine Ressourcen für aufwändige Supportprozesse, wie die Rechnungslegung, aufzuwenden. Der Empfänger wiederum spart sich die manuelle Bearbeitung der erhaltenen Rechnung, da die Rechnungsdaten automatisch in das ERP/FIBU-System fließen können.
Schnellerer Bezahlprozess durch schnellere Durchlaufzeiten.
Die Zahlungsfristen bei Rechnungen beginnen üblicherweise mit Erhalt der Rechnung zu laufen. Eine elektronisch versendete Rechnung ist sofort beim Empfänger verfügbar. Frühere und (hoffentlich) fristgerechte Zahlungen sind die Folge.
Reduktion von Eingabefehlern
Durch die durchgehende Automatisierung des Rechnungsprozesses und den Wegfall von manuellen Interventionen reduzieren sich Eingabefehler auf ein Minimum.
Vereinfachung der Archivierung
Gemäß den gesetzlichen Vorschriften müssen Unternehmen Rechnungen für zukünftige Prüfungen durch die Finanzbehörden aufbewahren. In Deutschland sind es mindestens 10 Jahre, in der Praxis auch mal zwölf. Papierrechnungen eignen sich für langfristige Aufbewahrung generell nur schlecht. Ein Brand oder ein Wasserschaden im Archiv hat potentiell den Verlust der archivierten Rechnungen zur Folge. Und dann kann es für das Unternehmen sehr teuer werden – die Finanzbehörden beginnen typischerweise zu schätzen – zumeist nicht zum Vorteil des Unternehmens.
Bei einer elektronischen Rechnungsübermittlung liegen die Rechnungsdaten bereits in elektronischer Form vor und können so sehr einfach in ein elektronisches Archivierungssystem eingebunden und gesichert werden. Zudem gewinnt man regalmeterweise Platz: Das komplette Jahresarchiv passt künftig auf einen USB-Stick.