Wie sieht die Zukunft mit XRechnung, ZUGFerD, Peppol und Co. aus ?

[haentschman]

Zitat:

Das ist aus buchhalterischer Sicht meines Wissens nach der Empfänger beim Rechnungseingang, welcher eine fehlerhafte Rechnung abweisen muss und den Aussteller informieren muss.

...vieleicht sind es aber auch Personen (später auch B2C) die das gar nicht beurteilen können. Weil die Rechnung NUR das XML, ohne PDF, ist. (Beispiel Conrad) Das muß eine Software machen. Das wird ein Spaß, Rentnern zu erklären wie man die Rechnungen liest und zum Bezahlen geben...USB Stick zur Bank.

Zwischenfrage:
Diese Probleme haben auch andere Länder die länger als wir die elektronische Rechnung (verschiedene Formate) benutzen. Wie sind die Erfahrungen? Kann man was lernen? Hat Deutschland die mal gefragt?

[sqlman]

Zitat von haentschman:

Zitat:

Das ist aus buchhalterischer Sicht meines Wissens nach der Empfänger beim Rechnungseingang, welcher eine fehlerhafte Rechnung abweisen muss und den Aussteller informieren muss.

...vieleicht sind es aber auch Personen (später auch B2C) die das gar nicht beurteilen können. Weil die Rechnung NUR das XML, ohne PDF, ist. (Beispiel Conrad) Das muß eine Software machen. Das wird ein Spaß, Rentnern zu erklären wie man die Rechnungen ließt und zum Bezahlen geben...USB Stick zur Bank.

Hier gebe ich dir so etwas von Recht! B2B ist die ERechnung vollkommen in Ordnung. B2C...tja also das wird meiner Ansicht nach nicht funktionieren.

vor allem: Hier sparen wir Papier ein und im Gegenzug gibt es nun für jedes Brötchen einen halben Meter Bon aufgrund der Transaktionsdaten, dann auch noch die Gutscheine und Werbung des Ladens usw....alles auf dem Bon. Und beim Einbuchen eines Stiftes für 2 EUR für das Büro sicht man sich nach dem Datum dumm und dusselig

[Rollo62]

Genau, ich kann beim Erstellen 1000x Prüfen, wenn der Empfänger niemals prüft und jeden Mist durchlässt,
dann ist das ganze System eigentlich für die Tonne.
Der Empfänger muss prüfen und bei Fehler dem Sender mitteilen.

Das auch, weil das ganze Eystem hochdynamisch ist und ständige neue Versionen und Regeln rauskommen,
wo keiner genau Bescheid weiss was er braucht und machen muss.
Da ist der Empfänger meiner Meinung nach voll in der Verantwortung, für ihn falsche Rechnungen abzuweisen,
selbst wenn die beim Sender durch die Validierung kämen.

Ich denke es gibt viele Möglichkeiten für logische Fehler, wo ein z.B. Feld falsch benutzt wird,
was dann womöglich durch alle Validatoren kommt, aber trotzdem falsch ist.

Deshalb wäre mein Fazit:
Der Empfänger ist verantwortlich für seine Prüfung, wenn er Aufgrund einer solchen Rechnung eine Überweisung tätigt.
Der Sender sollte validieren, um nicht im ersten Schritt Schrott zu senden und einen Rückläufer zu produzieren.

Mir scheint es aber fast so, dass die Empfänger gar nicht validieren, es dann lieber ausdrucken und abheften.
Schöne digitale Welt

Das Problem sind meiner Meinung nach immer die vollkommen überkomplexen Spezifikationen und nicht vorhandenen Standardtools,
wo am es Ende noch nicht mal ein einfaches Bedienungshandbuch zu gibt und jeder es auf seine Weise interpretieren muss.
Wenn man XRechnung will, dann muss man doch zuerst ein für alle nutzbares Standardtool bereitgestellt werden,
das MustangProject kommt der Sache noch am nächsten, aber ehrlich, ist das was eine kleine Galabau Firma nutzen möchte?
Die muss dann erst noch einen IT-Spezialisten einstellen.

Besser wäre es gewesen, man hätte einfach die auf Papierrechnungen üblichen Felder so leicht und flexibel wie möglich belassen,
das hätte wohl den meisten (99,9%) gereicht.

[haentschman]

Moin...

Ich sehe es so:
Der Versender sollte die Rechnung validieren. Quasi auf syntaktische Richtigkeit prüfen. Der Empfänger sollte die Rechnung auf Korrektheit des Inhaltes prüfen...wie er es schon immer gemacht hat und ggf. beanstanden. Dazu braucht der Empfänger aber Werkzeuge um das beurteilen zu können. (Einfache! Software)

[arnof]

Ich mache das mittlerweile seit 2020 mit Landrix seinem Tool und habe mich intensiv mit Zugferd und X Rechnung beschäftigt. Ich habe meine Software mittlerweile über 5000 Kunden mit E Rechnung ausgeliefert, aber jeden Tag kommt jemand und hat ein neues Problem. Das kriegt man im Allgemeinen nicht im Griff. Manche Kunden vor allen Dingen große Firmen brauchen zum Beispiel unbedingt die XMP Erweiterung im PDF sonst sagen Sie es ist keine E Rechnung.Die nächsten Kunden. Wollen irgendwelche Angaben haben die eigentlich nirgendswo definiert sind z.B. eine Abrechnungbank will die Objektnummer und solche Sachen wie Vertragsnr und sonstige Sachen in der E Rechnung sehen. Also hier sind ständig Erweiterung nötig. Ich habe allein dieses Jahr schon über zehn Updates gebracht Und jeden Tag kommt ein neuer Kunde mit einem anderen Problem Wunsch oder wo der Endkunde einfach irgendwelche Bedingungen setzt und diese umgesetzt haben will, sonst kriegt man die Rechnung halt nicht bezahlt. Also das ist ein Thema das wird uns lange beschäftigen.

[Rollo62]

Zitat von arnof:

... über 5000 Kunden mit E Rechnung ausgeliefert, aber jeden Tag kommt jemand und hat ein neues Problem.

Exakt das meine ich
Gibt es eigentlich eine Beschwerdestelle beim Digitalministerium?
Der Erfolg und die Wirksamkeit des Ganzen, zumindest laut EU, soll ja regelmäßig überprüft werden.
Man sollte sich da mal entsprechend melden und den ganzen Irrsinn mit Mehraufwänden usw. genau dokumentieren.
Steht dem eigentlich irgendeine Art von "volkswirtschaftlicher Ersparnis" entgegen, ich fürchte nein,
das muss man den entsprechenden Stellen immer mal wieder vor die Nase halten.

[BlueStarHH]

Zitat von Rollo62:

Steht dem eigentlich irgendeine Art von "volkswirtschaftlicher Ersparnis" entgegen, ich fürchte nein,
das muss man den entsprechenden Stellen immer mal wieder vor die Nase halten.

Ersparnisse gibt es in Form von Zeitersparnissen:
-Man kann die Rechnungen per Kopfdruck bezahlen, da das Online-Banking sie direkt auslesen kann.
-USt-Voranmeldungen sollen entfallen, da das Finanzamt ab 2028 ja alle Rechnungen hat.
-Mehreinnahmen für den Staat (weniger Steuerhinterziehung, das Umsatzsteuerkarussell soll verhindert werden usw.)

[Frickler]

Zitat von haentschman:

Das wird ein Spaß, Rentnern zu erklären wie man die Rechnungen liest und zum Bezahlen geben...USB Stick zur Bank.

Rentner haben i.A. einen ELSTER Account. Und bei ELSTER gibt es einen kostenlosen Service "E-Rechnung visualisieren" (https://www.elster.de/eportal/e-rechnung). Rechnungsdatei auf das Feld ziehen, anzeigen lassen, fertig.

[haentschman]

Danke...

Ich hatte vergessen X-Rechung zu schreiben.

Es wird wohl BT-19 werden.

Zitat:

<xs:element name="Buyer_accounting_reference"
type="xr:text"
minOccurs="0"
maxOccurs="1">
<xs:annotation>
<xs:appinfo>BT-19</xs:appinfo>
<xs:documentation>Ein Textwert, der angibt, an welcher Stelle die betreffenden Daten in den Finanzkonten des Erwerbers zu buchen sind.</xs:documentation>
</xs:annotation>
</xs:element>

Aber die "BuyerAccountingReferenence" oder "AccountingCost" finde ich auch nicht in der Version XRechnung-Version 3.0.2 service release 3

[AuronTLG]

Ich verstehe glaube ich nicht so ganz, was du suchst.
Das, was du gepostet hast, ist doch das semantische Datenmodell, was für die praktische Umsetzung keine Relevanz hat.
Geht es nicht um die Umsetzung in CII und UBL?

Suchst du das hier im semantischen Datenmodell?

Code:

<xs:element name="Invoice_line_Buyer_accounting_reference"
                     type="xr:text"
                     minOccurs="0"
                     maxOccurs="1">
            <xs:annotation>
               <xs:appinfo>BT-133</xs:appinfo>
               <xs:documentation>Ein Textwert, der angibt, an welcher Stelle die betreffenden Daten in den Finanzkonten des Erwerbers zu buchen sind. Anmerkung: Wenn die Angabe genutzt werden 
                                 soll, muss der Erwerber dem Verkäufer diese Referenz vor der Rechnungserstellung mitteilen.</xs:documentation>
            </xs:annotation>
</xs:element>