Build vs. Buy: Dokumentextraktion –
Was Eigenentwicklung wirklich kostet

Was „Build" tatsächlich bedeutet — nicht ein API-Aufruf, sondern sechs Systeme

Der Satz „wir bauen einfach Dokumentextraktion mit GPT" reduziert mindestens sechs verschiedene technische Systeme auf vier Wörter. Hier ist, was eine produktionsreife Pipeline — eine, die echte Dokumente von echten Geschäftspartnern verarbeitet, nicht kuratierte Demo-Beispiele — tatsächlich erfordert:

Erfassung und Vorverarbeitung. Rohe Dokumente 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.

Dokumentklassifizierung. Eine Lieferantenrechnung, ein Kontoauszug, ein handsignierter Vertrag und ein Foto einer Quittung benötigen alle unterschiedliche Extraktionsstrategien. Die Klassifizierung leitet jedes Dokument an den richtigen Verarbeitungspfad — und liegt oft genug falsch, sodass Sie eine Fallback-Ebene benötigen. Ein Entwickler, der eine Dokumentextraktionsplattform gebaut hat, beschrieb die Kernaussage auf Reddit: „Dokumentextraktion dreht sich weniger darum, ein perfektes Modell zu finden, sondern mehr darum, ein System zu bauen, das Tausende verschiedener Dokumentvarianten 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 sind. Die Document-AI-Preisseite bei Google Cloud listet einen separaten Layout-Parser-Prozessor für $10 pro 1.000 Seiten — Layout-Erkennung allein 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 Dokumenttyp: Ein Prompt, der bei 50 Rechnungen eines Lieferanten funktioniert, scheitert am Format eines anderen Lieferanten. Sie schreiben nicht einen Prompt. Sie schreiben und pflegen Prompts pro Dokumenttyp, pro Variante und pro Randfall.

Ausgaberouting und Validierung. Extrahierte Daten benötigen eine konfidenzbasierte Sortierung — Ergebnisse mit hoher Konfidenz werden automatisch an die Datenbank weitergeleitet, Ergebnisse mit niedriger Konfidenz gehen an eine menschliche Prüfwarteschlange. Diese Warteschlange zu bauen bedeutet, eine UI zu bauen, in der Prüfer nur das spezifische Feld sehen, das sie verifizieren müssen, nicht das gesamte Dokument — eine separate Frontend-Engineering-Aufgabe.

Beobachtbarkeit und Monitoring. Sie müssen wissen, wann die Extraktionsgenauigkeit nachlässt, wann ein neues Dokumentformat stillschweigend zu scheitern beginnt und wann API-Kosten steigen. Das ist ein Überwachungssystem, das auf der Extraktionspipeline aufbaut — Dashboards, Alerts, Erkennung von Genauigkeitsabweichungen. Jedes davon ist ein eigenes Entwicklungsprojekt.

Die vollständige Dokumentextraktionspipeline ist ein Engineering-Stack, kein Feature. Ein Dokumentextraktionssystem 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

Lassen Sie uns die Kosten für jede Ebene beziffern. Dies sind konservative Schätzungen, basierend auf veröffentlichten Preislisten und US-Entwicklergehältern, nicht auf Marketingmaterial der Anbieter.

Entwicklungskosten basierend auf $132.000/Jahr inkl. Lohnnebenkosten für einen mittleren bis leitenden Entwickler (~$2.750/Woche). US News berichtete 2024 ein mittleres Softwareentwickler-Gehalt von $133.080; inkl. Zusatzleistungen, Lohnsteuern und Gemeinkosten kommen 25–40% hinzu. Die Zeitspannen spiegeln Produktionsqualität wider, keine Demo.

Jetzt kommen die API-Kosten hinzu. Jedes Dokument, das durch Ihre Pipeline lä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 Volumina sind sie das auch. Bei 1.000 Seiten pro Monat könnte Ihre gesamte API-Rechnung $30–$65 betragen. Bei 100.000 Seiten pro Monat könnte allein GPT-4o $250–$1.000 erreichen. Und diese Kosten pro Seite multiplizieren sich über jedes Dokument, das Sie verarbeiten müssen, jeden erneuten Versuch bei fehlgeschlagener Extraktion und jede erneute Verarbeitung, wenn Sie den Prompt iterieren.

Dann kommt die Infrastruktur hinzu – Cloud-Compute für Ihre Pipeline-Orchestrierung, Datenspeicherung für Dokumente und Ausgaben, Monitoring-Tools, CI/CD für die Pipeline selbst. Ein bescheidenes Setup kostet $200–$500 pro Monat. Bei größerem Umfang 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 Abdeckung und Bus-Faktor): das Doppelte. Die Kosten für ein SaaS-Abonnement für Dokumentenextraktion – $19 bis $59 pro Monat – sind im Vergleich dazu ein Rundungsfehler.

Die versteckten Kosten, die niemand einplant

Die Baukosten im ersten Jahr sind der Teil, den Teams kalkulieren. Den Teil, den sie überspringen, ist alles, was nach dem Launch passiert – und dieser Teil ist größer.

Formatänderungen sind Wartungsereignisse. Jeder Geschäftspartner, der seine Rechnungsvorlage aktualisiert, jeder Anbieter, der auf ein neues PDF-Layout umstellt, jede Verordnung, die ein Pflichtfeld hinzufügt – jede Änderung ist ein Wartungsereignis in Ihrer Pipeline: Fehler identifizieren, reproduzieren, Extraktionsregel patchen, Fix testen, neu bereitstellen. Ein häufiges Muster, das von Betriebsteams berichtet wird: Die Extraktionsgenauigkeit nimmt nicht ab, weil das Extraktionsmodell schlechter geworden ist, sondern weil Geschäftspartner ihre Dokumentformate ohne Vorankündigung geändert haben. Drei Anbieter gestalten ihre Rechnungen neu, und eine Pipeline, die zu 94 % genau war, fällt leise auf 78 %. Das Team bemerkt es erst, wenn die Ausnahmeraten steigen – zu diesem Zeitpunkt fließen bereits seit Wochen falsche Daten in nachgelagerte Systeme.

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

Modellupdates brechen Ihre Genauigkeit stillschweigend. Wenn Sie auf einer LLM-API (GPT-4o, Claude, Gemini) aufbauen, kontrollieren Sie das Modell nicht. Wenn der Anbieter ein Update ausliefert, können sich Ihre Prompts – abgestimmt und getestet gegen die vorherige Version – anders verhalten. Die Ausgabeformatierung driftet. Feld-Extraktionsmuster verschieben sich. Das sind keine dramatischen Ausfälle; es sind subtile Verschlechterungen, die sich über Tausende von Dokumenten ansammeln, bevor sie jemand bemerkt. Um sie zu erkennen, müssen Sie eine Evaluierungsumgebung pflegen: zurückgehaltene Testdokumente, Regressionstests, kontrollierte Einführung. Das ist keine Bonusaufgabe – es ist eine fortlaufende Engineering-Funktion.

Prompt-Engineering ist Arbeit pro Dokumenttyp. Ein Prompt, der zuverlässig Daten aus einer Standard-US-Rechnung extrahiert, kann bei einer brasilianischen Nota Fiscal oder einer deutschen Rechnung scheitern – andere Feldnamen, andere Layoutkonventionen, anderes juristisches Vokabular. 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, volumenkorrelierte Arbeit, die in ersten Schätzungen nie enthalten ist.

Die Warteschlange für die menschliche Prüfung wächst mit dem Volumen. Keine Extraktionspipeline erreicht 100 % Durchsatz ohne Zwischenschritte. Die 5–15 % der Dokumente, die unter Ihre Konfidenzschwelle fallen, benötigen einen Menschen zur Überprüfung oder Korrektur. Diese Prüfoberfläche zu bauen, ist ein Engineering-Projekt. Sie zu besetzen, ist eine laufende Betriebskosten. 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 meldet, ist die Zahl praktisch bedeutungslos. Ihr Team endete damit, eine gesamte Open-Source-Verifizierungsebene für Dokumenttypen zu bauen, bei denen Genauigkeit wirklich zählt. Das ist ein separates Produkt, das gebaut wurde, um ein Problem zu lösen, 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. 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 mehrmonatiges Projekt. SaaS-Anbieter verteilen diese Kosten auf ihre Kundenbasis; Ihre interne Pipeline zahlt den vollen Preis.

Gartners CIO-Forschung zeigt, dass technische Schulden 20–40 % des Technologiewerts konsumieren — und bei internen Dokument-Pipelines ist die Wartung der dominierende Posten dieser Schulden. Der Aufbau ist ein einmaliges Ereignis. Die Wartung ist für immer.

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

Die Ökonomie der SaaS-Dokumentextraktion ist einfach: Der Anbieter baut die Pipeline einmal und verkauft den Zugang über 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 typischerweise einen vollständigen Dokumentverarbeitungs-Stack: Datei-Upload (PDF, JPG, PNG, WebP), automatische Dokumentvorverarbeitung, KI-gestützte Extraktion, die über Dokumentlayouts hinweg ohne Lieferanten-spezifische Vorlagenkonfiguration funktioniert, 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 auch von nicht-technischen Teammitgliedern genutzt werden kann.

Einige Tools — einschließlich ImageToTable.ai — gehen mit Funktionen weiter, die jeweils eigenständige Entwicklungsprojekte in einem internen Build wären. Benutzerdefinierte Spaltenextraktion: Sie geben die gewünschten Feldnamen ein (z. B. „Rechnungsnummer, Lieferant, Gesamtbetrag, Fälligkeitsdatum") und die KI findet jeden Wert überall auf der Seite, indem sie versteht, was er bedeutet, nicht wo er steht. In einem internen Build ist diese semantische Extraktionslogik die zentrale technische Herausforderung — das, wofür Sie Wochen mit Prompt-Engineering verbringen, um es zu optimieren. Hier ist es eine Texteingabe. Sammellink: eine teilbare URL, über die Kunden, Außendienstmitarbeiter oder Lieferanten Dokumente direkt in Ihre Verarbeitungswarteschlange hochladen können, ohne Konten zu erstellen. Wenn Sie das selbst bauen, bauen Sie einen mandantenfähigen Datei-Upload-Dienst mit Authentifizierung — ein weiteres Engineering-Projekt. Der 6-dimensionale Bewertungsrahmen behandelt, wie diese Funktionen über Tools hinweg abschneiden, aber das Muster bleibt: Die Funktionen, die auf einer Feature-Liste klein klingen, sind volle Engineering-Aufwände, wenn Sie sie selbst schreiben.

Der stille Vorteil von SaaS ist, dass Modellverbesserungen ohne Ihr Zutun geschehen. 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 interne Pipeline, die an eine Modellversion von vor 12–18 Monaten gebunden ist, fällt zurück, ohne eine bewusste Engineering-Investition in Upgrade, Regressionstests und erneutes 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 stehen)" ist. Entwicklerzeit, die bereits auf der Gehaltsliste steht, ist nicht kostenlos — sie wird von allem anderen abgezogen. Der echte Vergleich ist „19 $/Monat vs. 60.000 $+ an umgeleiteter Engineering-Kapazität plus laufende Wartung für immer". Eine Analyse von Abonnement vs. nutzungsbasierter Zahlung fügt der Build-vs-Buy-Frage zusätzliche Nuancen 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, verhindert, dass Sie ein Tool kaufen, das Sie jahrelang frustrieren wird.

Ihre Dokumenttypen sind wirklich einzigartig. Wenn Sie Bau-Zahlungsanträge nach AIA G702, brasilianische Rechnungen auf Basis von Nota-Fiscal-XML oder japanische qualifizierte Rechnungen mit strengen regulatorischen Pflichtfeldern verarbeiten – Dokumenttypen, für die Standard-SaaS-Tools nicht entwickelt wurden – 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. Eine Bestellung ist eine Bestellung, unabhängig von der Branche. Bevor Sie sich für eine Eigenentwicklung entscheiden, testen Sie, ob ein SaaS-Tool Ihre Felder aus einer Beispiel-Stichprobe extrahieren kann. Wenn das gelingt, ist das Einzigartigkeits-Argument hinfällig.

Datenschutz erfordert eine luftdichte Verarbeitung. Wenn Ihre Dokumente Informationen enthalten, die rechtlich Ihre Infrastruktur nicht verlassen dürfen – klassifizierte Regierungsdaten, sensible medizinische Aufzeichnungen unter strengen Datenresidenz-Regeln, Finanzdaten, die internen Compliance-Richtlinien unterliegen, die eine Verarbeitung durch Dritte verbieten – dann bleibt Ihnen möglicherweise keine andere Wahl als eine Eigenentwicklung. Auch hier gilt: Prüfen Sie, ob SaaS-Anbieter On-Premise- oder VPC-Bereitstellung anbieten, bevor Sie annehmen, dass Eigenentwicklung der einzige Weg ist.

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 Kauf von einem Anbieter macht Ihre Kernkompetenz abhängig von der Roadmap und Preisgestaltung eines Dritten. Das ist das stärkste Argument für Eigenentwicklung – wenn Extraktion das Unterscheidungsmerkmal ist, nicht der operative Overhead.

Das Volumen ist hoch genug, dass API-Margen eine Rolle spielen. Bei 500.000+ Seiten pro Monat summieren sich die Seitenkosten von Google Document AI ($0,03) auf $15.000/Monat allein an API-Kosten. In dieser Größenordnung kann sich die Investition in eine maßgeschneiderte Extraktions-Pipeline mit niedrigeren Stückkosten innerhalb eines Jahres amortisieren. Aber der Break-even-Punkt verschiebt sich je nach tatsächlichem Volumen – rechnen Sie es durch, gehen Sie nicht von Annahmen aus.

Eine nützliche Faustregel: Wenn Ihr Team bereits Produktions-ML-Pipelines gebaut und gewartet hat, kennen Sie den Umfang dessen, worauf Sie sich einlassen. Wenn dies das erste ML-Infrastrukturprojekt Ihrer Organisation wäre, übersteigen die alleinigen Lernkosten oft das erste Jahr der SaaS-Abonnementgebühren.

Der Hybrid-Ansatz: Den Kern kaufen, darum herum bauen

Die Build-vs-Buy-Frage wird meist als binäre Entscheidung dargestellt. In der Praxis ist die häufigste – und effektivste – Antwort weder reines Build noch reines Buy. Es ist ein Hybrid: die Extraktionsebene kaufen, die Integrationen und Workflows selbst bauen, die sie für Ihren spezifischen Betrieb nützlich machen.

Die Extraktionsebene – Dokumentenanalyse, Felderkennung, Datenstrukturierung – ist der Teil, der am schwersten gut zu bauen ist, und der Teil, bei dem die SaaS-Ökonomie das stärkste Argument liefert. 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 Individualisierung echten geschäftlichen Mehrwert schafft, ohne dass Sie Computer-Vision-Probleme lösen müssen.

Deshalb bieten Tools, die sowohl eine No-Code-Oberfläche als auch eine API haben, 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 – dieselbe Extraktionsebene, verschiedene Interaktionsebenen. Die API-vs-No-Code-Entscheidung ist kein Entweder-oder, wenn die zugrunde liegende Extraktions-Engine beides unterstützt – sie ist ein Migrationspfad vom schnellsten, was heute funktioniert, zum skalierbarsten für morgen.

Die Build-vs-Buy-Frage, sobald Sie die Zahlen durchgerechnet haben, führt meist zu drei praktischen Antworten: kaufen, wenn Ihre Dokumente Standard sind und Ihr Volumen kein dediziertes Engineering-Team rechtfertigt; bauen, wenn Extraktion Ihr Produkt ist und Sie die ML-Infrastruktur haben, um sie zu besitzen; Hybrid für alles dazwischen – lassen Sie den Anbieter das Dokumentverständnis übernehmen, nutzen Sie Ihre Engineering-Ressourcen für die Integrationslogik, die die Extraktion mit dem Rest Ihres Unternehmens verbindet.

Häufig gestellte Fragen

Was kostet es tatsächlich, Dokumentextraktion intern aufzubauen?

Für eine produktionsreife Pipeline, die mehrere Dokumenttypen verarbeitet — Erfassung, Klassifizierung, OCR, Extraktion, Validierung, Überwachung und Integration — rechnen Sie mit 60.000–95.000 $ an Engineering-Kosten im ersten Jahr für einen Entwickler bzw. 120.000–190.000 $ für ein Zweipersonenteam. Das deckt den Aufbau ab. Die laufende Wartung (Formatänderungen, Modellupdates, Prompt-Engineering, Compliance-Dokumentation) schlägt jährlich mit 20–30 % der anfänglichen Aufbaukosten zu Buche. Eine vollständige Preisvergleichsanalyse setzt die SaaS-Alternative ins Verhältnis — die meisten Tools kosten je nach Volumen und Funktionen zwischen 19 $/Monat und 500 $/Monat.

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 Produktionsbetrieb mit 2.000 Dokumenten pro Monat von 50 verschiedenen Lieferanten — nein. Die GPT-4o API bietet eine reine Extraktionsfunktion. Sie bietet keine Dokumentklassifizierung, Formatnormalisierung, Fehlerbehandlung, konfidenzbasierte Weiterleitung, Prüfwarteschlange, Ausgabeformatierung, Stapelverarbeitung, Excel-Export oder Überwachung. Jede dieser Funktionen ist eine Engineering-Aufgabe. Die API ist eine Komponente eines Systems aus sechs Komponenten. Bei geringem Volumen sind die anderen fünf Komponenten der dominierende Kostenfaktor. Bei hohem Volumen werden die API-Kosten selbst erheblich — GPT-4o Vision kostet bei hoher Auflösung etwa 2,50–10 $ 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 den internen Aufbau machen?

Die Baukosten als „ein Entwickler für zwei Monate" zu veranschlagen und dabei stehen zu bleiben. Der Aufbau 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, Modellupdates von API-Anbietern, Prompt-Engineering für neue Dokumenttypen, Genauigkeits-Regressionstests und die menschliche Prüfwarteschlange, die mit dem Volumen wächst. Die meisten kundenspezifischen Projekte enden 30–50 % teurer 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 Dokumentvolumen ist Eigenentwicklung günstiger als Kauf?

Bei Standarddokumenttypen (Rechnungen, Belege, Bestellungen) ist der Kauf bei nahezu jedem Volumen bis zu mehreren hunderttausend Seiten pro Monat günstiger – die SaaS-Abonnementkosten (19–500 $/Monat) liegen um eine Größenordnung unter den vollständig belasteten Kosten selbst eines Teilzeit-Entwicklers (2.750 $+/Woche). Bei extrem hohen Volumen (500.000+ Seiten/Monat) können die API-Kosten pro Seite einer Eigenentwicklung den SaaS-Preis erreichen, aber der Wartungsaufwand bleibt bestehen. Die Break-even-Berechnung muss sowohl Entwicklungszeit als auch laufende Wartung berücksichtigen, nicht nur API-Kosten. Für die meisten Organisationen, die unter 100.000 Dokumente pro Monat verarbeiten, rechnet sich eine Eigenentwicklung nicht – sie 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, Handschrift oder semantisches Verständnis – es liefert Rohtext, keine strukturierten Daten. Der Aufbau der strukturierten Extraktionsschicht auf Tesseract erfordert dieselbe Prompt-Entwicklung, Klassifizierung, Validierung und Ausgabe-Routing wie oben beschrieben, plus zusätzliche Entwicklungsarbeit für Fälle, in denen die OCR-Qualität von Tesseract unzureichend ist (niedrig aufgelöste Scans, nicht-lateinische Schriften, Dokumente mit gemischten Inhalten). Kostenlose OCR spart die API-Kosten pro Seite, spart aber nicht die Entwicklungszeit – und Entwicklungszeit ist der dominierende Kostenfaktor bei jeder Eigenentwicklung.

Wie lange dauert es, eine produktionsreife Dokumentextraktions-Pipeline zu entwickeln?

Ein funktionsfähiger Proof of Concept – ein Dokumenttyp, bekannte Formate, keine Review-Warteschlange – kann in 2–3 Wochen erstellt werden. Eine produktionsreife Pipeline, die mehrere Dokumenttypen verarbeitet, mit Klassifizierung, Fehlerbehandlung, Validierungs-UI, Monitoring und CI/CD, benötigt 20–31 Wochen für einen Entwickler, um die anfängliche Produktionsqualität zu erreichen, und weitere 2–3 Monate Iteration, bevor sie sich bei Volumen stabilisiert. Die Zeitspanne verdoppelt sich, wenn Ihr Team keine Vorerfahrung mit ML-Infrastruktur hat. Im Gegensatz dazu kann ein SaaS-Tool Dokumente innerhalb einer Stunde nach der 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 Geschäftspartnern — 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.