Stufe 1 — Der konkrete Einstieg

Automatische
Vorkontierung

Rechnungen automatisch erkennen, klassifizieren und vorkontieren — vom Email-Postfach bis zum fertigen DATEV-Buchungsvorschlag. Der Sachbearbeiter prüft und gibt frei. Der schnellste Weg zu messbarer Zeitersparnis.

~75%
Zeitersparnis
7
AI-Kontierungsschritte
11
Steps bis DATEV
XML v6
DATEV-Schnittstelle
Der Weg einer Rechnung

Von der Email bis zur DATEV-Buchung

Jede Rechnung durchläuft denselben strukturierten Prozess — automatisch, nachvollziehbar, abbrechbar an jedem Punkt.

1
Eingang

Email, Upload oder OneDrive — PDFs werden automatisch erkannt und übernommen.

2
OCR & Klassifikation

Text-Extraktion und KI-Einordnung: Absender, Kategorie, vorgeschlagene Aktionen.

3
Dokumenttyp bestätigt

Ein Blick, ein Klick: Prüfen und Folgeworkflow starten.

4
7-Schritt-Kontierung

Sechs spezialisierte Bots extrahieren, prüfen und bebuchen jede Position einzeln.

5
DATEV XML-Export

Buchung + Beleg als XML-ZIP — per Belegtransfer direkt in DATEV verknüpft.

Phase 1 & 2

So kommt die Rechnung rein

Drei Eingangskanäle, eine einheitliche Verarbeitung. Kein manuelles Ablegen, kein manuelles Einlesen.

Email-Postfach

Rechnungen an ein dediziertes Postfach weiterleiten. Microsoft Graph API holt sie ab, extrahiert PDF-Anhänge und entfernt Präfixe wie FW/WG/AW automatisch.

Standardweg

Manueller Upload

Drag & Drop direkt in die Oberfläche — ideal für Post, Fotos oder einzelne Belege unterwegs.

Ergänzend

SharePoint / OneDrive

Synchronisierte Eingangsordner, für bestehende Ablagestrukturen.

Optional

OCR & Text-Extraktion

Vierstufige OCR-Kaskade — immer der beste verfügbare Weg:

  1. pdf-parse — direkter Textlayer (schnell, kostenlos)
  2. Encodian — Azure Germany West Central (EU-konform)
  3. KI-Vision — Fallback für Scans und Fotos
  4. Tesseract — lokaler Fallback

QuickClassifier Bot

Ein einziger Bot statt sechs: Absender, Zusammenfassung, Kategorie und vorgeschlagene Folgeaktionen in einem Durchlauf.

Absender Betreff Kategorie Confidence Auto-Bestätigung ab 80%
Workflow · rechnung-business

Eingangsrechnung — 11 Schritte

Ein automatischer, sieben KI-gestützte, ein manueller und zwei abschließende Schritte. Jeder Schritt liefert strukturiertes Output — im Zweifel jederzeit prüfbar.

1
Dokumenttyp bestätigt
Basisdaten übernommen, Rechnung erkannt.
auto
2
Beleg-Extraktion
Positionen, Beträge, Lieferant, Fälligkeit.
Bot 1
3
Quellen-Konsistenz
Netto + USt = Brutto? Summen, Datumslogik.
Bot 2
4
Positions-Analyse
GWG, Anlage, Bewirtung 70/30, Privatanteile.
Bot 3
5
Kontenrahmen & Kostenart
SKR03 / SKR04 / SKR49 / IKR · Kostenart-Taxonomie.
Bot 4
6
Konten-Matching
Konten, BU-Schlüssel, Kreditorenkonto — lernt aus der Historie.
Bot 5
7
Steuer- & Buchungslogik
DATEV-Steuerschlüssel (2=7%, 3=19%, 0=steuerfrei).
Bot 5
8
Buchungsvorschlag
DATEV-Zeilen (Brutto) + Journal (aufgelöst).
Bot 6
9
Kontierung prüfen
Checkliste: Konten, Schlüssel, Journal-Balance.
manuell
10
DATEV XML-Export
Buchungsdaten + Original-PDF als DATEV-XML (v6) — ZIP für Belegtransfer. Beleg und Buchung automatisch verknüpft.
auto
11
Mandant informieren
Status-Benachrichtigung: Beleg verarbeitet, Buchung in DATEV. Erster Schritt Richtung gemeinsame digitale Plattform.
auto
Beispiel

Apple AirPods · 238,00 EUR brutto

Eingangsrechnung ER-2026-042, bezahlt per Überweisung. Nettobetrag 200 EUR → automatische GWG-Klassifikation.

DATEV-Zeile (EXTF)
238,00;S;EUR;;;0480;1600;3;0204;ER-2026-042;;;Apple AirPods GWG
Journal (intern aufgelöst)
KontoBezeichnungSollHaben
0480GWG200,00--
1576Vorsteuer 19%38,00--
1600Verbindlichkeiten--238,00
Summen (balanced)238,00238,00
Die sechs Kontierungs-Bots

Ein Bot pro Aufgabe — statt einer Blackbox

Jeder Schritt ist isoliert, prüfbar und wiederholbar. Wenn etwas schiefgeht, weiss man exakt wo.

BOT 1

Beleg-Extraktion

Erfasst Lieferant, Rechnungsnummer, Datum, Fälligkeit und jede einzelne Position mit Menge, Einzelpreis und Steuersatz.

→ vendor, positions[], taxBreakdown
BOT 2

Quellen-Konsistenz

Prüft die Extraktion gegen den OCR-Text: Rechenlogik, Summen, plausible Datumsangaben. Korrekturen werden dokumentiert.

→ validated, corrections[], checks
BOT 3

Positions-Analyse

GWG-Schwellen (250 EUR / 800 EUR), Anlage-Klassifikation mit AfA, Bewirtung 70/30-Split, Privatanteile je Position.

→ classification, splits[], afaInfo
BOT 4

Kontenrahmen & Kostenart

Ordnet jede Position einer Kostenart zu — Bürobedarf, Telekom, Bewirtung, GWG, Anlage, Fremdleistungen, u.v.m.

→ kontenrahmen, kostenart, indizien[]
BOT 5

Konten-Matching

Findet konkrete Konten (0480, 4930, 4650, ...) und BU-Schlüssel. Nutzt die bisherigen Buchungen und die DATEV-Kreditoren als Kontext — wer Telekom schon immer auf 4920 gebucht hat, bekommt auch diesmal 4920. Ordnet den richtigen Kreditor zu oder schlägt ein neues Konto vor.

→ hauptkonto, personenkonto, historyMatch
BOT 6

Buchungsvorschlag

Baut DATEV-Zeilen (Brutto mit Automatikkonto) und das aufgelöste Journal. Balance-Check ist Pflicht.

→ datevZeilen[], journal[], balanced
Kreditorenkonten & Lernfähigkeit

Richtiges Kreditorenkonto statt Sammelkonto

DATEV führt die Kreditoren — wir schlagen das richtige Konto vor. Bot 5 lädt die bestehenden Kreditorenkonten aus DATEV und ordnet jeden Lieferanten korrekt zu. Bei neuen Lieferanten wird ein Vorschlag für ein neues Kreditorenkonto gemacht.

Kreditoren

DATEV-Kreditoren als Kontext

Ohne
Sammelkonto 1600
Alle Lieferanten auf 1600. Kein OP-Abgleich, keine Auswertung je Lieferant.
Mit Vorkontierung
Richtiger Kreditor
Kreditorenkonto aus DATEV (ab 70000). Bekannter Lieferant → automatisch zugeordnet. Neuer Lieferant → Vorschlag.
  • Kreditorenstamm wird aus DATEV geladen (SuSa / Stammdaten)
  • Erkennung über Name, USt-ID, IBAN — auch bei Schreibvarianten
  • Neuer Lieferant: Kreditorenkonto-Vorschlag im XML-Export
  • DATEV legt den Kreditor an — wir liefern die Zuordnung
Bot 5 lernt mit

Historie als Kontext

Beim Konten-Matching bekommt Bot 5 nicht nur den aktuellen Beleg, sondern auch die bisherigen Buchungen als Entscheidungshilfe.

Konsistenz statt Raten
Einmal richtig gebucht, bleibt die Zuordnung stabil — auch über Monate.
Keine Regelpflege
Kein statisches Regelwerk, keine Keyword-Listen. Der Bot lernt durch das Buchungsverhalten.
Kreditor wird wiedererkannt
Gleiche Firma → gleiches Personenkonto, auch bei unterschiedlicher Schreibweise.
Transparent in der Prüfung
Jeder Vorschlag wird mit dem passenden historischen Beleg belegt — nachvollziehbar, kein Blackbox-Effekt.
Integration

DATEV XML-Schnittstelle — Beleg + Buchung in einem

Nach der Kontierung werden Buchungsdaten und Original-PDF als DATEV-XML (Version 6) exportiert. Über Belegtransfer landen Beleg und Buchung verknüpft in DATEV — kein manuelles Zuordnen, kein Medienbruch.

Kernfeature

DATEV XML-Schnittstelle online (Version 6)

Nach der Kontierung werden Buchungsdaten + Originalbelege als DATEV XML-Schnittstelle online exportiert. Eine ZIP-Datei, die über DATEV Belegtransfer direkt nach DATEV Belege online / DATEV Rechnungswesen übertragen wird — mit automatischer Verknüpfung von Beleg und Buchung.

Format 1 — Invoice (Rechnungsdaten)

Für Eingangsrechnungen mit Rechnungskopf + Positionen.

Pflichtfelder aus Extraktion: Bruttobetrag, Währung, Rechnungsnr., Datum, Leistungsdatum, Steuer, Geschäftspartner
Aus Kontierung: Sachkonto, Gegenkonto (Kreditor/Debitor), BU-Schlüssel, KOST1/KOST2, Fälligkeit, USt-IdNr.
Format 2 — Ledger (Belegsatzdaten)

Für fertige Buchungssätze — eine Zeile pro Buchung, einfacher.

Pflichtfelder: Betrag, Währung, Rechnungsnr., Datum, Geschäftspartner
Empfehlung: Ledger-Format nutzen, da wir bereits fertige Kontierungen liefern.
// ZIP-Struktur
export_2026-04-18_14-30.zip
├── document.xml     // Rechnungs- oder Belegsatzdaten
├── Rechnung_001.pdf // Original-Beleg → automatisch verknüpft
├── Rechnung_002.pdf
└── ...
Phase 1: Einzel-Export
Download-Button pro Dokument nach Kontierung
Phase 2: Batch-Export
Sammel-ZIP für Zeitraum (Monat/Woche)
Phase 3: Auto-Upload
Belegtransfer-API (optional)
Ablauf

Von der Kontierung in DATEV

  1. Kontierung abgeschlossen — Buchungsvorschlag geprüft und freigegeben
  2. XML generieren — Buchungsdaten als DATEV-XML (v6), Original-PDF als Beleg
  3. ZIP erstellen — document.xml + alle PDFs in einer Datei
  4. Download oder Batch — Einzel-Download pro Beleg oder Sammel-Export pro Monat
  5. Belegtransfer — ZIP in DATEV Belegtransfer importieren
  6. In DATEV verknüpft — Buchung + Beleg erscheinen zusammen in Belege online
Mapping

Kontierung → DATEV XML-Felder

Alle Daten die DATEV braucht, sind nach den 7 Kontierungs-Bots vorhanden:

Bot 1: Beleg-Extraktion → Rechnungsnr., Datum, Betrag, Absender, USt-IdNr.
Bot 3: Positions-Analyse → Positionen mit Netto/Brutto/Steuer
Bot 4: Kontenrahmen → Sachkonto (SKR03/04), KOST1/KOST2
Bot 5: Konten-Matching → Kreditorenkonto (aus DATEV oder Vorschlag), BU-Schlüssel
Bot 6: Buchungsvorschlag → DATEV-Zeilen, Steuerschlüssel, Buchungstext
Warum Vorkontierung

Der konkreteste Hebel für ACP

Automatisiert wo möglich, prüfbar wo nötig, nachvollziehbar in jedem Schritt.

Zero Manual Data Entry

Alle Daten aus OCR und KI — kein manuelles Abtippen, nirgends.

Prüfbar in jedem Schritt

Strukturiertes Output pro Bot, Debug-Panel in jedem Step.

EU-konform

OCR & KI in Azure Germany West Central, EU-gehostete Mammouth-Modelle.

GoBD-tauglich

Audit-Trail, Event-Sourcing, unveränderliche Archivierung.

Ein Klick zu DATEV

Automatischer Upload an Unternehmen Online — kein Medienbruch.

Lernt aus der Historie

Bot 5 nutzt bisherige Buchungen als Kontext — konsistente Kontierung ohne Regelpflege.

Kreditoren aus DATEV

Richtiges Kreditorenkonto statt Sammelkonto — DATEV-Stammdaten als Kontext.

Wochen, nicht Monate

Vom Setup bis zur ersten produktiven Nutzung in wenigen Wochen.

Infrastruktur & Sicherheit

Europäisch gehostet. Prüfbar verankert.

Keine US-Clouds im Daten-Pfad. Jede Komponente ist austauschbar, jede Verarbeitung nachvollziehbar.

Hosting

IONOS Cloud (Deutschland), PostgreSQL auf Managed Database, PM2-Prozess, nginx als Reverse Proxy mit Let's-Encrypt-SSL.

IONOSDEPM2

Datenhaltung

PostgreSQL, eigene Datenbank für ACP. Strikte Trennung, Backups verschlüsselt.

PostgreSQLEigene DB

KI-Modelle

Mammouth.ai (EU-gehostet), OpenAI-kompatibel. Modell: mistral-large-3. Keine Daten verlassen den EU-Raum, jeder AI-Call wird geloggt und bepreist.

MammouthEUMistral Large 3

Authentifizierung

NextAuth mit Azure AD OAuth. Single Sign-On über den bestehenden Microsoft-Tenant, keine separaten Passwörter.

Azure ADSSOOAuth

OCR & Dokumente

Encodian OCR in Azure Germany West Central. PDFs werden lokal auf dem Server gespeichert, keine externen Zwischenablagen.

EncodianAzure DE

Observability

Strukturiertes Error-Log, Process-Tracking pro Dokument, HTTP-Log pro externem Call, AI-Usage-Log mit Kostenstelle.

Error-LogProcess-TrackingAI-Usage

GoBD & Revisionssicherheit

Event-Sourcing für jeden Workflow, unveränderliche Dokument-Versionen, vollständiger Audit-Trail pro Step und Freigabe.

GoBDAudit-Trail

Deployment

GitHub Actions Pipeline, Next.js Standalone, Zero-Downtime Restart via PM2, Rollback per Commit.

GitHub ActionsNext.js 14

Bot-Instructions

Alle Bot-Prompts in der Datenbank, editierbar über Admin-UI. Kein Code-Deploy für fachliche Anpassungen.

EditierbarVersioniert
Standortbestimmung

Was erreicht ist — und was als nächstes kommt

Ehrlicher Blick auf den aktuellen Stand: fertig ist, was fertig ist. Der Rest steht auf der Liste.

Erreicht

Was heute schon läuft

Durchgängiger Prozess vom Postfach bis zur Buchung
Email-Import, OCR, Klassifikation, Dispatch, Folgeworkflows
6-Bot-Kontierung für Eingangsrechnungen
Positionsgenau, mit GWG/Anlage/Bewirtung-Logik
DATEV XML-Schnittstelle (v6) konzipiert
Buchung + Beleg als ZIP, Belegtransfer-kompatibel
Kontenrahmen wählbar
SKR03 / SKR04 / SKR49 / IKR, pro Mandant konfigurierbar
Admin-Config ohne Code-Deploy
Workflows, Bots, Preise, Postfächer editierbar in der UI
Observability in jedem Step
Debug-Panel, HTTP-Log, strukturierte Outputs
Azure AD SSO & EU-Hosting
Authentifizierung und Datenhaltung vollständig in der EU
Nächste Schritte

Was als nächstes kommt

Die Vorkontierung ist fertig entwickelt. Jetzt geht es darum, sie für ACP produktiv zu machen — mit eigener Instanz, eigenem Kontenrahmen und echten Belegen.

1
Entwicklungsumgebung aufsetzen
Eigene Dev-Instanz für ACP: Datenbank, PM2-Prozess, Zugänge. Erreichbar unter einer eigenen Subdomain.
2
DATEV XML-Schnittstelle
DATEV XML v6 Generator implementieren — Rechnungsdaten + Belegsatzdaten, ZIP mit PDF-Belegen, Belegtransfer-Import.
3
Kontenrahmen & Account-Mappings anpassen
ACP-spezifische Kontenzuordnungen, Kostenarten, Personenkonten-Bereiche. Abgestimmt auf die bestehende DATEV-Struktur.
4
Pilot mit echten Belegen
20-50 echte Rechnungen durchlaufen lassen. Kontierungsqualität messen, Korrekturen dokumentieren, Feintuning der Bots.
Wie es danach weitergeht

Stufe 1 ist der Einstieg. Die Evolutionsstufen zeigen den ganzen Weg.

Die Vorkontierung ist der schnellste Weg zu messbarem Nutzen. Aber sie ist nur der Anfang. Wie die nächsten Stufen aussehen — vom vollen Dokumenteneingang über Workflow-Automatisierung bis zur digitalen Kanzlei-Gruppe — steht in der Evolutionsübersicht.

Evolutionsstufen ansehen