Eine Initiative – Digitalisierter Zahlungsverkehr mit Anbindung an die Buchhaltung

Zielsetzung – Grundgedanke

Die Anforderungen für die Buchhaltung in einem Verein sind im Prinzip denkbar einfach – eine einfache, geordnete Einnahmen-/Ausgaben-Buchhaltung deckt i.d.R. die Erfordernisse ab.

Gleichzeitig sind aber viele Vereine sehr dezentral organisiert und der administrative Bereich eines Vereins läuft nicht so ab, wie man es vielleicht in einem KMU gewohnt wäre. Es gibt z.B. keinen „normalen“ Bürobetrieb, wo alle Verantwortlichen jederzeit verfügbar sind und somit lokal kommunizieren könnten. Aber dennoch gelten natürlich auch für einen Verein die Grundsätze der GoDB – also Übersichtlichkeit, Ordnung, Nachvollziehbarkeit, usw. usw.

Im Nachfolgenden ist mal in der Übersicht ein System definiert, welches den vorstehend genannten Forderungen entspricht und gleichzeitig den Schritt in die digitale Welt geht. In dem nachstehenden Beispiel gibt es eine Kombination von fertigen Komponenten (hier: Paperless als DMS (Document Management System) sowie individuell angepassten Komponenten (Workflow). Nicht im Detail dargestellt ist das Buchhaltungssystem, welches voll in dieses Szenario integriert ist. Dies ist im aktuellen Fall auf der Basis von MS Access mit einem MySQL-Backend realisiert.

Die Abwicklung des Zahlungsverkehrs ist denkbar einfach -> Rechnungsdokumente werden eingescannt oder sie liegen bereits als digitales Dokument in Form eines E-Mail-Anhanges bereit. Im Hintergrund ist das DMS aktiv und wartet darauf, dass Dokumente bereitgestellt werden.

Sobald ein neues Dokument im DMS gespeichert ist, prüft ein interner 24/7-Prozess dieses Dokument und extrahiert aus dem Dokument die für den Zahlungsverkehr relevanten Informationen (Kundenname, IBAN, Betrag, Rechnungsdatum, Rechnungsnummer, usw.) mit Hilfe von KI (ChatGPT). Diese Informationen werden dann mittels der Workflow-Komponente den Personen weitergeleitet, welche für die Sichtprüfung dieser Informationen verantwortlich sind.

Sind die Informationen vollständig, wird das Dokument für die Freigabe an die im System definierten Personen weitergeleitet, welche für die Freigabe verantwortlich zeichnen.

Ist die Freigabe erfolgt, dann werden die Informationen des Dokumentes für die Erstellung einer SEPA-Datei genutzt. Die für die Bankabwicklung verantwortlichen Personen werden informiert und müssen nun noch die SEPA-Datei in der hierfür zuständigen Bank für die finale Verarbeitung hochladen. Ein direktes Interface aus dem Workflow in die Bank (e.g. EBICS) gibt es hier nicht.

Bargeld – das Sorgenkind

Warum Sorgenkind? Weil im Bereich der Barkasse oft sehr hemdsärmelig mit wenig aussagefähigen Belegen hantiert wird. Aber gerade in diesem Bereich sollte verstärkt auf die Vorgaben der GoDB geachtet werden. Das bedeutet, dass man jeden Bargeldtransfer – egal ob Einnahme oder Ausgabe – mit einem eindeutigen, aussagefähigen Dokument belegen sollte. Das bedeutet für die Ausgabe -> Quittungsbeleg erstellen und dort den Empfänger sowie den Zweck eindeutig beschreiben und quittieren lassen.

Gleiches gilt für die Einnahme -> nicht einfach den Betrag in die Kasse legen und einen wenig aussagefähigen Kommentar im Kassenbuch hinterlegen, sondern aus freien Stücken eine Quittung für den erhaltenen Betrag samt dem Verwendungszweck hinterlegen und quittieren.

Hat man dieses Prinzip einmal verinnerlicht, dann ist der Weg zu einer digitalen Belegerfassung nicht mehr weit. Den vorstehend genannten Quittungsbeleg einscannen -> den Rest macht dann DMS und Workflow. Mit dem dann erstellten digitalen Dokument geht es dann weiter in Richtung Buchhaltung. Die Buchhaltung muss in diesem Falle nur noch das entsprechende Sachkonto zuordnen, der Rest aller benötigten Informationen ist bereits durch den Workflow hinterlegt.

Die weiteren Schritte in der Buchhaltung

Natürlich gibt es in der Buchhaltung nicht nur Zahlungen von Rechnungen, sondern eine Menge anderer Transaktionen wie z.B.

• Einnahmen – z.B. Spenden, Zinsen, Zuschüsse von Behörden
• Sonstige Ausgaben – z.B. Kosten des Zahlungsverkehrs, Lohnzahlungen, Steuern, Sozialabgaben
• Umbuchungen zwischen unterschiedlichen Konten des Vereins

Es gibt – auch bei derart einfachen Buchhaltungssystem wie E/A-Buchführung – auch den Grundsatz, dass es für jede Buchung einen Beleg geben muss. Hier kommt der Begriff „Ersatzbeleg“ ins Spiel. Dieser Begriff steht dafür, dass für bestimmte Buchungspositionen des System selbsttätig einen Beleg erstellt und dieser in das DMS einspeichert wird. Natürlich wird dieser Prozess kontrolliert und es darf nicht beliebig für fehlende Dokumente ein Ersatzbeleg erstellt werden. Im Prinzip ausgeschlossen sind Ausgabepositionen, wobei hier die Ausnahme besteht, dass für ausgestellte Einzugsmandate ein Ersatzbeleg erstellt werden kann, da oft keine explizite Rechnung beim Einzug geliefert wird -> Beispiele: Mieten, Nebenkosten und dergleichen.

Schlussendlich aber verknüpft das System den Buchhaltungsbeleg mit dem DMS-Dokument, womit einfach per Knopfdruck aus dem Buchhaltungssystem das digitale Dokument angezeigt werden kann.

Konsequenzen für die Revision

Natürlich ändert sich in Verbindung mit einem digitalen System die Anforderung und Vorgehensweise der Revision total. Wo früher die Kontrolle der Vollständigkeit von Belegen Vorrang hatte, steht jetzt der Inhalt und die Korrektheit der Belege als solche im Mittelpunkt.

Systemkomponenten

Im vorliegenden Fall wurden folgende Systemkomponenten genutzt:

• ein Linux-Server (Basis Ubuntu)
• ein DMS-System -> hier Paperless Ngx
• ein auf Php-Basis entwickelter Controller, welcher den Input für den Workflow erstellt
• eine Workflow-Komponente auf der Basis von Yii
• eine MySQL-Datenbank
• ein MS-Access-Frontend für die Buchhaltung

Leider ist das System sehr individuell geschneidert. Der Schritt von einem individuellen System zu einem allgemein verfügbaren Produkt ist doch ziemlich groß und nicht so ohne weiteres von einer einzelnen Person zu stemmen.

Fazit

Natürlich stellt sich die Frage: „lohnt“ sich das? Diese Frage ist sehr schwer zu beantworten. Aus Sicht der Transparenz und den Möglichkeiten, einfach zu kommunizieren und Buchungsbelege immer digital bereit zu haben – JA!

Aber es bleibt natürlich die Frage: wer kann das System administrieren? Ist das System einmal installiert und bei den betroffenen Personen etabliert, dann gibt es nicht viele Aspekte, welche besonders wartungsanfällig sind. Schön wäre es, wenn andere Softwarehersteller (z.B. „Mein Verein“) ihre Applikationen via API öffnen würden, damit z.B. die Buchhaltungskomponente von „Mein Verein“ eingesetzt werden könnte. Diese API-Schnittstellen sind z.B. in Paperless-Ngx hervorragend gelöst und lassen damit erst die vorstehend gezeigte Integration zu.

Die Anforderungen an den (ehrenamtlichen?) Support sind vielfältig, aber natürlich auch interessant. Es braucht halt gutes analytisches Verständnis und ausreichende Kenntnisse in den vorstehend genannten Systemkomponenten. Man muss sich dort „bewegen“ können und für Detailfragen sollte man heut zu Tage die KI (ChatGPT, Claude, ..) als Tutor und Assistent mit ins Boot nehmen.

Aber in der Summe bräuchte es eben Mitstreiter im Sinne von NPOITSUPPORT -> die ehrenamtliche Unterstützung von Vereinen im IT-Bereich.