Zum Inhalt springen

Guide · Go

ZUGFeRD-E-Rechnung erstellen mit Go

Zwischen Unternehmen in Deutschland muss seit 2025 jedes Unternehmen E-Rechnungen empfangen können; ausstellen müssen sie ab 2027 Unternehmen mit mehr als 800.000 € Umsatz im Vorjahr und ab 2028 alle, mit Ausnahmen wie Rechnungen bis 250 €. Dieses Go-Programm sendet eine Rechnung als JSON und erhält eine ZUGFeRD- bzw. Factur-X-Datei zurück: das PDF, das Menschen lesen, mit dem XML darin, das die Buchhaltungssoftware liest, beides aus denselben Daten und geprüft, bevor Sie die Datei bekommen.

Kostenloser Plan mit 100 Einheiten im Monat, keine Kreditkarte

Was Sie brauchen

  • Einen API-Key. Legen Sie ihn in der App unter API-Schlüssel an und exportieren Sie ihn als FORMFEED_API_KEY. Zum Ausprobieren ist ein Test-Key (ff_test_…) richtig. Siehe Quickstart.
  • Go. Sie brauchen Go 1.21 oder neuer; das Programm nutzt nur die Standardbibliothek.
  • Die Vorlage. e-rechnung aus dem E-Rechnungs-Beispiel: Kopieren Sie es von der Seite des Beispiels in Ihren Workspace, oder pushen Sie den Ordner mit der CLI (formfeed templates push --publish). Jede Rechnungsvorlage funktioniert genauso, sobald ihre Daten einen _invoice-Block haben.
  • Die Daten. Die data.json des Beispiels neben dem Programm: ein _invoice-Block mit Verkäufer, Käufer, Positionen, der Aufschlüsselung der Umsatzsteuer und den Summen, benannt wie in der europäischen Norm EN 16931.
  • Ein Plan mit E-Rechnungen. Live-E-Rechnungen setzen den Starter-Plan oder höher voraus. Mit einem Test-Schlüssel (ff_test_…) erzeugt jeder Plan Test-E-Rechnungen mit Testmarkierung auf der Seite, der Free-Plan bis zu 20 pro Tag.

Das Programm

Das Programm liest data.json, sendet sie mit dem Namen der Vorlage und post.einvoice, wartet auf das Ergebnis, wenn die API mit 202 antwortet, bricht mit der Meldung der API ab, wenn etwas nicht stimmt, und speichert die E-Rechnung.

main.goGo
package main

import (
	"bytes"
	"encoding/json"
	"fmt"
	"io"
	"net/http"
	"os"
	"time"
)

const endpoint = "https://api-eu.formfeed.dev/v1/renders"

// a render or a problem document: both are JSON objects, so one struct decodes either
type render struct {
	ID          string  `json:"id"`
	Status      string  `json:"status"`
	DownloadURL string  `json:"download_url"`
	PageCount   int     `json:"page_count"`
	Units       float64 `json:"units"`
	Title       string  `json:"title"`
	Detail      string  `json:"detail"`
}

// send makes one call with the key and decodes the answer
func send(method, url string, body []byte) (int, render) {
	request, _ := http.NewRequest(method, url, bytes.NewReader(body))
	request.Header.Set("Authorization", "Bearer "+os.Getenv("FORMFEED_API_KEY"))
	request.Header.Set("Content-Type", "application/json")
	response, err := http.DefaultClient.Do(request)
	if err != nil {
		panic(err)
	}
	defer response.Body.Close()
	var answer render
	json.NewDecoder(response.Body).Decode(&answer)
	return response.StatusCode, answer
}

func main() {
	data, err := os.ReadFile("data.json")
	if err != nil {
		panic(err)
	}
	body, _ := json.Marshal(map[string]any{
		"template": "e-rechnung",
		"data":     json.RawMessage(data),
		"post": map[string]any{
			"einvoice": map[string]any{"profile": "en16931"},
		},
	})

	status, result := send("POST", endpoint, body)
	// not done within 60 seconds: the answer is 202 and the render goes on in the background;
	// its result answers the same way until the render has finished
	for status == http.StatusAccepted {
		time.Sleep(2 * time.Second)
		status, result = send("GET", endpoint+"/"+result.ID+"/result", nil)
	}
	// every error is a problem document (RFC 9457) with a title and a detail
	if status >= 400 {
		fmt.Fprintf(os.Stderr, "%s: %s\n", result.Title, result.Detail)
		os.Exit(1)
	}

	file, err := http.Get(result.DownloadURL)
	if err != nil {
		panic(err)
	}
	defer file.Body.Close()
	out, _ := os.Create("e-invoice.pdf")
	defer out.Close()
	io.Copy(out, file.Body)
	fmt.Printf("%s %d page(s), %v unit(s)\n", result.ID, result.PageCount, result.Units)
}

Ausführen

Es gibt die ID des Renderings, die Seitenzahl und die verbrauchten Einheiten aus (mit einem Live-Schlüssel eine mehr als dasselbe PDF ohne XML), und e-invoice.pdf liegt neben dem Programm. Ein PDF-Viewer zeigt die Rechnung, seine Anhänge zeigen die factur-x.xml darin. Mit einem Test-Schlüssel wird das Rendering nicht gezählt, und jede Test-E-Rechnung trägt eine Testmarkierung, in jedem Plan.

Shell
export FORMFEED_API_KEY=ff_test_...
go run main.go

Was an Go besonders ist

  • json.RawMessage. Die Beispieldaten gehen so in den Body, wie sie auf der Platte liegen, ohne vorher in Go-Typen dekodiert zu werden; das Programm funktioniert deshalb für jede Vorlage.
  • Ein Struct für beide Antworten. Ein Rendering und ein Problem-Dokument sind beide JSON-Objekte, ein einziges Struct mit title und detail neben den Render-Feldern dekodiert also beides.
  • Timeouts. http.DefaultClient hat keinen. Geben Sie dem Client in einem Dienst einen Timeout etwas über 60 Sekunden: Ein synchrones Rendering antwortet, wenn die Datei fertig ist, oder nach 60 Sekunden mit 202, während es im Hintergrund weiterläuft.

Was das PDF zur E-Rechnung macht

  • post.einvoice. macht aus dem PDF ein PDF/A-3, das die Rechnung als factur-x.xml trägt. Die Beispielvorlage erklärt dasselbe in ihrer settings.json, für sie ist die Zeile also optional; für Ihre eigene Rechnungsvorlage ist sie der eine Schalter.
  • Der _invoice-Block. Verkäufer, Käufer, Positionen, Aufschlüsselung der Umsatzsteuer und Summen, benannt wie in der Norm; Einheiten und Steuerkategorien sind Codes (HUR, S). Die Vorlage druckt die Seite aus demselben Block, Seite und XML können also nichts Verschiedenes sagen.
  • Die Prüfung. Bevor die Datei ausgeliefert wird, wird das XML gegen die Regeln der EN 16931 und das PDF gegen PDF/A-3b geprüft. Der Bericht steht in einvoice.validation des Renderings, und ein Wert, den die Seite nicht zeigt, steht in einvoice.display.missing.
  • ZUGFeRD oder Factur-X. Eine Spezifikation unter zwei Namen, und dieselbe Datei. flavour entscheidet nur, welchen Namen und welches Release das Rendering meldet: ZUGFeRD 2.5 oder Factur-X 1.09.

Wenn die Daten nicht stimmen

Ein Block, der eine Regel verletzt, lässt die Anfrage mit 422 einvoice_data_invalid scheitern, bevor etwas gerendert oder gezählt wird. Das Problem nennt jeden Befund mit seiner Stelle in den Daten und der verletzten Regel (BR-CO-15, …), und das Programm gibt Titel und Detail aus. Eine Datei, die die Prüfung nicht besteht, wird nie ausgeliefert und nie durch ein einfaches PDF ersetzt.

Was bei Ihnen bleibt

Formfeed erzeugt und prüft die Datei. Den Versand an Ihren Kunden, die Archivierung und die umsatzsteuerliche Behandlung der Rechnung übernehmen Sie. Wann eine E-Rechnung Pflicht ist, mit den amtlichen Quellen, steht auf der Seite zur E-Rechnung; Felder und Regeln stehen in der Dokumentation zur E-Rechnung.

Wenn die API nein sagt

  • Eine Form für jeden Fehler. Fehler sind Problem-Dokumente (RFC 9457) mit type, title, status, detail, einem stabilen code und der request_id, die Sie dem Support nennen; die type-URL führt zu einer Seite über diesen Fehler. Die Liste steht in der Fehlerreferenz.
  • Die üblichen. 401 unauthorized bei fehlendem oder widerrufenem Schlüssel, 404 template_not_found bei falschem Vorlagennamen, 422 template_runtime_error, wenn die Vorlage an den Daten scheitert, 429 rate_limited über den Anfragen pro Sekunde des Tarifs, 402 quota_exceeded, wenn die Einheiten des Free-Tarifs verbraucht sind (ein bezahlter Tarif rechnet weitere Einheiten ab, bis zu seiner Obergrenze).
  • Sicher wiederholen. Senden Sie beim POST einen Idempotency-Key-Header und wiederholen Sie die Anfrage mit demselben Schlüssel, wenn Sie nicht wissen, ob der erste Versuch ankam: 24 Stunden lang liefert der Schlüssel die erste Antwort, statt erneut zu rendern und zu berechnen. Gespeichert wird die Antwort, sobald der erste Versuch beantwortet ist; wiederholen Sie also nicht, solange er noch laufen kann. Auch Probleme unter 500 werden gespeichert, eine korrigierte Anfrage braucht deshalb einen neuen Schlüssel.

Die Aufgabe um dieses Programm

Dieser Guide ist ein Programm. Was die Aufgabe darum herum braucht, von der Vorlage bis zu Limits und Preis, steht auf der Seite Rechnungs-PDF-API.

Weitere Guides für Go

FAQ

Welches Profil soll ich wählen?
en16931, die Voreinstellung, trägt jedes Feld der europäischen Norm; basic ist das kleinste Profil, das für sich allein eine Rechnung ist. Jedes andere Profil wird mit einvoice_profile_unsupported beantwortet.
Erzeugt Formfeed XRechnung?
Nein. Formfeed schreibt ZUGFeRD bzw. Factur-X: das XML in einem PDF/A-3. XRechnung und UBL gibt es nicht.
Was kostet eine E-Rechnung?
Eine Einheit zusätzlich zu ihrem Rendering, eine einseitige E-Rechnung kostet also zwei Einheiten. Live-E-Rechnungen setzen den Starter-Plan oder höher voraus; im Free-Plan erzeugen Test-Renderings bis zu 20 pro Tag. Siehe Preise.
Bekomme ich das XML als eigene Datei?
xml: "both" in post.einvoice speichert das XML zusätzlich neben dem PDF, und das Rendering verlinkt es als einvoice.xml_url. Im PDF steckt es so oder so.

ZUGFeRD-E-Rechnung in anderen Sprachen

Heute mit dem Rendern beginnen

Der kostenlose Plan enthält 100 Einheiten im Monat und kostenlose Testrenderings. Wechseln Sie den Plan, wenn Sie mehr brauchen.