Sendungs-, Objekt- oder Projektdaten aufs Rechnungsdokument bringen, ohne die E-Rechnung zu brechen

Wir fakturieren Seefracht. Auf unseren Rechnungen stehen seit jeher Schiffsname, Reisenummer, Konnossement und der Bestimmungshafen — nicht aus Nostalgie, sondern weil die Buchhaltung unseres Kunden ohne diese Angaben nicht weiß, zu welcher Sendung die Rechnung gehört. Als wir auf ZUGFeRD umgestellt haben, war meine erste Sorge nicht die Norm, sondern genau das: Wenn EN 16931 diese Felder nicht kennt, verschwinden sie dann von der Rechnung?

Tun sie nicht. Eine ZUGFeRD-Rechnung ist ein PDF mit eingebettetem XML — zwei Ebenen, zwei Aufgaben. Das XML ist genormt und bleibt es, sonst kann die Software des Empfängers es nicht automatisch verarbeiten. Das PDF ist unser Dokument. Dieser Workflow nutzt beides: Die Abrechnungszeile kommt aus einer Tabelle, die Sendungsdaten hängen als eigenes Objekt am Payload, und im PDF-Template stehen sie als Platzhalter. Für die XML-Erzeugung wird das Objekt nicht ausgewertet — die ZUGFeRD-Daten sind exakt dieselben wie ohne.

Das lässt sich auf alles übertragen, was auf eurer Rechnung steht und in keiner Norm vorkommt: Objekt und Bauabschnitt im Handwerk, Seriennummer im Maschinenbau, Projektkürzel und Kostenstelle in der Beratung.

Zwei Dinge, die ich vor dem Import sagen würde.

Was der Empfänger maschinell braucht, gehört nicht ins Zusatzobjekt. Bestellnummer und Käuferreferenz haben in der Norm einen Platz — bei XRechnung transportiert die Käuferreferenz die Leitweg-ID. Wer solche Angaben ins Zusatzobjekt legt, hat sie auf dem Papier, aber die Software des Empfängers findet sie nicht. Und die soll ja gerade automatisch zuordnen. Faustregel: erst prüfen, ob die Norm ein Feld hat. Nur was dort keinen Platz findet und für den Menschen bestimmt ist, geht auf die Dokumentebene.

Die Rechnungsnummer wird nicht in n8n vergeben. Zwei parallele Läufe lesen denselben Höchststand aus der Tabelle und schreiben dieselbe Nummer — §14 UStG verlangt aber eine Nummer, die einmalig vergeben wird. Ein Duplikat ist ein echter Mangel, und man merkt es erst, wenn jemand systematisch draufschaut. Die Nummer kommt deshalb aus dem System, das sie transaktional vergibt, und steht in der Tabelle. Der Workflow liest sie, er erfindet sie nicht.

Ansonsten macht der Workflow das Naheliegende: Abrechnungen, Stammdaten und Positionen aus der Tabelle holen, zusammenführen, den Payload bauen, die Summen neu berechnen statt sie zu übernehmen, validieren, erzeugen, ablegen, versenden, protokollieren. Weichen die gerechneten Summen um mehr als zwei Cent von den Tabellenwerten ab, geht der Beleg in den Fehlerpfad — das fängt zuverlässig die Fälle, in denen jemand eine Position von Hand nachgetragen hat.

Die templateId steht je Kunde in den Stammdaten. Wer für Großkunden ein eigenes Layout braucht, trägt dort eine andere ein; am Workflow ändert sich nichts.

Was du brauchst

• Den Community-Node n8n-nodes-invoice-api-xhub fürs Validieren und Erzeugen — er reicht das JSON unverändert an die API weiter, es ist also keine Sonderbehandlung für das Zusatzobjekt nötig
• Einen invoice-api.xhub-API-Key
• Eine Tabelle mit drei Blättern: Abrechnungen, Positionen, Stammdaten (Käufer inklusive templateId)
• Ein PDF-Template mit einem keyvalue-Block für die Zusatzangaben — die Platzhalter-Referenz unter /docs/templates zeigt den Aufbau
• Ein Gmail-Konto zum Versenden (wer lieber SMTP nutzt, tauscht den Knoten), und auf selbst gehostetem n8n einen Ausgabeordner in N8N_RESTRICT_FILE_ACCESS_TO

Was er nicht tut

Er funktioniert nicht für reine XRechnung. Die ist eine XML-Datei, es gibt kein Dokument, auf das man etwas drucken könnte — wer an öffentliche Auftraggeber liefert, klärt vorher, ob die Angaben dort überhaupt gebraucht werden oder ob nur ein Mensch sie liest. Er versendet nicht über Peppol, die E-Rechnung geht als Mailanhang raus. Er prüft nicht auf Dubletten über Läufe hinweg — wer zweimal denselben Status setzt, bekommt zweimal eine Rechnung. Und er liest keine PDFs: Der Input ist strukturiert, das ist der Unterschied zu Template 06.

Ein Hinweis noch: Die Vorlagen sind derzeit im Beta-Status. Nutzbar und dokumentiert, aber die API kann sich noch ändern.