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

169 lines
8.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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
Reference in a new issue View git blame Copy permalink