mivita/dev/2026-02-06/steuerberater.md

Vom Steuerberater.

Umsatzerlöse

• 8400 Erlöse 19% -> Steuerschlüssel 9
• 8300 Erlöse 7% -> Steuerschlüssel 8
• 8120 Steuerfreie Umsätze nach § 4 Nr. 1a UStG (Drittland) -> Steuerschlüssel = 11
• 8125 Steuerfreie innergemeinschaftliche Lieferungen nach § 4 Nr. 1b UStG (EU) -> Steuerschlüssel = 1

Provisionen (Unterscheidung in Shop, Payline und Wachstumsbonus)

• 4760 Verkaufsprovision (Shop + Wachstumsbonus) o 19% -> Steuerschlüssel = 9 o Kleinunternehmer -> Steuerschlüssen = 50 o Reverse Charge -> Steuerschlüssel = 94
• 4764 (Payline) o 19% -> Steuerschlüssel = 9 o Kleinunternehmer -> Steuerschlüssen = 50 o Reverse Charge -> Steuerschlüssel = 94

Relevante Felder/Spalten

• Umsatz (Spalte A) -> Bruttobetrag je Steuerschlüssel
• Soll/Haben (Spalte B) o Umsatz -> H o Provisionen -> S
• Konto (Spalte G) o Umsätze -> siehe Umsatzerlöse o Provisionen -> siehe Gutschriften
• Gegenkonto (Spalte H) o Umsatzerlöse = Debitorenkonto (vermutlich Sammelkonto) o Provisionen = Kreditorenkonto (vermutlich Sammelkonto)
• Buchungsschlüssel o Steuerschlüssel siehe oben je Sachverhalt
• Belegdatum (Spalte J) = Rechnungs-/Gutschriftsdatum
• Belegfeld 1 (Spalte K) o Umsatz = Rechnungsnummer o Gutschrift = Gutschriftnummer
• Buchungstext (Spalte N) o Umsatz = Name Kunde (Nachname Vorname) o Provisionen = Name Kunde (Nachname Vorname)
• EU-Land u. UStID (Spalte AN) o USt-ID

Gegenkonto Umsatz

• Payone -> Debitor (Mapping erforderlich)
• Paypal -> 1230
• Kunden -> vermutlich Sammeldebitor

Gegenbuchung Provisionen

• Kreditor 71586
• Vermutlich Sammelkreditor

Zu klären

• Kundennummer erforderlich?
• Kreditorennummer erforderlich?

Erläuterungen

1. Header a. DATEV-Format - DATEV Developer Portal
2. Buchungsstapel a. DATEV-Format - DATEV Developer Portal

Erste Konzeption für ein DATEV-Export-Modul (EXTF „Buchungsstapel“) im Laravel-CRM – basierend auf dem Briefing des Steuerberaters und orientiert am DATEV Developer Portal (Header + Buchungsstapel). 

⸻

1. Zielbild: Was das Modul am Ende liefern muss

Output: pro Abrechnungsperiode (z. B. Monat) eine Datei EXTF_Buchungsstapel.csv mit 1. Header-Satz (erste Zeile, beginnt mit EXTF;700;21;...) 2. Spaltenkopfzeile (zweite Zeile) 3. Buchungszeilen (ab Zeile 3, je Buchung eine Zeile) 

Euer Beispiel/Template entspricht genau diesem Muster (Headerzeile + Spaltenkopfzeile + Daten).

⸻

2. Fachliche Logik (Mapping) – so entstehen Buchungszeilen

2.1 Buchungsarten (aus euren CRM-Daten ableitbar)

Ihr habt im System bereits: Bestellungen, Rechnungen, Gutschriften, Storno usw. Daraus leitet ihr je Datensatz eine „Buchungsart“ ab: • Umsatz (Rechnung / Belastung) • Soll/Haben: H • Konto: Erlöskonto (8400/8300/8120/8125) • Gegenkonto: Debitor/Zahlkonto (Payone/PayPal/Sammeldebitor) • Provision (Gutschrift / Abzug) (Shop, Payline, Wachstumsbonus) • Soll/Haben: S • Konto: 4760 (Shop+Wachstumsbonus) oder 4764 (Payline) • Gegenkonto: Kreditor (z. B. 71586 oder Sammelkreditor)

Wichtig: „Provision“ ist in eurem Export fachlich eine eigene Buchungslogik, auch wenn sie technisch über Gutschriften abgebildet ist.

2.2 Steuerschlüssel & Konten (1:1 aus dem Briefing)

Umsatzerlöse • 8400 Erlöse 19% → Steuerschlüssel 9 • 8300 Erlöse 7% → Steuerschlüssel 8 • 8120 Drittland steuerfrei §4 Nr. 1a → Steuerschlüssel 11 • 8125 IG Lieferung steuerfrei §4 Nr. 1b → Steuerschlüssel 1

Provisionen • 4760 Verkaufsprovision (Shop + Wachstumsbonus) • 19% → 9 • Kleinunternehmer → 50 • Reverse Charge → 94 • 4764 (Payline) • 19% → 9 • Kleinunternehmer → 50 • Reverse Charge → 94

2.3 Relevante DATEV-Spalten (aus Steuerberater-Vorgabe)

Ihr befüllt (mindestens) folgende Felder: • Spalte A Umsatz: Bruttobetrag je Steuerschlüssel • Spalte B Soll/Haben: Umsatz = H, Provisionen = S • Spalte G Konto: wie oben • Spalte H Gegenkonto: Debitor/Kreditor/Zahlkonto (Mapping) • Buchungsschlüssel (BU-Schlüssel): Steuerschlüssel wie oben • Belegdatum (Spalte J): Rechnungs-/Gutschriftsdatum • Belegfeld 1 (Spalte K): Rechnungsnummer / Gutschriftsnummer • Buchungstext (Spalte N): Name Kunde „Nachname Vorname“ • EU-Land u. UStID (Spalte AN): USt-ID (wenn vorhanden)

Die restlichen DATEV-Spalten bleiben leer (aber müssen als Trennzeichen „mitlaufen“, weil das Format feste Spaltenpositionen hat). 

⸻

3. Gegenkonto-Logik (entscheidet über Debitor/Zahlkonto)

Aus dem Briefing:

Gegenkonto Umsatz • Payone → Debitor (Mapping erforderlich) • PayPal → 1230 • Kunden → Sammeldebitor (vermutlich)

Gegenbuchung Provisionen • Kreditor 71586 (oder Sammelkreditor)

Empfehlung (damit es skalierbar bleibt)

Baut das als Regelwerk + Mappingtabellen, nicht hardcodiert.

(A) payment_method_counteraccounts • payment_method (payone, paypal, invoice, …) • counteraccount_type (DEBITOR, GL_ACCOUNT) • counteraccount_value (z. B. 1230)

(B) payone_debitor_mapping • Schlüssel z. B. payone_account_id / merchant_id / settlement_reference • Ziel: debitor_account_no

Fallback-Regeln 1. Wenn PayPal → 1230 2. Wenn Payone und Mapping gefunden → gemappter Debitor 3. Sonst → Sammeldebitor

⸻

4. „Zu klären“ (Kundennummer/Kreditorennummer) – pragmatische Konzeption ohne Blocker

Ihr könnt das so designen, dass beides optional ist, aber unterstützt wird:

Option 1: Sammelkonten (schnell, wenig Stammdatenpflege) • Gegenkonto Umsatz: Sammeldebitor • Gegenkonto Provision: Sammelkreditor/71586 • Vorteil: einfacher Start • Nachteil: keine OP-Auswertung pro Kunde in DATEV

Option 2: echte Debitoren/Kreditoren (sauberer, mehr Pflege) • Jeder Kunde bekommt Debitorennummer (und ggf. Kreditorennummer, wenn Provisionen individuell laufen sollen) • Optional zusätzlich Export „Debitoren/Kreditoren“-Stammdaten in DATEV-Format (separater EXTF-Datensatztyp) 

Empfehlung für eure Roadmap • Phase 1: Sammelkonten + Payone-Mapping + PayPal 1230 • Phase 2: Debitoren/Kreditoren optional (wenn Steuerberater OP-Listen braucht)

Ist geklärt. Option 1 Wird umgesetzt. Zusätzlich wird immer wie in Phase 1 noch das Payone-Mapping + PayPal 1230 etc angahangen.

⸻

5. Storno / Korrekturen / Gutschriften: robustes Regelwerk

Ihr wollt verhindern, dass „Storno“ doppelt wirkt oder als falsches Vorzeichen rausgeht.

Konzeptionell sauber: • Jede exportierte Zeile bekommt eine interne Export-Signatur (z. B. source_type, source_id, line_hash) und wird als „exportiert“ protokolliert. • Storno/Gutschrift wird als eigene Buchung exportiert (typischerweise Gegenbuchung zur Ursprungsbuchung), nicht als stilles Überschreiben.

DATEV-seitig gibt es Felder/Mechaniken für Umkehr/Korrektur; wie ihr das exakt nutzt (eigener Umkehrschlüssel vs. negativer Betrag) sollte ihr einmal mit dem Steuerberater festziehen, aber euer Modul kann beides abbilden: • Variante A: negativer Umsatzbetrag in Spalte A • Variante B: Umkehr-/Berichtigungsschlüssel befüllen (wenn gewünscht)

(Die DATEV-Doku zum Buchungsstapel beschreibt die Struktur/Spalten; die konkrete Kanzlei-Konvention ist oft Mandantenstandard.) 

⸻

6. Datenmodell in Laravel (minimal, aber vollständig)

6.1 Kern-Tabellen

datev_exports • id, period_from, period_to, created_by • status (draft/generated/downloaded/locked) • berater_nr, mandant_nr (für Header) • filename, file_path, hash

datev_export_lines • export_id • source_type (invoice/credit_note/cancellation/commission) • source_id • amount_gross • soll_haben (H/S) • konto • gegenkonto • bu_schluessel • belegdatum • belegfeld1 • buchungstext • ustid, eu_land • row_csv (optional: final gerenderte Zeile zur Nachvollziehbarkeit)

accounting_rules (konfigurierbar) • für Umsatz: VAT-Case → (konto, bu) • für Provision: scenario → (konto, bu)

counteraccount_mappings (Payone/PayPal/Default)

6.2 Warum „Export Lines“ speichern? • Audit-Trail (Steuerberaterfragen) • Re-Download exakt identisch • Sperre gegen Doppel-Export derselben Quellen

⸻

7. UI/Workflow (CRM-Modul) 1. Periode wählen (Monat/Zeitraum) 2. Datenbasis anzeigen: Anzahl Rechnungen, Gutschriften, Stornos, Provisionen 3. Regel-Preview: gruppiert nach (Konto, Gegenkonto, Steuerschlüssel) + Summen 4. Validierungscheck (Blocking): • fehlender Steuercase (z. B. EU ohne USt-ID aber als IG markiert) • fehlendes Payone-Debitor-Mapping (falls Pflicht) • fehlendes Belegdatum/Belegnr. 5. Export generieren → Datei + Protokoll 6. Lock (optional) → „Dieses Periodenset ist final“

⸻

8. CSV/Format-Generator (technische Konzeption, ohne Code) • Semikolon als Delimiter • Headerzeile gemäß DATEV-Vorgaben (Formatkategorie 21 = Buchungsstapel, Versionen etc.)  • Danach Spaltenkopfzeile (fixe Reihenfolge) • Dann Zeilen mit exakt derselben Spaltenanzahl (leere Felder als leer zwischen ;)

Praxis-Hinweis: Haltet Header-Felder (Berater-Nr, Mandant-Nr, Zeitraum) als Kanzlei-Konfiguration im CRM, damit ihr nicht pro Export „handwerkelt“. (Gerade diese Angaben sind beim Import relevant.) 

⸻

9. Konkrete Regel-Engine (so entscheidet ihr automatisch)

Umsatz-Fallunterscheidung

Input: invoice.vat_rate, invoice.destination_country, invoice.customer_vat_id, invoice.tax_exemption_reason

Mapping: • vat_rate == 19% → (8400, bu=9) • vat_rate == 7% → (8300, bu=8) • Drittland steuerfrei → (8120, bu=11) • EU IG Lieferung steuerfrei → (8125, bu=1)

Provision-Fallunterscheidung

Input: commission.type (shop/payline/bonus), supplier_tax_status (normal/KU/RC) • type shop|bonus → konto 4760 • type payline → konto 4764 • tax_status normal → bu 9 • KU → bu 50 • RC → bu 94

⸻

10. Was ich aus eurer Beispieldatei ableite (für die Konzeption wichtig)

Eure Datei nutzt exakt das typische Muster: • Zeile 1: EXTF;700;21;Buchungsstapel;... • Zeile 2: Spaltenüberschriften (u. a. „Umsatz (ohne Soll/Haben-Kz)“, „Soll/Haben-Kennzeichen“, „Konto“, „Gegenkonto“, „BU-Schlüssel“, „Belegdatum“, …) • Danach Datenzeilen mit vielen leeren Feldern (DATEV-typisch bei Minimalbefüllung)

Das bestätigt: Ihr braucht vor allem stabile Spaltenpositionen + korrektes Mapping, nicht „alle 116 Felder“. 

⸻

Wenn du willst, kann ich als nächsten Schritt (ohne extra Rückfragen) aus eurem Briefing ein konkretes Mapping-Dokument erstellen (als technische Spezifikation): • Feld-zu-Quelle (CRM) je DATEV-Spalte • Regelprioritäten (Fallbacks) • Validierungsregeln + Fehlermeldungen (für UI) • Testfälle (z. B. EU ohne USt-ID, Storno nach Periodenwechsel, Payone ohne Mapping, KU/RC-Provisionen)