datvia
Technical PRD v1.0 · August 2026

Eine Entwicklungsblaupause,
keine KI-Demo.

Das MVP konzentriert sich auf einen einzigen wertvollen End-to-End-Prozess: Eingangsrechnung → Erkennung → Kontierungsvorschlag → Confidence/Risk → menschliche Ausnahmeprüfung → Pre-DATEV Validation → DATEV-Übergabe.

Multi-TenantEvent-drivenIdempotentAppend-only Audit
MVP-Scope

Bewusst eng geschnitten

In Scope

  • Multi-Tenant Kanzlei/Mandant
  • Benutzer, Rollen und Berechtigungen
  • E-Mail-/Datei-Inbox
  • PDF, Bild, XRechnung, ZUGFeRD
  • Dokumentklassifikation und Extraktion
  • Lieferantenerkennung
  • SKR03/SKR04-Kontierungsvorschläge
  • Steuerschlüssel- und Kostenstellenvorschlag
  • Accounting Memory
  • Confidence/Risk Engine
  • Exception Review
  • Audit Trail
  • Pre-DATEV Validator
  • DATEV Connector für den Pilot-Use-Case
  • Monitoring und KPI Dashboard

Explizit nicht im ersten MVP

  • Vollautomatischer Zahlungsverkehr
  • Lohnbuchhaltung
  • Jahresabschlussautomatisierung
  • Autonome Steuerberatung
  • Komplette ERP-Funktionalität
  • Alle denkbaren DATEV-Schnittstellen gleichzeitig
  • Generische Chat-Funktion ohne Buchhaltungs-Use-Case
UJ-01 · Rechnung automatisch verarbeiten

Zwölf Schritte ohne Handgriff

01

Rechnung trifft ein

02

System bestimmt Mandant

03

Dokument wird gehasht und unverändert gespeichert

04

Typ/Format wird erkannt

05

Felder + Positionen werden extrahiert

06

Lieferant wird gematcht

07

Accounting Proposal wird erzeugt

08

Rules + Risk + Confidence laufen

09

Policy entscheidet AUTO oder REVIEW

10

Validator prüft Exportfähigkeit

11

Freigabe / Export

12

Ergebnis + Evidenz werden auditiert

UJ-03 · Fehlende oder widersprüchliche Pflichtdaten

Das System erzeugt keine erfundenen Werte. Der Fall erhält einen maschinenlesbaren Exception Code – z. B. MISSING_INVOICE_NUMBER, TAX_MISMATCH oder UNKNOWN_VENDOR – und wird an den passenden Bearbeiter geroutet.

Screen-Spezifikation

Zehn Kernbildschirme

Login/SSO

MFA, Session Handling, Recovery

Kanzlei Dashboard

Mandantenstatus, Exceptions, Autonomy, Sync-Fehler

Mandanten Dashboard

Inbox, Verarbeitung, fehlende Daten, Exportstatus

Accounting Inbox

Filter, Quelle, Dokumenttyp, Status, Upload

Review Workspace

Dokumentviewer, Felder, Buchung, Evidenz, Confidence

Exception Queue

Priorität, Typ, Betrag, SLA, Owner, Bulk Actions

Vendor Profile

Stammdaten, Historie, Kontierungs-/Steuermuster

Policy Center

Autonomiegrenzen, Risk Overrides, Freigaberegeln

DATEV Integration

Verbindung, Mapping, Status, Fehler/Retry

Audit Log

Suche nach Dokument, User, Entscheidung, Export

Review Workspace · UX-Anforderung

Ein Standard-Review darf bei geübten Nutzern nur wenige Sekunden benötigen. Die Oberfläche zeigt zuerst die Entscheidung – nicht 30 Eingabefelder.

Keyboard Shortcuts: Accept, Edit, Skip, Escalate

Side-by-side Dokument und Buchung

Unsichere Felder visuell markieren

Confidence feld- und entscheidungsspezifisch, nicht nur global

„Warum?“ öffnet Evidenz statt generischer KI-Erklärung

Änderungen vor dem Speichern als Diff anzeigen

Review Workspace ansehen
Canonical Data Model

Entitäten und Kernfelder

Entity

tenants

Entity

companies

Entity

users

Entity

memberships

Entity

documents

Entity

invoices

Entity

vendors

Entity

proposals

Entity

exceptions

Entity

audit_events

Entity

export_jobs

EntityKernfelder
tenantsid, type, name, status, policy_set_id
companiesid, tenant_id, legal_name, chart_of_accounts, fiscal_year, datev_config_id
usersid, identity_provider_id, status
membershipsuser_id, tenant_id/company_id, role
documentsid, company_id, source, hash, storage_ref, doc_type, state
invoicesid, document_id, vendor_id, numbers, dates, net/tax/gross, currency
vendorsid, company_id, name, vat_id, iban_history, risk_flags
proposalsid, invoice_id, version, account, tax_key, cost_center, confidence
exceptionsid, invoice_id, code, priority, owner, sla, state
audit_eventsid, actor, tenant, company, action, payload_hash, ts (append-only)
export_jobsid, period, idempotency_key, record_count, state, ack_ref
Service-Landschaft

API Gateway → Domain Services → Event Bus → Worker

01Identity Service
02Document Service
03Invoice Service
04Vendor Service
05Accounting Service
06Exception Service
07Policy Service
08Integration Service
09Audit Service
Beispiel-Endpunkte
POST

/v1/documents

Upload / Registrierung

GET

/v1/documents/{id}

Dokument + Status

POST

/v1/invoices/{id}/reprocess

Pipeline erneut starten

GET

/v1/exceptions

Exception Queue

POST

/v1/exceptions/{id}/resolve

Entscheidung speichern

GET

/v1/vendors/{id}/memory

Mandantenhistorie

POST

/v1/proposals/{id}/approve

Buchung freigeben

POST

/v1/export-jobs

DATEV Export anstoßen

E-Mail Postfach

IN

XRechnung / ZUGFeRD

IDLE

Scan & Upload

IDLE

Engine

Domain Services & Event Bus

Worker → DATEV Transfer

Bankfeed (PSD2)

IDLE

Kassensystem

IDLE

DATEV Stammdaten

IDLE
Events & Jobs

Asynchron, idempotent, ohne Endlosschleifen

document.received

Hash, Mandantenzuordnung, unveränderte Ablage

document.classified

Extraktion + Evidence Spans

proposal.created

Rules, Risk und Confidence laufen

exception.opened

Routing nach Exception Code

export.failed

Retry / Dead-Letter + Alerting

human.correction_saved

Accounting-Memory Updater

Delivery-Regeln

  • At-least-once Delivery einkalkulieren
  • Jeder Consumer idempotent
  • Dead Letter Queue für nicht lösbare Jobs
  • Retries mit Exponential Backoff
  • Keine unendlichen AI-Reprocessing-Loops

Transfer Job · idempotency-key

EXP-3391
  1. QUEUED
  2. TRANSFER
  3. ACK
  4. COMMITTED
Retry mit BackoffKeine DoppelbuchungReconciliation-Report
document.receiveddocument.classifiedproposal.createdexception.openedexport.failedhuman.correction_saveddocument.receiveddocument.classifiedproposal.createdexception.openedexport.failedhuman.correction_saved

Kontrollierte AI-Pipeline

Modelle schlagen vor.

Regeln entscheiden.

Menschen bleiben Chef.

Structured Proposal → Confidence Calibration → Policy Gate. Kein Modell schreibt direkt in Datenbank oder DATEV.

AI Orchestration

LLMs erzeugen Vorschläge – niemals Schreiboperationen

Die AI-Schicht ist eine kontrollierte Pipeline: Structured Proposal → Confidence Calibration → Policy Gate. Kein Modell schreibt direkt in Datenbank oder DATEV.

AgentInputOutput
DocumentDatei / strukturierte XMLDocumentType + normalized fields + evidence spans
VendorFields + company vendorsvendor_id / new_vendor + similarity
AccountingInvoice + vendor memory + chartstructured proposal candidates
TaxProposal + Steuerregelngeprüfter Steuerschlüssel + Begründung
RiskProposal + Historie + PoliciesAnomalien, Dubletten, Hard Gates
ValidatorCanonical RecordREADY / BLOCKED + Fehlerliste

Regeln müssen deklarativ, versioniert, testbar und scope-basiert sein: global → Kanzlei → Mandant. Spezifischere Regeln überschreiben nur dort, wo die Policy es erlaubt.

Epics & Acceptance Criteria

Was „fertig“ bedeutet

EPIC 01 – Intake

  • Dokument wird gehasht und unverändert gespeichert
  • Mandantenzuordnung automatisch, Duplikate erkannt
  • Document State Machine ist nachvollziehbar

EPIC 02 – Document AI

  • Jedes extrahierte Feld besitzt Confidence und Evidence Reference
  • Summen-/Steuerarithmetik wird deterministisch geprüft
  • XRechnung/ZUGFeRD nutzt strukturierte Daten, wenn valide

EPIC 03 – Accounting Proposal

  • Vorschlag enthält Konto, Steuerschlüssel, Betrag, optional Kostenstelle
  • Proposal ist versioniert und über Model-/Rule-Versionen reproduzierbar
  • Kein Proposal wird automatisch freigegeben, wenn ein Hard Gate aktiv ist

EPIC 04 – Exception Review

  • Reviewer sieht Eskalationsgrund und relevante Evidenz
  • Korrektur erzeugt neue Proposal-Version
  • Entscheidung, Nutzer, Zeit und Grund werden auditiert
  • Nach Korrektur läuft die Validation erneut

EPIC 05 – DATEV Export

  • Nur READY-Datensätze können exportiert werden
  • Doppelter Request mit gleichem Idempotency Key erzeugt keinen Doppelexport
  • Technische Fehler retrybar, fachliche als Actionable Exception
  • Erfolg/Fehler in Audit und UI nachvollziehbar

Sprint-Reihenfolge

01 FoundationIdentity/RBAC, Tenant/Company, Audit, Storage, CI/CD
02 IntakeUpload, E-Mail Ingestion, Document State Machine
03 Document AIClassification, Extraction, Evidence, E-Invoice Parser
04 VendorVendor Matching, Accounting Memory, Risiko-Flags
05 AccountingProposals, Rules & Policy Engine, Confidence Engine
06 ExceptionsQueue, Review Workspace, Bulk Actions, SLA
07 DATEVMapping Layer, Validator, Transfer Jobs, Retry Queue
08 HardeningObservability, Security, Evaluation, Rollback
Observability

Metriken, die Missbrauch der Autonomie sichtbar machen

  • Queue Depth, Processing Latency, Error Rate
  • Model Usage/Cost pro Dokument und Mandant
  • Confidence Distribution
  • Auto vs Review vs Failed
  • DATEV First-Pass Success
  • Retry / Dead-Letter Counts
  • Vendor Match Drift
  • Alert bei ungewöhnlichem Anstieg von Auto-Processing oder Fehlern

Ein plötzlicher Anstieg der Autonomy Rate ist nicht automatisch positiv – er kann auf eine fehlerhafte Policy oder Confidence-Kalibrierung hindeuten.

Ingest
Extraktion
3Kontierung
4Validation
5Export

Hash-Kette · append-only

VERIFIED

9f2c…a41d

c701…8bb2

42ae…10f7

7d55…c39e

e8b0…5aa1

Pilot-Stufenmodell

Von Shadow bis Production

S1

Shadow

Ground Truth sammeln; Confidence kalibrieren

S2

Assisted

Schnelles Review; keine kritischen Auto-Fälle

S3

Guarded Auto

Nur sehr sichere, bekannte Standardfälle

S4

Expanded Auto

Schrittweise nach Vendor-/Case-Klassen

S5

Production

Kontinuierliche Monitoring- und Rollback-Prozesse

Pilot-Fortschritt

Shadow
  1. Shadow
  2. Assisted
  3. Guarded Auto
  4. Expanded Auto
  5. Production

Unmittelbarer nächster Schritt

DATEV Integration Spike starten · 20–30 Kanzlei-Interviews führen · 500–1.000 fachlich bestätigte Vorgänge als Evaluation Set aufbauen · Click Prototype testen · erst danach das MVP-Backlog final committen.

Pilotplatz anfragen