![\"\"](\"https:\/\/www.npoitsupport.de\/wp-content\/uploads\/2026\/06\/Praesentation1-1024x576.jpg\")
<\/figure>\n\n\n\nDie 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.<\/p>\n\n\n\n
Sobald ein neues Dokument im DMS gespeichert ist, pr\u00fcft ein interner 24\/7-Prozess dieses Dokument und extrahiert aus dem Dokument die f\u00fcr 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\u00fcr die Sichtpr\u00fcfung dieser Informationen verantwortlich sind. <\/p>\n\n\n\n
Sind die Informationen vollst\u00e4ndig, wird das Dokument f\u00fcr die Freigabe an die im System definierten Personen weitergeleitet, welche f\u00fcr die Freigabe verantwortlich zeichnen.<\/p>\n\n\n\n
Ist die Freigabe erfolgt, dann werden die Informationen des Dokumentes f\u00fcr die Erstellung einer SEPA-Datei genutzt. Die f\u00fcr die Bankabwicklung verantwortlichen Personen werden informiert und m\u00fcssen nun noch die SEPA-Datei in der hierf\u00fcr zust\u00e4ndigen Bank f\u00fcr die finale Verarbeitung hochladen. Ein direktes Interface aus dem Workflow in die Bank (e.g. EBICS) gibt es hier nicht.<\/p>\n\n\n\n
Bargeld – das Sorgenkind<\/h2>\n\n\n\n
Warum Sorgenkind? Weil im Bereich der Barkasse oft sehr hemds\u00e4rmelig mit wenig aussagef\u00e4higen Belegen hantiert wird. Aber gerade in diesem Bereich sollte verst\u00e4rkt auf die Vorgaben der GoDB geachtet werden. Das bedeutet, dass man jeden Bargeldtransfer – egal ob Einnahme oder Ausgabe – mit einem eindeutigen, aussagef\u00e4higen Dokument belegen sollte. Das bedeutet f\u00fcr die Ausgabe -> Quittungsbeleg erstellen und dort den Empf\u00e4nger sowie den Zweck eindeutig beschreiben und quittieren lassen.<\/p>\n\n\n\n
Gleiches gilt f\u00fcr die Einnahme -> nicht einfach den Betrag in die Kasse legen und einen wenig aussagef\u00e4higen Kommentar im Kassenbuch hinterlegen, sondern aus freien St\u00fccken eine Quittung f\u00fcr den erhaltenen Betrag samt dem Verwendungszweck hinterlegen und quittieren.<\/p>\n\n\n\n
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\u00f6tigten Informationen ist bereits durch den Workflow hinterlegt.<\/p>\n\n\n\n
Die weiteren Schritte in der Buchhaltung<\/h2>\n\n\n\n
Nat\u00fcrlich gibt es in der Buchhaltung nicht nur Zahlungen von Rechnungen, sondern eine Menge anderer Transaktionen wie z.B.<\/p>\n\n\n\n
- \n
- Einnahmen – z.B. Spenden, Zinsen, Zusch\u00fcsse von Beh\u00f6rden<\/li>\n\n\n\n
- Sonstige Ausgaben – z.B. Kosten des Zahlungsverkehrs, Lohnzahlungen, Steuern, Sozialabgaben<\/li>\n\n\n\n
- Umbuchungen zwischen unterschiedlichen Konten des Vereins<\/li>\n<\/ul>\n\n\n\n
Es gibt – auch bei derart einfachen Buchhaltungssystem wie E\/A-Buchf\u00fchrung – auch den Grundsatz, dass es f\u00fcr jede Buchung einen Beleg geben muss. Hier kommt der Begriff „Ersatzbeleg“ ins Spiel. Dieser Begriff steht daf\u00fcr, dass f\u00fcr bestimmte Buchungspositionen des System selbstt\u00e4tig einen Beleg erstellt und dieser in das DMS einspeichert wird. Nat\u00fcrlich wird dieser Prozess kontrolliert und es darf nicht beliebig f\u00fcr fehlende Dokumente ein Ersatzbeleg erstellt werden. Im Prinzip ausgeschlossen sind Ausgabepositionen, wobei hier die Ausnahme besteht, dass f\u00fcr ausgestellte Einzugsmandate ein Ersatzbeleg erstellt werden kann, da oft keine explizite Rechnung beim Einzug geliefert wird -> Beispiele: Mieten, Nebenkosten und dergleichen.<\/p>\n\n\n\n
Schlussendlich aber verkn\u00fcpft das System den Buchhaltungsbeleg mit dem DMS-Dokument, womit einfach per Knopfdruck aus dem Buchhaltungssystem das digitale Dokument angezeigt werden kann. <\/p>\n\n\n\n
Konsequenzen f\u00fcr die Revision<\/h2>\n\n\n\n
Nat\u00fcrlich \u00e4ndert sich in Verbindung mit einem digitalen System die Anforderung und Vorgehensweise der Revision total. Wo fr\u00fcher die Kontrolle der Vollst\u00e4ndigkeit von Belegen Vorrang hatte, steht jetzt der Inhalt und die Korrektheit der Belege als solche im Mittelpunkt.<\/p>\n\n\n\n
Systemkomponenten<\/h2>\n\n\n\n
Im vorliegenden Fall wurden folgende Systemkomponenten genutzt:<\/p>\n\n\n\n
- \n
- ein Linux-Server (Basis Ubuntu)<\/li>\n\n\n\n
- ein DMS-System -> hier Paperless Ngx<\/li>\n\n\n\n
- ein auf Php-Basis entwickelter Controller, welcher den Input f\u00fcr den Workflow erstellt<\/li>\n\n\n\n
- eine Workflow-Komponente auf der Basis von Yii<\/li>\n\n\n\n
- eine MySQL-Datenbank<\/li>\n\n\n\n
- ein MS-Access-Frontend f\u00fcr die Buchhaltung<\/li>\n<\/ul>\n\n\n\n
Leider ist das System sehr individuell geschneidert. Der Schritt von einem individuellen System zu einem allgemein verf\u00fcgbaren Produkt ist doch ziemlich gro\u00df und nicht so ohne weiteres von einer einzelnen Person zu stemmen. <\/p>\n\n\n\n
Fazit<\/h2>\n\n\n\n
Nat\u00fcrlich stellt sich die Frage: „lohnt“ sich das? Diese Frage ist sehr schwer zu beantworten. Aus Sicht der Transparenz und den M\u00f6glichkeiten, einfach zu kommunizieren und Buchungsbelege immer digital bereit zu haben – JA! <\/p>\n\n\n\n
Aber es bleibt nat\u00fcrlich 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\u00e4llig sind. Sch\u00f6n w\u00e4re es, wenn andere Softwarehersteller (z.B. „Mein Verein“) ihre Applikationen via API \u00f6ffnen w\u00fcrden, damit z.B. die Buchhaltungskomponente von „Mein Verein“ eingesetzt werden k\u00f6nnte. Diese API-Schnittstellen sind z.B. in Paperless-Ngx hervorragend gel\u00f6st und lassen damit erst die vorstehend gezeigte Integration zu. <\/p>\n\n\n\n
Die Anforderungen an den (ehrenamtlichen?) Support sind vielf\u00e4ltig, aber nat\u00fcrlich auch interessant. Es braucht halt gutes analytisches Verst\u00e4ndnis und ausreichende Kenntnisse in den vorstehend genannten Systemkomponenten. Man muss sich dort „bewegen“ k\u00f6nnen und f\u00fcr Detailfragen sollte man heut zu Tage die KI (ChatGPT, Claude, ..) als Tutor und Assistent mit ins Boot nehmen. <\/p>\n\n\n\n
Aber in der Summe br\u00e4uchte es eben Mitstreiter im Sinne von NPOITSUPPORT -> die ehrenamtliche Unterst\u00fctzung von Vereinen im IT-Bereich. <\/p>\n","protected":false},"excerpt":{"rendered":"
Zielsetzung – Grundgedanke Die Anforderungen f\u00fcr 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\u00e4uft nicht so ab, wie man es vielleicht in einem KMU gewohnt w\u00e4re. Es gibt z.B. keinen „normalen“ B\u00fcrobetrieb, wo alle Verantwortlichen jederzeit verf\u00fcgbar sind und somit lokal kommunizieren k\u00f6nnten. Aber dennoch gelten nat\u00fcrlich auch f\u00fcr einen Verein die Grunds\u00e4tze der GoDB – also \u00dcbersichtlichkeit, Ordnung, Nachvollziehbarkeit, usw. usw. Im Nachfolgenden ist mal in der \u00dcbersicht 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\u00fcft ein interner 24\/7-Prozess dieses Dokument und extrahiert aus dem Dokument die f\u00fcr 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\u00fcr die Sichtpr\u00fcfung dieser Informationen verantwortlich sind. Sind die Informationen vollst\u00e4ndig, wird das Dokument f\u00fcr die Freigabe an die im System definierten Personen weitergeleitet, welche f\u00fcr die Freigabe verantwortlich zeichnen. Ist die Freigabe erfolgt, dann werden die Informationen des Dokumentes f\u00fcr die Erstellung einer SEPA-Datei genutzt. Die f\u00fcr die Bankabwicklung verantwortlichen Personen werden informiert und m\u00fcssen nun noch die SEPA-Datei in der hierf\u00fcr zust\u00e4ndigen Bank f\u00fcr 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\u00e4rmelig mit wenig aussagef\u00e4higen Belegen hantiert wird. Aber gerade in diesem Bereich sollte verst\u00e4rkt auf die Vorgaben der GoDB geachtet werden. Das bedeutet, dass man jeden Bargeldtransfer – egal ob Einnahme oder Ausgabe – mit einem eindeutigen, aussagef\u00e4higen Dokument belegen sollte. Das bedeutet f\u00fcr die Ausgabe -> Quittungsbeleg erstellen und dort den Empf\u00e4nger sowie den Zweck eindeutig beschreiben und quittieren lassen. Gleiches gilt f\u00fcr die Einnahme -> nicht einfach den Betrag in die Kasse legen und einen wenig aussagef\u00e4higen Kommentar im Kassenbuch hinterlegen, sondern aus freien St\u00fccken eine Quittung f\u00fcr 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\u00f6tigten Informationen ist bereits durch den Workflow hinterlegt. Die weiteren Schritte in der Buchhaltung Nat\u00fcrlich gibt es in der Buchhaltung nicht nur Zahlungen von Rechnungen, sondern eine Menge anderer Transaktionen wie z.B. Es gibt – auch bei derart einfachen Buchhaltungssystem wie E\/A-Buchf\u00fchrung – auch den Grundsatz, dass es f\u00fcr jede Buchung einen Beleg geben muss. Hier kommt der Begriff „Ersatzbeleg“ ins Spiel. Dieser Begriff steht daf\u00fcr, dass f\u00fcr bestimmte Buchungspositionen des System selbstt\u00e4tig einen Beleg erstellt und dieser in das DMS einspeichert wird. Nat\u00fcrlich wird dieser Prozess kontrolliert und es darf nicht beliebig f\u00fcr fehlende Dokumente ein Ersatzbeleg erstellt werden. Im Prinzip ausgeschlossen sind Ausgabepositionen, wobei hier die Ausnahme besteht, dass f\u00fcr ausgestellte Einzugsmandate ein Ersatzbeleg erstellt werden kann, da oft keine explizite Rechnung beim Einzug geliefert wird -> Beispiele: Mieten, Nebenkosten und dergleichen. Schlussendlich aber verkn\u00fcpft das System den Buchhaltungsbeleg mit dem DMS-Dokument, womit einfach per Knopfdruck aus dem Buchhaltungssystem das digitale Dokument angezeigt werden kann. Konsequenzen f\u00fcr die Revision Nat\u00fcrlich \u00e4ndert sich in Verbindung mit einem digitalen System die Anforderung und Vorgehensweise der Revision total. Wo fr\u00fcher die Kontrolle der Vollst\u00e4ndigkeit 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: Leider ist das System sehr individuell geschneidert. Der Schritt von einem individuellen System zu einem allgemein verf\u00fcgbaren Produkt ist doch ziemlich gro\u00df und nicht so ohne weiteres von einer einzelnen Person zu stemmen. Fazit Nat\u00fcrlich stellt sich die Frage: „lohnt“ sich das? Diese Frage ist sehr schwer zu beantworten. Aus Sicht der Transparenz und den M\u00f6glichkeiten, einfach zu kommunizieren und Buchungsbelege immer digital bereit zu haben – JA! Aber es bleibt nat\u00fcrlich 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\u00e4llig sind. Sch\u00f6n w\u00e4re es, wenn andere Softwarehersteller (z.B. „Mein Verein“) ihre Applikationen via API \u00f6ffnen w\u00fcrden, damit z.B. die Buchhaltungskomponente von „Mein Verein“ eingesetzt werden k\u00f6nnte. Diese API-Schnittstellen sind z.B. in Paperless-Ngx hervorragend gel\u00f6st und lassen damit erst die vorstehend gezeigte Integration zu. Die Anforderungen an den (ehrenamtlichen?) Support sind vielf\u00e4ltig, aber nat\u00fcrlich auch interessant. Es braucht halt gutes analytisches Verst\u00e4ndnis und ausreichende Kenntnisse in den vorstehend genannten Systemkomponenten. Man muss sich dort „bewegen“ k\u00f6nnen und f\u00fcr Detailfragen sollte man heut zu Tage die KI (ChatGPT, Claude, ..) als Tutor und Assistent mit ins Boot nehmen. Aber in der Summe br\u00e4uchte es eben Mitstreiter im Sinne von NPOITSUPPORT -> die ehrenamtliche Unterst\u00fctzung von Vereinen im IT-Bereich.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-179","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.npoitsupport.de\/index.php\/wp-json\/wp\/v2\/posts\/179","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.npoitsupport.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.npoitsupport.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.npoitsupport.de\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.npoitsupport.de\/index.php\/wp-json\/wp\/v2\/comments?post=179"}],"version-history":[{"count":10,"href":"https:\/\/www.npoitsupport.de\/index.php\/wp-json\/wp\/v2\/posts\/179\/revisions"}],"predecessor-version":[{"id":197,"href":"https:\/\/www.npoitsupport.de\/index.php\/wp-json\/wp\/v2\/posts\/179\/revisions\/197"}],"wp:attachment":[{"href":"https:\/\/www.npoitsupport.de\/index.php\/wp-json\/wp\/v2\/media?parent=179"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.npoitsupport.de\/index.php\/wp-json\/wp\/v2\/categories?post=179"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.npoitsupport.de\/index.php\/wp-json\/wp\/v2\/tags?post=179"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}