Eigenbau vs. Kauf: 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. Rohe Dokumente kommen als PDFs, JPGs, PNGs, manchmal passwortgeschützt, manchmal beschädigt. Die Erfassungsschicht normalisiert Dateiformate, behandelt Fehler, ohne die Pipeline zum Absturz zu bringen, 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 benötigen alle unterschiedliche Extraktionsstrategien. Die Klassifizierung leitet jedes Dokument an den richtigen Verarbeitungspfad weiter – und liegt oft genug falsch, dass Sie eine Rückfallebene benötigen. Ein Entwickler, der eine Dokumentenextraktionsplattform gebaut hat, beschrieb die Kern-Erkenntnis auf Reddit: „Dokumentenextraktion bedeutet weniger, ein perfektes Modell zu finden, sondern vielmehr ein System zu bauen, das Tausende verschiedener Dokumentenvarianten verarbeiten kann.“

OCR und Layout-Analyse. Nicht alle PDFs enthalten auswählbaren Text. Viele sind Scans. Manche mischen Text, Tabellen und Bilder auf derselben Seite. Layout-Verständnis – das Erkennen von verbundenen Zellen, mehrspaltigen Berichten und verschachtelten Tabellen – erfordert Vision-Modelle, die selbst eine Spezialisierung darstellen. Die Preisseite von Document AI unter 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. Dies erfordert Prompt-Engineering pro Dokumenttyp: Ein Prompt, der bei 50 Rechnungen eines Lieferanten funktioniert, scheitert am Format eines anderen Lieferanten. Man schreibt nicht einen Prompt. Man schreibt und pflegt Prompts pro Dokumenttyp, pro Variante und pro Randfall.

Ausgabe-Routing und Validierung. Extrahierte Daten benötigen eine konfidenzbasierte Sortierung – Ergebnisse mit hoher Konfidenz werden automatisch in die Datenbank übernommen, Ergebnisse mit niedriger Konfidenz landen in einer manuellen Prüf-Warteschlange. Der Aufbau dieser Warteschlange erfordert eine Benutzeroberfläche, 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 Monitoring. Man muss erkennen, wann die Extraktionsgenauigkeit nachlässt, wann ein neues Dokumentformat stillschweigend zu scheitern beginnt und wann die API-Kosten steigen. Dies ist ein Überwachungssystem, das auf die Extraktions-Pipeline aufgesetzt wird – Dashboards, Warnungen, Erkennung von Genauigkeitsabweichungen. Jedes davon ist ein eigenständiges Entwicklungsprojekt.

Die vollständige Dokumenten-Extraktions-Pipeline ist ein Engineering-Stack, kein Feature. Ein Dokumenten-Extraktionssystem ist im Kern eine Pipeline, die unstrukturierte Dokumente in strukturierte, abfragbare Daten umwandelt – und jede Komponente dieser Pipeline wird entweder selbst entwickelt oder zugekauft.

Die tatsächliche Rechnung fürs erste Jahr: Entwicklerzeit + API-Kosten + Infrastruktur

Legen wir Zahlen für jede Schicht vor. Dies sind konservative Schätzungen, basierend auf veröffentlichten Preislisten und US-Entwicklergehältern, nicht auf Marketingmaterial von Anbietern.

Engineering-Kosten basierend auf 132.000 $/Jahr Vollkosten für einen mittleren bis erfahrenen Entwickler (~2.750 $/Woche). US News berichtete 2024 ein mittleres Softwareentwickler-Gehalt von 133.080 $; mit Zusatzleistungen, Lohnnebenkosten und Gemeinkosten kommen 25–40 % hinzu. Die Zeiträume beziehen sich auf Produktionsqualität, nicht auf einen Prototypen.

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 Preise 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 etwa 30–65 $. Bei 100.000 Seiten pro Monat kann allein GPT-4o 250–1.000 $ kosten. Und diese Kosten pro Seite multiplizieren sich mit jedem Dokument, das Sie verarbeiten müssen, jedem erneuten Versuch bei fehlgeschlagener Extraktion und jeder erneuten Verarbeitung, wenn Sie den Prompt optimieren.

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.

Die 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 in dieser Zahl ein Rundungsfehler.

Die versteckten Kosten, die niemand einplant

Die Baukosten für das erste Jahr sind der Teil, den Teams berechnen. Der Teil, den sie überspringen, ist alles, was nach dem Start passiert – 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 Pflichtfeld hinzufügt – jede Änderung ist ein Wartungsereignis in Ihrer Pipeline: Fehler identifizieren, reproduzieren, Extraktionsregel anpassen, Fix testen, neu bereitstellen. Ein häufiges Muster, das von Betriebsteams gemeldet wird: Die Extraktionsgenauigkeit sinkt nicht, weil das Extraktionsmodell schlechter geworden ist, 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 bemerkt es erst, wenn die Ausnahmeraten in die Höhe schnellen – zu diesem Zeitpunkt fließen bereits seit Wochen fehlerhafte 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 behandeln. 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 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 auf die vorherige Version – anders verhalten. Die Ausgabeformatierung driftet. Muster der Feldextraktion verschieben sich. Dies sind keine dramatischen Ausfälle; es sind subtile Verschlechterungen, die sich über Tausende von Dokumenten hinweg anhäufen, bevor sie jemand bemerkt. Um sie zu erkennen, muss ein Evaluierungsrahmen gepflegt werden: zurückgehaltene Testdokumente, Regressionstests, gesteuerter Rollout. Das ist keine Bonusaufgabe – es ist eine fortlaufende Engineering-Funktion.

Prompt-Engineering ist dokumententypspezifische Arbeit. Ein Prompt, der zuverlässig Daten aus einer Standard-US-Rechnung extrahiert, kann bei einer brasilianischen Nota Fiscal oder einer deutschen Rechnung scheitern – unterschiedliche Feldnamen, unterschiedliche Layoutkonventionen, unterschiedliche Rechtsterminologie. Wenn Ihr Unternehmen fünf Dokumententypen verarbeitet, pflegen Sie mindestens fünf Extraktions-Prompts, plus Varianten für die Formatbesonderheiten jedes wichtigen Lieferanten. Wenn ein Lieferant sein Layout ändert (siehe oben), muss der Prompt aktualisiert werden. Das ist wiederkehrende, mengenabhängige Arbeit, die in ersten Kostenschätzungen nie enthalten ist.

Die manuelle Prüfschlange wächst mit dem Volumen. Keine Extraktionspipeline erreicht eine 100%ige Durchlaufquote. Die 5–15 % der Dokumente, die unter Ihrer Konfidenzschwelle 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 meldet, ist die Zahl praktisch bedeutungslos. Sein Team baute schließlich eine vollständige Open-Source-Verifikationsebene für Dokumententypen, bei denen Genauigkeit wirklich zählt. Das ist ein separates Produkt, entwickelt, 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, Krankenakten, 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 Dokumentenpipelines 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 bietet

Die Wirtschaftlichkeit der SaaS-Dokumentenextraktion ist einfach: Der Anbieter baut die Pipeline einmal auf und verkauft den Zugang zu ihr 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 Dokumentenverarbeitungs-Stack: Datei-Upload (PDF, JPG, PNG, WebP), automatische Dokumentenvorverarbeitung, KI-gestützte Extraktion, die über Dokumentenlayouts hinweg funktioniert, ohne dass eine Vorlagenkonfiguration pro Lieferant 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.

Manche Tools — darunter ImageToTable.ai — gehen mit Funktionen noch weiter, die bei einer Eigenentwicklung jeweils eigenständige Entwicklungsprojekte wären. Benutzerdefinierte Spaltenextraktion: Sie geben die gewünschten Feldnamen ein (z. B. „Rechnungsnummer, Lieferant, Gesamtbetrag, Fälligkeitsdatum“) und die KI findet jeden Wert an beliebiger Stelle auf der Seite, indem sie dessen Bedeutung versteht, nicht seine Position. Bei einer Eigenentwicklung ist diese semantische Extraktionslogik die zentrale technische Herausforderung — das, woran man wochenlang mit Prompt-Engineering feilt. Hier ist sie ein Texteingabefeld. Sammlungslink: eine teilbare URL, über die Kunden, Außendienstmitarbeiter oder Lieferanten Dokumente direkt in Ihre Verarbeitungswarteschlange hochladen können, ohne ein Konto anzulegen. Wenn Sie das selbst bauen, entwickeln Sie einen Multi-Mandanten-Dateiupload-Dienst mit Authentifizierung — ein weiteres Engineering-Projekt. Das 6-dimensionale Bewertungsframework zeigt, wie sich diese Funktionen toolsübergreifend schlagen, aber das Muster bleibt: Die Features, die auf einer Funktionsliste klein klingen, sind volle Engineering-Aufwände, wenn man sie selbst umsetzt.

Der stille Vorteil von SaaS ist, dass Modellverbesserungen ohne Ihr Zutun geschehen. Wenn das zugrundeliegende Bildverarbeitungsmodell besser wird — und diese Modelle verbessern sich rasant — aktualisiert ein SaaS-Anbieter das Backend, und jeder Kunde profitiert. Ihre Eigenentwicklung, die an eine Modellversion von vor 12–18 Monaten gebunden ist, hinkt hinterher, ohne einen bewussten Engineering-Aufwand für Upgrade, Regressionstests und erneute Bereitstellung.

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)“ lautet. Die Zeit von Entwicklern, die bereits auf der Gehaltsliste stehen, ist nicht kostenlos – sie wird von allem anderen abgezogen. Der wirkliche Vergleich lautet: „19 $/Monat vs. 60.000 $+ an umgeleiteten Entwicklungskapazitäten plus laufende Wartung für immer.“ Eine Analyse von Abonnement vs. nutzungsbasierter Bezahlung fügt der Build-vs.-Buy-Frage eine weitere Nuance hinzu – die beiden Entscheidungen interagieren, sind aber nicht identisch.

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-AIA-G702-Zahlungsanträge, brasilianische XML-basierte Nota-Fiscal-Rechnungen oder japanische qualifizierte Rechnungen mit strengen regulatorischen Feldern verarbeiten – Dokumenttypen, für die Standard-SaaS-Tools nicht entwickelt wurden – kann Ihnen Eigenentwicklung eine Extraktionsqualität bieten, die kein generisches Tool erreicht. Das Schlüsselwort ist „wirklich“. Die meisten Teams überschätzen, wie einzigartig ihre Dokumente sind. Ein Kaufauftrag ist ein Kaufauftrag, unabhängig von Ihrer Branche. Bevor Sie sich für Eigenentwicklung entscheiden, testen Sie, ob ein SaaS-Tool Ihre Felder aus einer Beispielcharge extrahieren kann. Wenn ja, ist das Einzigartigkeitsargument hinfällig.

Datenschutz erfordert luftgekapselte Verarbeitung. Wenn Ihre Dokumente Informationen enthalten, die Ihr Unternehmen rechtlich nicht verlassen dürfen – etwa Geheimdokumente, sensible Patientenakten mit strengen Datenresidenzregeln oder Finanzdaten, deren interne Compliance-Richtlinien eine Verarbeitung durch Dritte verbieten –, bleibt Ihnen unter Umständen keine Wahl, als selbst zu entwickeln. Prüfen Sie aber auch hier, ob SaaS-Anbieter eine lokale oder VPC-Bereitstellung anbieten, bevor Sie die Eigenentwicklung als einzigen Weg annehmen.

Dokumentenextraktion ist Ihr Produkt, kein Kostenfaktor. Wenn das Kernangebot Ihres Startups eine KI-gestützte Dokumentenanalyseplattform ist, müssen Sie die Extraktionsebene selbst kontrollieren. Der Zukauf von einem Anbieter macht Ihre Kernkompetenz von dessen Roadmap und Preisen abhängig. Das ist das stärkste Argument für Eigenentwicklung – wenn die Extraktion das Unterscheidungsmerkmal ist, nicht der operative Overhead.

Das Volumen ist hoch genug, dass API-Kosten ins Gewicht fallen. Ab 500.000+ Seiten pro Monat summieren sich die Seitenkosten von Google Document AI (0,03 $) auf 15.000 $/Monat allein für die API. In dieser Größenordnung kann sich die Investition in eine eigene Extraktionspipeline mit niedrigeren Stückkosten innerhalb eines Jahres amortisieren. Der Break-even-Punkt hängt jedoch von Ihrem tatsächlichen Volumen ab – rechnen Sie ihn aus, gehen Sie nicht von ihm aus.

Eine nützliche Faustregel: Wenn Ihr Team bereits produktive ML-Pipelines entwickelt und betrieben hat, wissen Sie, worauf Sie sich einlassen. Wenn dies das erste ML-Infrastrukturprojekt Ihres Unternehmens wäre, übersteigen die Kosten der Lernkurve allein oft das erste Jahr des SaaS-Abonnements.

Der hybride Ansatz: Kern zukaufen, drumherum entwickeln

Die Frage „Eigenentwicklung oder 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 am schwierigsten zu bauende Teil und der, bei dem die SaaS-Ökonomie am stärksten überzeugt. 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 automatisieren wird – gleiche Extraktionsebene, unterschiedliche Interaktionsebenen. Die Entscheidung zwischen API und No-Code ist kein Entweder-Oder, wenn die zugrundeliegende Extraktions-Engine beides unterstützt – sie ist ein Migrationspfad von der schnellsten Lösung, die heute funktioniert, zur skalierbarsten für morgen.

Die Frage „Eigenentwicklung oder Kauf“ führt nach einer Kostenanalyse meist zu drei praktischen Antworten: Kaufen, wenn Ihre Dokumente Standard sind und Ihr Volumen kein dediziertes Entwicklungsteam rechtfertigt; Eigenentwicklung, 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, Dokumentenextraktion selbst zu entwickeln?

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 Entwicklungskosten im ersten Jahr für einen Entwickler bzw. 120.000–190.000 € für ein Zweier-Team. Das deckt den Bau ab. Die laufende Wartung (Formatänderungen, Modell-Updates, Prompt-Engineering, Compliance-Dokumentation) schlägt jährlich mit 20–30 % der anfänglichen Baukosten zu Buche. Eine vollständige Preisanalyse setzt die SaaS-Alternative ins Verhältnis – die meisten Tools kosten zwischen 19 € und 500 € 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 Produktivbetrieb mit 2.000 Dokumenten pro Monat von 50 verschiedenen Lieferanten – nein. Die GPT-4o-API bietet eine reine Extraktionsfähigkeit. Sie bietet keine Dokumentenklassifizierung, Formatnormalisierung, Fehlerbehandlung, konfidenzbasierte Weiterleitung, Prüf-Warteschlange, Ausgabeformatierung, Stapelverarbeitung, Excel-Export oder Überwachung. Jeder dieser Punkte ist eine Entwicklungsaufgabe. 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 signifikant – GPT-4o Vision in hoher Auflösung kostet 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 eine Eigenentwicklung machen?

Die Entwicklungskosten als „ein Entwickler für zwei Monate“ zu veranschlagen und dabei stehenzubleiben. Die Entwicklung ist der kleinere Teil der Gesamtkosten. Der größere Teil – der laufende Betrieb – beginnt am Tag der Auslieferung und endet nie: Formatänderungen von Geschäftspartnern, Modell-Updates von API-Anbietern, Prompt-Engineering für neue Dokumenttypen, Regressionstests der Genauigkeit und die menschliche Prüf-Warteschlange, die mit dem Volumen wächst. Die meisten Eigenentwicklungen fallen am Ende 30–50 % teurer aus als die ursprüngliche Schätzung, weil der Umfang während der Entwicklung wächst und die jährliche Wartungslast – 20–30 % der Entwicklungskosten pro Jahr – selten im ursprünglichen Budget enthalten ist.

Ab welchem Dokumentvolumen ist Eigenentwicklung günstiger als Zukauf?

Bei Standard-Dokumenttypen (Rechnungen, Quittungen, Bestellungen) ist der Kauf bei nahezu jedem Volumen bis zu Hunderttausenden von Seiten pro Monat günstiger – die SaaS-Abonnementkosten (19–500 $/Monat) liegen um Größenordnungen unter den Vollkosten selbst eines Teilzeit-Entwicklers (2.750+ $/Woche). Bei extrem hohen Volumen (500.000+ Seiten/Monat) können die API-Kosten pro Seite einer Eigenentwicklung zwar an den SaaS-Preis heranreichen, der Wartungsaufwand bleibt jedoch bestehen. Die Break-Even-Berechnung 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 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 jedoch keine komplexen Layouts, Tabellen, Handschriften oder semantisches Verständnis – es liefert Rohtext, keine strukturierten Daten. Der Aufbau der strukturierten Extraktionsebene auf Tesseract erfordert die gleiche Prompt-Entwicklung, Klassifizierung, Validierung und Ausgabe-Routing wie oben beschrieben, plus zusätzliche Entwicklungsarbeit für Fälle, in denen Tesseracts OCR-Qualität nicht ausreicht (niedrig aufgelöste Scans, nicht-lateinische Schriften, Dokumente mit gemischten Inhalten). Kostenlose OCR spart die API-Kosten pro Seite, aber nicht die Entwicklungszeit – und die Entwicklungszeit ist der dominierende Kostenfaktor bei jeder Eigenentwicklung.

Wie lange dauert der Aufbau einer produktionsreifen Dokumentenextraktions-Pipeline?

Ein funktionaler Proof of Concept – ein Dokumententyp, bekannte Formate, keine Prüfungswarteschlange – ist in 2–3 Wochen umsetzbar. Eine produktionsreife Pipeline für mehrere Dokumententypen mit Klassifikation, Fehlerbehandlung, Validierungs-UI, Monitoring und CI/CD benötigt für einen Entwickler 20–31 Wochen, 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 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 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.