### 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)