Eigenentwicklung vs. Kauflösung: Dokumentenprüfung intern?

„Wir haben Entwickler. Wir haben Tesseract. Wie schwer kann es sein?" Diese Frage hat Hunderte interner Dokumentenprüfungsprojekte ausgelöst. Einige sind erfolgreich. Die meisten liefern weniger als erwartet, überschreiten ihre Budgets und werden 18 Monate später still durch eine SaaS-Plattform ersetzt. Aber nicht alle – und diese Unterscheidung ist wichtig.

Die Entscheidung Eigenentwicklung vs. Kauflösung für die Dokumentenprüfung verdient eine rigorose, sachliche Analyse. Kein als Blogartikel getarnter Verkaufs-Pitch. Keine Abwertung legitimer Ingenieurskompetenz. Ein ehrlicher Vergleich dessen, was jeder Weg kostet, wie lange er dauert und wo er zusammenbricht.

Dieser Artikel liefert den Rahmen. Die Zahlen sind real. Die Schlussfolgerung ziehen Sie selbst.

Das Argument für die Eigenentwicklung

Vier Argumente sprechen technisch und geschäftlich für die interne Entwicklung — keines davon ist falsch, aber alle lassen eine zentrale Komplexitätsdimension unberücksichtigt.

Die kumulierten 3-Jahres-Kosten einer internen Dokumentenprüfungslösung übersteigen bei 300 Akten pro Monat EUR 500.000, gegenüber rund EUR 20.000 für eine spezialisierte Plattform — ein Verhältnis von 25:1, das die Entscheidung für die überwiegende Mehrheit der Organisationen eindeutig bestimmt. (BaFin IT-Aufsichtsanforderungen)

• „Wir verstehen unsere Geschäftsregeln besser als jeder Anbieter."
• „OCR-APIs sind commoditisiert. Der schwierige Teil ist die Geschäftslogik, die wir bereits kennen."
• „Wir vermeiden Vendor Lock-in und behalten die volle Datensouveränität."
• „Wir behalten die vollständige Kontrolle über die Roadmap."

Jede dieser Aussagen hat ihre Berechtigung. Die erste ist fast immer wahr – niemand versteht Ihre spezifischen Prüfworkflows besser als Ihr Team. Die zweite ist technisch korrekt, aber strategisch unvollständig. Die dritte spiegelt eine legitime architektonische Präferenz wider. Die vierte ist ein berechtigtes organisatorisches Anliegen.

Das Problem liegt nicht in dem, was diese Argumente sagen. Es liegt in dem, was sie auslassen. Dokumentenprüfung ist kein OCR-Problem. Es ist ein Orchestrierungsproblem – Klassifizierung, Regel-Engines, dokumentenübergreifende Validierung, Prüfpfade, regulatorische Updates und Edge-Case-Management. OCR macht 15 bis 20 % des Gesamtaufwands aus. Die restlichen 80 % sind der Punkt, an dem interne Projekte ins Stocken geraten.

Die 5 Komponenten, die Sie bauen müssen

Jedes interne Dokumentenprüfungssystem erfordert fünf Komponenten, die alle gebaut, getestet, bereitgestellt und dauerhaft gewartet werden müssen — OCR allein macht dabei nur 15–20 % des Gesamtaufwands aus.

Der EU AI Act (Verordnung (EU) 2024/1689, Anhang III) klassifiziert Dokumentenprüfungssysteme für Kreditentscheidungen als Hochrisiko-KI; Eigenentwickler tragen die volle Konformitätsverantwortung — inklusive Konformitätsbewertung, Registrierung bei nationaler Behörde und laufender Überwachung. (EUR-Lex EU AI Act Anhang III)

1. OCR und Datenextraktion

Die Extraktionsschicht wandelt Scans, Fotos und PDFs in strukturierte Daten um. Dies ist die Komponente, bei der sich Engineering-Teams am sichersten fühlen, weil die APIs existieren und die Dokumentation gut ist.

Die Herausforderung ist nicht sauberes OCR auf gut formatierten Dokumenten. Es ist OCR auf einem Fax-Scan, der als E-Mail-Anhang weitergeleitet wurde, einem Handyfoto eines Personalausweises bei schlechter Beleuchtung oder einer Gehaltsabrechnung in einem nicht standardmäßigen Layout. Veröffentlichte Genauigkeitsraten von 98–99 % gelten für hochwertig gedruckten Text. Bei realen Eingaben sinkt die Genauigkeit auf 85–92 %. Der Unterschied zwischen 98 % und 92 % Genauigkeit bei einem kritischen Feld – einer Steueridentifikationsnummer, einem Dokumentenablaufdatum, einer HRB-Nummer – ist der Unterschied zwischen einem zuverlässigen System und einem, das mehr Arbeit erzeugt als es eliminiert.

Für eine tiefere Analyse der Technologieentscheidungen auf dieser Ebene lesen Sie unseren Vergleich von generativer KI vs. Extraktion.

2. Dokumentenklassifizierung

Bevor ein Dokument validiert wird, muss es identifiziert werden. Ein Adressnachweis kann eine Versorgungsrechnung, ein Kontoauszug, ein Steuerbescheid oder eine Meldebescheinigung sein. Jeder hat unterschiedliche Gültigkeitsregeln, unterschiedliche zu extrahierende Felder und unterschiedliche Prüflogik. Das System muss jedes eingehende Dokument gegen die erwarteten Typen klassifizieren – einschließlich Typen, die es noch nie gesehen hat.

Ein schlüsselwortbasierter Klassifizierer deckt 60–70 % der Fälle ab. Die restlichen 30 % erfordern ein Machine-Learning-Modell, trainiert auf Tausenden annotierter Beispiele. Diese Beispiele müssen gesammelt, gelabelt, geprüft und gepflegt werden, da sich Dokumentenformate weiterentwickeln.

3. Geschäftsregel-Engine

Hier explodiert die Komplexität. Validierungsregeln sind nicht universell. Sie hängen vom Aktentyp, den Anforderungen des Finanzierungspartners, der geltenden Regulierung und internen Richtlinien ab. Eine Produktions-Regel-Engine muss handhaben:

• Vollständigkeitsregeln: Enthält die Akte alle erforderlichen Dokumente?
• Gültigkeitsregeln: Ist jedes Dokument noch gültig (Ablaufdatum, Höchstalter)?
• Konsistenzregeln: Stimmt der Name auf dem Personalausweis mit dem Namen auf der Gehaltsabrechnung überein?
• Bedingte Regeln: Wenn das Einkommen unter einem Schwellenwert liegt, Bürgschaft anfordern; wenn der Bürge eine Gesellschaft ist, Handelsregisterauszug anfordern.

Ein Produktionssystem verwaltet typischerweise 200 bis 500 aktive Regeln. Jede Regel muss getestet, versioniert und auditierbar sein. Jede regulatorische Änderung betrifft mehrere Regeln. Jeder neue Finanzierungspartner fügt einen neuen Regelsatz hinzu.

4. Dokumentenübergreifende Validierung

Einzeldokumentenvalidierung ist notwendig, aber unzureichend. Der wahre Wert liegt in der Kreuzreferenzierung von Informationen über Dokumente hinweg: Ist das deklarierte Einkommen auf der Gehaltsabrechnung konsistent mit der Steuererklärung? Stimmt die Adresse auf der Meldebescheinigung mit der Adresse auf dem Personalausweis überein? Stimmt die HRB-Nummer im Handelsregisterauszug mit der auf der Bankverbindung überein?

Diese dokumentenübergreifende Validierungslogik ist die komplexeste zu implementierende und die teuerste zu wartende Komponente. Sie erfordert einen Abhängigkeitsgraphen zwischen extrahierten Feldern, Toleranzmanagement für Schreibvarianten, Abkürzungen und Adressformatunterschiede sowie einen Konfidenz-Scoring-Mechanismus.

5. Prüfpfad und Compliance

In regulierten Branchen – Finanzwesen, Versicherung, Immobilien, Leasing – muss jede Validierungsentscheidung rückverfolgbar sein. Das System muss ein detailliertes Auditprotokoll erzeugen: welches Dokument geprüft wurde, welche Regeln angewandt wurden, welches Ergebnis erzielt wurde, zu welchem Zeitpunkt und von welchem Bearbeiter oder Algorithmus.

Dieses Protokoll muss unveränderlich, zeitgestempelt und bei Audits auf Abruf verfügbar sein. Das ist keine Log-Datei. Es ist eine Compliance-Komponente. Ein mangelhafter Prüfpfad kann das gesamte Validierungssystem aus regulatorischer Sicht entwerten.

Die versteckten Kosten der Eigenentwicklung

Die Erstentwicklungskosten (EUR 195.000 im ersten Jahr) repräsentieren weniger als 38 % der 3-Jahres-TCO — Wartung, regulatorische Updates und Infrastruktur machen die verbleibenden 62 % aus.

Trainingsdaten

Ein performanter Dokumentenklassifizierer erfordert 2.000 bis 10.000 annotierte Beispiele pro Dokumententyp. Für 15 Dokumententypen sind das 30.000 bis 150.000 Annotationen. Annotationskosten (intern oder extern) liegen bei 0,20 bis 0,50 € pro Dokument. Budget: 6.000 bis 75.000 €, mit teilweiser Erneuerung jährlich zur Aufnahme neuer Formate.

Edge-Case-Management

Die 20 % der Dokumente, die „schwierig" sind – schlechte Qualität, nicht standardmäßige Formate, Fremdsprachen, handschriftliche Felder – verbrauchen 80 % des Entwicklungsaufwands. Jeder neue Edge Case erzeugt ein Ticket, eine Analyse, einen Fix, einen Regressionstest und ein Deployment. Dieser Strom ist kontinuierlich und endet nie.

Regulatorische Updates

GwG-Vorschriften, DSGVO-Anforderungen, BaFin-Rundschreiben und Spezifikationen von Finanzierungspartnern ändern sich quartalsweise. Jede regulatorische Änderung muss in Code übersetzt, getestet und bereitgestellt werden. Ein Team von zwei Entwicklern verbringt typischerweise 15–20 % seiner Kapazität mit regulatorischer Wartung – das Äquivalent einer Drittel-Vollzeitstelle.

Für eine detaillierte Methodik zur Quantifizierung dieser kumulativen Kosten lesen Sie unsere Analyse der wahren Kosten manueller Dokumentenprüfung.

Sicherheit und Hosting

Identitätsdokumente sind sensible personenbezogene Daten. Ihre Verarbeitung erfordert DSGVO- und BDSG-konformes Hosting, Verschlüsselung im Ruhezustand und bei der Übertragung, Zugriffsverwaltung, regelmäßige Sicherheitsaudits und in Deutschland idealerweise ein BSI C5-Testat. Infrastruktur- und Sicherheits-Compliance-Kosten werden routinemäßig in Erstschätzungen ausgelassen.

Skalierbarkeit

Ein Proof of Concept, der 50 Dokumente pro Tag verarbeitet, verhält sich völlig anders als ein Produktionssystem mit 5.000 Dokumenten. Leistungsprobleme, Queue-Management, Nebenläufigkeitsbehandlung und Monitoring-Lücken treten erst im Betrieb auf. Deren Lösung erfordert ungeplante Entwicklungszeit.

Gesamtkostenvergleich: 3 Jahre Eigenentwicklung vs. Kauflösung

Das kumulative 3-Jahres-Kostenverhältnis zwischen Eigenentwicklung und Kauflösung beträgt 25:1 für eine Organisation mit 300 Akten pro Monat — EUR 520.000 versus EUR 20.364.

Die folgende Tabelle vergleicht die Gesamtbetriebskosten für ein internes System gegenüber einer spezialisierten Plattform wie CheckFile, für eine Organisation, die 300 Akten pro Monat verarbeitet.

Annahmen

3-Jahres-Kostenaufstellung

Das kumulative 3-Jahres-Verhältnis beträgt 25:1. Der Eigenentwicklungspfad übersteigt eine halbe Million Euro, ohne die Opportunitätskosten der von Ihrem Kernprodukt abgezogenen Entwickler.

Time-to-Market: Die andere Kosten

Der Weg zur ersten Produktionsbereitstellung dauert bei Eigenentwicklung 6–12 Monate — gegenüber 2–4 Wochen bei einer spezialisierten Plattform via REST-API-Integration.

Die 6 bis 12 monatige Lücke zwischen den beiden Pfaden ist nicht nur eine Verzögerung. Es ist ein Zeitraum, in dem Ihre Teams weiterhin manuell prüfen und alle damit verbundenen Kosten tragen.

Wann Eigenentwicklung die richtige Entscheidung ist

Eigenentwicklung ist die richtige Entscheidung in spezifischen, identifizierbaren Situationen:

• Proprietäre Dokumententypen: Ihre Dokumente gleichen nichts Standardmäßigem. Sie werden von Ihren internen Systemen in Formaten erzeugt, die nur Ihre Organisation bearbeitet.
• Absolute Datensouveränität: Ihr regulatorisches Umfeld verbietet die Verarbeitung von Dokumenten durch Dritte, auch kurzzeitig, auch verschlüsselt. Das gilt in bestimmten militärischen, behördlichen oder klassifizierten Gesundheitskontexten.
• Kern-Wettbewerbsvorteil: Dokumentenprüfung IST Ihr Produkt, kein Unterstützungsprozess. Sie verkaufen Dokumentenverifizierung an Ihre Kunden.
• Verfügbares und qualifiziertes Engineering-Team: Sie haben mindestens 3 erfahrene ML/NLP-Ingenieure, eine reife Dateninfrastruktur und ein mehrjährig gesichertes Budget.
• Sehr hohes Volumen mit Skaleneffekten: Jenseits von 50.000 Dokumenten pro Monat kann der Stückpreis einer SaaS-Plattform den einer amortisierten internen Lösung übersteigen.

Wann die Kauflösung die richtige Entscheidung ist

Der Kauf einer spezialisierten Plattform ist die rationale Wahl in der Mehrheit der operativen Szenarien:

• Standard- oder Semi-Standarddokumente: Personalausweise, Meldebescheinigungen, Gehaltsabrechnungen, Handelsregisterauszüge, Bankverbindungen, Steuerbescheide.
• Regulierte Branche: Finanzwesen, Versicherung, Immobilien, Leasing. Regulatorische Updates sind häufig und ihre Implementierung kritisch.
• Time-to-Market-Druck: Sie müssen innerhalb von Wochen automatisieren, nicht Monaten.
• Schlankes Engineering-Team: Ihr Entwicklungsteam ist für Ihr Kernprodukt dimensioniert.
• Bedarf an sofortiger Zuverlässigkeit: Ein internes V1-System hat eine Fehlerquote von 8–15 %. Eine reife Plattform startet bei 2–4 % und sinkt nach Kalibrierung unter 1 %.

Entscheidungsrahmen

Interpretation:

• 5 bis 7 „Eigenentwicklung"-Antworten: Interne Entwicklung ist wahrscheinlich gerechtfertigt. Stellen Sie sicher, dass Budget und Ressourcen für mindestens 3 Jahre reserviert sind.
• 3 bis 4 „Eigenentwicklung"-Antworten: Erwägen Sie die Hybridoption (siehe unten).
• 0 bis 2 „Eigenentwicklung"-Antworten: Die Kauflösung ist die rationale Wahl.

Die Hybridoption: Plattform kaufen, mit eigenen Regeln erweitern

Es gibt ein drittes Szenario: die Basisplattform kaufen und mit proprietärer Geschäftslogik erweitern.

In der Praxis bedeutet das:

1. Die Plattform nutzen für OCR, Klassifizierung, Standardvalidierung und Prüfpfad.
2. Eigene Geschäftsregeln hinzufügen über API und konfigurierbare Regel-Engine – ohne Extraktionscode zu schreiben.
3. In bestehende Systeme integrieren via REST-API oder Webhooks.
4. Kontrolle behalten über kritische Entscheidungslogik, während die Dokumenteninfrastruktur delegiert wird.

Dieser Ansatz erfasst 80 % der Kaufvorteile (Geschwindigkeit, Zuverlässigkeit, delegierte Wartung) bei gleichzeitiger Beibehaltung der Flexibilität der Eigenentwicklung bei differenzierenden Aspekten.

Häufig gestellte Fragen

Wie viel kostet es, eine Dokumentenprüfungslösung intern zu entwickeln?

Die kumulierten 3-Jahres-Kosten übersteigen typischerweise 500.000 € für eine Organisation, die 300 Akten pro Monat verarbeitet. Das umfasst Erstentwicklung (195.000 €), jährliche Wartung (65.000 €/Jahr), Infrastruktur, Trainingsdaten und regulatorische Updates. Vergleichen Sie das mit rund 20.000 € über 3 Jahre für eine spezialisierte Plattform.

Kann ich mit Eigenentwicklung starten und später auf eine Plattform migrieren?

Es ist technisch möglich, aber selten optimal. Migration erfordert das Neuschreiben von Integrationen, die Konvertierung von Geschäftsregeln und die Umschulung von Teams. Organisationen, die diesen Ansatz versuchen, verlieren durchschnittlich 9 bis 12 Monate, und bereits getätigte Investitionen in die interne Entwicklung sind weitgehend nicht rückholbar.

Ab welchem Volumen wird Eigenentwicklung kosteneffektiv?

Jenseits von 50.000 Dokumenten pro Monat kann der Stückpreis einer SaaS-Plattform den einer amortisierten internen Lösung übersteigen. Unter diesem Schwellenwert beträgt das 3-Jahres-Kostenverhältnis 25:1 zugunsten der Kauflösung.

Fazit: Eine strategische Entscheidung, keine technische

Die Eigenentwicklungs- vs. Kaufentscheidung für Dokumentenprüfung ist keine Frage der technischen Fähigkeit. Jedes kompetente Engineering-Team kann eine funktionale OCR-Pipeline bauen. Die Frage ist: Ist Dokumentenprüfung die Domäne, in der Sie Ihren Wettbewerbsvorteil konzentrieren wollen?

Wenn die Antwort Ja lautet, entwickeln Sie intern. Investieren Sie kräftig, stellen Sie die besten ML-Ingenieure ein und verpflichten Sie sich zu einem mehrjährigen Budget von über 500.000 €.

Wenn die Antwort Nein lautet – und sie lautet für 90 % der Organisationen, die Dokumentenakten verarbeiten, Nein – kaufen Sie die Plattform, integrieren Sie sie in Wochen via die API und leiten Sie Ihre Entwickler auf das um, was Ihr Geschäft tatsächlich differenziert.

CheckFile ist für das zweite Szenario gebaut. Prüfen Sie unsere Preise, um die Kosten für Ihr Volumen zu schätzen, oder fordern Sie eine Demonstration an.