Excel als Datenbank: Wann SQL und KI-Agenten übernehmen

Der Monatsbericht entsteht wieder in derselben Arbeitsmappe. Jemand kopiert zwei Systemexporte hinein, zieht die SVERWEIS-Spalten nach, aktualisiert die Pivot-Tabelle und verschickt die Datei als Anhang. Diesen Monat steht in einer Zelle #NV, und niemand kann sagen, seit wann.

Wer diese Szene kennt, arbeitet nicht mit einer Tabelle, sondern mit vier Werkzeugen in einer Datei: Datenbank, Datenaufbereitung, Berichtslayout und Rechenwerk. Diese Überladung ist die Quelle der meisten Tabellenprobleme. Jede der vier Rollen hat woanders ein besseres Zuhause, aber solange alles in einer Datei liegt, teilen sich alle Rollen dieselben Zellen, dieselbe Datei auf dem Laufwerk und denselben stillen Fehlermodus.

Wie sich das anfühlt, haben wir bei MAFU-SHERPA gesehen. Die Buchungsdaten für den Monatsabschluss lagen in Business Central, aber der Weg zu DATEV führte über manuelle Excel-Aufbereitung, die fehleranfällig war und sich kaum sauber prüfen ließ. Der automatisierte DATEV-Export hat diese Aufbereitung durch eine kleine Anwendung ersetzt; der Fall begleitet uns durch diesen Artikel.

Welche Rollen SQL, Web-Frontend und Agenten übernehmen

Die erste Rolle ist die Speicherung. Eine SQL-Datenbank wie Postgres oder DuckDB erzwingt, was in einer Spalte stehen darf; SQLite tut das, sobald Tabellen als STRICT angelegt werden. Ein Datum bleibt ein Datum, ein Betrag bleibt eine Zahl, und ein Tippfehler landet als Fehlermeldung auf dem Tisch statt als stiller Textwert in Zeile 3.412. Auch die Zeilenzahl verliert ihren Schrecken; ob ein Datenbestand 500 oder 5 Millionen Zeilen hält, ändert an der Abfrage nichts, während Excel bei 1.048.576 Zeilen schlicht endet.

Verknüpfungen werden zu Joins statt zu SVERWEIS-Ketten. Ein SVERWEIS zeigt auf Zellbereiche und liefert, sobald jemand eine Spalte einfügt, stillschweigend Werte aus der falschen Spalte. Ein Join verbindet Datensätze über einen Schlüssel und bleibt stabil, egal wie die Daten gerade sortiert sind. Die Abfrage für den Umsatz je Kunde passt dabei in eine Zeile, nämlich SELECT kunde, SUM(betrag) FROM rechnungen GROUP BY kunde.

Die zweite Rolle ist die Aufbereitung. Verdichtungen, Bereinigungen und Umrechnungen wandern in SQL-Views oder in eine dünne Skriptschicht. Damit steht die Logik als Text da und lässt sich versionieren und testen. Beim DATEV-Export stecken die Regeln, etwa das Soll/Haben-Kennzeichen aus dem Vorzeichen und Beträge mit deutschem Dezimalkomma, einmal im Code der Anwendung, statt jeden Monat neu in Handarbeit angewendet zu werden.

Die dritte Rolle, den Bericht, übernimmt eine kleine HTML-Seite mit einer Chart-Bibliothek, die aus derselben Abfrage jeden Monat denselben Bericht macht, erreichbar unter einer URL statt als Anhang in zwölf Postfächern. Wer den Bericht öffnet, sieht den aktuellen Stand.

Die vierte Rolle, die Orchestrierung, ist neu zu vergeben, denn KI-Agenten können Abfragen ausführen, Berichte aktualisieren und Auffälligkeiten melden, zum Beispiel einen Lieferanten, der diesen Monat fehlt, oder eine Summe, die negativ geworden ist. Für Ad-hoc-Fragen formuliert der Agent die Abfrage, und die Datenbank liefert die Antwort.

Am stärksten trägt diese Aufteilung bei vier Arten von Tabellenarbeit:

• Wiederkehrende Berichte, die jeden Monat nach demselben Muster entstehen.
• Abstimmungen über mehrere Quellen, etwa ERP gegen Bank oder Shop gegen Buchhaltung.
• Alles oberhalb von ein paar tausend Zeilen.
• Dateien, die mehrere Personen gleichzeitig pflegen.

Wo Excel weiterhin gewinnt

Ehrlicherweise gewinnt Excel eine ganze Klasse von Arbeit weiterhin klar. Für die einmalige Analyse eines CSV-Exports ist eine Stunde Klicken günstiger als ein Abend Code. Wer eine Preisliste einmal sortieren, filtern und kommentieren will, braucht keine Datenbank.

Excel bleibt auch die richtige Oberfläche, wenn Fachkollegen Eingaben selbst pflegen sollen. Das Zellraster ist eine Benutzeroberfläche, die niemand erklären muss; eine Planungstabelle, die der Vertrieb monatlich ausfüllt, ist dort besser aufgehoben als hinter einem Eingabeformular, das erst jemand bauen und pflegen muss.

Stark vernetzte Was-wäre-wenn-Modelle gehören ebenfalls dazu. Ein Finanzmodell, in dem eine geänderte Annahme sofort durch alle Szenarien rechnet, lebt genau von der Zellvernetzung, die beim Berichtswesen stört; es als Software nachzubauen kostet meist mehr, als es einbringt.

Und manchmal ist Excel schlicht das erwartete Format. Steuerberater, Wirtschaftsprüfer und Banken nehmen Arbeitsmappen entgegen, keine Datenbank-Dumps. Wann eine Tabelle grundsätzlich reicht und wann sie zum inoffiziellen System wird, haben wir im Leitfaden Individualsoftware vs. Standardsoftware eingeordnet.

Warum Agenten Code besser bearbeiten als Arbeitsmappen

Der stärkste Grund für den Umstieg steht noch aus, und er betrifft die Automatisierung. Wenn KI-Agenten einen Teil der Arbeit übernehmen sollen, entscheidet die Form, in der die Logik vorliegt, denn Agenten bearbeiten Text deutlich zuverlässiger als Zellgraphen.

Eine SQL-Datei ist ein lineares Textdokument, das ein Agent vollständig lesen kann. Eine Arbeitsmappe ist dagegen ein Graph aus Zellen mit impliziten Abhängigkeiten, den der Agent nur durch die Brille einer Bibliothek sieht, die die Datei serialisiert. Eine Änderung an einer Formel ist im Code lokal und begrenzt, während eine geänderte Zelle Dutzende abhängige Zellen still mitverändert. Auch die Rückmeldung ist ungleich verteilt. Eine Abfrage lässt sich ausführen, und die Fehlermeldung steht Sekunden später da; wer eine Arbeitsmappe außerhalb von Excel neu durchrechnen will, braucht eine nachbauende Rechen-Engine, die bei als Zahlen gespeicherten Datumswerten, bei Rundung, Array-Formeln und volatilen Funktionen vom Original abweichen kann. Dazu kommt die Prüfung. Text-Diffs lassen sich in der Versionsverwaltung Zeile für Zeile lesen, ein binärer .xlsx-Vergleich nicht. Und SQL hat eine Grammatik und ein Typsystem, während Excel-Formeln auf implizite Umwandlungen bauen, die ein Agent erraten muss.

Fair bleibt das Bild nur mit der Gegenseite, und die stammt aus unserer eigenen Arbeit mit Agenten, Stand August 2026. Werte lesen, flache Tabellen schreiben, Zellen formatieren und frische Arbeitsmappen erzeugen funktioniert darin zuverlässig. Brüchig wird es beim Bearbeiten bestehender Formeln, bei Pivot-Tabellen, bei Diagrammen mit festen Bezügen, bei benannten Bereichen, bedingter Formatierung und Makros.

Die Datei öffnet sich danach trotzdem.

Genau darin liegt der leise Fehlermodus. Die Zahlen sind falsch, nichts warnt, und es fällt erst auf, wenn jemand nachrechnet oder der Bericht schon beim Kunden liegt.

Agenten, die in der laufenden Excel-Anwendung arbeiten, etwa Copilot direkt in Excel, verkleinern diese Lücke, weil dann Excel selbst rechnet. Das Prüfproblem lösen sie nur zum Teil, denn Excels Änderungsprotokoll erfasst zwar Zell- und Formeländerungen samt Vorher-Werten, aber Pivot-Tabellen, Diagramme und Formatierungen nicht vollständig, und einen versionierten Diff der ganzen Arbeitsmappe ergibt es nicht. Ob bessere Werkzeuge das grundlegend ändern, ist offen.

Was Sie vor dem Umstieg klären sollten

Der Umstieg ist kein Selbstläufer. Sieben Punkte entscheiden darüber, ob aus der Idee ein verlässlicher Ablauf wird.

• Dateneingang: Solange Kollegen weiter in Excel erfassen, haben Sie eine Pipeline hinzugefügt und keine entfernt. Legen Sie fest, welches System die Wahrheit führt.
• Schema-Disziplin: Eine sauber definierte SQL-Spalte verträgt keine Mischung aus Datum, Leerzelle und „TBD“. Planen Sie Zeit für die Bereinigung ein und entscheiden Sie, was ein leerer Wert (NULL) bedeuten soll.
• Verantwortung: Datenbank, Frontend und Agent brauchen jemanden, der im Fehlerfall alle drei Schichten untersuchen kann.
• Agenten-Leitplanken: Der Agent bekommt nur Leserechte und arbeitet auf getesteten Views statt auf den Rohdaten; bevor eine Zahl in eine Entscheidung fließt, prüft ein Mensch. Behandeln Sie Agenten-Ausgaben wie den Entwurf eines Junior-Analysten.
• Sicherheit und Betrieb: Aus einer Datei wird ein Dienst. Anmeldung, Backups und Hosting sind ab dann Ihr Thema.
• Versionierung: SQL und Frontend liegen in Git, und jeder Bericht ist aus den Rohdaten reproduzierbar. Das ist der größte einzelne Gewinn des Umstiegs.
• Migration: Schreiben Sie nicht alles um. Nehmen Sie die eine schmerzhafte, wiederkehrende Arbeitsmappe, bauen Sie sie vollständig nach und behalten Sie Excel als Exportformat.

Dazu kommt ein achter Punkt aus unserer eigenen Erfahrung. Fachanwender akzeptieren Zahlen aus SQL erst, wenn sie sie ohne SQL-Kenntnisse plausibilisieren können. Beim DATEV-Export zeigt die Anwendung deshalb vor dem Import eine Datenvorschau mit Validierungshinweisen, geprüft wird also in dem Format, das die Buchhaltung ohnehin kennt. Bauen Sie solche Kontrollen von Anfang an ein, etwa Zeilenzahlen je Quelle und einen Abgleich gegen eine Monatssumme, der die Empfänger bereits vertrauen. Ein Bericht, der seine eigenen Prüfzahlen mitliefert, macht aus blindem Vertrauen eine kurze, konkrete Prüfung.

Die Steigerung dieser Regel ist ein zweiter, unabhängiger Rechenweg: Ein Agent rechnet das Ergebnis der Abfrage noch einmal direkt aus den Rohdaten nach, ohne die Abfrage zu kennen. So erschöpfend zu prüfen war immer möglich und bis jetzt nie wirtschaftlich; erst Agenten machen es so günstig, dass es nach jeder Änderung laufen kann statt nur bei der Abnahme.

Eine pragmatische Referenzarchitektur

Für die meisten Fälle reicht ein bewusst kleiner Aufbau. DuckDB oder Postgres speichert die Daten, SQL-Views, also versionierte und getestete Abfragen nach dem Muster von Werkzeugen wie dbt, übernehmen die Aufbereitung, eine kleine statische HTML-Seite oder ein leichter Server zeigt die Berichte, und ein Agent mit Leserechten auf die Views beantwortet Fragen und entwirft Zusammenfassungen. Mehr Infrastruktur, etwa ein BI-Produkt oder eine Orchestrierungsplattform, darf später kommen, wenn der Bedarf belegt ist. Wie sich so ein Umbau in die übrige Prozesslandschaft einfügt, beschreibt der Leitfaden Geschäftsprozesse automatisieren.

Die Entscheidungsregel

Die Regel, die wir selbst anwenden, ist kurz. Werden Agenten oder Automatisierung einen nennenswerten Teil der Bearbeitung übernehmen, gehört die Logik in SQL und die Darstellung in HTML, und Excel bleibt am Rand als Import- und Exportformat, in dem niemand eine Formel anfasst. Bleibt die Arbeit dagegen einmalig, interaktiv oder in den Händen von Fachkollegen, ist Excel weiterhin die richtige Wahl und keine Übergangslösung.

Die eine schmerzhafte, wiederkehrende Arbeitsmappe aus Punkt sieben ist der richtige Gesprächsanlass: Sprechen wir über den konkreten Ablauf.