Wenn du über Amazon / eBay / andere Marktplätze verkaufst (oder Shopify Payments nutzt), ist Buchhaltung nicht einfach „Export der Bestellungen“.
Der Engpass ist fast immer derselbe: Geldflüsse entstehen im Settlement-/Ledger-System des Marktplatzes, nicht im Order-System.Diese Seite ist eine praxisnahe Referenz für saubere DATEV-Integrationen im E-Commerce:
Datenobjekte, Mapping-Modelle, Fehlerquellen, Integrationsmuster – plus Assets, die du direkt für Projekt-Setup oder Doku nutzen kannst.---

• E-Commerce Ops / Finance Ops, die **Monatsabschluss stabil** bekommen müssen
• ERP-/Integrations-Teams, die **DATEV Export / Buchungsdatenservice** anbinden
• Agenturen / Systemhäuser, die **Marktplatz-Accounting-Projekte** umsetzen
• Product Teams, die einen **Connector** bauen oder verbessern

---

Wer nach DATEV + Marktplatz/Settlement/Schnittstelle sucht, will nicht Theorie, sondern:

• **Fehlerkosten senken** (Nacharbeit, Steuerberater-Rückfragen, manuelle Korrekturen)
• **Go-Live absichern** (keine „FiBu-Krise“ im 1. Monat)
• **Tool-/Integrationsentscheidungen** treffen (Connector, ERP, Datenservice, Betriebsmodell)

Kurz: Das ist E-Commerce – aber auf der Finance/Accounting-Ebene.---

Der wichtigste Denkfehler in E-Commerce-Accounting-Projekten ist:
> Order ≠ Buchungsgrundlage
In der Praxis gilt: Ledger/Settlement ist die finanzielle Wahrheit.

Was wurde verkauft, geliefert, storniert?
Was ist finanziell passiert (inkl. Gebühren)?
Was wurde tatsächlich wann ausbezahlt/abgebucht?

• **Handelsebene (Order/Invoice/Shipment)**
• **Finanzereignis-Ebene (Charges/Refunds/Fees/Adjustments/Disputes/Reserves)**
• **Auszahlungsebene (Payout/Transfer/Bank)**

### A) Buchungsfähige Ereignisse (Posting Layer)

• **Umsätze/Erlöse** (inkl. Versand, Rabatte, Gutscheine)
• **Steuern** (Steuersätze, Jurisdiktion, OSS-/Sonderfälle)
• **Gebühren** (Marktplatz-/Payment-/Fulfillment-/Werbegebühren, Adjustments)
• **Refunds / Stornos / Retouren** (inkl. Teilrefunds, Fee-Reversals)
• **Disputes / Chargebacks / Reserves** (Risikoflüsse, die nicht order-getrieben sind)
• **Payouts / Transfers** (Auszahlungen inkl. Referenzen)

### B) Nachweise & Kontext (Evidence Layer)

• **Belege/Belegbilder** (Rechnungen, Gutschriften, Gebührenrechnungen)
• **Stabile IDs** für Matching (order_id, capture_id, payout_id, settlement_id, invoice_id)
• **Stammdaten** (Debitor/Kreditor, Zahlbedingungen, Adressen – abhängig vom Setup)
• **Währung/FX-Kontext** (Transaktionswährung vs Auszahlungswährung, FX Fees)

---

Typische Symptome:

• „Umsätze fehlen im Monat“
• „Bank passt nicht zum Export“
• „Einige Orders sind nicht matchbar“

Typische Ursachen:

• Settlement berichtet **periodisch** (nicht order-nah)
• Cutoffs verschieben Transaktionen in den nächsten Report
• Zeitstempel/Zeitzonen (UTC vs lokal) + Wochenenden + Banklaufzeiten

Marktplätze ändern Gebührenstrukturen regelmäßig:

• neue Fee-Typen
• neue Amount-Descriptions
• geänderte steuerliche Behandlung (je Land, Rechnungstyp, Reverse-Charge etc.)

Wenn dein Mapping nicht versioniert ist, bricht die Buchungslogik „plötzlich“.

Gerade in EU-Konstellationen ist entscheidend:

• **Wer ist Lieferer?**
• **Welche Rechnung ist der Beleg?**
• **Welche Steuer ist zu buchen?**

Fehlerklasse: Integration bucht „Standard-B2C-Verkauf“ – obwohl Plattform-Sonderrollen oder OSS-Regeln greifen.

„Storno“ ist selten ein einzelnes Ereignis:

• Refund + Fee-Reversal + Adjustment + Dispute + Reserve kann zeitlich versetzt auftreten
• Order-Daten allein reichen nicht

---

Statt:
> Order → Buchung → fertigbesser:
> Order/ERP + Ledger/Settlement → Canonical Financial Events → Posting Engine → DATEV → Reconciliation Loop### Warum?
Weil Marktplätze ihr eigenes Ledger haben. Genau dort entstehen:

• Gebühren
• Disputes
• Reserves
• Payouts
• Adjustments

### 3.1 Event-driven Pipeline

• Jede relevante Finanzbewegung wird als **Event** verarbeitet
• Consumer bauen Buchungen deterministisch und wiederholbar

### 3.2 Idempotency (Dubletten killen)

• Jeder Financial Event bekommt eine **globale Event-ID**
• Posting Engine verarbeitet **idempotent**
• Ergebnis: Retries sind sicher, keine Doppelbuchungen

### 3.3 Transactional Outbox (keine verlorenen Events)

• Outbox-Table in deiner DB
• Events werden erst als „published“ markiert, wenn sicher versendet
• verhindert “missing postings” bei Deployments / Ausfällen

### 3.4 Reconciliation als Pflicht-Feature (nicht Excel danach)
Zwei Abstimmungen müssen möglich sein:
1) Order/ERP ↔ Settlement/Ledger
2) Settlement/Ledger ↔ BankOhne diese Schleifen ist „Go-live“ eine Wette.---

• **Settlement**: periodischer Auszug, der finanzielle Ereignisse zusammenfasst (nicht identisch mit Orders)
• **Ledger/Balance Transactions**: kanonische Liste *aller* Geldbewegungen (charges, refunds, disputes, adjustments, reserves, payouts)
• **Payout**: Auszahlung vom Marktplatz/PSP auf dein Bankkonto
• **Clearing-Konto**: Verrechnungskonto, auf dem du Order-/Payment-/Fee-Flüsse sammelst, bis Bankabgleich passt
• **Match Key**: Set aus IDs, das eine Transaktion eindeutig matchbar macht (z.B. order_id + capture_id + payout_id)
• **Belegbild**: PDF/Scan, der als Nachweis in DATEV mit dem Buchungssatz verknüpft wird

---

> Hinweis: Kontenrahmen (SKR) ist mandanten-/steuerberaterabhängig.
> Diese Tabelle bildet die Logik ab – nicht dein finales Kontensetup.| Geschäftsvorfall | Canonical Financial Event | Mindest-Referenzen | Buchungswirkung (konzeptionell) | Häufige Fehlerquelle |
|---|---|---|---|---|
| Verkauf bezahlt / charge | CHARGE | order_id + capture_id | Clearing/Forderung → Erlöse (+ USt) | Zeitversatz / UTC / Cutoff |
| Marktplatzgebühr | FEE | settlement_id + fee_type | Gebührenaufwand → Clearing | Fee drift / Steuer auf Fees |
| Refund (voll/teil) | REFUND | refund_id + original_event_id | Erlösminderung/Refund → Clearing | Teilrefund ohne klare Referenz |
| Dispute/Chargeback | DISPUTE | dispute_id + original_event_id | Dispute/Reserve → Clearing | Dispute kommt später als Order |
| Reserve hold/release | RESERVE | reserve_event_id | Clearing ↔ Reserve-Konto | Reserve nicht order-getrieben |
| Auszahlung | PAYOUT | payout_id + bank_ref | Bank → Clearing | Bankdatum ≠ Reportdatum |---

• [ ] Daily Reconciliation (Order↔Settlement, Settlement↔Bank) möglich
• [ ] Unmatched-Workflow (Nachläufer/Cutoffs) definiert
• [ ] Audit Trail: Jede Buchung → Event → Beleg ist rückverfolgbar

---

Root Cause: Cutoff / Nachläufer im nächsten Settlement
Detection: Orders mit Capture am Tag X ohne Settlement-Zeile
Fix: Unmatched-Set + Re-run / delayed reconciliation

Root Cause: Banklaufzeit / anderes Valutadatum / Konsolidierung
Detection: Betrag matcht, Datum weicht ab
Fix: Bankabgleich tolerant auf Datum, strikt auf Betrag + Referenz

Root Cause: Fee drift, neue amount-descriptions
Detection: fee_type nicht gemappt → „unknown“ steigt
Fix: Default-Konto + Alerting + Mapping-Versionierung

Root Cause: Refunds/Chargebacks/Reserves reduzieren net payout
Detection: negative adjustments/reserve/dispute im Ledger
Fix: Dispute/Reserve als eigene Events buchen, nicht nur Orders

Root Cause: Refund referenziert Original nicht sauber
Detection: Clearing-Saldo bleibt offen trotz Auszahlung
Fix: original_event_id zwingend, Matching-Regeln für partials---

Wenn du Settlement-/Ledger-Logik, Idempotency und Reconciliation sauber baust, bekommst du:

• stabilen Monatsabschluss
• weniger Steuerberater-Rückfragen
• weniger manuelle Korrekturen
• bessere Skalierbarkeit bei Multi-Marketplace

---

• Baue ein **Canonical Financial Event Model**
• Definiere **Match Keys** und **Reconciliation Reports**
• Erstelle eine **Mapping-Matrix** pro Marktplatz + pro Steuerfall
• Setze auf **idempotent postings** + Outbox

Wenn du willst, erstelle ich dir als nächstes:
1) eine Topic Map (10–20 SEO-Seiten um DATEV/Settlement/Reconciliation)
2) ein vollständiges Glossar (30–60 Begriffe)
3) eine Mapping-Tabelle als CSV/Sheet (Order → Booking, inkl. Gebührenklassen)