Dokumenten-KI fuer Treuhand
Dokumenten-KI fuer Treuhand-Mandate
Beleg-OCR mit Buchungsvorschlag
Spesenbelege und Quittungen erreichen das Treuhandbuero in jedem denkbaren Format. Mistral OCR liest den Text in zwei Durchgaengen, auch von zerknitterten Thermopapier-Belegen. Ein JSON-Modus-Schritt liefert Lieferant, Datum, Brutto, MWST und einen Konto-Vorschlag. Die juniore Buchhaltungskraft nimmt an, korrigiert oder verwirft in einer Maske.
Rechnungserfassung mit MWST-Klassifikation
Lieferantenrechnungen kommen als PDF oder gescannter Beleg herein. Die Pipeline extrahiert Kopfdaten, Positionen, MWST-Satz pro Position und Waehrung und ordnet jede Zeile dem Kontenplan des Mandanten zu. Bezugsteuer und Mischsatz-Rechnungen werden gemaess dem MWST-Profil des Mandanten verarbeitet, nicht nach einer generischen Vorlage.
Hilfe bei der Bankauszug-Abstimmung
Wo der Bankfeed eines Mandanten lueckenhaft oder gar nicht eingebunden ist, zerlegt die Pipeline Bankauszug-PDFs und camt.053-Anhaenge in einzelne Bewegungen. Ergebnis ist eine abstimmungsfertige Datei, die die senior Person gegen offene Posten matcht — die eigentliche Verbuchung bleibt beim Buchhaltungswerkzeug.
Lieferanten-Kontoauszug extrahieren
Monatsend-Kontoauszuege der Lieferanten kommen als PDF-Tabellen, die selten eins-zu-eins zur Offene-Posten-Liste des Mandanten passen. Wir extrahieren die Positionen und markieren Abweichungen gegen das Hauptbuch, damit das Treuhandbuero sie einmal sauber loest — nicht Rechnung fuer Rechnung.
Lohndokumente fuer den Monatsabschluss
Lohnabrechnungen, AHV-Bescheinigungen, Spesenabrechnungen und Quellensteuer-Anhaenge werden pro Mitarbeitenden und pro Periode klassifiziert und in der Struktur uebergeben, die das Lohntool des Bueros oder die S001.4-Lohn-Pipeline erwartet. Der Monatsabschluss hoert auf, eine Papierjagd zu sein.
Integration mit Bexio, Abacus und Sage
Wir ersetzen das Buchhaltungswerkzeug nicht. Wir erzeugen die Importdatei, die es ohnehin akzeptiert — CSV in der Bexio-, Abacus- oder Sage-Spaltenkonvention oder, wo eine API fuer Treuhand-Schnittstellen vorhanden ist, ueber genau diese. Das Hauptbuch bleibt dort, wo das Treuhandbuero es will.
Unser Vorgehen
Discovery: Mandate und Tool-Landschaft
Wir gehen die Mandatsliste auf der Flughoehe durch, auf der die Partnerin sie ohnehin fuehrt: Anzahl Mandate, welches Buchhaltungstool pro Mandat (Bexio, Abacus, Sage, Mischbetrieb), welche Eingangskanaele heute genutzt werden (E-Mail, WeTransfer, Portale), wo der Engpass tatsaechlich sitzt. Ergebnis ist ein Ein-Seiten-Workflow pro repraesentativem Mandatstyp.
Pilot: ein Mandat, eine Belegart
Wir waehlen ein laufendes Mandat und eine Belegart aus — meistens Spesenbelege oder Lieferantenrechnungen — und fuehren sie durchgaengig durch die Pipeline. Mit dem echten Kontenplan des Mandanten, dem echten MWST-Profil und den echten Pruefrollen. Keine Sandbox, keine synthetischen Daten.
HITL nach dem Treuhand-Rollenmodell
Die Pruefung ist an die Arbeitsweise des Bueros gebunden: Junior bucht den Vorschlag, Senior prueft und korrigiert, Partner gibt alles oberhalb einer Eskalationsschwelle frei. Jede Aenderung wird auf User und Quelldokument protokolliert, so dass die Revisionsspur einer OR-konformen Aufbewahrung von Anfang an folgt.
Skalierung auf die ganze Mandantenliste
Sobald das erste Mandat stabil laeuft, erweitern wir horizontal — weitere Mandate, weitere Belegarten, weitere Bankfeeds. Die mandantenweise Trennung sorgt dafuer, dass Prompts, Kontenplan und Pruefrollen jedes Kunden eigenstaendig bleiben. Ein neues Mandat ist Konfiguration, kein Redeploy.
Wir gehen die Mandatsliste auf der Flughoehe durch, auf der die Partnerin sie ohnehin fuehrt: Anzahl Mandate, welches Buchhaltungstool pro Mandat (Bexio, Abacus, Sage, Mischbetrieb), welche Eingangskanaele heute genutzt werden (E-Mail, WeTransfer, Portale), wo der Engpass tatsaechlich sitzt. Ergebnis ist ein Ein-Seiten-Workflow pro repraesentativem Mandatstyp.
Wir waehlen ein laufendes Mandat und eine Belegart aus — meistens Spesenbelege oder Lieferantenrechnungen — und fuehren sie durchgaengig durch die Pipeline. Mit dem echten Kontenplan des Mandanten, dem echten MWST-Profil und den echten Pruefrollen. Keine Sandbox, keine synthetischen Daten.
Die Pruefung ist an die Arbeitsweise des Bueros gebunden: Junior bucht den Vorschlag, Senior prueft und korrigiert, Partner gibt alles oberhalb einer Eskalationsschwelle frei. Jede Aenderung wird auf User und Quelldokument protokolliert, so dass die Revisionsspur einer OR-konformen Aufbewahrung von Anfang an folgt.
Sobald das erste Mandat stabil laeuft, erweitern wir horizontal — weitere Mandate, weitere Belegarten, weitere Bankfeeds. Die mandantenweise Trennung sorgt dafuer, dass Prompts, Kontenplan und Pruefrollen jedes Kunden eigenstaendig bleiben. Ein neues Mandat ist Konfiguration, kein Redeploy.
Warum diese Loesung zum Schweizer Treuhand-Alltag passt, nicht ein generisches OCR
Eine Schicht ueber Bexio, Abacus und Sage — kein Ersatz
Das Buchhaltungstool, fuer das sich das Buero vor Jahren entschieden hat, ist dort, wo das Hauptbuch lebt, wo Abschluesse gezogen werden und wo die Revision sich einloggt. Daran ruetteln wir nicht. Die Dokumenten-KI-Schicht uebernimmt die Dokumentenlast vor dem Hauptbuch und uebergibt die buchungsfertige Datei ueber die Importschnittstelle, die Bexio, Abacus oder Sage ohnehin anbieten — CSV in der gewohnten Spaltenkonvention oder die jeweilige Treuhand-API, wo vorhanden.
Mandantenweise Trennung, so wie das Buero ohnehin denkt
Jedes Treuhand-Mandat hat einen eigenen Auftraggeber, einen eigenen Kontenplan, ein eigenes MWST-Profil und eine eigene Vertraulichkeitsgrenze. Die Pipeline spiegelt das: Jedes Mandat ist ein eigener Arbeitsbereich mit eigenem Dokumentenspeicher, eigener Prompt-Konfiguration und eigenen Pruefrollen. Dokumente und Prompts kreuzen die Mandantenlinie nicht. Die Sicht der Partnerin auf das Buero ist die Sicht im System.
Rollenbasierte Pruefung: Junior verbucht, Senior prueft, Partner gibt frei
Treuhand-Arbeit kennt ein Qualitaetstor, kein Freibad. Die Pruefoberflaeche ist um drei reale Rollen herum gebaut. Die juniore Person nimmt den Buchungsvorschlag an oder korrigiert ihn; die senior Person gibt die Tagescharge frei; die Partnerin oder der Partner sieht Eskalationen und alles oberhalb einer konfigurierbaren Schwelle. Jede Aenderung haengt an User, Dokument, Prompt-Version und Zeitstempel — die Revisionsspur, die eine OR-konforme zehnjaehrige Aufbewahrung erwartet, faellt als Nebenprodukt des Workflows an.
Schweizer Datenresidenz und OR-konforme Aufbewahrung
Mandantendokumente bleiben auf Schweizer Hosting (AWS Zuerich) oder auf kundeneigenen Servern, wenn das Buero das so will. Die Aufbewahrung wird pro Mandat so konfiguriert, dass sie den Erwartungen des Schweizer Obligationenrechts an buchhalterische Belege entspricht; die rechtliche Freigabe der Aufbewahrungspolitik bleibt beim Treuhandbuero, wo sie hingehoert. revDSG- und DSGVO-Posture sind Deployment-Vorlage, nicht Aufsatz.
Haeufig gestellte Fragen
Nein. Das Buchhaltungswerkzeug, das das Buero einsetzt, bleibt das fuehrende System. Wir sitzen davor als Dokumenten-KI-Schicht — wir nehmen Belege, Rechnungen, Bankauszuege und Lohndokumente an, bereiten die buchungsfertige Datei vor und uebergeben sie ueber die Standard-Importschnittstelle, die das Buchhaltungstool ohnehin akzeptiert.
Fuer Bexio, Abacus und Sage erzeugen wir das Importformat, das das Buero ohnehin nutzt — CSV in der Spaltenkonvention des jeweiligen Tools oder ueber die Treuhand-API, wo eine offizielle Schnittstelle existiert. Keine zurueck-engineerten privaten Endpoints, keine behauptete Partnerschaft; wir nutzen die Schnittstellen, die die Tools selbst dokumentieren.
Jedes Mandat ist ein eigener Arbeitsbereich mit eigenem Dokumentenspeicher, eigenem Kontenplan, eigenem MWST-Profil, eigener Prompt-Konfiguration und eigenen Pruefrollen. Eine juniore Person, die fuer Mandat A zustaendig ist, sieht Mandat B nicht. Die Rollenbindung sitzt auf der Bearbeitungsoberflaeche, nicht in einer separaten ACL-Ebene.
Drei Rollen sind ab dem ersten Tag verdrahtet. Die juniore Person nimmt den Buchungsvorschlag an, korrigiert oder verwirft ihn. Die senior Person prueft die Tagescharge und loest Auffaelligkeiten. Die Partnerin oder der Partner sieht alles oberhalb einer konfigurierbaren Eskalationsschwelle — unklare MWST, ungewoehnliche Betraege, fehlende Belege — und gibt Abschlussperioden frei.
Auf Wunsch ja. Das Standard-Schweiz-Deployment laeuft auf AWS Zuerich; ein Deployment auf kundeneigenen Servern ist fuer Bueros mit strengeren Souveraenitaets-Anforderungen verfuegbar. Der Apertus-Pfad ist die Option, wenn die Anforderung lautet 'kein oeffentlicher Modell-Endpunkt darf die Daten beruehren'.
Die Aufbewahrung wird pro Mandat so konfiguriert, dass sie sich an den Erwartungen von Art. 957a und 958f OR an die buchhalterische Archivierung orientiert. Der technische Aufbewahrungsmechanismus ist eingerichtet; die rechtliche Freigabe der Aufbewahrungspolitik bleibt beim Treuhandbuero, das die regulatorische Beziehung zum Mandanten traegt.
Mandantendaten werden unter einem schriftlichen Auftragsverarbeitungsvertrag verarbeitet, das Treuhandbuero ist Verantwortlicher. Schweizer Residenz ist Standard. Zugriffe sind rollenbasiert, jedes Lesen und Bearbeiten wird protokolliert, und die Revisionsspur folgt dem Dokument ueber die gesamte Mandantenlaufzeit. revDSG- und DSGVO-Posture sind Teil der Deployment-Vorlage.
Wenn das Buero ein Mandantenportal moechte, laedt der Mandant Dokumente hoch und sieht den Status — erhalten, in Pruefung, verbucht. Andere Kunden des Bueros sieht er nie, ebenso wenig die internen Pruefaktionen, Prompts oder Reviewer-Kommentare. Soll der Eingang vollstaendig intern bleiben, kann der Mandantenkanal schlicht E-Mail bleiben und die Pipeline uebernimmt ab dort.
Über SAPIENTROQ
Sind Sie an einer Lösung interessiert?
Wir freuen uns, Ihnen die Möglichkeiten unverbindlich aufzuzeigen.
Roland Kurmann
CEO, SAPIENTROQ
