Zugferd Dateien auslesen/erzeugen für Faule

[IBExpert]

ich hab mittlerweile bei den ganzen tool anbietern, die irgendwelche portale machen, da alles ungenügend finden und einem die eierlegende wollmilchsau gegen gewaltige gebühren verkaufen wollen, keine lust mehr, das überall zu testen, es ist halt deren business modell, nur das toll zu finden, was von denen selber kommt
Der von dir genannte findet meine pdf auch nicht gut, gleiche fehlermeldung wie bei dir.

workaround:
chatgpt (ersetzt bei mir immer mehr alles was ich sonst in suchmaschine gesucht aber so detailliert nicht gefunden habe)
fand fehler durch abweichungen vomvisuellen inhalte und xml inhalt, das war mir bewusst, aber der optische teil ist ja nur begrenzt relevant, ich fand die kommentare super hilfreich.


1. frage kannst du eine e-rechnung pdf auf gültigkeit prüfen

Antwort
Ich kann dir auf jeden Fall helfen, eine E-Rechnung im PDF-Format zu prüfen – insbesondere auf formale Gültigkeit nach Standards wie XRechnung oder ZUGFeRD, sofern die Datei die strukturierten XML-Daten eingebettet enthält.
Bitte lade die entsprechende PDF-Datei hoch, dann analysiere ich:
Ob eine eingebettete XML-Datei vorhanden ist (z. B. zugferd-invoice.xml oder xrechnung.xml)
Welcher Standard verwendet wird (ZUGFeRD, XRechnung, Factur-X, etc.)
Ob sie den grundlegenden formalen Anforderungen entspricht (Schema-Validierung etc.)
👉 Lade die Datei hoch, und ich schaue sie mir direkt an.

2. datei hochgeladne (genau die die ich damals auch schon getestet hatte)

ergebnis

Danke für das Hochladen der Datei. Ich habe sie analysiert und hier ist das Ergebnis der Prüfung:

✅ Formale Prüfung der E-Rechnung (r2.pdf)
1. Eingebettetes XML erkannt
Die PDF enthält ein Factur-X/ZUGFeRD XML-Dokument.
Identifizierter Standard: urn:factur-x.eu:1p0:minimum
Das entspricht dem ZUGFeRD 1.0 Profil "Minimum".
2. Grunddaten aus dem XML
Rechnungsdatum: 15.11.2024 (20241115)
Gesamtbetrag: 235.62 EUR
MwSt.: 37.62 EUR
Käufer: Kunden AG Frankreich
Verkäufer: kurios GmbH, DE123456789
3. Formale Gültigkeit
Die XML-Struktur entspricht dem Factur-X/ZUGFeRD 1.0 "Minimum"-Profil.
Kein Schemafehler oder Strukturproblem erkannt.
Für rechtssichere Archivierung oder Weiterverarbeitung z. B. in ERP-Systemen ist dieses Format grundsätzlich geeignet.
4. Inhaltliche Diskrepanz
Die Inhalte der PDF-Ansicht (sichtbarer Teil) weichen stark vom XML-Inhalt ab:
PDF zeigt: Verkäufer ist IBExpert Ltd. (Malta), Käufer ist Scooter Freaks LTD
XML zeigt: Verkäufer ist kurios GmbH (DE), Käufer ist Kunden AG Frankreich
🛑 Fazit
Technisch ist die PDF eine gültige ZUGFeRD-/Factur-X-E-Rechnung (Minimum-Profil).
Inhaltlich ist sie nicht konsistent: PDF-Darstellung und eingebettete XML-Rechnung widersprechen sich. Das kann auf einen Erstellungsfehler oder Manipulationsversuch hindeuten.
Wenn du willst, kann ich dir auch helfen:
Die XML separat zu extrahieren
Den XML-Inhalt verständlich aufzubereiten
Eine konsistente E-Rechnung zu erstellen
Sag einfach Bescheid, wie du weitermachen willst.

[mkinzler]

Zitat:

Das entspricht dem ZUGFeRD 1.0 Profil "Minimum".

Achtung: ZUGFeRD 1.x ist veraltet! Um als E-Rechnung zu gelten muss ZUGFerd 2.x erfüllt sein. Sonst handelt es isch um eine "sonstige Rechnung" und keine E-Rechnung!

https://www.elster.de/eportal/e-rechnung

Hinter den meisten (Online-)Validatoren steckt KOSIT: https://github.com/itplr-kosit

[sh17]

bzw auch https://validool.org/

Den kann ich wirklich empfehlen zu lizensieren. Sehr genau.

[IBExpert]

der xml part in meiner rechnung ist auch kompatibel, auch bei elster, also wird es in zukunft dannn eben nur den xml part geben und wenn jemand das nicht selber visualisieren kann, bekommt der informativ halt noch ein grafik dazu, besser gar nicht erst pdf, was auch immer da drauf steht. Mein Beispiel wäre zwar sicher auch ohne extremen aufwand dann 2.x kompatibel machbar, weil der xml teil ja schon passt, aber das seh ich wie in anderen bereichen auch:

ich bin im ältesten gewerbe der Welt. Ich mach Kunden für Geld glücklich! Was ihr da jetzt in eurem Kopf abgeht liegt an euch ....

Die E-Rechnung regulierungen wie auch viele andere neu eingeführte Regulierungen sind teilweise derartig hirnverbrannt, wundert mich eigentlich das man nicht an jeder Tanke dann auch nur noch xml gelumpe in die hand gedrückt bekommt. Und ja, auch die Regulierungen für Kassensysteme sind mir bekannt.

Warum hat man den jahrzente langen Standard Edifakt nicht benutzt? hauptsache irgendwas neues das der Steuerberaterbranche weiterhilft, ohne manpower weiterhin mehr als reichlich Gebühren für voll automatisierte Buchführung einzunehmen .... müsste man mal ausrechnen wie viel energie der europaweit zusätzliche speicherplatz erfordert, den xml da zusätzlich erfordert in vergleich zu edifakt oder sogar json bei gleichenm informationsgehalt.

lasst uns sonst diesen topic mit der nachricht von mkinzler abshcliessen, 1.x ist ungültig, das generelle verfahren ist aber technisch sicherlich machbar, aber mögliche details wurden
ja auch in anderen threads bereits diskutiert.

[handyotto]

Guten Morgen,

danke für Eure Ausführungen. Ich bin ja auch schon länger im Gewerbe und komme mehr und mehr zu dem Entschluss dass es mir langsam egal ist. Wie IBExpert auch, bekommt, wer mit meiner ZUGFeRD-pdf nicht zufrieden ist, eben nur eine X-Recnung-xml. Die stimmt nämlich bei bisher jedem Validierungstool.

Man könnte fast sagen q.e.d., denn hier:

Zitat von sh17:

bzw auch https://validool.org/

Den kann ich wirklich empfehlen zu lizensieren. Sehr genau.

Bekomme ich mit der pdf "lustige" Meldungen:

Beschreibung	Wert
Die Datei ist eine PDF oder ein XML?	PDF
Die PDF hat eine Datei eingebettet?	Ja
Die XML hat ein gültige Syntax?	Nein, kann keines der folgenden Elemente finden: "/rsm:CrossIndustryDocument/rsm:SpecifiedExchangedDocumentContext/ram:GuidelineSpecifiedDocumentContextParameter/ram:ID", "/rsm:CrossIndustryInvoice/rsm:ExchangedDocumentContext/ram:GuidelineSpecifiedDocumentContextParameter/ram:ID" oder "/Invoice/cbc:CustomizationID"
Die XML hat ein gültiges Profil?	Nein
Die Datei wird in die Validierung gegeben?	Nein

Wenn ich nur das beinhaltende xml hochlade schaut es dann aber so aus:

---8<-----------8<-----------8<-----------8<-----------8<-----------8<--------
Die E-Rechnung entspricht den Vorgaben der deutschen USt-Gesetzgebung und könnte somit angenommen werden.
---8<-----------8<-----------8<-----------8<-----------8<-----------8<--------

Und auch die Details von den drei "Prüfseiten" drunter bescheinigen mir: Alles gültig, nur einer meckert einen Rundungsfehler an, der so aber garnicht vorkommt...

Und ja, Elster frisst fast alles. Nur einen frei erfundenen Namen für das xml in der pdf mag es nicht. Also sollte ein Verweis darauf genügen.

Da ich aber intern die xml-Dateien nicht alle gleich nennen will, lautet meine qpdf-Zusammenpackzeile deshalb wie folgt (ich mach das unter Linux):

Code:

qpdf NameNacktePdf.pdf --add-attachment NameVomXml.xml --description="ZUGFeRD" --filename=factur-x.xml -- NameZusammengepacktesPdf.pdf

[AuronTLG]

Das könnte evtl auch mit etwas zu tun haben, was mir neulich aufgefallen ist:
Schon seit ZUGFeRD 1 gibt es eigentlich bereits die Vorgabe, dass die PDF bestimmte Metadaten enthalten muss, momentan nämlich "ConformanceLevel", "DocumentType", "DocumentFileName" und "Version".
Lustigerweise haben diese Metadaten bislang anscheinend niemanden interessiert, was sich aber irgendwann in den letzten 2-3 Monaten geändert zu haben scheint. Fehlen diese Metadaten, beschweren sich nun einige Validatoren, wie z.B. Mustang, eben genau darüber, dass zwar eine XML enthalten, aber ungültig sei.

Ich hatte tatsächlich an einer Stelle einen Fehler drin, durch den unter Umständen ZUGFeRDs ohne diese Metadaten erzeugt wurden, was zuvor nicht aufgefallen war, weil es eben niemanden gejuckt hat. Dadurch entstand das Phänomen, dass ZUGFeRDS, die einen Monat zuvor noch einhellig validiert wurden, nun plötzlich angemeckert wurden, und eben genau das, was du gerade beschrieben hast: Die ZUGFeRDS wurden angemeckert, die nackte XML jedoch nicht.

[sh17]

fügt qpdf denn Metadaten hinzu?

[AuronTLG]

Von der Zusammenpackzeile her sieht das nicht so aus, denn da fehlen die Angaben für Version und ConformanceLevel.
Nimmt man Mustang für das Kombinieren von PDF und XML, so muss man ja als Parameter sowohl die ZUGFeRD-Version als auch das verwendete Profil angeben, welche dann in die entsprechenden Metadaten geschrieben werden. Ich wüsste jetzt nicht, wie qpdf durch jenen Befehl wissen sollte, welches ZUGFeRD-Profil man verwendet.