Reporting automatisieren: Wochenberichte aus mehreren Systemen mit n8n zusammenführen

Ein n8n-Workflow führt wiederkehrende Berichte aus mehreren Systemen zusammen, indem ein zeitgesteuerter Trigger den Lauf startet, je ein Node die Daten aus jeder Quelle abruft, ein Merge- oder Code-Node sie zu einer gemeinsamen Struktur zusammenführt und ein letzter Node das Ergebnis ausgibt. Lohnen tut sich der Bau nicht bei jedem Bericht, der mehrere Systeme berührt, sondern dort, wo Frequenz und manuelle Zusammenstellungszeit hoch genug sind, um den Aufwand für Bau und Pflege in absehbarer Zeit aufzuwiegen.

Ein Hinweis vorweg: Die Angaben zu den n8n-Nodes geben den Stand der n8n-Dokumentation vom 30. September 2026 wieder. Node-Funktionsumfang ändert sich zwischen Versionen; die Quellen sind unten verlinkt, damit Sie den aktuellen Stand selbst nachschlagen können.

Der Workflow in vier Schritten

Schritt	Was passiert	n8n-Baustein
1. Trigger	Der Lauf startet zu einer festen Zeit	Schedule Trigger
2. Datenabruf je Quelle	Jedes System liefert seine Zahlen in seinem eigenen Format	HTTP Request (APIs), Postgres/MySQL (Datenbanken), Google Sheets oder Microsoft Excel 365 (Tabellen)
3. Zusammenführung	Die Antworten werden zu einer gemeinsamen Struktur	Merge-Node (Combine-Modi) oder Code-Node für eigene Rechenlogik
4. Ausgabe	Das Ergebnis landet dort, wo es gebraucht wird	Google Sheets/Excel schreiben, Send Email, Slack oder Microsoft Teams

1. Trigger: wann der Bericht entstehen soll

Der Schedule-Trigger-Node startet den Workflow laut n8n-Dokumentation zu festen Zeiten und Intervallen – von einem einfachen “alle X Minuten” bis zu einem vollständigen Cron-Ausdruck. Für einen Wochenbericht reicht ein fester Wochentag und eine feste Uhrzeit. Zwei Dinge gehören zur Planung dazu: Der Workflow muss laut Dokumentation veröffentlicht sein, damit der Trigger überhaupt feuert, und die Zeitzone richtet sich nach der Workflow- oder der Instanz-Zeitzone – bei Systemen, die in unterschiedlichen Zeitzonen laufen (ein Shop-System auf UTC, ein CRM auf der lokalen Zeitzone), entscheidet diese Einstellung mit darüber, welcher Tag als “diese Woche” zählt.

2. Datenabruf: jede Quelle spricht ihre eigene Sprache

Für jedes Quellsystem braucht der Workflow einen eigenen Abfrage-Schritt, weil die drei gängigen Quellenarten technisch unterschiedlich angesprochen werden:

• APIs ruft der HTTP-Request-Node ab, der laut n8n-Dokumentation HTTP-Anfragen an jeden Dienst mit einer REST-Schnittstelle stellt, mit vordefinierten oder generischen Zugangsdaten (Basic, Header, OAuth1/2 und weitere) und eingebauter Pagination für Antworten, die über mehrere Seiten verteilt sind.
• Datenbanken spricht n8n über eigene Nodes an, etwa Postgres oder MySQL. Beide unterstützen laut Dokumentation unter anderem die Operationen Select, Insert und Update sowie eine eigene SQL-Abfrage – bei Postgres unter „Execute Query”, bei MySQL unter „Execute SQL”. Für einen Bericht genügt ein lesender Select oder diese eigene Abfrage, sofern keine Verknüpfung mehrerer Tabellen nötig ist – sonst wird daraus ein Join in der eigenen SQL-Abfrage.
• Tabellen liest der Google-Sheets-Node (Operationen u. a. “Get Row(s)”, “Append or Update Row”) oder der Microsoft-Excel-365-Node (u. a. Zeilen an eine Tabelle anhängen, Zeilen und Spalten auslesen, eine Zeile über einen Spaltenwert nachschlagen) direkt aus der jeweiligen Datei.

Läuft eine der Quellen auf einem Altsystem ohne eigene API, ändert sich dieser Schritt: Dann braucht es einen der Wege, die unser Beitrag zu Altsystemen ohne API beschreibt – Datei, E-Mail-Postfach, Datenbank oder zuletzt die Bedienoberfläche, mit den dort genannten Einschränkungen.

3. Zusammenführung: aus mehreren Antworten eine Zeile

Sobald alle Quellen geantwortet haben, führt der Merge-Node sie zusammen. Im Combine-Modus mit dem Untermodus “Matching Fields” gleicht er zwei Dateneingänge über ein gemeinsames Feld ab, etwa Datum oder Kunden-ID. Wichtig für einen Bericht: In der Voreinstellung behält dieser Modus laut Dokumentation nur die Treffer (“Keep Matches”) und verwirft, was sich nicht zuordnen lässt – für einen vollständigen Bericht, der auch zeigt, wo eine Quelle nichts geliefert hat, muss der Output Type auf eine der Optionen gestellt werden, die auch nicht zugeordnete Zeilen behalten. Bei mehr als zwei Quellen oder wenn eine eigene Rechenlogik dazukommt (Summen, Differenzen, Kennzahlen aus mehreren Feldern), übernimmt das der Code-Node: Er läuft laut Dokumentation wahlweise einmal für alle eingehenden Daten oder einmal je Datensatz, unterstützt JavaScript und – langsamer – Python, kann aber weder auf das Dateisystem zugreifen noch selbst HTTP-Anfragen stellen; beides bleibt Aufgabe der dafür vorgesehenen Nodes.

4. Ausgabe: wohin die Zahlen gehen

Am Ende schreibt der Workflow das Ergebnis zurück in eine Tabelle (Google Sheets oder Microsoft Excel 365, mit denselben Nodes wie beim Abruf) oder verschickt es direkt: der Send-Email-Node über einen SMTP-Server, der Slack-Node an einen Kanal oder eine Person, der Microsoft-Teams-Node an einen Kanal oder Chat. Ein fertiges PDF gehört nicht zu diesem Standardweg: n8n bringt dafür keinen eigenen Node mit, der aus Daten ein PDF erzeugt – der Extract-From-File-Node liest aus einer bestehenden PDF-Datei, erzeugt aber keine. Wer ein PDF will, braucht einen Node für einen externen Dienst wie APITemplate.io oder einen eigenen HTML-zu-PDF-Weg; für die meisten wiederkehrenden Berichte reicht eine aktuell gehaltene Tabelle mit einer kurzen Zusammenfassung per Mail oder Chat. Ein Beispiel für einen solchen Bericht steht bereits in Schritt 6 unseres Beitrags zur Automatisierung der Buchhaltung: Dort bleibt die Zusammenführung Aufgabe des Workflows, die Interpretation der Zahlen bleibt beim Menschen – dasselbe Prinzip wie hier.

Wo das technisch bricht

Drei Stellen verdienen mehr Sorgfalt als der Grundaufbau selbst:

Unterschiedliche Datenformate und Zeitzonen. Ein CRM liefert ein Datum vielleicht als 2026-09-30, ein Shopsystem als 30.09.2026 00:00 UTC, eine Buchhaltungs-API als Unix-Zeitstempel. Bevor der Merge-Node zwei Quellen über ein Datumsfeld abgleichen kann, müssen beide Seiten dasselbe Format und – bei Systemen in unterschiedlichen Zeitzonen – denselben Tagesbeginn verwenden, sonst zählt eine Randzeile mal hier, mal dort.

Fehlende oder verspätete Daten einer Quelle. Antwortet eine API erfolgreich, aber mit einer leeren Liste – etwa weil ein Batch-Job dort noch nicht fertig ist –, ist das für n8n kein Fehler: Der HTTP-Request-Node wertet laut Dokumentation standardmäßig nur einen Nicht-2xx-Statuscode als Fehler, eine leere, aber erfolgreiche Antwort lässt die Ausführung grün durchlaufen, nur eben mit einer Lücke im Bericht. Anders bei einem echten Fehlerstatus wie einer erreichten Rate-Limit-Grenze: Den fängt der Node standardmäßig als Fehler ab, sofern nicht die Option „Never Error” gesetzt ist – dieser Fall zeigt sich also eher im Monitoring als im Bericht selbst. Ein Bericht, der mit unvollständigen Daten unbemerkt durchläuft, ist gefährlicher als ein Bericht, der einen Tag später von Hand fertig wird, weil niemand merkt, dass eine Zahl fehlt. Die Prüfung dafür bringt kein Node von allein mit; sie muss der Workflow selbst enthalten, etwa eine Bedingungs-Node, die eine leere oder unplausible Quellantwort abfängt, bevor sie in die Zusammenführung einfließt. Das ist ausdrücklich eine andere Prüfung als die, ob der Workflow technisch durchgelaufen ist: Monitoring beobachtet, ob n8n einen Fehler protokolliert – nicht, ob die im Bericht ausgewiesenen Zahlen stimmen. Ein Report-Workflow braucht deshalb beides: eine externe Beobachtung dafür, dass er überhaupt gelaufen ist, und eine eingebaute Prüfung dafür, dass jede Quelle tatsächlich etwas geliefert hat.

Versionierung von Kennzahl-Definitionen. Was als “Umsatz” oder “aktiver Kunde” zählt, steckt in der Formel des Merge- oder Code-Node – nicht sichtbar für jemanden, der nur den fertigen Bericht liest. Ändert sich diese Definition (ein neues Feld im CRM, eine andere Abgrenzung für “aktiv”), ändert sich der Bericht still mit, ohne dass eine Zeile im Ergebnis das anzeigt. Halten Sie deshalb fest, wo die Definition jeder Kennzahl im Workflow steht, und tragen Sie jede Änderung daran mit Datum nach – eine Sticky Note direkt am Code-Node im Workflow oder ein kurzer Eintrag in einer Versionsliste reicht dafür.

Welche Berichte die Automatisierung lohnen: eine Prüfliste

Ein Rechenbeispiel vorweg, ausdrücklich mit frei gewählten Annahmezahlen zur Veranschaulichung, keine gemessene Größe: Ein Bericht, der einmal im Jahr zwanzig Minuten Zusammenstellung kostet, macht in einem Jahr zwanzig Minuten Aufwand – ein halber Tag Bau- und Testzeit für einen Workflow amortisiert sich darin nie. Ein Bericht, der wöchentlich fünfundvierzig Minuten aus vier Systemen zusammengetragen wird, kostet über ein Jahr gerechnet (52 Wochen mal 45 Minuten) knapp 39 Stunden manuelle Arbeit; ein halber Tag Bau (angenommen vier Stunden) plus eine Stunde Pflege im Monat (zwölf Stunden im Jahr) amortisiert sich darin nach wenigen Monaten und spart danach weiter.

Der Grundgedanke dieser Rechnung ist eine Schwelle: Frequenz mal manuelle Zusammenstellungszeit gegen Bau- und Pflegeaufwand des Workflows. Tragen Sie für jeden wiederkehrenden Bericht in Ihrem Haus die eigene Frequenz und die eigene Zusammenstellungszeit ein – die Rechnung oben ist nur das Muster, nicht der Wert, der für Sie gilt.

Frequenz mal Zeit ist aber nicht die einzige Frage. Drei weitere gehören in dieselbe Prüfung, bevor Sie einen Bericht automatisieren:

• Wie stabil sind die Quellsysteme und ihre Schnittstellen? Eine dokumentierte API oder eine Datenbank mit stabiler Tabellenstruktur trägt einen automatisierten Bericht zuverlässig. Eine Quelle, die nur über eine Bedienoberfläche ohne API erreichbar ist, bricht bei der nächsten Oberflächenänderung – dafür lohnt sich der Mehraufwand nur, wenn der Bericht selbst besonders wertvoll ist.
• Braucht der Bericht eine menschliche Einordnung, die ohnehin niemand wegautomatisieren sollte? Ein Workflow kann Zahlen zusammenführen; die Frage, warum eine Kennzahl gestiegen oder gefallen ist, beantwortet er nicht. Berichte, deren Wert vor allem in der Interpretation liegt, gewinnen durch Automatisierung nur bei der Zusammenstellung, nicht bei ihrem eigentlichen Zweck.
• Wie teuer ist ein stiller Fehler in diesem Bericht? Ein Bericht, auf dessen Basis eine Bestellung ausgelöst oder ein Budget freigegeben wird, braucht eine sorgfältigere Prüfung gegen fehlende Daten als ein interner Statusüberblick, den ohnehin niemand ungeprüft weiterreicht.

Ein Bericht, der bei Frequenz mal Zeit über der Schwelle liegt, aus stabilen Quellen stammt, keine tiefere Interpretation ersetzen soll und dessen Fehlerkosten überschaubar sind, ist ein guter erster Kandidat. Fehlt eine dieser Bedingungen deutlich, bleibt der Bericht vorerst Handarbeit – nicht, weil er sich nicht bauen ließe, sondern weil der Aufwand an der falschen Stelle steckt.

Für den Mittelstand heißt das

Haben Sie n8n noch nicht im Haus, klären Sie zuerst die Grundlagen in unserem Leitfaden zur Einführung von n8n im Mittelstand – ein einzelner Report-Workflow ist kein Grund, das Werkzeug an sich neu zu bewerten. Automatisieren Sie dann zuerst den Bericht, der bei Ihnen am häufigsten wiederkehrt und am meisten Zusammenstellungszeit aus möglichst stabilen Quellen frisst – nicht den, der Ihnen auf den ersten Blick am wichtigsten erscheint. Ein Wochenbericht aus CRM, Warenwirtschaft und Bank amortisiert den Bauaufwand schneller als ein Jahresbericht, selbst wenn der Jahresbericht mehr Aufmerksamkeit bekommt. Und behandeln Sie die eingebaute Prüfung gegen fehlende Daten nicht als optionalen Zusatz: Ein automatisierter Bericht, der bei einer leeren Quellantwort weiterläuft, sieht auf den ersten Blick zuverlässiger aus als der alte manuelle Prozess – bis jemand eine Entscheidung auf falschen Zahlen trifft, die niemand angezweifelt hat, weil der Bericht ja pünktlich kam.

FAQ

Wie führt ein n8n-Workflow Daten aus mehreren Systemen zu einem Bericht zusammen?

Ein zeitgesteuerter Trigger startet den Lauf, für jedes Quellsystem ruft ein eigener Node die Daten ab (HTTP Request für APIs, ein Datenbank-Node für SQL-Systeme, Google Sheets oder Microsoft Excel 365 für Tabellen), ein Merge- oder Code-Node führt die Ergebnisse zu einer gemeinsamen Struktur zusammen, und ein letzter Node schreibt sie in eine Tabelle oder verschickt sie als Nachricht.

Welche Berichte lohnen sich zuerst für die Automatisierung?

Die, bei denen Frequenz mal manuelle Zusammenstellungszeit hoch genug ist, dass sie den Bau- und Pflegeaufwand des Workflows in absehbarer Zeit aufwiegt – und bei denen die Quellsysteme stabile, dokumentierte Schnittstellen haben. Ein Bericht, der einmal im Jahr zwanzig Minuten kostet, gehört nicht dazu; ein wöchentlicher Bericht aus mehreren Systemen mit einer Dreiviertelstunde Zusammenstellung schon eher.

Kann n8n aus den zusammengeführten Daten auch ein PDF erzeugen?

Nicht mit einem eigenen, von n8n selbst gebauten Node (Stand 30. September 2026, geprüft an der Node-Übersicht der n8n-Dokumentation). Der Extract-From-File-Node liest aus einem bestehenden PDF, erzeugt aber keins. Für eine PDF-Ausgabe braucht es einen Node für einen externen Dienst wie APITemplate.io oder einen eigenen HTML-zu-PDF-Weg; der einfachere Standardweg ist, die Kennzahlen in eine Tabelle zu schreiben und diese oder eine Zusammenfassung davon per Mail, Slack oder Microsoft Teams zu verschicken.

Was passiert, wenn eine der Quellen beim automatischen Lauf keine Daten liefert?

Ohne eine eingebaute Prüfung nichts Sichtbares – ein leeres oder unvollständiges Ergebnis ist für n8n kein Fehler, der Bericht geht trotzdem raus, nur mit falschen Zahlen. Das ist gefährlicher als ein Bericht, der einen Tag später von Hand kommt, weil niemand merkt, dass etwas fehlt. Die Prüfung muss der Workflow selbst mitbringen, etwa eine Bedingungs-Node, die eine leere oder unplausible Antwort einer Quelle abfängt, bevor sie in den Bericht einfließt.

Ist der Merge-Node dafür gedacht, Daten aus verschiedenen Systemen zusammenzuführen?

Ja, im Combine-Modus über den Untermodus “Matching Fields”: Er gleicht zwei Dateneingänge über ein gemeinsames Feld ab, etwa Datum oder Kunden-ID. In der Voreinstellung behält er dabei nur die Treffer und verwirft nicht zugeordnete Zeilen aus beiden Eingängen; wer auch die Lücken sehen will, muss den Output Type auf eine der anderen Optionen stellen. Bei mehr als zwei Quellen oder eigener Rechenlogik kommt statt- oder zusätzlich der Code-Node infrage.