---
title: "7 Richtlinien, die vor dem Aufbau eines Abrechnungssystems mit KI festzulegen sind"
locale: de
category: how_to
category_name: "Anleitungen"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/seven-policies-before-building-ai-settlement-system
published_at: 2026-07-27T00:58:06+09:00
---

# 7 Richtlinien, die vor dem Aufbau eines Abrechnungssystems mit KI festzulegen sind

> Die Abrechnung ist keine bloße Rechenfunktion, die Gebühren vom Verkaufsbetrag abzieht, sondern ein System für Finanzoperationen, das die Zuordnung der Verkaufserlöse, Auszahlungsbedingungen, Erstattungen, Steuern und die Behandlung von Fehlern steuert. Bevor die Implementierung einer KI übertragen wird, müssen Menschen zunächst sieben Richtlinien festlegen – vom Abrechnungsstichtag bis zu den Audit-Logs.

## Key Points

- Verkaufserlöse sind nicht als frei verfügbares Betriebskapital der Plattform zu verwalten, sondern als zweckgebundene Mittel, die mit Verpflichtungen zu Auszahlungen an Verkäufer und andere Empfänger verbunden sind.
- Bestellstatus und Abrechnungsstatus sind voneinander zu trennen; Kaufbestätigung, Erstattung, Streitfall und fehlgeschlagene Auszahlung müssen jeweils im Hauptbuch erfasst werden.
- Bei privaten Verkäufern sind nicht immer 3,3 % Quellensteuer einzubehalten; dies ist anhand der rechtlichen Art der Einkünfte und des Status des Verkäufers zu beurteilen.
- Auch bei Nutzung von PG oder Treuhanddiensten muss die Plattform über Abrechnungszyklus, Gebühren, Sperren, Übertragung negativer Salden und steuerliche Richtlinien entscheiden.
- Von KI erzeugter Abrechnungscode darf erst nach Abstimmung des Hauptbuchs, Maßnahmen gegen Doppelauszahlungen, Zugriffskontrollen und einer Prüfung durch Fachleute eingesetzt werden.

Die Abrechnung ist keine einfache Subtraktionsfunktion. Sie ist ein Buchführungssystem, das die Rechte und Pflichten für jede Bestellung festlegt, die von der Plattform zu verwahrenden oder auszuzahlenden Gelder trennt und Rückerstattungen, Streitfälle, Steuern sowie fehlgeschlagene Überweisungen nachverfolgt.

Generative AI kann beim Schreiben von Code und Tests helfen, aber nicht die Verantwortung für die Abrechnungsrichtlinien übernehmen. Fehlen entsprechende Richtlinien, kann AI plausibel wirkende Standardwerte erzeugen oder Ausnahmefälle auslassen. Dies kann zu Überzahlungen, doppelten Zahlungen, Steuerfehlern oder Liquiditätsproblemen führen.

## Grundsätze aus dem Fall TMON und WeMakePrice von 2024

Die umfangreichen ausstehenden Auszahlungen von Verkaufserlösen bei TMON und WeMakePrice im Jahr 2024 haben gezeigt, welch große Kettenreaktion verzögerte Abrechnungen für Verkäufer und Verbraucher auslösen können. Die Ursache des Vorfalls darf jedoch nicht allein auf einen langen Abrechnungszyklus reduziert werden. Mehrere Faktoren wie Kapitalverwaltung, Liquidität, Unternehmensführung und interne Kontrollen müssen gemeinsam geprüft werden.

Die wichtigsten Lehren für Betreiber sind eindeutig.

- Noch nicht ausgezahlte Verkaufserlöse dürfen nicht als frei verwendbare Unternehmensliquidität betrachtet werden.
- Je länger der Abrechnungszyklus ist, desto größer ist der ausstehende Saldo, der durch eine einzelne Störung oder mangelnde Liquidität gefährdet wird.
- Der Saldo der Verkaufserlöse und die tatsächlich verwahrten Gelder werden täglich abgeglichen.
- Abrechnungsbedingungen und Gründe für Verzögerungen werden den Verkäufern transparent offengelegt.
- Einschlägige Rechtsvorschriften, die Vertragsstruktur und der Leistungsumfang des PG-Dienstes werden gesondert geprüft.

Die rechtliche Zuordnung und die Art des Schutzes von Verkaufserlösen können je nach Transaktionsstruktur variieren. Im Tagesgeschäft sollte daher stets das Bewusstsein gewahrt bleiben, dass es sich um „fremdes Geld“ handelt; die tatsächliche buchhalterische und rechtliche Behandlung muss jedoch anhand der Verträge und geltenden Rechtsvorschriften beurteilt werden.

## 7 vor der Implementierung festzulegende Abrechnungsrichtlinien

### 1. Abrechnungsstichtag und Auszahlungszyklus

Zunächst muss definiert werden, wann eine Bestellung abrechnungsfähig wird. Werden nur das Bestell- oder Zahlungsdatum zugrunde gelegt, können Beträge für Stornierungen vor dem Versand und mögliche Rücksendungen in die Auszahlung einfließen.

Für gewöhnliche Warentransaktionen kann folgender Ablauf gestaltet werden.

1. Zahlungsautorisierung
2. Abschluss der Lieferung
3. Kaufbestätigung oder automatische Bestätigung nach Ablauf des vereinbarten Zeitraums
4. Prüfung auf Rücksendungen, Streitfälle und auffällige Transaktionen
5. Festlegung der abrechnungsfähigen Positionen
6. Aufnahme in einen Auszahlungslauf
7. Abschluss von Überweisung und Abgleich

Folgende Punkte müssen zwingend festgelegt werden.

- Das abrechnungsrelevante Ereignis für jede Transaktionsart wie Waren, digitale Inhalte und Dienstleistungen
- Der Zeitraum bis zur automatischen Kaufbestätigung und dessen Beginn
- Täglicher, wöchentlicher oder monatlicher Auszahlungszyklus
- Umgang mit Wochenenden und Feiertagen
- Abrechnungsschluss und Zuordnung von Transaktionen nach diesem Zeitpunkt zu einem Auszahlungslauf
- Mindestauszahlungsbetrag und Übertrag kleiner Restbeträge
- Ob unterschiedliche Zyklen je nach Verkäuferstufe zugelassen werden
- Verfahren zur Prüfung, ob gesetzliche oder vertragliche Auszahlungsfristen überschritten werden

Abrechnungsfähigkeit und tatsächliches Auszahlungsdatum müssen getrennt betrachtet werden. Beispielsweise bezeichnet `eligible_at` den Zeitpunkt, zu dem die Auszahlungsvoraussetzungen erfüllt sind, `scheduled_payout_at` den Zeitpunkt der Aufnahme in einen Auszahlungslauf und `paid_at` den Zeitpunkt, zu dem die erfolgreiche Überweisung bestätigt wurde.

### 2. Gebührenberechnung und Abrechnungsnachweis

Wird Verkäufern nur der endgültige Auszahlungsbetrag angezeigt, ist eine Kontrollrechnung schwierig und die Zahl der Anfragen und Streitfälle steigt. Sowohl Einzelaufstellungen pro Bestellung als auch periodische Summen sind erforderlich.

| Aufstellungsposten | Beschreibung |
|---|---|
| Bruttotransaktionsbetrag | Vertragliche Bestandteile des Verkaufspreises wie Warenpreis, Optionspreis und Versandkosten |
| Getragene Rabattbeträge | Jeweils von Plattform, Verkäufer und Partner getragenen Rabatte |
| Stornierungs- und Rückerstattungsbetrag | Vollständige und teilweise Rückerstattungen sowie Anpassungen der Versandkosten |
| Plattformgebühr | Gebührensatz, Pauschalgebühren und deren Steuerpflicht |
| Zahlungsbezogene Kosten | Angabe, ob PG-Kosten gesondert abgezogen oder in der Gebühr berücksichtigt werden |
| Steuerliche Anpassungen | Relevante Posten wie Ausweis der Mehrwertsteuer und Quellensteuer |
| Sonstige Anpassungen | Vertraglich begründete Anpassungen wie Entschädigungen, Werbekosten und Vertragsstrafen |
| Endgültiger Auszahlungsbetrag | Für die Überweisung vorgesehener Betrag nach Berücksichtigung aller Zu- und Abschläge |

Die Gebührenrichtlinie muss auch die Berechnungsgrundlage angeben. Es muss festgelegt werden, ob der Verkaufspreis vor dem Rabatt oder der Zahlungsbetrag nach dem Rabatt zugrunde gelegt wird, ob Versandkosten und Mehrwertsteuer enthalten sind und wie die Gebühr bei einer teilweisen Rückerstattung rückgängig gemacht wird.

Es ist sicherer, Geldbeträge nicht mit Gleitkommadatentypen zu berechnen. Bei Währungen wie dem koreanischen Won, deren kleinste Währungseinheit ganzzahlig ist, werden die Beträge als Ganzzahlen gespeichert. Sind Fremdwährungen oder Dezimalberechnungen erforderlich, werden Festkommadatentypen und währungsspezifische Rundungsregeln verwendet.

### 3. Rückerstattungen und negative Abrechnungen

Eine bereits an den Verkäufer ausgezahlte Bestellung kann später rückerstattet werden. In diesem Fall müssen der Rückerstattungsbetrag und die zurückzuerstattende Gebühr im Anpassungsbuch erfasst und vom nächsten Auszahlungsbetrag abgezogen werden.

Beträgt der für diese Abrechnung vorgesehene Betrag beispielsweise 300.000 Won und der rückerstattungsbezogene Abzugsbetrag aus einer früheren Bestellung 400.000 Won, kann dies wie folgt behandelt werden.

- Diesmaliger Auszahlungsbetrag: 0 Won
- Nicht eingezogener Saldo: minus 100.000 Won
- Auf die nächste Abrechnung zu übertragender Betrag: Abzug von 100.000 Won

Die Richtlinie muss folgende Punkte enthalten.

- Verteilung von Warenpreis, Versandkosten und Gebühren bei teilweisen Rückerstattungen
- Übertragungszeitraum für negative Salden und Reihenfolge der Verrechnung
- Einzugsverfahren bei Verkäufern, die über einen langen Zeitraum keine Verkäufe tätigen
- Vertragliche Grundlage für Kautionen oder Auszahlungsreserven
- Verfahren zur Prüfung offener Verpflichtungen vor dem Austritt eines Verkäufers
- Gegenbuchungsverfahren bei der Stornierung einer Rückerstattung oder Änderung des Ergebnisses eines Streitfalls

Bestehende Transaktionsdatensätze dürfen nicht überschrieben werden; stattdessen müssen die ursprüngliche Transaktion und die Anpassungstransaktion miteinander verknüpft werden. Nur so lässt sich nachvollziehen, welche Rückerstattung welche Abrechnung verändert hat.

### 4. Auszahlungssperre und Freigabe

Statt die Auszahlungen für ein gesamtes Verkäuferkonto pauschal auszusetzen, müssen sie nach Bestellung, Betrag oder Grund gesperrt werden können. Typische Gründe für eine Sperre sind:

- Laufender Verbraucherstreit oder laufende Rücksendung
- Verdacht auf Scheingeschäfte, Kontoübernahme oder ungewöhnliche Zahlungen
- Fehlgeschlagene Identitäts-, Unternehmens- oder Kontoverifizierung des Verkäufers
- Rechtmäßige Anforderung eines Gerichts, einer Ermittlungsbehörde oder einer zuständigen Stelle
- Nichtvorlage vertraglich erforderlicher Abrechnungsunterlagen

Für jede Sperre werden Zielbetrag, Grundcode, Belege, Beginn, Prüffrist, zuständige Person und Freigabebedingungen gespeichert. In der Verkäuferansicht werden, soweit offengelegt werden darf, der gesperrte Betrag, der Grund, erforderliche Maßnahmen und Kontaktwege angezeigt.

Damit Betreiber Sperren nicht willkürlich wiederholt verhängen können, sollten die Berechtigungen zum Anlegen und Freigeben getrennt und für die Freigabe großer gesperrter Beträge eine doppelte Genehmigung vorgesehen werden.

### 5. Getrennte Verwaltung von Verkaufserlösen sowie PG- und Treuhandstruktur

Werden noch nicht ausgezahlte Verkaufserlöse und betriebliche Mittel des Unternehmens wie dieselbe verfügbare Liquidität verwaltet, kann sich ein Liquiditätsmangel unmittelbar in ausstehenden Abrechnungen niederschlagen. Zumindest in der internen Buchführung und Kontenführung müssen Gelder im Zusammenhang mit Verkaufserlösen und Betriebsmittel klar getrennt sowie die Salden täglich abgeglichen werden.

Die bloße Einrichtung eines separaten Kontos führt jedoch nicht automatisch zu einer rechtlichen Insolvenzfestigkeit oder einem vollständigen Schutz der Gelder. Die Wirksamkeit und die Pflichten von Schutzmechanismen wie Treuhandverwaltung, Hinterlegung und Auszahlungsgarantien müssen anhand der geltenden Rechtsvorschriften und der Vertragsstruktur geprüft werden.

Je nachdem, welche Rolle die Plattform im Zahlungs- und Auszahlungsprozess übernimmt, kann nach dem Gesetz über elektronische Finanztransaktionen eine Registrierungspflicht, etwa als elektronischer Zahlungsabwickler, entstehen. Nicht jede Plattform unterliegt gleichermaßen der PG-Registrierungspflicht, und auch die bloße Berechnung von Abrechnungsdaten führt nicht immer zu einer Registrierungspflicht. Entscheidend sind die tatsächliche Art der Entgegennahme, Verwahrung und Weiterleitung von Geldern sowie die Vertragsbeziehungen.

Plattformen in der Anfangsphase können Zahlungs-, Treuhand- oder verkäuferspezifische Split-Abrechnungsdienste registrierter PG prüfen. Doch auch bei Nutzung eines PG entfallen folgende Verantwortlichkeiten nicht.

- Entscheidung, welche Bestellungen wann zur Auszahlung übermittelt werden
- Berechnung von Gebühren und Anpassungsbeträgen
- Verwaltung von Rückerstattungen und dem Übertrag negativer Salden
- Überprüfung von Verkäuferdaten und Konten
- Abgleich der PG-Ergebnisse mit dem internen Hauptbuch
- Reaktion auf Störungen und fehlgeschlagene Auszahlungen

Da auch Treuhandpflichten und Ausnahmen je nach Transaktionsart und Zahlungsmittel variieren, müssen das Gesetz über den elektronischen Geschäftsverkehr und die entsprechenden untergeordneten Vorschriften geprüft werden.

### 6. Quellensteuer, Mehrwertsteuer und Nachweise

Die Regel „Bei privaten Verkäufern werden immer 3,3 % einbehalten“ ist nicht korrekt. 3,3 % ist eine übliche Bezeichnung für die Summe aus 3 % Einkommensteuer auf Geschäftseinkünfte und 0,3 % lokaler Einkommensteuer für Privatpersonen. Ob tatsächlich Quellensteuer einbehalten wird, hängt nicht nur davon ab, ob der Verkäufer ein Gewerbe angemeldet hat, sondern auch von der Art der Einkünfte, dem Vertragsverhältnis, dem Auszahlungsposten und den Ausnahmeregelungen.

Bei der Registrierung und beim Vertragsabschluss müssen folgende Angaben erhoben werden.

- Verkäufertyp, etwa Privatperson, Einzelunternehmer oder juristische Person
- Status als inländischer oder ausländischer Ansässiger beziehungsweise als inländische oder ausländische juristische Person
- Steuerlicher Status wie steuerpflichtig, steuerbefreit oder vereinfachte Besteuerung
- Für gesetzliche Meldungen erforderliche Angaben wie Gewerberegisternummer und Einwohnerregistrierungsnummer
- Art der Einkünfte und Grund der Auszahlung
- Erforderliche Nachweise wie Steuerrechnung, Rechnung oder Quellensteuerbescheinigung

Auch bei gewerblichen Verkäufern darf nicht pauschal angenommen werden, dass „immer 100 % ohne jeglichen Steuerabzug ausgezahlt werden“. Sieht der Vertrag einen Abzug der Plattformgebühr vor, müssen der Gesamtbetrag der Transaktion, die Gebühr, die Mehrwertsteuer und der tatsächlich überwiesene Betrag getrennt ausgewiesen werden. Wer zu welchem Zeitpunkt eine Steuerrechnung für die Gebühren der von der Plattform erbrachten Vermittlungsleistung ausstellt, wird ebenfalls entsprechend dem vertraglichen und steuerrechtlichen Leistungsverhältnis festgelegt.

Für Quellensteuern gilt üblicherweise eine Struktur, bei der sie bis zum 10. des Monats gemeldet und abgeführt werden, der auf den Monat des Auszahlungstages folgt. Da jedoch Ausnahmen oder Friständerungen möglich sind, müssen die zum tatsächlichen Meldezeitpunkt geltenden Vorschriften geprüft werden. Sicherer ist es, Steuervorschriften nicht fest im Code zu verankern, sondern als versionierte Richtlinien mit Gültigkeitsbeginn und -ende zu verwalten.

### 7. Fehlgeschlagene Auszahlungen, Abrechnungsverwaltung und Audit-Logs

Auch ordnungsgemäß erzeugte Auszahlungen können aufgrund fehlerhafter Kontodaten, eines abweichenden Kontoinhabers, von Transaktionsbeschränkungen, Bankwartungen oder PG-Störungen fehlschlagen. Ein Fehlschlag darf nicht einfach als „nicht ausgezahlt“ markiert werden; Status und Regeln für die erneute Verarbeitung müssen differenziert werden.

Empfohlene Statusbeispiele:

- `scheduled`: Auszahlung vorgemerkt
- `submitted`: Anfrage an Bank oder PG übermittelt
- `processing`: Verarbeitung durch externe Stelle
- `paid`: Erfolg bestätigt
- `failed_retryable`: Erneut versuchbarer Fehlschlag
- `failed_final`: Endgültiger Fehlschlag, der etwa eine Korrektur der Angaben erfordert
- `reversed`: Stornierung oder Rückbuchung nach erfolgreicher Auszahlung

Für erneute Versuche muss ein Idempotenzschlüssel verwendet werden, der dieselbe Auszahlung identifiziert. Da eine Antwortverzögerung fälschlicherweise als Fehlschlag gewertet und durch eine erneute Überweisung eine doppelte Zahlung ausgelöst werden kann, muss zunächst anhand der externen Transaktionsnummer das Ergebnis der bestehenden Anfrage abgefragt werden.

Im Audit-Log werden folgende Angaben erfasst.

- Handelnde Person und verwendetes Betreiberkonto
- Sicherheitsinformationen wie Ausführungszeitpunkt und Zugriffsort
- Werte vor und nach der Änderung
- Gründe für Sperren, Freigaben und manuelle Anpassungen
- Genehmigende und ausführende Person
- Zugehörige Bestellung, Abrechnungslauf und externe Transaktionsnummer
- Fehlercode und Verlauf erneuter Versuche

Audit-Logs müssen so geschützt werden, dass gewöhnliche Betreiber sie weder bearbeiten noch löschen können. Für personenbezogene Daten und Finanzinformationen gelten Datensparsamkeit, Zugriffskontrollen, Verschlüsselung und Aufbewahrungsrichtlinien.

## Mindestumfang des Abrechnungsdatenmodells

Statt AI zuerst Benutzeroberflächen erstellen zu lassen, sollten zunächst die folgenden Bücher definiert werden.

| Datenobjekt | Aufgabe |
|---|---|
| Bestellbuch | Erfassung des Status von Bestellung, Zahlung, Lieferung und Kaufbestätigung |
| Abrechnungsposten | Erfassung von Gesamtbetrag, Gebühren, Steuern, Anpassungsbetrag und zugeordnetem Verkäufer je Bestellung |
| Anpassungsbuch | Erfassung von Rückerstattungen, Entschädigungen, Vertragsstrafen und manuellen Anpassungen |
| Sperrbuch | Erfassung von gesperrtem Betrag, Grund, Frist und Freigabeverlauf |
| Abrechnungslauf | Bündel der Auszahlungen für einen bestimmten Zeitraum und Verkäufer |
| Auszahlungsbuch | Erfassung von Überweisungsanfragen, Erfolg oder Fehlschlag und externer Transaktionsnummer |
| Steuerbuch | Erfassung von Quellensteuer sowie Status der Ausstellung und Meldung von Nachweisen |
| Audit-Log | Erfassung aller wichtigen Änderungen durch Betreiber und System |

Jedes Buch muss Angaben zu Währung, Richtlinienversion und Erstellungszeitpunkt sowie einen Verknüpfungsschlüssel zur ursprünglichen Transaktion enthalten. Allein durch die Änderung des Bestellstatus dürfen sich vergangene Abrechnungsbeträge nicht unbemerkt ändern.

## Zwingend einzuhaltende Kontrollregeln

Das Abrechnungssystem muss folgende Invarianten automatisch prüfen.

- Jeder Abrechnungsposten ist genau einem Verkäufer und einer ursprünglichen Transaktion zugeordnet.
- Mit demselben Auszahlungsschlüssel wird nicht zweimal überwiesen.
- Die Summe aus abgeschlossenen Auszahlungen, ausstehenden Beträgen, gesperrten Beträgen und Anpassungsbeträgen stimmt mit dem Hauptbuch überein.
- Für jede manuelle Anpassung gibt es einen Grund und eine genehmigende Person.
- Bereits abgeschlossene Abrechnungen werden nicht geändert, sondern durch Gegenbuchungen und neue Anpassungen korrigiert.
- Abweichungen zwischen internen Salden im Zusammenhang mit Verkaufserlösen und den Salden bei PG und Banken werden täglich untersucht.
- Bei Steuer- und Gebührenberechnungen wird die angewandte Richtlinienversion erfasst.

## Beispiel für eine an AI zu übergebende Richtlinienspezifikation

Werden die Anforderungen wie folgt strukturiert, lassen sich Auslassungen reduzieren.

> Bestellstatus und Abrechnungsstatus sind getrennt zu gestalten. Zu implementieren sind Bedingungen für die Kaufbestätigung nach Transaktionsart, ein Auszahlungslauf jeden Mittwoch, die Feiertagsbehandlung, die Gebührenberechnungsgrundlage, die Verteilung bei Teilrückerstattungen, der Übertrag negativer Salden, Auszahlungssperren für einzelne Vorgänge, versionierte Quellensteuerrichtlinien, Idempotenzschlüssel für Auszahlungen und unveränderliche Audit-Logs. Geldbeträge sind als Ganzzahlen oder Festkommazahlen zu verarbeiten. Jede manuelle Anpassung erfordert eine doppelte Genehmigung und einen Grund. Vor der Implementierung sind noch nicht festgelegte Richtlinien wie Mindestauszahlungsbetrag, Zeitraum bis zur automatischen Kaufbestätigung, langfristiger Einzug negativer Salden, Sperrfrist und Anzahl erneuter Versuche als Fragenliste vorzulegen.

Von AI darf nicht nur Code verlangt werden, sondern auch folgende Ergebnisse.

- Zustandsübergangsdiagramm und Liste der Ausnahmefälle
- Datenbankschema und Einschränkungen
- Berechtigungs- und Genehmigungssystem
- Tests für Normalfälle, Grenzwerte, Störungen und doppelte Anfragen
- Format des täglichen Abgleichsberichts
- Verfahren zur Wiederherstellung nach Störungen und zur manuellen Verarbeitung
- Prüfliste zum Schutz personenbezogener Daten und Finanzinformationen

## Prüfliste vor der Einführung

- [ ] Der Abrechnungsstichtag ist für jede Transaktionsart dokumentiert.
- [ ] Verkäufer können die Abrechnungsaufstellung auf Bestellungsebene nachrechnen.
- [ ] Tests für Teilrückerstattungen und den Übertrag negativer Salden wurden bestanden.
- [ ] Gründe und Fristen für Sperren sowie Freigabeberechtigungen sind definiert.
- [ ] Die Verwaltungskriterien für Gelder im Zusammenhang mit Verkaufserlösen und für Betriebsmittel sind voneinander getrennt.
- [ ] Mit Fachleuten wurde geprüft, ob die Regelungen für PG, Treuhanddienste und elektronische Finanzdienstleister anwendbar sind.
- [ ] Die steuerliche Behandlung nach Verkäufer- und Einkommensart wurde geprüft.
- [ ] Tests zur Verhinderung doppelter Zahlungen und zu erneuten Versuchen nach Fehlschlägen wurden abgeschlossen.
- [ ] Ein täglicher Abgleich zwischen Bank, PG und internem Hauptbuch ist möglich.
- [ ] Manuelle Änderungen durch Betreiber werden im Audit-Log erfasst.
- [ ] Für Abrechnungsstörungen bestehen Verfahren zur Information der Verkäufer und zur Bearbeitung von Anfragen.

## Fazit

Der Ausgangspunkt eines sicheren Abrechnungssystems ist nicht ein AI-Prompt, sondern sind ausdrücklich festgelegte Richtlinien und getrennte Bücher. AI ist als Werkzeug einzusetzen, um festgelegte Regeln in Code, Tests und Dokumentation zu übertragen. Die Struktur der Geldverwahrung sowie Beurteilungen zum elektronischen Finanzwesen und zum Steuerrecht müssen gemeinsam mit PG, Fachleuten für Rechnungswesen und Steuern sowie Rechtsexperten überprüft werden.

## FAQ

### Ist die Abrechnung eine Funktion, bei der lediglich die Gebühren vom Verkaufsbetrag abgezogen werden?
Nein. Die Abrechnung umfasst die Kaufbestätigung, Teilerstattungen, Auszahlungssperren, die Übertragung negativer Salden, Steuern, fehlgeschlagene Überweisungen, die Verhinderung doppelter Auszahlungen und den Abgleich mit dem Hauptbuch. Neben einer Berechnungsformel sind auch Statusübergänge und die Kontrolle der Geldflüsse erforderlich.

### Muss der Stichtag für die Abrechnung zwingend das Datum der Kaufbestätigung sein?
Ein einheitlicher Maßstab lässt sich nicht pauschal auf alle Transaktionen anwenden. Bei physischen Waren kann die Kaufbestätigung oder eine automatische Bestätigung herangezogen werden, doch bei Dienstleistungen, digitalen Inhalten und Reservierungsprodukten gelten unterschiedliche Voraussetzungen für den Abschluss der Leistungserbringung. Für jede Transaktionsart müssen sowohl das maßgebliche Ereignis als auch die gesetzliche bzw. vertragliche Zahlungsfrist festgelegt werden.

### Ist ein kürzerer Abrechnungszyklus immer besser?
Ein kurzer Zyklus reduziert ausstehende Beträge und die Liquiditätsbelastung der Verkäufer, doch Rücksendungen, verdächtige Transaktionen und Betriebskosten müssen berücksichtigt werden. Statt den Zyklus unter Berufung auf Risiken unnötig zu verlängern, ist es wichtig, eine den Transaktionsmerkmalen angemessene Mindestprüffrist und einen vorhersehbaren Auszahlungstermin festzulegen.

### Muss die Plattform keine Abrechnungsrichtlinien erstellen, wenn sie einen PG nutzt?
Nein. Ein PG kann Funktionen für Zahlungen, Geldtransfers, Treuhandzahlungen oder geteilte Auszahlungen bereitstellen, doch welche Bestellungen wann ausgezahlt werden, wie Gebühren und Erstattungsbeträge berechnet werden und wessen Auszahlung zurückgehalten wird, hängt von den Richtlinien der Plattform ab.

### Muss bei allen privaten Verkäufern eine Quellensteuer von 3,3 % einbehalten werden?
Nein. 3,3 % ist üblicherweise eine zusammenfassende Bezeichnung für die Quellensteuer auf gewerbliche Einkünfte und die lokale Einkommensteuer für natürliche Personen. Ob eine Quellensteuer einzubehalten ist und welcher Steuersatz gilt, muss nicht nur anhand der Registrierungsform des Verkäufers, sondern auch anhand der Art der Einkünfte, des Vertragsverhältnisses, des Wohnsitzstatus und der Ausnahmeregelungen beurteilt werden.

### Ist der Verkaufserlös vollständig sicher, wenn er auf einem separaten Konto verwahrt wird?
Ein separates Konto ist eine grundlegende Kontrollmaßnahme zur Trennung von Betriebsmitteln und Verkaufserlösen, gewährleistet jedoch für sich genommen weder Insolvenzfestigkeit noch rechtlichen Schutz. Es ist erforderlich, die notwendigen Schutzmechanismen wie Treuhandverwaltung, Hinterlegung oder Zahlungsgarantie sowie die Rechtsnatur des Kontos anhand des Vertrags und der geltenden Rechtsvorschriften zu prüfen.

### Wie sind negative Abrechnungen zu erfassen?
Der Erstattungsbetrag für eine bereits ausgezahlte Bestellung wird als separate Korrekturtransaktion erfasst und von der nächsten Auszahlung abgezogen. Ist der Abzugsbetrag höher als der vorgesehene Auszahlungsbetrag, wird der Auszahlungsbetrag auf 0 Won gesetzt und der verbleibende Saldo auf die nächste Abrechnung übertragen. Die ursprüngliche Transaktion darf weder gelöscht noch darf eine frühere Abrechnung überschrieben werden.

### Kann ich eine Überweisungsanfrage sofort erneut senden, wenn ich keine Antwort erhalte?
Nein. Die erste Anfrage könnte tatsächlich erfolgreich gewesen sein, während lediglich die Antwort verloren ging. Um eine doppelte Auszahlung zu verhindern, müssen für dieselbe Zahlung ein Idempotenzschlüssel und eine externe Transaktionsnummer verwendet und vor einem erneuten Versuch das Ergebnis der bisherigen Verarbeitung beim Zahlungsdienstleister oder bei der Bank abgefragt werden.

### Kann von KI generierter Abrechnungscode direkt im Produktivbetrieb eingesetzt werden?
Das wird nicht empfohlen. Zustandsübergänge, die Konsistenz des Hauptbuchs, Nebenläufigkeit, doppelte Anfragen, Teilerstattungen, die Wiederherstellung nach Ausfällen und die Zugriffskontrolle müssen getestet werden. Fragen zum elektronischen Zahlungsverkehr und zu Steuern sollten zudem anhand der tatsächlichen Geschäftsstruktur von Fachleuten geprüft werden.

## Sources

- [Gesetz über elektronische Finanztransaktionen](https://www.law.go.kr/법령/전자금융거래법)
- [Gesetz über den Verbraucherschutz im elektronischen Geschäftsverkehr usw.](https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률)
- [Einkommensteuergesetz](https://www.law.go.kr/법령/소득세법)
- [Gesetz über Kommunalsteuern](https://www.law.go.kr/법령/지방세법)
- [Mehrwertsteuergesetz](https://www.law.go.kr/법령/부가가치세법)

## Images

![쇼핑몰과 정산·보안·검증 단계를 연결한 AI 자동화 흐름도](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzI4NCwicHVyIjoiYmxvYl9pZCJ9fQ==--327ce77d86d637d351158c65c70ddfacddacae1e/ai-ed29586c.webp)
![보안 방패, 정책 단계, 자금 보관함과 금융기관이 연결된 AI 정산 시스템 일러스트](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzI5MCwicHVyIjoiYmxvYl9pZCJ9fQ==--128e8c8dd212c1da8f86663e5bcd292ceb74aec1/ai-1bda19eb.webp)