Dokumentengenerierung als Feature — nicht als Infrastrukturproblem

Wer hier gemeint ist

Produkt- und Engineering-Teams, die B2B-SaaS bauen und an einem Punkt ankommen, an dem Dokumente Teil des Produkts werden müssen: Rechnungs-PDFs an die Endkunden, Verträge aus Template-Daten, Monats­reports als druckbare Version, exportierbare Formulare.

Typische Situationen:

• Serie A/B: erste zahlungspflichtige Kunden → Rechnungs­ausgabe muss professionell sein
• Enterprise-Deal in Sicht: der Kunde verlangt SSO, SAML, und ein druckbares Angebot auf seinem Briefpapier
• Compliance-Anforderung: Kunden im EU-Raum brauchen E-Rechnungen (XRechnung/ZUGFeRD) ab 2025
• Wachstums­schmerz: die aktuelle wkhtmltopdf-Lösung bricht unter Last, Fonts verschwinden, PDFs werden inkonsistent

Typische Pain Points

1. Eigenes Chrome zu betreiben kostet mehr, als man denkt — OOM-Kills, Font-Management, Timeouts, Release-Zyklen
2. Template-Editoren bremsen das Produktteam — jedes Kunden-spezifische Layout wird zum Ticket für Engineering
3. Mehrsprachigkeit und i18n in PDFs ist aufwändig — Umlaute, RTL, Datumsformate
4. E-Rechnungs-Pflicht 2025/2027 landet auf dem Backlog — XRechnung und ZUGFeRD werden zu eigenständigen Stories
5. Digitale Signaturen (PAdES, PKCS#12) will niemand selbst implementieren

Vier typische Einsatz-Szenarien

1. Rechnung auf Kunden-Briefpapier

Deine Plattform wickelt Abrechnungen für Kunden ab. Jeder Kunde hat ein eigenes Briefpapier als PDF hochgeladen. Beim Monats­billing soll die fertige Rechnung exakt auf diesem Briefpapier erscheinen:

curl -X POST https://api.dokmatiq.com/v1/docgen/render \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -d '{
    "stationery": { "firstPage": "<base64-pdf>", "subsequentPages": "<base64-pdf>" },
    "contentAreas": [
      { "x": 20, "y": 50, "width": 80, "html": "<p>An<br>Beispiel GmbH<br>Musterstraße 1<br>12345 Berlin</p>" },
      { "x": 20, "y": 90, "html": "<h1>Rechnung 2026-0042</h1>" },
      { "x": 20, "y": 120, "html": "<table>...</table>" }
    ],
    "outputProfile": "PDF/A-3b"
  }' -o rechnung.pdf

Kein Template-Editor, kein HTML-Nachbau — das Original-Briefpapier wird einfach „bedruckt”.

2. Vertragsausgabe mit Platzhalter-Ersetzung

Deine Nutzer pflegen Verträge als .docx-Vorlagen im Team. Beim Abschluss sollen die Kunden­daten automatisch eingesetzt und das Ergebnis als signiertes PDF ausgegeben werden:

curl -X POST https://api.dokmatiq.com/v1/convert/word-to-pdf \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -F "document=@vertrag-template.docx" \
  -F 'variables={"kundenname":"ACME","beginn":"2026-05-01","summe":"€ 12.500"}' \
  -F "outputProfile=PDF/A-3b" | \
curl -X POST https://api.dokmatiq.com/v1/pdf/sign \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -F "document=@-" \
  -F "certificate=@signatur.p12" \
  -F "passphrase=$P12_PASS" \
  -F "profile=PAdES-B-LT" \
  -o vertrag-signiert.pdf

Zwei Calls: Konvertierung mit Platzhalter­ersetzung, dann PAdES-Langzeit-Signatur. Beides stateless, beides in Sekunden.

3. E-Rechnung direkt aus den Abrechnungs­daten

Deine Rechnungs-Logik bleibt in deinem Code; der Transport nach ZUGFeRD oder XRechnung läuft über einen API-Call:

curl -X POST https://api.dokmatiq.com/v1/einvoice/zugferd \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -d '{
    "profile": "EN16931",
    "invoice": { "id": "2026-0042", "issueDate": "2026-04-18", "seller": {...}, "buyer": {...}, "lines": [...] }
  }' -o rechnung-zugferd.pdf

Ein einziger Endpoint, ein fertiges ZUGFeRD-PDF/A-3 mit eingebettetem CII-XML. Deine Datenbank bleibt die Quelle der Wahrheit.

4. Monats-Report mit Daten aus dem BI-Tool

Dein BI-Tool erzeugt HTML oder Markdown mit Kunden­metriken. Daraus wird ein PDF für den Kunden:

curl -X POST https://api.dokmatiq.com/v1/convert/markdown-to-pdf \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -d '{
    "markdown": "# Monatsreport April 2026\n\n## KPIs\n...",
    "theme": "stationery",
    "stationery": { "firstPage": "<base64-pdf>" }
  }' -o report.pdf

Kein eigener Template-Generator. Der Content lebt im BI-Tool oder in deinem CMS, die API kümmert sich um das Layout.

Welche Features besonders relevant sind

• Dokumentgenerierung — das Kern-Feature: Briefpapier + Content-Areas
• PDF-Werkzeuge — Merge, Split, Passwort­schutz, Watermarks
• Digitale Signaturen — PAdES-Langzeit­signaturen per API
• E-Rechnungen — ZUGFeRD, XRechnung, Peppol BIS

SDKs und Integration

Dokmatiq bietet SDKs für Python, TypeScript, Java, PHP und C#. Alle gegen die gleiche OpenAPI-Spec generiert — also deterministisch, typed, und mit dem Tooling deines Ökosystems (pytest-Fixtures, Jest-Mocks, etc.). Jeder Call ist idempotent via Idempotency-Key, retry-safe und mit strukturierten Fehlern.

Preis-Modell

• Free-Tier: 100 Dokumente/Monat — reicht für Development, Staging, erste Piloten
• Pay-per-Use ab da: konsolidierte Abrechnung pro Team, Stripe-Billing, keine Stufensprünge
• Enterprise: eigener Rate-Limit-Bucket, SLA, Self-Hosting-Option per Docker-Container

Typisches Konsum­profil: Ein B2B-SaaS mit ~500 zahlenden Kunden, monatlicher Rechnungs­lauf + gelegentliche Verträge = ~5.000–10.000 Dokumente/Monat.

Wann Dokmatiq nicht die beste Wahl ist

• Rein HTML-Rendering ohne Briefpapier-Logik — wenn du nur HTML zu PDF willst und Stil/Layout selbst im HTML definierst, reicht oft ein einfacherer Dienst
• Massenversand an Endkunden mit komplexer Template-Verwaltung — Dienste wie Docmosis oder DocRaptor haben breitere Template-Editoren für Nicht-Entwickler
• Ad-hoc-Dokumente ohne wiederkehrende Struktur — bei Einmal-Generierung lohnt sich Pandoc lokal

Ehrlichkeit hilft beiden Seiten: Dokmatiq glänzt bei wiederkehrender, daten­getriebener Dokumenten­erzeugung mit Anspruch an Layout-Qualität und Compliance.

Häufige Stolpersteine

1. Briefpapier im falschen Format — gerade frisch aus Illustrator exportiert, oft RGB statt CMYK; DocGen akzeptiert beides, aber Drucker­ausgabe kann abweichen
2. Content-Areas in mm statt Pixel — Positionen sind immer millimeter­genau; Umrechnung aus Pixel ist Pflicht
3. Idempotency-Key nicht gesetzt — bei Retry-Logik unverzichtbar, sonst potentiell doppelte Dokumente
4. Font-Embedding-Edge-Cases — Emoji und chinesische Zeichen brauchen ggf. eigene Font-Registrierung