Spracheingabe in der Buchhaltung: wo es wirklich bricht

Du kannst inzwischen mit einer Buchhaltungs-App sprechen. Sag "vierzig Euro Mittagessen mit Kunde gestern, bar" und bekomme eine gebuchte Ausgabe, oder halte das Mikrofon und diktiere eine Frage zu deiner Umsatzsteuerfrist. Das funktioniert, und es ist das Uninteressanteste daran.

Interessant ist, wie wenig vom Voice-Stack 2026 du dafür brauchst, und wie viel Aufwand in Dinge geht, die mit Spracherkennung nichts zu tun haben. Wir haben dieses Jahr Spracherfassung auf zwei Oberflächen ausgeliefert, und die Fehler lagen nie im Transkript. Sie lagen in einem Dateipfad, einer Berechtigungsabfrage, einem zu kurzen Tap und einem Modell-Upgrade, das still eine Funktion entfernt hat, von der wir abhängig waren.

Kann man Buchhaltung per Sprache machen?

Für Erfassung und für Fragen ja. Für unbeaufsichtigte Befehle nein, und nicht, weil das Modell sie nicht parsen könnte.

Sprache ist eine Eingabemethode für Text. Sie ist kein Autorisierungsmechanismus. Ein gesprochener Satz, der zu einer Buchung wird, muss durch einen Zustand laufen, den ein Mensch lesen und korrigieren kann, weil es bei einer abgegebenen Umsatzsteuervoranmeldung kein Undo gibt und weil ein Transkript genau die Stelle ist, an der aus "neunzehn" "neunzig" wird. Beide unserer Oberflächen tun deshalb dasselbe: transkribieren, den Text zeigen, den Menschen auf Senden drücken lassen. Auf der Messaging-Oberfläche gibt der Bot buchstäblich zurück, was er gehört hat, bevor er antwortet.

Diese eine Regel nimmt einer Sprachfunktion den größten Teil des Risikos, und sie ist auch der Grund, warum wir die Teile des Industrie-Stacks nicht brauchen, die gerade alle ausliefern.

Die zwei Sprachmodi, und welchen du willst

Es gibt zwei Wege, Sprache in eine App zu bekommen, und sie sind keine Varianten derselben Sache.

Wir nutzen beides. Diktat passt, wenn jemand eine Nachricht formuliert und sie entstehen sehen will. Die Sprachnachricht passt für "vierzig Euro Mittagessen, bar", wo der Nutzer eine Sache sagt, aufhört und ein Ergebnis erwartet. Das interessante Implementierungsdetail: unser Sprachnachrichten-Recorder nutzt das Erkennungsmodul auf dem Gerät als Aufnahmegerät und nicht als Erkenner. Es fragt das Mikrofon an, misst den Pegel für die Wellenform und speichert das Audio, während das eigentliche Transkript von einem Servermodell kommt. Aufgenommen wird mit 16 kHz, PCM 16 Bit, weil Sprachmodelle das wollen und weil 48 kHz Stereo über eine Mobilverbindung zu schicken die Zeit aller verschwendet.

Was in einem Sprach-Flow wirklich bricht

Vier Dinge, keines davon das Modell.

Berechtigungen, und nur bei einer frischen Installation. Das Diktat fragte Mikrofonzugriff vor dem Start an, der Sprachnachrichten-Pfad ging davon aus, dass er schon erteilt war. Auf einem Gerät, auf dem er nie erteilt wurde, sendete der Erkenner ein not-allowed-Event, es entstand nie eine Audiodatei, und die UI blieb einfach stehen. Der Fix ist trivial, die Lehre nicht: jeder Einstiegspunkt in Audio muss die Berechtigung selbst anfragen, weil dein Testgerät sie vor Wochen erteilt hat.

Die Audiodatei existiert nicht dann, wenn du denkst. Die Aufnahme-URI kommt mit einem Start-Event, aber der native Writer hält die Datei noch. Wer sie dann liest, bekommt einen Pfad auf etwas Unvollständiges. Wir behalten den frühen Pfad nur als Fallback und konsumieren ihn nach dem letzten End-Event, wenn der Writer fertig ist. Wenn deine Sprachfunktion im Simulator läuft und auf einem echten Telefon scheitert, prüfe zuerst diesen Race.

Tippen und loslassen. Wer den Aufnahmeknopf antippt und sofort loslässt, schickt einen Header ohne Audio darin. Der Transkriptionsdienst lehnt das zu Recht ab, und die naive Implementierung meldet einen Serverfehler, wiederholt und scheitert erneut an denselben Bytes. Das ist ein 4xx, kein 5xx: die Eingabe ist das Problem, der Retry ist sinnlos, und die richtige Antwort ist "das war zu kurz, versuch es nochmal" statt eines Vorfalls in deinem Error-Tracking.

Das Latenzbudget, das eine Kette ist und keine Zahl. Der Client begrenzt eine Aufnahme auf zwei Minuten. Der Serveraufruf hat achtzehn Sekunden Timeout, gewählt unterhalb der Obergrenze des Request-Handlers von fünfundzwanzig Sekunden, damit eine langsame Transkription sauber scheitert statt mitten im Request abgeschossen zu werden. Wähle diese drei Zahlen zusammen, sonst entscheidet die äußere für dich, und zwar indem sie die Aufnahme verwirft, nachdem der Nutzer neunzig Sekunden geredet hat.

Das Modell-Upgrade, das uns die Spracherkennung gekostet hat

Das ist der Teil, den ich in einem fremden Postmortem lesen wollen würde.

Unsere Transkription nutzte ursprünglich ein Modell, dessen ausführliches Antwortformat die erkannte Sprache und die Audiodauer zurückgibt, abgeleitet aus dem Audio selbst. Für ein Produkt, das auf Deutsch, Englisch und Polnisch benutzt wird, ist dieser Sprachcode keine Nettigkeit: er entscheidet, in welcher Sprache der Assistent antwortet. Beim Wechsel auf ein neueres, besseres Transkriptionsmodell wurde dieses Antwortformat schlicht abgelehnt. Das neuere Modell transkribiert genauer und sagt dir weniger.

Die Sprache kommt jetzt aus einer Stoppwort-Heuristik über dem Ergebnistext, und das ist ein Rückschritt, ein ehrlicher: ein kurzer Satz ohne Stoppwörter bekommt gar keine Sprache, und wir fallen auf die Oberflächensprache zurück. Die Streaming-Anbieter sind unterdessen in die andere Richtung gelaufen und haben genau das zum Aufmacher gemacht. Deepgrams Flux Multilingual erreichte am 29. April 2026 allgemeine Verfügbarkeit, mit zehn Sprachen und dynamischem Wechsel innerhalb eines Gesprächs, und AssemblyAIs mehrsprachiges Streaming-Modell, veröffentlicht am 12. November 2025, deckt sechs Sprachen in einem Modell zu einem festen Stundenpreis unabhängig von der Sprache ab.

Was echt nützlich ist, und größtenteils nicht für uns. Schau, worauf der Rest dieses Stacks optimiert ist: Flux wurde darum herum gebaut, zu erkennen, wann ein Sprecher seinen Zug beendet hat, und AssemblyAI lieferte am 4. Mai 2026 ein Upgrade der Streaming-Diarisierung. Sprecherwechsel-Erkennung und Sprechertrennung sind die harten Probleme eines lebenden, unterbrechbaren Gesprächs mit mehreren Beteiligten. Ein Erfassungs-Flow in der Buchhaltung hat einen Sprecher, keine Unterbrechungen und einen Satz, der endet, wenn ein Daumen einen Knopf verlässt. Den Konversations-Stack dafür zu kaufen heißt, für ein Problem zu zahlen, das du nicht hast.

Wie die Nutzung tatsächlich aussieht

Eine Zahl, mit angehängtem Vorbehalt, weil ich lieber ein kleines ehrliches Signal veröffentliche als ein großes vages.

Auf unserer Messaging-Bot-Oberfläche, wo ein Nutzer Text, ein Foto oder eine Sprachnachricht senden kann, sind etwas mehr eingehende Nachrichten Sprachnachrichten als getippter Text. Das stammt aus ein paar hundert eingehenden Nachrichten einer frühen Kohorte, also behandle es als Richtung und nicht als Benchmark. Mich hat es trotzdem überrascht: bei freier Wahl der Eingabe auf einem Gerät, das zum Tippen gebaut ist, reden diese Nutzer.

Das Zweite, was unsere Daten sagen, betrifft unsere eigene Instrumentierung. In den Chat-Tabellen ist eine gesprochene Nachricht nicht von einer getippten zu unterscheiden, weil wir das Transkript speichern. Für den Datenschutz ist das richtig und für Produktentscheidungen unbequem: wir können "wie viele Buchungen begannen als Sprache" nicht beantworten, ohne ein Flag zu ergänzen, das wir nie ergänzt haben. Wenn du das baust, schreibe die Herkunft an die Nachricht, bevor du ausrollst, nicht wenn du die Zahl brauchst.

Häufige Fragen

Wie höre ich auf, Ausgabendaten von Hand zu tippen?

Erfasse im Moment der Ausgabe statt in einer Monatssitzung, und nutze die Eingabe, die für die Situation die schnellste ist: ein Foto, wenn es einen Beleg gibt, Sprache, wenn nicht. Ein gesprochener Satz wie "vierzig Euro Mittagessen mit Kunde, bar" trägt Betrag, Kategoriehinweis und Zahlungsart in einem Atemzug, und das ist schneller als jedes Formular. Danach bestätige das geparste Ergebnis, denn die Korrektur ist der letzte verbleibende Handgriff.

Kann ich eine Ausgabe per Sprache auf Deutsch buchen?

Ja, und zu prüfen ist die Sprachbehandlung, nicht die Erkennungsqualität. Moderne Transkription kommt mit Deutsch inklusive Zahlen und Währung gut zurecht; der Fehler tritt auf, wenn die App in der falschen Sprache antwortet oder ein Dezimalkomma zu einem Dezimalpunkt normalisiert. Frag einen Anbieter, was bei einem kurzen Satz passiert, dessen gesprochene Sprache von der Oberflächensprache abweicht, denn das ist der Fall, der still bricht.

Ist Spracheingabe genau genug für Zahlen in der Buchhaltung?

Genau genug für einen Vorschlag, nicht für unbeaufsichtigtes Abgeben. Beträge und Daten kommen verlässlich zurück, aber "neunzehn" und "neunzig" liegen in mehreren Sprachen einen Vokal auseinander, und ein Transkript ist die Stelle, an der das zusammenfällt. Jeder Sprach-Flow, der steuerrelevante Datensätze berührt, sollte die geparsten Werte zur Bestätigung zeigen, bevor er schreibt, und das gibt dir zugleich einen klaren Prüfpfad, wer die Buchung freigegeben hat.

Was passiert danach mit der Audioaufnahme?

In unserem Flow wird die Aufnahme hochgeladen, transkribiert, und die lokale Datei danach gelöscht, es bleibt also der Text und nicht das Audio. Das lohnt sich, jeden Anbieter ausdrücklich zu fragen, denn Sprachnachrichten über Betriebsausgaben enthalten regelmäßig Namen Dritter, und Audio, das "zur Qualitätssicherung" behalten wird, ist eine Kopie personenbezogener Daten, die du nicht behalten musstest. Bei unseren eigenen Modell-Traces halten wir es genauso, dort liegt ein Hash statt der Nutzlast.

Funktioniert Spracheingabe ohne Internetverbindung?

Live-Diktat auf dem Gerät kann es, je nach Plattform und installierter Sprache. Aufgenommene Sprachnachrichten nicht, weil das Transkript von einem Servermodell kommt. Praktisch zählt das weniger als es klingt: die Buchung braucht den Server ohnehin, ein Offline-Transkript würde sich also nur hinter derselben Verbindung anstauen.

Fazit

Sprache in einer Buchhaltungs-App ist ein gelöstes Problem hinter vier ungelösten Implementierungsdetails, und die Details sind Berechtigungen, ein Datei-Handle, eine zu kurze Aufnahme und eine Timeout-Kette. Keines davon steht in einem Vergleich von Sprachmodellen.

Das Strategische ist, zu wissen, welche Teile des Voice-Stacks 2026 man überspringt. Sprecherwechsel-Erkennung, Diarisierung und dynamischer Sprachwechsel sind die richtigen Investitionen für einen Konversationsagenten am Telefon. Für jemanden, der vor einem Restaurant steht und "vierzig Euro, Mittagessen, bar" sagt, ist die richtige Investition eine Aufnahme, die verlässlich zu einem Transkript kommt, ein Transkript, das die Person sieht, und ein Senden-Knopf, den sie selbst drückt. Dieselbe Disziplin haben wir in das Einsammeln fehlender Belege eingebaut, und sie gilt hier genauso: das interessante Engineering ist fast nie das Modell.