30.04.2015

Zah­lungs­be­din­gun­gen – Kei­ne vor­ei­li­gen Schlüs­se zie­hen

Mit diesem Blogpost schließe ich die Serie über Zahlungsbedingungen in SAP® ab. In zwei vergangenen Beiträgen hatte ich beleuchtet, dass Zahlungsbedingungen auf verschiedenen Ebenen bzw. zwischen den verschiedenen SAP® Modulen existieren, und erklärt, was bei Stammdatenvergleichen zu beachten ist.

In diesem Artikel zeige ich, dass man, wenn es um die Analyse von Zahlungsbedingungen geht, „ein Buch nicht nach seinem Einband beurteilen sollte“. Diesmal wenden wir uns nicht den Stammdaten zu, sondern den Zahlungsbedingungen auf Ebene von Einzeltransaktionen.

Im Tagesgeschäft ist es im Rahmen von Audit/Revision, der Buchhaltung oder des Controllings oft interessant, welche Zahlungsbedingungen verwendet werden, und ob Konzernvorgaben eingehalten werden. Die Zahlungsbedingungen haben ja erheblichen Einfluss etwa auf Cash-Flow Berechnungen – wann fließen finanzielle Mittel ab, wann fließen sie wieder zu.

Zahlungsbedingungen beinhalten Fristen und manchmal auch – abhängig von Ländern bzw. Regionen und den dortigen Zahlungsgepflogenheiten – Skonto (Cash Discount, Early-Payment Discount). In den SAP® Modulen sind Zahlungsbedingungen mit einem Kürzel bezeichnet, welches eine bestimmte Ausprägung von Fristen und/oder Skontoprozentsätzen repräsentiert.

Folgende Abbildung zeigt einen Auszug von Zahlungsbedingungen aus einem SAP® IDES System:

 

Zahlungs- bedingung
Tage 1
Skonto 1
Tage 2
Skonto 2
Tage netto
Beschreibung
ZB01143%302%4514 Tage 3%, 30/2%, 45 netto
ZB0700%00%0Sofort fällig ohne Abzug
ZB10103%00%0innerhalb 10 Tagen 3 % Skonto
NT30300%00%0Netto 30

Abbildung 1 – Beispiele für Zahlungsbedingungen aus SAP IDES®

 

Man sieht, dass es verschiedene Möglichkeiten gibt, die Zahlungsbedingungen auszugestalten. Es stehen bis zu drei Felder für die Tage und zwei Skontoprozentsatz-Felder zur Verfügung. Sind alle Tages-Felder mit Nullen gefüllt, so impliziert das „Sofort fällig“ (wie in ZB07). Es gibt zwar auch ein Feld, das mit „Tage netto“ bezeichnet ist – dies kommt aber oft nur dann zum Tragen, wenn die Felder Tage 1 und Tage 2 g und die entsprechenden Skontosätze 1 und 2 ebenfalls erfüllt sind. Die Zahlungskondition „NT30“ steht für „30 Tage netto“, und da nur eine Tagesfrist vorhanden ist, findet sich diese in der ersten Spalte „Tage 1“, und nicht in der letzten „Tage netto“.

Angelegt werden die Zahlungsbedingungen im Customizing von SAP® (SAP® Transaktionscode SPRO). Man sieht in der folgenden Abbildung 2 gut, dass die Zahlungsbedingung bei Neuanlage mit verschiedenen Attributen (Welches Basisdatum, welche Geschäftspartnertypen, etc.) versehen werden können, inklusive einem erklärenden Text.

Abbildung 2 – Sicht beim Anlegen / Pflegen von Zahlungsbedingungen in SAP® Transaktion SPRO

Wie wir in den vorangegangenen Blogposts gesehen haben, sind die Zahlungsbedingungen bei den Debitoren- und Kreditorenstammdaten auf verschiedenen Ebenen gespeichert. Natürlich werden sie im Rahmen der Einzeltransaktionen auch auf Belegebene protokolliert, d.h. sie finden sich in den SAP® FI-Belegen der debitorischen bzw. kreditorischen Nebenbücher. Untenstehender Screenshot in Abbildung 3 zeigt eine Rechnung an einen Debitor mit Zahlungsbedingung ZB01 (welche für 14 Tage 3%, 30 Tage 2%, 45 Tage netto steht).

Abbildung 3 – Debitorenrechnung in SAP® FI-AR mit Zahlungsbedingung ZB01

Wir haben also Zahlungsbedingungen, die als Stammdaten über das Customizing in SAP® hinterlegt werden können. Diese finden dann in den Geschäftsvorfällen (wie zum Beispiel der oben genannten Debitorenrechnung) Anwendung und werden auch entsprechend je Transaktion protokolliert. Soweit – so geradlinig.

Mit unserem Vorwissen können wir nun anfangen, die Zahlungsbedingungen auch auf Belegebene auszuwerten. Gehen wir vom einfachsten Fall aus: Für all unsere Kunden soll Zahlungsbedingung „ZB01“ in Rechnungen angewendet werden. Unsere 146 Beispielrechnungen liegen dabei in der Software ACL™ Analytics vor, welche uns mit vordefinierten Befehlen und ohne Datensatzbeschränkung Datenanalysen verschiedenster Art ermöglicht. (Anmerkung: Die Software gibt es natürlich auch komplett in Deutsch – der Einfachheit halber habe ich für diesen Blogpost nur die bei mir installierte englische Version für die Screenshots verwendet).

Abbildung 4 – Beispielrechnungen

Wir betrachten die drei rot markierten Beispiele. Auch unsere Rechnung von oben ist darunter, sie hat die Nummer 0100000608. Verdichten wir in ACL™ mittels „Klassifizieren“ unsere Rechnungsbelege, sieht auch alles ordentlich aus. Von 146 Rechnungen ist allen Rechnungen die „ZB01“ zugewiesen. Das sieht also ganz gut aus, offensichtlich ist die Anwendung homogen entsprechend der Richtlinie.

Abbildung 5 – Verdichtung der Beispielrechnung nach der Zahlungsbedingung

Doch, und das ist die Kernaussage dieses kurzen Artikels, die Tücke liegt im Detail: Es lassen sich mit der entsprechenden Berechtigung sowohl die Fälligkeitsintervalle bzw. Fälligkeitstage an sich ändern, als auch das Basisdatum für die Fälligkeitsberechnung. Dies zeige ich Ihnen mittels jeweils eines Beispiels.

Genauer gesagt ist es nicht nur möglich, eine andere Zahlungsbedingung als z.B.: ZB01 auszuwählen, sondern auch, einzelne Ausprägungen zu ändern. Beispielsweise kann man, basierend auf dem Eingangsbeispiel, die Zahlungsfrist von 14 / 30 / 45 Tagen auf andere Werte ändern, und somit die Fälligkeit maßgeblich verlängern. Betrachten wir dazu Rechnung „0100002388“– sie ist ebenfalls in unserer Liste oben enthalten, ebenfalls mit Zahlungsbedingung ZB01. Doch wenn wir uns die Details in Abbildung 6 ansehen, stellen wir folgendes fest:

Abbildung 6 – Die Zahlungsbedingung ist mit ZB01 bezeichnet – aber die Werte weichen ab

Trotz der Zahlungsbedingung ZB01 finden andere Fristen und Prozentsätze Anwendung, nämlich 30 Tage 5%, 90 Tage 2,5%, 180 Tage netto! Das wäre übrigens bei unserem ersten Analysebeispiel nicht aufgefallen, da die Bezeichnung immer noch „ZB01“ lautet! Derartige Änderungen können sowohl direkt bei Rechnungserfassung erfolgen, als auch zu einem späteren Zeitpunkt, solange die Rechnung noch als offen im System geführt wird.

Eine zweite Möglichkeit, Zahlungsfristen zu verlängern, ist das Verändern des Zahlungsfristenbasisdatums. Dieses bestimmt, wann die Fristen zu laufen beginnen. Lautet das Zahlungsfristbasisdatum „01.01.2015“ und die Zahlungsfrist beträgt 10 Tage, so ist die Rechnung am 11.01.2015 fällig (01. Januar + 10 Tage). Ändert man dagegen das Zahlungsfristenbasisdatum auf „01.02.2015“, so ist die Rechnung plötzlich am 11. Februar fällig – und das, ohne dass die eigentlichen Fälligkeitstage angepasst wurden.

Abbildung 7 zeigt ein solches Beispiel:

Abbildung 7 – Das Zahlungsfristbasisdatum wurde um einen Monat in die Zukunft verlegt

Es handelt sich ebenfalls um eine Rechnung aus unserer Liste oben. Sie wurde ursprünglich mit Buchungsdatum (und damit Start der Zahlungsfrist per) 31.07.2005 gebucht; Endfälligkeit war der 15.09.2005 (45 Tage später). Dann wurde allerdings das Zahlungsfristbasisdatum auf 31.08.2005 geändert; die Endfälligkeit verschiebt sich somit ebenfalls um einen Monat in die Zukunft, nämlich auf den 15.10.2005. Obwohl also die einzelnen Tage und Prozentsätze unverändert blieben, hat sich die Zahlungsfrist für den Kunden um 30 Tage verlängert.

An diesen zwei Beispielen wird deutlich, dass es sich bei der Analyse von Zahlungsbedingungen lohnt, mehr als einen oberflächlichen Blick zu riskieren. Es könnten mit entsprechenden Berechtigungen Änderungen vorgenommen worden sein, die einen Einfluss auf die Endfälligkeit einer Rechnung haben. Dies kann sowohl bei der Erfassung einer Rechnung bereits erfolgen, als auch nachgelagert im Prozess, wie in meinen Beispielen. Diese Änderungsmöglichkeiten sind der Grund dafür, dass man die Zahlungsbedingungen inhaltlich nicht nur anhand Ihres Kürzels bzw. der Beschreibung beurteilen kann, sondern auch die Ausprägungen der Tages- und Prozentfelder sowie die Änderung des Zahlungsfristbasisdatums betrachten sollte.

Ich würde mich freuen, wenn Sie den Artikel spannend fanden. Gerne unterstützen wir Sie bei Ihren Datenanalysen, mittels unserer Datenextraktionssoftware dab:Exporter, den vordefinierten Analysen in unseren dab:FastForwards oder mittels der Analysesoftware ACL™ und unseren Services. Wenn Sie die Informationen aus unserem Blog verwenden, etwa in Veröffentlichungen, würden wir uns darüber freuen, wenn Sie auf diesen Blog als Quelle verweisen.

Für Fragen oder Kommentare können Sie sich gerne unter info@dab-gmbh.de an uns wenden.

Um den Autor zu kontaktieren, bieten sich auch LinkedIn oder XING an (möglicherweise müssen Sie sich erst einloggen in das entsprechende Social Network, bevor Sie die folgenden Links nutzen können):

LinkedIn: http://de.linkedin.com/pub/stefan-wenig/54/1b8/b30

XING: https://www.xing.com/profile/Stefan_Wenig2?sc_o=mxb_p


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