11.04.2016

Auf der Su­che nach dem (Steuer-) Pa­ra­dies

Eigentlich wäre „Oh wie schön ist Panama“ („The Trip to Panama“) eine bessere Überschrift gewesen, aber da waren die Nachrichtenredaktionen schneller, etwa der Bayerische Rundfunk in seinem Beitrag vom 04. April 2016. Wobei inhaltlich natürlich das Kinderbuch von Janosch über den kleinen Tiger und den kleinen Bären nichts mit der Affäre um die Briefkastenfirmen der Anwaltskanzlei in Panama zu tun hat, aber der Titel einfach gerade so schön griffig ist.

In diesem Blogpost hier verweise ich eingangs kurz auf einen älteren, umfassenden Beitrag, bei dem ein Datenanalyseansatz mit der konkreten Fragestellung „Ermittlung von Zahlungen / Geschäftspartnern in kritischen Ländern“ als Beispiel zu Grunde liegt. Der Hauptteil des heutigen Beitrags ist allerdings das Aufzeigen einiger Spezifika, die es zu beachten gilt, wenn man es mit Daten aus SAP® zu tun hat. Die gewählten Beispiele sind dabei fiktiv (und – zugegeben - auch plakativ), sie basieren auf einem SAP® IDES System in der Version SAP® mySAP ERP2005 ECC 6.0 (unicode).

Steueroasen bzw. Zahlungen oder Geschäftspartner in solchen Ländern ausfindig zu machen ist also wie angedeutet kein neues Thema, sondern sollte eigentlich zu den Standardanalysen bei der revisorischen Betrachtung von Unternehmensdaten zählen, bzw. je nach Rollenteilung auch aus Compliance-Sicht regelmäßig und automatisiert betrieben werden. Man kann es auch kurz und knackig mit KYP umschreiben, nicht „Keep you posted“, sondern „Know Your Partners“. Mögen Beweggründe oder das Interesse, derartige Sachverhalte zu ermitteln, im aktuellen Fall auch leicht anders gelagert sein, so gibt es aus unserer Sicht doch eine Schnittmenge zur revisorischen oder compliance-getriebenen Fragestellungen hinsichtlich des Themas.

Die Analyse „Geschäftspartner in kritischen Ländern“ im Kontext von Steueroasen war übrigens in der Vergangenheit bereits eines der zentralen Beispiele, welches in unserer Serie „CCM - 5 Dinge, die Sie wissen sollten - und 2 Dinge, die Sie besser nicht vergessen“ verwendet wurde. Dort geht es darum, wie man strukturiert solche Datenanalysen in Form automatisierter bzw. kontinuierlicher Auswertungen (Continuous Controls Monitoring / Continuous Auditing) etablieren kann. Die dafür genannten notwendigen Arbeitsschritte beginnen bei der Definition der Fragestellung und Identifikation der notwendigen Datenquelle(n), erstrecken sich über die Erarbeitung der relevanten Datenstrukturen, Verstehen der technischen Möglichkeiten und Beschränkungen bis hin zum Maßschneidern der Ergebnisse auf den jeweiligen Empfänger. Wenn Sie sich also für die grundsätzliche Methodik und Projektmeilensteine interessieren, werfen Sie doch noch einen Blick in diese Artikelreihe.

Heute dagegen werde ich anhand konkreter Beispiele aufzeigen, dass derart einfache Analysen nicht immer die bekannten „quick wins“ / „low hanging fruits“ sind, sondern man oft tiefer schürfen muss, um sogar eine relativ einfache Fragestellungeng möglichst erschöpfend zu behandeln.

Dazu behandle ich folgende Punkte:

  1. Der Firmensitz als Teil der globalen Stammdaten in SAP® Tabellen
  2. Die Rolle des Banklandes im Vergleich zum Sitzland
  3. Intransparenz bei manuell durchgeführten Zahlungen
  4. Das Risiko von CpD-Stammsätzen
  5. Die Bedeutung von Partnerrollen
  6. Zeitpunktbetrachtung von Stammdaten im Vergleich zur Historie

Beginnen wir mit dem Sitzland des Geschäftspartners:

1. Fir­men­sitz als Teil der glo­ba­len Stamm­da­ten in SAP®

Natürlich ist der Geschäftspartner i.d.R. als Stammsatz im System angelegt, also mit Name, Adresse, Kontaktdaten, Steuernummer und sonstigen relevanten Details gespeichert. Dies betrifft übrigens nicht nur Partner im Sinne von Debitoren und Kreditoren, sondern auch verbundene Unternehmen. Letztere sind i.d.R. separat über das Kennzeichen „Partnergesellschaft“ identifizierbar, und/oder über eigene Kontengruppen oder ein entsprechendes Abstimmkonto. Zu den Adressdetails des Stammsatzes gehört entsprechend auch das Land des Partners bzw. verbundenen Unternehmens.

Werfen wir einen Blick auf einen typischen Lieferantenstammsatz in unserem SAP® IDES System. Es ist die Sicht auf den Stammsatz des Lieferanten mit der Nummer 1700, die SAP® Transaktion ist XK03 (Zentrale Anzeige der Kreditorenstammdaten).

Abb. 1 - Lieferant 1700 – Sitzland Panama

Gespeichert sind die meisten der hier im Screenshot sichtbaren Adressinformationen in der Tabelle LFA1 für Lieferanten bzw. KNA1 für Kunden. Der Feldname für das Länderattribut lautet in beiden Fällen „LAND1“, und das häufig zur Differenzierung von zum Konzern gehörigen Unternehmen verwendete Feld „VBUND“. (Letzteres ist in obigem Fall nicht gefüllt, es handelt sich also vermutlich um einen Lieferanten, der nicht zum Konzernverbund gehört.)

„Problem gelöst“, könnte man meinen – alles was man tun muss ist, die Länder der Geschäftspartner mit einer Liste kritischer Länder zu vergleichen, Treffer auszugeben und nachzuverfolgen, und ggf. noch eine Trennung nach Verbundunternehmen und „Third Parties“ vornehmen. Doch wenn man sich intensiver mit dem Thema beschäftigt, trifft man noch auf weitere Aspekte, die in dem Kontext wichtig sind:

2. Bank­land vs. Sitz­land

Es ist eine Sache, in welchem Land der Kreditor oder Debitor seinen Sitz hat, aber möglicherweise spielt auch eine Rolle, in welchem Land (bzw. in welchen Ländern) der Geschäftspartner bzw. das verbundene Unternehmen Bankverbindungen unterhält. Das Bankland für Kunden und Lieferanten ist in SAP® Datenstrukturen unter anderem in den Tabellen LFBK (Bankverbindungen Kreditoren) und KNBK (Bankverbindungen Debitoren) verortet. Analysiert man nur die Länder im globalen Lieferanten- bzw. Kundenstamm wie im Beispiel des Firmensitzes erklärt, würde man diesen Aspekt nicht berücksichtigen. Die Bankverbindung lässt sich im Übrigen häufiger im Kontext von Lieferanten analysieren, gerade wenn der übliche Zahlweg „Überweisung“ lautet, denn ohne bekanntes Bankkonto kann auch – zumindest über den automatischen Zahllauf - keine Überweisung vorgenommen werden. Kundenbankverbindungen dagegen sind häufig etwas lückenhafter gepflegt, sofern sie nicht gerade für Lastschriftabbuchungsverfahren benötigt werden. Wenn der Debitor per Überweisung bezahlen kann, man also selber auf den Geldeingang wartet ohne aktiv tätig zu werden, dann benötigt man als Unternehmen die Bankverbindung des Kunden erst einmal nicht.

Werfen wir also erneut mit XK03 einen Blick auf einen Lieferanten, in diesem Falle Kreditor Nr. 3000 in unserem SAP® System. Das Sitzland ist „US“, soweit also alles im Lot.

Abb. 2 - Lieferant 3000 – Sitzland US

Doch betrachtet man die für diesen Kreditor angelegten Bankverbindungen näher, indem man durch die verschiedenen Sichten der Lieferantenstammdaten blättert, so sieht man nach wenigen Klicks, dass für den Lieferant Nr. 3000 zwei Bankverbindungen im System existieren, eine mit Bankland USA, und eine weitere mit dem Kürzel VI für die Amerikanischen Jungfraueninseln.

Abb. 3 - Zwei verschiedene Bankverbindungen für Lieferant 3000

Hier wird also deutlich, dass die Betrachtung des Banklandes durchaus von Interesse sein kann. (Übrigens ist im Zuge der IBAN Umstellung auch ganz interessant, wie in SAP® aus Datensicht der Zusammenhang zwischen diesen Bankverbindungen der „alten Welt“ und der neuen IBAN-Systematik gemacht wird; das Thema ist aber einen separaten Blogpost wert; für unsere Zwecke reichen LFBK / KNBK erst einmal aus).

3. In­trans­pa­renz bei ma­nu­el­len Zah­lung­en

Eine klassische Fragestellung in der Revision ist die Suche nach manuellen Zahlungen. Wieso aber sind diese überhaupt als kritisch anzusehen? Dies wird im Kontext der Länderanalysen deutlich: Ein wichtiger Aspekt der Risikominimierung ist es, den Zahlungsprozess so stabil und automatisiert wie möglich zu gestalten. Das heißt, im Idealfall wird eine Bestellung zu einem Lieferanten aufgegeben, dieser liefert und stellt eine Rechnung. Die Rechnung wird für seine Lieferantennummer eingebucht, und die auf der Rechnung vorhandene Bankverbindung ist identisch mit der in den Stammdaten hinterlegten und wird automatisiert herangezogen. Das Zahlprogramm (in unserem Falle der SAP® Zahllauf via Transaktion F110) terminiert die Zahlung anhand des laut Zahlungsbedingung (Fristen, Skonto) optimalen Zeitpunktes und erstellt die Zahlliste, die automatisiert und ohne weitere Manipulationsmöglichkeit an die Bank weitergeleitet wird.

Soweit zum Idealfall. Doch wenn eine Zahlung außerhalb des Systems vorgenommen wird, ist auch keine im SAP® System hinterlegte Bankverbindung nötig; es könnten also manuell Zahlungen an Partner (oder anders formuliert, in Länder) vorgenommen werden, die nicht im Zusammenhang mit der Zielbankverbindung in den Stammdatentabellen zu finden sind. Eine Lösung wäre die Analyse der elektronischen Kontoauszüge, sofern die entsprechende SAP® Funktionalität genutzt wird. Oft finden hier auch Third-Party-Lösungen Verwendung, die man in die Betrachtung mit einbeziehen sollte. Fazit dieses Punktes ist, dass nur bei Betrachtung der Bankkontobewegungen außerhalb des Finanzbuchhaltungssystems, also auf Ebene der Kontoauszüge, man sich sicher sein kann, auch manuelle Zahlvorgänge berücksichtigt zu haben.

4. Das Ri­si­ko von CpD – Stamm­sätz­en (Con­to pro di­ver­se)

Über CpD haben wir an verschiedener Steller schon im Blog berichtet. Kurzgefasst kann das Risiko darin liegen, dass kein explizit für diesen Geschäftspartner angelegter Stammsatz verwendet und damit nicht die in den Stammdatentabellen vorhandenen Informationen wie eben die Bankverbindung genutzt werden. Beim Erfassen von Rechnungen, die unter einem CpD-Lieferanten gebucht werden, kann die Bankverbindung sogar ad-hoc erfasst werden. Auch in diesem Falle sind die Empfängerländer bzw. Empfängerbankverbindungen nicht in den Stammdatentabellen LFBK und KNBK zu finden. Grund ist, dass es für CpD-Stammsätze (z.B. „Sammellieferanten A-K“) i.d.R. nur einen allgemeinen Teil gibt, sie aber nicht mit einer konkreten Bankverbindung versehen sind, da diese ja je nach gebuchtem Beleg unterschiedlich sein kann. Doch es gibt eine gute Nachricht für Datenanalysten, zumindest für den Fall, dass der SAP® Zahllauf genutzt wurde, um die Zahlungen vorzunehmen, und keine manuelle Zahlung: In der Zahllauftabelle REGUH werden für jeden Zahllauf die Empfängerbankverbindung und damit auch das Empfängerland protokolliert. Folgender Screenshot zeigt nicht die Tabellensicht, sondern die Transaktion F110 unter Ansicht einer konkreten Zahllauf-Zahlung.

Abb. 4 - Detailansicht einer CpD-Zahlung mittels automatischen Zahllauf (Tabelle REGUH)

Es wurde zwar ein CpD-Lieferant „One time vendor“ verwendet, und somit ist die Empfängerbankverbindung nicht in der Tabelle LFBK auffindbar. In den Zahlungsdetails des Zahllaufes ist die tatsächlich genutzt Bankverbindung inklusive Bankland („JP“) sichtbar.

5. Part­ner­rol­len

Der nächste Aspekt, den ich hier anführen möchte, sind Partnerrollen. Diese werden in SAP® häufig benutzt, um komplexe Geschäftsbeziehungen abzubilden. Im einfachsten Fall hat man für Lieferanten gesprochen folgendes Szenario: Die Anfrage geht an Lieferant 1000, dieser erstellt ein Angebot, erhält unsere Bestellung, schickt die Rechnung an uns und erhält die Zahlung. Oder, für Kunden gesprochen: Kunde Nummer 2000 bestellt bei uns, wir liefern auch an Kunde 2000, schicken die Rechnung dorthin, erhalten vielleicht von dort eine Retoure und erteilen ihm dafür eine Gutschrift. Alle genannten Vorgänge sind unter jeweils derselben Partnernummer zu finden. Nun gibt es hier aber auch andere Konstrukte, die sich vielleicht sogar innerhalb verschiedener Vertriebsbelege für den selben Kunden unterscheiden können: Die Bestellung kommt zwar von Kunde 2000 in Land A, die Lieferung erfolgt aber an Kunde 3000 in Land B und die Rechnungsstellung an Kunde 4000 in Land C – selbstredend können diese also wiederum ihren Sitz und ihre Bankverbindung(en) in verschiedenen Ländern haben. Die gute Nachricht ist, dass Stammsätze, die in Partnerrollen verwendet werden, sich auch in den normalen Stammsatztabellen LFA1 und KNA1 finden und mit der entsprechenden Partnernummer ausfindig gemacht werden können.

Abb. 5 - Partnerrollen für Kunde 1000 – Zahlungsempfänger 1050

Wenn wir diesen näher betrachten stellen wir fest, dass Zahlungsempfänger 1050 seinen Sitz in einem kritischen Land hat:

Abb. 6 - Sitzland Zahlungsempfänger 1050

Wichtig ist aber, wenn man die Analyse kritischer Länder ausgehend von den Geschäftsvorfällen (z.B. Vertriebsbelegen im SAP® SD Modul) beginnt, dass man das Vorhandensein von Partnerrollen auf Ebene des Vertriebsbeleges berücksichtigt. Zu finden sind die Partnerrollen auf Belegebene in der SAP® Tabelle VBPA.

6. Än­de­run­gen im Zeit­ver­lauf

Abschließend möchte ich noch dafür sensibilisieren, dass es sich bei den meisten Stammdatenbetrachtungen um den Ist-Zustand handelt, also den Zustand zum Zeitpunkt des Datenexportes bzw. der Betrachtung im Quellsystem. Doch Adressdaten und Bankverbindungen können natürlich im Zeitverlauf geändert worden sein. Um auch historisch gesehen eine gewisse Sicherheit für seine Datenanalysen zu erzielen ist es hilfreich, einen Blick auf die SAP® Änderungstabellen zu werfen, in denen die Protokollierung inklusive den Attributen „alter Wert“, „neuer Wert“ sowie dem entsprechenden Zeitstempel stattfindet. Ansatzpunkt dafür sind etwa die schon öfter hier im Blog erwähnten Tabellen CDHDR und CDPOS, zu denen Sie im Downloadbereich ein Whitepaper finden. Die Änderungsklassen hier wären KRED für die Kreditoren sowie DEBI für Änderungen an den Debitorenstammdaten.

Ich hoffe, ich konnte Ihnen einen kleinen Einblick geben, welche Punkte beachtenswert sein können, wenn Sie sich – vielleicht aus aktuellem Anlass wie den Panama Papers– für die Analyse von Geschäftsbeziehungen zu Partnern in kritischen Länder oder Steueroasen interessieren.

Auch wenn die Beispiele anhand von SAP® Screenshots verdeutlicht wurden, machen solche Analysen natürlich eher Sinn auf Ebene der Grundgesamtheit der Daten. Dabei unterstützen wir Sie gerne direkt in diesem Zusammenhang, etwa mit unserer Datenextraktionsoftware dab:Exporter, mit deren Hilfe Sie die oben genannten Tabellen einfach extrahieren können, da einige der genannten Tabellen sehr groß sein können. Relevant für Sie sind möglicherweise auch die Analysesoftware ACL™ für das manuelle Durchführen der Analysen oder unseren vordefinierten Auswertungen dab:AnalyticSuite, in denen wir diese Ländervergleiche bereits auf Knopfdruck in Form von Standardreports abgebildet haben. Wenden Sie sich dafür gerne jederzeit bei Fragen an uns!


Kommentare (0)
Sei der erste, der diesen Blog-Beitrag kommentiert.
Blog Anmeldung

Sie sind nicht angemeldet. Bitte melden Sie sich an um diesen Blogbeitrag zu kommentieren.

anmelden