Ein Muster, das sich wiederholt
Kaum ein Softwareanbieter beginnt mit der Entscheidung, keine eigene Belegerkennung zu bauen. Fast immer beginnt es umgekehrt: ein Entwickler bindet in wenigen Tagen einen allgemeinen OCR-Dienst an, ein erster Kunde ist begeistert, und niemand im Team stellt zu diesem Zeitpunkt die Frage, wie sich das Projekt verhält, sobald der zehnte, der hundertste und der tausendste unterschiedliche Lieferant Rechnungen in das System schickt. Genau an diesem blinden Fleck setzt dieser Text an.
Was folgt, ist selten ein einzelner Rückschlag, sondern eine Serie kleiner, jeweils für sich genommen plausibler Entscheidungen, die sich am Ende zu einem Projekt summieren, das mehr Wartung als Entwicklung ist. Dieser Text beschreibt diesen Verlauf so konkret wie möglich — nicht als Behauptung, sondern anhand der drei Stellen, an denen dieses Muster tatsächlich bricht.
Dieses Muster ist auch nicht spezifisch für Deutschland oder für Buchhaltungssoftware — es taucht überall dort auf, wo ein Team ein allgemeines KI-Werkzeug für eine spezifische, belegreiche Aufgabe einsetzt und dabei die Wartungslast unterschätzt, die mit echter Layoutvielfalt einhergeht. Der deutsche Markt fügt diesem allgemeinen Muster lediglich einen zusätzlichen, sehr spezifischen vierten Schritt hinzu: das DATEV-Format als Zielpunkt der gesamten Kette, auf das dieser Text später gesondert eingeht.
Wie das Projekt beginnt
Der Startpunkt ist fast immer derselbe: ein allgemeiner Dokument-KI-Dienst wie Amazon Textract oder Google Document AI liest ein PDF und liefert Text mit Koordinaten zurück. Für eine einfache Rechnung mit wenigen Feldern lässt sich daraus in kurzer Zeit ein Prototyp bauen, der "funktioniert" — Lieferantenname und Rechnungsbetrag lassen sich mit ein paar Positionsregeln zuverlässig herausfischen, solange das Layout einfach genug ist.
An diesem Punkt entsteht ein Missverständnis, das das gesamte weitere Projekt prägt: der Prototyp wird für die eigentliche Lösung gehalten, obwohl er erst den einfachsten Teil des Problems gelöst hat. Kopfdaten sind der leichte Teil einer Rechnung — die eigentliche Substanz liegt in der Positionstabelle, und die kommt im Prototyp meist noch gar nicht vor.
Die erste Wand: die Positionstabelle
Sobald echte Kundenrechnungen mit mehrseitigen Positionstabellen ins System kommen, zeigt sich das erste ernsthafte Problem. Eine Position kann über zwei Zeilen umgebrochen sein, eine Zwischensumme kann mitten in der Tabelle stehen, und bei einer mehrseitigen Rechnung wiederholt die zweite Seite die Spaltenüberschriften oft nicht. Eine einfache, regelbasierte Zuordnung — "die dritte Spalte ist immer der Preis" — bricht an genau diesen Stellen, und zwar nicht selten, sondern bei einem relevanten Anteil aller echten Belege.
Die Reaktion an diesem Punkt ist fast immer dieselbe: mehr Regeln, mehr Sonderfälle, mehr Bedingungen im Code. Jede neue Regel behebt den einen Fall, der gerade aufgefallen ist, und erhöht gleichzeitig die Wahrscheinlichkeit, dass der nächste Sonderfall eine bereits bestehende Regel bricht. Das ist der Moment, in dem aus "wir haben OCR eingebaut" leise "wir pflegen einen Rechnungsparser" wird — eine deutlich größere, dauerhafte Aufgabe.
Ein Zeitmuster, das sich in vielen dieser Projekte wiederholt: Die erste Wand wird typischerweise im zweiten oder dritten Monat nach dem ersten Prototyp erreicht — genau dann, wenn ein Team von den anfänglich getesteten, sauberen Beispieldokumenten zu echten, vielfältigeren Kundenbelegen übergeht. Bis dahin wirkte das Projekt abgeschlossen; ab diesem Punkt beginnt die eigentliche, dauerhafte Arbeit erst.
Die zweite Wand: neue Lieferantenlayouts
Selbst ein Team, das die erste Wand mit viel Aufwand überwindet, trifft zuverlässig auf die zweite: Ein regelbasierter oder vorlagengetriebener Parser, der beim Launch für die vorhandenen Kunden funktioniert, verschlechtert sich mit jedem neuen Kunden, dessen Lieferanten Rechnungen in einem bis dahin unbekannten Layout senden. Anders als bei einem klassischen Softwarefehler ist das kein einmaliges Problem, das man behebt und abhakt — es ist ein laufender Strom neuer Fälle, der mit dem Wachstum des eigenen Kundenstamms mitwächst.
An dieser Stelle beginnt sich die Kostenstruktur des Projekts spürbar zu verschieben: Statt geplanter Feature-Entwicklung übernimmt das Team zunehmend reaktive Pflege — ein neues Layout taucht auf, ein Support-Ticket landet beim Engineering, ein Entwickler unterbricht die aktuelle Arbeit, um die Regel anzupassen. Multipliziert über viele Kunden und viele Lieferanten wird daraus eine der teuersten, am wenigsten sichtbaren Zeilen im Entwicklungsbudget.
Die dritte Wand: Konfidenz ohne Kalibrierung
Die dritte Wand ist die am wenigsten offensichtliche, aber langfristig teuerste: Ohne einen verlässlich kalibrierten Konfidenzwert je Feld bleibt einem Team nur die Wahl zwischen zwei schlechten Optionen. Entweder wird jeder gelesene Beleg manuell geprüft — was den eigentlichen Effizienzgewinn der Automatisierung wieder auffrisst —, oder es wird jedem gelesenen Wert blind vertraut, mit dem Risiko, dass falsche Beträge unbemerkt in die Buchhaltung eines Kunden gelangen.
Eine gut kalibrierte Konfidenzschicht selbst zu bauen — eine, die tatsächlich vorhersagt, wann ein Wert wahrscheinlich falsch ist, statt einfach eine willkürliche Zahl auszugeben — ist ein eigenständiges, datenintensives Projekt, das die meisten Teams beim ursprünglichen Umfang des Vorhabens nicht eingeplant hatten.
Ein Detail macht diese dritte Wand besonders tückisch: Sie äußert sich selten als offener Fehler, den ein Test aufdecken würde. Ein falsch kalibrierter Konfidenzwert liefert weiterhin eine Zahl zwischen null und eins zurück — sie ist nur falsch, ohne dass irgendetwas im System das von selbst bemerkt. Anders als ein Absturz oder eine Fehlermeldung bleibt eine schlecht kalibrierte Konfidenz oft monatelang unentdeckt, bis jemand die tatsächlichen Fehlerquoten manuell mit den gemeldeten Konfidenzwerten vergleicht — eine Analyse, die in der Hektik des Tagesgeschäfts selten von allein passiert.
Was diese drei Wände gemeinsam haben
Auf den ersten Blick wirken die Positionstabelle, neue Lieferantenlayouts und unkalibrierte Konfidenzwerte wie drei unabhängige technische Probleme. Bei genauerem Hinsehen teilen sie ein gemeinsames Muster: Jede der drei Wände lässt sich mit genug Aufwand lokal lösen, aber keine davon bleibt gelöst, ohne fortlaufend neue Arbeit zu verursachen. Eine Positionstabellen-Regel, die heute funktioniert, kann morgen an einem neuen Layout scheitern. Ein Konfidenzwert, der heute gut kalibriert ist, driftet, sobald sich die Zusammensetzung der verarbeiteten Belege verschiebt. Das unterscheidet dieses Problem von den meisten anderen Softwareprojekten: Es gibt selten einen Zustand, den man einmal erreicht und dann als "fertig" markieren kann.
Genau dieser fortlaufende, nie ganz abgeschlossene Charakter ist der eigentliche Grund, warum sich eine spezialisierte API hier anders rechnet als bei den meisten anderen Build-vs-Buy- Entscheidungen: Man kauft nicht nur eine fertige Lösung für einen einmaligen Aufwand ein, sondern gibt eine Aufgabe ab, die sonst dauerhaft, Monat für Monat, weiterlaufen würde.
Ein Vergleich, der diesen Unterschied greifbar macht: Eine einmalige Migration eines Datenbankschemas ist nach dem Abschluss tatsächlich fertig. Eine Belegerkennung ist es nie ganz — sie steht in einem stillen, fortlaufenden Wettlauf gegen die Kreativität der Welt, in der Rechnungen ausgestellt werden, und dieser Wettlauf endet nicht, solange das Produkt neue Kunden gewinnt.
Was das Projekt tatsächlich kostet
Die sichtbaren Kosten eines eigenen OCR-Projekts sind die Entwicklerstunden für den ersten Prototyp. Die tatsächlichen Kosten liegen fast immer woanders: in der laufenden Pflege gegen neue Layouts, in der Zeit, die ein Support-Team mit der Diagnose falsch gelesener Werte verbringt, und in der Opportunitätskosten dessen, was das Engineering-Team stattdessen hätte bauen können, wenn es nicht regelmäßig für Parser-Regressionen unterbrochen worden wäre. Diese Kosten erscheinen selten als eine einzelne Budgetzeile — sie verteilen sich über viele kleine Unterbrechungen, was sie leicht zu unterschätzen, aber in der Summe teuer macht.
Eine zweite, weniger offensichtliche Kostenart betrifft das Vertrauen der eigenen Nutzer. Ein Kunde, der einmal einen falsch gebuchten Betrag entdeckt, prüft danach jede weitere automatisch übernommene Position gründlicher — selbst wenn die Erkennung inzwischen zuverlässiger geworden ist. Dieses verlorene Vertrauen lässt sich schwerer beziffern als Entwicklerstunden, wirkt sich aber direkt auf die eigentliche Automatisierungsersparnis aus, für die das Feature ursprünglich gebaut wurde.
Eine dritte, oft übersehene Kostenart ist die Zeit, die im Verkaufsprozess verloren geht: Ein interessierter Kunde, der die Belegerkennung mit einem eigenen, schwierigen Beleg testet und ein falsches Ergebnis sieht, testet selten ein zweites Mal — der Vertrauensverlust entsteht dort, wo er am teuersten ist, nämlich bevor der Kunde überhaupt zahlt.
Eigenbau gegen API im Zahlenvergleich
Zahlen aus einem einzelnen Projekt lassen sich schwer verallgemeinern, aber die Größenordnung wiederholt sich über viele Teams hinweg erstaunlich konsistent: Der erste Prototyp wirkt fast immer günstiger als er tatsächlich ist, weil er die laufende Pflege noch nicht einpreist — und genau diese Pflege ist der Posten, der beim Eigenbau am Ende dominiert, nicht die Erstentwicklung.
| Kostenpunkt | Eigene OCR-Pipeline | Spezialisierte API |
|---|---|---|
| Erste funktionierende Version | Ein bis zwei Quartale | Ein bis zwei Tage bis zum ersten Aufruf |
| Laufende Pflege bei neuen Layouts | Wiederkehrender Entwicklereinsatz | Im Preis pro Seite enthalten |
| Konfidenzkalibrierung | Eigenes, datenintensives Projekt | Bereits Teil jeder Antwort |
| Kostenstruktur | Fixkosten plus schwankende Entwicklerzeit | Fester Preis pro tatsächlich gelesener Seite |
| Skalierung auf neue Kunden | Jeder neue Kunde erhöht das Pflegerisiko | Kein zusätzliches Risiko je Kunde |
Der Punkt, an dem ein Team aufgibt
Der Moment, an dem ein Team die eigene Erkennung tatsächlich aufgibt, ist fast nie der Start des Projekts und selten ein einzelner katastrophaler Vorfall. Es ist meist ein leiserer Moment: ein Blick auf den Entwicklerkalender zeigt, dass ein wachsender Anteil der Sprintkapazität in Parser-Regressionen fließt statt in neue Funktionen, und jemand im Team stellt zum ersten Mal laut die Frage, ob das wirklich die beste Verwendung dieser Zeit ist. Ab diesem Punkt wird die Frage "selbst bauen oder eine API einbinden" noch einmal neu gestellt — diesmal mit echten Kosten- und Aufwandsdaten aus dem eigenen Projekt statt mit einer Vermutung vom Anfang.
Das auslösende Signal ist selten die Fehlerquote selbst, sondern ihre Richtung: eine Erkennung, die mit jedem neuen Kunden zuverlässiger würde, wäre kein Problem. Eine, die mit jedem neuen Kunden mehr Pflege braucht, ist ein strukturelles.
Fünf Fragen, um den eigenen Stand ehrlich einzuschätzen
Bevor die Frage "selbst bauen oder wechseln" noch einmal gestellt wird, hilft ein kurzer, ehrlicher Selbsttest — nicht als Verkaufsargument, sondern als Bestandsaufnahme, die sich mit den tatsächlichen Zahlen aus dem eigenen Projekt beantworten lässt:
Wie viel Entwicklerzeit floss in den letzten drei Monaten in Layout-Anpassungen?
Eine grobe Zahl reicht — wichtig ist die Richtung, nicht die Genauigkeit. Ein spürbarer Anstieg gegenüber dem Vorquartal ist das eigentliche Signal.
Wie viele Support-Tickets zu falsch gelesenen Werten kamen in dieser Zeit an?
Ein Ticket ist ein sichtbares Symptom für einen unsichtbaren Konfidenzfehler — die Zahl der Tickets ist meist nur ein Bruchteil der tatsächlich betroffenen Belege.
Wächst der Kundenstamm schneller als die Pflege der Erkennung mithalten kann?
Wenn jeder zehnte neue Kunde ein neues Lieferantenlayout mitbringt, wächst der Pflegeaufwand proportional zum Wachstum selbst — ein strukturelles, kein vorübergehendes Problem.
Existiert im Team eine verlässliche Kalibrierung für Konfidenzwerte?
Ein Team ohne klare Antwort auf diese Frage vertraut vermutlich entweder blind oder prüft zu viel manuell — beide Zustände kosten in der Praxis mehr, als sie zeigen.
Wie viel Zeit ginge für eine eigene DATEV-EXTF-Implementierung drauf, wenn sie heute begonnen würde?
Eine ehrliche Schätzung dieser einen Zahl reicht oft schon aus, um die Gesamtrechnung neu zu bewerten.
Wann Eigenbau trotzdem sinnvoll bleibt
Nicht jedes Projekt endet an diesen drei Wänden. Ein Anbieter mit einem sehr engen, stark standardisierten Kundenkreis — etwa nur einer Handvoll immer gleicher Belegtypen von immer denselben wenigen Lieferanten — kann eine eigene, spezialisierte Erkennung erfolgreich bauen und betreiben, gerade weil die Layoutvielfalt künstlich klein bleibt. Ebenso kann ein Team mit echter, tiefer OCR- und Machine-Learning-Erfahrung im Haus die drei Wände schneller überwinden als ein Team, das OCR zum ersten Mal angeht. Die ehrliche Frage ist nicht "kann man das selbst bauen", sondern "lohnt sich das für unseren konkreten Kundenkreis und unser konkretes Team".
Es gibt noch einen dritten, selteneren Grund, der für Eigenbau sprechen kann: ein Anbieter, für den Belegerkennung selbst das eigentliche Kernprodukt ist, nicht nur eine Zulieferfunktion für ein größeres Buchhaltungsprodukt. In diesem Fall ist die Erkennung nicht der vorgelagerte Schritt vor der eigentlichen Wertschöpfung, sondern die Wertschöpfung selbst — und die Kalkulation, die für jeden anderen Anbieter gegen Eigenbau spricht, dreht sich hier um.
Fünf frühe Anzeichen, dass die eigene Erkennung an eine Wand läuft
Keines dieser fünf Anzeichen ist für sich genommen ein Beweis. Zusammen ergeben sie aber ein Bild, das sich schwer ignorieren lässt, sobald man einmal bewusst danach sucht — die meisten Teams bemerken erst im Rückblick, wie lange sich diese Signale bereits gehäuft hatten, bevor jemand die eigentliche Frage laut gestellt hat.
Support-Anfragen zu falschen Werten häufen sich bei bestimmten Lieferanten
Ein wiederkehrendes Muster bei denselben wenigen Ausstellern ist ein deutlicheres Signal als vereinzelte Einzelfälle über den ganzen Kundenstamm verteilt.
Ein Entwickler wird informell zum "OCR-Experten" des Teams
Sobald eine einzelne Person regelmäßig für Erkennungsprobleme herangezogen wird, ist die Pflege bereits ein faktisches, wenn auch inoffizielles Zuständigkeitsgebiet geworden.
Neue Kunden-Onboardings dauern länger als geplant
Wenn ein neuer Kunde regelmäßig eine Anpassung der Erkennung braucht, bevor er produktiv gehen kann, wächst der Pflegeaufwand direkt mit dem Vertriebserfolg mit.
Sprint-Planungen enthalten wiederkehrend "OCR-Fixes" als eigenen Posten
Ein Posten, der Sprint für Sprint auftaucht, ohne je vollständig abgeschlossen zu sein, ist meist kein einzelnes Problem mehr, sondern eine dauerhafte Aufgabe geworden.
Die Genauigkeit schwankt sichtbar mit dem Kundenmix des jeweiligen Monats
Eine Erkennung, deren gemessene Qualität davon abhängt, welche Kunden gerade aktiv sind, zeigt damit indirekt, dass sie nicht robust über die volle Layoutvielfalt hinweg funktioniert.
Wie ein Wechsel im Team wahrgenommen wird
Ein Aspekt, der in rein technischen Abwägungen oft fehlt: Ein Entwicklerteam, das über Monate an der eigenen Erkennung gearbeitet hat, empfindet den Vorschlag, sie durch eine externe API zu ersetzen, selten neutral. Es steckt reale Arbeit und reales Fachwissen in der bestehenden Lösung, und ein Wechsel kann sich zunächst wie eine Abwertung dieser Arbeit anfühlen, auch wenn er rein wirtschaftlich der richtige Schritt ist.
In der Praxis hilft es, den Wechsel nicht als "unsere Lösung war schlecht" zu rahmen, sondern als das, was er meist tatsächlich ist: eine Verschiebung der Teamkapazität von einer Aufgabe, die inzwischen ein spezialisierter Anbieter besser löst, hin zu den Funktionen, die das eigene Produkt tatsächlich unterscheidbar machen. Die investierte Erfahrung — welche Randfälle es gibt, welche Kunden welche Anforderungen haben — bleibt dabei erhalten und fließt direkt in die Konfiguration der neuen Integration ein, statt verloren zu gehen.
Der deutsche Sonderfall: DATEV als Zielformat
Für einen deutschen Anbieter kommt zu den drei allgemeinen Wänden noch eine vierte, sehr spezifische hinzu: das DATEV-Format selbst. Ein Buchungsstapel im EXTF-Format folgt eigenen Regeln — Beträge stehen mit deutschem Dezimalkomma und sind immer positiv, das Vorzeichen trägt das Soll/Haben-Kennzeichen, das Belegdatum steht im Format TTMM, und Kontonummern folgen SKR03- oder SKR04-Konventionen. Diese Regeln selbst zu implementieren und gegen echte DATEV-Importe zu testen, ist eine eigene, oft unterschätzte Teilaufgabe innerhalb eines ohnehin schon aufwendigen Projekts.
Ein spezialisierter Anbieter, für den DATEV-Export eine Kernfunktion und nicht ein Nebenprojekt ist, hat diese Regeln bereits gegen reale Importe getestet — für ein Team, das ohnehin schon an den drei allgemeinen Wänden arbeitet, ist das ein zusätzlicher, guter Grund, diesen einen Teil nicht auch noch selbst zu bauen.
Hinzu kommt ein Detail, das erst beim ersten echten DATEV-Import auffällt: Unterschiedliche Mandanten buchen häufig nach unterschiedlichen Kontenrahmen — SKR03 oder SKR04 — mit unterschiedlichen Standardkonten. Eine Eigenentwicklung, die zunächst nur für den eigenen, homogenen Kundenstamm gebaut wurde, muss diese Vielfalt oft nachträglich einbauen, sobald der Kundenstamm wächst — ein weiterer Fall, in dem ein anfangs kleines Projekt im Nachhinein größer wird, als ursprünglich veranschlagt.
Ein typischer Fall, zusammengefasst
Ein Anbieter für Kanzleisoftware beginnt mit einem allgemeinen OCR-Dienst und einer einfachen Feldzuordnung für Kopfdaten. Innerhalb weniger Monate wächst der Kundenstamm, und mit ihm die Vielfalt der Lieferantenlayouts, die verarbeitet werden müssen. Ein Entwickler verbringt zunehmend Zeit mit Sonderfällen in der Positionstabelle; nach einem weiteren Quartal übernimmt ein zweiter Entwickler Teilzeit die laufende Pflege. Als die Frage aufkommt, wofür dieses zweite Entwicklerpaar eigentlich eingestellt wurde, stellt sich heraus: für ein Feature, das längst als "fertig" galt. Der Wechsel auf eine spezialisierte API dauert danach wenige Tage — die eigentliche Erkenntnis war nicht technisch, sondern die ehrliche Zahl hinter der bisherigen "fertigen" Lösung.
Bemerkenswert an diesem Verlauf ist, was NICHT passiert: Es gibt keinen einzelnen Moment, an dem jemand bewusst entschieden hätte, ein zweijähriges Wartungsprojekt zu starten. Jede einzelne Entscheidung unterwegs — eine weitere Sonderregel, eine weitere Teilzeitkraft — war für sich genommen vernünftig. Erst die Summe macht das Muster sichtbar, und meist erst, wenn jemand außerhalb des Teams, etwa in einem Budgetgespräch, die naheliegende Frage stellt: Was genau bekommen wir eigentlich für diese Entwicklerzeit, verglichen mit dem, was eine fertige Lösung dafür kostet.
Häufige Missverständnisse über den Wechsel
"Ein Wechsel bedeutet, alles noch einmal zu bauen"
In der Praxis bleibt die Oberfläche für Freigabe, Kontierung und Prüfung meist unverändert — ausgetauscht wird nur die Erkennungsschicht darunter.
"Eine API ist eine Blackbox ohne Kontrolle"
Konfidenzwerte je Feld geben dieselbe, wenn nicht mehr Kontrolle über die Schwelle zwischen Automatisierung und manueller Prüfung wie eine selbst kalibrierte Lösung.
"Der eigene Code war doch nicht umsonst"
Die investierte Zeit in Freigabe-Workflows, Kontierungslogik und die eigene Oberfläche bleibt vollständig erhalten — nur die Erkennung selbst wird ersetzt.
"Das lohnt sich erst bei sehr hohem Volumen"
Der Pflegeaufwand einer eigenen Lösung skaliert eher mit der Layoutvielfalt der Lieferanten als mit dem reinen Belegvolumen — auch ein moderat großer, aber vielfältiger Kundenstamm erreicht die drei Wände.
"Ein Wechsel muss auf einmal für alle Kunden passieren"
Ein Parallelbetrieb mit einer kleinen Teilmenge der Kunden liefert echte Vergleichsdaten, bevor irgendetwas vollständig umgestellt wird — der Umstieg selbst lässt sich beliebig kleinschrittig gestalten.
Wie ein Wechsel praktisch abläuft
Der übliche Weg beginnt klein: ein kostenloser Plan und eine Handvoll echter, bereits bekannter Problemfälle aus dem eigenen Kundenbestand — genau die Belege, an denen die eigene Lösung bisher gescheitert ist. Zeigt die neue Erkennung an diesen konkreten Fällen einen echten Unterschied, ist das ein deutlich überzeugenderes Signal als jede allgemeine Genauigkeitsangabe. Der eigentliche Umbau — Mapping der Antwortstruktur, Anpassung der Schwellenwert-Logik, Anbindung an den bestehenden Export — lässt sich danach parallel zur laufenden alten Lösung vorbereiten, statt in einem riskanten großen Schnitt.
Details zum konkreten Integrationsweg beschreibt die Anleitung Dokumentenerkennung in die eigene Software integrieren.
Details zur konkreten API-Funktion beschreibt die Seite Belegerkennung für Entwickler.
Was ein Team stattdessen bauen könnte
Der am schwersten zu beziffernde, aber vermutlich größte Effekt eines Wechsels ist selten Teil der ursprünglichen Kalkulation: Was hätte das Team stattdessen gebaut, wenn die Erkennung nicht laufend Aufmerksamkeit gebunden hätte? Bei den meisten Anbietern lautet die ehrliche Antwort: genau die Funktionen, die im eigenen Produkt-Backlog seit Monaten unbearbeitet liegen, weil immer wieder etwas Dringenderes dazwischenkam. Ein neues Reporting-Modul, eine überfällige Überarbeitung der Freigabeoberfläche, eine Integration, die Kunden seit Längerem nachfragen — all das konkurriert direkt mit der Zeit, die stattdessen in Parser-Pflege fließt.
Diese Opportunitätskosten sind der eigentliche Grund, warum die Entscheidung selten rein technisch getroffen wird. Sie ist am Ende eine Priorisierungsfrage: Soll das Entwicklerteam seine Zeit in eine Funktion investieren, die ein spezialisierter Anbieter bereits besser und günstiger anbietet, oder in das, was das eigene Produkt tatsächlich von der Konkurrenz unterscheidet?
Diese Frage lässt sich nicht abstrakt beantworten, aber sie lässt sich konkret stellen — und genau das ist oft der erste Schritt, der ein festgefahrenes eigenes OCR-Projekt tatsächlich in Bewegung bringt.