Unser Ziel ist es, Sie auf die Tücken und Fallstricke im Zahlungsverkehr hinzuweisen. Es muss nicht immer Betrug sein. Schaden entsteht auch durch Unachtsamkeit, oder weil organisatorische und technische Möglichkeiten nicht genutzt werden, und manchmal einfach aus Dummheit. Die Beiträge sind bewusst gewählt. Wenn Sie aufgrund dieser Artikel hinterfragen, wie denn die Abläufe in ihrem Unternehmen sind und ob dort ein ähnliches Schadensereignis eintreten könnte, dann haben wir unser Ziel erreicht. Die beschriebenen Abwehrmaßnahmen zur Verhinderung sind sicher nicht vollständig und schon gar nicht allumfassend. Sie werden damit aber schon sehr weit kommen!
Die Fälschung von Überweisungsformularen der Bank ist oldschool. Davon betroffen sind meistens Privatpersonen. Der Betrüger wirft die Überweisung in den Briefkasten der Bank ein und einige Tage später landet das Geld auf seinem eigenen Konto. Das klappt auch dann, wenn der Betrüger mit Hans Dampf unterschrieben hat. Aufgrund der Masse an Überweisungen prüft die Bank in den meisten Fällen die Unterschrift gar nicht. Für Sie wäre der Namenszug Hans Dampf im Unterschriftsfeld sogar ein Segen (es sei denn, Sie heißen tatsächlich so!). Dann muss die Bank für die Abzocke geradestehen. Macht ein Betrüger ihre Unterschrift aber nach und ist somit der Betrug nicht ohne weiteres zu erkennen, haben sie Pech gehabt. Die Kohle ist weg und die Bank ist aus dem Schneider. Siehe Urteil des Landgerichtes Dessau. Auch Unternehmen sind davon betroffen. So z.B. geschehen bei einem niedersächsischen Hersteller von Spielwaren. Bei deren Hausbank in Manila ging eine Überweisung ein, unterzeichnet vom „unterschriftsberechtigten“ örtlichen Geschäftsführer des Unternehmens. Schaden: 218.000 USD.
Ein Energieversorger bestellt bei einem Zulieferer nach einer längeren Pause Ware und erhält dafür die Faktura. Die Stammdaten im ERP-System sind ordentlich gepflegt und unverändert. Alles schick. Der Rechnungsbetrag (> 30.000 Euro) wird auf das bekannte Girokonto überwiesen. Allein der Lieferant hatte in der Zwischenzeit sein Konto gekündigt und war zu einer anderen Bank gewechselt. Die neue Bankverbindung stand auch auf der Rechnung, was aber bei der Eingangsverarbeitung übersehen wurde. Es kommt, wie es kommen muss. Die Bank hatte die IBAN einem anderen Kunden gegeben; ein üblicher Vorgang. Damit läuft die Überweisung nicht ins Leere, sondern das Geld wird korrekt auf dem angegebenen Konto gutgeschrieben. Einzig der Name des Empfängers stimmte nicht mit dem auf der Überweisung angegebenen überein. Pech gehabt: Seit SEPA ist die Bank nicht mehr verpflichtet, die Übereinstimmung von Konto und Name zu prüfen. Klar ist, dass der Empfänger das Geld zurückzahlen muss. Das ist aber auch nicht immer so einfach wie es sich zunächst anhört. Im vorliegenden Fall ist der neue Kontoinhaber ein kleines Unternehmen mit Hauptsitz in England. Er kann glaubhaft machen, dass er einen Zahlungseingang in etwa der gleichen Höhe erwartet hatte. Das Geld ist inzwischen ausgegeben und ja, er erstattet den Betrag zurück sobald ihm das möglich ist! Das war vor circa 2 Jahren!
Davor schützt Technik. Viele Unternehmen setzen in der Zwischenzeit auf das Scannen von Rechnungen! Eine Software liest anschließend die auf dem PDF angegebenen Informationen. Das Programm vergleicht die Angaben der Rechnungen mit den im ERP-System geführten Stammdaten. Bei Abweichungen, oder werden Stammdaten gar nicht erkannt, wird ein Protokoll erstellt. Die Buchhalter überprüfen die gemeldeten Fälle manuell.
Ein Unternehmen betreibt neben dem Onlinehandel auch Filialgeschäfte. Die Kunden bezahlen die durchweg hochpreisigen Produkte zumeist mit Karte. Im Reklamationsfall ist man sehr kulant. Wird Ware zurückgegeben, gibt es zwar kein Bargeld für den Kunden, aber für die Erstattung reicht ein Vordruck mit Angabe von Name, Kontoverbindung und Unterschrift. Der Vordruck wird vom Filialleiter abgezeichnet und an die Unternehmenszentrale geschickt, von wo aus dann der Erstattungsbetrag angewiesen wird. Woher die Betrüger ihr Insiderwissen haben und ob es im Unternehmen Komplizen gibt, ist bislang nicht geklärt. Tatsächlich können sie über einen Zeitraum immer wieder gefälschte Anträge einschleusen. Die Unstimmigkeiten fallen erst auf, als bei einigen Filialen im Rahmen einer Revision Warenbestände und Umsätze abgeglichen werden. Schaden bis dahin: > 120.000 Euro.
Es stellt sich natürlich die Frage, warum das erst so spät aufgefallen ist. Das liegt in der Natur der Sache. Erstattungen werden nur unbar geleistet. Da es sich bei den Kunden um Laufkunden handelt, gibt es im ERP-System aber keine Stammdaten. Erstattungen können daher nicht als Gutschriften auf die Kundenkonten gebucht werden. Stattdessen werden Zahlungsanordnungen gebucht, oder Zahlungen als so genannte Ad-hoc-Zahlungen erfasst. Bei denen greifen aber die bisher geschilderten Sicherheitsmaßnahmen nicht!
Zahlungsanordnungen – oder auch Ad-hoc-Zahlungen – sind in Unternehmen Tagesgeschäft. Sie werden genutzt, wenn eine Zahlung ausgeführt werden soll, zu der es im ERP-System keinen OP gibt und/oder wenn der Zahlungsempfänger nicht als Geschäftspartner angelegt ist und/oder wenn von einer bestehenden Verbindlichkeit gegenüber dem Geschäftspartner nur ein Teil beglichen werden soll. Es gibt zwei Möglichkeiten der Erfassung:
- Die Anordnung wird im ERP-System erfasst. SAP stellt hierfür verschiedene Transaktionen bereit. Je nach Auswahl wird die Anordnung als Zahlposten auf ein Geschäftspartnerkonto oder auf ein Sachkonto gebucht. Anschließend wird ein Zahlungslauf für Anordnungen (Transaktion F111) ausgeführt. Die erstellte Datei wird zur Bank übertragen und die Posten werden reguliert. Die Erfassung der Personendaten (Name, Adresse, Bankverbindung etc.) und der eigentlichen Vorgangsdaten (Zahlbetrag, Verwendungszweck etc.) sind personell nicht getrennt. Die komplette Erfassung liegt in einer Hand. Die Tür zur Manipulation ist damit schon mal nicht mehr abgeschlossen. Der Folgeprozess ist mit dem sonst üblichen Verfahren identisch. Das bedeutet, dass ein oder mehrere Personen die Sachverhalte im ERP-System prüfen. Das muss man dann aber auch tun – und zwar immer! Eine stichprobenweise Kontrolle reicht nicht aus.
- Die Ad-hoc-Zahlung wird direkt in der BCM erfasst (ähnlich einer Überweisung beim Homebanking). Der Zahlungsauftrag wird mit den notwendigen Unterschriften ergänzt und zur Ausführung an die Bank gesendet. Auch bei diesem Verfahren ist die Erfassung der Personen- und Vorgangsdaten personell nicht getrennt. Die komplette Erfassung liegt bei einem Mitarbeiter. Hinzu kommt, dass derjenige, der die Eingaben macht (also der die BCM-Software bedienen darf) meistens auch unterschriftsberechtigt ist. Mitarbeiter A erfasst eine Zahlung über Betrag B an Geschäftspartner C auf dessen Konto D und bestätigt mit seiner Signatur auch noch die Richtigkeit gegenüber der Bank. Ist mit der Bank vereinbart, dass zwei Unterschriften notwendig sind, kommt dann wenigstens noch eine Person, die eventuelle Fehler oder Missbräuche entdecken könnte; bei Einzelunterschrift ist das Geld gleich weg! Diese vom Standard so extrem abweichenden Vorgänge sollten genauestens geprüft werden, aber die Kontrolle an sich gestaltet sich schwierig. Im ERP-System gibt es keinen Bezug zu der in der BCM getätigten Überweisung. Der Bezug wird erst hergestellt, wenn der Umsatz auf dem Kontoauszug steht und dieser im ERP-System gebucht wird. Angenommen, der Zweit-Unterzeichner soll/möchte tatsächlich kontrollieren, dann benötigt er dazu den Ursprungsbeleg (z.B. den Erstattungsantrag eines Kunden); entweder über das Archiv, oder im Original. Er muss alle Personen- und Vorgangsdaten prüfen. Das geht ja noch an, die kann er ja im Dokument ablesen. Er muss aber auch einschätzen können, ob die Erstattung sachlich richtig ist. Wurde das Dokument von einer berechtigten Person vor Ort gegengezeichnet. Ist das Dokument auf dem regulären Weg (z.B. gescannt und als Mailanhang) von der Filiale zur Zentrale gelangt etc. Das sind alles Dinge, von denen ein typischer zeichnungsberechtigter Treasurer oder Cash Manager keinen Plan hat. Das gehört ja auch nicht zu seinen originären Aufgaben. Wie also soll er prüfen?
Ein Paradigmenwechsel kann hier helfen. Anstatt zu überlegen, mittels welcher Prüfmechanismen man die Gefahr von Unregelmäßigkeiten verhindern kann, sollte man fragen, warum denn überhaupt Online-Zahlungen direkt in der BCM erfasst werden müssen? Gibt es dafür triftige Gründe? Die richtige Antwort lautet: Nein. Man kann die Erfassung im ERP-System vornehmen (siehe oben). Dazu bedarf es nur weniger Schritte: Customizing des Systems + Vergeben der Berechtigungen für die Buchhalter + Erklärung für die Buchhalter + Festlegung der Prozesse.
Und wenn wir schon dabei sind und Sie sich vielleicht sagen: Ja, aber das muss ja auch alles erst umgesetzt werden, und da ist dann die IT, die eh schon wenig Zeit hat, und dann sind da die Mitarbeiter, die von den Transaktionen noch keinen Plan haben, und dann müssen wir die Prozesse umschmeißen, und … Buchen Sie stattdessen den Vorgang als Rechnung auf den CPD-Kreditor, da gehört er ja eigentlich auch hin. Verknüpfen sie das Original-Dokument mit dem Buchungsbeleg. Führen sie anschließend den Vorschlagslauf aus, lassen Sie diesen prüfen, machen sie den Zahlungslauf usw. Das ist alles Standard!
Und noch ein Vorteil: Den CPD-Kreditor und die verwendeten Girokontonummern kann man auswerten und damit Häufungen feststellen!
Es dürfte auch einigermaßen schwierig sein, einem Revisor gegenüber zu belegen, dass geprüft wird/wurde. Es gibt ja auch kein Protokoll darüber. Von Aussagen wie „Ja, wir prüfen immer, der Herr X hat’s versprochen!“, sind diese Leute nicht zu überzeugen. Das alles betrachtet, steht die Manipulationstür sperrangelweit offen. Das ist nicht kritisch. Das ist auch nicht bedenklich. Das ist grob fahrlässig!
