Vom leeren Ordner zur ersten Rechnung

25. Juni 2026

Vom leeren Ordner zur ersten Rechnung

Seit Anfang 2025 müssen Unternehmen in Deutschland E-Rechnungen empfangen können. Bald kommt die Pflicht, auch selbst welche zu verschicken. Eine E-Rechnung ist dabei keine PDF, die man nur ansieht, sondern eine Rechnung mit strukturierten Daten, die eine Software direkt weiterverarbeiten kann. Wer Rechnungen schreibt, braucht also früher oder später ein Werkzeug dafür.

Für meine Buchhaltung nutze ich DATEV, und das Programm zum Rechnungschreiben dort ärgert mich seit Langem. Es zwingt mich zu einer festen Versand-Adresse pro Kunde. In der Praxis schicke ich eine Rechnung aber oft an den Ansprechpartner, nicht an eine zentrale Adresse. Eine Nextcloud-App, die schlankes Rechnungschreiben, E-Rechnung und eine flexible Übergabe an DATEV verbindet, gibt es nicht. Also habe ich angefangen, mir selbst eine zu bauen. Sie heißt RechnungsWerk.

Am Abend desselben Tages war aus einem leeren Ordner eine App geworden, in der ich die erste echte Rechnung angelegt und festgeschrieben habe. Sie trug die Nummer RE-2026-0001.

Bevor die erste Zeile Code steht

Das Erste an so einer App ist nicht der Code. Bevor ich irgendetwas gebaut habe, stand eine ausführliche Produktbeschreibung. Was soll die App können, was bewusst nicht, für wen ist sie gedacht. Dazu kam ein klickbarer Entwurf der Oberfläche, also eine Seite, durch die ich mich klicken kann, ohne dass dahinter schon etwas funktioniert. Erst als Idee, Beschreibung und Entwurf standen, habe ich das eigentliche Gerüst der App aufgesetzt.

Dieses Gerüst habe ich nicht neu erfunden. Ich habe es von einer bestehenden App von mir abgeschaut, die schon auf der aktuellen Technik läuft. Die Lehre aus einem früheren Umbau war eindeutig. Lieber gleich auf dem zeitgemäßen Stand anfangen, als später mühsam nachzuziehen.

Wo das Wissen herkam, das ich nicht hatte

Ich bin kein gelernter Entwickler, und an einer Stelle wurde das an diesem Tag sehr deutlich. Zu meiner Arbeitsweise gehört, dass jeder Schritt von einer automatischen Prüfung gegengelesen wird, bevor er in die App wandert. Diese Prüfung meldete ein ernstes Problem, an das ich selbst nie gedacht hätte.

Es ging um die Rechnungsnummern. Die müssen lückenlos und eindeutig sein, das ist bei einem Buchhaltungswerkzeug gesetzliche Pflicht und keine Geschmacksfrage. Wenn nun zwei Rechnungen im selben Moment festgeschrieben werden, also endgültig abgeschlossen und mit ihrer Nummer versehen werden, könnten sie sich dieselbe Nummer greifen oder eine Lücke hinterlassen. Die Lösung dafür ist technisch und von außen unsichtbar. Sie kam nicht aus meinem Kopf, sondern aus der Prüfung.

Genau das ist für mich der Kern. Ich entscheide, beurteile und gebe die Richtung vor. Die tiefe technische Absicherung liefert das Werkzeug. Man muss eben nicht jede Feinheit selbst beherrschen, um etwas Solides zu bauen.

Design kommt nicht aus dem Nichts

Ein zweiter Moment des Tages hatte mit dem Aussehen zu tun. Wir hatten vorher einen Entwurf der Oberfläche gemacht. Zwei meiner anderen Apps haben außerdem längst eine fertige, einheitliche Gestaltung. Trotzdem kam an einer Stelle plötzlich selbstgebautes, billig wirkendes Design heraus, das mit alldem nichts zu tun hatte. Das hat mich geärgert.

Der Punkt dahinter ist simpel und trotzdem leicht zu übersehen. Wenn die Designsprache schon existiert, muss man sie benutzen, statt jedes Mal etwas Neues zu erfinden. Ich will nicht selbst Kästchen verschieben und an Abständen feilen. Ich will den fertigen Stand sehen und beurteilen. Also haben wir das Aussehen auf eine gemeinsame Quelle umgestellt, aus der sich alles bedient.

Danach habe ich am laufenden Stand im Detail nachgeschärft. Kräftige, lesbare Farben für die Status-Markierungen statt blasser Schrift, die niemand entziffern kann. Gleich lange Markierungen statt unterschiedlich breiter. Die richtigen Feldbreiten. Lauter Kleinigkeiten, die zusammen den Unterschied machen.

Wo es heute steht

Am Ende des Tages konnte ich in der App eine Rechnung anlegen, festschreiben und auch wieder stornieren. Die erste echte Rechnung trug die Nummer RE-2026-0001, die Stornierung danach RE-2026-0002. Das war der Moment, in dem aus einem Konzept etwas Benutzbares wurde.

Ein Stück fehlte an dem Abend aber noch. Eine gültige E-Rechnung hatte ich bis dahin nicht erzeugt. Dafür gibt es eine Norm mit festen Formvorschriften, die man umsetzen muss.

Am 25. Juni ging RechnungsWerk dann in den Nextcloud App Store. Inzwischen erzeugt die App auch die gültige E-Rechnung nach dem geforderten Standard und übergibt sie automatisch an DATEV.

Die Grundfunktion steht damit. Von hier an geht es um die Feinheiten. Darum, dass die App im Alltag leichter von der Hand geht, Schritt für Schritt.