Fortlaufende lückenlose Rechnungsnummern

[IBExpert]

Moin,

ich war heute beim Delphitreff in Köln eingeladen und da gab es neben diversen anderen hochinteressanten Diskussionsthemen auch ein Thema, was sicherlich auch viele hier in der dp interessiert.

Es geht um das leidige Thema fortlaufende lückenlose Rechnungsnummern. Das einzige Problem bei der Vergabe fortlaufender lückenloser Rechnungsnummern ist wohl in erster Linie die fehlende Fortbildung der Finanzamtsprüfer bezgl. Entscheidungen im eigenen Haus und das Steuerberater auch nicht immer alles wissen.

Eine solche Regel, das Rechnungsnummern fortlaufend lückenlos sein müssen, gibt es nämlich nicht.

Da aber ein Prüfer, der einfach das Gegenteil behauptet, sich nicht so einfach mit Behauptungen oder Einträgen in irgenwelchen Internetforen überzeigen lässt, hier eine konkrete Quelle, mit der jeder Eurer Kunden das Diskussionsthama umgehend beenden kann. Auch die Aussagen von irgendwelchen Steuerberatern könnt Ihr damit abschmettern und Ihr könnt die Arbeit in sinnvolle Programmfunktionen investieren. Das gilt schon seit 2011, wurde erstmalig aber schon 2008 in Koblenz von der Oberfinanzdirektion schriftlich festgelegt.

bundesfinanzministerium Umsatzsteuer-Anwendungserlass Stand-31-12-2011

Seite 506:

Fortlaufende Nummer (Rechnungsnummer)
(10) 1 Durch die fortlaufende Nummer (Rechnungsnummer) soll sichergestellt werden, dass die vom
Unternehmer erstellte Rechnung einmalig ist.
2 Bei der Erstellung der Rechnungsnummer ist es zulässig, eine
oder mehrere Zahlen- oder Buchstabenreihen zu verwenden.
3 Auch eine Kombination von Ziffern mit
Buchstaben ist möglich.
4 Eine lückenlose Abfolge der ausgestellten Rechnungsnummern ist nicht zwingend.
5 Es ist auch zulässig, im Rahmen eines weltweiten Abrechnungssystems verschiedener, in unterschiedlichen Ländern
angesiedelter Konzerngesellschaften nur einen fortlaufenden Nummernkreis zu verwenden.
(11) 1 Bei der Erstellung der Rechnungsnummer bleibt es dem Rechnungsaussteller überlassen, wie viele und
welche separaten Nummernkreise geschaffen werden, in denen eine Rechnungsnummer jeweils einmalig
vergeben wird. 2 Dabei sind Nummernkreise für zeitlich, geographisch oder organisatorisch abgegrenzte Bereiche
zulässig, z.B. für Zeiträume (Monate, Wochen, Tage), verschiedene Filialen, Betriebsstätten einschließlich
Organgesellschaften oder Bestandsobjekte.
3 Die einzelnen Nummernkreise müssen dabei nicht zwingend
lückenlos sein.
4 Es muss jedoch gewährleistet sein (z.B. durch Vergabe einer bestimmten Klassifizierung für
einen Nummernkreis), dass die jeweilige Rechnung leicht und eindeutig dem jeweiligen Nummernkreis
zugeordnet werden kann und die Rechnungsnummer einmalig ist.

Wem damit geholfen ist, der darf mir auf den Delphi Tagen ein Bier ausgeben :-)

[mm1256]

Zitat:

Zitat von IBExpert (Beitrag 1306917)

Wem damit geholfen ist, der darf mir auf den Delphi Tagen ein Bier ausgeben :-)

Das mit dem Bier können wir so machen. Ich werde auch da sein.

Allerdings ist die Angelegenheit nicht ganz so rund wie es den Anschein hat. Wenn ein Betriebsprüfer Lücken in den Rechnungsnummernkreisen findet (ich verwende bewusst den Plural, weil sich bei nicht lückenlosen Rechnungsnummern zwangsläufig mehrere Nummernkreise ergeben) dann läuten bei ihm erst mal die Alarmglocken. Die Glocken klingen erst dann langsam aus, wenn für mehrere Nummernkreise ein offensichtlicher Anlass gegeben ist, z.B. das Ausstellungsjahr als Präfix.

Sind die Nummern innerhalb eines Nummernkreises fortlaufend und lückenlos, ist das i.d.R. nicht verdächtig. Fehlen aber Nummern, schauen die Betriebsprüfer sehr genau nach, was die Ursachen sind. Spätestens dann werfen die Betriebsprüfer auch einen Blick auf die verwendete Software. Stellt diese die Möglichkeit lückenloser Belegnummernvergabe zur Verfügung, zerlegen die Betriebsprüfer die komplette Buchhaltung. Dabei kommt es auch zu vollständigem Einblick in alle beteiligten Programme. Was die Prüfer dabei alles prüfen, kontrollieren, nachrechnen usw. übersteigt oftmals das Vorstellungsvermögen der Anwender.

Und, sie werden in der Regel auch fündig. Klar, die Daseinsberechtigung muss abgegeben werden. Er muss etwas finden und die Frage ist lediglich, wo er beginnt, und welchen Aufwand er betreiben muss :stupid:

Lückenhafte Nummernkreise sind darum geradezu eine Einladung an dieser Stelle mit der Suche zu beginnen. Die Frage aus Sicht des Anwenders ist also, wie halte ich es mit lückenhaften Nummernkreisen und dem sich daraus ergebenden "Generalverdacht"?

Aus rein rechtlicher Sicht stimme ich deinen Ausführungen vollständig zu. Die Praxis zeigt aber, dass es gute, vernünftige, und aus Anwendersicht auch lohnende Argumente für die Verwendung lückenloser Belegnummern gibt. Darum habe ich beispielsweise ungeachtet der Rechtslage in meiner SW ein eingebautes "Warnsystem" das den Anwender vor Lücken in den Belegnummern warnt. Wobei ich hier bewusst den Begriff "Belegnummern" verwende, und nicht "Rechnungsnummern", denn man ist aufgrund der Rechtslage (Stichwort "Stornierung von Belegen") gut beraten, wenn man für den Belegausgang (Rechnungen, Gutschriften, Abschlagsrechnungen, Stornierungen...) einen einzigen lückenlosen Nummernkreis generiert.

Aus datenbanktechnischer Sicht sind lückenlose Belegnummern kein Problem und darum sollte vielleicht die Frage erlaubt sein, warum man es als Entwickler/Programmierer/SW-Hersteller nicht tun sollte?

[haentschman]

Moin...:P
Eigentlich mußt du mir ein Bier ausgeben. 8-) Du hast meine Lüge an meine Frau auffliegen lassen. Vor ein paar Tagen hatten wir das Thema. Schon erstaunlich, dieses "Gerücht" philosophiere ich schon seit Jahren. :wall:
Nachtrag:
Das "Generalverdacht" Argument hat auch seine Berechtigung.

[IBExpert]

Zitat:

Sind die Nummern innerhalb eines Nummernkreises fortlaufend und lückenlos, ist das i.d.R. nicht verdächtig. Fehlen aber Nummern, schauen die Betriebsprüfer sehr genau nach, was die Ursachen sind.

Und wie wehrt man sich dagegen? Ganz einfach, es sind immer ungleiche Lücken zwischen den Rechnungsnummern, weil zum Beispiel jede neue Rechnungsnummer um random(xxx) erhöht wird.

Da es keiner verbietet, seine Rechnung auch mit word oder excel zu schreiben und sich die "Rechnungsnummer" auch komplett auszdenken, muss man dem Prüfer, der entgegen der Anweisung von seiner eigenen Behörde handelt, ja kein Ansatzpunkt bieten.

Warum sollte ein kleiner freiberuflicher Programmierer mit wenigen Kunden seinem Kunden durch die lückenlose Rechnungsnummer direkt klar machen, das er gar keine anderen Kunden hat und von Ihm als einzige Einnahmequelle abhängig ist?

Also schreibt man auf die Rechnung gar keine Rechnungsnummer, sondern nutzt als eindeutige Identifikation zum Beispiel das Tagesdatum mit einem suffix -01 oder so. Da viele Freiberufler gar nicht täglich eine Rechnung schreiben, bleiben da reichlich Lücken.

Aber auch als Onlinehändler schafft das nicht gerade vertrauen, wenn du Mitte des Jahres die Rechnungsnummer *00099 erzeugst. Daraus würde ich direkt den Schluss ziehen, das es im ganzen Jahr nicht mehr als 99 Verkäufe gab. Bei dem Verkäufer würde ich nicht noch mal kaufen, da er aufgrund der geringen Verkaufszahl sicherlich in ein paar Wochen seinen Shop dicht machen muss, also ich auf Gewährleistungsansprüche sitzen bleibe, weil man davon nicht leben kann. Ob der überhaupt davon leben muss oder einen Laden betreibt, in dem er deutlich mehr als online verkauft, aber andere Nummernkreise benutzt, kann man nicht erkennen.

Wenn du die Erfahrung mit Betriebsprüfern hast, das die entegen der Anweisung vom Finanzministerium trotzdem irgendwelche Interpretationen in kückenhafte Nummernkreise haben, sollte man den einfach den Wind aus den Segeln nehmen und konsequent für nicht nachvollziehbare Lücken sorgen, denn das ist explizit erlaubt!

[Mavarik]

Zitat:

Zitat von mm1256 (Beitrag 1306924)

Aus datenbanktechnischer Sicht sind lückenlose Belegnummern kein Problem und darum sollte vielleicht die Frage erlaubt sein, warum man es als Entwickler/Programmierer/SW-Hersteller nicht tun sollte?

Doch genau das ist es... Daher resultiert auch der Einwurf von IBExpert

Zitat:

Zitat von IBExpert (Beitrag 1306917)

ich war heute beim Delphitreff in Köln eingeladen und da gab es neben diversen anderen hochinteressanten Diskussionsthemen auch ein Thema, was sicherlich auch viele hier in der dp interessiert.

Danke für Dein kommen!

Wo liegt das Problem? Ganz Einfach.

Gegeben Sei Büro A und Büro B... Bei Büros verbinden sich mit dem gleichen Server auf dem die Rechnungsdatenbank liegt.

Natürlich muss sicher gestellt werden, dass die Büros arbeiten können, auch wenn keine Internetverbindung besteht... Hierfür wird ein lokaler Server verwendet der sich mit dem zentralen Server synchronisiert...

Wenn also die Internetverbindung fehlt, gibt es keine Vergabestelle für die zentrale Rechnungsnummer.

Daher getrennte Rechnungsnummernkreise...

Mavarik

[IBExpert]

Zitat:

Aus datenbanktechnischer Sicht sind lückenlose Belegnummern kein Problem und darum sollte vielleicht die Frage erlaubt sein, warum man es als Entwickler/Programmierer/SW-Hersteller nicht tun sollte?

Sogar wenn du nur eine Quelle für deine Nummernvergabe hast, entsteht bei Installationen mit mehreren Clients eine gewisse Wahrscheinlichkeit, das irgendwann mal 2 Clients gleichzeitig eine neue Rechnung erzeugen und in beiden Programmen der Wert der letzten Rechnungsnummer auf Basis des aktuellen Werts +1 ermittelt wird.

Beide haben aber vielelicht schon erfolgreich per update den letzten Wert je um 1 erhöht, abermindestens einer bekommt beim Speichern wegen einem Unique Index auf der Rechnungsnummer in der Datenbank eine Exception.

Wenn der durch die Exception dann den Vorgang einfach noch mal macht, ist eine Lücke in den Rechnungsnummern. Diese dann generell wieder aufzufüllen mit der noch fehlenden Rechnungssnummer ist zwar eine nette Idee, aber spätestens bei Jahreswechsel eine sehr blöde Idee. Ob das durch deine Datenbank serialisiert wird und durch Transaktionen sauber abgearbeitet wird oder du andere Techniken eingebaut hast, sei hier jetzt mal offen, natürlich lässt sich so was pro Server mehr oder weniger sauber realisieren, insbesondere wenn der Transaktionen unterstützt. Es bleibt aber dabei, das die bewusste Einplanung von Lücken da eine Menge Arbeit einspart.

Und es gibt durchaus Systeme, da reden wir nicht über 2 oder 3 Rechner, an denen Rechnungen geschrieben werden, sondern wo dutzende Abteilungen im Unternehmen verteilt das machen. Die Chance, das es dann knallt, steigt sehr schnell an. Und wenn die dann noch an unterschiedlichen Standorten verteilt sind, sind Nummerkreise pro Standort sowieso erforderlich, um die Forderung nach Eindeutigkeit erfüllen zu können. Eine Forderung der Lückenlosigkeit gibt es aber nicht.

[Phoenix]

Sagen wir es mal so:

Seit Jahren vergebe ich Rechnungsnummern immer yyyymmdd/xxx wobei xxx meist 001 ist, und falls ich doch mal mehrere Rechnungen an einem Tag schreibe habe ich für 998 andere Platz :)

Noch nie hat ein Prüfer darüber gemeckert.

[mkinzler]

Dann hast Du für jeden Tag einen Nummernkreis, und der ist wieder lückenlos.

[Dejan Vu]

Also rein technisch sollte sich das durch den entsprechenden Isolation Level lösen lassen. Aber darum geht es ja nicht, sondern darum, ob man sich die Mühe machen sollte. Denn entweder bekommt man es 100% hin (dann schadet es nicht und erleichtert die Arbeit des Prüfers), oder man bekommt es nicht hin. Dann sollte man es aber auch nicht versuchen, weil dann der Prüfer ins Grübeln kommt.

Ich habe immer das Tagesdatum genommen. Eine GUID hätte aber auch etwas sehr charmantes. Man könnte sich auch z.B. die Liste aller Top-10 Hits der letzten 50 Jahre aus Indien nehmen und vergeben, das wäre doch lustig: "Bitte überweisen Sie den Betrag unter Angabe der Rechnungsnummer:"Phir Se Ud Chala / Mohit Cauhan" bis zum 29.6.2015... :-D

[Sir Rufo]

Lückenlose Rechnungsnummern sind kein Problem, wenn man sich vorher Gedanken macht.

Auch bei unterschiedlichen Standorte die nur zeitweise Kontakt zum Haupt-Server haben ist das realisierbar. Indem jeder Standort seinen eigenen Nummernkreis hat. Dieses wird tagtäglich auf der ganzen Welt benutzt und jeder ist damit schon in Berührung gekommen.

Einfach mal in eine Tankstelle (oder wo auch immer) und eine Packung Kaugummis (oder was auch immer) kaufen.

Dann einen Blick auf die Bon-Nummer werfen.

Wer glaubt denn jetzt, dass die Kassen erst eine Verbindung mit irgendeinem Server herstellen um die korrekte Bon-Nummer zu erzeugen?

Gut - ich auch nicht.

Zum Dilemma fortlaufende Nummer - Information an den Kunden - Betriebsprüfer:

Auch dieses Problem ist einfach zu lösen:

Da die Rechnungsnummer nicht zwangsläufig numerisch sein muss, kann man also die echte (fortlaufende) Nummer dadurch verstecken, dass man aus der Nummer und der Uhrzeit eine neue Nummer bildet und diese dann entsprechend kodiert. Die Rechnungsnummern sehen dann so aus, wie auf den amazon Rechnungen. (Eine Prüfziffer kann man auch noch implementieren)

Dem Betriebsprüfer gibt man dann den Algorithmus an die Hand, mit dem er nachprüfen kann, dass es keine Lücken gibt. Der Kunde kann aber anhand der ihm mitgeteilten Rechnungsnummer nicht auf die Anzahl der bisher geschriebenen Rechnungen schliessen.

Eindeutig sind diese Rechnungsnummern auch, selbst wenn zum gleichen Zeitpunkt mehrere Rechnungen geschrieben werden.

[bernau]

Zitat:

Zitat von IBExpert (Beitrag 1306917)

ich war heute beim Delphitreff in Köln eingeladen

Der Vollständigkeit halber, hier noch der Link zum Delphitreff.

http://wiki.delphitreff.de/usertreffen/20150627

[jaenicke]

Zitat:

Zitat von IBExpert (Beitrag 1306928)

Wenn du die Erfahrung mit Betriebsprüfern hast, das die entegen der Anweisung vom Finanzministerium trotzdem irgendwelche Interpretationen in kückenhafte Nummernkreise haben, sollte man den einfach den Wind aus den Segeln nehmen und konsequent für nicht nachvollziehbare Lücken sorgen, denn das ist explizit erlaubt!

Oder man sorgt dafür, dass sie lückenlos sind und gibt damit ein Argument dafür, dass alles in Ordnung ist.
Und in anderen Ländern geht es anders sowieso nicht. In Portugal und ein paar anderen Ländern ist die lückenlose Vergabe der Rechnungsnummern gesetzlich vorgeschrieben und teilweise sogar die Gestaltung der Nummernkreise.

[mquadrat]

Das Problem bei lückenlosen Nummern ist aus meiner Erfahrung weniger die Software, sondern der Anwender. "Das wollte ich gar nicht". Wir vergeben unsere RE-Nummern schon so spät wie möglich, aber sobald der Benutzer mal einen Info-Druck macht oder die RE-Erfassung verlässt, kriegt das Ding eine ´Nummer. Zumindest die Diskussionen mit Kunden, die ich geführt habe, gingen alle in die Richtung "da hab ich dann lieber ne Lücke".

[Sir Rufo]

Zitat:

Zitat von mquadrat (Beitrag 1306981)

Das Problem bei lückenlosen Nummern ist aus meiner Erfahrung weniger die Software, ...

Nein, in den meisten Fällen liegt es einfach an der Software.

Überlegen wir uns doch mal, wie es früher war - ohne Computer.

Da gab es ein Buch in denen die Belegnummer festgehalten wurden. Immer dann, wenn ein Beleg fertig war (also wirklich fertig, so wie er sein soll, Ready for shipping) wurde in dem Buch die nächste Belegnummer in eine Liste geschrieben und dann auf den Beleg. Der Beleg wurde als gebucht.

Sodele und was hindert die Software es genau so zu handhaben? Also einem Beleg erst dann zu buchen, wenn der Anwender das sagt?

Aber genau da stolpern einige Anwendungen. Da wird die Belegnummer vergeben, wenn einfach nur ein neuer Beleg angefangen wird oder zwischengeparkt oder mal eben in der Vorschau angezeigt werden soll.

Nur wieso das so passiert und nicht wie es eigentlich korrekt wäre ...

weil es einfacher zu programmieren ist. Das ist der Grund.

[baumina]

Früher wurde in den Büchern die Belegnummer auch wieder durchgestrichen, wenn der Azubi halt mal wieder alles verkehrt gemacht hatte.

[bernau]

Will nur mal darauf hinweisen, daß es bei der ursprünglichen Diskussion im Delphitreff nicht um das "WIE" der Rechnungsnummernerzeugung ging. Ich glaube, das können die meisten. Sondern es geht um den Fakt, daß es rechtens ist, einen unvollständigen Nummernkreis zu haben. Hauptsache die Nummern sind eindeutig.

Wir haben allerdings auch darüber diskutiert, wie es machbar ist einen lückenlosen Nummernkreis sicher zu stellen. Und das bei zwei Filialen deren Internetverbindung zueinander ggf. unterbrochen ist.

[mquadrat]

Zitat:

Zitat von Sir Rufo (Beitrag 1306982)

Nur wieso das so passiert und nicht wie es eigentlich korrekt wäre ...

weil es einfacher zu programmieren ist. Das ist der Grund.

Da widerspreche ich. Ein Schalter für das Erzeugen der Nummer ist programmiertechnisch in keinster Weise anspruchsvoll. Zumindest unsere Kunden möchten aber einfach keinen Schalter drücken müssen (das Argument ist dann immer, dass man das ja auch vergessen könne und dann würde man sein Geld nicht kriegen). Außerdem werden Prüfer erst richtig nervös, wenn sie einen Rechnungsbeleg ohne Rechnungsnummer irgendwo rumliegen sehen. Da hilft auch das "das ist aber noch nicht fertig" vom Sachbearbeiter nichts. Die Aussage von unserem FA war: "sobald es den Beleg in Papierform gibt, muss auch ne Nummer drauf sein".

Interessant finde ich die Idee mit dem Durchstreichen. Damit kann man sowohl die lückenlose Nummernvergabe dokumentieren, als auch das "Wegwerfen" der Rechnung.

[rapante]

Zitat:

Zitat von Sir Rufo (Beitrag 1306982)

Sodele und was hindert die Software es genau so zu handhaben? Also einem Beleg erst dann zu buchen, wenn der Anwender das sagt?

Wenn es nur immer so einfach wäre...
Der Anwender schreibt seine Rechnung, klickt auf "buchen", und erzeugt die Nummer (Beleg ist nicht mehr änderbar und wird an die Buchhaltung übergeben). 2 Sekunden später fällt ihm ein, dass er etwas vergessen oder falsch eingegeben hat. Es ist dann müßig ihm zu erklären, dass er erst eine Gutschrift erzeugen und eine neue Rechnung erstellen muss, weil es im Nummernsystem keine Lücken geben darf...

[Perlsau]

Posting gelöscht wegen eben via anonymer Email erhaltener Drohung vermutlich von einem hiesigen User, mich bei meinem zuständigen Finanzamt anzuzeigen.

[baumina]

Zitat:

Zitat von Perlsau (Beitrag 1306989)

Wenn ich eine Rechnung ausstelle, die nicht bezahlt wird, kann ich diese Rechnung nicht beim Finanzamt als Beleg für meine Einnahmen einreichen (Kleingewerbler = nur Einnahmen-Überschuß-Rechnung). Ergo storniere ich die Rechnung und weise die freigewordene Nummer der nächsten Rechnung zu. So habe ich stets fortlaufende Rechnungs- und Belegnummern und hatte noch nie irgendwelche Nachfragen oder Einwände vom Finanzamt.

Rechnungsnummer-Lücken wieder auffüllen, auch ne lustige Variante :thumb:

[bernau]

Zitat:

Zitat von Perlsau (Beitrag 1306989)

Wenn ich eine Rechnung ausstelle, die nicht bezahlt wird, kann ich diese Rechnung nicht beim Finanzamt als Beleg für meine Einnahmen einreichen (Kleingewerbler = nur Einnahmen-Überschuß-Rechnung). Ergo storniere ich die Rechnung und weise die freigewordene Nummer der nächsten Rechnung zu. So habe ich stets fortlaufende Rechnungs- und Belegnummern und hatte noch nie irgendwelche Nachfragen oder Einwände vom Finanzamt.

Du spielst mit dem Feuer ;-)

Wenn du die Rechnung versendet hast, dann musst du immer damit Rechnen, daß diese auch beim Finanzamt von der Gegenseite eingereicht wird. Selbst wenn die nicht bezahlt wurde. Damit hast du dann zwei Rechnungen mit der gleichen Rechnungsnummer ausgestellt. Uiuiui.

[mkinzler]

Dann hoffe ich mal für Dich, dass Dein Kunde, die Rechnung, die er nicht bezahlt hat dann auch vernichtet.

[Perlsau]

Posting gelöscht wegen eben via anonymer Email erhaltener Drohung vermutlich von einem hiesigen User, mich bei meinem zuständigen Finanzamt anzuzeigen.

[BadenPower]

Zitat:

Zitat von rapante (Beitrag 1306988)

Es ist dann müßig ihm zu erklären, dass er erst eine Gutschrift erzeugen und eine neue Rechnung erstellen muss, weil es im Nummernsystem keine Lücken geben darf...

Das mußt Du dem Anwender nicht erklären, Du mußt ihm erklären, weshalb Dein Programm, für welches er Dich bezahlt hat, keine Storno-Funktion hat.

[mm1256]

Zitat:

Zitat von BadenPower (Beitrag 1306998)

Zitat:

Zitat von rapante (Beitrag 1306988)

Es ist dann müßig ihm zu erklären, dass er erst eine Gutschrift erzeugen und eine neue Rechnung erstellen muss, weil es im Nummernsystem keine Lücken geben darf...

Das mußt Du dem Anwender nicht erklären, Du mußt ihm erklären, weshalb Dein Programm, für welches er Dich bezahlt hat, keine Storno-Funktion hat.

So sieht es aus :thumb:

Die Beiträge #21 und #22 sind aus diesem Grund als spekulativ anzusehen, denn Perlsau hat geschrieben "Ergo storniere ich die Rechnung...". Wenn man davon ausgeht, dass er eine Rechnung "ordnungsgemäß" storniert (ich gehe mal davon aus, dass die hier Schreibenden wissen, wie man eine Rechnung seit Januar 2013 ordnungsgemäß stornieren muss), dann ist die Vorgehensweise absolut in Ordnung.

Zitat:

Zitat von rapante (Beitrag 1306988)

.....Es ist dann müßig ihm zu erklären, dass er erst eine Gutschrift erzeugen und eine neue Rechnung erstellen muss, weil es im Nummernsystem keine Lücken geben darf...

Die Formulierung "eine Gutschrift erzeugen..." zeigt schon, dass es mit deinem Kenntnisstand, wie eine Rechnung zu stornieren ist, nicht weit her ist. Um die Mitlesenden nicht zu verwirren und dem Thread nicht ein Minimum an Wahrheitsgehalt zu nehmen, sollte man wenigstens die Gesetzeslage kennen.

[Lemmy]

Zitat:

Zitat von Perlsau (Beitrag 1306997)

Ich kann jederzeit nachweisen, daß die Rechnung nicht bezahlt und daher storniert wurde.

nicht unbedingt.. wurde die Rechnung vielleicht bar bezahlt? ;-)

Fakt ist: Das FA sieht als aller erstes nur deinen Namen und dass Du 2 Rechnungen mit der selben Rechnungsnummer geschrieben hast. Ergo: Außenprüfung bei dir! Da interessiert dann niemanden dass Du nicht schuld bist - du hast den Aufwand und ggf. die Prüfung am Hals!

Deshalb: Nie eine Rechnungsnummer mehrfach verwenden sobald die das Haus verlassen hat...

Grüße

[Mavarik]

Lücken auffüllen geht schon nicht wegen dem Rechnungsdatum - es sei den Du patchst das auch auf das Datum der vorhergehenden Rechnung. :evil:

Rechnungen die das Haus verlassen haben werden nicht storniert, sondern dafür wird eine Gutschrift erzeugt... Besonders, wenn die UmSt. dafür schon bezahlt wurde (weil in anderem Monat).

[mkinzler]

Wobei hier der Begriff "Gutschrift" missvertanden werden kann. Ich würde es eher Stornorechnung o.ä. nennen.

[mm1256]

Zitat:

Zitat von Mavarik (Beitrag 1307003)

Rechnungen die das Haus verlassen haben werden nicht storniert, sondern dafür wird eine Gutschrift erzeugt... Besonders, wenn die UmSt. dafür schon bezahlt wurde (weil in anderem Monat).

Bleibt doch bitte bei der Sachlage: Das Erstellen einer Gutschrift zum Stornieren einer Rechnung ist nicht zulässig!

[Perlsau]

Posting gelöscht wegen eben via anonymer Email erhaltener Drohung vermutlich von einem hiesigen User, mich bei meinem zuständigen Finanzamt anzuzeigen.

[vagtler]

Zitat:

Zitat von Perlsau (Beitrag 1306997)

[...] Das soll sich mal einer trauen: Eine Rechnung, die er nicht bezahlt hat, als steuermindernde Ausgabe geltend machen. Das wäre Betrug und er würde sich damit selbst ins Knie schießen. Deshalb muß ich damit nicht wirklich rechnen, und schon gar nicht jederzeit. [...]

Natürlich musst Du das. Bei einer doppelten Buchführung kann z.B. der Aufwand schon erfasst worden sein bevor kurz darauf die Zahlungsunfähigkeit eintritt. In diesem Fall würdest sogar Du mit dieser Verschleierung eine strafbare Handlung begehen, da Du hier Deine Steuerlast zu kürzen versuchst.

[bernau]

Zitat:

Zitat von mm1256 (Beitrag 1307000)

Die Beiträge #21 und #22 sind aus diesem Grund als spekulativ anzusehen, denn Perlsau hat geschrieben "Ergo storniere ich die Rechnung...". Wenn man davon ausgeht, dass er eine Rechnung "ordnungsgemäß" storniert (ich gehe mal davon aus, dass die hier Schreibenden wissen, wie man eine Rechnung seit Januar 2013 ordnungsgemäß stornieren muss), dann ist die Vorgehensweise absolut in Ordnung.

Lies noch mal, was Perlsau schrieb

Zitat:

Zitat von Perlsau (Beitrag 1306989)

Wenn ich eine Rechnung ausstelle, die nicht bezahlt wird, kann ich diese Rechnung nicht beim Finanzamt als Beleg für meine Einnahmen einreichen (Kleingewerbler = nur Einnahmen-Überschuß-Rechnung). Ergo storniere ich die Rechnung und weise die freigewordene Nummer der nächsten Rechnung zu. So habe ich stets fortlaufende Rechnungs- und Belegnummern und hatte noch nie irgendwelche Nachfragen oder Einwände vom Finanzamt.

Er storniert für sich die Rechnung und reicht diese erst garnicht beim Finanzamt ein (Ich Spekuliere mal auf Papierkorb). Die Rechnungsnummer wird erneut verwendet.

Ob das ein korrekter Storno ist, wage ich zu bezweifeln.

[vagtler]

Zitat:

Zitat von bernau (Beitrag 1307009)

[...] Ob das ein korrekter Storno ist, wage ich zu bezweifeln.

Ich befürchte, jeder Prüfer auch. Und dann ist die Ka..e am Dampfen...

Auf jeden Fall ist das ganz dünnes Eis und ich würde das an Perlsaus Stelle ganz dringend überdenken wollen...

[bernau]

Zitat:

Zitat von Perlsau (Beitrag 1307006)

Zitat:

Zitat von bernau (Beitrag 1306993)

Du spielst mit dem Feuer ;-)
Wenn du die Rechnung versendet hast, dann musst du immer damit Rechnen, daß diese auch beim Finanzamt von der Gegenseite eingereicht wird. Selbst wenn die nicht bezahlt wurde. Damit hast du dann zwei Rechnungen mit der gleichen Rechnungsnummer ausgestellt. Uiuiui.

Das soll sich mal einer trauen: Eine Rechnung, die er nicht bezahlt hat, als steuermindernde Ausgabe geltend machen. Das wäre Betrug und er würde sich damit selbst ins Knie schießen. Deshalb muß ich damit nicht wirklich rechnen, und schon gar nicht jederzeit.

Als GmbH (Beispiel) musst du die Umsatzsteuer abführen sobald die Rechnung ausgestellt ist. Dazu muss kein Gled fliessen. Umgekehrt kannst du erhaltene Rechnungen steuermindernd geltend machen. Auch wenn kein Geld geflossen ist. Er macht da keinen Fehler und auch kein Betrug. Spricht ja nichts dagegen, daß er irgendwann mal bezahlt. Du aber machst einen Fehler, indem du eine Rechnung versendest und die darauf stehende Rechnungsnummer erneut verwendest.

[mkinzler]

Bei Einnahmen-/Überschuß-Rechnung ist die Zahlung massgebend.

[Perlsau]

Posting gelöscht wegen eben via anonymer Email erhaltener Drohung vermutlich von einem hiesigen User, mich bei meinem zuständigen Finanzamt anzuzeigen.

[bernau]

Zitat:

Zitat von mkinzler (Beitrag 1307013)

Bei Einnahmen-/Überschuß-Rechnung ist die Zahlung massgebend.

Das zweifelt keiner an.

[vagtler]

Zitat:

Zitat von Perlsau (Beitrag 1307016)

[...] Keine doppelte Buchführung, da Kleingewerbler und daher nur Einnahmen-Überschuß-Rechnung erforderlich [...]

Es ging nicht um Dich. Es ging in diesem Beispiel um den Rechnungsempfänger.

Zitat:

Zitat von vagtler (Beitrag 1307011)

[...] Da ist kein dünnes Eis, wie mir ein studierter Betriebswirt versicherte. [...]

Nun, dann hat Dir jetzt schon mindestens ein anderer studierter Betriebswirt das Gegenteil versichert.

Aber letztendlich kannst Du machen was Du für richtig hältst. Das muss sich nicht mit geltendem Recht decken.

[Mavarik]

Zitat:

Zitat von mm1256 (Beitrag 1307005)

Bleibt doch bitte bei der Sachlage:

Hier herrscht ja wieder ein Ton im Thread...:oops:

Für die älteren unter uns is dat ne jutschrift

Dass da jetzt Storno drüber steht und das Vorzeichnen andersrum ist... Ändert nix an der Vorgehensweise...

[rapante]

Zitat:

Zitat von mm1256 (Beitrag 1307000)

Zitat:

Zitat von rapante (Beitrag 1306988)

.....Es ist dann müßig ihm zu erklären, dass er erst eine Gutschrift erzeugen und eine neue Rechnung erstellen muss, weil es im Nummernsystem keine Lücken geben darf...

Die Formulierung "eine Gutschrift erzeugen..." zeigt schon, dass es mit deinem Kenntnisstand, wie eine Rechnung zu stornieren ist, nicht weit her ist. Um die Mitlesenden nicht zu verwirren und dem Thread nicht ein Minimum an Wahrheitsgehalt zu nehmen, sollte man wenigstens die Gesetzeslage kennen.

Nenne es von mir aus auch Storno-Rechnung - wichtig ist nicht die Bezeichnung sondern der Inhalt.
Siehe BMF Schreiben vom 25.10.2013 auf Seite 3, letzter Absatz:

"Die im allgemeinen Sprachgebrauch bezeichnete Stornierung oder Korrektur der ursprünglichen
Rechnung als Gutschrift (sog. kaufmännische Gutschrift) ist keine Gutschrift im
umsatzsteuerrechtlichen Sinne. Wird in einem solchen Dokument der Begriff „Gutschrift“
verwendet, obwohl keine Gutschrift im umsatzsteuerrechtlichen Sinne nach § 14 Abs. 2
Satz 2 UStG vorliegt, ist dies weiterhin umsatzsteuerrechtlich unbeachtlich. Die Bezeichnung
als „Gutschrift“ führt allein nicht zur Anwendung des § 14c UStG."