Kann KI den Rechnungseingang übernehmen, ohne dass meine Daten in den USA landen?

Von /

Jede Woche der gleiche Stapel. Lieferscheine, Eingangsrechnungen, Auftragsbestätigungen kommen als PDF im Postfach an, und jemand tippt die Zahlen von Hand in die Datenbank. Rechnungsnummer, Lieferant, Netto, Mehrwertsteuer, Brutto. Ein Tag die Woche, manchmal mehr. Irgendwann sagt jemand „das soll doch die KI machen“, und der nächste Gedanke ist sofort: landen meine Belege dann bei einem amerikanischen Anbieter?

Die kurze Antwort: Ja, KI kann den Rechnungseingang auslesen. Und ja, die Daten können dabei in der EU bleiben. Es gibt genau einen Haken, und um den geht es weiter unten.

Kann ich überhaupt ein PDF an eine KI schicken und kriege die Inhalte zurück?

Das ist der Kern Deiner Frage, und die Antwort ist heute schlicht: ja. Du schickst ein PDF oder ein Foto an eine Schnittstelle, und Du bekommst nicht etwa eine vage Zusammenfassung zurück, sondern strukturierte Felder. Lieferant, Rechnungsnummer, Datum, Positionen, Beträge, jedes als eigener Wert.

Das Format, in dem diese Werte zurückkommen, ist JSON. Das ist eine maschinenlesbare Liste aus Feldnamen und Werten, die jede Datenbank und jedes Programm direkt weiterverarbeiten kann. XML bekommst Du nicht immer direkt, aber JSON lässt sich in einem Schritt nach XML wandeln, falls Dein Zielsystem das braucht. Aus „ein PDF“ wird also ein sauberer Datensatz, den Du in den SQL Server schreiben kannst.

Technisch erledigen das spezialisierte Dokumenten-Dienste. Microsoft nutzt im Hintergrund Azure Document Intelligence (früher Form Recognizer), Mistral aus Frankreich bietet mit Mistral OCR einen vergleichbaren Dienst für rund ein bis zwei US-Dollar pro 1.000 Seiten an, und auch die großen Sprachmodelle können PDFs lesen. Für Belege ist ein spezialisierter Dokumenten-Dienst die bessere Wahl als ein geschwätziges Sprachmodell, weil er ein festes Schema liefert und nicht heute Netto und morgen den Bruttobetrag in dasselbe Feld schreibt.

So lief das früher, und warum das niemand vermisst

Vor einigen Jahren habe ich bei einem Kunden eingehende Bestellungen aus Outlook in Access verarbeitet. Der Weg war: PDF in Word öffnen, aus Word nach HTML exportieren, und dann die HTML-Struktur mit VBA mühsam auseinandernehmen. Tabellenzellen suchen, Zwischenüberschriften abfangen, Sonderfälle pro Lieferant abfedern.

Das funktionierte, solange das Layout gleich blieb. Sobald ein Lieferant sein Rechnungsformular umstellte, eine Spalte verschob oder das Logo vergrößerte, brach die Zerlegung, und jemand musste den Code anfassen. Diese Lösungen waren teuer in der Wartung, weil sie auf Position statt auf Bedeutung gebaut waren. Genau das ist der Unterschied zu heute: Ein Dokumenten-Modell erkennt den Bruttobetrag als Bruttobetrag, egal an welcher Stelle der Seite er steht.

Wie das heute mit Microsoft AI Builder läuft

Microsoft AI Builder ist der KI-Baustein der Power Platform. Du trainierst ihn einmal auf Deine typischen Belegformate oder nimmst das fertige Modell für Rechnungen, danach läuft er als ein Schritt in einem Power-Automate-Ablauf, ganz ohne eigene Programmierung der KI-Anbindung.

Die Kette, nach der Du gefragt hast, sieht so aus:

  1. Outlook (Microsoft 365) empfängt die Mail mit dem PDF-Anhang. Das ist der Auslöser.
  2. Power Automate startet automatisch, sobald so eine Mail eintrifft, und greift den Anhang ab.
  3. Microsoft AI Builder liest aus dem PDF die Felder aus: Lieferant, Rechnungsnummer, Datum, Positionen, Beträge. Als Ergebnis kommt ein strukturierter Datensatz zurück.
  4. SQL Server nimmt diesen Datensatz auf. Den Schreibzugriff stellt der SQL-Server-Connector her, das ist ein sogenannter Premium-Connector, der eine Power-Automate-Premium-Lizenz voraussetzt.
  5. Microsoft Access liest die Daten wie gewohnt aus dem SQL Server, über die verknüpften Tabellen, die Du ohnehin schon hast.

Access bleibt also Dein Frontend, der SQL Server bleibt Dein Datenspeicher, und die KI ist nur ein schmaler Auslese-Schritt dazwischen. Niemand muss mehr abtippen, und niemand baut eine fragile Zerlegung pro Lieferant.

Wo die Daten dabei landen

Hier wird die Titelfrage konkret. Datenresidenz bezeichnet die Festlegung, in welcher geografischen Region Daten gespeichert und verarbeitet werden. Bei AI Builder gilt eine klare Regel: Deine Modelle werden in der Region betrieben, in der Deine Power-Platform-Umgebung angelegt ist. Liegt die Umgebung in der EU, werden die Modelle in europäischen Rechenzentren betrieben, und die Daten bleiben in dieser Region. Das Analyse-Ergebnis wird beim zugrunde liegenden Dienst nur etwa 24 Stunden zwischengespeichert und ist per Schnittstelle löschbar.

Damit ist die Auslese der Rechnungen kein Datenexport in die USA, sondern eine Verarbeitung in Deiner gewählten EU-Region. Der entscheidende Hebel ist also keine Magie, sondern eine Einstellung: Lege die Umgebung von Anfang an in einer EU-Region an, dann bleibt der Beleg dort.

Struktur vor KI: Die KI füllt nur eine Tabelle, die Du vorgibst

Der Punkt, an dem viele KI-Projekte kippen, ist nicht die KI. Es ist die fehlende Struktur dahinter. Eine KI, die Felder ausliest, braucht ein Ziel, in das sie schreibt. Dieses Ziel definierst Du, nicht das Modell. Eine Landetabelle im SQL Server für die ausgelesenen Rechnungsköpfe kann so aussehen:

CREATE TABLE stg.tblRechnungEingang
(
     idRechnungEingang   INT IDENTITY(1,1) NOT NULL
    ,strReLieferant      VARCHAR(200)  NULL
    ,strReRechnungsnr    VARCHAR(50)   NULL
    ,dtmReRechnungsdatum DATE          NULL
    ,curReNetto          DECIMAL(19,4) NULL
    ,curReMwst           DECIMAL(19,4) NULL
    ,curReBrutto         DECIMAL(19,4) NULL
    ,strReWaehrung       VARCHAR(3)    NULL
    ,dblReKonfidenz      FLOAT         NULL
    ,bitReGeprueft       BIT           NOT NULL CONSTRAINT DF_ReGeprueft DEFAULT (0)
    ,dtmReEingang        DATETIME2(0)  NOT NULL CONSTRAINT DF_ReEingang DEFAULT (SYSDATETIME())
    ,memReRohdaten       VARCHAR(MAX)  NULL
    ,CONSTRAINT PK_RechnungEingang PRIMARY KEY CLUSTERED (idRechnungEingang)
);

Zwei Spalten sind hier entscheidend und werden gern vergessen. dblReKonfidenz nimmt den Sicherheitswert des Modells auf, also wie sicher es sich bei der Auslese war. Liegt der unter Deiner Schwelle, geht die Rechnung nicht automatisch durch, sondern zur Prüfung an einen Menschen. bitReGeprueft ist genau dieses menschliche Tor: Erst nach Freigabe wandert der Datensatz aus dem Staging-Schema in Deine echten Buchungstabellen. memReRohdaten hält zusätzlich das rohe JSON vor, damit bei einer Prüfung nachvollziehbar bleibt, was die KI ursprünglich erkannt hat.

Das ist „Struktur vor KI“ in einer Tabelle: Die KI darf erfassen, aber sie entscheidet nicht. Sie füllt ein Fach, das Du gebaut hast, und ein Mensch oder eine Regel macht das Tor auf.

Was ich an dieser Stelle gegen den ersten Reflex empfehle

Der naheliegende Weg wäre, die Belege an das beste verfügbare Sprachmodell zu schicken, oft ein US-Dienst, und sich um die Struktur später zu kümmern. Ich rate bei Eingangsrechnungen davon ab, aus zwei Gründen.

Erstens ist der Rechnungseingang GoBD-relevant. Du willst nachvollziehbar belegen können, welcher Wert woher kam, und das geht mit einem festen Schema und einem aufbewahrten Rohdatensatz besser als mit einem Modell, das jedes Mal etwas anders antwortet. Zweitens brauchst Du die Daten nicht in eine zweite Datenwelt zu verschieben. Du musst für diesen Ablauf weder Dataverse als Pflicht-Datenhaltung einführen noch Deine Stammdaten verdoppeln. Der SQL Server, den Du hast, ist das Ziel, und Access bleibt die Bühne. Die KI kommt als schmale Ergänzung dazu, nicht als neues Zentrum.

Wo der Ansatz an Grenzen stößt

Drei ehrliche Einschränkungen, bevor Du das einplanst.

Erstens der eine Haken aus der Einleitung: Die reine Belegauslese bleibt in Deiner Region. Sobald Du aber einen zusätzlichen, generativen Schritt einbaust, etwa einen KI-Prompt, der eine Rechnung in Worten zusammenfasst, kommt ein anderer Dienst ins Spiel, der per Standardeinstellung zwar ebenfalls in Deiner Region bzw. innerhalb der EU-Datengrenze bleibt, für den es aber Schalter wie „Datenverschiebung zwischen Regionen“ und das sogenannte Flex Routing gibt. Diese erlauben in Spitzenlast eine Verarbeitung außerhalb der EU-Datengrenze. Wer streng in der EU bleiben will, prüft, dass diese Optionen aus sind.

Zweitens die Lizenz. Der SQL-Server-Connector ist ein Premium-Connector und kostet eine Power-Automate-Premium-Lizenz. Dazu kommt, dass die früher in vielen Lizenzen enthaltenen AI-Builder-Credits zum November 2026 wegfallen und durch ein verbrauchsbasiertes Modell ersetzt werden. Das ändert nichts an der Technik, aber an der Kostenrechnung, und das gehört vor den Start auf den Tisch.

Drittens die Genauigkeit. Kein Modell liest zu hundert Prozent fehlerfrei. Genau deshalb gibt es oben die Konfidenz-Spalte und das Prüf-Tor. Ohne diese beiden ist die Automatisierung keine Entlastung, sondern eine Fehlerquelle mit Tempo.

Und falls Du gar nicht im Microsoft-Kosmos unterwegs bist: Der gleiche Ablauf lässt sich mit einem EU-Dienst wie Mistral aufbauen, der das PDF ebenfalls als JSON zurückgibt und sich sogar selbst hosten lässt. Der Microsoft-Weg ist nur der naheliegende, wenn Outlook, Power Automate und SQL Server bei Dir ohnehin stehen.

Für alle, die das nicht selbst bauen

Wenn Dich der Code oben nicht interessiert, sondern die Frage dahinter: Ja, der Tag pro Woche für den Rechnungseingang lässt sich auf eine Prüfminute pro Beleg eindampfen, und ja, das geht so, dass Deine Belege die EU nicht verlassen. Was es dafür braucht, ist keine neue Software, sondern eine saubere Schicht zwischen Postfach und Datenbank, plus die richtige Region und ein menschliches Tor für die Zweifelsfälle. Das ist weniger ein KI-Projekt als ein Strukturprojekt mit KI-Baustein.

Diese Seite ist die Detail-Antwort zu Abschnitt sechs aus „Brauchst Du eine neue Software, oder reicht Dein Access mit ein paar modernen Ergänzungen?“, wo der Rechnungseingang als einer von acht Anlässen für eine Power-Platform-Ergänzung steht.

Wenn Du einmal durchsprechen willst, ob sich das für Deinen Beleg-Eingang rechnet, erreichst Du mich über ein kostenloses Erstgespräch. Dreißig Minuten, in denen wir Dein konkretes Belegaufkommen und Deine bestehende Access- und SQL-Server-Landschaft durchgehen.

Quellen

Über Sönke Schäfer

Sönke Schäfer berät seit über 25 Jahren KMU im norddeutschen Raum bei Datenbank-Anwendungen mit Microsoft Access und SQL Server. Sein Schwerpunkt liegt darauf, KI gezielt an bestehende Datenbestände anzubinden, statt sie als Ersatz für gewachsene Strukturen zu verkaufen. Belegerfassung, Schnittstellen und schreibende Synchronisation zwischen Altsystemen gehören dabei zum Alltag. Büro in Sierksdorf, Ostholstein, erreichbar für Unternehmen in Lübeck, Kiel, Hamburg und im gesamten norddeutschen Raum, auf Wunsch remote.

Ähnliche Beiträge

Nach oben scrollen