gitmedia/mivita
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
mivita/dev/2026-07-17-steuern/02-09-2026-mail-an-steuerberater.md
Kevin 1a3af17f9a DATEV: stornierte Rechnungen im Rechnungsmonat, Pruefliste fuer den Steuerberater 
- Eine spaeter stornierte Rechnung fehlte im Export ihres Rechnungsmonats,
  weil cancellation = true auch an der Originalrechnung steht. Sie bleibt
  jetzt als Erloes im Rechnungsmonat; die Stornierung wird im Monat des
  Stornobelegs gegengebucht (nur Belege ohne cancellation_id).
- Pruefliste je Buchungsstapel als CSV (Button im Steuerberater-Bereich):
  Belege, die sich ohne Zusatzinformation nicht abstimmen lassen (doppelte
  Rechnungsnummern, Stornos ausserhalb des Systems).
- Korrespondenz und offene Differenzen mit dem Steuerberater unter
  dev/2026-07-17-steuern/.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-23 15:42:54 +00:00

8.5 KiB
Raw Blame History

Mail an den Steuerberater — 02.09.2026

Betreff: Offene Differenzen 08+09/2025, Prüfliste und Vorschlag für einen Vergleichszeitraum

Sehr geehrte Damen und Herren,

vielen Dank für die Übersicht der offenen Differenzen und Ihre Rückfragen. Ich habe die Punkte ausgewertet und schlage vor, den Abgleich in zwei Teile zu trennen: die Altfälle aus 08+09/2025 abschließend zu dokumentieren und parallel einen aktuellen Monat vollständig abzustimmen.

1. Vergleichszeitraum: August 2026

Als Vergleichszeitraum eignet sich August 2026. Den Buchungsstapel dazu stelle ich Ihnen zusammen mit diesem Schreiben zur Verfügung.

August 2026 ist der erste Monat, der vollständig nach der Systemumstellung vom 24.07.2026 entstanden ist. Alle Belege dieses Zeitraums wurden durchgehend über die korrigierten Abläufe erzeugt. Juli 2026 ist demgegenüber ein gemischter Zeitraum: Belege aus der ersten Julihälfte entstanden noch nach altem Stand, Belege danach nach neuem. September 2026 ist noch nicht abgeschlossen.

Prüfpunkt Stand 08/2026
Doppelt vergebene Rechnungsnummern keine
Beträge über 1.000 € korrekt
Rückzahlungen ohne Stornobeleg im System keine
Stornierungen 3, alle systemseitig als Stornobeleg erfasst
Steuerfreie innergemeinschaftliche Lieferungen ohne USt-IdNr. keine (28 Lieferungen, alle mit geprüfter USt-IdNr.)
Technische Prüfung des Buchungsstapels 0 Fehler

2. Chronologie: ab wann welche Ursache nicht mehr auftritt

Damit nachvollziehbar ist, welche Zeiträume von welchen Ursachen noch betroffen sind, habe ich jede Fehlerursache im Datenbestand zurückverfolgt. Zu unterscheiden sind zwei Arten:

a) Ursachen im Datenbestand. Diese wirken bis zu einem Stichtag und lassen sich für zurückliegende Zeiträume nicht mehr korrigieren.

Ursache Letzter Fall im Datenbestand Betroffene Zeiträume
Doppelt vergebene Rechnungsnummer 12.01.2026 bis einschließlich 01/2026
Beträge über 1.000 € fehlerhaft gespeichert 05.07.2026 bis einschließlich 07/2026
Rückzahlung ohne Stornobeleg im System 27.01.2026 bis einschließlich 01/2026
USt-IdNr. ohne laufende Prüfung übernommen 24.07.2026 bis einschließlich 07/2026

Ab 08/2026 tritt keine dieser Ursachen mehr auf.

b) Ursachen in der Aufbereitung des Buchungsstapels. Diese lagen nicht im Datenbestand, sondern in der Erzeugung der Datei. Sie sind behoben und wirken bei jeder Neuerzeugung rückwirkend für alle Zeiträume — auch für 2025.

Ursache Status
Beträge über 1.000 € falsch ausgelesen behoben, wirkt rückwirkend
Kontenzuordnung 8125 ↔ 8400/8300 behoben, folgt jetzt dem ausgestellten Beleg
Steuerschlüssel der Gutschriften behoben, entspricht dem Beleg
Verarbeitung von Stornobelegen behoben, Erlös im Rechnungsmonat, Gegenbuchung im Stornomonat

Die Ihnen am 24.07.2026 übermittelten Buchungsstapel für 08/2025 und 09/2025 sind unverändert auf dem aktuellen Stand; eine erneute Lieferung ist nicht erforderlich.

c) Systemseitige Stornierungen. Stornorechnungen werden seit dem 19.02.2026 als eigener Beleg erzeugt und erscheinen seither automatisch im Buchungsstapel. Rückzahlungen davor wurden außerhalb des Systems abgewickelt und sind dort nicht als Storno erfasst.

Der Verlauf lässt sich an den steuerfreien innergemeinschaftlichen Lieferungen ohne hinterlegte USt-IdNr. ablesen: 08/2025 waren es 10 von 42, 01/2026 noch 4 von 46, 08/2026 keine mehr von 28.

3. Neu: Prüfliste zu jedem Buchungsstapel

Damit Sie die nicht automatisch abstimmbaren Positionen nicht einzeln recherchieren müssen, liefere ich ab sofort zu jedem Buchungsstapel eine Prüfliste als zweite Datei. Sie enthält je Beleg: Kategorie, Belegnummer, Belegdatum, Konto, Steuerschlüssel, Betrag, Name und einen konkreten Hinweis.

Erfasst werden:

  • Doppelt vergebene Rechnungsnummern — mit Nennung aller Einzelrechnungen hinter der Nummer, jeweils mit Kundenname und Betrag
  • Rückzahlungen ohne Stornobeleg — mit Datum der Rückzahlung
  • Stornierungen über Monatsgrenzen — in beide Richtungen, damit die Gegenbuchung im richtigen Zeitraum zugeordnet werden kann
  • Steuerfreie innergemeinschaftliche Lieferungen ohne hinterlegte USt-IdNr.
  • Provisionsgutschriften mit Reverse Charge ohne hinterlegte USt-IdNr.

Ein Beispiel aus 08/2025:

202537208 | Hoppe Torben | 24,80 € | Nummer im Zeitraum 2× vergeben, Summe unter dieser Nummer 169,70 €. Weitere Rechnung(en): Kuhn Laura (144,90 €)

Für 08/2025 umfasst die Prüfliste 47 Positionen, für 09/2025 44 Positionen. Beide Listen lege ich bei, damit die verbleibende manuelle Abstimmung dieser beiden Monate auf einer vollständigen Aufstellung aufsetzen kann.

Ein Hinweis zur Vollständigkeit: Rückzahlungen erkennt die Liste anhand der Daten des Zahlungsdienstleisters. Bei 202539501 ist im System keinerlei Rückzahlung vermerkt — dieser Fall wurde vollständig außerhalb abgewickelt und lässt sich nicht automatisiert ausweisen.

4. Ihre Frage: Erfassung ungültiger USt-IdNr.

Die USt-IdNr. wird seit dem 24.07.2026 bei jeder Bestellung erneut live über die EU-Datenbank (VIES) geprüft, nicht mehr nur einmalig bei der Eingabe. Ist sie ungültig, abgelaufen oder deutsch, wird der Reverse-Charge-Status entzogen, die Bestellung mit Umsatzsteuer berechnet und der Kunde darauf hingewiesen. Deutsche USt-IdNr. werden systemweit nicht mehr als Grundlage für steuerfreie Lieferungen akzeptiert.

Für die Kontenzuordnung ist maßgeblich, wie die Rechnung tatsächlich ausgestellt wurde: ohne Umsatzsteuer verkaufte EU-Lieferungen auf 8125 (BU 1), mit Umsatzsteuer berechnete Lieferungen auf 8400/8300. Rechnung und Buchung können dadurch nicht mehr auseinanderlaufen.

Für Rechnungen, die vor der Umstellung bereits steuerfrei ausgestellt wurden, gilt dies naturgemäß nicht rückwirkend — siehe 202537251 unter Punkt 7.

5. Ihre Frage: Belege aus dem separaten Rechnungskreislauf

Diese Belege werden von MIVITA außerhalb des Shopsystems erstellt. Ich habe darauf weder Zugriff noch Einblick; sie können im Buchungsstapel des Shops daher systembedingt nicht enthalten sein. Wie diese Belege in die Buchhaltung überführt werden, stimmen Sie bitte direkt mit MIVITA ab. Im Abgleich mit dem Shop-Export bitte ich, sie weiterhin als „extern" zu kennzeichnen.

6. Provisionsgutschriften an Berater im Ausland

Zur Einordnung, wie das System aktuell verfährt: Provisionsgutschriften an Berater mit Sitz außerhalb Deutschlands werden ohne Umsatzsteuer ausgestellt. Im Buchungsstapel werden sie bei Ansässigkeit in der EU mit dem Steuerschlüssel für Reverse Charge (BU 94) übergeben.

Bei einem Teil dieser Berater ist im System keine USt-IdNr. hinterlegt. Im August 2026 betrifft das 32 von 44 EU-Gutschriften über zusammen 2.378,18 €; die übrigen 12 (17.838,06 €) verfügen über eine hinterlegte und geprüfte USt-IdNr. Alle betroffenen Belege sind in der Prüfliste einzeln ausgewiesen.

Sollte für Gutschriften ohne hinterlegte USt-IdNr. ein anderer Steuerschlüssel maßgeblich sein, setze ich das im Export um und fordere die fehlenden USt-IdNr. bei den betroffenen Beratern an. Ich bitte hierzu um Ihre Einschätzung.

7. Verbleibende Einzelfälle aus 08+09/2025

  • 202537251 (spanische USt-IdNr.): Die Rechnung wurde 2025 steuerfrei ausgestellt. Der Export bildet den Beleg ab und weist sie deshalb auf 8125 aus. Eine Zuordnung auf 8400 setzt eine Rechnungskorrektur gegenüber dem Kunden voraus. Bitte teilen Sie mir mit, ob Sie eine solche Korrektur für erforderlich halten.
  • 202535876 (Teilrückzahlung 16.09.2025 zur Juli-Rechnung): Die Rückzahlung ist im System ohne Beleg erfolgt; Teilstornierungen kann das System bis heute nicht als eigenen Beleg abbilden. Ich bitte um manuelle Berücksichtigung. Sollten solche Fälle häufiger auftreten, richte ich eine Teilstornierung mit eigenem Beleg ein.
  • 202539011: Das Rechnungs-PDF ist beigefügt.
  • Doppelnummern, Stornos 2025 und externe Belege: abschließend in den beiliegenden Prüflisten dokumentiert.

8. Vorschlag zum weiteren Vorgehen

  1. Abgleich von 08/2026 anhand des beiliegenden Buchungsstapels und der Prüfliste — dieser sollte ohne Differenzen aufgehen.
  2. Abschluss der Altfälle 08+09/2025 anhand der Prüflisten; die dort genannten Positionen sind nicht mehr systemseitig korrigierbar.
  3. Ihre Einschätzung zu Punkt 6 und zu 202537251.

Für Rückfragen zu einzelnen Belegen liefere ich gern Detailauswertungen nach.

Mit freundlichen Grüßen