E-Rechnungspflicht ab 2025

Morje,
danke! JA der Kunde möchte einfach nur die xml Datei erstellen ohne vorher noch eine PDF dazu , nur die Leitweg ID hat hier kein Nutzen da es nicht an eine Behörde oder öffentliche Einrichtung geht , also wäre es besser ZugFerd zu lassen und den Anhang der PDF zu nutzen?
 
Also ich würde nicht das xRechnungs Format nehmen.

Die Frage ist wieso der Kunde nur die .xml benötigt da diese ja automatisch beim erzeugen in die pdf integriert wird. Ist ja kein Mehraufwand.

Zweite Frage wäre mit welchem System der Kunde die Daten einlesen will.
Vermute da wird was selbst "gebasteltes" dahinter stehen, da jede vernünftige Software die ZUGFeRD Datei (pdf) ja problemlos einlesen sollte.
Die pdf ist ja nur der "Umschlag".
 
Es ist leider wirklich so, dass zur Zeit die X-Rechnung auf reine öffentlich-rechtliche Rechnungsempfänger ausgelegt ist. Natürlich kann man einfach irgend eine Nummer in das Feld Leitweg ID schreiben und hoffen das der Empfänger damit klar kommt und keine Validierung durch sage oder den Rechnungsempfänger erfolgt. Aber die erstellten XML Datei unterscheiden sich doch im Verhalten und Aussehen.
z.B.
ZUGFeRD
XML:
  <rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
X-Rechnung
XML:
  <rsm:ExchangedDocumentContext>
    <ram:BusinessProcessSpecifiedDocumentContextParameter>
      <ram:ID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</ram:ID>
    </ram:BusinessProcessSpecifiedDocumentContextParameter>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <ram:ID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
Darüber hinaus wird bei ZUGFeRD anscheinend das Feld "Ihr Zeichen" in das Feld BuyerReference gemappt, bei X-Rechnung halt die Leitweg ID,

Code:
      <!--Ihr Zeichen bzw. Leitweg-Id-->
      <ram:BuyerReference>12345</ram:BuyerReference>
      <!--Verkäufer-->
In der aktuellen Version kann ich darüber hinaus auch noch eine Kunden-ID im Kundenstamm angeben, die wird nur bei ZUGFeRD gemappt und landet dann hier:
XML:
      <!--Käufer-->
      <ram:BuyerTradeParty>
        <ram:ID>D10396</ram:ID>

Im Augenblick würde ich auch die Verwendung von X-Rechnung bei normalen Kunden nicht empfehlen. Da können wir nur hoffen, dass sage uns eine Option ergänzt um nur den reinen XML Part der ZUGFeRD ohne PDF auszugeben.

liebe Grüße
 
Ich vermute mal das
Im Augenblick würde ich auch die Verwendung von X-Rechnung bei normalen Kunden nicht empfehlen. Da können wir nur hoffen, dass sage uns eine Option ergänzt um nur den reinen XML Part der ZUGFeRD ohne PDF auszugeben.
nicht passieren wird.

ZUGFeRD definiert ja selbst schon das in einer pdf ein xml eingebettet ist.
Somit wäre es nicht Standardkonform.

Ich frage mich warum man die xml ohne pdf überhaupt benötigt.
Wenn Programme konform sind zum einlesen einer ZUGFeRD dann müssen die ja mit der pdf und dem eingebetteten xml umgehen können.
 
soweit ich weiß, geht das bei XRechnung nicht, anders wie bei Peppol. Xrechnung wie auch ZUGPfeRD 2.2 welches Sage noch verwendet sind nicht mit Factor-X (Frankreich kompatibel) hier wird min. Version ZUGPfeRD 2.3 benötigt. XRechnung ist so eine eigene deutsche Erfindung und dient erst einmal nur für den öffentlichen Sektor in DE. XRechnung sollte dem Stand von ZUGPfeRD 2.3 entsprechen und nicht zwingend eine Leitweg ID verlangen, weil im Austausch mit anderen Europäischen Ländern verwendet werden kann, die nicht ZUGPfeRD verwenden und das sind eigentlich alle anderen außer DE. In allen anderen Ländern gilt auch weiterhin, wen es keine öffentlichen sind, E-Rechnung kann frei vereinbart werden und ist nicht zwingend und ist auch so nicht vorgesehen (DK, FI, SE usw.). Warum das DE so verpflichtend will bis 2028, müssen wir anscheinend das FA fragen. Registrierung in einem Peppol Netz ist auch nicht kostenlos, man benötigt einen Provider dafür. So wie es momentan angedacht ist von DE die als letzte darauf reagiert haben, wird das für uns in Zukunft einen bedeutenden Mehraufwand bzw. Mehrkosten verursachen.

Also anders wie in @breithecker Video / Schulung, ZUGPfeRD gilt nicht EU weit. Wir müssen von Glück reden wen es wenigstens bereits mit FR geht (Factor-X, ab ZUGPfeRD Version 2.3, Sage kann nur 2.2). XRechnung ist bisher ein Format das nur von DE öffentlichen verwendet wird, könnte aber auch für XML Rechnungen verwendet werden, wen die Leitweg ID nicht Pflicht ist und das Format gleich wäre. Nur kocht eben öffentlich anders als die Unternehmen.

Und die Drittstaaten Rechnungen tippen wir weiter von Hand. :cool: Man könnte Lauterbach dahinter vermuten, wenn der nicht in einem anderen Ministerium gesessen hätte. :) So war es Lindner und der wusste das er es nicht lange macht, also ging ihm das am Po.. vorbei.

Fazit: ZUGPfeRD können wir auf Grund des hybriden Formats an jeden senden, auch an B2C Kunden, da ja eine lesbare und druckbare PDF dabei ist.
Eingelesen und verarbeitet kann ZUGPfeRD ab 2.3 auch von Factor-X FR sonst noch keiner und wird sich voraussichtlich auch nicht ändern, da andere Länder seit fast 10 Jahren sich schon für Peppol entschieden haben.

XRechnung mit Leitweg ID nur für öffentliche in DE und Preiskataloge etc. sind vorerst da nicht vorgesehen.
Die Nutzung des verpflichtenden Portals ab 2028 in DE wird auch nicht kostenfrei an den Nutzern vorbeischrammen, da wird wieder jemand versorgt werden. Notfalls die Kaste der Steuerberater.
 
Zuletzt bearbeitet:
Ich frage mich warum man die xml ohne pdf überhaupt benötigt.
Wenn Programme konform sind zum einlesen einer ZUGFeRD dann müssen die ja mit der pdf und dem eingebetteten xml umgehen können.
weil es in fast allen EU-Staaten eben nicht konform ist. Die erwarten eine reine XML und verwenden kein ZUGPfeRD. :cool:
Weil Sie keinen Umschlag wollen, Netztrafic etc. im Peppol Netz bekommst eben keinen Umschlag wie Du sagst oder meinst Du am deutschen Wesen muss die Welt genesen. :)
 
man kann aber auch - ich weiß es sind kostenpflichtige Zusatzlösungen - diverse Rechnungsfreigabelösungen wie E-Invoice und Candis nutzen.

Damit will ich es nicht klein reden und auch keine Diskussion starten was im Standard drin sein sollte.

Aber zusammengefasst gilt - es gibt Lösungen für die Sage 100
 
@breithecker , wie Recht Du hast, der Kunde erwirbt eine Standardsoftware, die gesetzlichen Anforderungen ändern sich, der Kunde zahlt Service und Wartung und muss damit er Gesetzes konform die Software weiter verwenden kann, entweder eine kostenpflichtige Zusatzlösung kaufen oder +10% von seinem Preis auf Connected lösen. Das nenne ich Mehrwert Generierung.

Nur traurig, dass bei Connected noch nicht mal die aktuelle Version von ZUGPferd dabei ist und nur versendet werden konnte, einlesen hätte ja auch noch was kosten können. Aber war dann vielleicht doch zu viel.
 
Zuletzt bearbeitet:
Als ich zum Thema E-Rechnungen noch so "naiv" an die Sachlage herangegangen war, habe ich in der Zwischenzeit doch viele kleine Hürden vorgefunden, die das automatische einlesen von E-Rechnungen doch beeinträchtigen. Ich habe nun konkret ein Beispiel was wirklich komplex ist.

Bisher hat mein Endkunde im Sozial Sektor die Eingangsrechnungen manuell nach Papier Vorgaben (PDF gedruckt, verbucht und abgelegt); mit den E-Rechnungen hat nun dieser Endkunde sorgen, dieses Vorhaben so nicht umsetzen zu können. Der Grund ist, das einige Eingangsrechnungen immer auf unterschiedliche "Häuser" (welches in der Sage 100 innerhalb der Datenbank, Mandanten sind), aufgeteilt werden müssen.

Der Anwender hat damit auf unterschiedliche Mandanten eine Rechnung verbucht, 60% Haus A, 30% Haus B und Rest auf Haus C, Mandant A bis C;

Im Sage Standard habe ich bisher solche Möglichkeiten nicht vorgefunden und ich denke, das E-Rechnung PLUS das auch so nicht machen könnte.

Rein theoretisch könnte er im Standard diese E-Rechnung einlesen im Mandanten A, aber dort nicht verbuchen lassen. Nur damit er Informationen zur Sicht hätte. Oder er verwendet einen E-Rechnung Viewer zur Einsicht. Einige der Versender seiner Lieferanten möchten nämlich zu 2026 nur noch xml Anlieferung vornehmen, ohne eine sichtbare PDF.

Ich vermute ähnliche Probleme könnten hier im Forum bereits diskutiert worden zu sein.

Wie würdet ihr da vorgehen. Oder müssten wir über eine Sonderprogrammierung schon vorab prüfen.
 
wie macht der Kunde das denn rein rechtlich. Eine Rechnung ist doch immer auf einen Mandanten ausgestellt. Dort muss er es doch auch einbuchen. Danach kann er doch erst die Kosten umlegen.
 
Das die Lieferanten immer nur reine XML (XRechnung) versenden ist eher ungewöhnlich.
Wurde das wirklich so mitgeteilt?

Bisher kenn ich das so, dass der Lieferant entweder automatisch eine ZUGfERD (PDF mit integrieter XML) sendet, oder fragt, was man haben will.

Wenn er ZUGfERD sendet gibt´s ja kein Problem.
...außer dem von @breithecker schon angesprochenen rechtlichen Thema.
 
Hallo, ich wundere mich, wie diese Art der Verbuchung bisher durch Wirtschaftsprüfer abgenickt werden konnte. Im Standard wird Sage sowas nie umsetzen - weil die Steueridentifikationen des Rechnungsstellers und der Rechnungsempfängers dann nicht übereinstimmen - da kann es nur eine 1:1-Beziehung geben. Man müsste daher die Rechnung bei einem Mandanten buchen und dann über eine Intercompany-Rechnungsstellung verteilen oder vielleicht sogar in eine Gesamtumlage einrechnen. Bitte meldet Euch, wenn ihr da Unterstützung braucht.
 
Mein Kunde ist nicht Umsatzsteuerpflichtig und kann auch keine Vorsteuer abziehen. Die Häuser sind praktisch seine Kostenstellen, das wurde damals so gemacht, weil innerhalb der einzelnen Häuser "Patienten" als Debitoren geführt werden und daher es immer nur eine Rechnung gibt, das hat also nichts mit dem Versender zu tun, für den wird nur an den Hauptmandanten die Rechnung versendet, alles andere wurde bisher nur Intern so auf die einzelnen Mandaten umgebucht. Sicherlich könnte ich mir vorstellen, das weiterhin die PDF versendet wird.

Ich wollte hier keine rechtliche Dinge wissen, sondern ob es technisch überhaupt möglich wäre eine E-Rechnung so einzulesen, das man da beim Buchen auch andere Mandaten hätte bedienen können. Aber da es ein zu sehr spezieller Fall ist werde ich mit meinem Kunden sprechen, das wir hier mittels der Viewer in der Lage sind, wie bisher auch die Rechnungen zu verwenden.

Thema Erledigt.
 
Zurück
Oben