Momentan ist ja alles nur B2B.
Was soll der Privatkunde auch mit einer elektronischen Rechnung?
Also ist das aktuell noch gar kein Thema mit der DSGVO.
e-rechnungen ?
- Ersteller haass
- Erstellt am
Was soll der Privatkunde auch mit einer elektronischen Rechnung?
Also ist das aktuell noch gar kein Thema mit der DSGVO.
easy-e-invoice
ww-pappel
Ich danke dir für das Feedback, super Sache. Den QR-Code habe ich direkt mal eingebaut
easy-e-invoice
ww-pappel
Vielen Dank für den Denkanstoß. Das ist tatsächlich ein sehr interessanter Aspekt. Nach meinem aktuellen Verständnis besteht keine direkte Informationspflicht gegenüber dem Rechnungsempfänger, da dieser keine Beziehung zu mir als Anbieter hat und die Daten ausschließlich im Auftrag des Rechnungserstellers verarbeitet werden, der den AGB und Datenschutzerklärungen zustimmt.
Eine Informationspflicht trifft den Rechnungsersteller nach meiner bisherigen Recherche nur dann, wenn er personenbezogene Daten systematisch verarbeitet. Wer lediglich einmalig eine Rechnung erstellt, ohne weitere Verarbeitung oder Speicherung, fällt in der Regel nicht unter diese Pflicht. Ich bin allerdings kein Jurist, daher nehme ich Deinen Hinweis sehr ernst und werde das sicherheitshalber mit meinem Anwalt besprechen. Nochmals danke für die Anregung. Gerade bei so komplexen Themen wie Datenschutz ist der Blick von außen besonders wertvoll.
Wir schreiben seit 2025 nur noch digitale Rechnungen auch an privat Personen. Keine Lust mehr da 2 fleißig zu fahren. Kommt ja eh irgendwann für alle.
Wir machen alles über die Datev. Haben aber auch meist nur 5-10 Rechnungen im Monat.
Grüße Sebastian
wirdelprumpft
ww-robinie
Evtl. wäre ein Prüftool für Fremde e-Rechnungen auch recht praktisch
Das FA prüft ja nur den maschinenlesbaren Teil - selbst sieht man aber nur die PDF - Bildinformation und wenn das aus irgendeinem Grund nicht überein stimmt könnte es lustig werden.
Manchmal sind Werbeanrufe zu gebrauchen den Aspekt hatte ich nicht auf dem Schirm - man ist ja verpflichtet die Rechnung auf vollständigkeit zu Prüfen- hab ich noch nie gemacht bei B2B weil ich davon ausgegangen bin das alles passt aber beim erstellen der XML Information könnte schon mal was vorkommen.
Das FA prüft ja nur den maschinenlesbaren Teil - selbst sieht man aber nur die PDF - Bildinformation und wenn das aus irgendeinem Grund nicht überein stimmt könnte es lustig werden.
Manchmal sind Werbeanrufe zu gebrauchen den Aspekt hatte ich nicht auf dem Schirm - man ist ja verpflichtet die Rechnung auf vollständigkeit zu Prüfen- hab ich noch nie gemacht bei B2B weil ich davon ausgegangen bin das alles passt aber beim erstellen der XML Information könnte schon mal was vorkommen.
wirdelprumpft
ww-robinie
Da die Anmerkungen ja bearbeitet werden siehe Bild (pos. sind im Schriftfeld)
Abkürzungen sind seltsam.
würde da
Stunden - Std. statt HUR
Stück - Stk. statt C62
verwenden
evtl. ein paar Zahlungsarten zur Auswahl und dann das Fälligkeitdatum automatisch auf die ausgewählte Zahlungsart setzen.
ist zwar ne e-rechnung aber passt das Adressfeld in ein Sichtfensterumschlag ?
Manche stehen auf Pos. Nr. (ich nicht)
AW = Arbeitswert verwenden auch manche Firmen
Was ist mit Sonderfällen wie Bauleistung nach §13 etc.
3x die eigene Adresse auf der Seite evtl. ein und ausblendbar gestalten.
Nachtrag: evtl. Handynummer einblendbar im Fußfeld u.a. wegen Whatsapp
Abkürzungen sind seltsam.
würde da
Stunden - Std. statt HUR
Stück - Stk. statt C62
verwenden
evtl. ein paar Zahlungsarten zur Auswahl und dann das Fälligkeitdatum automatisch auf die ausgewählte Zahlungsart setzen.
ist zwar ne e-rechnung aber passt das Adressfeld in ein Sichtfensterumschlag ?
Manche stehen auf Pos. Nr. (ich nicht)
AW = Arbeitswert verwenden auch manche Firmen
Was ist mit Sonderfällen wie Bauleistung nach §13 etc.
3x die eigene Adresse auf der Seite evtl. ein und ausblendbar gestalten.
Nachtrag: evtl. Handynummer einblendbar im Fußfeld u.a. wegen Whatsapp
Anhänge
Zuletzt bearbeitet:
Ich lege das in den Kundendaten an.
Wo der Haken bei E-Rechnung ist, geht es als E-Rechnung raus.
Ist auch schwierig, die E-Rechnung per Post zu versenden - von vielen Kunden habe ich keine Mailadresse.
easy-e-invoice
ww-pappel
Super guter Input!!! Danke
Abkürzungen: Bei denen bin ich auch nicht so happy. Beim Auswählen sieht man es ausführlich, auf der Rechnung dann aus Platzgründen kürzer. Hier wollte ich auf Feedback warten, wie deines nun
Ich muss mir da was überlegenZahlungsarten: Hab ich extra erstmal nur Überweising, da meine Zielgruppe ja eher Einzelunternhemer mit wenig Rechnungen betrifft. Meine Vermutung ist, dass der Großteil nur mit Überweisungen arbeitet
Positionsnummern: Lassen sich in den Einstellungen einblenden
Adressfeld: Ja, passt genau in ein DIN Lang Sichtfenster
Sonderfälle: Da muss ich recherchieren
Handynummer: Hier war meine Vermutung (Zielgruppe), dass eine Nummer reicht, die bestimmt zu 95% eine Handynummer ist
Screenshot: Wäre es für dich ok mir zu sagen welchen Browser (inkl. Version) und Betriebssystem du nutzt? Dann kann ich versuchen das nachtzstellen. Danke!
wirdelprumpft
ww-robinie
ZahlungsArten war von mir etwas unglücklich ausgedrückt.
10Tage/ 2% Skonto , 14 Tage netto, oder 10 Tage sofort ohne Abzug, etc und wenn das ausgewählt wird oben das Fälligkeitsdatum automatisch angepasst wird.
Firefox/Win11 beides aktuelle Version
hab einfach zahllose Positionen erstellt und irgendwann sind die ins untere Schriftfeld gerutscht.
10Tage/ 2% Skonto , 14 Tage netto, oder 10 Tage sofort ohne Abzug, etc und wenn das ausgewählt wird oben das Fälligkeitsdatum automatisch angepasst wird.
Firefox/Win11 beides aktuelle Version
hab einfach zahllose Positionen erstellt und irgendwann sind die ins untere Schriftfeld gerutscht.
pinguin1966
ww-ulme
Zurzeit sind sehr viele E-rechnungen fehlerbehaftet. Ich berate ein Unternehmen, dass bis Februar 7.000 E-Rechnungen erhalten hat. Davon war keine - keine einzige - vollständig korrekt. Sie wurden bei der ersten Vorlage alle zurückgewiesen; neu machen. Bis Ende Juni hat sich das gebessert. Die geringste Fehlerquote, die ich von einem E-Rechnungsprovider kenne ist ca. 30 % fehlerhafte Rechnungen.
Das liegt sowohl an der flaschen Umsetzung der Programmieurngsvorgaben - viele Anbieter wollen halt schnell auf dem Markt sein, als auch an der falschen Befüllung der Datenfelder duch den Rechnungssteller. Hier wäre eine eineindeutige Anleitung wirklich hilfreich. Die gibt es aber offensichtlich gerade bei preiswerten Antietern eher seltener.
Weiter oben wurde eine Validierung angesprochen. Die ist wirklich wichtig! Eine Tool, das laut Aussage von Unternehmen, die E-Rechnungen nutzen, korrekt funktioniert, ist das hier: https://valitool.org/ (Ich habe keine privaten oder geschäftlichen Verbindungen).
Ob ein QR-Code so einfach in die E-Rechnung integriert werden kann, eiß ich nicht. Die europäische Norm für elektronische Rechnungsstellung EN-16931 hat eine ganz klare Semantik. Das dürfte deshalb nach meinem Verständnis nur im Bildteil einer ZUGFeRD-Rechnung, also dem PDF gehen. Skonto ist ein echtes Problem bei E-Rechnungen. Es gibt zurzet noch keine Feldbelegung dafür. D.h. im strukturierten Teil der Rechnung ist Skonto nicht abbildbar, weder in der X-Rechnung noch in ZUGFeRD. Man kann Skonto natürlich in ein Freitextfeld schreiben. Aber dann ist keine automatisierte Verarbeitung mehr möglich und der Recnungsempfänger muss das Skonto in - der oftmals sehr unkomfortablen - Visualisierung der Rechnung erst mal finden. Es gibt auch noch einige weitere Probleme mit der E-Rechnung, z.B. die Verarbeitung von Anzahlungen und die Stellung einer Schlussrechnung.
Deshalb wird die EN-16931 zurzeit überarbeitet und solche Sachen ergänzt. ZUGFerd und X-Rechnung sind ein sog. CIUS (Core Invoice User Specification), d.h. eine Teilmenge der Norm und damit compliant. Die überarbeitete Norm wird voraussichtlich demnaächst veröffentlicht. Entscheidend ist aber, wann sie in Kraft tritt. Ab dem Zeitpunk muss sie angewendet werden und wann das sein wird, weiß zurzeit niemand. Bevor jetzt wieder das Bashing kommt, die E-Rechnung sei zu früh eingeführt worden, vergesst bitte nicht die Übergangsregeln. Niemand muss zurzeit eine E-Rechnung stellen. Jeder kann jetzt noch auch im B2B-Bereich weiter machen wie bisher. Und ohne klare Timeline wären die ganzen Unzulänglichkeiten nicht gefunden worden. Die Norm EN-16931 ist oder war bisher halt ein kleiner Kerndatensatz für B2G Rechnungen.
Mit der DSGVO kenne ich mich nicht aus. Ich verstehe aber die Hinweise darauf nicht. Es schreibt doch niemand mehr Rechnungen handschriftlich. Und niemand löscht unmittelbar nach der Rechnungsstellung die Kundendaten, egal ob eine klassische oder eine E-Rechnung gestellt wird. Damit sind m.E. die Datenschutzanforderungen nach wie vor die selben.
Das liegt sowohl an der flaschen Umsetzung der Programmieurngsvorgaben - viele Anbieter wollen halt schnell auf dem Markt sein, als auch an der falschen Befüllung der Datenfelder duch den Rechnungssteller. Hier wäre eine eineindeutige Anleitung wirklich hilfreich. Die gibt es aber offensichtlich gerade bei preiswerten Antietern eher seltener.
Weiter oben wurde eine Validierung angesprochen. Die ist wirklich wichtig! Eine Tool, das laut Aussage von Unternehmen, die E-Rechnungen nutzen, korrekt funktioniert, ist das hier: https://valitool.org/ (Ich habe keine privaten oder geschäftlichen Verbindungen).
Ob ein QR-Code so einfach in die E-Rechnung integriert werden kann, eiß ich nicht. Die europäische Norm für elektronische Rechnungsstellung EN-16931 hat eine ganz klare Semantik. Das dürfte deshalb nach meinem Verständnis nur im Bildteil einer ZUGFeRD-Rechnung, also dem PDF gehen. Skonto ist ein echtes Problem bei E-Rechnungen. Es gibt zurzet noch keine Feldbelegung dafür. D.h. im strukturierten Teil der Rechnung ist Skonto nicht abbildbar, weder in der X-Rechnung noch in ZUGFeRD. Man kann Skonto natürlich in ein Freitextfeld schreiben. Aber dann ist keine automatisierte Verarbeitung mehr möglich und der Recnungsempfänger muss das Skonto in - der oftmals sehr unkomfortablen - Visualisierung der Rechnung erst mal finden. Es gibt auch noch einige weitere Probleme mit der E-Rechnung, z.B. die Verarbeitung von Anzahlungen und die Stellung einer Schlussrechnung.
Deshalb wird die EN-16931 zurzeit überarbeitet und solche Sachen ergänzt. ZUGFerd und X-Rechnung sind ein sog. CIUS (Core Invoice User Specification), d.h. eine Teilmenge der Norm und damit compliant. Die überarbeitete Norm wird voraussichtlich demnaächst veröffentlicht. Entscheidend ist aber, wann sie in Kraft tritt. Ab dem Zeitpunk muss sie angewendet werden und wann das sein wird, weiß zurzeit niemand. Bevor jetzt wieder das Bashing kommt, die E-Rechnung sei zu früh eingeführt worden, vergesst bitte nicht die Übergangsregeln. Niemand muss zurzeit eine E-Rechnung stellen. Jeder kann jetzt noch auch im B2B-Bereich weiter machen wie bisher. Und ohne klare Timeline wären die ganzen Unzulänglichkeiten nicht gefunden worden. Die Norm EN-16931 ist oder war bisher halt ein kleiner Kerndatensatz für B2G Rechnungen.
Mit der DSGVO kenne ich mich nicht aus. Ich verstehe aber die Hinweise darauf nicht. Es schreibt doch niemand mehr Rechnungen handschriftlich. Und niemand löscht unmittelbar nach der Rechnungsstellung die Kundendaten, egal ob eine klassische oder eine E-Rechnung gestellt wird. Damit sind m.E. die Datenschutzanforderungen nach wie vor die selben.
Ob Du`s glaubst oder nicht. Gelegentlich bestelle ich was bei Würth. Der Lieferschein kommt per Mail.
Die Rechnung kommt mit der POST ...
pinguin1966
ww-ulme
Ja, aber doch nicht handgeschrieben, oder?Das ist aber dennoch bemerkenswert. Auf den letzten E-Rechnungsgipfeln hat gerade Würht mehrere Präsentationen gehalten, in denen sie eine eigentlich sehr gute Einbindung der E-Rechnung auch für den Kunden präsentiert haben.
Als ich heute früh #109 gelesen hatte, zauberte mir die Tatsache, dass die Skonto-Geschichte wohl vom Normungsgremium schlicht vergessen wurde, wieder ein Grinsen ins Gesicht. Vor allem, weil ich vor längerer Zeit schon einmal den (deutschen?) Ansatz aufgeschnappt hatte, in "Payment terms" - eigentlich der "Prosateil" einer eRechnung - dafür eine zusätzliche Struktur zu etablieren. Komischer Ansatz meiner bescheidenen Meinung nach.
Ich frage mich - auch bei anderen Normierungen in völlig anderen Bereichen - ob es nicht sinnvoll wäre, im Normungsprozess ein bisschen Geld dafür auszugeben, dass man ein paar ausgewählte tasächlich wirtschaftlich agierende Anwender dafür bezahlt, dass sie solche Dinge schon in einer frühen Phase auf Praxistauglichkeit parallel zu ihren etablierten Prozessen testen.
Also, der "Skontofall", bin ich mir sicher, wäre wohl schnell aufgefallen.
Girocodes in einer Rechnung abzubilden ist meiner Meinung nach ja eher im B2C-Umfeld nützlich. Der QR-Code besteht ja nur aus rund einem Dutzend Zeilen und symbolisiert nichts anderes, als die Daten einer anzulegenden Sepa-Überweisung.
Im B2B-Umfeld werden wohl die wenigsten den scannen... zumal die eRechnung ja gerade auch dazu führen soll, solche Prozesse voll digital zu gestalten.
Zumindest momentan ist ist der DSGVO-Hinweis natürlich in den meisten Fällen obsolet, weil im B2B-Bereich meist keine personengebundenen Daten natürlicher Personen verarbeitet werden. Aber selbst da - so scheint die Rechtssprechung momentan zu sein - kann man schon mit einem Rechnungsempfänger a la "XYZ GmbH, Zentraleinkauf - z.Hd. Herrn Max Mustermann" dann doch wieder in deren Geltungsbereich sein.
Ích hab' ja aber auch nicht insistiert, dass das ein Showblocker sein muss, sondern habe lediglich darauf hingewiesen, dass man das zumindest einmal juristisch abklopfen lassen sollte. Das hat Jan ja aufgenommen. Insofern muss das imho ja auch nicht weiter debattiert werden.
Funfact am Rande... Solche Auftragsverarbeitung-Vertragskonstrukte kenne ich sogar für hundertprozentige Tochterfirmen der Gesellschaft... und finde spätestens das ein bisschen übertrieben. Die Juristen sahen es aber anders.
Ich frage mich - auch bei anderen Normierungen in völlig anderen Bereichen - ob es nicht sinnvoll wäre, im Normungsprozess ein bisschen Geld dafür auszugeben, dass man ein paar ausgewählte tasächlich wirtschaftlich agierende Anwender dafür bezahlt, dass sie solche Dinge schon in einer frühen Phase auf Praxistauglichkeit parallel zu ihren etablierten Prozessen testen.
Also, der "Skontofall", bin ich mir sicher, wäre wohl schnell aufgefallen.
Girocodes in einer Rechnung abzubilden ist meiner Meinung nach ja eher im B2C-Umfeld nützlich. Der QR-Code besteht ja nur aus rund einem Dutzend Zeilen und symbolisiert nichts anderes, als die Daten einer anzulegenden Sepa-Überweisung.
Im B2B-Umfeld werden wohl die wenigsten den scannen... zumal die eRechnung ja gerade auch dazu führen soll, solche Prozesse voll digital zu gestalten.
Zumindest momentan ist ist der DSGVO-Hinweis natürlich in den meisten Fällen obsolet, weil im B2B-Bereich meist keine personengebundenen Daten natürlicher Personen verarbeitet werden. Aber selbst da - so scheint die Rechtssprechung momentan zu sein - kann man schon mit einem Rechnungsempfänger a la "XYZ GmbH, Zentraleinkauf - z.Hd. Herrn Max Mustermann" dann doch wieder in deren Geltungsbereich sein.
Es ging darum, dass die DSGVO nicht nur die Verantwortlichkeiten der unmittelbar Beteiligten, also Auftraggeber und Auftragnehmer, festlegt, sondern auch dafür sorgt, dass auch der komplette "Rattenschwanz" zusätzlicher Beteiligter Berücksichtigung findet. Sprich: Wenn der Auftragnehmer sich an irgendeiner Stelle des Prozesses eines Dienstleisters bedient, muss er in der Regel mit diesem einen Vertrag zur Auftragsverarbeitung abschliessen.... und diesen auch gegenüber dem Auftraggeber benennen. In dem Fall wäre Jan mit seiner Webapplikation der Auftragsverarbeiter... der allerdings seine Nutzer mangels Registrierungspflicht gar nicht kennen würde. Und der Auftragnehmer, der die Dienstleistung in Anspruch nimmt, hätte im Fall der Fälle keinen Vertrag über die Auftragsverarbeitung vorzuweisen.
Ích hab' ja aber auch nicht insistiert, dass das ein Showblocker sein muss, sondern habe lediglich darauf hingewiesen, dass man das zumindest einmal juristisch abklopfen lassen sollte. Das hat Jan ja aufgenommen. Insofern muss das imho ja auch nicht weiter debattiert werden.
Funfact am Rande... Solche Auftragsverarbeitung-Vertragskonstrukte kenne ich sogar für hundertprozentige Tochterfirmen der Gesellschaft... und finde spätestens das ein bisschen übertrieben. Die Juristen sahen es aber anders.
wirdelprumpft
ww-robinie
Die Fa. Würth hat ein QR - Code auf der Rechnung den nutze ich tatsächlich ab und an ist zwar etwas umständlich da Würthapp und Paypal aber irgendwie immer noch schneller als über Online-Banking
Bis auf ein Holzlieferant verschicken alle meine Lieferanten PDF - Rechnungen ob das e-Rechnungen sind müsste ich mal überprüfen.
Bis auf ein Holzlieferant verschicken alle meine Lieferanten PDF - Rechnungen ob das e-Rechnungen sind müsste ich mal überprüfen.
pinguin1966
ww-ulme
Ein PDF allein ist keine E-Rechnung. Dafür muss ein strukturierter Datensatz wie bei ZUGFeRD eingebettet sein.
Dale_B_Cooper
ww-robinie
<sorry>
Dale_B_Cooper
ww-robinie
Juristen sehen das immer das halt immer wie.. Juristen.
Bei uns hat das ausgereicht mit der Tochterfirma und ist auch geprüft worden, also vom Datenschutzbeauftragten der Kundenpartei, der auch Anwalt ist. Hängt aber sicherlich von den Beteiligungsverträgen ab.
Schön ist ja, dass alle Juristen, die ich kenne, selber den Spruch bringen oder zumindest dazu schmunzeln können: Zwei Juristen, drei fundierte Meinungen.
Dale_B_Cooper
ww-robinie
Solange andere dafür zahlen.. (ja, ich mag keine Juristen..)
Was Juristen sagen, ist genauso wenig immer richtig wie das, was Tischler hier erzählen.
