Wie prüfen ob PDF ZUGFeRD enthält?

[DerMondistunsereSonne]

Also wenn du es von Hand wissen möchtest, dann kannst du das in der PDF ansehen, siehe Bild. Und ich gehe mal davon aus, dass auch jemand da eine Variante für Delphi hat.

Die XML zu Validieren ist leider nicht einfach. Dafür gibt es allerdings genügend Seiten, die so etwas anbieten. Wie gut das Ergebnis ist, kann ich nicht beurteilen.

[Rollo62]

Es geht doch darum ein einfaches, verlässliches Format zu haben.
Wie eben PDF, das ist sowas von Standard, dass es mittlerweile überall problemlos läuft.
Das sollte doch mit genauso einem verlässlichem XML gepaart werden, wofür es dann auch auf tausenden System in gleicher Weise einen Viewer gewen sollte um das zu checken.

PDF läuft perfekt, XML anscheinend noch nicht.
Dabei hätte ich eigentlich bei dem strukturierten XML weniger Probleme erwartet einen Viewer zu finden,
als bei der proprietären PDF.

Das Argument kann ja nicht sein, dass ich solange einen passenden Viewer suchen muss, bis die Daten stimmen.
Das ZugFErD XML sollte in "irgendeinen" Viewer geworfen werden können, und BÄM ... fertig.

Vielleicht denke ich mal wieder zu einfach ... aber ist es nicht genau das, was Millionen Firmen und Kunden demnächst machen müssten, um die Validität einer Rechnung prüfen zu können?

Das kann doch nicht sein, dass dies nur innerhalb von komplexen B2B System funktionieren mag, aber der einfache Bürger mit seiner Telekom, 1&1 und Handwerkerrechnung dies nicht auf simpelste Weise prüfen kann.
Seltsam, ich hatte mal wieder mehr erwartet :shock:

[DerMondistunsereSonne]

Du kannst auch die XML in irgendeinen Viewer werfen und es dir ansehen. Das ist dann so, als ob du dir Autos auf der Strasse anschaust, die Farbe und Marke etc kannst du erkennen.

Die Validierung ob die Reifen eingetragen sind, muss man schon mit dem Fahrzeugschein und so weiter machen. Und das ist bei der ERechnung genauso, die XRechnung ist sogar noch aufwändiger.

[Rollo62]

Was ich meine ist, dass so eine Standard-XML doch in einem Standard-Viewer für Normalsterbliche lesbar gemacht werden sollte.
Die meisten Rechnungen haben halt keine Super-Sonder-Verknüppelung, sondern Lieferant, Kunde, Produktliste/Anzahl, Rechnungsdatum/Id, Summe, VAT, Endbetrag, Zahlungsziel, usw.

Das ist doch überschaubar genug für einen Standardviewer, um zumindest die Basics auszulesen, oder sehe ich das zu einfach?

Bei komplexerem Zeugs kann er sich ja ausklinken, es sollte aber mit den einfachen Muster-PDF der ZugFeRD Leute selber funktionieren.

[DerMondistunsereSonne]

Ich kenne zumindest kein Freeware-Tool, dass diese vermeintlich einfache Aufgabe umsetzen kann. Und wir haben das auch nicht "mal eben" entwickelt.

[Papaschlumpf73]

Falls einer von euch die iX aus dem Heise-Verlag liest: In der Ausgabe 2/2024 ist auf Seite 84 eine Übersicht mit 11 Tools zur Anzeige und Validierung von elektronischen Rechnungen. Alles Open Source und Freeware.

[Papaschlumpf73]

Die ix-Ausgabe 2/2024 kann man auch noch einzeln im Heise-Shop erwerben. (Ich bekomme keine Provision)
- doch nicht - lässt sich nicht mehr bestellen.

[Papaschlumpf73]

Gewissensfrage: Soll ich hier mal einen Scan der Übersicht posten? Dem Verlag entsteht ja kein Schaden, wenn er die Ausgabe eh nicht mehr verkauft...
- geht leider auch nicht - den Artikel kann man ziemlich sicher über Heise+ online lesen. Hab ich aber nicht, um das zu checken.

[Papaschlumpf73]

Der Hinweis auf die iX-Ausgabe war doch nicht so cool. Einige der vorgestellten Tools wurden in diesem Beitrag bereits erwähnt. Andere sind nur online verfügbar und unterstützen nur reine X-Rechnungen.

[sh17]

Im Falle von XML/ZUGFeRD in PDF ist das eigentliche Problem, dass zukünftig das XML-Dokument steuerrechtlich ausschlaggebend ist. Dem Finanzamt ist also egal, was in der PDF steht, die XML wird bei Fragen herangezogen. Deswegen ist es wichtig, dass der die Rechnung Prüfende, die XML-View prüft, ob die Rechnung in Ordnung ist. Die Probleme mit dem Viewer für die x-verschiedenen Versionen der E-Rechnung sind natürlich nicht gelöst und basieren meist auf langsamen Java-Bibliotheken. Hier kann man nur eine Art Zwischenlösung anbieten, Pdf anzeigen, die der Bearbeiter versteht und nebenbei die Zahlen der gelesenen XML. Was quasi einer doppelten Prüfung / doppeltem Arbeit entspricht. Am Ende kann man wenigstens die Übertragung der Werte in das System automatisieren. Aber mehr ist momentan nicht zu gewinnen meines Wissens.