ZUGFeRD: Standard für die elektronische Rechnung

ZUGFeRD elektronische Rechnung

ZUGFeRD ist die Abkürzung für „Zentraler User Guide des Forums elektronische Rechnung Deutschland“. Die gewollte Analogie zum "Zugpferd" soll deutlich machen, dass das neue elektronische Rechnungsformat die elektronische Rechnung zügig voranbringen soll. Herausgegeben wurde ZUGFeRD vom Verband "„Forum elektronische Rechnung Deutschland" (FeRD) im Dezember 2012. 

FeRD (http://www.ferd-net.de) hat sich für ZUGFeRD "Faktura Base" der Unterstützung der Ministerien, von Minister Rösler und auf der CeBIT von Bundeskanzlerin Merkel versichert. Es ist der logische Schritt nach der Abschafung der qualifizierten elektronsichen Signatur für die elektronische Rechnung jetzt auf ein automatisch verarbeitbares Format zu setzen, dass allen Größenordnungen von Unternehmen und Verwaltungen gleichermaßen offen zugänglich ist.
ZUGFeRD ist ein XML-basiertes Format (http://bit.ly/ZUGFeRD), das vergleichbar EDI den Austausch und die automatische Verarbeitung von strukturierten Rechnungsdaten ermöglicht. Anders als bei EDI ist kein besonderes technisches Übermittlungsverfahren (wie z.B. X.400) und keine vorherige vertragliche Vereinbarung zwischen Absender und Empfänger der Rechnung notwendig. Eine Zustellung von ZUGFeRD-Rechnungen ist auch zulässig, wenn der Empfänger dem nicht widerspricht (siehe auch die Diskussion auf XING "Elektronische Rechnung mit ZUGFeRD ohne Zustimmung des Empfängers nutzbar?" http://bit.ly/12IShq2). 
Auch eine Reihe von ECM-Anbietern setzt sich mit ZUGFeRD auseinander. Hier geht es zum Beispiel um das Einbetten der XML-Daten in PDF/A-Dokumente. Die Zukunft sollte allerdings eher so aussehen, dass Finanzbuchhaltungs- und ERP-Systeme automatisch Dokumente mit diesem Format erzeugen und beim Empfänger ebenso automatisch wieder einlesen. Wie die Daten dazwischen transportiert werden, ist eher nebensächlich. Jedoch kann bei der Aufbewahrung entsprechung Handelsrecht und Steuergesetzen das Format eine wichtige Rolle spielen, wenn es um die erneute Nutzung und Verarbeitungsfähigkeit der Rechnungsdaten geht. Auch hierzu gibt es eine Diskussion, in wieweit zum Beispiel das neue PDF/A-3-Format als Archivierungs-Container von Bedeutung sein kann, in unserem Diskussionsforum auf XING "PDF/A-3 als Container für ZUGFeRD bei elektronischen Rechnungen?" http://bit.ly/16Mj7Qs.
In unserem EIM Update Januar 2013 haben wir die Spezifikation in der Version 0.5 auf den Seiten 30 bis 36 der PDF-Dokumentation besprochen: http://bit.ly/PCHH_EIM2013

Kommentare

Corrigendum zum ZUGFeRD Format Version 1.0

Die finale Version des ZUGFeRD Formats wurde im Oktober 2014 durch ein Corrigendum angepasst. Dieses beinhaltet Korrekturen zur Darstellung der Rechnungssummen, den Beispieldateien und eine Aktualisierung der Schemadateien.

Die nachfolgende Tabelle enthält alle aktuellen relevanten Dokumente zum Download.

Spezifikation ZUGFeRD 1.0 ZUGFeRD Spezifikation 1.0
Hinweise zu Änderungen von Version ReleaseCandidate (RC) zu ZUGFeRD 1.0 ZUGFeRD Änderungshistorie Release Candidate
Corrigendum mit Korrekturen vom 17.10.2014 ZUGFeRD Corrigendum
Betriebswirtschaftliche Begriffe, Datenmodell und Schemas ZUGFeRD Technische Dokumentation
Codelisten ZUGFeRD Codelisten
12 Beispieldateien ZUGFeRD Beispiele
Schema- und Stylesheetdateien ZUGFeRD Schema- und Stylesheet-Dateien

Alles Weitere auf http://www.ferd-net.de/

ZUGFeRD Spezifikation in Englisch

Mit der englischen Version von ZUGFeRD 1.0 kommt kann sich die deutsche Variante der elektronischen Rechnung endlich auch auf dem internationalen Parkett sehen lassen. Nur so hat man die Chance, aus der Ecke der "deutschen Sonderlocken" herauszukommen: http://bit.ly/ZUGFeRD-EN
Download:
Information der AWV/FeRD:
In order to enable small and medium-sized enterprises to benefit from the advantages of e-invoicing, the German Forum on electronic Invoicing (FeRD) has developed a uniform data format called ZUGFeRD, the "Central User Guide of the Forum for Electronic Invoicing in Germany" which is freely available to all interested companies and organisations since 25th June 2014.
Providing invoice data digitally has fundamental benefits for both the business sector and public administration: quicker and more efficient work processes, fewer late payments as well as lower printing and postage costs. This in turn reduces errors and improves transparency, while the procedural steps involved in processing invoices are made quicker overall.
ZUGFeRD 1.0 is designed to achieve these objectives, most notably for those parties which only issue a small number of invoices to one partner each year or for parties which sometimes or even exclusively deal with partners without a regular business relationship. To achieve this aim, electronic invoices should be just as easy to send and receive as paper invoices. Therefore, ZUGFeRD 1.0 combines structured XML data and PDF/A as visualization to a hybrid electronic invoice. Both the structured XML file and the PDF visualization represent the complete invoice, and the receiver can choose what he processes, be it XML, PDF or both. Eventually this means that it is possible to exchange structured invoices without any prior consultation or agreement between the involved parties and without any agreement on the transmission itself.
The objective that ZUGFeRD 1.0 can be used on an international scale is a key aspect: ZUGFeRD 1.0 can be used in non-German-speaking countries – both in Europe and beyond.  ZUGFeRD 1.0 is based on the regulations of the Cross Industry Invoice (CII) standard developed by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) as well as on the European Committee for Standardization’s (CEN) Message User Guides (MUG) for a core invoice, for which the CII serves as a basis. This means that the foundation for establishing ZUGFeRD as a uniform European format has already been laid.

BMI Leitfaden Elektronische Rechnung

Passend zum Thema ZUGFeRD veröffentlichte das BMI Im Rahmen des Zukunftskongresses 2014 die neuen Leitlinien zu e-Rechnung in der öffentlichen Verwaltung. Es ist ein Leitfaden, keine bindende Richtlinie oder Verordnung. Der „Leitfaden Elektronische Rechnung in der Öffentlichen Verwaltung – Grundlagen, Umsetzungsempfehlungen, Best Practices“ richtet sich an Verwaltungen aller föderalen Ebenen. Es beschreibt sich selbst als "ein umfassendes Kompendium zum Einsatz der elektronischen Rechnung im öffentlichen Auftragswesen." Den Leitfaden gibt es hier im Download.
Was steht drin und was heißt dies? Der Leitfaden beinhaltet in Gestalt einzelner Artikel Grundsätzliches zur E-Rechnung, Verfahren wie ZUGFeRD, rechtliche Fragen und Best-Practice-Beispiele. Eine Handreichung an der auch Initiativen für den Mittelstand mitwirkten. Eine Stringenz wie in Österreich, wo bei Bundesverwaltungen nur noch elktronische Rechnungen angenommen werden, fehlt.
Hintergrund für den Leitfaden ist die europäische Richtlinie für elektronische Rechnungen.
 
Inhaltsverzeichnis

  • Vorwort: Der elektronische Rechnungsaustausch mit der Verwaltung – Meilenstein des E-Governments in Deutschland und Europa
  • Die Richtlinie über die elektronische Rechnungsstellung bei öffentlichen Aufträgen
  • Warum eRechnung? Ökonomische und ökologische Einsparpotenziale in der öffentlichen Verwaltung
  • Haushaltsrechtliche Rahmenbedingungen für die elektronische Rechnung
  • Datenschutz und Sicherheit bei der elektronischen Rechnung
  • Lieferanten plädieren für die einfache Lösung: Die elektronische Rechnung per E-Mail
  • „ZUGFeRD“ – Einführung und Aufbau des Formats für strukturierten elektronischen Rechnungsaustausch
  • Anpassung der Geschäftsprozesse für die eRechnung
  • Technisches Hilfswerk: Elektronischer Rechnungsempfang ganzheitlich und technologieneutral
    • Elektronischer Rechnungseingang beim Bundesverwaltungsamt (BVA)
    • Elektronische Rechnung bei der Hansestadt Herford
  • Welche Lösung für meine Behörde? Kochrezepte für die Einführung der eRechnung

 
Es wird für einfache Lösungen plädiert, E-Mail ins Spiel gebracht, Und natürlich auch ausführlich ZUGFeRD. Hier wird auch darauf hingewiesen, dass der Grundstein für die eurpäische Anerkennung von ZUGFeRD bereits gelegt sei und es eine entsprechende Empfehlung gibt. Dies gilt aber offenbar nur für das XML-Datenformat. Gilt es auch für das zusätzliche Dokument und alles zusammen in ein PDF/A-3 eingebettet. Das internatioanle Rechnungsformat ist nur eine Option in ZUGFeRD. Genauso wie ZUGFeRD auch nur eine Option für elektronische Rechnungen ist. Genaugenommen ist dieses spezielle "Einpacken", das zusätzliche lesbare Dokument die Sonderlocke neben dem XML-Format, das durchaus Chancen einer europaweiten Standardisierung und Nutzbarkeit hätte. Beim der elektronischen Beschaffungsprozess erscheint denn das ZUGFeRD-PDF/A als Anhängsel des Pfeils im Eingabeprozess. In anderen Grafiken erscheint ZUGFeRD erst nach dem Eingang beim Rechnungsempfänger THW. Hier sollen durch Konverter aus einer e-Mail-Rechnung oder einer E-Mail mit einer PDF-Rechnung erst ZUGFeRD-Container für die weitere Verarbeitung gebildet werden. Sinnvoll? Immerhin zeigt das Beispiel, dass auch Rechnungen in anderen Formatern als ZUGFeRD in Empfang genommen werden (müssen) (können) (sollen). Beim BVA kommen neben ZUGFeRD-Rechnungen auch noch Fax und Papier an, wie bei den Meisten in den nächsten Jahren. Interessant ist, dass auch das PDF in einem ZUGFeRD-Container über OCR in Daten gewandelt wird - gab es da nicht irgendwo im Container die ZUGFeRD-XML-Datei? Und wenn man sich die Verarbeitungsschritte ansieht, was wäre dann die originäre Rechnung, die man in der freien Wirtschaft dem Steuerprüfer auswertbar nach GDPdU/GoBD vorlegen muss? Doch nicht die PDF des lesbaren Dokumentes, doch wohl die XML?! Im Beispiel Herford sieht man neben ZUGFeRD zumindest auch noch Fornate wie XML, EDIFACT, CSV, Idoc und andere. Immerhin gibt es eine Reihe von Beispielen aus anderen Ländern, wo anders mit elektronischen Rechnungen umgegangen wird. Es muss sich so erst noch zeigen, ob ZUGFeRD wieder eine rein deutsche Lösung bleibt oder auch international sich durchsetzen kann - d.h. ZUGFeRD inkl. Dokument im PDF/A-3-Container! Der betreffende Abschnitt mit den Beispielen nennt sich übrigens "technologieneutral".
Immerhin steht klar drin, dass man keine elektronische Signatur bei e-Rechnungen braucht. Aber es wird in einer Fußnote erwähnt, dass man natürlich dennoch elektronische Signaturen verwenden kann, und dann ein Stückchen weiter wird natürlich die qualifizierte elektronische Signatur mit Anbieterakkreditierung im Text als Möglichkeit zur Sicherung der Authentizität und Integrität der Rechnung dargestellt. So zieht sich immer wieder die Signatur noch mehrfach durch das Dokument. Ach, war da nicht noch etwas mit Signieren  beim Scannen nach TR-03138. Brauche ich die Signatur, wenn ich Rechnungen scanne und anschließend das Papierdokument vernichte? Ach lassen wir das.
Bleibt noch die Frage nach De-Mail. Ja - De-Mail kommt vor. Als sichere Alternative für E-Mail, da sowohl "die Identität der Kommunikationspartner als auch der Versand und der Eingang von De-Mails jederzeit zweifelsfrei nachgewiesen werden" können. Auch hier kein Kommentar zu Sicherheit, Nutzungsmodell und Verbreitung, außer dass manche Leute die Idee haben, alle De-Mails (mit der Signatur des Providers sic) in ein TR-ESOR-Archiv nach BSI TR 03125 - nebst Nachsignieren - zu packen. Die optimal sichere Rechnung wäre dann also ZUGFeRD-XML + PDF-Dokument (QES signiert) in PDF/A-3-Container (QES signiert) per De-Mail und anschließend in ein BSI-TR-ESOR-Archiv abgelegt. Unter Wirtschaftlichkeitsgesichtspunkten wird es soweit wohl nicht kommen. 
Download der Leitlinie: bit.ly/BMI_E_Rechnung

ZUGFeRD Version 1.0

Nun soll es losgehen. ZUGFeRD liegt seit 25.06.2014 in der finalen Version 1.0 vor. Allerdings macht die AWV den Download nicht einfach. Hier http://bit.ly/ZUGFeRD1null kommt man auf die Seite, wo man sich das Info-Paket mit der Spezifikation ZUGFeRD 1.0, den Hinweisen zu Änderungen von Version ReleaseCandidate (RC) zu ZUGFeRD 1.0, den Betriebswirtschaftlichen Begriffen, dem Datenmodell und Schemas, den Codelisten, 12 Beispieldateien sowie Schema- und Stylesheetdateien herunterladen kann. Grund ist nicht etwa, die Verbreitung zu verhindern sondern den Disclaimer mit den Haftungsausschlüssen durchzusetzen. :)
Trotzdem, wir bleiben bei der Position, dass das Verpacken in einen Container mit XML-Rechnung + PDF-Rechnung einen unnötigen Overhead beim Generieren, Auspacken und Verarbeiten der ZUGFeRD-Dateien darstellt. Erst wenn die großen ERP-Anbeiter automatisch das Erstellen und EInlesen nebst automatischem Verabreiten standardmäßig unterstützen, erst dann hat dieser wiederum deutschlandspezifische Weg eine Chance.

ZUGFeRD: XML, Dokument + PDF/A-3

Noch immer stellt sich mir die Frage, warum müssen wir die XML-Dateien mit einem "lesbaren Dokument" in ein PDF/A-3 einpacken. Ohne dem ginge automatische Erzeugung, Einlesen und Verarbeiten einfacher. Meine lange Liste von Einwürfen ist natürlich unbeantwortet geblieben: ZUGFeRD Standard für die elektronische Rechnung in Deutschland :)
Das Hauptdokument zur aktuellen Version ZUGFeRD 1.0 finden Sie hier: ZUGFeRD-Format_1p0.pdf, die komplette Dokumentation in dieser ZIP: zugferd10.zip

Deutsche-Nationale Sonderbehandlung?

Seh ich das richtig, dass ZUGFeRD wieder eine nationale Sonderlocke ist, die nicht mal mit 8unseren österreichischen Nachbarn kompatibel ist geschweige denn, mit anderen modernen EU-Ländern wie UK oder gar kapitalistischen Ländern wie USA?
Dann wäre das Risiko sehr hoch, dass es bedeutungslos bleibt wie Qualsig, De-Mail, eID und die anderen nationalen Sonderbehandlungen der deutschen Bürger.

ZUGFeRD = Deutsche Sonderlocke? JA

@ Wolfgang Ksoll | Lieber Kollege Ksoll, Sie sehen dies richtig. Auch ZUGFeRD ist eine deutsche Sonderlocke - einmal durch die Spezifikation der XML (die allerdings auch um ein internationales Profil ergänzt wurde) sowie durch das Einpacken und Entpacken als PDF/A-3. Dahinter steht die Annahme, dass die XML-Datei nicht "mit menschlichem Auge les- und interpretierbar" sei und daher eine "Druck-/Leseversion" notwendig erscheine. In anderen Ländern existiert diese altertümliche Ansicht nicht. Anstelle automatisch erstellter und automatisch verarbeiteter elektronischer Rechnungen (à la EDI) in XML wird in Deutschland wieder eine recht komplexe Lösung erdacht, die zumindest von den ECM-Anbietern begierig aufgegriffen wurde (da hier ein neues Feld für neue spezielle Anwendungen entsteht, die im Übrigen nicht mehr viel mit ECM zu tun haben). Wie bei anderen Lösungen, werden so auch internationale Anbieter vom deutschen Markt der Sonderlocken ferngehalten. Man versucht inzwischen ZUGFeRD auch anderen Nationen iN Europa nahezubringen, aber zunächst ist und bleibt ZUGFeRD eine auf Deutschland beschränkte und auch von offizieller Seite nur mäßig unterstützte Initiative. ZUGFeRD reiht sich so ein in die Welt der qualifizierten elektronischen Signatur, des Nachsignierens, der De-Mail, der eID, des Signierens beim Scannen, der Gesundsheitskarte usw. usw.
Ulrich Kampffmeyer

Open Source ZUGFeRD

Es gibt zwei Open Source Bibliotheken die sich mit ZUGFeRD beschäftigen.

http://konik.io/
http://mustangproject.org/

ZUGFeRD & die neue EU Richtlinie

Die Europäische Kommission hat am 16.April 2014 die Richtlinie "elektronische Rechnungsstellung bei öffentlichen Aufträgen" (2014/55/EU) des  Europäischen Parlamentes und des Rates veröffentlicht “: http://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:JOL_2014_133_R_0001; Download in Deutsch http://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32014L0055&from=DE.
Darin werden einheitliche Regelungen für die Einreichung von Rechnungen in elektronischer Form zumindest für die öffentliche Verwaltung definiert, wie sie z.B. in Österreich bereits im Einsatz sind. In Deutschland nehmen dies Branchenverbände zum Anlass, ZUGFeRD als den geeigneten Standard für solche Rechnungen zu propagieren. In Österreich werden dagegen Rechnungen direkt verarbeitungsfähig in XML eingereicht ohne dass es des Umschlages PDF/A-3 und eines mit direkt mit dem menschlichen Auge lesbaren und interpretierbaren Dokumentes bedarf.  Auch in England gilt, dass z.B. formalisierte XML-Dateien durchaus vom Menschen les- und interpretierbar sind.
Der BITKOM hat eine zusammenfassende Darstellung von ZUGFeRD veröffentlicht: http://www.bitkom.org/files/documents/140505_Broschuere_ZUGFeRD_web.pdf
Noch bis 06.06.2014 können Kommentare zur Definition von ZUGFeRD eingereicht werden: http://www.ferd-net.de/front_content.php?idcat=231 . Den aktuellen Releasestand gibt es hier: http://www.ferd-net.de/front_content.php?idcat=255

 

Nationaler Alleingang statt europäischer Harmonisierung?

Was heisst es denn nun konkret, dass deutsche Gremien an einer nationalen Sonderbehandlung basteln? Soll wieder das europäische Geschäft behindert werden wie schon mit der qualifizierten Signatur die EU-Dienstleistungsrichtlinie im Artikel 8 vorsätzlich boykottiert wurde? Was steckt dahinter, dass der BITKOM Werbung für europäisch nicht kompatible Lösungen macht?
Bei den Signaturen, wo sich Deutschland technologisch ins Abseits gedrängt hat, zeichnet sich nach 15 Jahren nationalem, weitgehend sinnlosen Signaturgesetz ab, das die EU damit europaweit aufräumen wird. Soll man den ZUGFeRD-Aspiranten daher raten, dass sie erst mal weiter auf Papier-Rechnungen austauschen, bevor sie wie bei den Signaturen sinnlos Geld verschwenden für verfehlte Marktinterventionen des Staates? Seit Jahren kann man rechtskräftig mit ordinärer E-Mail Rechnungen aus Word mit eingescannter Unterschrift versende. Das ist nicht schön für eine maschinelle Bearbeitung, aber wesentlich billiger als eine kleinräumige, nationale Lösung. Maschinell mit EDI kann man aber seit Jahrzehnten Rechnungen übermitteln. In den 1990ern hat das US-Verteidigungsministerium für alle Lieferanten elektronische Rechnungsstellung gefordert. Für kleine Unternehmen wie Pizza-Bäcker zum Catering hat man dann Web-EDI zur Verfügung gestellt. Und 20 Jahre später basteln wir in Deutschland an einer nationalen, proprietären Lösung?

ZUGFeRD Release Candidate "Extended"

Der ZUGFeRD Release Candidate "Extended"  soll in einer 6-wöchigen Review-Phase überprüft weden. Die relevanten Dokumente gibt es Infopaket „Extended“: http://www.ferd-net.de/front_content.php?idcat=231&lang=3 Das Infopaket enthält das Datenmodell und das Schema als Strukturdiagramm, eine alphabetische Liste der Elemente sowie die von ZUGFeRD definierten Codelisten. Darüber hinaus wird eine Gegenüberstellung (Mapping) zwischen dem im Juni 2013 veröffentlichten Release Candidate und der neuen Version Release Candidate Extended sowie eine Aufstellung der neuen Elemente als ZIP-Datei zur Verfügung gestellt.
Kommentare, Tipps und Anregungen zum ZUGFeRD-Release Candidate „Extended" können bis spätestens 6. Juni 2014 per E-Mail mit dem Betreff "Review ZUGFeRD-Release Candidate Extended" an die Adresse zugferd@ferd-net.de eingereicht werden.
Die Veröffentlichung der finalen Version 1.0 des ZUGFeRD-Formats erfolgt im Anschluss an die Review-Phase am 25. Juni 2014.
 
P.S.
Dass es mit ZUGFeRD doch nicht so ganz einfach ist, zeigt auch die Diskussion, ob man dem Empfang von elektronischen ZUGFeRD-Rechnungen im Vorwege zustimmen muss: http://bit.ly/zugFeRD

ZUGFeRD Wunschliste 2014

ZUGFeRD hat nur dann eine Chance, wenn es schnell und auf breiter Front umgesetzt wird. Hier meine Wunschliste für ZUGFeRD 2014:
a) Mehr Unterstützung, mehr Geld von offizieller Seite (nicht nur aus einem Ministerium und nicht nur über die AWV ... :-) )
b) Nutzung von ZUGFeRD-XML auch ohne PDF/A-3 (direkt Export / Import durch kaufmännische Software)
c) ZUGFeRD-Profil auch als Auswertungsergebnis (Ausgabeformat des Scan-/OCR/ICR-Prozesses zur Weiterverarbeitung) bei gescannten Rechnungsdokumenten
d) ZUGFeRD auch als EDI-/EDIFACT-Profil (um Kompatibilität zur erreichen)
e) ZUGFeRD als standardmäßiges Ausgabe- und als Eingabe-Format bei  den weitverbreiteten ERP (SAP, Navision, Lexmark,  Oracle Financials ...)
f) Durchsetzung ZUGFeRD (mit/ohne PDF/A-3 !) auf europäischer Ebene (möglichst als Directive :-) )
g) Effiziente Unterstützung von ZUGFeRD bei OECD und internationalen Standardisierungsgremien (damit wir aus der proprietären "nationalen Ecke" rauskommen)
h) Ab 2015 bei allen Bundesbehörden nur noch Rechnungen anerkennen und begleichen, die im ZUGFeRD-Format kommen (wie in Österreich)
i) ZUGFeRD-Viewer-Plugin für alle gängigen Internet-Browser (Chrome, Firefox, IE u.a.) als Alternative zu PDF/A-3
j) ZUGFeRD-Viewer-Plugin für Outlook als Alternative zu PDF/A-3
k) ZUGFeRD-Viewer-Plugin für Explorer (Filesystem) als Alternative zu PDF/A-3
l) explizit und bindend zu verankern: Kein Signieren/Nachsignieren von Rechnungen (weder ZUGFeRD noch gescannte Rechnungen; auch nicht in Bayern und auch nicht im Sozial-/Health-Sektor; kein höherer Beweiswert)
m) explizit und bindend zu verankern: Keine Notwendigkeit, Rechnungen per De-Mail zu senden (kein höherer Beweiswert)
n) Änderungen der Aufbewahrungsfristen als Anreiz für die Nutzung von ZUGFeRD: elektronische Rechnungen im ZUGFeRD-Format zukünftig Aufbewahrungsfrist 7 Jahre, Papier-Rechnungen 15 Jahre
o) Klärung der Verbindlichkeit: XML-Datensatz ist die originale Rechnung; das Abbild (Viewer/PDF/Ausdruck) ist nur die Kopie
p) Bereitstellung von Mitteln/eines Fonds,  um Anbieter die c), d), e), i), j) und/oder k) umsetzen, finanziell zu unterstützen und einen Teil der Entwicklungskosten zu übernehmen
q) Bereitstellung elektronischer Rechnungen im Handel im ZUGFeRD-Format bei Einkäufen vor Ort (z.B. Übertragung in eine App; siehe z.B. Netto, Lidl, Saturn ...)
r) Bereitstellung elektronischer Rechnungen im Online-Handel im ZUGFeRD-Format bei Einkäufen Internet (Amazon, Ebay ...)
s) Mehr Personal im "BMWE" Ministerium (BMWi) zu diesem Thema, um Breite und Durchschlagskraft der Initiative zu erhöhen

Fragen und Antworten zu ZUGFeRD

Zum aktuellen Stand von ZUGFeRD (Infopaket mit Release Candidate von ZUGFerD, XML-Format und Datenmodell: http://bit.ly/ZugFerd)  ist ein FaQ erschienen: http://bit.ly/FaQ-ZUGFeRD. Der Fragen-und-Antworten beschreibt die Verfahren, wie ZUGFeRD als genutzt werden kann.
Bei ZUGFeRD spielt dabei die Idee, dass man weiterhin ein "lesbares Rechnungsdokument" benötigt eine wichtige Rolle. Als Transport-Medium wird daher für die Kombination von Rechnungsdokument und XML-Datensatz PDF/A3 vorgesehen. In Österreich ist man schon weiter. Hier werden bei Rechnungen in der öffentlichen Verwaltung ab 1.1.2014 nur direkt XML-Datensätze angenommen.

ZugFeRD Musterrechnung nicht konform zum Handelsrecht

Die ZugFeRD Musterrechnung entspricht in der bereitgestellten Form nicht den in Deutschland gültigen Formvorschriften des Handels- und Steuerrechts.

Einige Beispiele:
- Die Angabe des Leistungszeitraumes ist nicht ausdrücklich vorgesehen. Dieser ist bei Dienstleistungen erforderlich, wenn nicht nur eine Lieferung an einem Tag erfolgt.
- Der Ausweis der Umsatzsteuer in erhaltenen Zahlungen ist nicht ausdrücklich vorgesehen. Dies ist gerade bei Abschlagsrechnungen in der Bauwirtschaft zwingend erforderlich.

Eine weitere Prüfung wäre sicher angebracht.

Viele Grüße
Peter Rösch

ZUGFeRD Release Candidate

Am 6.6.2013 wurde der überarbeitende Entwurf von ZUGFeRD als Standard für elektronische Rechnungen als Release Candidate vorgestellt. Das komplette Info-Paket mit Release-Candidate, steuerrechtlichen Überlegungen, Musterbeispiel etc. gibt es hier:
Download: http://bit.ly/ZUGFeRD-Info
Passend dazu gibt es einen neuen Flyer über die Ziele von FeRD und die Beteiligten:
Download: http://bit.ly/FeRD-Flyer
Und eine Empfehlung für PDF/A-3 als Träger/Transport-Format (wenn es denn so sein soll). Die Frage ZUGFeRD ohne "Dokumentcharakter" als XML-Datensatz zu transportieren, scheint wenig sexy. Immerhin gibt es hierzu jetzt auch einen kleinen Führer der PDF-Kompetenz-Centers.
Download: http://bit.ly/PDFA3-ZUGFeRD
Der Release-Candidate als PDF: 
Download: http://bit.ly/ZUGFeRD-RC

Überlegungen und Diskussionen zu ZUGFeRD

ZUGFeRD wird aktuell in verschiedenen Zusammenhängen diskutiert (XING http://bit.ly/XIDM-ZUGFeRDhttp://bit.ly/XING-PDFA3, http://bit.ly/16Mj7Qs, http://bit.ly/XIDM-PDFA3, http://bit.ly/12IShq2) .
Da ist zunächst einmal die strategische Frage, für welchen Zweck soll ZUGFeRD eingesetzt werden. Meines Erachtens ist die Zielgruppe von ZUGFeRD die Anbieter von ERP- und Fibu-Systemen. Es geht darum, in Systemen automatisch standardisierte Rechnungen zu erstellen (analog zu EDI), "irgendwie" zu versenden (E-Mail,, Upload in Portale, oder ähnlich) und automatisch einzulesen und zu verarbeiten. So entsteht der größte Nutzen - ein automatischer Prozess. Ähnliches tun wir ja bereits beim Empfang von elektronischen Rechnungen und beim Scannen von Papierrechnungen (OCRn, Auswerten, Abgleichen, Buchen). PDF und andere Formate sind eher hinderlich für eine automatische Verarbeitung. Primäre Zielgruppe sind also die ERP/FiBu-Anbieter (http://bit.ly/PC-ZUGFeRD).
Zweite Zielgruppe könnten die Anbieter von Archivsystemen sein, die diese elektronischen Rechnungen auswertbar über die Aufbewahrungsfristen (sollen verkürzt werden!) und gemäß den GoBD (kommt im Sommer http://bit.ly/PC-GoBD) und verarbeitungsfähig aufbewahrt werden müssen. Die GoBD sieht übrigens vor, dass Anzeigekopie und Originalformat unter gleichem Index zu verwalten sind. Für die Archivierung muss die DTD/Schema/Styklesheet-Datei mit archiviert werden, da es (zur Zeit) noch keinen Webserver gibt, wo man sich dauerhaft und über alle Versionen getreu die richtige Spezifikation runterladen kann. Gäbe es das (z.B. beim Finanzamt wie das IDEA-Format) dann braucht man DTD/Schema/Stylesheet nicht mit zu archivieren.
Und dann ist da noch die Frage der Lesbarkeit mit dem menschlichen Auge. Hier gibt es verschiedene Varianten. Einen Viewer einsetzen, der die XML-Rechnung mit der richtigen, dazugehörigen DTD/Schema lesbar (und reproduzierbar) anzeigt. Oder wie die "PDF-Fraktion" das plant, die XML in die Zusatzinformationen im PDF-Objekt zu packen und die lesbare Textversion als PDF-Dokument zu generieren. Aus Archivsicht wird hier gerade diskutiert, ob man besser PDF/A-3 als Container oder PDF/A-2 als echtes Archivformat benutzen sollte. Für PDF/A-2 spricht, dass man gleich ein vollständiges, "plattgeklopftes" Archivobjekt hätte (http://bit.ly/PDF-ZUGFeRD, http://bit.ly/XING-PDFA3). Beim PDF/A-3-Container weiß man nicht was drin ist und muss außerdem sicherstellen, dass alle notwendigen Komponenten inkl. einem Archivformat in den Container hineinkommen. Die Diskussion um PDF wird sich also am Format, am Transport und an der Lesbarkeit durch den Menschen entwickeln.
Im Übrigen ist ZUGFeRD als Format noch längst nicht "rund" (http://bit.ly/PC-ZUGFeRD). Eine Aufteilung in "Basis" und "Erweitert" scheint sinnvoll. Auch muss man sich Gedanken machen, welche Auswirkungen die Struktur für die spätere Versionierung des Schemas hat. Und wie man die Spezifikation z.B. auch für den "kleinen Mann" in Formulare oder Textverarbeitungslayouts hineinbekommt. FeRD hat hier noch einiges zu tun.
P.S. wie wäre es denn mit elektronischen ZUGFeRD-Rechnungen als 2-D-Barcode, wäre doch auch eine Variante (wenn man ZUGFeRD klein genug bekommt ...), oder? 

Normales PDF ausreichend für ZUGFeRD

In Foren wird diskutiert ob PDF/A-3 das ideale Format für die elektronische Rechnung mit ZUGFeRD ist (z.B. hier bei uns http://bit.ly/PC-ZUGFeRD und hier auf XING http://bit.ly/16Mj7Qs ).
Nein, eher nicht!
Es erscheint günstiger, für elektronische Rechnungen das PDF/A-2-Format zu nehmen. Dort kann man im Header auch die ZUGFeRD-XML unterbringen und hat gleich ein stabiles Langzeitformat für das Archiv.
ZUGFeRD selbst ist noch nicht ausgreift, zu voluminös und in Bezug die notwendige Stabilität des XML-Schema nicht klar durchdacht. Bevor man also XML-Dateien als PDF/A versendet sollte man hier die nächste(n) Version(en) abwarten.
PDF ist außerdem nur eine Möglichkeit die XML-Rechnung zu transportieren. 

PDF/A-2 ist nicht ausreichend für ZUGFeRD

Der hier geäußerte Vorschlag, an Stelle des zugegebenermaßen neuen ISO-Standards PDF/A-3 ein PDF/A-2 mit Einbettung der ZUGFeRD XML-Daten im Header zu verwenden, ist zwar technisch möglich, aber alles andere als empfehlenswert. PDF/A-2 erlaubt im Gegensatz zu PDF/A-3 eben gerade keine Fremddateieinbindung, d.h. eine XML-Datei hat in einem PDF/A-2 Dokument absolut nichts zu suchen. Natürlich kann man den Trick anwenden, den wir bei PDF/A-1 und A-2 auch getan haben, und eine XML-Struktur als Text an einen sog. "privaten" Knoten in der PDF-Struktur hängen. Der Nachteil dabei ergibt sich aber gerade aus dem "Printen" Charakter: jeder kann hier die Knoten und Benennung wählen wir er will, es gibt keine standardisierte Konvention, wie so etwas zu erfolgen hat. Aus unserer Sicht ist so etwas völlig ungeeignet für einen echten Standard.
Das Argument der Größe ist ebenfalls schwer nachzuvollziehen. Die ZUGFeRD-CeBIT-Rechnung hatte als PDF/A-Dokument durch Zeichensatz- und Logografik-Einbindung eine durch Größe von ca. 240KB. Dagegen ist die reine XML-Datei mit den ZUGFeRD-Daten mit 7KB roh und unter 2KB eingebettet und standardmäßig komprimiert vernachlässigbar. Selbst eine voll aufgeblasene ZUGFeRD "Gold" Rechnung, d.h. mit nahezu allen Tags des UN/CEFACT-Standards schlägt nicht mit mehr als ca. 35KB zu Buche.
Insgesamt ermöglicht es eben gerade PDF/A-3 die Dateieinbindung standardisiert vorzunehmen und es jedem konformen Programm zu ermöglichen ohne forensische Qualitäten die eingebetteten Daten wieder zu extrahieren. Im übrigen ist eine PDF/A-3b-Datei bis auf die Einbettung strukturell praktisch mit einer PDF/A-1b-Datei identisch, sodass sich der Umstellungsaufwand auch in Grenzen halten dürfte.