Die Geschichte eines verrutschten Briefkopfs
Ein Verwalter formuliert eine zweite Mahnung an einen Eigentümer mit offenem Hausgeld-Soll. Word-Vorlage geöffnet, Anrede gepflegt, Forderungs-Tabelle eingefügt, Höflichkeitsformel angepasst, Datum kontrolliert. Dann der Druck auf den Kanzlei-Multifunktionsdrucker. Beim Falten fällt es auf: Die Anschrift sitzt drei Millimeter zu hoch, der obere Rand des Adressfelds rutscht hinter den Rand des Briefumschlag-Fensters. Auf dem zweiten Blatt fehlt die Seitenzahl, weil der Word-Header nur auf Seite 1 konfiguriert war. Die Korrekturschleife dauert vierzig Minuten — neue Vorlage öffnen, Tabulatoren nachziehen, Tabelle nachformatieren, Probedruck, Falztest, Wiederholungs-Druck. Der Brief geht raus, der Tag ist verbrannt.
Das Muster wiederholt sich in jeder Verwaltung, in der Briefe in Word geschrieben und über den Drucker-Treiber ausgegeben werden. Inhalt und Layout sind im selben Dokument verheiratet, jede inhaltliche Änderung kann das Layout zerschießen, und die DIN-5008-Maße sind eine permanente Fehlerquelle. Mit der Markdown-WYSIWYG-Variante des Brief-Editors und einer live aktualisierten PDF-Vorschau löst ImmoGenio dieses Muster sauber auf — und bettet das Schreiben gleichzeitig in den Workflow ein, aus dem der Brief tatsächlich entsteht.
Warum Word-Briefe in der Hausverwaltung Reibung erzeugen
Die DIN 5008:2020-03 regelt die Form des Geschäftsbriefs verbindlich: Anschriftfeld 45 mm vom oberen Blattrand entfernt, neunzeilig, mit einer Rücksendeangabe in den ersten beiden Zeilen; Faltmarken bei 105 mm und 210 mm; Bezugszeichenzeile bei 50 mm oder ein Informationsblock rechtsbündig; Seitenränder links 25 mm, rechts 20 mm, oben 16,9 mm bis zum Briefkopf. Diese Maße sind in Word nur über manuell konfigurierte Vorlagen abbildbar. Wer die Vorlage einmal angelegt hat, ist nicht fertig — Word verschiebt beim Einfügen längerer Textblöcke regelmäßig den Adressblock, der Briefkopf wird auf Seite 2 wiederholt, wo er nicht hingehört, und die Faltmarken verrutschen, sobald die Seitenzahl-Logik anders konfiguriert ist als beim Original.
Der zweite Schwachpunkt ist die fehlende Trennung von Inhalt und Darstellung. In Word steht der Fließtext direkt im Dokument, mit Inline-Formatierungen, Tabulatoren, manuell gesetzten Schriftgrößen. Eine Korrektur am Inhalt — etwa der Austausch der Empfänger-Adresse über eine Serienbrief-Funktion — kann unbemerkt die Schriftart wechseln, weil die Quell-Tabelle eine andere Standard-Schrift definiert. Der Verwalter sieht das Resultat erst beim Druck.
Die PDF-Konvertierung läuft in der Praxis über den Drucker-Treiber, oft über „Microsoft Print to PDF” oder den Adobe-Druckertreiber. Beide rastern Schriftarten unterschiedlich, behandeln eingebettete Bilder unterschiedlich und liefern bei gleichem Word-Dokument auf zwei verschiedenen Arbeitsplätzen zwei unterschiedliche PDF-Ergebnisse. Wer den Brief im Anschluss an einen Versanddienstleister wie Pingen oder LetterXpress übergibt — ein Workflow, der im Beitrag zum Hybrid-Briefversand beschrieben ist —, riskiert, dass das Adressfeld nicht im Fenster sitzt.
Hinzu kommt die fehlende Versionierung. Word-Dokumente sind Binärformate; ein Diff zwischen zwei Versionen ist ohne Spezialwerkzeuge nicht lesbar. Wer in der Hausverwaltung dokumentieren muss, welche Brief-Version am 14. April abgesandt wurde und welche am 21. April, hat in Word keine vernünftige Spur. Die Aufbewahrungspflicht nach § 257 HGB und § 147 AO verlangt zehn Jahre revisionssichere Ablage — Word-Stände in einem Netzlaufwerk-Ordner sind dafür keine geeignete Grundlage.
Die Markdown-Idee und der WYSIWYG-Toggle
Markdown trennt Inhalt von Darstellung, weil die Auszeichnung minimal und an den Inhalt gebunden ist: Überschriften per #, Listen per -, Hervorhebungen per **fett**. Es gibt keine eingebetteten Schriftarten, keine Tabulator-Setzungen, keine WordArt. Das hat zwei direkte Konsequenzen. Erstens lässt sich der Brief-Inhalt in einem Format speichern, das in jedem Texteditor lesbar bleibt und sich versionssicher diffieren lässt — ein Vorteil, der für die Aufbewahrung nach § 257 HGB und für interne Vier-Augen-Prüfungen relevant ist. Zweitens entsteht die finale Darstellung erst beim Rendering durch die Layout-Engine; Layout-Fehler beim Schreiben sind ausgeschlossen, weil das Schreiben kein Layout kennt.
Der Einwand gegen reines Markdown ist berechtigt: Nicht jeder Verwalter kennt die Auszeichnungsregeln, und die Lernkurve für ungeübte Schreiber ist eine Hürde. ImmoGenio löst das über einen Toggle. Wer Markdown beherrscht, schreibt in der Markdown-Spalte; wer den Brief lieber wie im Textverarbeitungsprogramm gewohnt sieht, schaltet auf WYSIWYG um und arbeitet mit einer Symbolleiste für Hervorhebungen, Listen und Überschriften-Stufen. Beide Eingabewege schreiben gegen denselben Markdown-Datensatz im Backend — die Eingabe-Oberfläche ist austauschbar, die gespeicherte Quelle bleibt identisch.
Die Trennung von Inhalt und Darstellung ist nicht nur ein Komfort-Argument. Sie ist die Voraussetzung dafür, dass das Tenant-spezifische Layout (Briefkopf, Brand-Farben, Logo) zentral gesteuert werden kann, ohne dass jeder einzelne Brief händisch angepasst werden muss. Wenn der Tenant das Logo austauscht, ist es im nächsten Brief automatisch korrekt — ein Detail, das im Whitelabel-Konzept zentral verankert ist.
Wie ImmoGenio den Editor umsetzt
Der Brief-Editor besteht aus drei Komponenten, die im Portal zu einem Panel verbunden sind. Der MarkdownToggleEditor rendert links den Markdown-Pane mit Syntax-Hervorhebung und rechts den WYSIWYG-Pane mit der gleichen logischen Struktur. Ein Toggle in der Header-Leiste schaltet zwischen beiden Eingabe-Modi um; beide Modi sind bidirektional an denselben Markdown-State gebunden, sodass eine Änderung im WYSIWYG-Pane sofort als Markdown im linken Pane sichtbar wird und umgekehrt. Die Tastenkürzel folgen Standard-Konventionen: Strg+B für fett, Strg+I für kursiv, Strg+K für Hyperlink-Einfügung.
Die Live-PDF-Vorschau läuft in einem separaten iframe. Diese Trennung ist bewusst gewählt: Der Editor läuft im Portal-Origin, der PDF-Renderer in einem eigenen Cross-Origin-isolierten Frame. So lassen sich Asset-URLs, Schrift-Einbindungen und Brand-Variablen sauber trennen, ohne dass der Editor-State Layout-Reflows im Vorschau-Rendering auslöst. Bei jeder Markdown-Änderung wird über einen debounced Request (250 ms) ein neuer PDF-Build angestoßen; der Renderer liefert das aktualisierte PDF zurück, das iframe lädt es mit einem Versions-Query-Parameter neu, um das Browser-Caching auszuhebeln.
Das PDF-Rendering selbst läuft über die interne Bibliothek @assetfux/pdf-renderer, die Puppeteer mit puppeteer-core und einer im Container vorinstallierten Chromium-Version kombiniert. Die HTML-Vorlage für den DIN-5008-Brief ist eine im Repository versionierte Template-Datei mit CSS-Druckregeln. Das Anschriftfeld sitzt absolut positioniert bei 45 mm vom Blattrand, die Faltmarken werden über @page und CSS-Hintergründe an den Stellen 105 mm und 210 mm gerendert, der Briefkopf greift Logo und Brand-Farben aus den Tenant-Settings ab. Die Schriften (PT Sans für Fließtext, Source Sans Pro für Headlines) sind als WOFF2 im Container abgelegt — keine Web-Font-Calls zur Laufzeit, weil Puppeteer im PDF-Modus kein externes Netzwerk haben darf.
Mehrseitige Briefe werden über CSS-Page-Regeln paginiert. @page :first definiert die Marge mit Briefkopf, @page ohne Pseudo-Klasse die Marge ab Seite 2 mit reduziertem Kopfbereich und Fußzeile inklusive Seitenzahl im Format „Seite X von Y”. Der Page-Counter wird von Chromium gerendert; eine manuelle Seitenzahl-Pflege entfällt. Tabellen mit Forderungs-Aufstellungen werden bei Seitenumbrüchen automatisch fortgesetzt, die Tabellenkopfzeile wiederholt sich auf jeder Folgeseite. Diese Detail-Disziplin ist der eigentliche Hebel: Wer einen dreiseitigen Mahnungs-Brief mit Forderungstabelle in Word baut, verbringt einen Tag mit Seiten-Headern; im Brief-Editor ist das eine Frage von Sekunden.
Brand-Treue ist nicht trivial. Tenant-spezifische Brand-Farben werden über CSS-Custom-Properties in die Vorlage eingespeist; das Logo wird als optimiertes SVG in den Briefkopf eingebettet, die Geschäfts-Pflichtangaben nach § 14 GewO und § 35a GmbHG kommen aus den Tenant-Stammdaten in den Footer. Der Editor zeigt zwar nur den Text-Inhalt, das Rendering liefert die vollständige DIN-5008-konforme Darstellung.
Die Workflow-Drafts-Inbox
Briefe entstehen in der Hausverwaltung selten frei. Sie sind fast immer Ergebnis eines Vorgangs: Ein Mietverhältnis geht in den Kündigungs-Prozess und löst ein Anschreiben an den Mieter aus; eine Forderung erreicht den zweiten Mahnschritt und erfordert ein neues Mahnschreiben; ein Wirtschaftsplan wird beschlossen und muss den Eigentümern zugesandt werden. Im klassischen Word-Workflow wird die Briefvorlage manuell gesucht, gefüllt, gespeichert und versandt — die Verbindung zum auslösenden Vorgang lebt nur im Kopf des Bearbeiters.
ImmoGenio dreht diese Logik um. Sobald ein Workflow einen brieflichen State erreicht, erzeugt ein Datenbank-Trigger einen Eintrag in der Tabelle workflow_letter_drafts. Der Eintrag enthält die Vorlagen-Referenz, die Adressdaten des Empfängers aus den Stammdaten, die kontext-spezifischen Variablen (Mahnstufe, Forderungssumme, Verzugszinsen-Berechnung) und einen vorbereiteten Markdown-Body, der über das im Beitrag zur Mustervorlagen-Bibliothek beschriebene Templating gefüllt wurde. Der Brief liegt damit als Draft vor, bevor der Verwalter ihn überhaupt geöffnet hat.
Die WorkflowDraftsInbox im Portal zeigt alle aktiven Drafts als Liste mit Empfänger, Anlass, Vorgang und Frist. Jede Zeile ist ein WorkflowDraftRow mit einem Ein-Klick-Öffnen, das den BriefEditorPanel mit dem vorbereiteten Markdown lädt. Der Verwalter ergänzt, kürzt oder passt an, beobachtet die Live-Vorschau und entscheidet anschließend über den Versand. Der Versand löst die im Hybrid-Briefversand-Beitrag beschriebene Übergabe an Pingen oder LetterXpress aus, der Draft wechselt in den Status „versandt”, der zugrunde liegende Workflow geht in den nächsten State.
Diese Inbox ist mehr als ein UI-Element. Sie ist die Schnittstelle, die das Brief-Schreiben aus dem Word-Silo herausholt und in den Workflow-Kontext stellt. Die Drafts sind versionssicher: Jede Editor-Speicherung erzeugt einen neuen Snapshot, der über den Audit-Trail nachvollziehbar bleibt. Wer am 14. April welche Mahnstufe an welchen Empfänger versandt hat, lässt sich noch im Jahr 2036 nachvollziehen.
Praxis-Workflow Kündigung
Ein Mietverhältnis tritt in den State kuendigung_in_prozess, weil ein Eigentümer-Antrag auf Eigenbedarf nach § 573 Abs. 2 Nr. 2 BGB vorliegt und alle Vorprüfungen abgeschlossen sind. Der Workflow-Trigger erzeugt automatisch einen Letter-Draft auf Basis der hinterlegten Kündigungs-Vorlage. Die Vorlage kennt die Pflichtangaben nach § 568 BGB (Schriftform), die Begründungspflicht nach § 573 Abs. 3 BGB (konkrete Darlegung des Eigenbedarfs) und die Kündigungsfrist nach § 573c BGB (drei, sechs oder neun Monate je nach Mietdauer, vgl. den Kündigungsworkflow-Beitrag).
Der Verwalter sieht den Draft in der Inbox, öffnet ihn im Brief-Editor und ergänzt die individuelle Begründung des Eigenbedarfs — konkret: welche Person den Bedarf hat, in welchem Verwandtschaftsverhältnis sie zum Eigentümer steht, ab wann und warum die Nutzung notwendig ist. Während er schreibt, rendert die Live-Vorschau die seitenweise PDF-Darstellung. Bei längerer Begründung wechselt der Brief von einer auf zwei Seiten; der Briefkopf bleibt auf Seite 1, die Fußzeile mit Seitenzahl rückt auf Seite 2 in den Sichtbereich.
Mit dem Klick auf „Versenden” wird der Brief in die im Hybrid-Briefversand-Modul beschriebene Pipeline übergeben, üblicherweise als Einschreiben Einwurf zur Beweis-Sicherung des Zugangs nach § 130 BGB. Pingen meldet die Zustellung über einen Webhook zurück, der Workflow geht in den State kuendigung_versandt und startet die Frist-Überwachung gemäß § 573c BGB. Die gesamte Kette — vom State-Wechsel über den Draft bis zur Zustell-Bestätigung — ist ohne manuellen Übergabe-Schritt zwischen Systemen abgebildet.
Compliance-Anker
Der Brief-Editor ist nicht nur ein UX-Feature, er ist ein Compliance-Baustein. Sechs Normen sind direkt einschlägig:
DIN 5008:2020-03. Die Norm definiert das verbindliche Layout für Geschäftsbriefe — Anschriftfeld, Faltmarken, Bezugszeichenzeile, Seitenränder. Der Brief-Renderer ist gegen diese Maße kalibriert, sodass Briefe in Standard-Fenster-Kuverts (DIN-lang, DIN-C5) ohne manuelles Nachjustieren passen.
§ 312i BGB. Im Geschäftsverkehr mit Verbrauchern müssen bestimmte Pflichtangaben in der Korrespondenz enthalten sein, wenn Verträge entstehen oder geändert werden. Der Brief-Footer zieht diese Angaben aus den Tenant-Stammdaten.
§ 14 UStG. Wenn ein Brief auf eine Rechnung verweist oder eine Mahnung mit Rechnungsbezug enthält, müssen die Pflichtangaben aus § 14 UStG eingehalten werden. Bei Mahnschreiben mit Forderungstabelle prüft das Template diese Felder vor dem Versand.
§ 257 HGB und § 147 AO. Geschäftsbriefe sind aufbewahrungspflichtig — sechs Jahre nach HGB, zehn Jahre nach AO bei steuerlich relevanten Schreiben. Drafts und versandte Briefe werden im Archiv revisionssicher abgelegt; der Markdown-Quelltext bleibt als Plain-Text-Diff durchsuchbar.
DSGVO Artikel 5 Absatz 1 Buchstabe c. Datenminimierung verlangt, dass nur die für den Zweck notwendigen personenbezogenen Daten verarbeitet werden. Der Brief enthält ausschließlich Empfänger-relevante Daten; Stamm-Datensätze werden nicht in den Brief-Body geschrieben, sondern über getrennte Felder geführt.
Zusätzlich greift § 130 BGB für den Zugangsnachweis von Willenserklärungen — relevant bei Kündigungen, Mahnungen, Mieterhöhungen. Der Zugangsnachweis wird über die Versand-Klassen der Druckdienstleister geliefert und im Vorgang dokumentiert.
Grenzen der aktuellen Lösung
Die erste Version unterstützt einen Brand pro Tenant. Wer mehrere Marken unter einem Tenant-Dach betreibt — etwa eine Verwaltung mit einer Mietverwaltung-Sparte und einer separaten WEG-Verwaltungs-Marke —, muss aktuell zwei Tenants konfigurieren oder auf das Multi-Brand-Whitelabel-Modul warten. Die Architektur ist auf Multi-Brand vorbereitet, die UI-Auswahl folgt in einer späteren Iteration.
Inline-Bilder im Markdown-Body sind nicht vorgesehen. Das Logo sitzt im Briefkopf, weitere Grafiken (etwa Pläne, Diagramme, Fotos) gehören in Anlagen, nicht in den Fließtext eines Geschäftsbriefs. Diese Entscheidung folgt der DIN 5008 und ist bewusst eng gehalten.
Echtzeit-Co-Editing — zwei Verwalter, die gleichzeitig denselben Draft bearbeiten — ist nicht implementiert. Bei paralleler Bearbeitung erkennt das System einen Konflikt, sperrt den Draft kurzzeitig und gibt den ersten Editor den Vortritt. Spell-Check im Editor läuft über die Browser-Rechtschreibprüfung; eine integrierte Sprach-Engine mit Branchen-Vokabular ist für eine spätere Version vorgesehen.
FAQ
Wieso Markdown und nicht Word?
Markdown trennt Inhalt von Darstellung, ist als Plain-Text versionssicher diffbar und entkoppelt das Tenant-Layout vom Brief-Inhalt. Word vermischt beides, und jede Korrektur kann Layout-Folgen haben. Wer Markdown nicht beherrscht, schaltet auf den WYSIWYG-Pane um — die Quelle bleibt Markdown, die Eingabe ist beliebig.
Kann ich Tabellen in den Brief einbauen?
Ja, Markdown-Tabellen werden vom Renderer in HTML-Tabellen umgesetzt, die DIN-konform formatiert und bei Seitenumbrüchen mit wiederholter Kopfzeile fortgesetzt werden. Typische Anwendung sind Forderungs-Aufstellungen in Mahnschreiben, Kosten-Aufstellungen in Wirtschaftsplan-Versendungen und Ablesewerte in Heizkosten-Korrespondenz.
Wie wird DIN 5008 genau eingehalten?
Das HTML-Template setzt die Anschrift absolut bei 45 mm vom Blattrand, die Faltmarken werden über CSS-Background bei 105 mm und 210 mm gerendert, die Bezugszeichenzeile sitzt bei 50 mm. Seitenränder folgen der Norm (links 25 mm, rechts 20 mm). Die Maße sind im Template fest verdrahtet, eine Verschiebung ist ohne Template-Änderung nicht möglich.
Was passiert, wenn der Brief auf drei Seiten geht?
Der Renderer paginiert automatisch über CSS-Page-Regeln. Seite 1 trägt den Briefkopf mit Logo, ab Seite 2 ersetzt eine schmale Kopfzeile mit Empfänger-Kürzel und Datum den vollen Briefkopf. Die Fußzeile zeigt durchgängig „Seite X von Y” mit korrektem Page-Counter. Forderungstabellen werden mit wiederholter Kopfzeile fortgesetzt.
Kann ich den Brief vor Versand ausdrucken?
Ja. Die PDF-Vorschau lässt sich direkt aus dem Editor heraus herunterladen und auf einem lokalen Drucker ausgeben. Der spätere API-Versand über Pingen oder LetterXpress rendert dasselbe PDF aus derselben Quelle — die lokale Probe-Druck-Ausgabe ist identisch mit dem versandten Brief. Damit lässt sich vor dem Massenversand stichprobenartig auf Papier prüfen.
Wo werden die Drafts gespeichert?
Drafts liegen in der Tabelle workflow_letter_drafts und sind dem auslösenden Workflow-Vorgang über eine Fremdschlüssel-Beziehung zugeordnet. Jede Editor-Speicherung erzeugt einen neuen Snapshot, sodass der Verlauf eines Briefes von der Trigger-Erzeugung bis zum Versand vollständig im Audit-Trail nachvollziehbar ist. Nach dem Versand wird der finale Stand zusammen mit der versandten PDF im Archiv abgelegt und mit der für den Vorgang einschlägigen Aufbewahrungsfrist versehen.
Verwandte Beiträge
- Mustervorlagen-Bibliothek mit 33 revisionssicheren Vorlagen — die Quelle der Templates, aus denen die Drafts entstehen.
- GenioFlow als Evolution der Immobilienverwaltung — der übergeordnete Workflow-Rahmen, in dem Drafts entstehen.
- Drei-stufiges Mahnwesen mit Verzugszinsen nach § 288 BGB — der häufigste Brief-erzeugende Workflow im Buchhaltungs-Bereich.
Wo wir stehen
Der Brief-Editor mit Markdown- und WYSIWYG-Toggle ist produktiv. Die mehrseitige Pagination über Puppeteer und CSS-Page-Regeln läuft stabil; bisher getestete Brief-Längen reichen von einseitigen Bestätigungs-Schreiben bis zu siebenseitigen Mahnschreiben mit umfangreicher Forderungs-Tabelle. Die Workflow-Drafts-Inbox ist in allen Welle-2-Workflows aktiv — Kündigungs-Prozess, Mahnwesen, Wirtschaftsplan-Genehmigung, Vermietung. Drafts werden Trigger-basiert erzeugt; die Verbindung zum auslösenden Vorgang ist über die Fremdschlüssel-Beziehung dauerhaft hergestellt.
Die Pipeline vom Workflow-State-Wechsel über den Draft, die Editor-Bearbeitung, die Live-Vorschau bis zum API-Versand und der Webhook-bestätigten Zustellung ist End-to-End ohne manuelle Übergaben abgebildet. Wer das Modul einsetzt, ersetzt den Word-Briefkopf-Workflow durch eine kohärente, versionssichere und DIN-konforme Brief-Produktion.
Kontakt
Fragen, Rückmeldungen oder eigene Erfahrungen mit dem Brief-Workflow in der Hausverwaltung? Wir freuen uns über Ihre Nachricht an kontakt@immogenio.de.