E-Commerce-Buchhaltung: Was KI-Bestellungen kaputtmachen

Am 11. Januar 2026 hat Google auf der NRF-Keynote das Universal Commerce Protocol vorgestellt, gemeinsam entwickelt mit Shopify und gebaut mit Etsy, Wayfair, Target und Walmart. Es gibt einem KI-Agenten einen einheitlichen Weg, den Katalog eines Händlers zu lesen und den Checkout auszuführen. OpenAI und Stripe haben ihre eigene Variante, Microsoft hat den Checkout in Copilot eingebaut, und das erklärte Ziel ist, dass Käufer den Chat nie verlassen.

Jeder dieser Käufe landet irgendwann in der Buchhaltung eines Verkäufers. Die Annahme der Branche lautet: KI-Bestellungen sind einfach mehr Bestellungen, also kommt ein System, das Onlineverkäufe schon beherrscht, auch damit zurecht.

Das ist nicht der Fehlerfall. Der Fehlerfall ist, dass eine Agenten-Bestellung ohne Kundendatensatz ankommt, und in den meisten Buchhaltungssystemen ist der Kundendatensatz das Einzige, das weiß, welches Land die Umsatzsteuer bestimmt.

Ich kann das an unserem eigenen Hauptbuch zeigen, denn wir haben denselben Defekt.

Warum bucht automatisierte Buchhaltung E-Commerce-Umsätze als inländisch?

Norman ist ein deutsches Buchhaltungs- und Steuerprodukt. Etwa eine von fünfzig Einnahmezeilen in unserem Hauptbuch ist grenzüberschreitend gebucht. Alles andere ist inländisch. Schnell gelesen heißt das: Unsere Kunden verkaufen zu Hause. Es heißt nichts dergleichen. Es heißt, unser Default ist inländisch.

Das Land eines Umsatzes wird an genau einer Stelle abgeleitet, unter genau einer Bedingung:

# Skizze der Form, nicht unser Quellcode.
def on_save(transaction):
    if transaction.client and transaction.client.country:
        transaction.supplier_country = bucket(
            transaction.client.country, transaction.company.country
        )  # inland | eu | drittland
    # Kein Kunde? Das Feld behält, womit es angelegt wurde.

Die Leistungsortlogik hängt an einem verknüpften Kunden. Kein Kunde, keine Ableitung, und die Zeile behält den inländischen Wert, mit dem sie entstanden ist. Das ist der Normalfall für alles, was als Geld statt als Beleg ankommt.

Die Messung, die das greifbar macht: ob eine Einnahmezeile überhaupt eine Kennzeichnung als Lieferung oder Leistung trägt, den zweiten Input, den die Leistungsortregeln brauchen. Bei grenzüberschreitend gebuchten Zeilen tragen ihn mehr als neun von zehn. Bei inländisch gebuchten etwa eine von vierzehn. Diese Lücke ist keine Schlamperei. Sie ist ausschließlich die Frage, ob ein Kundendatensatz existierte, aus dem sich das ableiten ließ. Rechnungen haben Kunden. Bankeingänge nicht.

Die ehrliche Lesart von "98 % inländisch" ist also: Bei 98 % unserer Einnahmezeilen wurde die Frage nie gestellt.

Heute ist das verkraftbar, denn die grenzüberschreitenden Einnahmen eines deutschen Freiberuflers sind eine Handvoll großer B2B-Rechnungen im Jahr, jede mit Kunde. In unserem Hauptbuch ist die durchschnittliche Drittlands-Einnahmezeile ein Mehrfaches der durchschnittlichen inländischen wert. Wenige, groß, belegt.

Ein KI-getriebener Bestellstrom ist das Spiegelbild: viele, klein, anonym in dem Moment, in dem das Geld fließt. Knapp drei von zehn Unternehmen mit Umsatz in unserem Hauptbuch haben bereits mindestens einen grenzüberschreitenden Verkauf gebucht, und ein Drittel der inländischen Einnahmezeilen liegt schon heute unter 50 Euro. Das bestellungsförmige Geld kommt an. Es wird nur als inländisch abgelegt.

Zählt eine Shopify-Auszahlung als Umsatz?

Nein, und das ist die zweite Sache, die bricht, unabhängig von KI.

Ein Shop mit Zahlungsdienstleister erzeugt zwei Geldereignisse für einen Verkauf: die Bestellung, das ist der Umsatz brutto am Tag der Kundenzahlung, und die Auszahlung, bei der der Dienstleister Tage später ein Bündel Bestellungen abzüglich Gebühren aufs Konto schiebt.

Buchst du beides, verdoppelt sich der Umsatz. Importiert der Bankfeed die Auszahlung zusätzlich als Einnahme, verdreifacht er sich. Genau das war der Bug in unserem ersten Anlauf einer Shop-Anbindung, gefunden bevor er einen Kunden erreicht hat, und es ist der häufigste Weg, auf dem E-Commerce-Automatisierung eine schöne, vollständig falsche Gewinnermittlung produziert.

Das richtige Modell ist langweilig und gehört klar gesagt:

• Die Bestellung ist das Umsatzereignis. Brutto, zum Satz des Bestimmungslandes, am Zahlungsdatum.
• Die Auszahlung ist kein Umsatz. Nur die Gebühr des Dienstleisters ist Aufwand. Der passende Bankeingang ist ein Durchlaufposten, keine Einnahme.
• Die Erstattung ist negativer Umsatz auf der Einnahmenseite. Sie ist niemals Aufwand.

Der letzte Punkt klingt pedantisch, bis man auf die Mengen schaut. Erstattungen liegen bei rund zwei bis drei Prozent der Einnahmezeilen in unserem Hauptbuch, und diese Population ist von Dienstleistungen dominiert, wo es kaum Retouren gibt. Konsumgüter, die ein Agent nach bester Übereinstimmung kauft, laufen nicht auf zwei Prozent. Buchst du die als Aufwand, blähst du Umsatz und Kosten zugleich auf und gibst deiner Umsatzsteuervoranmeldung eine Zahl, die zu keinem Kontoauszug passt.

Was ein Bestellstrom tatsächlich verlangt

Die drei Umsatzformen unten brauchen unterschiedliche Maschinerie. Der Großteil deutscher Buchhaltungsautomatisierung ist für die erste Spalte gebaut und wird verkauft, als decke er die dritte ab.

Die technische Schlussfolgerung ist eng und läuft der aktuellen Stimmung leicht zuwider: Bestimmungsland-Umsatzsteuer ist ein Routing-Problem, kein Klassifikationsproblem. Die Versuchung ist, das einem Modell zu geben, weil die Bestelldaten halbstrukturiert sind und Modelle darin gut sind. Tu es nicht. Das Bestimmungsland ist ein Feld. Der Satz für dieses Land an diesem Datum ist ein Nachschlagen. Die Regel, ob du ihn berechnest, deutsche Umsatzsteuer berechnest oder gar keine, ist ein kurzer Entscheidungsbaum, der im Gesetz steht. Ein Modell, das raten soll, liegt meistens richtig, und das ist das schlechteste Ergebnis für etwas, das jährlich geprüft wird.

Wo ein Modell seinen Platz verdient, ist der Teil ohne Regel: zu entscheiden, dass dieser Bankeingang und jener Auszahlungsreport dasselbe Bündel beschreiben, oder dass eine Position namens "Versandschutz" eine Leistung ist und keine Lieferung.

Wir haben dieses bestellungsorientierte Modell in Normans Shop-Anbindung gebaut, es läuft in unserer Entwicklungsumgebung und ist für Kunden noch nicht freigeschaltet. Das Schreiben hat meine Sicht darauf verändert, was der schwere Teil ist. Ich hatte die Steuerregeln erwartet. Der schwere Teil war, dass unser Hauptbuch, wie die meisten, um den Beleg herum entworfen wurde, und ein Bestellstrom hat keinen Beleg.

Was der ViDA-Zeitplan daran ändert

Die regulatorische Richtung macht den Default schlimmer. Unter VAT in the Digital Age wird der One-Stop-Shop ab 1. Januar 2027 erweitert, und ab 1. Juli 2028 dehnt die einheitliche Umsatzsteuerregistrierung ihn auf praktisch alle B2C-Umsätze aus. Der Sinn ist, dass ein Verkäufer viele Länder über eine Registrierung meldet, und das funktioniert nur, wenn die Bücher wissen, zu welchem Land jeder Verkauf gehörte. Ein System, das still alles als inländisch ablegt, produziert eine sauber aussehende Umsatzsteuervoranmeldung und eine OSS-Meldung, die aus dem falschen Grund leer ist.

Wenn du gerade Software auswählst, ist die Frage an einen Anbieter nicht, ob er OSS unterstützt. Sie lautet, woher das Bestimmungsland kommt, wenn es keinen Kundendatensatz gibt.

Zum Weiterlesen: das OSS-Verfahren in Deutschland, Verkaufen auf Amazon und die steuerliche Anmeldung, Buchhaltung automatisieren für den Weg außerhalb des E-Commerce, und der Agent, der unsere Umsatzsteuervoranmeldungen abgibt.

Häufige Fragen

Welche Umsatzsteuerregeln gelten für den grenzüberschreitenden E-Commerce in der EU?

Bei Verkäufen an Privatpersonen in anderen EU-Ländern entscheidet die EU-weite Lieferschwelle von 10.000 Euro. Darunter bleibt der Umsatz in Deutschland steuerbar. Darüber verlagert sich der Leistungsort ins Bestimmungsland, und du schuldest den dortigen Steuersatz, meldest ihn aber über den One-Stop-Shop in einer einzigen Erklärung. Das ist eine Zusammenfassung, keine Beratung für deinen Fall.

Wie handhabt man Steuern für E-Commerce-Verkäufe?

Buchhalterisch braucht jede Bestellung drei Angaben, die eine reine Bankbuchung nicht liefert: das Bestimmungsland, ob es sich um eine Lieferung oder eine Leistung handelt, und den tatsächlich berechneten Steuersatz. Wer nur den Zahlungseingang bucht, verliert alle drei. Deshalb ist die Bestellung und nicht die Auszahlung der richtige Ausgangspunkt.

Zählt eine Shopify-Auszahlung als Umsatz?

Nein. Die Auszahlung ist eine Sammelabrechnung bereits verdienter Bestellungen, abzüglich Gebühren und oft abzüglich Erstattungen. Der Umsatz entsteht mit der Bestellung, brutto, bei Zahlung des Kunden. Die Auszahlung gehört als Durchlaufposten plus Gebührenaufwand gebucht. Sie zusätzlich zu den Bestellungen als Einnahme zu buchen, ist die häufigste Ursache für doppelten E-Commerce-Umsatz.

Ändern KI-Einkaufsagenten etwas an der Umsatzsteuer?

An den Regeln nichts. Leistungsort, Lieferschwelle und OSS gelten unverändert. Was sich ändert, sind die Daten: Agenten-Bestellungen kommen in hoher Zahl, klein und ohne den Kundendatensatz, aus dem die meisten Buchhaltungssysteme das Bestimmungsland ableiten. Die Pflicht bleibt, der Input dafür fehlt, und deshalb ist der Fehler lautlos.

Kann eine KI den Steuersatz einer Bestellung bestimmen?

Sie sollte es nicht. Das Bestimmungsland ist ein Feld in den Bestelldaten, der Satz ein Nachschlagen nach Land und Datum. Beides ist deterministisch. Ein deterministisches Nachschlagen an ein Modell zu geben, kauft dir gelegentliche selbstbewusste Fehler in einer Zahl, die geprüft wird. Modelle gehören an die wirklich mehrdeutigen Stellen, etwa das Zuordnen eines Bankeingangs zu einem Auszahlungsbündel.