Teillieferungen und Teilrechnungen im B2B-Shop steuern

Das Bürgerliche Gesetzbuch stellt den Ausgangspunkt klar: Der Schuldner ist zu Teilleistungen nicht berechtigt (Bundesministerium der Justiz). Eine Teillieferung ist damit kein Recht des Lieferanten, sondern etwas, das vereinbart wird – im Rahmenvertrag, in den Verkaufsbedingungen oder im einzelnen Auftrag. Für die Schnittstelle heißt das: Die Erlaubnis ist ein Datum, kein Bauchgefühl. Ein Feld am Auftragskopf, das aus dem Kundenstamm vorbelegt und im Checkout überschrieben werden kann, ist die technische Entsprechung dieser Vereinbarung. Fehlt es, entscheidet die Auftragsabwicklung jeden Fall neu, und die Entscheidung ist hinterher nicht nachvollziehbar.

Umsatzsteuerlich hängt an derselben Vereinbarung mehr als die Logistik. Bei der Berechnung der Steuer nach vereinbarten Entgelten entsteht sie mit Ablauf des Voranmeldungszeitraums, in dem die Leistungen ausgeführt worden sind; das gilt auch für Teilleistungen, die vorliegen, wenn für bestimmte Teile einer wirtschaftlich teilbaren Leistung das Entgelt gesondert vereinbart wird (Bundesministerium der Justiz). Ob eine Teillieferung eine Teilleistung in diesem Sinne ist, entscheidet also die Entgeltvereinbarung und nicht der Versandschein. Handelsrechtlich kommt hinzu, dass der Käufer die Ware unverzüglich nach der Ablieferung durch den Verkäufer zu untersuchen hat, soweit dies nach ordnungsmäßigem Geschäftsgange tunlich ist (Bundesministerium der Justiz) – bei zwei Ablieferungen laufen zwei Rügefristen, und der Kunde braucht je Sendung einen eigenen Lieferschein, um sie einhalten zu können.

Die europäische Norm für die elektronische Rechnung kennt den Fall. Das Feld BT-3 trägt den Code für die Rechnungsart, und die deutsche Ausprägung XRechnung nennt acht Codes aus der Codeliste UNTDID 1001, die dort übermittelt werden sollen: 326 für die Teilrechnung, 380 für die Handelsrechnung, 384 für die Rechnungskorrektur, 389 für die Gutschriftsabrechnung, 381 für die Gutschrift sowie 875, 876 und 877 für die Abschlags- und Schlussrechnungen im Bauwesen (KoSIT). Die Codeliste selbst kennt daneben 386 für die Vorauszahlungsrechnung (OpenPeppol). Wer eine Teilrechnung als 380 verschickt, verliert eine Information, die der Empfänger für die Zuordnung gebrauchen könnte.

Für die Kette sind zwei Kardinalitäten entscheidend. Die Gruppe BG-3 mit der Referenz auf die vorausgegangene Rechnung darf beliebig oft vorkommen (0..*) und trägt je Vorkommen die Kennung der vorausgegangenen Rechnung in BT-25 und optional deren Ausstellungsdatum in BT-26 (KoSIT). Eine Schlussrechnung kann damit sämtliche Teilrechnungen benennen, die ihr vorausgingen. Die Kennung für eine referenzierte Versandanzeige in BT-16 ist dagegen einmalig (0..1), ebenso das tatsächliche Lieferdatum in BT-72 (KoSIT). Auf Kopfebene lässt sich also genau eine Lieferung benennen – eine Sammelrechnung über drei Lieferscheine passt dort nicht hinein.

Der Ausschnitt zeigt die Stellen, an denen die Zuordnung hängt: die Auftragsnummer als Klammer über alles, die Kennung der Versandanzeige als Verweis auf den Lieferschein, das tatsächliche Lieferdatum als Zeitpunkt der Leistung und die Auftragspositionsnummer je Rechnungszeile. Das Umsatzsteuergesetz verlangt in der Rechnung ohnehin den Zeitpunkt der Lieferung oder sonstigen Leistung (Bundesministerium der Justiz); bei zwei Teillieferungen sind das zwei verschiedene Zeitpunkte in zwei verschiedenen Rechnungen. Wer beide Rechnungen mit dem Datum des zweiten Versands ausstellt, hat den Beleg formal beschädigt. Welche Fristen dabei ab 2027 gelten, steht im Beitrag zur Pflicht zur elektronischen Rechnung.

In der Praxis entstehen die teuren Fehler nicht beim ersten Teilversand, sondern beim zweiten. Eine Position wird doppelt berechnet, weil die Teilrechnung aus dem ERP und die Rechnung aus dem Shop-Prozess beide auf dieselbe Menge zugreifen. Eine Restmenge bleibt liegen, weil der Auftrag im Shop nach der ersten Lieferung auf „abgeschlossen“ gesprungen ist. Oder eine Nachlieferung wird versendet, obwohl der Kunde die Restmenge längst storniert hat. Alle drei Fälle haben dieselbe Ursache: Es gibt mehr als eine Stelle, an der die offene Menge geführt wird. Dasselbe Muster kennt jede Bestandssynchronisation über mehrere Lager.

Die Belegkette ist erst dann fertig, wenn sie im Kundenkonto ankommt. Ein Auftrag, der als teilweise geliefert ausgewiesen ist, braucht drei Angaben auf einen Blick: welche Positionen mit welcher Menge geliefert wurden, welche Menge offen ist und welcher Termin für den Rest gilt. Der Zustand des ganzen Auftrags ist dabei nachrangig – der Einkäufer will wissen, ob seine Position dabei war, nicht ob der Auftrag statistisch als abgeschlossen zählt. Ein Fortschrittsbalken je Position sagt darüber mehr aus als ein Statuswort je Auftrag.

Dazu gehört der Zugriff auf die Belege selbst. Jeder Lieferschein und jede Rechnung liegen als Datei im Konto, nach Datum sortiert und je Auftrag gruppiert. Der Bezug wird sichtbar gemacht, nicht unterstellt: Die Rechnung nennt den Lieferschein, den sie abrechnet, und der Lieferschein nennt die Rechnung, sobald sie existiert. Wer bereits Versand- und Logistikschnittstellen angebunden hat, hängt die Sendungsverfolgung an das Lieferereignis und nicht an den Auftrag – bei zwei Sendungen gibt es zwei Nummern, und eine davon im Auftragskopf zu speichern, kostet später eine Rückfrage.

Eine Teillieferungslogik lässt sich prüfen, ohne auf den nächsten Engpass zu warten. Der Testfall bleibt derselbe: ein Auftrag mit mehreren Positionen, eine Lieferung über einen Teil der Mengen, eine Rechnung darüber, danach die zweite Lieferung und die Schlussrechnung. Entscheidend ist, dass die Prüfung an den Belegen ansetzt und nicht an den Statusfeldern – ein Statusfeld sagt, was ein System glaubt, ein Beleg sagt, was es ausgestellt hat.

Teillieferungen sind kein Randfall, den man beim nächsten Release nachzieht, sondern der Normalbetrieb eines Sortiments mit Zulaufware. Ob der Onlinekanal daran wächst oder Rückfragen erzeugt, entscheidet sich an drei Stellen: an einem Datenmodell, das mehrere Lieferungen und Rechnungen je Auftrag zulässt, an Belegen, die einander benennen, und an einem Kundenkonto, das die offene Menge zeigt. Wir bauen diese Kette in bestehende Systeme ein – von der Anbindung an SAP über die Middleware bis zur elektronischen Rechnung – und prüfen sie an echten Belegen statt an Statusfeldern. Einen Überblick über die einzelnen Bausteine gibt die Seite zu unseren Leistungen.