Typisches Szenario:

Ein deutsches Handelsunternehmen betreibt seinen Hauptsitz in Deutschland und ist dort auch im SAP-System mit einem Buchungskreis abgebildet. Zusätzlich wird ein Lager in Österreich genutzt, aus dem Waren direkt an österreichische Endkunden geliefert werden.

Konkretes Beispiel

 

• Unternehmen: Handels GmbH (Deutschland)
• Buchungskreis: 1000 (DE)
• Zentrallager: Hamburg (Deutschland)
• Auslieferungslager: Salzburg (Österreich)

Das Unternehmen vertreibt seine Produkte über einen Online-Shop im gesamten DACH-Raum.

Steuerliche Ausgangssituation

Sobald das österreichische Lager für Lieferungen an Kunden in Österreich genutzt wird, entsteht dort eine umsatzsteuerliche Registrierungspflicht in Österreich.

Das bedeutet konkret:

• Das Unternehmen bleibt eine rechtliche Einheit (ein Buchungskreis)
• Es erhält zusätzlich eine österreichische Umsatzsteuer-Identifikationsnummer
• Es muss in Österreich:
  • Umsatzsteuer-Voranmeldungen abgeben
  • ggf. Zusammenfassende Meldungen berücksichtigen
  • lokale steuerliche Meldepflichten erfüllen

Die SAP-Herausforderung

Im SAP-System laufen alle Buchungen weiterhin im deutschen Buchungskreis 1000. Gleichzeitig entstehen jedoch zwei steuerliche Welten:

Geschäftsvorfall	Lager/Werk	Steuerliche Zuordnung
Verkauf nach Deutschland	Hamburg	deutsche USt-Registrierung
Verkauf aus Österreich an AT-Kunden	Salzburg	österreichische USt-Registrierung

Ohne zusätzliche steuerliche Logik kann SAP nicht unterscheiden, welche Umsätze welcher Steuerregistrierung zugeordnet werden müssen.

Lösung mit „Werke im Ausland (WIA)“

Hier setzt die SAP-Funktion Plants Abroad (WIA) an.

Das österreichische Lager wird im System als Werk im Ausland geführt, bleibt aber organisatorisch dem deutschen Buchungskreis zugeordnet.

Damit ergibt sich folgende Struktur:

• Buchungskreis: Deutschland
• Werk Salzburg → Land: Österreich
• zusätzliche USt-IdNr.: österreichische Registrierung

Wie SAP die steuerliche Trennung ermöglicht

Durch die Aktivierung von WIA werden zusätzliche steuerliche Steuerungsparameter im System verfügbar, insbesondere:

• Zuordnung eines Meldelandes (Reporting Country) zum Steuerkennzeichen
• Hinterlegung mehrerer USt-Identifikationsnummern pro Buchungskreis
• Nutzung länderspezifischer Steuerlogiken im Customizing

Beispielhafte Logik im System:

• Steuerkennzeichen D9 → Meldeland Deutschland
• Steuerkennzeichen A2 → Meldeland Österreich

Damit kann SAP eindeutig ableiten:

Dieser Beleg gehört zur jeweiligen Umsatzsteuerregistrierung im entsprechenden Land.

Ergebnis im operativen Prozess

Wird eine Rechnung für einen Kunden aus dem österreichischen Lager gebucht, läuft der Prozess wie folgt:

• SAP erkennt das Werk „Salzburg“
• Das Steuerkennzeichen verweist auf das Meldeland Österreich
• Der Beleg wird der österreichischen Umsatzsteuerregistrierung zugeordnet
• Diese Information steht anschließend für Reporting und DRC zur Verfügung

Abwicklung in SAP DRC bei mehreren Umsatzsteuerregistrierungen (ohne eigenen Buchungskreis)

Nachdem im SAP-System über WIA die steuerliche Grundlage geschaffen wurde, stellt sich die zentrale Frage:

Wie stellt SAP DRC sicher, dass diese Belege korrekt an die richtige Steuerbehörde gemeldet werden?

Ausgangssituation im DRC-Kontext

Mit SAP Document and Reporting Compliance (DRC) muss das System entscheiden:

Welcher Beleg gehört zu welcher Umsatzsteuerregistrierung und damit zu welchem eDocument-Prozess?

Rolle von SAP DRC im Gesamtprozess

Wichtig ist die klare Abgrenzung der Verantwortlichkeiten:

• FI / SD (inkl. WIA) liefert die steuerliche Einordnung des Belegs
• DRC (eDocument Framework) verarbeitet diese Informationen und erzeugt daraus ein meldefähiges elektronisches Dokument
• Die Steuerbehörde wird dabei nicht direkt im Beleg bestimmt, sondern über Customizing- und Steuerlogik abgeleitet

Zentrale Steuerungslogik im eDocument Cockpit

1. FI- bzw. SD-Belegart als Steuerungsmerkmal

Ein praktikabler Ansatz zur Trennung unterschiedlicher Umsatzsteuerregistrierungen ist der Einsatz unterschiedlicher Belegarten.

Im SD- oder FI-Prozess kann bereits definiert werden, welche Belegart für bestimmte Auslandsszenarien verwendet wird. So lassen sich beispielsweise Lieferungen über eine ausländische Umsatzsteuer-Identifikationsnummer bewusst mit einer abweichenden Rechnungs- oder Belegart buchen.

Diese Differenzierung wird im SAP eDocument Framework weiterverwendet. Im Customizing können eDocument-Typen gezielt an bestimmte Belegarten gekoppelt werden.

Im eDocument Cockpit lassen sich dadurch pro Buchungskreis mehrere Verarbeitungslogiken definieren, die anhand der Belegart gesteuert werden.

Das Ergebnis:
Ein einzelner Buchungskreis kann mehrere parallele eDocument-Prozesse enthalten, die jeweils unterschiedlichen Umsatzsteuerregistrierungen zugeordnet sind.

2. Steuerkennzeichen als zentrales Unterscheidungsmerkmal

Ein weiterer zentraler Steuerungshebel sind die Steuerkennzeichen (Tax Codes). Sie definieren den konkreten Steuerfall inklusive Steuersatz, Steuerart und Steuerland.

In der Praxis empfiehlt es sich, für jedes Land mit Umsatzsteuerregistrierung eigene Steuerkennzeichen zu verwenden. Dadurch ist bereits auf Belegebene ersichtlich, welche Registrierung betroffen ist.

Zusätzlich ist es entscheidend, dass die jeweiligen Umsatzsteuer-Identifikationsnummern (USt-IdNr.) vollständig und korrekt im System gepflegt werden.

Ein besonders wichtiger Aspekt ist die Pflege des Meldelandes im Steuerkennzeichen (FTXP, Tabelle T007A). Dieses Feld verknüpft das Steuerkennzeichen direkt mit einer steuerlichen Landeszuordnung.

Damit wird das Steuerkennzeichen nicht nur steuerlich (z. B. über den Steuersatz), sondern auch meldeseitig eindeutig einem Land zugeordnet. Diese Zuordnung bildet eine zentrale Grundlage für Reporting- und DRC-Prozesse.

Konzeption: klare Zuordnungslogik

Zu Beginn eines Projekts sollte eindeutig definiert werden, welches Kriterium die Steuerungslogik bestimmt – typischerweise Steuerkennzeichen oder Belegart.

Diese Entscheidung muss dokumentiert und verbindlich für alle Beteiligten festgelegt werden, um spätere Inkonsistenzen im Reporting zu vermeiden.

Standard vor Erweiterung

Grundsätzlich sollte der SAP-Standard konsequent genutzt werden. Steuerkennzeichen, Belegarten und das eDocument Customizing reichen in vielen Szenarien aus, um die notwendige Logik abzubilden.

Erweiterungen über BAdIs sollten nur dann eingesetzt werden, wenn die Standardmechanismen nicht ausreichen. Standardnahe Lösungen sind in der Regel transparenter, stabiler und wartungsfreundlicher im Betrieb.

 

Abschließend zeigt sich, dass sich umsatzsteuerliche Auslandsregistrierungen auch ohne zusätzliche Buchungskreise sauber in SAP DRC abbilden lassen, sofern die steuerliche Vorarbeit in WIA sowie eine konsistente Steuerungslogik über Steuerkennzeichen und Belegarten konsequent umgesetzt werden.