WooCommerce-Bestellung → XRechnung → an den Käufer mailen, Bestellung vermerken

Mein Shop verkauft Laborverbrauchsmaterial — Pipettenspitzen, Reagenzflaschen, Filterpapiere — überwiegend an Universitätsinstitute, Kliniken und gelegentlich eine Forschungsstiftung. Alle öffentlich finanziert, und seit Anfang 2025 haben deren Beschaffungsstellen unsere Auftragsbestätigungs-Mails zurückgeschickt, weil eine einfache PDF keine konforme E-Rechnung mehr ist. Die Support-Tickets haben sich gestapelt. Mit diesem Workflow habe ich sie abgearbeitet.

Jede neue WooCommerce-Bestellung triggert den Flow. Ein Code-Knoten mappt die Bestellung — Positionen, Rechnungsadresse, Währung, Summen — in das JSON, das invoice-api.xhub erwartet, die API generiert die XRechnung-XML, Gmail hängt sie an eine kurze Mail an die Rechnungs-E-Mail, und eine interne Notiz wird an die WooCommerce-Bestellung angehängt, damit mein zukünftiges Ich weiß, dass die XRechnung rausging.

Die einmalige Config liegt in Set Config: dein Firmenname, USt-ID, Rechnungsmail, Straße, Stadt, PLZ, Land und der Default-Steuersatz. Ich habe vatRate auf 19 gelassen, weil das den Großteil meines Katalogs abdeckt — siehe Limitations weiter unten, wenn deiner gemischt ist.

WooCommerce anbinden

Du brauchst die REST-API-Credentials aus dem Shop (WooCommerce → Settings → Advanced → REST API, Consumer Key / Secret). Read-Access reicht: dieser Workflow liest die Bestellung nur fürs Mapping, und die Bestätigungs-Notiz wird über den n8n-WooCommerce-Knoten geschrieben, nicht über einen Raw-API-Call.

Limitations

Ein Steuersatz pro Bestellung. Wenn dein Katalog 7 % und 19 % mischt — Bücher, Lebensmittel, Druckerzeugnisse — plättet dieses Template sie auf einen Satz, was für eine saubere XRechnung falsch ist. Der Fix ist klein (leite vatRate pro Position ab statt aus Set Config), aber ich hab ihn nicht gebraucht und deshalb nicht gebaut. Ermäßigte Sätze und Reverse-Charge-Szenarien sind auch nicht modelliert; die wollen sowieso meist einen Menschen im Loop.