Nebenbücher für Marktplatz-Verkäufer: Umsatzerlöse vs. Verbindlichkeiten

Der häufigste Fehler in der Marktplatz-Buchhaltung ist es, die Bruttozahlung des Käufers als Plattformumsatz zu behandeln. Ein Kunde zahlt €100, diese €100 landen auf dem Konto des Zahlungsdienstleisters (Payment Processor) und jemand bucht den gesamten Betrag als Umsatzerlös. Die Bücher stimmen eine Zeit lang, der Umsatz sieht hervorragend aus, und dann fragt der Wirtschaftsprüfer, wo die Verbindlichkeit gegenüber dem Verkäufer geblieben ist. Es gibt keine, da die €90 des Verkäufers nie als geschuldeter Betrag erfasst wurden.

Die Lösung ist struktureller, nicht kosmetischer Natur. Ein Marktplatz benötigt ein Hauptbuchmodell (Ledger Model), das ab der ersten Buchung fünf klare Töpfe voneinander trennt: unterwegs befindliche Kundengelder (Cash in Transit), Plattformprovisionen, Verbindlichkeiten gegenüber Verkäufern, Gebühren und Sicherheitsrückbehalte (Reserves). Auszahlungen sind ein sechstes Ereignis, das die Verbindlichkeit ausgleicht, und kein eigenständiges Ertrags- oder Aufwandsereignis. Dieser Leitfaden zeigt die ausgeglichenen Buchungssätze und das Datenmodell, mit denen diese Töpfe sauber getrennt bleiben.

Beginnen Sie mit der Prinzipal-versus-Agent-Einschätzung

Bevor die Kontenstruktur überhaupt eine Rolle spielt, muss die Plattform entscheiden, was sie eigentlich verkauft. Nach ASC 606 wird dies für jede spezifizierte Ware oder Dienstleistung einzeln beurteilt, und die Antwort bestimmt, ob der Umsatz brutto oder netto ausgewiesen wird. Eine Plattform kann für den einen Zahlungsstrom Prinzipal und für einen anderen Agent sein.

Bei einem typischen Marktplatzverkauf von Waren eines Verkäufers ist die Plattform in der Regel der Agent. Sie arrangiert lediglich, dass das Produkt des Verkäufers zum Käufer gelangt, übernimmt kein Bestandsrisiko und ihre Gegenleistung (Consideration) besteht aus einer Provision. Der Leitfaden von Deloitte zum Prinzipal-versus-Agent-Prinzip nach ASC 606 stellt die Verfügungsgewalt (Control) in den Mittelpunkt der Prüfung: Die Verantwortung für die Erfüllung der Leistungszusage, das Bestandsrisiko und die Preisfestsetzungshoheit sind lediglich Indikatoren, keine Checkliste, die die zugrunde liegende Beurteilung der Verfügungsgewalt außer Kraft setzt.

Der Grund, warum dies in das Design des Hauptbuchs und nicht nur in ein Aktenmemo gehört, ist, dass diese Einschätzung jede nachfolgende Buchung bestimmt. Ist die Plattform ein Agent, ist der Anteil des Verkäufers ab dem Moment der Entstehung eine Verbindlichkeit. Tritt sie bei einer Fulfillment- oder Garantiedienstleistung als Prinzipal auf, stellt dieser Teil einen Plattformumsatz dar. Hinterlegen Sie diese Schlussfolgerung als Datenpunkte:

• principal_agent_role
• specified_good_or_service
• commission_rule_id
• control_assessment_version
• effective_from / effective_to

Ein Wirtschaftsprüfer, der sich zwei Jahre später eine Netto-Provisionszeile ansieht, sollte nachvollziehen können, warum nicht brutto gebucht wurde. Wie BillingPlatform zum Thema ASC 606 Prinzipal vs. Agent anmerkt, wird die Frage nicht durch das bloße Etikett „Marktplatz“ beantwortet, sondern durch die Analyse der Verfügungsgewalt.

Definieren Sie das Verkäuferguthaben, bevor Sie auch nur eine Buchungsregel erstellen

Das „Verkäuferguthaben“ (Seller Balance) ist nicht nur eine einzelne Zahl. Ein Verkäufer kann ein gesundes Gesamtguthaben aufweisen, aber keinen auszahlungsfähigen Betrag, weil das Geld noch ausstehend ist oder als Sicherheit zurückbehalten wird. Wenn Sie diese Status vermischen, weisen Sie unzutreffend aus, was der Verkäufer abheben kann und was die Plattform ihm noch schuldet.

Erfassen Sie mindestens:

• Ausstehend (Pending): verdient oder eingezogen, aber noch nicht auszahlungsberechtigt
• Verfügbar (Available): gemäß den Plattformrichtlinien für die Auszahlung berechtigt
• Einbehalten (Reserved): einbehalten für erwartete Rückerstattungen, Streitfälle oder Rückbuchungen (Chargebacks)
• Ausgezahlt (Paid out): überwiesen oder zur Verrechnung eingereicht
• Negativ (Negative): Betrag, den der Verkäufer schuldet; aus künftigen Erlösen rückforderbar
• Ungeklärt (Suspense): erhalten, aber Verkäufer oder genaue Behandlung noch nicht zugeordnet

Zahlungsanbieter bilden diese Unterscheidung bereits ab. Stripe unterteilt jedes verbundene Konto in ausstehende und verfügbare Salden und führt auf Plattformebene einen Sicherheitsrückbehalt für bestimmte negative Verkäufersalden. Wenn der Zahlungsdienstleister diese trennt, muss das Hauptbuch (General Ledger) dies ebenfalls tun, andernfalls wird die Kontenabstimmung (Reconciliation) niemals aufgehen.

Der Kontenplan und die entscheidenden Dimensionen

Eine funktionierende Ausgangsstruktur trennt Verrechnungskonten (Clearing Accounts), Verbindlichkeiten und Umsätze strikt voneinander und versieht jede wesentliche Buchung mit einer Verkäufer-Dimension.

Zweck	Konto oder Dimension	Behandlung
Gelder beim Zahlungsdienstleister, die auf Abrechnung warten	Verrechnungskonto Zahlungsdienstleister	Aktives Verrechnungskonto
Auszahlung vom Zahlungsdienstleister auf das Bankkonto	Bank	Aktivkonto
Verdienter, aber noch nicht ausgezahlter Verkäuferbetrag	Verbindlichkeiten gegenüber Verkäufern	Passivkonto (Verbindlichkeit)
Details auf Verkäuferebene	seller_id-Dimension	Verbindlichkeitsdetail, kein Umsatz
Plattformprovision	Provisionserlöse	Umsatzerlös
Umsatzsteuer oder Sales Tax	Umsatzsteuer-Verbindlichkeit	Passivkonto (Verbindlichkeit)
Gebühren des Zahlungsdienstleisters	Aufwand für Zahlungsabwicklung	Aufwand
Sicherheitsrückbehalte des Verkäufers	Verbindlichkeit aus Rückbehalten	Vertragsabhängig
Rückerstattungen	Erlösschmälerung (Contra-revenue) oder Rückerstattungen	Kehrt die ursprüngliche Buchung um
Rückbuchungen (Chargebacks)	Verlust, Forderung oder Rückforderung vom Verkäufer	Abhängig davon, wer den Verlust trägt
Auszahlungen, die auf Bankbestätigung warten	Verrechnungskonto für Verkäuferauszahlungen	Verrechnungskonto
Nicht zugeordnete Beträge	Klärungskonto (Suspense)	Temporäre Ausnahme

Jede wesentliche Buchung sollte Verkäufer, Bestellung, Auszahlungs-Batch, Zahlungsdienstleister, Währung, Rechtsträger, steuerliche Behandlung, Ereignistyp, externe Referenz und einen Verweis auf eventuelle Stornierungen enthalten. Ohne diese Angaben kann das Verkäufer-Nebenbuch (Subledger) keinen individuellen Saldo und das Hauptbuch nicht die Gesamtsumme nachweisen.

Sie können das Nebenbuch als ein Verbindlichkeitskonto pro Verkäufer, als ein aggregiertes Verbindlichkeitskonto mit seller_id als Dimension oder aufgeteilt in Verbindlichkeiten, Rückbehalte und Auszahlungsverrechnung implementieren. Der Ansatz mit Sammelkonto plus Dimension skaliert besser, sobald Sie mehr als ein paar Dutzend Verkäufer haben. Wählen Sie das Modell gemeinsam mit Ihrem Buchhalter aus, da Safeguarding-Vorschriften und lokale Zahlungsregularien die Art der Darstellung von Geldern beeinflussen können. Was die Mechanik hinter den Buchungen betrifft, so behandelt unser Artikel über Double-Entry-Ledger-APIs für die Marktplatz-Buchhaltung die grundlegenden Ledger-Bausteine, auf denen dieses Modell beruht.

Buchen Sie den Verkauf mit getrennten Zeilen für Verkäufer und Plattform

Nehmen wir einen Agenten-Verkauf: Der Kunde zahlt €100, die Plattformprovision beträgt €10, der Verkäufer verdient €90. Zum Zeitpunkt, an dem die Provision und der Anspruch des Verkäufers entstehen, sieht das so aus:

Konto	Soll	Haben
Verrechnungskonto Zahlungsdienstleister	€100
Verbindlichkeit gegenüber Verkäufer – Verkäufer A		€90
Provisionserlöse		€10

Die entscheidende Kontrolle: Die €90 gehen im Haben auf ein Verbindlichkeitskonto, nicht auf ein Umsatzkonto. Die Plattform erfasst €10 als Umsatz. Genau dieses Ergebnis liefert das Marktplatz-Beispiel unter ASC 606 für einen Agenten, bei dem die Plattform ihre Provision und nicht den gesamten Verkaufsbetrag des Verkäufers als Umsatz erfasst.

Falls Steuern separat erhoben werden, fügen Sie die Zeile für die Umsatzsteuer-Verbindlichkeit hinzu und reduzieren den Verkäufer- oder Plattformbetrag entsprechend der steuerlichen Einschätzung. Schlagen Sie die Steuer nicht aus Bequemlichkeit der Provision oder der Verbindlichkeit gegenüber dem Verkäufer zu.

Halten Sie die Gebühren des Zahlungsdienstleisters aus der Umsatz- und Verbindlichkeitsberechnung heraus

Drei Dinge werden ständig verwechselt: Plattformprovision, Gebühr des Zahlungsdienstleisters und Auszahlungsbetrag. Diese sind unterschiedlich und betreffen verschiedene Konten.

Der Kunde zahlt €100, die Provision beträgt €10, der Zahlungsdienstleister behält €3 ein.

• Die Provisionserlöse bleiben bei €10, wenn dies vertraglich so vereinbart ist.
• Die Gebühr von €3 für den Zahlungsdienstleister ist ein Aufwand.
• Die Verbindlichkeit gegenüber dem Verkäufer beträgt €90, es sei denn, der Verkäufervertrag besagt, dass der Verkäufer die Bearbeitungsgebühr trägt. Nur dann sinkt sie auf €87 und dem Verkäufer werden entsprechend €3 in Rechnung gestellt.

Wenn Sie nur die €97 netto buchen, die auf dem Bankkonto landen, löschen Sie den Bruttoumsatz, die Provision und die Gebühr in einem einzigen Schritt aus. Unser Referenzleitfaden zur Zahlungsabstimmung bringt dasselbe auf den Punkt: Schlüsseln Sie die Abrechnung auf, behandeln Sie die Gebühren des Zahlungsdienstleisters als Aufwand und lassen Sie niemals die Nettoeinlage als Umsatz stehen.

Modellieren Sie Verfügbarkeit, Rückbehalte und Auszahlungen als separate Ereignisse

Geld ändert mehrmals seinen Status zwischen Einzug und abgerechneter Zahlung. Jeder Übergang erfordert eine eigene Buchung, und ein Sicherheitsrückbehalt ist niemals eine unerklärte Umsatzkürzung.

Wenn verfügbare Gelder in den Rückbehalt verschoben werden:

Konto	Soll	Haben
Verbindlichkeit gegenüber Verkäufer – Verkäufer A	€15
Verbindlichkeit aus Verkäufer-Rückbehalten		€15

Wenn der Rückbehalt freigegeben wird, stornieren Sie dies. Die Gesamtverbindlichkeit gegenüber dem Verkäufer hat sich nicht geändert, nur ihr Status. Stripe dokumentiert Reserve-Transaktionen, die Rückbehalte erhöhen und freigeben, sowie Inkassoüberweisungen für langjährige negative Salden. Genau deshalb bedarf es hierfür eindeutig identifizierbarer Konten anstelle einer einzigen Verrechnungsbuchung.

Auszahlungen werden in einem eigenen zweistufigen Verfahren behandelt. Bei Freigabe:

Konto	Soll	Haben
Verbindlichkeit gegenüber Verkäufer – Verkäufer A	€90
Verrechnungskonto für Verkäuferauszahlungen		€90

Bei bestätigter Bankabrechnung:

Konto	Soll	Haben
Verrechnungskonto für Verkäuferauszahlungen	€90
Bank		€90

Schlägt die Auszahlung fehl, buchen Sie den Betrag vom Verrechnungskonto zurück in die Verkäuferverbindlichkeit. Eine Auszahlung ist der Ausgleich einer Verbindlichkeit und kein Aufwand. Wenn sie als Aufwand behandelt wird, kommt es zu einer Doppelzählung gegenüber dem Verkauf, bei dem die Verbindlichkeit bereits erfasst wurde. Stripe trennt den Auszahlungsstatus (pending, in_transit, paid, failed, canceled) und das erwartete Ankunftsdatum von der Initiierung, und diese Daten sollten nicht zu einem einzigen Zeitstempel zusammengefasst werden.

Das Order-to-Payout-Datenmodell

Das Nebenbuch arbeitet auf Basis von Ereignissen (Events) und nicht auf Basis des aktuellen Bestellstatus in der Anwendung. Jedes den Verkäufer betreffende Ereignis hat denselben „Briefumschlag“ (Envelope):

• seller_id, event_id, order_id
• event_type (sale, refund, chargeback, reserve_hold, reserve_release, payout, adjustment)
• effective_date, posting_date
• currency, direction, gross, commission, fees, reserve
• refund_ref / dispute_ref
• payout_batch_id
• reversal_of
• source_status, idempotency_key

Aus diesen Ereignissen errechnen Sie den Schlusssaldo, anstatt ein überschreibbares Feld zu speichern:

Seller closing balance
= opening balance
+ seller credits
− seller debits
− payouts
± reserve movements
± corrections

Jedes externe Ereignis benötigt einen dauerhaften Idempotenzschlüssel, damit Neuversuche (Retries) und doppelte Webhooks einen Verkäufer nicht doppelt gutschreiben oder eine Auszahlung doppelt anweisen. Bewährte Muster:

• Verkäufer-Journalereignis: seller_id:order_id:event_type:version
• Auszahlungs-Batch: processor:payout_id
• Dienstleister-Ereignis: processor:event_type:processor_event_id

Die Webhook-Richtlinien von Stripe warnen ausdrücklich, dass doppelte Ereignisse auftreten, weshalb eine Duplikatserkennung unverzichtbar ist. Gebuchte Posten bleiben unveränderlich. Korrekturen erfolgen über eine Stornobuchung plus eine korrigierte Buchung, und es ist Ihr eigener Event-Envelope, der den reversal_of-Link und den Grund enthält. Das Hauptbuch hält die Buchungen, nicht diesen Link: Nordlet bietet Create-, Get- und List-Funktionen für Journaltransaktionen in seiner API-Referenz an und keine Update- oder Delete-Funktionen, sodass eine Korrektur immer eine neue Transaktion und keine Bearbeitung ist.

Rückerstattungen und Rückbuchungen verweisen zurück, sie schweben niemals im luftleeren Raum

Eine Rückerstattung, die in der Auszahlung der nächsten Woche auftaucht, sollte niemals zu einem neuen negativen Verkauf werden, der an diese Auszahlung angehängt wird. Verknüpfen Sie sie mit der ursprünglichen Transaktion und bewahren Sie die ursprüngliche Verkäuferzuordnung. Je nach Vertrag:

• Provision stornieren, wenn diese laut Vertrag erstattungsfähig ist
• Verbindlichkeit gegenüber dem Verkäufer im Soll belasten, wenn der Verkäufer die Rückerstattung trägt
• Ein Plattform-Verlustkonto im Soll belasten, wenn die Plattform sie trägt
• Einen Rückbehalt erhöhen, solange ein Streitfall offen ist; bei Klärung freigeben oder verbrauchen

Bei Rückbuchungen nach der Auszahlung entstehen negative Salden. Das Geld des Verkäufers ist bereits weg, sodass die Plattform es entweder aus künftigen Erlösen zurückfordert oder den Verlust auf die eigene Kappe nimmt. Das Modell muss negative Verkäufersalden zulassen und die Rückforderungsregel definieren. Das Marktplatz-Reporting von Adyen zeigt, dass Rückerstattungen und Rückbuchungen separate Soll-Zeilen pro Kontoinhaber erzeugen – genau diese Granularität sollten Sie anstreben.

Stimmen Sie pro Auszahlung ab, nicht pro Monat

Schlüsseln Sie jede Abrechnung des Zahlungsdienstleisters vor der Buchung auf und stimmen Sie jede Auszahlung ab, anstatt einen ganzen Monat zu aggregieren:

Gross charges
− refunds
− processor fees
− chargebacks
± reserves and adjustments
= net processor payout

Weisen Sie dann nach, dass vier Salden für jeden Verkäufer und jede Währung übereinstimmen: das Verkäufer-Nebenbuch, das Verkäuferguthaben beim Zahlungsdienstleister, der Auszahlungsbericht und das Bank-Verrechnungskonto. Wenn diese abweichen, klassifizieren Sie die Differenz (zeitliche Abweichung, fehlendes Ereignis, Duplikat, falsche Zuordnung, falsche Währung, fehlgeschlagene Auszahlung, einem falschen Beteiligten zugerechnete Rückbuchung). Werden Differenzen einfach saldiert, heben sich Fehler gegenseitig auf und überdauern bis zum nächsten Monatsabschluss.

Die Aggregation eines ganzen Monats führt dazu, dass sich zeitliche Differenzen aufheben und echte Abweichungen verborgen bleiben. Ein Abgleich pro Auszahlung, der anhand der Auszahlungs-ID und der Transaktionsreferenz anstatt nach Betrag und Datum erfolgt, deckt diese auf.

Häufige Fehlerquellen

Fehlerquelle	Warum das zum Problem wird	Kontrolle
Kunden-Bruttozahlung wird als Umsatz gebucht	Bläht den Umsatz auf, verdeckt die Verbindlichkeit gegenüber dem Verkäufer	Trennen Sie Verbindlichkeit und Provision bei Entstehung des Anspruchs
Nur Nettoeinlagen werden gebucht	Verliert den Überblick über Bruttobetrag, Gebühren, Rückerstattungen, Rückbehalte	Schlüsseln Sie jede Abrechnung auf
Auszahlung wird als Aufwand gebucht	Weist einen Verbindlichkeitsausgleich falsch aus	Belasten Sie die Verkäuferverbindlichkeit im Soll bei Auszahlung
Nur ein einziges Feld für das Verkäuferguthaben	Vermischt ausstehende, verfügbare, einbehaltene und ausgezahlte Beträge	Erfassen Sie die Saldostatus explizit
Provision wird zum Zeitpunkt der Auszahlung berechnet	Umsatz richtet sich nach dem Auszahlungszeitplan	Erfassen Sie die Provision, wenn sie verdient ist
Rückbehalt wird als Umsatzkürzung behandelt	Verschleiert den zeitlichen Ablauf und das Risiko	Erfassen Sie Einbehaltung, Freigabe und Verbrauch getrennt
Rückerstattung wird der neuesten Auszahlung zugeordnet	Bricht die Zuordnung zur Bestellung	Verknüpfen Sie die Rückerstattung mit der ursprünglichen Transaktion
Bearbeiten bereits gebuchter Posten	Zerstört den Prüfpfad	Stornieren und neu buchen
Erneut gesendete Webhooks	Doppelte Gutschriften und Auszahlungen	Idempotenzschlüssel, Duplikatserkennung
Abgleich nur nach Betrag und Datum	Verschiedene Positionen kollidieren	Gleichen Sie nach Auszahlungs-ID, Transaktions-ID, Verkäufer und Währung ab

Was ich als Erstes tun würde

Skizzieren Sie den Geldfluss, bevor Sie den Kontenplan anfassen. Notieren Sie jedes Ereignis von der Zahlungserfassung bis zur Freigabe des Rückbehalts und markieren Sie, welche davon Umsätze generieren, welche eine Verbindlichkeit schaffen und welche lediglich den Status ändern.

Bauen Sie dann einen durchgängigen Flow und weisen Sie nach, dass dieser aufgeht: ein normaler Verkauf, eine teilweise Rückerstattung, eine Rückbuchung nach Auszahlung, ein einbehaltener und wieder freigegebener Rückbehalt sowie eine fehlgeschlagene Auszahlung. Spielen Sie dies mit zuvor berechneten Zielsalden durch. Wenn das Abstimmkonto der Verkäuferverbindlichkeiten der Summe des Nebenbuchs entspricht, das Verrechnungskonto des Dienstleisters mit dem Abrechnungsbericht übereinstimmt und die Bankeinzahlung zur Auszahlungs-ID passt, verfügen Sie über ein funktionierendes Rückgrat.

Aktivieren Sie die Periodensperre erst, wenn der erste Monat sauber und mit einem leeren Klärungskonto abgeschlossen wurde. Zu frühes Sperren zementiert lediglich Fehler.

Nordlet bucht Abrechnungen von Haus aus nach genau diesem Schema: Die Plattformprovision fließt in den Provisionserlös, der Anteil des Verkäufers in die Verkäuferverbindlichkeit, Gebühren für den Zahlungsdienstleister in den Aufwand für Zahlungsabwicklung und alles, was noch nicht zugeordnet ist, auf ein Klärungskonto. Ledger-Perioden bleiben so lange offen, bis Sie diese explizit sperren; so kann der erste Monat abgeschlossen werden, sobald das Klärungskonto auf null steht. Die Features-Seite listet auf, was alles enthalten ist.

FAQ

Ist die Zahlung des Käufers jemals ein Plattformumsatz?

Nur für die spezifischen Waren oder Dienstleistungen, bei denen die Plattform als Prinzipal auftritt. Bei einem Agenten-Verkauf von Waren eines Verkäufers über einen Marktplatz ist der Umsatz die Provision und der Anteil des Verkäufers eine Verbindlichkeit. Eine Plattform kann bei derselben Bestellung Prinzipal für eine Fulfillment-Dienstleistung und Agent für die zugrunde liegende Ware sein. Die Beurteilung erfolgt also je spezifizierter Ware oder Dienstleistung, nicht je Unternehmen.

Sollten Sicherheitsrückbehalte (Reserves) den Umsatz mindern?

Nein. Ein Rückbehalt ist eine zeitliche Verschiebung und Risikoallokation, keine Umsatzanpassung. Verschieben Sie Gelder aus der Verkäuferverbindlichkeit in eine Reserve-Verbindlichkeit, wenn Sie sie einbehalten, und machen Sie dies bei Freigabe rückgängig. Umsatz und Provisionen bleiben unberührt von der Tatsache, ob das Geld des Verkäufers derzeit als Sicherheit zurückbehalten wird.

Wie verhindere ich doppelte Auszahlungen durch Webhook-Neuversuche?

Versehen Sie jedes externe Ereignis mit einem Idempotenzschlüssel, wie z. B. processor:payout_id für Auszahlungs-Batches, und erkennen Sie doppelte Ereignisse beim Speichern. Anbieter weisen ausdrücklich darauf hin, dass Webhooks mehrfach gesendet werden können, sodass das Hauptbuch den zweiten Versuch zwingend abweisen muss, anstatt ihn erneut zu buchen.

Kann das Verkäuferguthaben negativ werden?

Ja, und das Modell muss dies zulassen. Eine Rückbuchung, die nach Auszahlung an den Verkäufer eingeht, führt für die Plattform entweder zu einer Forderung gegenüber dem Verkäufer oder zu einem Verlust, den sie selbst trägt. Das Unterdrücken negativer Salden verbirgt lediglich eine nicht erfasste Verpflichtung.

Warum sollte jede Auszahlung abgestimmt werden und nicht die Monatssumme?

Weil zeitliche Differenzen und Fehler sich aufheben, wenn Sie einen Monat aggregieren; somit können die Summen zwar stimmen, obwohl einzelne Transaktionen fehlerhaft sind. Eine Abstimmung auf Basis der einzelnen Auszahlung, abgeglichen anhand von Auszahlungs- und Transaktions-IDs, deckt fehlende Ereignisse, Duplikate und falsch zugeordnete Rückbuchungen noch vor dem Monatsabschluss auf.

Weiterführende Links

• Double-Entry-Ledger-APIs für die Marktplatz-Buchhaltung
• Zahlungsabstimmung: PSP-Auszahlungen mit dem Hauptbuch abgleichen
• ASC 606 Prinzipal-versus-Agent-Prinzip (Deloitte)