Build vs. Buy: Dokumentenextraktion –
Was Eigenentwicklung wirklich kostet

Was „Bauen" wirklich bedeutet – nicht ein API-Aufruf, sondern sechs Systeme

Der Satz „Wir bauen einfach eine Dokumentenextraktion mit GPT" fasst mindestens sechs verschiedene technische Systeme in vier Wörtern zusammen. Hier ist, was eine produktionsreife Pipeline – eine, die echte Dokumente von echten Geschäftspartnern verarbeitet, nicht kuratierte Demobeispiele – tatsächlich erfordert:

Erfassung und Vorverarbeitung. Rohdokumente kommen als PDFs, JPGs, PNGs, manchmal passwortgeschützt, manchmal beschädigt. Die Erfassungsschicht normalisiert Dateiformate, behandelt Fehler ohne Absturz der Pipeline und validiert, dass jede Datei verarbeitbar ist, bevor nachgelagerte Komponenten Rechenleistung darauf verwenden.

Dokumentenklassifizierung. Eine Lieferantenrechnung, ein Kontoauszug, ein handsignierter Vertrag und ein Foto einer Quittung erfordern alle unterschiedliche Extraktionsstrategien. Die Klassifizierung leitet jedes Dokument an den richtigen Verarbeitungspfad weiter – und liegt oft genug falsch, dass Sie eine Auffangebene benötigen. Ein Entwickler, der eine Dokumentenextraktionsplattform gebaut hat, beschrieb die Kern-Erkenntnis auf Reddit: „Bei der Dokumentenextraktion geht es weniger darum, ein perfektes Modell zu finden, sondern vielmehr darum, ein System zu bauen, das Tausende verschiedener Dokumentenvarianten verarbeiten kann."

OCR und Layout-Analyse. Nicht alle PDFs enthalten auswählbaren Text. Viele sind Scans. Einige mischen Text, Tabellen und Bilder auf derselben Seite. Layout-Verständnis – das Verfolgen von verbundenen Zellen, mehrspaltigen Berichten und verschachtelten Tabellen – erfordert Vision-Modelle, die selbst eine Spezialisierung darstellen. Die Preisseite für Document AI bei Google Cloud listet einen separaten Layout-Parser-Prozessor für 10 $ pro 1.000 Seiten auf – allein die Layout-Erkennung ist ein eigenes kostenpflichtiges Produkt.

Schema-gesteuerte Extraktion. Hier extrahiert das LLM oder Vision-Modell tatsächlich „Rechnungsnummer", „Lieferantenname", „Gesamtbetrag" aus dem geparsten Dokument. Es erfordert Prompt-Engineering pro Dokumententyp: Ein Prompt, der bei 50 Rechnungen eines Lieferanten funktioniert, versagt beim Format eines anderen Lieferanten. Sie schreiben nicht einen Prompt. Sie schreiben und pflegen Prompts pro Dokumententyp, pro Variante und pro Grenzfall.

Ausgabe-Routing und Validierung. Extrahierte Daten benötigen eine konfidenzbasierte Sortierung – Ergebnisse mit hoher Konfidenz werden automatisch an die Datenbank weitergeleitet, Ergebnisse mit niedriger Konfidenz landen in einer Warteschlange zur manuellen Prüfung. Das Erstellen dieser Warteschlange bedeutet, eine Benutzeroberfläche zu bauen, in der Prüfer nur das spezifische Feld sehen, das sie überprüfen müssen, nicht das gesamte Dokument – eine separate Frontend-Entwicklungsaufgabe.

Beobachtbarkeit und Überwachung. Sie müssen wissen, wann die Extraktionsgenauigkeit nachlässt, wann ein neues Dokumentenformat stillschweigend zu scheitern beginnt und wann die API-Kosten steigen. Dies ist ein Überwachungssystem, das auf der Extraktionspipeline aufbaut – Dashboards, Warnungen, Erkennung von Genauigkeitsabweichungen. Jedes davon ist ein eigenständiges Entwicklungsprojekt.

Die vollständige Dokumentenextraktionspipeline ist ein Engineering-Stack, kein Feature. Ein Dokumentenextraktionssystem ist im Kern eine Pipeline, die unstrukturierte Dokumente in strukturierte, abfragbare Daten umwandelt – und jede Komponente in dieser Pipeline ist etwas, das Sie entweder bauen oder kaufen.

Die tatsächliche Rechnung im ersten Jahr: Entwicklerzeit + API-Kosten + Infrastruktur

Legen wir für jede Ebene konkrete Zahlen vor. Es handelt sich um konservative Schätzungen, basierend auf veröffentlichten Preislisten und US-amerikanischen Gehaltsdaten für Entwickler – nicht auf Marketingmaterial der Anbieter.

Entwicklungskosten basierend auf 132.000 $/Jahr (voll belastet) für einen mittleren bis erfahrenen Entwickler (~2.750 $/Woche). US News meldete für 2024 ein medianges Gehalt für Softwareentwickler von 133.080 $; voll belastet mit Zusatzleistungen, Lohnsteuern und Gemeinkosten kommen 25–40 % hinzu. Die Zeitspannen beziehen sich auf Produktionsqualität, nicht auf einen Prototypen.

Jetzt kommen die API-Kosten hinzu. Jedes Dokument, das Ihre Pipeline durchläuft, trifft auf mindestens eine kostenpflichtige Cloud-API – das LLM oder Vision-Modell, das die Extraktion durchführt. So sehen die Kosten pro Seite bei Produktionsvolumen aus:

Die API-Kosten wirken auf den ersten Blick gering – und bei niedrigen Volumen sind sie das auch. Bei 1.000 Seiten pro Monat liegt Ihre gesamte API-Rechnung bei 30–65 $. Bei 100.000 Seiten pro Monat kann allein GPT-4o 250–1.000 $ erreichen. Und diese Kosten pro Seite multiplizieren sich über jedes zu verarbeitende Dokument, jeden Wiederholungsversuch bei fehlgeschlagener Extraktion und jede erneute Verarbeitung bei Prompt-Optimierung.

Hinzu kommt die Infrastruktur – Cloud-Compute für die Pipeline-Orchestrierung, Datenspeicher für Dokumente und Ergebnisse, Monitoring-Tools, CI/CD für die Pipeline selbst. Ein bescheidenes Setup kostet 200–500 $ pro Monat. Im größeren Maßstab noch mehr.

Gesamtkosten im ersten Jahr für eine produktionsreife Pipeline, die von einem Entwickler erstellt wird: 60.000 bis 95.000 $. Für ein Team von zwei Personen (realistischer für Ausfallsicherheit und Wissensverteilung): das Doppelte. Die Kosten für ein SaaS-Abonnement zur Dokumentenextraktion – 19 bis 59 $ pro Monat – sind ein Rundungsfehler dieser Summe.

Die versteckten Kosten, die niemand einplant

Die Baukosten für das erste Jahr kalkuliert jedes Team. Was danach kommt, wird gern übersehen – und dieser Teil ist größer.

Formatänderungen sind Wartungsereignisse. Jeder Geschäftspartner, der seine Rechnungsvorlage aktualisiert, jeder Lieferant, der auf ein neues PDF-Layout umstellt, jede Verordnung, die ein neues Pflichtfeld hinzufügt – jede Änderung ist ein Wartungsereignis in Ihrer Pipeline: Fehler identifizieren, reproduzieren, Extraktionsregel anpassen, Korrektur testen, neu ausrollen. Ein häufiges Muster, das Betriebsteams melden: Die Extraktionsgenauigkeit sinkt nicht, weil das Extraktionsmodell schlechter wird, sondern weil Geschäftspartner ihre Dokumentformate ohne Vorankündigung ändern. Drei Lieferanten gestalten ihre Rechnungen um, und eine Pipeline, die zu 94 % genau war, fällt leise auf 78 %. Das Team merkt es erst, wenn die Ausnahmeraten in die Höhe schnellen – zu diesem Zeitpunkt fließen bereits seit Wochen falsche Daten in nachgelagerte Systeme.

Bei geringem Volumen – ein paar hundert Dokumente von einer Handvoll bekannter Lieferanten – sind diese Ereignisse selten genug, um sie ad hoc zu bewältigen. Bei Produktionsvolumen mit Hunderten von Dokumentquellen treffen neue Formatvarianten schneller ein, als ein Entwickler sie patchen kann. Die Pipeline erreicht nie einen stabilen Zustand.

Modellaktualisierungen beeinträchtigen leise Ihre Genauigkeit. Wenn Sie auf einer LLM-API (GPT-4o, Claude, Gemini) aufbauen, kontrollieren Sie das Modell nicht. Wenn der Anbieter ein Update ausliefert, können Ihre Prompts – auf die vorherige Version abgestimmt und getestet – anders reagieren. Die Ausgabeformatierung driftet. Feld-Extraktionsmuster verschieben sich. Es sind keine dramatischen Ausfälle, sondern subtile Verschlechterungen, die sich über Tausende von Dokumenten ansammeln, bevor sie jemand bemerkt. Um sie zu erkennen, muss ein Evaluierungs-Framework vorgehalten werden: zurückgehaltene Testdokumente, Regressionstests, gesteuerter Rollout. Das ist keine Bonusaufgabe – es ist eine fortlaufende Engineering-Aufgabe.

Prompt-Engineering ist arbeitsteilig pro Dokumenttyp. Ein Prompt, der zuverlässig Daten aus einer standardmäßigen US-Rechnung extrahiert, kann bei einer brasilianischen Nota Fiscal oder einer deutschen Rechnung versagen – andere Feldnamen, andere Layout-Konventionen, andere Rechtsterminologie. Wenn Ihr Unternehmen fünf Dokumenttypen verarbeitet, pflegen Sie mindestens fünf Extraktions-Prompts plus Varianten für die Format-Eigenheiten jedes wichtigen Lieferanten. Wenn ein Lieferant sein Layout ändert (siehe oben), muss der Prompt aktualisiert werden. Das ist wiederkehrende, volumenabhängige Arbeit, die in ersten Schätzungen nie enthalten ist.

Die menschliche Prüfschlange wächst mit dem Volumen. Keine Extraktionspipeline erreicht eine 100%ige Durchlaufverarbeitung. Die 5–15 % der Dokumente, die unter Ihrem Konfidenzschwellenwert liegen, müssen von einem Menschen überprüft oder korrigiert werden. Die Entwicklung dieser Prüfoberfläche ist ein Engineering-Projekt. Die Personalbesetzung ist ein laufender Betriebskostenfaktor. Ohne sie gelangen Fehler unentdeckt in Ihre Datenbank. Ein Entwickler beschrieb auf Reddit die Herausforderung: LLM-Konfidenzwerte sind keine kalibrierten Wahrscheinlichkeiten – wenn GPT bei einem handschriftlichen Wert 99 % Konfidenz angibt, ist die Zahl praktisch bedeutungslos. Sein Team baute schließlich eine ganze Open-Source-Verifizierungsschicht für Dokumenttypen, bei denen Genauigkeit wirklich zählt. Das ist ein separates Produkt, gebaut, um ein Problem zu beheben, das der ursprüngliche Entwickler nicht vorhergesehen hatte.

Compliance-Dokumentation ist ein jährliches Projekt. Wenn Ihre Pipeline Dokumente verarbeitet, die unter SOC 2, HIPAA oder GDPR fallen – Rechnungen mit personenbezogenen Daten, medizinische Unterlagen, Steuerformulare – tragen Sie die volle Verantwortung für die Compliance-Oberfläche. Jede Komponente Ihrer Pipeline (Erfassung, Parsing, Extraktion, Speicherung, Drittanbieter-API-Schlüssel) muss für jeden jährlichen Compliance-Zyklus dokumentiert, geprüft und verifiziert werden. Allein die Erstellung der Dokumentation ist ein mehrjähriges Projekt. SaaS-Anbieter verteilen diese Kosten auf ihre Kundenbasis; Ihre hauseigene Pipeline trägt die vollen Kosten.

Gartners CIO-Forschung ergab, dass technische Schulden 20–40 % des Technologiewerts ausmachen – und bei hauseigenen Dokumenten-Pipelines ist die Wartung der dominierende Posten dieser Schulden. Der Bau ist ein einmaliges Ereignis. Die Wartung ist für immer.

Was SaaS für 19–59 €/Monat tatsächlich liefert

Die Ökonomie der SaaS-Dokumentenextraktion ist einfach: Der Anbieter baut die Pipeline einmal und verkauft den Zugang an Tausende von Kunden. Sie zahlen für einen Bruchteil der Wartung, nicht für das Ganze.

Ein SaaS-Tool in der Preisklasse 19–59 €/Monat umfasst in der Regel einen vollständigen Dokumentenverarbeitungsstapel: Datei-Upload (PDF, JPG, PNG, WebP), automatische Dokumentenvorverarbeitung, KI-gestützte Extraktion, die über Dokumentenlayouts hinweg funktioniert, ohne dass eine lieferantenspezifische Vorlagenkonfiguration erforderlich ist, Stapelverarbeitung, bei der Sie mehrere Dateien hochladen und eine zusammengeführte Tabelle erhalten, Export nach Excel, CSV oder JSON sowie eine webbasierte Oberfläche, die von nicht-technischen Teammitgliedern genutzt werden kann.

Einige Tools – darunter ImageToTable.ai – gehen noch weiter mit Funktionen, die jeweils eigenständige Entwicklungsprojekte in einem hauseigenen Build wären. Benutzerdefinierte Spaltenextraktion: Sie geben die gewünschten Feldnamen ein (z. B. „Rechnungsnummer, Lieferant, Gesamtbetrag, Fälligkeitsdatum“) und die KI lokalisiert jeden Wert überall auf der Seite, indem sie versteht, was er bedeutet, nicht wo er sitzt. In einem hauseigenen Build ist diese semantische Extraktionslogik die zentrale technische Herausforderung – das, woran Sie Wochen des Prompt-Engineerings verbringen, um es zu optimieren. Hier ist es eine Texteingabe. Sammlungslink: eine teilbare URL, über die Kunden, Außendienstmitarbeiter oder Lieferanten Dokumente direkt in Ihre Verarbeitungswarteschlange hochladen können, ohne Konten zu erstellen. Bauen Sie das selbst, und Sie bauen einen Multi-Tenant-Datei-Upload-Dienst mit Authentifizierung – ein weiteres Engineering-Projekt. Der 6-dimensionale Bewertungsrahmen zeigt, wie diese Fähigkeiten über Tools hinweg abschneiden, aber das Muster bleibt: Die Funktionen, die auf einer Funktionsliste klein klingen, sind vollwertige Engineering-Aufwände, wenn Sie sie selbst schreiben.

Der stille Vorteil von SaaS ist, dass Modellverbesserungen ohne Ihr Zutun erfolgen. Wenn das zugrunde liegende Vision-Modell besser wird – und diese Modelle verbessern sich rasant – aktualisiert ein SaaS-Anbieter das Backend, und jeder Kunde profitiert. Ihre hauseigene Pipeline, die an eine Modellversion von vor 12–18 Monaten gebunden ist, fällt zurück, ohne eine bewusste Engineering-Investition zum Upgrade, Regressionstest und erneuten Deployment.

Das bedeutet nicht, dass SaaS immer die richtige Antwort ist. Es bedeutet, dass der Kostenvergleich nicht „19 €/Monat vs. kostenlos (weil Entwickler bereits auf der Gehaltsliste sind)“ ist. Entwicklerzeit, die bereits auf der Gehaltsliste ist, ist nicht kostenlos – sie wird von allem anderen abgezogen. Der wirkliche Vergleich ist „19 €/Monat vs. 60.000 €+ an umgeleiteter Engineering-Kapazität plus laufende Wartung für immer.“ Eine Analyse von Abonnement vs. Pay-as-you-go fügt der Build-vs.-Buy-Frage eine weitere Nuance hinzu – die beiden Entscheidungen interagieren, sind aber nicht dieselbe Entscheidung.

Wann Eigenentwicklung sinnvoll ist

Eigenentwicklung ist nicht immer falsch. Sie ist in bestimmten, vertretbaren Szenarien sinnvoll – und diese zu erkennen, bewahrt Sie davor, ein Tool zu kaufen, das Sie jahrelang frustrieren wird.

Ihre Dokumenttypen sind wirklich einzigartig. Wenn Sie Bau-Zahlungsanträge nach AIA G702, brasilianische Nota-Fiscal-XML-Rechnungen oder japanische qualifizierte Rechnungen mit strengen regulatorischen Feldern verarbeiten – Dokumenttypen, für die Standard-SaaS-Tools nicht ausgelegt sind – kann eine Eigenentwicklung eine Extraktionsqualität liefern, die kein generisches Tool erreicht. Das Schlüsselwort ist „wirklich". Die meisten Teams überschätzen, wie einzigartig ihre Dokumente sind. Ein Bestellschein ist ein Bestellschein, unabhängig von der Branche. Testen Sie vor der Entscheidung für Eigenentwicklung, ob ein SaaS-Tool Ihre Felder aus einer Stichprobe extrahieren kann. Wenn ja, ist das Einzigartigkeits-Argument hinfällig.

Datenschutz erfordert abgeschottete Verarbeitung. Wenn Ihre Dokumente Informationen enthalten, die Ihr System rechtlich nicht verlassen dürfen – klassifizierte Regierungsdaten, sensible medizinische Unterlagen unter strengen Datenresidenz-Regeln, Finanzdaten mit internen Compliance-Richtlinien, die die Verarbeitung durch Dritte verbieten – bleibt Ihnen oft keine Wahl. Prüfen Sie dennoch, ob SaaS-Anbieter On-Premise- oder VPC-Bereitstellung anbieten, bevor Sie Eigenentwicklung als einzigen Weg annehmen.

Dokumentextraktion ist Ihr Produkt, kein Kostenfaktor. Wenn das Kernangebot Ihres Startups eine KI-gestützte Dokumentenanalyse-Plattform ist, müssen Sie die Extraktionsebene selbst besitzen. Der Zukauf macht Ihre Kernkompetenz abhängig von der Roadmap und Preisgestaltung eines Drittanbieters. Dies ist das stärkste Argument für Eigenentwicklung – wenn Extraktion der Differenzierer ist, nicht der operative Overhead.

Das Volumen ist hoch genug, dass API-Margen zählen. Ab 500.000+ Seiten pro Monat summieren sich die Seitenkosten von Google Document AI ($0,03) auf $15.000/Monat allein für API-Kosten. In dieser Größenordnung kann sich die Investition in eine maßgeschneiderte Extraktionspipeline mit niedrigeren Stückkosten innerhalb eines Jahres amortisieren. Der Break-Even-Punkt variiert je nach tatsächlichem Volumen – rechnen Sie ihn aus, gehen Sie nicht davon aus.

Eine nützliche Faustregel: Wenn Ihr Team bereits produktive ML-Pipelines entwickelt und gewartet hat, kennen Sie den Umfang dessen, worauf Sie sich einlassen. Wäre dies das erste ML-Infrastrukturprojekt Ihrer Organisation, übersteigen die Lernkosten allein oft das erste Jahr eines SaaS-Abonnements.

Der Hybrid-Ansatz: Kern kaufen, drumherum bauen

Die Frage „Eigenentwicklung vs. Kauf“ wird meist als binäre Entscheidung dargestellt. In der Praxis ist die häufigste – und effektivste – Antwort weder reine Eigenentwicklung noch reiner Kauf. Es ist ein Hybrid: Kaufen Sie die Extraktionsebene, bauen Sie die Integrationen und Workflows, die sie für Ihren spezifischen Betrieb nützlich machen.

Die Extraktionsebene – Dokumentenanalyse, Felderkennung, Datenstrukturierung – ist der schwierigste Teil, den man gut selbst entwickeln kann, und der Teil, bei dem die SaaS-Ökonomie am überzeugendsten ist. Die umgebende Ebene – wie extrahierte Daten in Ihr ERP fließen, wie sie nachgelagerte Genehmigungen auslösen, wie sie in Ihren internen Dashboards erscheinen – ist der Ort, an dem Anpassung echten geschäftlichen Mehrwert schafft, ohne dass Sie Computer-Vision-Probleme lösen müssen.

Deshalb schaffen Tools, die sowohl eine No-Code-Oberfläche als auch eine API bieten, einen praktischen Weg zum Hybrid. Ein Finanzteam nutzt die Browser-Oberfläche, um diese Woche 200 Rechnungen zu verarbeiten, während ein Entwickler die Integration schreibt, die denselben Ablauf im nächsten Quartal automatisiert – gleiche Extraktionsebene, unterschiedliche Interaktionsebenen. Die Entscheidung zwischen API und No-Code ist kein Entweder-Oder, wenn die zugrunde liegende Extraktions-Engine beides unterstützt – es ist ein Migrationspfad vom schnellsten, was heute funktioniert, zum skalierbarsten für morgen.

Die Frage „Eigenentwicklung vs. Kauf“ führt nach einer Kostenanalyse meist zu drei praktischen Antworten: Kaufen, wenn Ihre Dokumente Standard sind und das Volumen kein dediziertes Entwicklungsteam rechtfertigt; selbst entwickeln, wenn Extraktion Ihr Produkt ist und Sie die ML-Infrastruktur dafür haben; Hybrid für alles dazwischen – lassen Sie den Anbieter das Dokumentenverständnis übernehmen, nutzen Sie Ihre Entwicklungsressourcen für die Integrationslogik, die die Extraktion mit dem Rest Ihres Unternehmens verbindet.

Häufig gestellte Fragen

Was kostet es tatsächlich, eine Dokumentenextraktion selbst zu entwickeln?

Für eine produktionsreife Pipeline, die mehrere Dokumenttypen verarbeitet – Erfassung, Klassifizierung, OCR, Extraktion, Validierung, Überwachung und Integration – sind im ersten Jahr mit Ingenieurskosten von 60.000 bis 95.000 US-Dollar für einen Entwickler bzw. 120.000 bis 190.000 US-Dollar für ein Zweipersonenteam zu rechnen. Das deckt den Bau ab. Die laufende Wartung (Formatänderungen, Modellaktualisierungen, Prompt-Engineering, Compliance-Dokumentation) schlägt jährlich mit 20–30 % der anfänglichen Baukosten zu Buche. Eine vollständige Analyse der Preislandschaft ordnet die SaaS-Alternative ein – die meisten Tools kosten zwischen 19 und 500 US-Dollar pro Monat, je nach Volumen und Funktionen.

Kann ich nicht einfach die GPT-4o Vision API nutzen und fertig?

Für einen Proof of Concept mit 20 Dokumenten – ja. Für den Produktiveinsatz mit 2.000 Dokumenten pro Monat von 50 verschiedenen Lieferanten – nein. Die GPT-4o API bietet eine rohe Extraktionsfähigkeit. Sie bietet keine Dokumentenklassifizierung, Formatnormalisierung, Fehlerbehandlung, konfidenzbasierte Weiterleitung, eine Prüfwarteschlange, Ausgabeformatierung, Stapelverarbeitung, Excel-Export oder Überwachung. All das sind Ingenieursaufgaben. Die API ist eine Komponente eines Sechs-Komponenten-Systems. Bei geringem Volumen sind die anderen fünf Komponenten der dominierende Kostenfaktor. Bei hohem Volumen werden die API-Kosten selbst erheblich – GPT-4o Vision in hoher Auflösung kostet etwa 2,50–10 US-Dollar pro 1.000 Bilder, und Verarbeitungsfehler, die Wiederholungen auslösen, vervielfachen diese Kosten.

Was ist der größte Fehler, den Teams bei der Kostenschätzung für die Eigenentwicklung machen?

Die Baukosten mit „ein Entwickler für zwei Monate" zu veranschlagen und dabei stehenzubleiben. Der Bau ist der kleinere Teil der Gesamtkosten. Der größere Teil – die laufende Wartung – beginnt am Tag der Auslieferung und endet nie: Formatänderungen von Geschäftspartnern, Modellaktualisierungen von API-Anbietern, Prompt-Engineering für neue Dokumenttypen, Regressionstests der Genauigkeit und die menschliche Prüfwarteschlange, die mit dem Volumen wächst. Die meisten kundenspezifischen Projekte fallen am Ende 30–50 % teurer aus als ursprünglich geschätzt, weil sich der Umfang während der Entwicklung ausweitet und die jährliche Wartungslast – 20–30 % der Baukosten pro Jahr – selten im ursprünglichen Budget enthalten ist.

Ab welchem Dokumentenvolumen wird Eigenbau günstiger als Kauf?

Bei Standard-Dokumenttypen (Rechnungen, Belege, Bestellungen) ist Kaufen bei fast jeder Menge bis zu Hunderttausenden Seiten pro Monat günstiger – die SaaS-Abonnementkosten (19–500 $/Monat) liegen um Größenordnungen unter den Vollkosten selbst eines Teilzeit-Entwicklers (ab 2.750 $/Woche). Bei extrem hohen Volumen (ab 500.000 Seiten/Monat) können die API-Kosten pro Seite einer Eigenentwicklung zwar an den SaaS-Preis herankommen, aber der Wartungsaufwand bleibt bestehen. Die Break-Even-Rechnung muss sowohl Entwicklerzeit als auch laufende Wartung einbeziehen, nicht nur API-Kosten. Für die meisten Organisationen, die unter 100.000 Dokumente pro Monat verarbeiten, rechnet sich Eigenbau nicht – er verliert Geld im Vergleich zum Kauf.

Was ist mit Open-Source-OCR wie Tesseract?

Tesseract ist kostenlos nutzbar und kann Text aus sauberen, gut strukturierten Dokumenten extrahieren. Es verarbeitet keine komplexen Layouts, Tabellen, Handschriften oder semantisches Verständnis – es liefert Rohtext, keine strukturierten Daten. Der Aufbau der strukturierten Extraktionsebene auf Tesseract erfordert denselben Prompt-Engineering-, Klassifikations-, Validierungs- und Ausgabe-Routing-Aufwand wie oben beschrieben, plus zusätzliche Entwicklung für Fälle, in denen Tesseracts OCR-Qualität nicht ausreicht (niedrig aufgelöste Scans, nicht-lateinische Schriften, gemischte Dokumente). Kostenlose OCR spart die API-Kosten pro Seite, aber nicht die Entwicklungszeit – und Entwicklungszeit ist der dominierende Kostenfaktor bei jedem Eigenbau.

Wie lange dauert der Bau einer produktionsreifen Dokumentextraktions-Pipeline?

Ein funktionsfähiger Proof of Concept – ein Dokumenttyp, bekannte Formate, keine Prüfwarteschlange – ist in 2–3 Wochen machbar. Eine produktionsreife Pipeline für mehrere Dokumenttypen mit Klassifikation, Fehlerbehandlung, Validierungs-UI, Monitoring und CI/CD benötigt 20–31 Wochen für einen Entwickler, um die erste Produktionsqualität zu erreichen, und weitere 2–3 Monate Iteration, bis sie sich im Volumen stabilisiert. Der Zeitrahmen verdoppelt sich, wenn Ihr Team keine Vorerfahrung mit ML-Infrastruktur hat. Im Gegensatz dazu kann ein SaaS-Tool Dokumente innerhalb einer Stunde nach Anmeldung verarbeiten – der Unterschied ist nicht marginal, sondern kategorial.

Wo anfangen

Die Build-vs.-Buy-Entscheidung erfordert keine perfekte Antwort am ersten Tag – sie erfordert ein ehrliches Kostenmodell und einen Test. Der Test kostet nichts. Laden Sie einen Stapel Ihrer tatsächlichen Dokumente hoch – keine kuratierte Stichprobe, sondern die echten von echten Gegenparteien – und prüfen Sie, ob ein SaaS-Tool die benötigten Felder extrahiert. Wenn es funktioniert, haben Sie die Frage für 19 $ beantwortet. Wenn nicht, wissen Sie zumindest, wogegen Sie entwickeln, und können die Lücke zwischen dem, was existiert, und dem, was Sie brauchen, mit echten Daten statt mit Annahmen bepreisen.