Dokumente automatisch auslesen und prüfen mit KI: selbst gehostet

Belege werden heute von Hand abgetippt und geprüft? WZ-IT baut Auslesen, Prüfregeln und Freigabe für einen abgegrenzten Belegtyp auf Ihrer Infrastruktur, siehe KI-Dokumentenverarbeitung im KI-Hub. Vorhaben gemeinsam einordnen

Seit dem 1. Januar 2025 muss jedes inländische Unternehmen E-Rechnungen empfangen können. Ein Teil der Belege kommt damit als strukturiertes XML an und wird geparst statt gelesen. Der größere Teil bleibt, was er war: PDF im Postfach, Scan, Foto vom Kassenbon, Lieferschein auf Papier. Nach Eurostat versandten 2023 nur 24,4 Prozent der deutschen Unternehmen Rechnungen in einem automatisiert verarbeitbaren Format, 81,3 Prozent verschickten PDF (Eurostat, isoc_eb_ics).

Dieser Beitrag beschreibt, wie Dokumente in einem Mittelstandsunternehmen automatisch ausgelesen und geprüft werden: welche Belegarten strukturiert ankommen und welche nicht, was Vision-Language-Modelle gegenüber OCR geändert haben, warum die Prüfung gegen Regeln und Register die eigentliche Arbeit ist, was die GoBD dazu verlangen, und wann der Betrieb auf eigener Infrastruktur der richtige Weg ist. Stand September 2026.

Inhaltsverzeichnis

1. Was die E-Rechnungspflicht ändert und was unstrukturiert bleibt
2. Bei E-Rechnungen wird geparst und geprüft, nicht geschätzt
3. Auslesen: OCR, Layout-Modelle und Vision-Language-Modelle
4. Prüfen ist die eigentliche Arbeit
5. Konfidenz, Freigabe und die richtige Kennzahl
6. GoBD: was bei OCR und KI aufzubewahren ist
7. Selbst gehostet oder API: Datenschutz, AI Act, Betrieb
8. Unser Vorgehen bei WZ-IT
9. Weiterführende Guides

Was die E-Rechnungspflicht ändert und was unstrukturiert bleibt

Das Wachstumschancengesetz hat § 14 UStG neu gefasst. Eine E-Rechnung ist seitdem eine Rechnung, die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht (§ 14 Abs. 1 Satz 3 UStG). Alles andere, also Papier und einfache PDF, ist eine sonstige Rechnung.

Die Fristen sind gestaffelt:

Wer eine E-Rechnung nicht annehmen kann, hat keinen Anspruch auf eine Papierrechnung (BMF 15.10.2024, Rn. 42). Zulässig sind Formate nach EN 16931, insbesondere XRechnung und ZUGFeRD ab Version 2.0.1 ohne die Profile MINIMUM und BASIC-WL (Rn. 25), außerdem vereinbarte Formate wie Factur-X oder Peppol BIS Billing (Rn. 26). Das maßgebliche BMF-Schreiben vom 15. Oktober 2024 wurde am 15. Oktober 2025 geändert und in den Umsatzsteuer-Anwendungserlass überführt (BMF vom 15.10.2025).

Dauerhaft ausgenommen bleiben Kleinbetragsrechnungen bis 250 Euro (§ 33 UStDV), Fahrausweise (§ 34 UStDV), Rechnungen von Kleinunternehmern (§ 34a UStDV, nur beim Ausstellen), Rechnungen an Privatkunden und Rechnungen über steuerfreie Umsätze nach § 4 Nr. 8 bis 29 UStG.

Für die Belegverarbeitung heißt das: Genau eine Belegart wird strukturiert, und auch sie nur schrittweise.

Die Einordnung in der letzten Spalte ist eine Praxiseinschätzung, kein erhobener Wert. Die Richtung bestätigt Eurostat: In Deutschland versandten 2023 Unternehmen mit 10 bis 49 Beschäftigten zu 20,8 Prozent strukturierte Rechnungen, Unternehmen ab 250 Beschäftigten zu 57,8 Prozent (Eurostat).

Bei E-Rechnungen wird geparst und geprüft, nicht geschätzt

Eine XRechnung oder das XML einer ZUGFeRD-Datei braucht kein Modell. Das Format ist definiert, die Felder haben Kennungen (BT-1 Rechnungsnummer, BT-10 Buyer Reference, BT-112 Bruttobetrag), und die Prüfung ist regelbasiert.

Drei Dinge sind dabei festgelegt und für den Prozess entscheidend:

Der strukturierte Teil ist führend. Bei einem hybriden Format wie ZUGFeRD gehen die XML-Daten der Bilddatei vor. Das BMF hat das Verhältnis mit der obligatorischen E-Rechnung ausdrücklich umgekehrt: Lesbarkeit heißt jetzt Maschinenlesbarkeit, und der Vorsteuerabzug ist nur aus dem strukturierten Teil möglich (BMF 15.10.2024, Rn. 31 und 32; seit 2025 UStAE Abschn. 14.4 Abs. 3). Ein Prozess, der bei ZUGFeRD das PDF durch OCR schickt, prüft den falschen Teil.

Validierungsberichte dokumentieren das Prüfergebnis. Ein Unternehmer darf sich auf das technische Ergebnis einer geeigneten Validierungsanwendung verlassen; zum Nachweis empfiehlt das BMF, den Validierungsbericht aufzubewahren (BMF 15.10.2025, Rn. 35a). Reine Geschäftsregelfehler bei Nicht-Pflichtangaben sind umsatzsteuerlich unbeachtlich, das BMF nennt als Beispiel das fehlende Feld BT-10, denn im B2B gibt es keine Leitweg-ID.

Die Werkzeuge sind offen. Die EN-16931-Artefakte der EU-Kommission stehen unter EUPL 1.2, aktuell Release validation-1.3.16 vom 13. April 2026 (ConnectingEurope/eInvoicing-EN16931). Der KoSIT-Validator ist Apache-2.0-lizenziert, Version 1.6.3 vom 20. August 2026 (itplr-kosit/validator), die XRechnung-Konfiguration 2026-08-31 für XRechnung 3.0.2 (validator-configuration-xrechnung). Version 1.6.3 schließt eine Schwachstelle bei der URI-Auflösung (GHSA-hg2c-p2m3-q29m); wer den Validator selbst betreibt, sollte mindestens diese Version einsetzen. Einen offiziellen Online-Validator gibt es in Deutschland nicht; die EU stellt einen bereit (itb.ec.europa.eu).

Die Prüfung hat zwei Ebenen. Die semantischen Geschäftsregeln (BR-Regeln, rund 200) sind syntaxunabhängig: Rechenlogik, Kardinalitäten, Umsatzsteuerkategorien. Die Syntaxbindungen (583 für CII, 756 für UBL) prüfen den konkreten XML-Baum. Ein Fehler in BR-CO-10 ist ein fachlicher Rechenfehler, ein Fehler in CII-SR-465 ein Strukturfehler.

Ausblick: EN 16931-1:2026 ist ratifiziert, die deutsche Fassung wird bis Ende September 2026 erwartet, eine Vorabversion von XRechnung 4.0 im September 2026, ausdrücklich nicht produktionsreif. Das Ende der Parallelnutzung ist für März 2029 angekündigt (KoSIT, 1. September 2026).

Auslesen: OCR, Layout-Modelle und Vision-Language-Modelle

Für alle Belege, die nicht als XML ankommen, beginnt die Arbeit mit dem Auslesen. Drei Werkzeugklassen stehen dafür zur Verfügung, alle als Open Source.

OCR liefert Zeichen mit Positionen. Für ein Feld wie „Rechnungsnummer" braucht es danach Regeln, wo auf der Seite die Nummer steht. Das ist die Vorlage je Lieferant, die klassische Belegerkennung erforderte.

Dokumentmodelle wie Docling erkennen Seitenstruktur, Tabellen und Leserichtung und geben ein strukturiertes Dokument zurück. Die Tabelle eines Lieferscheins bleibt eine Tabelle.

Vision-Language-Modelle lesen die Seite als Bild und geben auf eine Anweisung hin direkt Werte zurück, etwa als JSON mit Rechnungsnummer, Datum, Positionen und Beträgen, ohne Training je Lieferant. Qwen3-VL ist in allen Größen Apache-2.0-lizenziert und damit für den Betrieb im Unternehmen unproblematisch. Beim Vorgänger Qwen2.5-VL gilt das nur für die Varianten 7B und 32B; die 3B-Variante steht unter einer reinen Forschungslizenz (Modellkarte Qwen2.5-VL-3B). Modelle, die darauf aufbauen, erben diese Einschränkung. Bei Marker und Surya ist der Code Apache-2.0, die Modellgewichte stehen unter einer OpenRAIL-M-Lizenz mit einer Umsatzgrenze von fünf Millionen US-Dollar (Marker README).

Was sich damit geändert hat: Das Auslesen unbekannter Layouts funktioniert ohne Vorlage. Was sich nicht geändert hat: Ein Modell liefert plausible Werte, keine geprüften. Eine Summe, die im Bild schlecht lesbar ist, kommt als saubere Zahl zurück, ob richtig oder nicht. Die deutsche Anbieterseite blumatix benennt die Grenzen offen: begrenztes Verständnis für zweidimensionale Layouts, Token-Grenzen, fehlende Kenntnis firmenspezifischer Daten (blumatix). Genau deshalb ist das Auslesen der kleinere Teil.

Für Paperless-ngx-Nutzer: Seit Version 3.0.0 vom 22. Juli 2026 bringt Paperless-ngx eine eigene KI-Integration mit Ollama-Embeddings mit (Paperless-ngx Releases). Das Plugin paperless-ai ist seit März 2026 nicht mehr gepflegt; paperless-gpt wird weiterentwickelt. Paperless-ngx ist ein Dokumentenarchiv mit Volltext und Verschlagwortung, keine Prüfstrecke mit Regeln und Freigabe. Wie es aufgesetzt wird, steht im Paperless-ngx-Guide.

Prüfen ist die eigentliche Arbeit

Nach dem Auslesen liegt je Beleg ein Satz Kandidaten vor. Ob ein Beleg ohne Menschen weiterlaufen darf, entscheiden Regeln, die kein Modell ersetzt.

Rechenregeln. Nettobetrag plus Umsatzsteuer gleich Bruttobetrag, Positionssummen gleich Gesamtsumme, Steuersatz zur Steuerkategorie passend. Bei E-Rechnungen sind diese Regeln Teil der EN-16931-Validierung; bei ausgelesenen Belegen müssen sie nachgebaut werden. Eine Regel, die scheitert, zeigt meist einen Lesefehler an, nicht einen Fehler des Lieferanten.

Umsatzsteuer-Identifikationsnummer. Das EU-System VIES bietet neben SOAP eine REST-Schnittstelle: POST https://ec.europa.eu/taxation_customs/vies/rest-api/check-vat-number liefert Gültigkeit und, je nach Mitgliedstaat, Name und Anschrift; für deutsche Nummern bleiben Name und Anschrift leer (VIES REST). VIES ist für Einzelabfragen ausgelegt und untersagt Massenabfragen. Die qualifizierte Bestätigung mit Name und Anschrift nach § 18e UStG liefert das Bundeszentralamt für Steuern über die REST-API eVatR (API-Dokumentation); die frühere XML-RPC-Schnittstelle ist seit dem 30. November 2025 abgelöst. Bei Angabe der eigenen USt-IdNr. liefert VIES eine Konsultationsnummer, die als Nachweis aufbewahrt werden sollte.

IBAN. Die Prüfziffer folgt ISO/IEC 7064 MOD 97-10; eine deutsche IBAN hat 22 Stellen, acht Stellen Bankleitzahl und zehn Stellen Kontonummer (Bundesbank, IBAN-Regeln). Dasselbe Verfahren beschreibt die KoSIT in der Leitweg-ID-Spezifikation, inklusive der Zuordnung A gleich 10 bis Z gleich 35 (Leitweg-ID Formatspezifikation 2.0.2). Eine rechnerisch gültige IBAN sagt nichts darüber aus, ob das Konto existiert oder dem Lieferanten gehört. Die wirksame Regel ist der Abgleich mit der hinterlegten Bankverbindung im Lieferantenstamm; eine abweichende IBAN ist ein Freigabefall, kein Korrekturfall.

Stammdaten und Bestellung. Lieferant bekannt, Bestellnummer vorhanden, Preise und Mengen innerhalb der vereinbarten Toleranz zur Bestellung und zum Wareneingang. Dieser Abgleich ist der Schritt, der im Einkauf die meiste Zeit kostet und in Auslese-Angeboten regelmäßig fehlt.

Duplikate. Gleicher Lieferant, gleiche Rechnungsnummer, gleicher Betrag innerhalb eines Zeitfensters. Eine der wenigen Regeln, die auch bei E-Rechnungen unverzichtbar bleibt, weil das Format Doppelsendungen nicht verhindert.

Leitweg-ID. Nur relevant für Rechnungen an öffentliche Auftraggeber. Sie steht in BT-10 Buyer Reference, ist zwischen 5 und 46 Stellen lang und trägt eine Prüfziffer nach demselben MOD-97-10-Verfahren (KoSIT).

Jede dieser Regeln hat drei Ausgänge: bestanden, gescheitert mit eindeutiger Korrektur, gescheitert mit Freigabebedarf. Nur der erste Ausgang darf ohne Menschen weiterlaufen.

Konfidenz, Freigabe und die richtige Kennzahl

Nicht jedes Modell liefert für jedes Feld einen Konfidenzwert. Selbst Azure Document Intelligence weist auf Felder ohne solche Werte hin (Microsoft, Genauigkeit und Konfidenz). Verfügbare Werte prüfen wir anhand repräsentativer Belege; eine vom Sprachmodell selbst formulierte Sicherheit ist keine nachgewiesene Trefferquote. Die Frage, ab welchem Wert ein Beleg automatisch durchläuft, hat keine amtliche Antwort. Für Hochrisiko-KI-Systeme verlangt der EU AI Act in Artikel 9 Absatz 8, dass Tests gegen vorab definierte Metriken und Wahrscheinlichkeitsschwellen erfolgen, und überlässt die Zahl dem Anbieter (Verordnung (EU) 2024/1689). Das NIST AI Risk Management Framework sagt dasselbe: Über Metriken und Schwellwerte entscheidet menschliches Urteil (NIST AI 100-1).

Die Herstellerdokumentation nennt Beispiele, keine Vorgaben. AWS Textract: Der optimale Schwellwert hängt von der Anwendung ab, für Archivzwecke reichen 50 Prozent, Geschäftsprozesse mit Finanzentscheidungen erfordern eventuell 90 Prozent oder mehr (AWS Textract Best Practices). Microsoft nennt 0,80 als Beispiel für die Grenze zwischen Dunkelverarbeitung und manueller Prüfung und verlangt davor einen eigenen Pilot (Azure Document Intelligence, Transparency Note). Google hat die eigene Human-in-the-Loop-Funktion für Document AI zum 16. Januar 2024 abgekündigt.

Drei Folgerungen für den Aufbau:

1. Schwellen je Feld, nicht je Beleg. Betrag, IBAN und USt-IdNr. verlangen eine höhere Sicherheit als das Belegdatum. Das offizielle AWS-Beispielschema arbeitet mit feldabhängigen Schwellen.
2. Konfidenz ersetzt keine Regel. Ein sicher gelesener Betrag, der die Summenprüfung nicht besteht, geht in die Prüfung. Eine unsicher gelesene Rechnungsnummer wird nicht allein durch eine passende Bestellung freigegeben; maßgeblich sind die vereinbarten Prüf- und Freigaberegeln.
3. Die Kennzahl ist der Anteil ohne Eingriff. Eine Feldgenauigkeit allein beschreibt noch keine Prozessqualität. Rechenbeispiel: Bei zwanzig Feldern mit jeweils 99 Prozent Genauigkeit beträgt die Wahrscheinlichkeit für mindestens ein falsches Feld rund 18 Prozent, sofern die Fehler unabhängig voneinander auftreten (1 − 0,99²⁰). Reale Fehler können zusammenhängen; das Beispiel ist keine Prognose für Ihre Belege. Was zählt, ist der Anteil der Belege, die ohne jeden manuellen Eingriff im Zielsystem landen. Diese Quote wird im Pilot gemessen.

Die Freigabe selbst ist ein Arbeitsplatz: Beleg links, Kandidaten rechts, gescheiterte Regeln oben, Korrektur mit zwei Klicks. Korrekturen fließen als Prüfdaten zurück und verbessern Regeln und Schwellen. Das ist der Teil, an dem Projekte scheitern, wenn er als Nebensache behandelt wird.

GoBD: was bei OCR und KI aufzubewahren ist

Die GoBD wurden am 14. Juli 2025 ausdrücklich wegen der E-Rechnung geändert (BMF vom 14.07.2025). Vier Randziffern betreffen die Belegverarbeitung direkt.

Rz. 131, Aufbewahrungsformat. Eingehende elektronische Belege sind in dem Format aufzubewahren, in dem sie empfangen wurden, bei strukturierten E-Rechnungen insbesondere der strukturierte Teil. Durch OCR ergänzte Informationen sind nach ihrer Prüfung und gegebenenfalls Berichtigung ebenfalls zu erhalten. Daraus folgt keine pauschale Vorgabe, jeden Beleg manuell zu prüfen. Bei hybriden E-Rechnungen genügt der strukturierte Teil, sofern der Bildteil keine zusätzlichen oder abweichenden steuerlich relevanten Informationen enthält.

Rz. 129 und Beispiel 10 zu Rz. 125, Auswertbarkeit. Die Reduzierung einer bestehenden maschinellen Auswertbarkeit durch Formatumwandlung ist nicht zulässig. Das XML einer hybriden E-Rechnung darf nicht durch eine Umwandlung in TIFF oder PDF gelöscht werden, auch wenn die Buchhaltung nur das Rechnungsbild nutzt.

Rz. 110, Unveränderbarkeit. Die Ablage in einem Dateisystem erfüllt die Anforderung regelmäßig nicht ohne zusätzliche Maßnahmen. Zulässig sind hardware-, software- und organisatorische Maßnahmen: Festschreibung, Protokollierung, Versionierung, Zugriffsberechtigungen. Für eine Prüfstrecke heißt das: Der ausgelesene und korrigierte Datensatz wird versioniert, die Änderungshistorie selbst darf nicht veränderbar sein (Rz. 111).

Rz. 151 bis 155, Verfahrensdokumentation. Für jedes DV-System muss eine Verfahrensdokumentation vorliegen, die ein sachverständiger Dritter in angemessener Zeit nachprüfen kann. Sie besteht in der Regel aus allgemeiner Beschreibung, Anwenderdokumentation, technischer Systemdokumentation und Betriebsdokumentation (Rz. 153). Änderungen müssen versioniert sein (Rz. 154). Fehlt sie, liegt ein formeller Mangel nur dann vor, wenn Nachvollziehbarkeit und Nachprüfbarkeit beeinträchtigt sind (Rz. 155).

Für Papierbelege, die gescannt werden, gilt Rz. 136: Eine Organisationsanweisung sollte regeln, wer erfasst, wann, welches Schriftgut, mit welcher Qualitätskontrolle und Fehlerprotokollierung. Eine Signatur oder ein Zeitstempel ist nicht erforderlich (Rz. 138). Papierdokumente dürfen nach der Erfassung vernichtet werden, soweit keine Vorschrift die Originalaufbewahrung verlangt (Rz. 140). Die Aufbewahrungsfrist für Rechnungen beträgt acht Jahre (§ 14b UStG).

Selbst gehostet oder API: Datenschutz, AI Act, Betrieb

Belege enthalten personenbezogene Daten: Ansprechpartner, Einzelunternehmer, Adressen, Bankverbindungen. Verarbeitet ein externer KI-Dienst diese Daten im Auftrag, ist er Auftragsverarbeiter. Ein Vertrag nach Artikel 28 DSGVO ist dann zwingend, einschließlich Gegenstand, Dauer, Art der Daten und Weisungsbindung, und der Anbieter darf weitere Auftragsverarbeiter nur mit Genehmigung einsetzen. Lokale Verarbeitung kann den externen KI-Dienst aus der Verarbeitungskette nehmen. Eingesetzte Hosting- und Betriebsdienstleister bleiben gesondert zu berücksichtigen. Artikel 32 zu technischen und organisatorischen Maßnahmen gilt unverändert.

Wie stark dieser Punkt wiegt, zeigt das Statistische Bundesamt: 2025 nutzten 26 Prozent der Unternehmen ab zehn Beschäftigten KI. Von denen, die es erwogen und nicht umgesetzt haben, nannten 72 Prozent fehlendes Wissen und 60 Prozent Datenschutzbedenken als Gründe (Destatis, IKT-Erhebung 2025).

AI Act. Dokumentenverarbeitung für die Buchhaltung ist kein Hochrisikosystem. Anhang III nennt acht Bereiche, keiner davon ist die Belegverarbeitung. Erwägungsgrund 53 nennt als Beispiel für eng gefasste Aufgaben mit begrenztem Risiko ausdrücklich Systeme, die unstrukturierte Daten in strukturierte umwandeln oder eingehende Dokumente kategorisieren (Verordnung (EU) 2024/1689). Die Transparenzpflichten des Artikels 50 betreffen Interaktion mit Personen und erzeugte Inhalte, nicht einen Extraktionsdienst im Hintergrund. Der Zeitplan hat sich zudem verschoben: Die Verordnung (EU) 2026/1744, in Kraft seit 27. Juli 2026, verlegt die Hochrisikopflichten für Anhang-III-Systeme auf den 2. Dezember 2027 (Digital Omnibus). Wer ein offenes Modell selbst betreibt, ist Betreiber; die Pflichten für Anbieter von KI-Modellen mit allgemeinem Verwendungszweck nach Artikel 53 treffen den Modellhersteller.

Betrieb. Das Gegenargument gegen Self-Hosting ist real und gehört benannt: Modellwechsel, Layoutdrift bei Lieferanten, Randfälle und die Überwachung der Genauigkeit kosten im Betrieb oft mehr als der Aufbau. Ein selbst betriebenes System braucht Monitoring, Updates, Backups und jemanden, der die Freigabequote im Blick behält. Deshalb beginnt ein sinnvolles Vorhaben nicht mit einer Plattform, sondern mit einem Belegtyp, einem festen Umfang und einer gemessenen Quote. Wie lokale Modelle betrieben werden und was dabei zu protokollieren ist, beschreiben der Langfuse-Guide zur LLM-Observability und die Ollama-Expertise.

Unser Vorgehen bei WZ-IT

Wir bauen Dokumentenverarbeitung als Pilot mit festem Umfang, auf Ihrer Infrastruktur oder in einer von uns betriebenen Umgebung in Deutschland.

1. Belegtyp und Zielsystem festlegen. Ein Typ, der in Menge anfällt und heute manuell geprüft wird: Eingangsrechnungen, Lieferscheine oder Auftragsbestätigungen. Zielsystem ist das vorhandene ERP, DMS oder die Buchhaltung.
2. E-Rechnungen trennen. XRechnung und ZUGFeRD werden geparst und mit dem KoSIT-Validator geprüft; der Validierungsbericht wird aufbewahrt. Alles andere geht in die Auslesestrecke.
3. Auslesen mit offenen Modellen. Docling und ein Vision-Language-Modell mit Apache-2.0-Lizenz, lokal betrieben, mit Feldprüfungen und, soweit verfügbar und im Pilot bewertet, Konfidenzwerten.
4. Prüfregeln aus Ihren Stammdaten. Rechenregeln, USt-IdNr. über VIES oder eVatR, IBAN-Abgleich mit dem Lieferantenstamm, Bestellabgleich, Duplikate.
5. Freigabearbeitsplatz und Protokoll. Korrekturen versioniert, Änderungshistorie unveränderbar, Verfahrensdokumentation in den vier Teilen der Rz. 153.
6. Messen. Nach dem Pilot steht die Quote der Belege ohne Eingriff fest. Sie entscheidet über die Ausweitung.

Das Angebot mit Umfang, Ablauf und Preis steht auf der Seite KI-Dokumentenverarbeitung. Ist noch offen, welcher Prozess zuerst dran ist, ordnet der KI-Prozesscheck Belegarten, Mengen und Prüfschritte ein. Geht es um Bestellungen, die aus E-Mail, PDF und Excel ins ERP sollen, ist die automatisierte Auftragserfassung der passende Einstieg.

Weiterführende Guides

• Paperless-ngx auf Ubuntu mit Caddy installieren, das Archiv, in dem geprüfte Belege landen können.
• Paperless-AI für Paperless-ngx, inzwischen durch die native KI-Integration in Paperless-ngx 3 abgelöst.
• EU AI Act: Hochrisiko-KI im Unternehmen, Einordnung der Pflichten; die Termine haben sich mit dem Digital Omnibus verschoben.
• Langfuse: LLM-Observability und Protokollierung, Nachvollziehbarkeit lokaler Modelle im Betrieb.
• Lokale KI für Steuerkanzleien, derselbe Grundsatz für berufsgeheimnisgeschützte Daten.
• KI-Lösungen für Unternehmen, der Hub mit allen Einstiegen.

Welcher Belegtyp kostet bei Ihnen die meiste Zeit? Wir bauen dafür Auslesen, Prüfregeln und Freigabe mit festem Umfang und messen, was ohne Nacharbeit durchläuft. Termin vereinbaren

Quellen

• § 14 UStG, Ausstellung von Rechnungen
• § 14b UStG, Aufbewahrung von Rechnungen
• § 27 UStG, Übergangsvorschriften, Absatz 38
• § 18e UStG, Bestätigungsverfahren
• § 33 UStDV, Rechnungen über Kleinbeträge
• § 34a UStDV, Rechnungen von Kleinunternehmern
• BMF-Schreiben vom 15. Oktober 2025 zur obligatorischen E-Rechnung, Änderung des Schreibens vom 15. Oktober 2024
• BMF-Schreiben vom 15. Oktober 2024, Wortlaut in der IHK-Veröffentlichung
• BMF-Schreiben vom 14. Juli 2025, zweite Änderung der GoBD
• GoBD, BMF-Schreiben vom 28. November 2019, Archivfassung
• KoSIT, XRechnung Versionen und Bundles
• KoSIT, EN 16931 aktueller Stand und Ausblick auf XRechnung 4.0
• KoSIT, Leitweg-ID Formatspezifikation 2.0.2
• KoSIT Validator auf GitHub
• KoSIT XRechnung-Validatorkonfiguration auf GitHub
• EU-Kommission, EN-16931-Validierungsartefakte auf GitHub
• EU-Kommission, kostenfreier Zugang zur EN 16931
• EU-Kommission, Online-Validator für E-Rechnungen
• VIES REST-Schnittstelle
• BZSt eVatR REST-API, Dokumentation
• Deutsche Bundesbank, IBAN-Regeln
• Eurostat, E-Rechnungen und automatisierte Verarbeitung, isoc_eb_ics
• Statistisches Bundesamt, Gründe gegen die Nutzung von KI, IKT-Erhebung 2025
• Verordnung (EU) 2024/1689, KI-Verordnung
• Verordnung (EU) 2026/1744, Digital Omnibus on AI
• EU-Kommission, AI Omnibus in Kraft
• Verordnung (EU) 2016/679, DSGVO
• NIST AI Risk Management Framework 1.0
• AWS Textract Best Practices
• Microsoft, Azure AI Document Intelligence Transparency Note
• Google Document AI, Deprecations
• Docling auf GitHub
• Tesseract OCR auf GitHub
• PaddleOCR auf GitHub
• docTR auf GitHub
• Marker auf GitHub
• OCRmyPDF auf GitHub
• Paperless-ngx Releases
• Qwen3-VL-8B-Instruct, Modellkarte
• Qwen2.5-VL-3B-Instruct, Modellkarte mit Forschungslizenz
• granite-docling-258M, Modellkarte
• blumatix, Vor- und Nachteile großer Sprachmodelle bei der Dokumentenerfassung