Außenhandel im SAP ist keine Modulfrage, sondern eine Prozesseinführung. Sanktionslistenprüfung, Ausfuhrkontrolle und Präferenzabwicklung greifen in Geschäftspartner, Auftrag, Lieferung und Faktura ein — in jedem Werk, das ins Template kommt. Eine zu scharfe Einstellung blockiert den Versand, eine zu weiche lässt das Risiko im Haus. Was bei einer solchen Einführung zu klären ist:
Drei Blöcke, die getrennt zu betrachten sind
Hinter dem Kurzwort GTS stecken drei Prozesse mit eigener Datenbasis und sehr unterschiedlichem Aufwand. Wer sie in eine Welle packt, bindet die schnellen an den langsamsten.
- Sanktionslistenprüfung. Geschäftspartner und Belege gegen die geführten Listen prüfen, mit Sperr- und Freigabeweg. Zu entscheiden ist, welche Belegarten überhaupt geprüft werden, wer freigibt und wie lange ein gesperrter Beleg liegen bleiben darf. Der eigentliche Aufwand nach dem Go-Live sind Treffer, die keine sind.
- Legal Control und Embargo. Ausfuhrkontrolle über die Güterklassifizierung, Genehmigungen und deren Abschreibung, Länderembargos, dazu der US-Reexport mit Einstufung und De-minimis-Betrachtung. Hier hängt fast alles an Stammdaten, die in den Werken entstehen, nicht am Customizing.
- Präferenz und Zoll. Lieferantenerklärungen anfordern, überwachen und auswerten, Präferenzkalkulation über Stückliste und Preise, Ursprungsbestimmung je Abkommen, Ausstellung der Nachweise. Der aufwendigste der drei Blöcke — und der einzige, der eine vollständige Stücklistenkette braucht.
Der Systemschnitt entscheidet mehr als das Customizing
GTS ist ein eigenes System beziehungsweise ein eigener Mandant; die operativen Systeme sind Feeder. Ein Co-Deployment von Feeder und GTS auf einer Instanz ist ein von SAP dokumentiertes Installationsszenario — GTS liegt dann trotzdem in einem eigenen Mandanten. Diese Entscheidung fällt am Anfang und prägt danach jede Rollout-Welle.
Denn die Datenbasis kommt aus dem Feeder: Geschäftspartner, Produkte, Stücklisten und Einkaufsinfosätze gehen über Änderungszeiger und einen Verteilungslauf ins GTS. Bei ECC-, S/4HANA- und Fremdsystemen nebeneinander ist je Quelle zu klären, was übertragen wird, wie oft und wer den Lauf überwacht.
Der häufigste Befund bei einer Bestandsaufnahme ist nicht falsches Customizing, sondern ein nicht eingeplanter Verteilungslauf: Die Änderungszeiger laufen auf, im GTS steht kein klassifiziertes Produkt — und die Prüfung greift ins Leere, ohne dass jemand einen Fehler sieht.
Präferenz: was vor dem ersten Lauf steht
Das Abkommen wird im GTS als Rechtsvorschrift geführt und dort für die Präferenz aktiviert; die Präferenz selbst ist ein eigener Service, der je Belegart scharfgeschaltet wird. Dazu kommen Warentarifschema und Tarifnummern, das Regelwerk je Abkommen, die Verwaltungseinheit, das werksbezogene Präferenzmodell — und die Nummernkreise, die man beim ersten Lauf zuverlässig vergisst.
Die rechtliche Seite gehört in dieselbe Konzeption, weil sie Fristen und Belegpflichten setzt, die das System nur abbildet:
- Eine Langzeit-Lieferantenerklärung deckt höchstens 24 Monate ab; der Beginn darf bis zu zwölf Monate zurück und bis zu sechs Monate vorausliegen.
- Bis 6.000 Euro Sendungswert genügt die formlose Ursprungserklärung; darüber braucht es die REX-Registrierung beziehungsweise den Ermächtigten Ausführer.
- Ursprungszeugnis und INF 4 sind keine Präferenznachweise — eine Verwechslung, die in Konzepten regelmäßig auftaucht.
- Die revidierten Pan-Europa-Mittelmeer-Ursprungsregeln sind seit dem 01.01.2025 verbindlich: Wertregeln bei 50 Prozent, Toleranz 15 Prozent, EUR-MED entfällt. Ein Regelwerk aus einem älteren Projekt ist damit nicht mehr tragfähig.
- Aufbewahrung: zehn Jahre. Das ist eine Archiv-, keine Customizing-Frage — und sie wird beim Systemschnitt gern übersehen.
Beim Umstieg auf S/4HANA
Präferenz ist im S/4HANA kein SD-Thema mehr: Sämtliche Präferenz-Pakete liegen dort in der GTS-Auslieferungseinheit, während der S/4-Kern Klassifizierung, Legal Control und Intrastat mitbringt. Für Präferenz und Zollabwicklung braucht es GTS.
Die klassischen SD-Außenhandelsobjekte liegen technisch weiterhin im S/4-Repository und sind nicht gesperrt — das führt in Bewertungen oft zu dem Schluss, es sei nichts zu tun. Als Zielarchitektur gelten sie trotzdem nicht mehr. Wer heute im ERP kalkuliert, führt den Wechsel als eigenes Teilprojekt, nicht als Nebenprodukt der Konversion.
Was in einer Rollout-Welle zu entscheiden ist
| Frage | Woran sie hängt |
|---|---|
| Welche Belege werden geprüft, und wann? | Belegarten, Zeitpunkt der Prüfung, Sperrverhalten — zu weit gefasst blockiert es den Versand, zu eng lässt es Sendungen durch |
| Wer entscheidet über einen Treffer? | Benannte Rolle mit Vertretung, Freigabeweg, Reaktionszeit; ohne das staut sich der Versand am ersten Feiertag |
| Woher kommt die Klassifizierung? | Stammdatenarbeit in den Werken mit eigener Vorlaufzeit — der längste Pfad jeder Welle |
| Welche Quellsysteme liefern? | Je Feeder eigene Verdrahtung, Änderungszeiger und Verteilungslauf; Fremdsysteme brauchen einen eigenen Weg |
Fallen, die sich wiederholen
- Die Einführung wird als IT-Projekt geschnitten, obwohl Klassifizierung, Genehmigungen und Ursprungsregeln auf dem kritischen Pfad liegen — und die kann die IT nicht liefern.
- Ein Regelwerk wird aus einem älteren Stand übernommen, ohne die revidierten Ursprungsregeln nachzuziehen.
- Die Schulung der Verantwortlichen für Exportkontrolle wird ans Ende gelegt. Sie gehört vor den ersten Testlauf, sonst bewertet niemand die Treffer.
Mein Anteil
Ich arbeite an der Konzeption und am Customizing dieser drei Blöcke, an der Anbindung der Feeder-Systeme, an Testfällen und Abnahme je Welle sowie an der Schulung der Key-User. Zur Präferenzabwicklung habe ich eine Beraterdokumentation geschrieben — von der Rechtsvorschrift über die Aktivierung am Abkommen bis zu den Nummernkreisen, die man beim ersten Lauf vergisst.
Schildern Sie mir in ein paar Sätzen, wo Sie stehen: welche der drei Blöcke laufen sollen, welche Systeme liefern und ob ein Umstieg ansteht. Im ersten Gespräch sage ich, ob ich der Richtige bin und in welchem Zuschnitt.