Hallo @ChrisIR,    nein, ist es nicht. Der Beleg hat visuell auch keine Rundungsdifferenz.   Der Valididator stellt nur fest, dass der ermittelte Nettobetrag aus Brutto nicht korrekt sein kann. Hier mal ein Auschnitt eines Prüfprotokolls von Lexware, das immer sehr ausführlich ist.        ... Mehr anzeigen

Guten Morgen @ErgonomischerBürostuhl !   Vielen Dank für Ihre Rückmeldung.   Ich glaube, ich habe mich in meiner ursprünglichen Beschreibung missverständlich ausgedrückt. Das eigentliche Problem ist weniger das ZUGFeRD-Format selbst, sondern die mathematische bzw. validatorseitige Prüfung innerhalb der EN16931-Logik.   Im klassischen B2C-Handel arbeiten wir mit psychologischen Bruttopreisen wie 9,99 €, 10,99 €, 15,95 € usw. Diese Preise entstehen aus der Marktlogik heraus bruttoorientiert und nicht aus einer zuvor exakt kalkulierten Netto-Bemessungsgrundlage.   Genau dort entsteht das Problem:   Wird aus einem Bruttopreis rückwärts ein Netto mit zwei Nachkommastellen ermittelt und darauf anschließend die Umsatzsteuer wieder berechnet, ergibt sich rechnerisch häufig ein anderer Bruttopreis.   Beispielhaft:   10,99 € brutto → netto rechnerisch 9,235294… € → auf 2 Nachkommastellen gerundet: 9,24 € → zzgl. 19 % USt = 11,00 € brutto   Damit entsteht aus Sicht der Validierung eine rechnerische Unplausibilität zwischen den Einzelwerten und dem ursprünglich fakturierten Verkaufspreis von 10,99 €.   Vielleicht habe ich mich daher unglücklich ausgedrückt: Nicht „die XML-Datei an sich“ macht Probleme, sondern die Validitätsprüfung prüft mathematisch genau diese Zusammenhänge zwischen Netto, Steuer und Brutto nach EN16931-Logik. Und genau diese Prüfungen führen bei bruttopreisorientierten B2C-Preismodellen regelmäßig zu Auffälligkeiten.   Aus meiner Sicht ist das insbesondere für Handelsunternehmen problematisch, weil faktisch viele typische B2C-Endkundenpreise mit „x,99 €“-Logik rechnerisch nicht sauber in eine streng nettoorientierte EN16931-Systematik überführt werden können, ohne dass entweder   Rundungsdifferenzen entstehen oder der ursprüngliche Verkaufspreis verändert werden müsste. Wir beobachten aktuell zudem zunehmend, dass Geschäftspartner Rechnungen bereits dann vollständig zurückweisen, sobald ihre Systeme oder vorgeschalteten Prüfprozesse eine E-Rechnung als „invalid“ kennzeichnen. Dabei wird häufig nicht mehr unterschieden, ob tatsächlich Pflichtangaben fehlen oder ob lediglich solche rechnerischen bzw. validatorbedingten Rundungsauffälligkeiten vorliegen.   Die Übergangsregelungen entspannen die Situation zwar derzeit teilweise im klassischen B2B-Bereich. Für uns als Versandhändler greift das jedoch nur eingeschränkt, da wir durchaus auch B2G-Kunden beliefern, bei denen elektronische Rechnungen bereits verpflichtend sind.   Hinzu kommt aus praktischer Sicht ein weiterer Punkt: Im Versandhandel entstehen Rechnungen in großen Mengen vollautomatisch aus Warenwirtschafts- und Shopsystemen heraus. Eine unterschiedliche Behandlung nach Kundengruppe („diese Rechnung als ZUGFeRD“, „jene nur als PDF“) lässt sich organisatorisch und technisch nur sehr schwer sauber abbilden. Ziel ist daher möglichst ein einheitlicher und stabiler Prozess für alle Empfängergruppen.   Genau deshalb interessiert mich sehr, wie andere Händler bzw. deren Softwareanbieter mit dieser Thematik praktisch umgehen — insbesondere dort, wo bruttopreisorientierte B2C-Preislogiken auf die streng nettoorientierte EN16931-Validierung treffen.   Ich vermute ehrlich gesagt, dass dieses Thema künftig noch deutlich mehr Unternehmen beschäftigen wird, sobald automatisierte Prüfungen im Rechnungseingang weiter zunehmen. ... Mehr anzeigen

Wir können auch nicht mehr arbeiten     ... Mehr anzeigen

Wunderbar!!! Super Idee 😄   Besten Dank ... Mehr anzeigen

Prima, vielen Dank für den Hinweis – das werden wir entsprechend so kommunizieren.   Unabhängig davon stellt sich für mich jedoch noch folgende grundsätzliche Frage:   Im B2B-Bereich gibt es weiterhin Kleinbetragsrechnungen (z. B. Kassenbons bis 250 €), die als vereinfachte Rechnungen gelten und nicht den vollständigen Anforderungen einer EN16931-konformen E-Rechnung entsprechen müssen. Ein nicht unerheblicher Teil unserer Ausgangsrechnungen fällt in genau diese Kategorie.   Vor diesem Hintergrund interessiert mich, wie solche Belege im Umfeld von DATEV verarbeitet werden:   Besteht für DATEV-Anwender die Möglichkeit, die Validierung von Eingangsrechnungen zu deaktivieren oder zu umgehen, sodass auch formal nicht valide (aber steuerlich zulässige) Belege – wie etwa Kleinbetragsrechnungen – weiterhin verarbeitet werden können?   Wir selbst nutzen einen vorgelagerten, externen digitalen Rechnungseingangs-Workflow vor DATEV, sodass wir hier nicht auf eigene praktische Erfahrungen im DATEV-System zurückgreifen können.   Vielen Dank vorab für eure Einschätzungen! ... Mehr anzeigen

Guten Tag Frau Schönweiß,   verstehe ich es richtig, dass nur bei Geldkonten der Eingabebetrag saldiert angezeigt werden kann? Wir haben diverse GuV Konten, die wir mit Fremdwährungen bebuchen. Um diese mit dem Output unseres externen Warenwirtschaftssystems abzugleichen, muss ich immer mühsam Excellisten generieren und den Eingabebetrag nach Soll und Haben sortieren, um so den Saldo in Fremdwährung angezeigt zu bekommen.   Gibt es inzwischen eine andere Möglichkeit für diesen Abgleich?   Gruß Katherina Fröhlich ... Mehr anzeigen

Hallo Paula-Alice,   mir geht es jetzt auch so, wie dir. Hast du inzwischen eine Lösung für dein Doing gefunden?    Gruß Katherina ... Mehr anzeigen

Hallo Mick!     -> Meine Recherche ergab, dass, sofern die Geräte eine Kassenfunktion haben, die Nummer der Kassengeräte gemeint ist. Somit würden sich bei der Meldung Software eAS und Software Version eAS auf die zentrale Software beziehen und Seriennummer, Hersteller und Modell auf das einzelne Kassengerät. -> Wie seht ihr das?   Wir haben eine reine PC-Kassensoftware (Cloud) und alle nötigen Daten in einer Datei vom Kassensoftwareanbieter zur Verfügung gestellt bekommen. Dabei gab er sich als Hersteller und als Modell "xxxx.cloud" an. Wenn du als Kassengerät die Hartware meinst, dann würde ich das nicht so sehen, sofern auf ihr nichts gespeichert wird.       Die TSE haben ja eine Nutzungsdauer bzw. Ablaufzeit. Man meldet jetzt ja die (damalige) Inbetriebnahme/Aktivierung der TSE. Schafft man sich eine neue TSE an, ist diese wieder zu melden. Neue TSE heißt aber nicht zwingend, neue Kasse. Muss denn die reine Außerbetriebnahme der TSE auch gemeldet werden? Oder reicht hier die Inbetriebnahme der neuen TSE? Die Ausfüllanleitung gibt das in meinen Augen nicht her.   Mit Gewissheit kann ich es nicht sagen, allerdings habe ich aufgrund einer Messe bereits Kassen nachgemeldet, in dem ich meine erste Meldung kopiert und dann um meine Messekassen ergänzt hatte. Würde sich jetzt bei einer die TSE Nummer ändern, so würde ich diese einfach ändern und die Meldung wieder absenden. Damit habe ich dann ja bekanntgegeben, dass die alte TSE-Nr. zu dem Stichtag nicht mehr existierte.   vG Katherina   ... Mehr anzeigen

Hallo! Ich antworte jetzt noch einmal auf den eigentlichen Beitrag (statt der letzten Nachricht), in der Hoffnung, dass dieser Thread dann wieder "oben" angezeigt wird. Leider helfen mir die bisherigen Antworten nicht, um mein Problem zu beheben. So hoffe ich, zu diesem Thema noch einmal Hilfe von netten Usern zu erhalten. 🙂   __________________________________    Hallo zusammen,    ich versuche es noch einmal mit einem eigenen Thread, da meine Antwort auf einen alten irgendwie nicht erscheint.    Wir werden unseren Verkauf in wenigen Monaten auf die Währungen PLN und CZK ausweiten. Aus diesem Grund teste ich schon einmal, wie sich die Fremdwährungen in der OSS-Auswertung verhalten und habe dafür zwei Testbuchungen per 1.1. mit dem T-Kurs einer externen Plattform vorgenommen.    Wenn ich es jetzt richtig verstehe, dann soll durch die Verbindung zur EZB quasi mein gebuchter Wechselkurs korrgiert werden. Korrekt?   Jetzt habe ich zwei Probleme, wobei das eine Problem möglicherweise auf das andere aufbaut.   Zum einen wird mir nun beim Öffnen der OSS-Auswertung des 1. Quartals die Fehlermeldung #REW92816 angezeigt.          Ich habe schon gemäß des Dok. 1022611 die Internetverbindung geprüft und kann auch das xml-Dokument über den angegeben Pfad herunterladen.           Erstes Problem: Woran kann es liegen, dass der EZB Kurs nicht gezogen wird? Muss ich den Pfad zur EZB eventuell irgendwo manuell hinterlegen?   Zweites Problem: Möglichweise werden mir aus dem vorgenannten Grund die beiden Testbuchungen in Q1-2025 noch nicht als Nachbuchungen angezeigt. Das würde ich jetzt natürlich erwarten.    P.S. Bisher habe ich die Ergebnisse der Auswertungen immer noch manuell in BOB eingetragen. Ab Q2-2025 möchte ich dann erstmals auch die Datei nutzen.      Über Unterstützung würde ich mich sehr freuen!   Viele Grüße Katherina   ... Mehr anzeigen

Guten Tag,    wir werden unseren Verkauf in wenigen Monaten auf die Währungen PLN und CZK ausweiten, daher teste ich gerade, wie es sich mit der OSS-Auswertung verhält. Dafür habe ich zwei Testbuchungen in Fremdwährung vorgenommen (per 1.1. mit dem T-Kurs einer anderen Plattform).    Wenn ich es jetzt richtig verstehe, dann soll durch die Verbindung zur EZB quasi mein Kurs korrgiert werden. Korrekt?   Beim Öffnen der OSS-Auswertung des 1. Quartals wird mir allerdings auch die Fehlermeldung #REW92816 angezeigt.        Eine Internetverbindung besteht und auch kann ich das xml-Dokument über den angegeben Pfad herunterladen.       Woran kann es noch liegen, dass der EZB Kurs nicht gezogen wird? Muss ich eventuell noch grundsätzliche Stammdaten pflegen? Bisher wurde nie eine Verbindung zur EZB verwendet.   Viele Grüße Katherina ... Mehr anzeigen

Oh man, da habe ich aber echt mal ein richtiges Brett vor dem Kopf gehabt. Danke! ... Mehr anzeigen

Hallo Matthiass,   auch wenn dieser Thread schon älter ist, möchte ich das Thema gerne noch einmal aufgreifen und fragen, ob ihr letztlich fündig geworden sein, euch den Mitarbeiter/PC des Buchungssatzes anzeigen zu lassen?   Bei einem ehemaligen AG hatte ich mal die Ansicht und konnte so nachvollziehen, welcher Mitarbeiter bei welchen Sachverhalten noch Schulungsbedarf hat.   Leider weiß ich nicht mehr, wie wir die Einstellung hinbekommen haben. Es gab sie also auf jeden Fall und jetzt suche ich auch schon wieder länger nach der Funktion.   Gruß Katherina     ... Mehr anzeigen

Ich danke euch für die schnellen Antworten. 😄   ... Mehr anzeigen

Jo, Einheitsbilanz. 🙂 Vielen Dank!!!!   ... Mehr anzeigen

Hallo FBS094,   leider wurde das Buchungsverhalten, welches ich mir erarbeitet hatte, vom STB nicht verifiziert, stattdessen stellen wir nun auf das automatische Verbuchen durch Lodas um.   Bisher buchen wir die Eingangsrechnung zu 100% auf 6822 freiwillige Sozialleistungen.   1.)   6822, 54,00 € VSt.,10,26 € an Kreditor 64,26 €   Und im Rahmen der Lohnbuchungen müssten diese Buchungen entstehen, um die 100% USt. auch wieder abzuführen.   2.)   6072, 34,36 € an 4948 27,87 € an USt, 5,49 €   3.)   3720, 29,90 € an 4948, 25,13 € an USt. 4,77 €   Die Buchung Nr. 2 neutralisiert sich und von dem in Buchung Nr. 1 gebuchten 100% Aufwand haben wir einen Teil als Erlös (Nr. 3) vom Mitarbeiter wiederbekommen.   Hilft dir das?   Gruß Katherina     ... Mehr anzeigen

Liebe Silvia,   herzlichen Dank für deine Antwort. Hast du die Möglichkeit mir deine Erläuterungen in T-Konten oder Buchungssätzen aufzuzeigen? Ich glaube, ich verstehe die Erklärung nicht richtig. Demnach bebuchst du das 6072 im Haben und das 4948 zweimal?   Liebe Grüße Katherina       ... Mehr anzeigen

Schwubs habe ich mein Problem verschriftlicht, habe ich die Lösung selber gefunden. 😂 Hier für jemanden, der ein ähnliches Problem hat.   -> Über die "Anwendungsübersicht" konnte ich die fehlerhafte Zeile einfach löschen. 😁     ... Mehr anzeigen