Talonic vs. Reducto: Ein Vergleich der Schema-First-Dokumentenextraktion

Reducto ist als Parsing-API aufgebaut. Dokumente gehen hinein, strukturierter Text kommt heraus. Die Architektur ist auf Geschwindigkeit und Genauigkeit im Extraktionsschritt optimiert und wandelt visuelle Layouts in maschinenlesbare Ausgaben um. Das ist wertvolle Arbeit, und Reducto leistet sie gut. Mit $108M an Finanzierung hat das Unternehmen stark in die Parsing-Qualität über ein breites Spektrum an Dokumenttypen hinweg investiert.

Talonic ist als vierphasige Pipeline aufgebaut: Capture, Extract, Match, Deliver. Parsing ist Phase eins. Die Architektur geht davon aus, dass die Extraktion allein nicht der Engpass ist, der Engpass liegt in dem, was nach der Extraktion geschieht. Dokumente müssen gegen Schemas validiert, zu Fällen zusammengestellt, über Entitäten hinweg abgeglichen und als typisierte Datensätze an die maßgeblichen Unternehmenssysteme geliefert werden. Die Schema-Ebene liegt zwischen unstrukturierten Dokumenten und strukturierten Datenbanken und bildet den Kern des Produkts.

Dieser architektonische Unterschied bedeutet, dass Reducto und Talonic direkt nach dem Parsing-Schritt auseinandergehen. Reducto liefert geparste Ausgabe zurück. Talonic leitet die geparste Ausgabe durch Schemavalidierung, Fallauflösung, Entitätsabgleich und workflow-fertige Lieferung, bevor etwas das nachgelagerte System erreicht.

Talonic pflegt eine Dokumentontologie mit 529 Typen, eine hierarchische Klassifikation von Unternehmensdokumenttypen von Schedule K-1 bis Bill of Lading (Ocean), von notariellen Urkunden bis QC-Prüfberichten. Wenn ein Dokument in die Pipeline eintritt, wird es vor Beginn der Extraktion anhand dieser Ontologie klassifiziert. Die Ontologie bestimmt, welches Schema angewendet wird, welche Felder zu erwarten sind und welche Validierungsregeln durchgesetzt werden.

Reducto pflegt keine vergleichbare Dokumentontologie. Dokumente werden anhand ihres visuellen Layouts geparst, und der Aufrufer ist dafür verantwortlich zu wissen, welchen Dokumenttyp er übermittelt hat und welche Felder zu erwarten sind. Das funktioniert gut bei homogenen Dokumentmengen, bei denen der Aufrufer den Dokumenttyp bereits kennt. Es wird zur Einschränkung bei der Verarbeitung gemischter Dokumentportfolios, bei denen die Klassifikation selbst Teil des Problems ist.

Die Schema-Ebene ist der grundlegende Unterschied zwischen den beiden Produkten. In Talonic sind Schemas Entitäten erster Klasse mit Entwurf-/Veröffentlichungsversionierung, Routing-Regeln und Lifecycle-Management. Jedes extrahierte Feld wird gegen seine Schemadefinition validiert. Felder, die die Validierung nicht bestehen, werden je nach Schemakonfiguration markiert, zur Fallauflösung weitergeleitet oder abgelehnt.

Reducto unterstützt eine Extraktionskonfiguration, die vorgibt, was extrahiert werden soll, aber Schemavalidierung als Laufzeit-Primitiv, bei dem das System Feldtypen, Pflichtfelder, feldübergreifende Beschränkungen und Versionskompatibilität durchsetzt, ist nicht Teil der Kernarchitektur. Der Unterschied wirkt sich am stärksten aus, wenn die Extraktionsqualität hoch ist, das nachgelagerte System jedoch eine strikte Typkonformität erfordert, was in regulierten Unternehmensumgebungen typisch ist.

Unternehmens-Workflows arbeiten nicht mit einzelnen Dokumenten. Sie arbeiten mit Fällen, dem Bündel aus Dokumenten, Korrespondenz und Metadaten, das eine Geschäftseinheit beschreibt. Ein Lieferantenvertragsfall könnte den Rahmenvertrag, drei Nachträge, einen Preisplan, einen E-Mail-Thread und einen unterzeichneten Zusatz umfassen. Diese sechs Dokumente beschreiben eine Sache.

Talonic stellt Fälle automatisch zusammen, indem verwandte Dokumente über inferenzbasiertes Matching gruppiert werden. Die Fallauflösungs-Engine erkennt, welche Dokumente zusammengehören, löst Konflikte zwischen überlappenden Feldern auf und erzeugt einen einheitlichen Fall-Datensatz, der den aktuellen Zustand der Entität abbildet.

Reducto verarbeitet Dokumente einzeln. Es gibt keine Fallauflösungsebene. Muss ein Aufrufer verwandte Dokumente zu Fällen zusammenführen, muss diese Logik außerhalb von Reducto gebaut werden. Für Extraktionsaufgaben mit einzelnen Dokumenten ist das keine Einschränkung. Für Enterprise-Workflows, die eine Zusammenführung mehrerer Dokumente erfordern, ist es eine erhebliche Lücke.

Entity Matching verknüpft Datensätze über den gesamten Dokumentbestand hinweg. Ein Lieferant namens „GETEC GmbH“ in einem Vertrag, „GETEC Group“ in einem anderen und „Getec“ in einer E-Mail sind dieselbe Entität. Ein Frachtführer-Code „SCHN-4412“ in einer Ladungszuweisung entspricht einem Frachtführer-Datensatz im TMS. Entity Matching macht extrahierte Daten über den gesamten Korpus hinweg abfragbar.

Talonic führt Entity Matching nativ als Teil der Match-Phase durch. Entitäten werden über schema-bewusste Regeln, unscharfes Matching und kontextuelle Signale aus dem Dokumentgraphen abgeglichen. Reducto führt kein Entity Matching durch. Die geparste Ausgabe enthält den Text so, wie er im Quelldokument erscheint, ohne Abgleich mit anderen Datensätzen.

Provenienz auf Zellebene bedeutet, dass sich jeder extrahierte Wert in Talonic bis zu seinem Quelldokument, seiner Seite, Zeile und Begrenzungsregion zurückverfolgen lässt. Jede Zelle trägt einen Konfidenzwert, die Extraktionsphase, die sie erzeugt hat, und die Argumentationskette, die zu ihrer Klassifikation geführt hat. Das sind keine nachträglich angefügten Metadaten, sie entstehen während der Extraktion und bleiben über jede nachfolgende Phase hinweg erhalten.

Herkunftsnachweis ist für regulierte Branchen unverzichtbar. Fragt ein Prüfer „Woher stammt dieses Verlängerungsdatum?“, lautet die Antwort nicht „Die KI hat es extrahiert.“ Die Antwort ist ein nachvollziehbarer Pfad vom Zellwert bis zur konkreten Region der konkreten Seite des konkreten Dokuments, das ihn hervorgebracht hat, samt Konfidenz und Argumentationskette.

Reducto liefert Extraktionskoordinaten auf Chunk-Ebene, was für die visuelle Referenz nützlich ist. Es bietet keinen zellgenauen Herkunftsnachweis über eine mehrphasige Pipeline mit Konfidenzbewertung, Phasenzuordnung und Argumentationsketten.

Talonic ist DSGVO-konform, HIPAA-konform, an ISO 27001 und ISO 42001 ausgerichtet. Alle Daten werden auf Microsoft Azure in Germany West Central verarbeitet, mit Mistral Large als primärem LLM-Anbieter. Für Kunden mit Anforderung an EU-Datenresidenz verlassen die Daten die EU-Jurisdiktion nie. Talonic hat DIN SPEC 91491 mitverfasst, Europas ersten Standard für KI-taugliche Daten auf Schema-Ebene, gemeinsam mit Fraunhofer IIS, Humboldt-Innovation und GIIC.

Reducto ist ein Unternehmen mit Hauptsitz in den USA, dessen Standard-Tarif in US-AWS-Regionen verarbeitet wird. EU-Datenresidenz ist in den Tarifen Growth und Enterprise verfügbar, zusammen mit Optionen für VPC-Bereitstellung. Für Organisationen, die EU-Verarbeitung als Standard benötigen und nicht als Verhandlungssache einer höheren Tarifstufe, insbesondere in den Bereichen Energie, Pharma und Finanzdienstleistungen, ist dieser Unterschied bei den Standardeinstellungen der strukturelle Unterschied zwischen den beiden Produkten.

Reducto berechnet pro verarbeiteter Seite. Das ist ein klares, planbares Modell für Parsing-Workloads, bei denen das Eingabevolumen der primäre Kostentreiber ist. Es funktioniert gut, wenn jede Seite nutzbare Ausgabe erzeugt.

Talonic berechnet pro gelieferten, schema-validierten Datensatz. Die Kosten orientieren sich an Geschäftsergebnissen statt am reinen Dokumentvolumen. Ein 200-seitiger Vertrag, der einen validierten Datensatz erzeugt, wird als ein Datensatz berechnet, nicht als 200 Seiten. Für Unternehmen, die große Dokumente verarbeiten, die sich zu wenigen strukturierten Datensätzen verdichten, ist dieses Modell deutlich kosteneffizienter. Für hochvolumige Extraktionsaufgaben mit einzelnen Seiten kann seitenbasierte Preisgestaltung einfacher sein.

Reducto ist eine starke Wahl, wenn der primäre Bedarf hochwertige Textextraktion aus Dokumenten ist und die nachgelagerte Validierung, Fallzusammenstellung und Auslieferungslogik bereits existiert oder intern gebaut wird. Konkret:

• Der Engpass ist die Parsing-Qualität, nicht der Workflow nach der Extraktion
• Dokumente sind homogen (einheitlicher Typ, bekanntes Schema, konsistentes Layout)
• Die Organisation hat die technische Kapazität, Schema-Validierung, Fallauflösung und Auslieferungs-Pipelines auf Basis der geparsten Ausgabe selbst zu bauen
• US-gehostete Infrastruktur ist akzeptabel oder bevorzugt
• Preise pro Seite passen zum Workload (hohe Seitenzahl, jede Seite ist eigenständig wertvoll)
• Das Team möchte eine fokussierte Parsing-API, keine vollständige Pipeline-Plattform

Talonic ist die bessere Wahl, wenn das Ziel nicht nur die Extraktion ist, sondern die Lieferung schema-validierter, fallaufgelöster, entitätsabgeglichener Datensätze an Systems of Record. Konkret:

• Der Engpass besteht darin, dass geparste Daten das ERP-, TMS- oder Beschaffungssystem noch immer nicht erreichen
• Dokumente sind heterogen (gemischte Typen, mehrsprachig, mehrere Formate)
• Der Workflow erfordert eine dokumentübergreifende Fallauflösung, nicht nur die Extraktion einzelner Dokumente
• Entitätsabgleich über Datensätze hinweg ist erforderlich (Lieferanten, Frachtführer, Policen, Vertragspartner)
• Provenienz auf Zellenebene ist für Audit und Compliance erforderlich
• EU-Datensouveränität ist eine Anforderung (DSGVO, DIN SPEC 91491, in Deutschland gehostete Infrastruktur)
• Die Organisation benötigt eine Dokumentontologie mit 529 Typen für die automatische Dokumentklassifizierung
• Preise, die sich an Geschäftsergebnissen orientieren (pro geliefertem Datensatz), werden gegenüber Volumenpreisen pro Seite bevorzugt

Bridgeway (Logistik, USA): ein Portfolio-Unternehmen von Gemspring Capital, das Konnossemente, Frachtführerverträge und Ladungszuweisungen verarbeitet. Bridgeway führte einen Ground-Truth-Benchmark mit 930 Dokumenten über mehrere Extraktionsanbieter hinweg durch. Die Genauigkeit verbesserte sich über die POC-Zyklen mit Talonic von 75% auf 92% und ersetzte einen bisherigen Anbieter im Wert von $175-200K. Der entscheidende Faktor war nicht allein die Parsing-Qualität, sondern die Fähigkeit der Schema-Ebene, dokumentübergreifende Fälle aufzulösen und Frachtführer end-to-end den Ladungen zuzuordnen.

GETEC (Energie, Deutschland): 8,500 aktive Energielieferverträge in Strukturierung, Stand Q2 2026. Schema v2 mit 59 deutschsprachigen Feldern, validiert und geliefert an Microsoft Dynamics. GETEC benötigte EU-Datensouveränität, Provenienz auf Zellebene für die regulatorische Prüfung und eine Dokumentontologie, die in der Lage ist, deutschsprachige Energieverträge zu verarbeiten. Talonic war der einzige evaluierte Anbieter, der alle drei Anforderungen nativ erfüllte.