Vereinsverwaltung selbst gebaut:Vom Ticketshop zur Digitalen Zentrale

Im März stand hier: 3,5 Wochen, mehrere PDF-Bibliotheken, kein Plan. Ein halbes Jahr später hat derselbe Verein eine komplette Verwaltung – Mitglieder, Beiträge, Rechnungen, Partner, Protokolle. Die Umsetzung hat drei Tage gedauert. Warum das kein Widerspruch ist, sondern die eigentliche Geschichte, steht in diesem Artikel.

Ein Fest ist vorbei. Und dann?

Das Gründungsfest ist gelaufen. Das selbst gebaute Ticketsystem hat gehalten, der Nachmittag war voll, der Abend deutlich leerer als geplant – wie das kam, steht im Rückblick zum Ticketsystem. Der Verein hatte viel gelernt, ich war müde, und dann kam die Frage, die nach jedem Fest kommt:

„Und wie machen wir jetzt den Rest?“

Der Rest, das sind die anderen 360 Tage im Jahr. Mitgliedsanträge, Beiträge einziehen, Protokolle ablegen, Inventar zählen, Partner anschreiben, Anfragen von Ortschaften beantworten, die den Wagen im Umzug haben wollen. Bisher lief das über ein kleines Orga-Werkzeug, das ich nebenbei gebaut hatte – und das mit jedem Wunsch ein Stück gewachsen war.

Irgendwann wächst so ein Werkzeug nicht mehr. Es wuchert. Also: neu. Und diesmal richtig.

Warum nicht wieder Vanilla PHP?

Beim Ticketsystem war die ehrliche Antwort auf „Warum dieser Stack?“: Weil ich damit am schnellsten vorankam. Das war für einen Ticketshop in Ordnung.

Eine Vereinsverwaltung ist ein anderes Tier. Sie besteht aus Rollen, Rechten, Fristen, Formularen, Tabellen, Filtern und Exporten – also aus genau dem Zeug, das man kein zehntes Mal von Hand bauen sollte.

Filament liefert die Bausteine für Tabellen, Formulare und Filter gleich mit. Die Vereinsabläufe, Rollen und Zugriffsregeln muss ich trotzdem selbst definieren und testen — aber ich konnte mich um das kümmern, was der Verein wirklich braucht, statt um Pagination.

Die Regel, die alles geordnet hat

Die öffentliche Vereinswebsite und die interne Verwaltung sind seit diesem Umbau zwei getrennte Projekte. Eigener Ordner, eigenes Git-Repository, eigene Datenbank.

Klingt selbstverständlich. War es nicht. Vorher landeten Änderungen gern mal im falschen Projekt, und ein kleiner Fix an der Website zog plötzlich Dateien der Verwaltung mit. Jetzt trägt jede Aufgabe eine Kennung: W- für die Website, Z- für die Zentrale. Ohne Kennung wird nichts angefasst.

Eine Zeile Regel. Sie hat mir vermutlich mehr Stunden gespart als jedes Framework.

Was in der Zentrale steckt

Drei Dinge davon will ich genauer zeigen. Nicht, weil der Code besonders wäre, sondern weil sie mehr über Vereinsarbeit verraten als über Programmierung.

1. Beitragseinzug statt Mahnwesen

Mein erster Entwurf war ein Mahnwesen. Der Vorstand hat ihn verworfen, und zwar zu Recht: Der Normalfall ist, dass das Geld pünktlich kommt. Also baut man für den Normalfall und nicht für die Ausnahme.

Die Zentrale rechnet dem Kassier jetzt einen Fahrplan aus: bis wann die Vorabankündigung raus muss, bis wann der Einzug bei der Bank sein muss, welche Rückgabe- und Erstattungsfristen laufen — eine technische Rückgabe und die acht Wochen, in denen ein Mitglied ohne Begründung zurückbuchen kann, sind zweierlei. Erst wer tatsächlich zurückkommt, landet im Mahnwesen – in genau den zwei Stufen, die die Satzung vorschreibt.

Und eine Entscheidung, auf die ich Wert gelegt habe: Die Zentrale speichert keine Bankdaten der Mitglieder. Keine IBAN, kein Mandat. Der Einzug läuft in der Banksoftware des Kassiers; die Zentrale sagt nur, wann, für wen und wie viel. Was die Zentrale nicht speichert, kann dort auch nicht wegkommen — geschützt werden müssen die Daten trotzdem, nur eben in der Banksoftware.

2. Rechnungen, die eine Prüfung aushalten sollen

Sobald ein Verein Werbeleistung an Firmen verkauft – Logo am Wagen, Banner am Bauzaun – schreibt er Rechnungen. Und Rechnungen haben Regeln, die nicht der Mensch einhalten sollte, sondern die Software. Revisionssicherheit war für mich von Anfang an die Vorgabe, nicht ein nettes Extra. Konkret heißt das:

• Die Nummer entsteht erst beim Festschreiben. Ein verworfener Entwurf reißt keine Lücke in den Nummernkreis. Zwingend ist das nicht — das Umsatzsteuerrecht verlangt eine einmalige Nummer, keine lückenlose Folge. Aber eine Lücke, die niemand erklären kann, kostet im Zweifel mehr Zeit als die saubere Lösung.
• Danach ist der Beleg gesperrt. Die Sperre sitzt in der Anwendungslogik, nicht nur in der Oberfläche. Einen direkten Datenbankzugriff am Programm vorbei fängt sie nicht ab.
• Das PDF bekommt eine Prüfsumme. Ein späterer Vergleich erkennt Änderungen an der Datei — vorausgesetzt, der gespeicherte Vergleichswert bleibt selbst geschützt.
• Gelöscht wird nichts. Je nach Fehler wird berichtigt oder storniert, immer mit Bezug zum Original. Beides bleibt nachvollziehbar.
• Dieselbe Zahlung ist Spende oder Sponsoring, nie beides. Eine Spende bekommt eine Zuwendungsbestätigung, eine Werbeleistung eine Rechnung — die Anwendung führt beides getrennt. Ob der Verein im konkreten Fall zur Ausstellung berechtigt ist, prüft sie nicht; das bleibt Sache des Vorstands.

Was ich damit nicht behaupte: dass ein Betriebsprüfer das Verfahren abgenommen hätte. Revisionssicherheit hängt nicht nur an der Software, sondern auch an Aufbewahrung, Zugriffsrechten und einer Verfahrensdokumentation. Die Vorgabe habe ich gesetzt und technisch umgesetzt — das Urteil darüber fällt jemand anderes.

Ein Detail, das mir Spaß gemacht hat: Beträge liegen als ganze Cent in der Datenbank, nicht als binäre Gleitkommazahlen. Weil 0,10 € plus 0,20 € dort eben nicht exakt 0,30 € ergibt. Dafür gibt es einen eigenen Test. Er ist grün.

Und die E-Rechnung?

Eine Frage, die mir seit 2025 jeder stellt: Ein PDF ist keine E-Rechnung im Sinne der neuen Vorschriften, sondern eine „sonstige Rechnung". Für den rein ideellen Vereinsbereich spielt das keine Rolle. Sobald ein Verein unternehmerisch tätig wird — und Sponsoring ist das — gelten die allgemeinen Regeln mitsamt Übergangsfristen und Kleinunternehmer-Ausnahmen. Wichtig ist die Unterscheidung zwischen Ausstellen und Empfangen: Empfangen können muss man strukturierte Rechnungen früher, als man selbst welche schreiben muss. Wo das Modul dabei steht, dokumentiere ich getrennt — das ist nichts, was man im Vorbeigehen klärt.

3. Die Satzung ist die Spezifikation

Beim Bauen des Mahnwesens habe ich die Satzung auf der Vereinswebsite gelesen – und festgestellt, dass dort nur eine Kurzfassung stand. Ausgerechnet der Paragraf zum Mahnverfahren brach mitten im Satz ab.

Jetzt steht der vollständige Wortlaut online, und die Fristen daraus stecken in der Software: Geschäftsjahr, Einladungsfrist zur Mitgliederversammlung, Mahnstufen, Austrittsfristen, Stimmrecht ab 16. Die Zentrale rechnet mit dem, was der Verein beschlossen hat – nicht mit dem, was „üblich“ ist.

Partner: ein Name für alles

Website, Partnermappe und Vertrag nannten dieselben Sponsoring-Pakete unterschiedlich. Eine Firma liest die Website, lädt die Mappe herunter – und findet ein anderes Angebot. Genau an dieser Stelle kippt Vertrauen, noch bevor jemand angerufen hat.

Jetzt gibt es fünf Pakete mit je einem Namen und einem Preis, gepflegt an einer Stelle. Website, Vertrag und Rechnung lesen daraus. Wer einen Preis ändert, ändert ihn einmal.

Dazu kam ein richtiges Formular statt eines E-Mail-Links – mit einem Ankreuzfeld, das es vorher nicht gab: „Wir möchten lieber spenden, ohne Werbeleistung.“ Vorher landeten Spendenwillige zwangsläufig im Sponsoring-Trichter, und der Kassier saß hinterher zwischen zwei Belegarten fest.

Die Fails. Ja, schon wieder.

Eine Dokumentation, die nur Erfolge zeigt, ist wertlos. Also der Reihe nach.

Fail #1: Die lokale Konfiguration auf dem Server

Beim Hochladen per FTP ist eine Konfigurationsdatei meiner lokalen Testumgebung mitgewandert. Sie zeigte auf einen Ordner, den es auf dem Server nicht gibt. Ergebnis: Jede Unterseite der Vereinswebsite lieferte „Seite nicht gefunden“. Nur die Startseite lief.

Behoben in einer Viertelstunde. Die Datei trug im Kopf übrigens den Hinweis „NUR LOKAL – niemals hochladen“. Hat exakt nichts genützt.

Fail #2: Die Testumgebung hing an der Live-Datenbank

Im März war mein erstes Learning: Testumgebungen sind heilig. Tja.

Mitten im Umbau fiel auf, dass meine lokale Umgebung auf die echte Vereinsdatenbank zeigte. Ein einziger falscher Befehl, und die Mitgliederdaten wären weg gewesen. Aufgefallen ist es, bevor dieser Befehl lief. Das war Glück, keine Leistung.

Fail #3: Das „Übliche“ statt der Vereinsunterlagen

Zweimal habe ich Standardwerte genommen statt nachzulesen. Das Beitragsjahr als Kalenderjahr – die Satzung sagt: 1. September bis 31. August. Und 14 Tage Vorlauf für die Lastschrift-Ankündigung — das ist die reguläre Frist, abweichen darf man aber, wenn es vereinbart ist. Das Mandat des Vereins sagt: fünf.

Beides aufgefallen, bevor es ernst wurde. Beides wäre beim ersten echten Einzug schmerzhaft geworden.

Fail #4: Eine Vorgabe, die sich selbst widerspricht

Ich wollte den Mitgliederbereich „optisch zurückgenommen“ in die Hauptnavigation setzen – aber „ohne neues CSS“. Das geht nicht, und das Ergebnis sah entsprechend aus: In der Schauschrift wurde der Link zum breitesten Element im Kopf und brach um. Zwei Durchgänge verloren, bis die Entscheidung stand: Der Mitgliederbereich kommt aus dem Kopf raus und steht nur noch im Fuß. Die neun Navigationselemente passten in unserem Layout nicht mehr in eine Zeile.

Sechs Monate. Drei Tage.

Die drei Tage sind die Zahl, die am meisten Fragen auslöst. Deshalb ehrlich: Das waren drei Tage Umsetzung, nicht drei Tage Arbeit.

Davor lagen das Ticketsystem im März, Monate mit dem alten Orga-Werkzeug, ein Fest, das anders lief als geplant, die Satzung Paragraf für Paragraf und viele Gespräche darüber, wie dieser Verein tatsächlich arbeitet – nicht, wie Vereine im Allgemeinen arbeiten. Jeder Fehler aus dieser Zeit steckt als Regel in der neuen Zentrale.

Der Unterschied liegt nicht darin, dass ich schneller tippe. Er liegt darin, dass ich diesmal vorher wusste, was ich will – und es sauber aufgeschrieben hatte, bevor die erste Zeile Code entstand. Das Wissen hat ein halbes Jahr gedauert. Das Bauen nicht.

Was ich daraus mitnehme

1. Planung schlägt Tempo. Die kurze Umsetzung war nur möglich, weil jede Etappe einen klaren Auftrag hatte – und der kam aus einem halben Jahr Praxis.
2. Regeln gehören ins System, nicht ins Gedächtnis. Ausschlusslisten, getrennte Datenbanken, Sperren im Datenmodell.
3. Die Satzung ist die Spezifikation. Wer für einen Verein baut, liest sie zuerst. Vollständig.
4. Was man nicht speichert, muss man nicht schützen. Keine Bankdaten der Mitglieder – und der Datenschutz wird um eine Sorge leichter.
5. Fehler aufschreiben. Sonst macht man sie zweimal. Siehe Fail #2.

Braucht dein Verein das?

Ehrlich: Nicht jeder. Für viele Vereine reicht eine gute Tabelle und eine saubere Website. Eine eigene Verwaltung lohnt sich erst, wenn ein paar dieser Punkte zutreffen:

• Der Kassier jongliert mit drei Listen, und keine ist die aktuelle.
• Partneranfragen versanden in privaten Postfächern, und niemand weiß, wer zuletzt geantwortet hat.
• Bei der letzten Mitgliederversammlung war unklar, ob die Einladung fristgerecht raus war.
• Rechnungen an Sponsoren entstehen in Word, und die Nummern werden von Hand hochgezählt.
• Der Mitgliedsantrag liegt als Scan in einem Ordner, der bei einem Vorstandswechsel mit umzieht – oder auch nicht.

Wenn du dich bei zwei oder drei Punkten ertappt hast, lohnt sich ein Gespräch. Nicht zwingend über Software. Manchmal ist die richtige Antwort auch: erst die Satzung vollständig auf die Website, dann sehen wir weiter.