Mobile Money und ERP: mobile Zahlungen im Kernsystem verankern.

Das Muster wiederholt sich. Ein Handelsunternehmen vereinnahmt einen wachsenden Teil seiner Umsätze über mobile Zahlungen. Jede Woche lädt jemand aus der Buchhaltung die Auszüge jeder Wallet herunter, stimmt sie von Hand mit den offenen Rechnungen ab und bucht anschließend die Summe. Differenzen wandern auf Interimskonten. Die Gebühren des Anbieters werden geschätzt. Der Saldo der Wallet taucht in der Zwischenbilanz nirgends auf. Beim Abschluss werden diese Interimskonten dann zum ersten Gesprächsthema mit der Abschlussprüfung.

Marktrealität, kein Innovationsprojekt

Zunächst braucht es einen anderen Blick. Die mobile Zahlung ist kein Experimentierkanal, den man in einem eigenen Projekt behandelt. Sie ist ein Zahlungsmittel wie Überweisung, Scheck oder Bargeld und gehört mit derselben Sorgfalt ins Kernsystem: ein Geldkonto je Wallet, ein Journal, Belege, eine regelmäßige Abstimmung. Solange das ERP sie nicht sieht, steuert das Unternehmen seine Liquidität auf einem unvollständigen Bild.

Die zu integrierenden Ströme

Zahlungseingänge von Kunden. Die Kundin bezahlt eine Rechnung, eine Anzahlung oder einen Barkauf vom Telefon aus. Das ERP muss die Transaktion mit ihrer Referenz erhalten, sie der Rechnung oder dem Kunden zuordnen, das Konto ausgleichen und die Gebühren erfassen. Der heikle Punkt ist die Identifikation: Eine mobile Zahlung kommt mit einer Telefonnummer und einem Betrag an, selten mit einer Rechnungsnummer. Das Projekt muss deshalb die Zahlungsreferenz gestalten, sie den Kunden mitteilen und beim Eingang auslesen. Andernfalls bleibt der Ausgleich Handarbeit.

Zahlungen an Lieferanten und Mitarbeitende. In der Gegenrichtung bezahlt das Unternehmen Lieferanten, Transporteure, Tagelöhner oder Mitarbeitende per mobiler Zahlung, oft als Massenlauf. Das ERP muss den Zahlungsauftrag aus den freigegebenen Rechnungen oder der Lohnabrechnung erzeugen, ihn übermitteln, Bestätigung oder Ablehnung entgegennehmen und alles Zeile für Zeile verbuchen. Hier geht es nicht mehr um Identifikation, sondern um Kontrolle: Wer gibt die Liste frei, wer übermittelt sie, und wie wird eine Ablehnung behandelt.

Abstimmung und Verbuchung nach SYSCOHADA

Eine Mobile-Money-Wallet ist ein Geldkonto. Sie wird geführt und abgestimmt wie ein Bankkonto. Die Abstimmung stellt den Auszug des Anbieters den ERP-Buchungen Transaktion für Transaktion gegenüber und isoliert die Differenzen: nicht identifizierte Eingänge, nicht bestätigte Ausgänge, Gebühren, Stornos. Im überarbeiteten SYSCOHADA finden diese Vorgänge ihren Platz in den passenden Geld- und Aufwandskonten, mit einem Beleg je Transaktion statt einer Sammelbuchung. Was sich mit einer echten Integration ändert: Der Auszug ist keine heruntergeladene Datei mehr, sondern ein vom System empfangener Datenstrom, und die Abstimmung wird zur Ausnahmebearbeitung statt zur Wochenaufgabe.

Diese Disziplin wirkt sich unmittelbar auf den Abschluss aus. Wenn jede mobile Zahlung transaktionsgenau verbucht, ausgeglichen und abgestimmt wird, leeren sich die Interimskonten, und die Liquidität der Bilanz zeigt das tatsächlich verfügbare Geld, Wallets eingeschlossen. Wir sprechen darüber in unserem Standpunkt zum SYSCOHADA-Abschluss: Ein Interimskonto, das jeden Monat wächst, ist ein Strom, den das System nicht zu behandeln weiß.

Eine mobile Wallet ist ein Geldkonto. Solange das ERP sie nicht sieht, steuert das Unternehmen sein Geld auf einem unvollständigen Bild.

Über API integrieren, nicht über Dateien

Die Anbieter mobiler Zahlungen stellen Schnittstellen bereit, mit denen sich eine Zahlung auslösen, deren Benachrichtigung empfangen und ein Saldo oder ein Verlauf abfragen lässt. Auf diesen Schnittstellen baut eine dauerhafte Integration auf, nicht auf heruntergeladenen Exporten. Die Architektur hängt vom Kernsystem ab. Mit SAP S/4HANA läuft die Integration über SAP BTP, das die Konnektoren, die Nachrichtentransformation und die Überwachung trägt und den Kern frei von Eigenentwicklungen hält. Wenn das Unternehmen zusätzlich Salesforce einsetzt, übernimmt MuleSoft diese Rolle als gemeinsame Integrationsschicht zwischen CRM, ERP und Anbietern. Für Odoo existieren Konnektoren für die wichtigsten Anbieter der Region; sie sind vor der Auswahl auf Pflege und Abdeckung zu prüfen.

Unabhängig von der Plattform gelten drei Regeln. Eine vom Kern getrennte Integrationsschicht, um Schnittstellenänderungen der Anbieter aufzufangen, ohne das ERP anzufassen. Eine Überwachung der Ströme, um eine blockierte Zahlung zu sehen, bevor die Kundin reklamiert. Und eine von Anfang an durchdachte Fehlerbehandlung: Zeitüberschreitung, Ablehnung, Dublette, Erstattung.

Interne Kontrolle und Betrug

Die mobile Zahlung ist schnell und unwiderruflich. Das ist ihre kommerzielle Stärke und ihr Kontrollrisiko. Die Betrugsmuster, die wir sehen, sind einfach: eine im Lieferantenstamm geänderte Empfängernummer, eine doppelte Lohnzahlung, ein auf eine private Wallet umgeleiteter Zahlungseingang, eine fiktive Erstattung. Keines verlangt technische Kenntnisse. Alle nutzen eine fehlende Funktionstrennung oder Nachvollziehbarkeit aus.

Genau die Integration ins ERP erlaubt die Antwort darauf. Empfängernummern werden zu Stammdaten mit Vier-Augen-Freigabe bei jeder Änderung. Massenzahlungen durchlaufen einen Freigabeweg mit Grenzen je Person und Tag. Jede Transaktion trägt ihren Urheber, ihr Datum und ihren Beleg. Die Wallets werden von jemandem abgestimmt, der sie nicht bedient. Und die Warnungen, ungewöhnlicher Betrag, neuer Empfänger, Zahlung außerhalb der Geschäftszeiten, kommen aus dem System statt von individueller Wachsamkeit. Unser Angebot IT-Sicherheit & Risiken behandelt diese Kontrollen als Teil des Integrationsprojekts, nicht als nachträgliche Prüfung.

Personenbezogene Daten

Eine mit einer Zahlung verknüpfte Telefonnummer ist ein personenbezogenes Datum. Mobile Zahlungsströme, eingehend wie ausgehend, sind eine Verarbeitung im Sinne des Gesetzes Nr. 2008-12, bei der CDP nach den geltenden Formalitäten anzuzeigen, mit Zweck, Aufbewahrungsdauer und Zugriffsregeln. Die für die Kontrolle nützlichen Transaktionsprotokolle sind ebenso zu schützen wie die Lohndaten. Wir vertiefen diese Frage in unserem Standpunkt zur CDP-Konformität ab der Rahmensetzung.

Was wir empfehlen

• Die mobile Zahlung als Zahlungsmittel des Kernsystems behandeln, mit einem Geldkonto je Wallet und einem Beleg je Transaktion.
• Die Zahlungsreferenz vor der Integration gestalten: Sie macht den Ausgleich automatisch.
• Über API integrieren, durch eine eigene Schicht: SAP BTP, MuleSoft oder Odoo-Konnektoren, nie als Direktentwicklung im Kern.
• Täglich abstimmen, nach Ausnahmen, und kein Interimskonto über den Monat hinaus leben lassen.
• Funktionstrennung einführen bei Empfängern, Freigaben und Abstimmungen, mit Warnungen aus dem System.
• Die Verarbeitung anzeigen und Zahlungsdaten wie sensible Daten schützen.

Die mobile Zahlung steckt bereits in Ihrem Umsatz. Die einzige Frage ist, ob sie auch in Ihrem System steckt oder in einer Tabelle lebt, zwischen tatsächlicher und buchhalterischer Liquidität. Es ist ein kurzes Vorhaben an der Schnittstelle unserer Kompetenz Finanzen und unserer Arbeiten zu Integration und API, und eines von denen, deren Wirkung schon beim nächsten Abschluss sichtbar wird.