Auftragsabwicklung automatisieren: vom Auftragseingang bis zur Rechnung mit n8n

n8n kann einen Auftrag vom Eingang bis zur Rechnung automatisch durchlaufen lassen – Auftragsbestätigung senden, Lagerbestand buchen, Rechnungsdaten übergeben – aber nur für Aufträge, bei denen Bestand, Preis, Kunde und Menge beim Eingang bereits feststehen. Ob eine Auftragsart das erfüllt, entscheidet nicht die Technik, sondern eine Festlegung, die Sie einmal pro Auftragsart treffen und nicht im Einzelfall dem Workflow überlassen.

Der Ablauf in vier Schritten

1. Auftragseingang. Kommt die Bestellung aus einem Webshop, gibt es dafür eigene Trigger-Nodes: Der WooCommerce-Trigger kennt eigene Ereignisse je Ressource – unter anderem order.created, order.updated und order.deleted – und löst den Workflow direkt bei einer neuen Bestellung aus. Für Shopify existiert ebenfalls ein eigener Trigger-Node; die Dokumentation verweist für die Authentifizierung auf eine separate Credentials-Seite; eine Liste der auslösenden Ereignisse nennt aber weder die Node- noch die Credentials-Seite.

Kommt der Auftrag stattdessen als E-Mail oder als Datei, sieht der erste Schritt anders aus, und das lohnt sich zu wissen, bevor Sie ihn bauen. Der IMAP-E-Mail-Node holt neue Nachrichten aus einem Postfach, aber er parst den Bestelltext nicht und markiert eine Mail auch nicht als „bereits verarbeitet“ – beides müssen Sie selbst im Workflow lösen, etwa über eine eigene Markierung im CRM oder einen separaten Ordner für erledigte Mails. Anhänge lädt der Node nur, wenn Sie „Download Attachments“ aktivieren, weil das den Rechenaufwand erhöht. Liegt der Auftrag stattdessen als strukturierte Datei vor, etwa eine EDI- oder CSV-Datei in einem Übergabeordner, übernimmt ein Local-File-Trigger-Node den Einstieg, sobald dort eine neue Datei erscheint – mit zwei Einschränkungen: Der Node läuft nur bei selbst gehostetem n8n, und seit n8n 2.0 ist er standardmäßig deaktiviert, weil er in Umgebungen mit nicht vertrauenswürdigen Nutzern ein Sicherheitsrisiko darstellt.

2. Prüfung. Ein HTTP-Request-Node fragt das Warenwirtschafts- oder ERP-System über dessen REST-API ab: Ist der Artikel auf Lager, entspricht die Menge dem Posten in der Bestellung, stimmt der Preis mit der Preisliste überein? n8n empfiehlt dafür, wo ein vordefinierter Credential-Typ für den jeweiligen Dienst existiert, diesen statt generischer Zugangsdaten zu nutzen. Liefert die Abfrage sehr viele Positionen zurück, regelt einer von drei Pagination-Modi, ob und wie der Node weitere Seiten nachlädt.

3. Entscheidung. Hier verzweigt der Workflow: Ein If-Node reicht für eine einzelne Ja/Nein-Frage („Ist alles vollständig?“) mit den zwei Ausgängen wahr und falsch. Sobald mehr als zwei Wege möglich sind – etwa „automatisch“, „Freigabe nötig“ und „Rückfrage beim Kunden“ –, braucht es den Switch-Node, der laut Dokumentation genau für diesen Fall gedacht ist.

4. Ausgang. Bei vollständigen Daten: Auftragsbestätigung per E-Mail, Lagerbuchung im ERP, Übergabe der Rechnungsdaten an die Buchhaltung. Läuft diese Übergabe über DATEV, zeigt unser Beitrag zur DATEV-Anbindung die drei realistischen Wege dafür.

Die Bruchstelle, die niemand bemerkt

Der verwundbarste Punkt in diesem Ablauf liegt nicht im Trigger oder in der ERP-Abfrage, sondern in Schritt 3. Beim Switch-Node heißt die entscheidende Einstellung „Fallback Output“ – sie legt fest, was mit einem Auftrag passiert, der zu keiner der definierten Regeln passt. Drei Optionen stehen zur Wahl: „None“ ignoriert das Item, „Extra Output“ schickt es an einen eigenen Ausgang, „Output 0“ behandelt es wie einen Treffer der ersten Regel. Der Standardwert ist „None“.

Das bedeutet: Ein Auftrag, der in keine der vorgesehenen Kategorien passt – ein neuer Artikel ohne Preislisten-Eintrag, ein Kunde mit ungewöhnlicher Zahlungsart, eine Teillieferung, an die beim Bau des Workflows niemand gedacht hat – wird laut Dokumentation ignoriert – das ist das dokumentierte Standardverhalten des Switch-Nodes. Er verschwindet kommentarlos aus dem Workflow, statt an einen Menschen zu gehen. Für einen Reporting-Workflow ist das ein stiller Datenfehler. Für einen Auftrag ist es eine Bestellung, die der Kunde aufgegeben hat und die bei Ihnen nie ankommt.

Wer eine Auftragsabwicklung mit Switch-Logik baut, stellt „Fallback Output“ deshalb bewusst auf „Extra Output“ und verbindet diesen Ausgang mit einer Benachrichtigung an einen Menschen – nicht, weil das selten vorkommt, sondern weil genau diese Fälle die sind, die eine Freigabe am dringendsten brauchen.

Entscheidungsmatrix: welche Aufträge automatisch laufen dürfen

Die Matrix setzt nicht an der Frage an, was sich technisch verbinden lässt – das lässt sich fast alles –, sondern daran, ob die Entscheidungsgrundlage für eine Auftragsart vollständig vorliegt, bevor ein Mensch sie prüfen müsste:

Kriterium	Automatisch, wenn …	Freigabe nötig, wenn …
Bestand	Artikel ist Standardsortiment, Lagerbestand reicht für die Menge	Sonderanfertigung, Bestand reicht nicht, Artikel ist neu im System
Preis	entspricht der aktuellen Preisliste ohne Abweichung	Rabatt außerhalb der Preisliste, individuell verhandelter Preis
Kunde	bekannter Kunde, Zahlungsbedingungen bereits geklärt	Neukunde ohne Bonitätsprüfung, geänderte Zahlungsbedingungen
Menge	liegt im üblichen Bestellrahmen des Kunden	deutlich über dem bisherigen Bestellmuster

Trifft eine Auftragsart alle vier Punkte verlässlich zu, darf sie den vollen Weg automatisch durchlaufen. Trifft auch nur ein Punkt regelmäßig nicht zu, bekommt diese Auftragsart einen Freigabeschritt vor der Auftragsbestätigung – fest zugeordnet für die ganze Auftragsart, nicht im Einzelfall durch den Workflow entschieden. Diese Festlegung treffen Sie einmal je Auftragsart; der Workflow wendet sie an, er trifft sie nicht selbst.

Für den Mittelstand heißt das

Fangen Sie mit dem Schritt an, dessen Daten bereits saubere Entscheidungsgrundlagen haben. Prüfen Sie dafür zuerst, ob Preisliste und Lagerbestand in Ihrem ERP bereits gepflegt sind – dann eignen sich Auftragseingang und Bestandsprüfung als erster automatisierter Schritt; fehlen diese Daten noch, ist genau das Ihr erster Schritt, nicht die Automatisierung. Die Rechnungsstellung automatisch laufen zu lassen, bevor die Bestandsprüfung zuverlässig ist, verlagert das Risiko nur eine Stufe weiter: Dann geht zwar die Auftragsbestätigung richtig raus, aber die Rechnung weicht vom tatsächlich gelieferten Umfang ab. Und richten Sie den Fallback-Pfad für Ausnahmen ein, bevor der erste reguläre Auftrag durch den Workflow läuft – nicht danach, wenn der erste verschwundene Auftrag schon beim Kunden für Nachfragen gesorgt hat.

Mehr zum Gesamtbild: der Fünf-Schritte-Fahrplan für n8n im Mittelstand ordnet die Auftragsabwicklung neben andere Automatisierungsschritte ein. Vorgelagert dazu: wie n8n bereits Angebote und Follow-ups aus CRM-Daten erstellt, bevor aus dem Angebot ein Auftrag wird.

FAQ

Welche Aufträge kann n8n automatisch von der Bestellung bis zur Rechnung durchlaufen lassen?

Aufträge, bei denen beim Eingang bereits vier Dinge feststehen: der Bestand reicht für den bestellten Artikel, der Preis entspricht der Preisliste ohne Abweichung, der Kunde ist bekannt mit geklärten Zahlungsbedingungen, und die Menge liegt im üblichen Bestellrahmen. Fehlt eines davon – Sonderanfertigung, Rabatt außerhalb der Preisliste, Neukunde ohne Bonitätsprüfung, ungewöhnlich große Menge –, braucht der Auftrag vor dem nächsten Schritt eine Freigabe durch einen Menschen, nicht noch eine Automatisierungsstufe.

Was passiert mit einem Auftrag, der zu keiner der definierten Regeln passt?

Das kommt auf die Einstellung an, und die Standardeinstellung ist riskant: Beim Switch-Node heißt die Option „Fallback Output“, und ihr Standardwert „None“ bedeutet laut n8n-Dokumentation, dass ein nicht passendes Item ignoriert wird – das ist das dokumentierte Standardverhalten. Ein Auftrag, der in keine der vordefinierten Kategorien fällt, verschwindet dann kommentarlos aus dem Workflow, statt an einen Menschen zu gehen. Erst die Option „Extra Output“ schickt solche Fälle an einen eigenen, überwachten Ausgang.

Kann n8n die Rechnung direkt als PDF erzeugen?

Nicht mit einem eingebauten Node. Der Convert-to-File-Node wandelt Daten in zehn Formate um – CSV, HTML, ICS, JSON, ODS, RTF, Text File, XLS, XLSX und eine Base64-String-Konvertierung –, PDF gehört nicht dazu. Für eine PDF-Rechnung braucht es entweder einen Community-Node eines Drittanbieters oder die Übergabe der Rechnungsdaten an ein System, das die PDF-Erstellung selbst übernimmt.

Wie prüft der Workflow, ob genug Lagerbestand für einen Auftrag vorhanden ist?

Über einen HTTP-Request-Node, der die REST-API des Warenwirtschafts- oder ERP-Systems abfragt. n8n empfiehlt dafür, wo verfügbar, den vordefinierten Credential-Typ für den jeweiligen Dienst statt generischer Zugangsdaten – das vereinfacht Einrichtung und Verwaltung. Liefert das System viele Positionen zurück, regelt einer von drei Pagination-Modi, ob und wie der Node weitere Seiten nachlädt.

Woran erkennen Sie, ob eine Auftragsart in Ihrem Betrieb automatisiert werden darf?

Nicht daran, ob sich der Schritt technisch verbinden lässt, sondern daran, ob die vier Entscheidungsgrundlagen – Bestand, Preis, Kunde, Menge – für diese Auftragsart grundsätzlich vollständig vorliegen, bevor ein Mensch sie prüfen müsste. Prüfen Sie das für jede Auftragsart einmal fest, nicht im Einzelfall durch den Workflow.