Rechnungen als Webentwickler stellen: Honorare, Zahlungsbedingungen und Vorlagen

Kurzfassung: Rechnen Sie pro Meilenstein ab (Design-Uebergabe, Build, QA, Go-Live), trennen Sie wiederkehrende Kosten wie Hosting und Domains von einmaligen Build-Gebuehren, listen Sie Drittanbieter-Lizenzen als Durchlaufposten auf und rechnen Sie Retainer-Wartung monatlich mit Stunden-Tracking ab.

Webentwickler rechnen oft Implementierungs-Sprints, Bugfix-Kontingente und laufende Retainer ab. Rechnungen sollten Build-Phasen von Hosting, Domains und Drittanbieter-API-Gebuehren trennen, damit Kunden wiederkehrende versus einmalige Kosten sehen. Staging-Umgebungen, Content-Migration und Analytics-Setup gehen haeufig in einer einzelnen "Build"-Position verloren -- schluesseln Sie sie auf, damit nicht-technische Stakeholder die Rechnung verstehen.

Wenn Kunden Content oder Freigaben verzoegern, sollte Ihr Vertrag Pausen-Abrechnung oder Meilenstein-Neuterminierung erlauben -- verweisen Sie bei ueberarbeiteten Rechnungen auf diese Klausel. Barrierefreiheits-Remediation und Performance-Budgets sind zunehmend Vertragsklauseln -- wenn Sie sie kalkuliert haben, spiegeln Sie sie auf dem Meilenstein wider, an dem Sie den Fix geliefert haben. Drittanbieter-Script-Audits (Tag-Manager, Chat-Widgets), die Core Web Vitals aufgeblaehen haben, verdienen ihre eigene Position, wenn Sie Tage damit verbracht haben, sie zu entwirren.

Typische Honorare

Stundensaetze fuer Support und unklaren Umfang; feste Meilensteine fuer Launches (Design-Uebergabe -> Build -> QA -> Go-Live). Wartungs-Retainer monatlich. Benchmarks schwanken; Stack Overflows Entwickler-Umfrage zeigt, wie Spezialisierung die Verdienstmoeglichkeiten beeinflusst -- als Kontext nutzen, nicht als Zitat. Retainer-Kontingente (z.B. "bis zu 6 Stunden/Monat") sollten genutzte versus uebertragene Stunden auf jeder Rechnung zeigen, um Verlaengerungen zu rechtfertigen. Notfall-Support kann 1,5-fach mit einem Mindest-Inkrement sein -- kommunizieren Sie das, bevor der Pager klingelt. Headless-CMS-Contentmodelle und Webhook-Integrationen dauern oft laenger als visuelle Seiten -- teilen Sie sie auf der Rechnung auf, damit Stakeholder sehen, wohin die Backend-Zeit geflossen ist.

Stundenabrechnung ($75-$200+ je nach Stack und Markt) funktioniert fuer Support-Tickets, Bugfixes und Retainer-Arbeit. Feste Meilensteinpreise sind Standard fuer neue Builds: Teilen Sie das Projekt in 3-5 Meilensteine mit klaren Lieferobjekten bei jedem Schritt. Monatliche Retainer ($500-$5.000+) eignen sich fuer laufende Wartung, Sicherheitsupdates und Feature-Entwicklung. Tagessaetze ($600-$1.600+) funktionieren fuer intensive Vor-Ort- oder eingebettete Team-Sprints.

Spezialisierung treibt Honorarsteigerungen. Full-Stack-Entwickler, die Frontend und Backend abdecken, verlangen mehr als Single-Stack-Spezialisten. E-Commerce-Entwickler mit Shopify Plus- oder Magento-Erfahrung koennen Premium-Projektsaetze berechnen. Barrierefreiheit (WCAG-Konformitaet), Performance-Optimierung und Headless-CMS-Expertise sind alles Honorar-Multiplikatoren. Erhoehen Sie Preise, wenn Ihre Pipeline konstant voll ist, wenn Sie eine wertvolle Zertifizierung hinzufuegen oder wenn Kundenergebnisse klaren ROI demonstrieren.

Beispiel-Rechnungspositionen

Wann die Rechnung senden

Bei meilensteinbasierten Builds stellen Sie bei jedem Meilensteinabschluss die Rechnung -- typischerweise nachdem der Kunde das Lieferobjekt geprueft und freigegeben hat (Design-Entwurf, Staging-Site, finale QA-Abnahme). Warten Sie nicht, bis das gesamte Projekt fertig ist; Fortschrittsrechnungen halten Ihren Cashflow gesund und reduzieren das Risiko auf beiden Seiten.

Bei Wartungs-Retainern stellen Sie am Ersten jedes Monats die Rechnung. Fuegen Sie eine Zusammenfassung der geleisteten Arbeit hinzu (geschlossene Tickets, durchgefuehrte Updates, genutzte vs. verbleibende Stunden), damit der Kunde den Wert sieht und den Retainer nicht als vergessenes Abonnement behandelt.

Fuer Hosting, Domains und Drittanbieter-Verlaengerungen stellen Sie bei Faelligkeit die Rechnung. Jaehrliche Verlaengerungen in einer einzigen Rechnung mit klaren Beschreibungen zu buendeln ("Domain-Verlaengerung -- clientsite.com, 1 Jahr") verhindert, dass Kunden Zahlungen verpassen, die ihre Website offline nehmen koennten.

Zahlungsbedingungen

Anzahlung (30%-50%) vor schwerem Build, Fortschrittsrechnungen pro Meilenstein, Schlusszahlung vor DNS-Umstellung oder innerhalb von Net 14 nach Launch gemaess Vereinbarung. Net 30 fuer groessere Kunden mit guter Bonitaet. Dokumentieren Sie Ausserhalb-des-Umfangs-Arbeit als separate Positionen. Fuer Faelligkeitsformulierungen nutzen Sie Zahlungsbedingungen fuer Rechnungen. Agentur-Durchlauf-Arbeit benoetigt manchmal Kundenname + Muttermarke im Rechnungskopf fuer AP-Zuordnung -- fragen Sie Ihren PM-Kontakt.

Was enthalten sein sollte

Projekt- oder Ticketreferenz, Beschreibung pro Meilenstein (gelieferte Features, Umgebungen), Stunden und Satz bei Stundenabrechnung, Lizenzen und Durchlaufposten (Hosting, Plugins), Support-Fenster falls Post-Launch-Paket verkauft, Steuer, Gesamtbetrag, Faelligkeitsdatum. Nutzen Sie wie man eine Rechnung schreibt fuer Nummerierung und Geschaeftsangaben. Barrierefreiheits-Fixes ueber das urspruengliche WCAG-Ziel hinaus sollten auf das Change-Ticket oder die Audit-Finding-ID verweisen, damit das Produktteam versteht, warum die Stunden gestiegen sind. Content-Eingabe, die Sie fuer den Kunden durchgefuehrt haben, gehoert auf eine eigene Position, wenn sie nicht Teil des Build-Kostenvoranschlags war.

Haeufige Fehler

Hosting in Dev-Gebuehren buendeln ohne Verlaengerungsdatum -- Kunden vergessen zu zahlen. "Bugfix"-Mehrdeutigkeit -- definieren Sie Schweregrade oder SLAs im Vertrag und fassen Sie auf der Rechnung zusammen. Keine Kill-Fee-Klausel fuer abgebrochene Builds -- regeln Sie das in der Vereinbarung und spiegeln Sie Teilrechnungen wider. Drittanbieter-API-Keys auf Ihrer Kreditkarte ohne Weiterbelastung -- transparent durchreichen oder aufschlagen. SEO oder Analytics-Tag-Implementierung versteckt in "Launch", obwohl es die Haelfte des Sprints war. Einzelwaehrung angenommen fuer verteilte Teams -- geben Sie USD/GBP/EUR ausdruecklich an. Cookie-Consent oder CMP-Implementierungen als "kleine JS-Aufgaben" behandelt, obwohl sie mehrsprintige Compliance-Arbeit waren -- teilen Sie rechtlich getriebene Arbeit auf der Rechnung auf, damit Datenschutzteams den Aufwand erkennen.

Hosting-Verlaengerung nicht von Build-Gebuehren trennen -- wenn Hosting im Projekttotal vergraben ist, vergessen Kunden nach dem Launch zu zahlen und geben Ihnen die Schuld, wenn die Seite offline geht. Content-Eingabezeit nicht erfassen, wenn der Kunde Sie bat, Seiten zu befuellen -- 50 Produktbeschreibungen einzugeben ist nicht "Teil des Builds", es sei denn, Ihr Kostenvoranschlag sagte das. Offene "Bugfix"-Positionen ohne Schweregrad oder Zeitlimit -- definieren Sie, was als Bug (Ihr Code) versus Feature-Request (neuer Umfang) zaehlt, im Vertrag und spiegeln Sie diese Unterscheidung auf der Rechnung wider.

FAQ

Sollte ich Hosting separat abrechnen oder in meinen Retainer einschliessen? Rechnen Sie Hosting als separaten Durchlaufposten ab, auch wenn Sie das Konto verwalten. Das macht die Kosten transparent, vermeidet den Anschein eines Aufschlags auf eine Commodity und stellt sicher, dass der Kunde versteht, dass Hosting laufende Kosten sind, die von Ihren Entwicklungsleistungen getrennt sind. Wenn Sie Hosting aufschlagen (ueblich bei Managed Hosting, bei dem Sie die Serverwartung uebernehmen), legen Sie das offen.

Wie gehe ich mit Scope-Aenderungen bei einem Festpreisprojekt um? Erstellen Sie einen Change-Order, bevor Sie die zusaetzliche Arbeit ausfuehren. Listen Sie auf der Rechnung Original-Scope-Meilensteine und Change-Order-Positionen in separaten Abschnitten auf. Verweisen Sie auf die CO-Nummer und das Freigabedatum. Das schuetzt Sie vor "Ich dachte, das war inklusive"-Streitigkeiten und gibt dem Kunden eine klare Finanzaufzeichnung, wie sich das Projekt entwickelt hat.

Wie rechne ich einen Retainer am besten ab, wenn die Stunden von Monat zu Monat variieren? Zeigen Sie das Retainer-Honorar, enthaltene Stunden, genutzte Stunden und eine kurze Aufgabenzusammenfassung. Wenn Uebertrag Teil Ihrer Vereinbarung ist, zeigen Sie den Saldo. Wenn der Kunde weniger Stunden genutzt hat, bleibt das Retainer-Honorar gleich (das ist der Sinn eines Retainers). Wenn sie die enthaltenen Stunden ueberschreiten, fuegen Sie einen Mehrstundenabschnitt zu Ihrem Stundensatz hinzu.

Vorlagen-Link

Starten Sie mit unserer Webdesign-Rechnungsvorlage fuer eine meilensteinfreundliche Struktur (Design- plus Entwicklungsphasen).

---

Fruehzugang sichern, um Webprojekt-Rechnungen schneller zu erstellen.