Webshop, Kassa und Ladengeschäft in einem Mandanten: der OSS-Stolperstein
Webshop, Kassa und Ladengeschäft bei einem Mandanten: warum die OSS-Einstellung über die Konten entscheidet und wie sich die Kanäle zu einer Importdatei zusammenführen.
Es gibt einen Mandanten-Typ, bei dem die meisten Kanzleien am Monatsende kurz durchatmen, bevor sie die Buchhaltung anfangen: den Händler mit mehreren Verkaufskanälen. Ein Webshop, der quer durch die EU liefert. Ein Kassensystem im Geschäft. Dazu der klassische Verkauf über die Theke. Drei Kanäle, drei Exporte, drei Logiken. Und am Ende soll alles sauber in BMD, RZL oder DATEV landen.
Das eigentliche Problem ist nicht ein einzelner Kanal. Es ist die Summe. Und mitten drin sitzt eine Entscheidung, die darüber bestimmt, auf welche Konten überhaupt gebucht wird: die OSS-Einstellung des Mandanten.
Warum drei Kanäle in der Praxis nicht zusammenpassen
Jeder Kanal liefert seine Daten anders. Das Kassensystem exportiert Tagesabschlüsse, oft als CSV mit eigener Spaltenlogik. Der Webshop liefert Bestelldaten mit Lieferland, Versand und Rabatt in getrennten Feldern. Und der stationäre Verkauf taucht häufig gar nicht strukturiert auf, sondern nur als Summe in einer Zusammenfassung.
Was dabei selten existiert: ein vollständiger Export aus einem Guss. Stattdessen kommt ein Stapel Dateien, bei dem die Kanzlei zuerst herausfinden muss, welche Zeile zu welchem Kanal gehört und ob überhaupt alles dabei ist. Genau das beobachten wir in Demos mit Handels-Mandanten regelmäßig: Die Kanaldaten sind unvollständig, und niemand kann auf Anhieb sagen, ob die Summe am Ende stimmt.
Die Folge ist Handarbeit. Jemand kopiert die Kassendaten in eine Hilfstabelle, fügt die Webshop-Zeilen darunter, gleicht Datumsformate an, rechnet Versand und Rabatt heraus und versucht, am Schluss auf eine plausible Gesamtsumme zu kommen. Jeden Monat aufs Neue.
Der eigentliche Stolperstein: die OSS-Einstellung
Bei einem reinen Inlandsverkäufer ist die Steuerlogik überschaubar. Sobald der Webshop aber Privatkunden in anderen EU-Ländern beliefert, kommt der One-Stop-Shop ins Spiel. Und hier entscheidet sich, auf welche Konten gebucht wird.
Vereinfacht gesagt: Für grenzüberschreitende Verkäufe an Privatpersonen gibt es in der Regel eine EU-weite Lieferschwelle. Liegt der Mandant darunter, kann er typischerweise weiterhin mit dem österreichischen Steuersatz fakturieren. Liegt er darüber oder verzichtet er freiwillig auf die Schwelle, schuldet er die Umsatzsteuer des jeweiligen Bestimmungslandes und meldet diese gebündelt über OSS. Ob die Lieferschwelle genutzt oder darauf verzichtet wird, ist eine Einstellung beim Mandanten, keine Eigenschaft der Exportdatei.
Für die Buchhaltung heißt das: Dieselbe Webshop-Zeile landet je nach OSS-Status auf einem anderen Konto und mit einem anderen Steuercode. Eine Lieferung an einen Unternehmer mit gültiger UID im EU-Ausland ist wiederum ein dritter Fall, der getrennt behandelt wird. Wer das aus einem unsortierten Mehrkanal-Export von Hand ableitet, prüft jede einzelne Zeile gegen die Frage: Inland, EU-Privat über OSS, oder innergemeinschaftliche Lieferung an einen Unternehmer.
Hinweis vorab: Die konkrete OSS-Behandlung und die jeweils geltenden Schwellen klärt jede Kanzlei ohnehin selbst mit dem Mandanten. Was hier zählt, ist nicht die steuerliche Beurteilung, sondern dass die einmal getroffene Entscheidung sauber und wiederholbar auf jede Buchung angewandt wird.
Was sich davon automatisieren lässt
Genau an dieser Stelle setzt ein Konverter an. Er trifft keine steuerliche Entscheidung. Er wendet die Entscheidung an, die Sie für den Mandanten festgelegt haben, und zwar bei jeder Datei gleich. Drei Bausteine sind dafür relevant.
Erstens: die Kanäle zusammenführen. Über den Multi-File-Upload lassen sich die Exporte aus Webshop, Kassa und stationärem Verkauf gemeinsam einreichen, auch als ZIP-Bündel. Der Konverter führt sie zu einer einzigen Importdatei zusammen, statt dass jemand drei Tabellen von Hand untereinanderkopiert.
Zweitens: das Steuercode-Mapping. Der gemischte Umsatz wird auf die passenden BMD-Steuercodes abgebildet. Für eine innergemeinschaftliche Lieferung an einen Unternehmer gibt es den eigenen Code (in BMD ist das Steuercode 7), für grenzüberschreitende Umsätze einen weiteren (Steuercode 77), daneben die inländischen Erlöscodes. Die Zuordnung erfolgt automatisch über Mustererkennung und einen Datenbank-Abgleich, mit der Möglichkeit, jede Zuordnung manuell zu überschreiben. Das ist wichtig: Sie behalten die Kontrolle über jede Regel, der Konverter rät nicht im Hintergrund.
Drittens: die UID prüfen. Damit eine Lieferung überhaupt als innergemeinschaftliche Lieferung an einen Unternehmer durchgeht, muss die UID des Empfängers passen. Der Konverter validiert die UID gegen das EU-Muster und weist auf, wenn etwas nicht stimmt, statt eine zweifelhafte Zeile still durchzubuchen.
Am Ende steht eine Datei, die in BMD, RZL oder DATEV einspielbar ist. Einmal für den Mandanten eingerichtet, läuft derselbe Ablauf jeden Monat gleich, egal welche der drei Kanal-Dateien diesmal wie aussehen.
Ein typischer Fall
Stellen Sie sich eine Steuerberatung vor, die einen Händler betreut. Der verkauft über einen EU-Webshop an Privatkunden in mehreren Ländern, kassiert im Geschäft über ein Kassensystem und macht daneben Verkauf über die Theke. Am Monatsende landen drei verschiedene Exporte bei der Kanzlei, keiner davon vollständig, und ein Gesamtexport aus einem System existiert schlicht nicht.
Heute heißt das: zusammenkopieren, Datumsformate angleichen, pro Zeile entscheiden, ob Inland, OSS oder innergemeinschaftliche Lieferung, und am Schluss hoffen, dass die Summe stimmt. Mit einem eingerichteten Konverter heißt es: drei Dateien hochladen, die hinterlegte OSS-Logik und das Steuercode-Mapping greifen automatisch, auffällige Zeilen werden markiert statt stillschweigend gebucht, fertige Importdatei herunterladen.
Wo die Grenze liegt
Ehrlich bleibt: Ein Konverter ersetzt nicht Ihre steuerliche Beurteilung. Ob der Mandant die Lieferschwelle nutzt, ob die OSS-Registrierung korrekt ist, ob ein Sonderfall vorliegt, das entscheidet die Kanzlei. Was der Konverter übernimmt, ist die mechanische, fehleranfällige Arbeit dahinter: Kanäle zusammenführen, Steuercodes konsistent anwenden, UID prüfen, eine importierbare Datei erzeugen. Die Beurteilung bleibt bei Ihnen, die Fleißarbeit nicht.
Wenn Sie es an Ihrem eigenen Mandanten sehen wollen
Der schnellste Weg, das einzuschätzen, ist ein echter Export. Schicken Sie uns einen Monat aus dem Mehrkanal-Mandanten, der bei Ihnen den meisten Aufwand macht. Anonymisiert, wenn Sie möchten, es zählt nur die Struktur. Wir bauen daraus den Konverter, den ersten kostenlos als Proof-of-Concept, und Sie bekommen die importfertige Datei für BMD, RZL oder DATEV zurück. Ohne Risiko, ohne Verpflichtung. So sehen Sie an Ihren eigenen Daten, ob sich der Aufwand lohnt.
E-Commerce-Mandant mit mehreren Kanälen? Schicken Sie uns einen Export, der erste Converter ist gratis: hallo@kanzlei-import.at
Dominik Pototschnig, Gründer kanzlei-import.at Kontakt: hallo@kanzlei-import.at Weiterführend: 3 typische BMD-Import-Probleme · Eine Bank, fünf Exportformate