{"id":339500,"date":"2026-09-22T04:07:50","date_gmt":"2026-09-22T11:07:50","guid":{"rendered":"https:\/\/www.zuora.com\/guides\/ai-agent-marketplace-billing\/"},"modified":"2026-09-22T04:07:50","modified_gmt":"2026-09-22T11:07:50","slug":"ai-agent-marketplace-billing","status":"publish","type":"guides","link":"https:\/\/www.zuora.com\/de\/guides\/ai-agent-marketplace-billing\/","title":{"rendered":"Abrechnung f\u00fcr KI-Agent-Marktpl\u00e4tze: Umsatzbeteiligung, Abrechnungen, Steuern | Zuora"},"featured_media":0,"parent":0,"template":"page-knowledge-hub.php","content_type":[],"geo":[],"growth_initiatives":[],"parent_guide_categories":[],"industry":[],"persona":[],"product_line":[],"topic":[],"class_list":["post-339500","guides","type-guides","status-publish","hentry"],"acf":{"knowledge_hub_title":"Abrechnung, Umsatzbeteiligung und Abrechnungen f\u00fcr KI-Agent-Marktpl\u00e4tze","knowledge_hub_author":"","knowledge_hub_date":"20260922","knowledge_hub_read_time_label":"","knowledge_hub_secondary_category":"","knowledge_hub_category":"GUIDES","knowledge_hub_show_summary":true,"knowledge_hub_summary":"In diesem Leitfaden erl\u00e4utern wir, warum KI-Agent-Marktpl\u00e4tze eine Abrechnungsinfrastruktur ben\u00f6tigen, f\u00fcr die herk\u00f6mmliche SaaS-Systeme nie ausgelegt waren. Der Leitfaden zeigt, wie Ums\u00e4tze zwischen Plattform und Entwicklern aufgeteilt werden, wie Nutzung \u00fcber Multi-Agent-Workflows hinweg zugeordnet wird und wie Steuern, R\u00fcckerstattungen und Abrechnungen gehandhabt werden \u2013 und hebt die Entscheidungen hervor, die Marktplatzbetreiber vor der ersten Entwickler-Auszahlung treffen sollten.","knowledge_hub_featured_image":291462,"knowledge_hub_hero_media_content_group":{"knowledge_hub_is_vidyard_video":false,"knowledge_hub_vidyard_video_group":{"vidyard_id":""}},"knowledge_hub_show_toc":true,"toc_card_title":"Warum Zuora?","toc_card_description":"Von Abonnements und hybriden Bundles bis hin zu komplexer Nutzung und KI-Tokens \u2013 Zuora bietet die passenden L\u00f6sungen, um die gr\u00f6\u00dften Herausforderungen von CFOs mit einer einzigen Monetarisierungsplattform zu bew\u00e4ltigen.","toc_cta_label":"Demo ansehen","toc_cta_link":"https:\/\/www.zuora.com\/resources\/demo-on-demand\/","knowledge_hub_content":[{"acf_fc_layout":"knowledge_hub_intro","title":"Abrechnung, Umsatzbeteiligung und Abrechnungen f\u00fcr KI-Agent-Marktpl\u00e4tze","content":"<span style=\"font-weight: 400;\">Die Abrechnung in einem AI-Agenten-Marktplatz ist die Infrastruktur, die eine einzelne Kundentransaktion zwischen der Plattform und dem Drittanbieter-Entwickler aufteilt, dessen Agent die Leistung erbracht hat. Jede Transaktion umfasst mindestens drei Parteien. Erforderlich sind eine agentenbezogene Ereigniszuordnung (Event Attribution), ein definierter Umsatzverteilungsschl\u00fcssel, eine steuerliche Einstufung zur Frage, wer als \u201eSeller of Record\u201c gilt, sowie transaktionsbezogene Abrechnungs- und Auszahlungsnachweise (Settlement Statements) \u2014 nichts davon ist in einer Standard-SaaS-Abrechnung enthalten.<\/span>\n\n<b>TL;DR<\/b>\n<ul>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Die Abrechnung in einem Agenten-Marktplatz umfasst in jeder Transaktion mindestens drei Parteien (Plattform, Entwickler, Kunde) und erfordert eine Infrastruktur, f\u00fcr die Standard-SaaS-Abrechnungssysteme nicht ausgelegt sind.<\/span><\/li>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Die drei prim\u00e4ren Modelle der Umsatzbeteiligung sind prozentuale Aufteilungen, fixe Provisionen und volumen-\/staffelbasierte Auszahlungen. Jedes Modell bringt eine unterschiedliche Settlement-Komplexit\u00e4t sowie unterschiedliche Anreizstrukturen f\u00fcr Entwickler mit sich.<\/span><\/li>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Die agentenbezogene Ereigniszuordnung muss von Anfang an in das Event-Schema integriert werden. Periodenbasierte Aggregate k\u00f6nnen Entwicklerabrechnungen nachtr\u00e4glich nicht rekonstruieren und Zuordnungsstreitigkeiten im Nachhinein nicht sauber aufl\u00f6sen.<\/span><\/li>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Die Steuerpflicht h\u00e4ngt davon ab, ob die Plattform als Seller of Record auftritt. Diese Einstufung bestimmt die Pflichten zur Abf\u00fchrung von USt. bzw. vergleichbaren indirekten Steuern in jeder Jurisdiktion, in der die Plattform verkauft.<\/span><\/li>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Settlement-Reports f\u00fcr Entwickler m\u00fcssen Details auf Transaktionsebene enthalten, nicht nur zusammengefasste Gesamtbetr\u00e4ge.<\/span><\/li>\n<\/ul>\n\u00a0\n\n<span style=\"font-weight: 400;\">Der Aufbau eines AI-Agenten-Marktplatzes ist ein Infrastrukturproblem, das die meisten Abrechnungssysteme nicht l\u00f6sen sollten. Standard-SaaS-Abrechnung bildet einen Verk\u00e4ufer, einen K\u00e4ufer und ein Produkt ab. Nutzungsbasierte Abrechnung erg\u00e4nzt Messung und Bewertung (Metering und Rating) anhand einer einzelnen Preismetrik. Keines der beiden Modelle ber\u00fccksichtigt jedoch das pr\u00e4gende Merkmal eines Marktplatzes: mehrere Parteien mit unterschiedlichen finanziellen Beziehungen, die alle \u00fcber eine einzige Plattform Transaktionen abwickeln.<\/span>\n\n<span style=\"font-weight: 400;\">Wenn ein Unternehmen einen Marktplatz aufbaut, auf dem Drittanbieter-Entwickler AI Agents ver\u00f6ffentlichen und verkaufen, umfasst jede Kundentransaktion mindestens drei Parteien: die Plattform, den Entwickler und den Kunden. Ein einzelner Workflow kann Agents mehrerer unterschiedlicher Entwickler aufrufen. Ums\u00e4tze m\u00fcssen aufgeteilt, Provisionen abgezogen, Steuern der richtigen Einheit zugeordnet, Erstattungen entlang der Kette in die richtige Richtung zur\u00fcckgef\u00fchrt werden, und Entwickler m\u00fcssen am Ende jeder Periode korrekte, revisionssichere Settlement Statements erhalten.<\/span>\n\n<span style=\"font-weight: 400;\">Dieser Leitfaden behandelt diese Mechaniken im Detail: wie Umsatzbeteiligungen strukturiert sind, wie Billing-Events f\u00fcr die Zuordnung \u00fcber mehrere Parteien hinweg gestaltet werden, wie die Steuerpflicht im Marktplatzkontext zugewiesen wird, wie Erstattungen und Streitf\u00e4lle gehandhabt werden und was Settlement-Reporting im gro\u00dfen Ma\u00dfstab erfordert.<\/span>\n\n<span style=\"font-weight: 400;\">Dieser Leitfaden behandelt keine allgemeine AI-Monetarisierungsstrategie. Daf\u00fcr siehe<\/span><a href=\"https:\/\/www.zuora.com\/de\/?post_type=guides&p=324592\"> <span style=\"font-weight: 400;\">AI Monetization Strategy: A CFO's Guide<\/span><\/a><span style=\"font-weight: 400;\">. F\u00fcr die technische Pipeline, die Nutzungsereignisse in Rechnungen f\u00fcr AI-Produkte \u00fcberf\u00fchrt, siehe <\/span><a href=\"https:\/\/www.zuora.com\/guides\/ai-billing-for-usage-based-products\/\"><span style=\"font-weight: 400;\">AI Billing for Usage-Based Products: Metering, Invoices, Credits, and Chargeback.<\/span><\/a>","include_in_toc":true},{"acf_fc_layout":"knowledge_hub_text_block","title":"Was die Abrechnung in Agent-Marktpl\u00e4tzen anders macht","content":"<span style=\"font-weight: 400;\">Drei strukturelle Merkmale unterscheiden die Abrechnung von Agenten-Marktpl\u00e4tzen von jeder anderen Art der Softwareabrechnung. Sie zu verstehen, entscheidet dar\u00fcber, was die Infrastruktur vom ersten Tag an unterst\u00fctzen muss.<\/span>\n<h3><b>Transaktionen mit mehreren Parteien<\/b><\/h3>\n<span style=\"font-weight: 400;\">Im klassischen SaaS verkauft ein Anbieter an einen Kunden. In einem Marktplatz vermittelt die Plattform einen Verkauf zwischen einem Entwickler und einem Kunden. Es bestehen gleichzeitig zwei finanzielle Beziehungen: Der Kunde zahlt an die Plattform, und die Plattform schuldet dem Entwickler Geld. Jedes Abrechnungssystem, das nur die kundenseitige H\u00e4lfte dieser Beziehung abbildet, wird auf der entwicklerseitigen H\u00e4lfte zu Abstimmungsproblemen f\u00fchren.<\/span>\n\n<span style=\"font-weight: 400;\">Das ist kein Sonderfall. Es ist der Normalzustand jeder Transaktion in einem Agenten-Marktplatz.<\/span>\n<h3><b>Zuordnung auf Agentenebene<\/b><\/h3>\n<span style=\"font-weight: 400;\">Eine einzelne Kundenanfrage kann mehrere Agenten unterschiedlicher Publisher aufrufen. Ein Workflow, der ein Angebot entwirft, Daten validiert und ein Ergebnisdokument formatiert, kann drei Agenten von drei unterschiedlichen Entwicklern nutzen. Jeder Agent kann eine andere Preiskennzahl (verbrauchte Tokens, abgeschlossene Aufgaben, Rechenzeit) und eine andere Umsatzbeteiligungsregelung haben. Das Abrechnungssystem muss Nutzung und Umsatz jedem Agenten unabh\u00e4ngig zuordnen und anschlie\u00dfend eine einzige kundenseitige Rechnung konsolidieren.<\/span>\n\n<span style=\"font-weight: 400;\">Ohne Zuordnung auf Agentenebene im Ereignisschema existieren die Daten, die zur Berechnung von Entwicklerabrechnungen erforderlich sind, zum Abrechnungszeitpunkt nicht. Sie lassen sich nachtr\u00e4glich nicht rekonstruieren. Die Identit\u00e4t auf Agentenebene ist eine Plattformf\u00e4higkeit und keine Schema-Konvention \u2014 siehe Zuora AI unter zuora.com\/de\/products\/ai\/ dazu, wie die Agenten identifiziert und instrumentiert werden.<\/span>\n<h3><b>Ergebnisvariabilit\u00e4t und teilweise Ausf\u00fchrung<\/b><\/h3>\n<span style=\"font-weight: 400;\">KI-Agenten schlie\u00dfen ihre Aufgaben nicht immer ab. Ein Agent, der in der Mitte eines Workflows scheitert, wirft eine Abrechnungsfrage auf, f\u00fcr die es keine Standardantwort gibt: Hat der Kunde einen Nutzen erhalten? Ist Teilleistung abrechenbar? Wof\u00fcr wird der Entwickler bei unvollst\u00e4ndiger Arbeit bezahlt? Diese Fragen entstehen in der Abonnementabrechnung nicht. Marktplatzabrechnung erfordert explizite Richtlinien f\u00fcr jedes Szenario, und das Abrechnungssystem muss diese Richtlinien auf Transaktionsebene durchsetzen \u2014 nicht in einem manuellen Ausnahmeprozess.<\/span>\n<h3><b>Ein konkretes Szenario<\/b><\/h3>\n<span style=\"font-weight: 400;\">Ein Unternehmen betreibt einen Marktplatz mit 50 KI-Agenten von Drittanbietern. Ein Kunde f\u00fchrt einen Workflow aus, der vier Agenten von drei unterschiedlichen Entwicklern nutzt. Der Workflow wird erfolgreich abgeschlossen.<\/span>\n\n<span style=\"font-weight: 400;\">Bevor Geld flie\u00dft, m\u00fcssen sieben Dinge passieren:<\/span>\n<ol>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Die Nutzung jedes Agenten wird als separates Abrechnungsereignis erfasst, das Agenten-ID, Entwickler-ID, Kunden-ID, Nutzungsmenge und Zeitstempel enth\u00e4lt.<\/span><\/li>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Jedes Ereignis wird anhand des Preisplans f\u00fcr diesen Agenten bewertet.<\/span><\/li>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Der Umsatz wird je Agent berechnet und anschlie\u00dfend zu einer Gesamtsumme auf der Kundenrechnung aggregiert.<\/span><\/li>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Die Provision der Plattform wird je Entwickler abgezogen.<\/span><\/li>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">F\u00fcr den Gesamtbetrag wird eine Kundenrechnung erstellt.<\/span><\/li>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Auszahlungen an Entwickler werden nach Abzug der Plattformgeb\u00fchr berechnet und zur Abwicklung der Auszahlung vorgemerkt.<\/span><\/li>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Steuern werden danach angewendet, wer f\u00fcr jede Partei innerhalb der Transaktion als Seller of Record gilt.<\/span><\/li>\n<\/ol>\n<span style=\"font-weight: 400;\">Keiner dieser Schritte ist f\u00fcr sich genommen kompliziert. Zusammen, im gro\u00dfen Ma\u00dfstab, \u00fcber Tausende von Kunden und Hunderte von Entwicklern hinweg, erfordern sie jedoch eine Infrastruktur, die f\u00fcr dieses Modell gebaut wurde, statt daraus abgeleitet und angepasst zu sein.<\/span>","show_striped_bar":false,"related_post":"","include_in_toc":true},{"acf_fc_layout":"knowledge_hub_text_block","title":"Umsatzbeteiligungsmodelle f\u00fcr KI-Agent-Marktpl\u00e4tze","content":"<span style=\"font-weight: 400;\">Es gibt drei prim\u00e4re Modelle zur Aufteilung von Ums\u00e4tzen zwischen einer Plattform und ihren Entwicklern. Jedes hat unterschiedliche Auswirkungen auf die Anforderungen an Abrechnungsdaten, das Rechnungsformat und die Komplexit\u00e4t der Abrechnung bzw. Auszahlung (Settlement).<\/span>\n<h3><b>Umsatzbeteiligung (prozentuale Aufteilung)<\/b><\/h3>\n<span style=\"font-weight: 400;\">Die Plattform beh\u00e4lt einen prozentualen Anteil der Bruttoums\u00e4tze aus jeder Transaktion ein, und der Entwickler erh\u00e4lt den Rest. Eine g\u00e4ngige Aufteilung bei etablierten Marktpl\u00e4tzen ist 70% f\u00fcr den Entwickler und 30% f\u00fcr die Plattform, wobei dies je nach Agent-Kategorie und Exklusivit\u00e4t erheblich variieren kann.<\/span>\n\n<b>Erforderliche Abrechnungsdaten:<\/b><span style=\"font-weight: 400;\"> Bruttoumsatz je Transaktion, Kunden-ID, Agent-ID, Entwickler-ID. Die prozentuale Aufteilung wird im Vertragsdatensatz des Entwicklers hinterlegt und zum Zeitpunkt des Settlements angewendet, nicht zum Zeitpunkt der Rechnungsstellung. Die kundenseitige Rechnung weist den vollst\u00e4ndigen Preis der Agent-Leistung aus; die Umsatzaufteilung erfolgt intern.<\/span>\n\n<b>Auszahlungsrhythmus:<\/b><span style=\"font-weight: 400;\"> Monatlich ist in der fr\u00fchen Phase Standard. W\u00f6chentlich wird erforderlich, sobald das Auszahlungsvolumen an Entwickler steigt und Entwickler beginnen, ihren Cashflow an ihren Einnahmen auszurichten.<\/span>\n\n<b>Anforderung an die Pr\u00fcfbarkeit:<\/b><span style=\"font-weight: 400;\"> Entwickler werden Settlement-Berechnungen anfechten. Die Plattform muss in der Lage sein, die Roh-Transaktionsdaten bereitzustellen, die jede Zeile der Settlement-Abrechnung belegen. Eine zusammengefasste Auszahlung ohne Einzelposten-Nachweise ist eine h\u00e4ufige Ursache f\u00fcr Entwicklerstreitigkeiten.<\/span>\n<h3><b>Feste Provision (Geb\u00fchr pro Transaktion)<\/b><\/h3>\n<span style=\"font-weight: 400;\">Die Plattform berechnet einen festen Euro-Betrag pro Transaktion oder pro Invocation, unabh\u00e4ngig vom Transaktionswert. Der Entwickler erh\u00e4lt den Rest.<\/span>\n\n<b>Erforderliche Abrechnungsdaten:<\/b><span style=\"font-weight: 400;\"> Transaktionsanzahl je Entwickler je Zeitraum, Geb\u00fchrenplan mit Festbetr\u00e4gen je Agent-Kategorie oder Tier.<\/span>\n\n<b>Komplexit\u00e4t:<\/b><span style=\"font-weight: 400;\"> Gering auf der Abrechnungsseite. H\u00f6her auf der Seite der Entwicklerbeziehungen. Feste Provisionen erzeugen Druck, wenn Transaktionswerte stark variieren: Ein hochpreisiger und ein niedrigpreisiger Agent zahlen denselben absoluten Betrag, was die Nettomarge im niedrigpreisigen Segment komprimiert und hochpreisige Entwickler dazu bewegen kann, individuelle Konditionen zu verhandeln.<\/span>\n<h3><b>Gestaffelte Auszahlung (volumenbasierter Entwickleranteil)<\/b><\/h3>\n<span style=\"font-weight: 400;\">Der prozentuale Umsatzanteil des Entwicklers steigt mit wachsendem Transaktionsvolumen. Beispiel: 65% Anteil bei weniger als 10.000 \u20ac Monatsvolumen, 72% bei 10.000 \u20ac bis 50.000 \u20ac, 78% \u00fcber 50.000 \u20ac.<\/span>\n\n<b>Erforderliche Abrechnungsdaten:<\/b><span style=\"font-weight: 400;\"> Laufende monatliche Volumensumme je Entwickler, Tier-Schwellenwerte aus dem Entwicklervertrag, explizite Regeln f\u00fcr Tier-\u00dcberg\u00e4nge.<\/span>\n\n<b>Kritische Policy-Frage:<\/b><span style=\"font-weight: 400;\"> Gilt der h\u00f6here Satz r\u00fcckwirkend f\u00fcr den gesamten Zeitraum, sobald ein Schwellenwert \u00fcberschritten wird, oder nur f\u00fcr Transaktionen nach dem \u00dcberschreiten? Diese Policy muss im Entwicklervertrag festgehalten und im Abrechnungssystem konsistent durchgesetzt werden. Eine r\u00fcckwirkende Anwendung erh\u00f6ht die Settlement-Komplexit\u00e4t; eine prospektive Anwendung f\u00fchrt zu Beschwerden seitens der Entwickler. Keine der beiden Varianten ist \u201efalsch\u201c, aber eine inkonsistente Anwendung f\u00fchrt zu beidem.<\/span>\n\n<b>Komplexit\u00e4t:<\/b><span style=\"font-weight: 400;\"> Hoch. Tier-Berechnungen, Regeln zur R\u00fcckwirkung und Transparenz des Tier-Status innerhalb des Monats f\u00fcr Entwickler mit hohem Volumen erfordern, dass das Abrechnungssystem f\u00fcr jeden Entwickler einen laufenden Status seines Period-to-date-Volumens vorh\u00e4lt.<\/span>\n<h3><b>Modellvergleich<\/b><\/h3>\n<table>\n<tbody>\n<tr>\n<td><b>Modell<\/b><\/td>\n<td><b>Abrechnungskomplexit\u00e4t<\/b><\/td>\n<td><b>Attraktivit\u00e4t f\u00fcr Entwickler<\/b><\/td>\n<td><b>Audit-Aufwand im Settlement<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Umsatzbeteiligung<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Mittel<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Hoch f\u00fcr Agenten mit hoher Marge<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Mittel<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Feste Provision<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Gering<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Variabel je Agent-Typ<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Gering<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Gestaffelte Auszahlung<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Hoch<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Hoch f\u00fcr Entwickler mit hohem Volumen<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Hoch<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\u00a0","show_striped_bar":false,"related_post":"","include_in_toc":true},{"acf_fc_layout":"knowledge_hub_text_block","title":"Messung und Rating f\u00fcr agentische Workflows","content":"<span style=\"font-weight: 400;\">Das Metering f\u00fcr KI-Agenten unterscheidet sich in drei Punkten vom standardm\u00e4\u00dfigen API-Metering, die die Abrechnung wesentlich beeinflussen.<\/span>\n<h3><b>Zusammengesetzte Aufrufe<\/b><\/h3>\n<span style=\"font-weight: 400;\">Eine einzelne, kundenorientierte Anfrage l\u00f6st h\u00e4ufig zahlreiche nachgelagerte Agentenaufrufe aus. Wenn eine Orchestrierungsschicht eine Anfrage an vier Sub-Agenten weiterleitet, muss das Abrechnungssystem vier separate Usage-Events erfassen, jeweils eindeutig dem richtigen Agenten und dem richtigen Entwickler zugeordnet. Die Aggregation zu einem einzigen Event, das der Orchestrierungsschicht zugeschrieben wird, ist zwar schneller zu implementieren, macht jedoch die Berechnung der Entwicklerabrechnung unm\u00f6glich und l\u00e4sst sich im Streitfall nicht aufl\u00f6sen.<\/span>\n\n<span style=\"font-weight: 400;\">Das Event-Schema muss ausreichend Informationen enthalten, um den vollst\u00e4ndigen Aufruf-Graphen rekonstruieren zu k\u00f6nnen, falls Kunde oder Entwickler die Abrechnung anfechten.<\/span>\n<h3><b>Asynchrone Fertigstellung<\/b><\/h3>\n<span style=\"font-weight: 400;\">Viele Agentenaufgaben werden nicht synchron abgeschlossen. Ein Kunde \u00fcbermittelt eine Aufgabe, der Agent l\u00e4uft \u00fcber Minuten oder Stunden, und das Ergebnis trifft erst sp\u00e4ter ein. Das Abrechnungs-Event sollte bei Abschluss der Aufgabe erzeugt werden (wenn der Nutzen geliefert wurde) \u2013 nicht bei Einreichung (wenn die Anfrage gestellt wurde). Dieser zeitliche Unterschied beeinflusst, wie Usage zu Abrechnungszeitr\u00e4umen aggregiert wird und wie Guthaben von Prepaid-Guthabenst\u00e4nden abgezogen werden. Eine Aufgabe, die am letzten Tag des Monats eingereicht, aber am ersten Tag des Folgemonats abgeschlossen wird, geh\u00f6rt zu Abrechnungszwecken in den Zeitraum des Abschlusses \u2013 sofern der Vertrag nichts anderes festlegt.<\/span>\n<h3><b>Teilweise Abrechenbarkeit<\/b><\/h3>\n<span style=\"font-weight: 400;\">Wenn ein Agent fehlschl\u00e4gt oder ein Ergebnis liefert, das der Kunde ablehnt, muss die Plattform eine definierte Richtlinie dazu haben, welcher Anteil der Nutzung abrechenbar ist. Einige Plattformen berechnen die verbrauchte Rechenleistung unabh\u00e4ngig vom Ergebnis. Andere berechnen nur bei erfolgreichem Abschluss. Beides ist vertretbar, jedoch muss die Richtlinie in Kundenvereinbarungen ausdr\u00fccklich festgehalten und im Abrechnungssystem konsistent durchgesetzt werden.<\/span>\n<h3><b>Erforderliches Event-Schema<\/b><\/h3>\n<span style=\"font-weight: 400;\">Jedes agentenbasierte Abrechnungs-Event sollte die folgenden Felder enthalten, um eine Zuordnung \u00fcber mehrere Parteien hinweg sowie nachgelagerte Abstimmungen zu unterst\u00fctzen:<\/span>\n<table>\n<tbody>\n<tr>\n<td><b>Feld<\/b><\/td>\n<td><b>Zweck<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">event_id<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Eindeutige Kennung f\u00fcr Deduplizierung und Audit<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">session_id<\/span><\/td>\n<td><span style=\"font-weight: 400;\">\u00dcbergeordneter Kunden-Workflow oder Run<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">agent_id<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Konkreter Agent, der Nutzung erzeugt hat<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">developer_id<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Entwickler, dem der Agent geh\u00f6rt<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">customer_id<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Abzurechnendes Kundenkonto<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">usage_quantity<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Abrechenbare Einheit (Tokens, Rechensekunden, Completions)<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">usage_unit<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Einheitstyp f\u00fcr die Preisermittlung<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">timestamp_start<\/span><span style=\"font-weight: 400;\">, <\/span><span style=\"font-weight: 400;\">timestamp_end<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Dauer f\u00fcr zeitbasierte Abrechnung<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">completion_status<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Abgeschlossen, fehlgeschlagen oder teilweise<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">rated_amount<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Berechnete Geb\u00fchr, die zum Zeitpunkt des Ratings angewendet wird<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">platform_fee_amount<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Anteil der Plattform am berechneten Betrag<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">developer_payout_amount<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Nettoanteil des Entwicklers<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<span style=\"font-weight: 400;\">F\u00fcr eine detaillierte Schritt-f\u00fcr-Schritt-Darstellung, wie Usage-Events durch Metering, Rating, Aggregation und Rechnungsstellung laufen, siehe AI Billing for Usage-Based Products: Metering, Invoices, Credits, and Chargeback. Zuoras<\/span><a href=\"https:\/\/www.zuora.com\/de\/solutions\/monetize-usage\/\"> <span style=\"font-weight: 400;\">Nutzungsbasierte Abrechnungsinfrastruktur<\/span><\/a><span style=\"font-weight: 400;\"> \u00fcbernimmt f\u00fcr diese Event-Daten die Metering- und Rating-Schicht.<\/span>","show_striped_bar":false,"related_post":"","include_in_toc":true},{"acf_fc_layout":"knowledge_hub_text_block","title":"Steuerliche Behandlung in Agent-Marktpl\u00e4tzen","content":"<span style=\"font-weight: 400;\">Steuern in einem Marketplace werfen zwei Fragen auf, die bei der Standard-SaaS-Abrechnung nicht entstehen. Wenn eine der beiden falsch beantwortet wird, f\u00fchrt das zu Haftungsrisiken, deren Bereinigung kostspielig ist.<\/span>\n<h3><b>Ist die Plattform der Seller of Record?<\/b><\/h3>\n<span style=\"font-weight: 400;\">Der Seller of Record (SoR) ist die rechtlich verantwortliche Partei f\u00fcr den Verkauf sowie f\u00fcr die Erhebung und Abf\u00fchrung der jeweils anwendbaren Steuer (z. B. Umsatzsteuer\/VAT, GST, Sales Tax) an die zust\u00e4ndige Beh\u00f6rde. In einem Marketplace kann die Plattform der SoR sein (sie verkauft im Namen der Entwickler an Endkunden) oder als Zahlungsintermedi\u00e4r agieren (die Entwickler verkaufen direkt an Endkunden, und die Plattform \u00fcbernimmt ausschlie\u00dflich die Zahlungsabwicklung).<\/span>\n\n<span style=\"font-weight: 400;\">Die meisten Betreiber von Enterprise-Marktpl\u00e4tzen f\u00fcr KI-Agenten entscheiden sich aus zwei Gr\u00fcnden daf\u00fcr, SoR zu sein. Erstens vereinfacht es die Customer Experience: eine Rechnung, eine steuerliche Behandlung, eine verantwortliche Partei. Zweitens reduziert es das Compliance-Risiko durch Entwickler, die ihre steuerlichen Pflichten nicht in jeder Jurisdiktion, in der die Plattform t\u00e4tig ist, korrekt erf\u00fcllen.<\/span>\n\n<span style=\"font-weight: 400;\">Der Trade-off: Der SoR-Status begr\u00fcndet Abf\u00fchrungspflichten in jeder Jurisdiktion, in der die Plattform verkauft. Die SoR-Einstufung und ihre Auswirkungen in jedem Markt sollten mit Rechtsberatung best\u00e4tigt werden, da sich die Regeln zwischen EU-Mitgliedstaaten, US-Bundesstaaten und nichtwestlichen M\u00e4rkten erheblich unterscheiden.<\/span>\n\n<span style=\"font-weight: 400;\">Zuoras<\/span><a href=\"https:\/\/www.zuora.com\/de\/products\/billing-software\/e-invoicing-and-tax-compliance\/\"> <span style=\"font-weight: 400;\">Automatisierung f\u00fcr E\u2011Rechnungsstellung und Tax Compliance<\/span><\/a><span style=\"font-weight: 400;\"> \u00fcbernimmt f\u00fcr Plattformen, die als SoR agieren, die Steuerberechnung, -anwendung sowie Anforderungen an die E\u2011Rechnungsstellung \u00fcber verschiedene Jurisdiktionen hinweg.<\/span>\n<h3><b>Wie werden Entwickler-Auszahlungen f\u00fcr das Steuer-Reporting behandelt?<\/b><\/h3>\n<span style=\"font-weight: 400;\">In den Vereinigten Staaten muss eine Plattform, die einem Entwickler in einem Kalenderjahr mehr als 600\u00a0US\u2011$ auszahlt, ein Formular 1099-NEC einreichen. F\u00fcr Entwickler, die keine US-Personen sind, gelten unter FATCA abweichende Regeln zu Quellensteuer und Reporting; hierf\u00fcr ist beim Developer-Onboarding die Dokumentation mittels W-8BEN oder W-8BEN-E erforderlich.<\/span>\n\n<span style=\"font-weight: 400;\">F\u00fcr internationale Entwickler-\u00d6kosysteme muss die Plattform von jedem Entwickler vor jeder Auszahlung Daten zur steuerlichen Ans\u00e4ssigkeit erfassen, den korrekten Quellensteuersatz anwenden und die Quellensteuer vor der Auszahlung vom Abrechnungsbetrag einbehalten.<\/span>\n\n<span style=\"font-weight: 400;\">Die praktische Konsequenz: Das Developer-Onboarding muss einen Schritt zur steuerlichen Klassifizierung enthalten. Plattformen, die dies auf einen manuellen Prozess nach dem Launch verschieben, werden es bereits ab einigen Dutzend Entwicklern nicht mehr beherrschbar finden. Das Billing- und Auszahlungssystem muss die steuerliche Klassifizierung je Entwickler speichern und sie zum Settlement-Zeitpunkt automatisch anwenden.<\/span>","show_striped_bar":false,"related_post":"","include_in_toc":true},{"acf_fc_layout":"knowledge_hub_text_block","title":"R\u00fcckerstattungen und Streitf\u00e4lle in Agent-Marktpl\u00e4tzen","content":"<span style=\"font-weight: 400;\">Drei Szenarien f\u00fchren in einem Agent-Marktplatz zu R\u00fcckerstattungen oder Streitf\u00e4llen. Jedes wirkt sich unterschiedlich auf die Umsatzbeteiligung aus, und jedes erfordert spezifische F\u00e4higkeiten des Abrechnungssystems, um eine korrekte Kl\u00e4rung sicherzustellen.<\/span>\n<h3><b>Szenario 1: Agent schlie\u00dft eine Aufgabe nicht ab<\/b><\/h3>\n<span style=\"font-weight: 400;\">Der Kunde erh\u00e4lt keinen Nutzen. Standardrichtlinie ist eine vollst\u00e4ndige R\u00fcckerstattung des belasteten Betrags. Dem Kunden wird \u00fcber den vollen Betrag der Rechnungsposition eine Gutschrift ausgestellt. Die Abrechnung an den Entwickler wird um den entsprechenden Nettoauszahlungsbetrag reduziert. Wurde die Abrechnung an den Entwickler f\u00fcr den Zeitraum bereits ausgezahlt, muss die Plattform den Betrag ggf. im n\u00e4chsten Abrechnungszyklus zur\u00fcckfordern.<\/span>\n\n<b>Anforderung an das Abrechnungssystem:<\/b><span style=\"font-weight: 400;\"> Die Plattform muss in der Lage sein, jede kundenseitige Belastung bis zu ihrem urspr\u00fcnglichen Ereignisdatensatz, der Agent-ID und der Entwickler-ID zur\u00fcckzuverfolgen. Ohne diese Nachverfolgbarkeit kann die R\u00fcckerstattung den Auszahlungs-\/Abrechnungsbestand des richtigen Entwicklers nicht reduzieren.<\/span>\n<h3><b>Szenario 2: Kunde beanstandet die Qualit\u00e4t des Ergebnisses<\/b><\/h3>\n<span style=\"font-weight: 400;\">Der Agent hat die Aufgabe abgeschlossen, aber der Kunde ist mit dem Ergebnis unzufrieden. Dies ist eine Richtlinienentscheidung, keine Entscheidung des Abrechnungssystems. Die drei Standardans\u00e4tze sind vollst\u00e4ndige R\u00fcckerstattung (hohe Kosten f\u00fcr die Entwicklerbeziehung), teilweise R\u00fcckerstattung (geteilte Verantwortung) oder keine R\u00fcckerstattung (nutzungsbasiertes Prinzip: bezahlt wird f\u00fcr verbrauchte Compute-Ressourcen, nicht f\u00fcr Zufriedenheit). Unabh\u00e4ngig von der Richtlinie muss das Abrechnungssystem die Ausstellung einer Teilgutschrift gegen eine spezifische Rechnungsposition unterst\u00fctzen, wobei der Teilbetrag \u00fcber die Umsatzbeteiligung an die Abrechnung des Entwicklers zur\u00fcckflie\u00dft.<\/span>\n<h3><b>Szenario 3: Entwickler beanstandet die Plattform-Zuordnung<\/b><\/h3>\n<span style=\"font-weight: 400;\">Der Entwickler ist der Ansicht, dass die Zuordnung der Nutzung durch die Plattform zu seinem Agenten falsch ist, typischerweise eine Beanstandung wegen \u00dcberzuordnung, bei der er davon ausgeht, dass ihm mehr belastet wurde, als sein Agent tats\u00e4chlich verbraucht hat. Zur Kl\u00e4rung wird das Roh-Ereignisprotokoll ben\u00f6tigt: die <\/span><span style=\"font-weight: 400;\">event_id<\/span><span style=\"font-weight: 400;\">-Datens\u00e4tze, der Invocation-Graph und die bewerteten Betr\u00e4ge in jedem Schritt. Deshalb muss das Ereignisschema gespeichert und abfragbar sein, nicht nur zu Periodensummen aggregiert. Periodensummen k\u00f6nnen Zuordnungsstreitigkeiten nicht kl\u00e4ren.<\/span>","show_striped_bar":false,"related_post":"","include_in_toc":true},{"acf_fc_layout":"knowledge_hub_text_block","title":"Abrechnungsreporting","content":"<span style=\"font-weight: 400;\">Settlement-Reporting ist der Prozess, bei dem am Ende jedes Abrechnungszeitraums berechnet wird, welcher Betrag jedem Entwickler zusteht, dies mit den in Rechnung gestellten Kundenerl\u00f6sen abgeglichen wird und Auszahlungsdatens\u00e4tze erstellt werden, die die tats\u00e4chliche Zahlung ausl\u00f6sen. Hier wird Billing-Komplexit\u00e4t zur Finance-Komplexit\u00e4t.<\/span>\n<h3><b>Was eine Settlement-Abrechnung enthalten muss<\/b><\/h3>\n<span style=\"font-weight: 400;\">Eine Settlement-Abrechnung f\u00fcr Entwickler muss f\u00fcr jeden Entwickler und f\u00fcr jeden Zeitraum Folgendes ausweisen:<\/span>\n<ul>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Brutto-Kundenerl\u00f6se, die ihren Agents zuzuordnen sind<\/span><\/li>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Plattformgeb\u00fchr als Betrag in W\u00e4hrungseinheiten (nicht nur als Prozentsatz; Betr\u00e4ge sind das, was Entwickler mit ihren eigenen Aufzeichnungen abgleichen)<\/span><\/li>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Einbehaltene Steuerbetr\u00e4ge, sofern zutreffend<\/span><\/li>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Gutschriften oder R\u00fcckbelastungen aus Erstattungen fr\u00fcherer Perioden<\/span><\/li>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Netto-Auszahlungsbetrag<\/span><\/li>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Transaktionsdetails oder ein herunterladbares Transaktionsprotokoll als Nachweis f\u00fcr die Bruttoerl\u00f6szahl<\/span><\/li>\n<\/ul>\n<span style=\"font-weight: 400;\">Die Transaktionsdetails sind in der Praxis erforderlich, sobald ein Entwickler seine Marketplace-Einnahmen als Gesch\u00e4ftserl\u00f6se behandelt. Nach unserer Erfahrung f\u00fchrt eine reine Zusammenfassung zu Streitf\u00e4llen, die mit der Auszahlungsgr\u00f6\u00dfe zunehmen.<\/span>\n<h3><b>Abgleich von Settlement mit erfassten Umsatzerl\u00f6sen<\/b><\/h3>\n<span style=\"font-weight: 400;\">Die Settlement-Gesamtsumme einer Periode muss mit den aus denselben Transaktionen erfassten Umsatzerl\u00f6sen abgeglichen werden. Dieser Abgleich erfordert vier Kennzahlen:<\/span>\n<ol>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Gesamtbetrag der Kundenrechnungen f\u00fcr die Periode (Summe aller Agent-Service-Geb\u00fchren)<\/span><\/li>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Gesamte Plattformums\u00e4tze (Summe aller Plattformgeb\u00fchr-Abz\u00fcge \u00fcber alle Entwickler-Settlements hinweg)<\/span><\/li>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Gesamte Entwickler-Auszahlungen (Summe aller Netto-Entwicklerbetr\u00e4ge)<\/span><\/li>\n \t<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Gesamtsumme der Erstattungen und Gutschriften, die w\u00e4hrend der Periode ausgestellt wurden<\/span><\/li>\n<\/ol>\n<span style=\"font-weight: 400;\">Die Summe aus Plattformums\u00e4tzen plus gesamten Entwickler-Auszahlungen plus vereinnahmten Steuern plus Netto-Gutschriften sollte dem Gesamtbetrag der Kundenrechnungen entsprechen. Jede Abweichung ist entweder eine nicht abgeglichene Gutschrift, eine Erstattung, die keinem Settlement zugeordnet wurde, oder ein Billing-Ereignis, das zwar geratet, aber nicht in Rechnung gestellt wurde.<\/span>\n\n<span style=\"font-weight: 400;\">Zuoras<\/span><a href=\"https:\/\/www.zuora.com\/de\/products\/revenue\/\"> <span style=\"font-weight: 400;\">Software f\u00fcr Umsatzrealisierung<\/span><\/a><span style=\"font-weight: 400;\"> und<\/span><a href=\"https:\/\/www.zuora.com\/de\/guides\/revenue-subledger-vs-erp\/\"> <span style=\"font-weight: 400;\">Revenue-Subledger-Infrastruktur<\/span><\/a><span style=\"font-weight: 400;\"> verbinden die Kunden-Billing-Seite mit der Seite der erfassten Umsatzerl\u00f6se und stellen die Abstimmungsebene bereit, die Finance-Teams ben\u00f6tigen, um jede Periode sauber abzuschlie\u00dfen.<\/span>\n<h3><b>Integration von ERP und Kreditorenbuchhaltung<\/b><\/h3>\n<span style=\"font-weight: 400;\">Entwickler-Auszahlungen sind ausgehende Zahlungen, keine Buchungss\u00e4tze. Sie m\u00fcssen in das Kreditorensystem integriert werden, das die \u00dcberweisung oder Zahlung an die konfigurierte Auszahlungsart des Entwicklers ausf\u00fchrt. Die Settlement-Abrechnung ist der Input f\u00fcr diesen AP-Prozess. Zuoras<\/span><a href=\"https:\/\/www.zuora.com\/de\/solutions\/quote-to-cash\/\"> <span style=\"font-weight: 400;\">Quote-to-Cash-Infrastruktur<\/span><\/a><span style=\"font-weight: 400;\"> verbindet Billing-Daten mit nachgelagerten Finanzsystemen, einschlie\u00dflich ERP-Integrationen, die Settlement-Outputs in Kreditoren-Workflows \u00fcberf\u00fchren.<\/span>","show_striped_bar":false,"related_post":"","include_in_toc":true},{"acf_fc_layout":"knowledge_hub_text_block","title":"Eigenentwicklung vs. Zukauf der Infrastruktur","content":"<span style=\"font-weight: 400;\">Die Make-or-buy-Frage bei der Abrechnung von Marktpl\u00e4tzen ist in erster Linie keine Technologiefrage. Es ist eine Frage des Umfangs.<\/span>\n\n<b>Was sich intern realistisch entwickeln l\u00e4sst:<\/b><span style=\"font-weight: 400;\"> Eine einfache Umsatzbeteiligung f\u00fcr einen einzelnen Produkttyp, bei der alle Agenten dasselbe Preismodell nutzen und alle Entwickler denselben Provisionssatz haben. Liegt die Anzahl der Entwickler unter 20 und ist das Preismodell stabil, ist eine individuelle Settlement-Berechnung auf Basis eines Standard-Abrechnungssystems praktikabel.<\/span>\n\n<b>Was im gro\u00dfen Ma\u00dfstab scheitert:<\/b><span style=\"font-weight: 400;\"> Multi-Agent-Attribution ger\u00e4t an Grenzen, wenn Invocation-Graphen komplex werden. Das steuerliche Reporting f\u00fcr Entwickler scheitert, wenn sich die Entwicklerbasis \u00fcber mehrere Jurisdiktionen erstreckt. Die Settlement-Abstimmung scheitert, wenn R\u00fcckerstattungen, Teilgutschriften und Tier-Anpassungen Ausnahmen erzeugen, f\u00fcr die das Custom-System nicht ausgelegt wurde. Audit-Trails scheitern, wenn das Roh-Event-Log nicht von Anfang an auf Abfragef\u00e4higkeit ausgelegt wurde. Das Gegengewicht ist die Implementierungsgeschwindigkeit: Die Quote-to-Cash-Implementierung l\u00e4sst sich auf Wochen statt auf Quartale komprimieren, was die Make-or-buy-Rechnung st\u00e4rker ver\u00e4ndert, als es Lizenzkosten tun. Siehe zuora.com\/de\/products\/milo\/.<\/span>\n\n<span style=\"font-weight: 400;\">Die kumulativen Kosten technischer Schulden in Abrechnungssystemen sind hoch. Marktpl\u00e4tze, die ihre eigene Settlement-Logik entwickeln, stellen h\u00e4ufig fest, dass sie mit wachsendem Volumen und zunehmender geografischer sowie regulatorischer Streuung neu aufgebaut werden muss \u2013 typischerweise innerhalb von 18 bis 24 Monaten. Die Kosten des Rebuilds in Engineering-Zeit, Finance-Remediation fehlerhafter Settlements und der Wiederherstellung des Entwicklervertrauens \u00fcbersteigen nahezu immer die anf\u00e4nglichen Kosten einer zweckm\u00e4\u00dfig entwickelten Infrastruktur.<\/span>\n\n<span style=\"font-weight: 400;\">Zuoras<\/span><a href=\"https:\/\/www.zuora.com\/de\/solutions\/ai-monetization-suite\/\"> <span style=\"font-weight: 400;\">AI Monetization Suite<\/span><\/a><span style=\"font-weight: 400;\"> und<\/span><a href=\"https:\/\/www.zuora.com\/de\/ai\/\"> <span style=\"font-weight: 400;\">KI-gest\u00fctzte Abrechnungs- und Umsatzplattform<\/span><\/a><span style=\"font-weight: 400;\"> wurden daf\u00fcr entwickelt, Monetarisierung mit mehreren Parteien im Enterprise-Ma\u00dfstab zu unterst\u00fctzen \u2013 einschlie\u00dflich der in diesem Leitfaden behandelten Marktplatz-Szenarien. F\u00fcr Unternehmen in der Architekturphase lautet die richtige Frage nicht, ob zweckm\u00e4\u00dfig entwickelte Infrastruktur eingesetzt werden soll, sondern welche Settlement-Mechaniken definiert werden m\u00fcssen, bevor der erste Entwickler an Bord geholt wird.<\/span>\n\n\u00a0","show_striped_bar":false,"related_post":"","include_in_toc":true},{"acf_fc_layout":"knowledge_hub_text_block","title":"Fazit","content":"<span style=\"font-weight: 400;\">Marktpl\u00e4tze f\u00fcr KI-Agenten stellen eine neue Kategorie von Herausforderungen im Bereich der Finanzinfrastruktur dar. Die in diesem Leitfaden beschriebenen Mechanismen f\u00fcr Umsatzbeteiligung, Abrechnung, Mehrparteien-Attribution und die steuerliche Meldelogik f\u00fcr Entwickler existieren in Standard-SaaS-Abrechnungssystemen nicht, weil diese Systeme nicht daf\u00fcr konzipiert wurden. Unternehmen, die die Abrechnung f\u00fcr Marktpl\u00e4tze als Erweiterung ihrer bestehenden Abrechnungsumgebung behandeln, sto\u00dfen auf diese L\u00fccke, sobald sich Entwicklerstreitigkeiten, steuerliche Fehlklassifizierungen und Fehler bei der Abstimmung von Auszahlungen und Abrechnungen zu h\u00e4ufen beginnen.<\/span>\n\n<span style=\"font-weight: 400;\">Unternehmen, die das richtig machen, verstehen die Abrechnungsinfrastruktur f\u00fcr Marktpl\u00e4tze als Produktentscheidung vor dem Launch \u2013 nicht als Engineering-Thema, das erst nach der ersten Auszahlung an Entwickler adressiert wird. Das Event-Schema, der Auszahlungs- und Abrechnungsrhythmus, die Festlegung der SoR-Rolle sowie die R\u00fcckerstattungsrichtlinie m\u00fcssen vorab definiert und getestet werden, bevor Skalierung \u00c4nderungen teuer macht.<\/span>\n\n<a href=\"https:\/\/www.zuora.com\/de\/ai\/\"><span style=\"font-weight: 400;\">Buchen Sie eine Demo mit Zuora<\/span><\/a><span style=\"font-weight: 400;\">, um zu sehen, wie die AI Monetization Suite auf Ihr spezifisches Marktplatzmodell angewendet wird.<\/span>","show_striped_bar":false,"related_post":"","include_in_toc":true}],"faq_title":"FAQs","faq_items":[{"question":"Wie verdienen KI-Agent-Marktpl\u00e4tze Geld?","answer":"<span style=\"font-weight: 400;\">KI-Agent-Marktpl\u00e4tze erzielen Ums\u00e4tze, indem sie an jeder Transaktion zwischen Kunden und Drittanbieter-Entwicklern auf der Plattform beteiligt werden. Die drei g\u00e4ngigen Modelle sind eine prozentuale Umsatzbeteiligung (die Plattform beh\u00e4lt einen Prozentsatz der Bruttoausgaben des Kunden ein), eine feste Provision pro Transaktion sowie ein gestaffeltes Auszahlungsmodell, bei dem der Anteil des Entwicklers mit wachsendem Volumen steigt. Zus\u00e4tzlich erzielt die Plattform typischerweise Erl\u00f6se aus Premium-Platzierungen, Zertifizierungsprogrammen und Zugangsgeb\u00fchren f\u00fcr Enterprise-Tarife, die \u00fcber das Transaktionsmodell hinausgehen.<\/span>"},{"question":"Worin liegt der Unterschied zwischen Marktplatz-Abrechnung und standardm\u00e4\u00dfiger SaaS-Abrechnung?","answer":"<span style=\"font-weight: 400;\">Bei der standardm\u00e4\u00dfigen SaaS-Abrechnung gibt es einen Verk\u00e4ufer, einen K\u00e4ufer und eine Preisbeziehung. Bei der Marktplatz-Abrechnung sind an jeder Transaktion mehrere Parteien beteiligt: die Plattform, der Entwickler und der Kunde. Das Abrechnungssystem muss die Ums\u00e4tze f\u00fcr jede Transaktion dem richtigen Entwickler zuordnen, die Provision bzw. Plattformgeb\u00fchr berechnen und abziehen, die Steuer abh\u00e4ngig davon anwenden, wer als Seller of Record auftritt, und am Ende jeder Periode Abrechnungs-\/Settlement-Ausz\u00fcge f\u00fcr jeden Entwickler erstellen. Keiner dieser Schritte existiert in einem standardm\u00e4\u00dfigen SaaS-Abrechnungsmodell.<\/span>"},{"question":"Wie funktioniert die Umsatzbeteiligung in einem KI-Agent-Marktplatz?","answer":"<span style=\"font-weight: 400;\">Wenn ein Kunde einen Agenten auf dem Marktplatz kauft oder nutzt, vereinnahmt die Plattform die vollst\u00e4ndige Zahlung des Kunden, zieht ihre Provision bzw. Plattformgeb\u00fchr ab und zahlt den Nettobetrag an den Entwickler aus. Der Prozentsatz der Umsatzbeteiligung, der Zeitpunkt der Berechnung und der Auszahlungsrhythmus sind im Vertrag jedes Entwicklers festgelegt. Entwickler mit hohem Volumen verhandeln h\u00e4ufig gestaffelte Modelle, bei denen ihr Nettoanteil mit steigenden monatlichen Ums\u00e4tzen zunimmt. In fr\u00fchen Phasen erfolgen Auszahlungen typischerweise monatlich und bei wachsendem Auszahlungsvolumen w\u00f6chentlich.<\/span>"},{"question":"Wer erhebt und f\u00fchrt Steuern in einem KI-Agent-Marktplatz ab?","answer":"<span style=\"font-weight: 400;\">Die steuerlichen Pflichten h\u00e4ngen davon ab, ob die Plattform den Status als Seller of Record (SoR) gew\u00e4hlt hat. Ist die Plattform SoR, ist sie rechtlich daf\u00fcr verantwortlich, die jeweils anfallende Umsatzsteuer (VAT), GST und Sales Tax bei den Kunden zu erheben und an die Steuerbeh\u00f6rden in den jeweiligen Jurisdiktionen abzuf\u00fchren. Tritt die Plattform dagegen als Zahlungsintermedi\u00e4r und nicht als SoR auf, liegen die steuerlichen Pflichten bei jedem einzelnen Entwickler \u2013 was Compliance-Risiken f\u00fcr Entwickler schafft, die ihre steuerlichen Pflichten in mehreren Jurisdiktionen nicht konsistent steuern. Die meisten Betreiber von Enterprise-Marktpl\u00e4tzen w\u00e4hlen den SoR-Status, um das Kundenerlebnis zu vereinfachen und die Compliance zentral zu steuern.<\/span>"},{"question":"Was ist ein \u201eSeller of Record\u201c im Kontext eines Marktplatzes?","answer":"<span style=\"font-weight: 400;\">Der \u201eSeller of Record\u201c (SoR) ist die juristische Person, die auf der Kundenrechnung als Verk\u00e4ufer ausgewiesen ist. In einem Marktplatzmodell ist das entweder die Plattform oder der jeweilige Entwickler. Der SoR-Status bestimmt, welche Partei Umsatzsteuer, VAT und GST erhebt und abf\u00fchrt und welche Partei haftet, wenn diese Pflichten nicht erf\u00fcllt werden. Plattformen, die den SoR-Status \u00fcbernehmen, tragen die Abf\u00fchrungspflichten in allen L\u00e4ndern\/Regionen, in denen sie t\u00e4tig sind, gewinnen daf\u00fcr aber die Kontrolle \u00fcber den steuerlichen Compliance\u2011Prozess. Plattformen, die keinen SoR-Status \u00fcbernehmen, \u00fcbertragen diese Verpflichtung auf die Entwickler \u2013 inklusive des damit verbundenen Compliance\u2011Risikos.<\/span>"},{"question":"Wie werden Erstattungen gehandhabt, wenn ein KI\u2011Agent scheitert?","answer":"<span style=\"font-weight: 400;\">Wenn ein Agent eine Aufgabe nicht erfolgreich abschlie\u00dft, ist es g\u00e4ngige Praxis, dem Kunden eine vollst\u00e4ndige Erstattung per Gutschrift zu gew\u00e4hren und das Auszahlungs-\/Settlement-Guthaben des Entwicklers um den entsprechenden Betrag zu reduzieren. Wurde das Settlement f\u00fcr den Zeitraum bereits ausgezahlt, wird der R\u00fcckbelastungsbetrag (\u201eClawback\u201c) im n\u00e4chsten Settlement-Zyklus verrechnet. Teilweise Fehlschl\u00e4ge (bei denen ein Agent einen Teil, aber nicht die gesamte Aufgabe erledigt) erfordern eine explizite Richtlinie: entweder eine anteilige Gutschrift (Abrechnung der erbrachten Leistung) oder eine vollst\u00e4ndige Erstattung. Diese Richtlinie muss in den Kundenvertr\u00e4gen festgelegt und im Abrechnungssystem durchgesetzt werden \u2013 nicht fallweise entschieden.<\/span>"},{"question":"Was muss ein Developer-Settlement-Report enthalten?","answer":"<span style=\"font-weight: 400;\">Ein vollst\u00e4ndiger Developer-Settlement-Report muss je Abrechnungsperiode Folgendes enthalten: die dem Entwickler zuzurechnenden Brutto-Kundenerl\u00f6se aus dessen Agenten, aufgeschl\u00fcsselt nach Transaktion; die Plattformgeb\u00fchr als absoluter Betrag (nicht nur als Prozentsatz); einbehaltene Steuern einschlie\u00dflich Satz und Bemessungsgrundlage; Gutschriften oder R\u00fcckbelastungen aus Erstattungen fr\u00fcherer Perioden; sowie den Nettoauszahlungsbetrag. F\u00fcr Entwickler, die Marktplatzerl\u00f6se als Betriebseinnahmen behandeln, sind Transaktionsdetails oder ein herunterladbares Transaktionsprotokoll zur Untermauerung der Bruttoerl\u00f6szahl erforderlich. Reine Zusammenfassungen ohne Einzelposten-Nachweise f\u00fchren bei Skalierung regelm\u00e4\u00dfig zu Streitf\u00e4llen.<\/span>"},{"question":"Kann ich mein bestehendes Abrechnungssystem f\u00fcr einen KI\u2011Agenten\u2011Marktplatz verwenden?","answer":"<span style=\"font-weight: 400;\">Bestehende Abrechnungssysteme, die f\u00fcr Abonnements oder die Abrechnung eines einzelnen Leistungserbringers konzipiert sind, k\u00f6nnen in einem Marktplatz das kundenseitige Rechnungswesen abbilden, sind jedoch nicht f\u00fcr mehrparteiische Umsatzzuordnung, die Berechnung von Entwickler-Settlements, gestaffelte Auszahlungslogik oder steuerliche Entwickler-Reports ausgelegt. Unternehmen, die Standard-Abrechnungssysteme f\u00fcr Marktplatz-Zwecke anpassen, bauen typischerweise innerhalb von 18 bis 24 Monaten die Settlement-Schicht neu, sobald Entwicklerzahl und Transaktionskomplexit\u00e4t steigen. Zweckgebundene Infrastruktur, die das vollst\u00e4ndige Marktplatz-Abrechnungsmodell von Beginn an abdeckt, vermeidet diesen Neuaufbau \u2013 das ist der sinnvollere Vergleichspunkt als reine Lizenzkosten.<\/span>"},{"question":"Wie funktioniert die Zuordnung (Attribution) mehrerer Agenten in einem einzelnen Kunden-Workflow?","answer":"<span style=\"font-weight: 400;\">Wenn ein Kunden-Workflow mehrere Agenten unterschiedlicher Entwickler aufruft, muss jeder Agent ein eigenes Billing-Event erzeugen, das Agent\u2011ID, Developer\u2011ID, Customer\u2011ID, Nutzungsmenge und den bewerteten Betrag enth\u00e4lt. Diese Events werden unabh\u00e4ngig geratet, zu einer einzelnen Kundenrechnung zusammengef\u00fchrt und anschlie\u00dfend zur Settlement-Berechnung verwendet, um den Anteil jedes Entwicklers an dieser Rechnung zu ermitteln. Voraussetzung f\u00fcr eine korrekte Zuordnung ist, dass das Event-Schema bereits im Moment der Erfassung Agenten-Identifiers auf Ebene des einzelnen Agenten enth\u00e4lt. Periodenaggregate, die die gesamte Agentennutzung in einer einzigen Position zusammenfassen, k\u00f6nnen weder developer-spezifische Settlement-Berechnungen unterst\u00fctzen noch nachtr\u00e4glich Zuordnungsstreitigkeiten aufl\u00f6sen.<\/span>"},{"question":"Welche Settlement-Frequenz ist bei Auszahlungen in KI\u2011Agenten\u2011Marktpl\u00e4tzen \u00fcblich?","answer":"<span style=\"font-weight: 400;\">Eine monatliche Abrechnung (Settlement) ist in der fr\u00fchen Betriebsphase von Marktpl\u00e4tzen Standard. W\u00f6chentliche Abrechnung wird notwendig, sobald das Auszahlungsvolumen an Entwickler steigt und Entwickler beginnen, ihre Liquidit\u00e4t an erwarteten Einnahmen auszurichten. Echtzeit- oder t\u00e4gliche Abrechnung ist selten und operativ komplex; sie wird typischerweise nur Entwicklern mit hohem Volumen zu individuell verhandelten Enterprise-Konditionen angeboten. Unabh\u00e4ngig von der Frequenz sollte die Settlement-Abrechnung den Entwicklern vor Ausf\u00fchrung der Auszahlung zur Verf\u00fcgung stehen, damit sie die Berechnung pr\u00fcfen und Einw\u00e4nde vor Periodenabschluss geltend machen k\u00f6nnen.<\/span>"}],"knowledge_hub_archive_url":"","knowledge_hub_archive_label":"","glossary_topic_tax_item":33676,"resource_marketo_form_id":"","marketo_form_title":"","marketo_form_sub_title":""},"_links":{"self":[{"href":"https:\/\/www.zuora.com\/de\/wp-json\/wp\/v2\/guides\/339500","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.zuora.com\/de\/wp-json\/wp\/v2\/guides"}],"about":[{"href":"https:\/\/www.zuora.com\/de\/wp-json\/wp\/v2\/types\/guides"}],"version-history":[{"count":0,"href":"https:\/\/www.zuora.com\/de\/wp-json\/wp\/v2\/guides\/339500\/revisions"}],"acf:term":[{"embeddable":true,"taxonomy":"topic","href":"https:\/\/www.zuora.com\/de\/wp-json\/wp\/v2\/topic\/33676"}],"wp:attachment":[{"href":"https:\/\/www.zuora.com\/de\/wp-json\/wp\/v2\/media?parent=339500"}],"wp:term":[{"taxonomy":"content_type","embeddable":true,"href":"https:\/\/www.zuora.com\/de\/wp-json\/wp\/v2\/content_type?post=339500"},{"taxonomy":"geo","embeddable":true,"href":"https:\/\/www.zuora.com\/de\/wp-json\/wp\/v2\/geo?post=339500"},{"taxonomy":"growth_initiatives","embeddable":true,"href":"https:\/\/www.zuora.com\/de\/wp-json\/wp\/v2\/growth_initiatives?post=339500"},{"taxonomy":"parent_guide_categories","embeddable":true,"href":"https:\/\/www.zuora.com\/de\/wp-json\/wp\/v2\/parent_guide_categories?post=339500"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/www.zuora.com\/de\/wp-json\/wp\/v2\/industry?post=339500"},{"taxonomy":"persona","embeddable":true,"href":"https:\/\/www.zuora.com\/de\/wp-json\/wp\/v2\/persona?post=339500"},{"taxonomy":"product_line","embeddable":true,"href":"https:\/\/www.zuora.com\/de\/wp-json\/wp\/v2\/product_line?post=339500"},{"taxonomy":"topic","embeddable":true,"href":"https:\/\/www.zuora.com\/de\/wp-json\/wp\/v2\/topic?post=339500"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}