Was diese Funktion konkret ist
"Belegerkennung" klingt wie ein einzelner Schritt, ist in einer eigenen Software aber meist mehrere: OCR auf dem Bild laufen lassen, den erkannten Text einer Bedeutung zuordnen — dieses Wort ist der Lieferant, diese Zahl ist der Bruttobetrag —, die Positionstabelle über mehrere Seiten hinweg richtig zusammenhalten und am Ende einschätzen, wie sicher jedes einzelne Ergebnis eigentlich ist. Diese Funktion bündelt genau diese Schritte hinter einem einzigen API-Aufruf und liefert das Ergebnis bereits typisiert zurück, statt eines Zwischenformats, das Sie selbst weiterverarbeiten müssten.
Für einen Entwickler bedeutet das: kein eigener Parser für Rechnungslayouts, keine eigene Logik, um eine mehrseitige Positionstabelle wieder zusammenzusetzen, und kein eigenes System, um zu entscheiden, wie sicher ein gelesener Wert tatsächlich ist.
Warum Belegerkennung mehr ist als OCR
OCR beantwortet nur eine Frage: welcher Text steht an welcher Stelle auf der Seite. Für eine nutzbare Belegerkennung bleiben danach noch die eigentlich schwierigen Fragen offen — welches dieser Textstücke ist die Rechnungsnummer und welches eine beliebige Referenznummer im Kopfbereich; wo genau endet eine Position und beginnt die nächste, wenn eine Beschreibung über zwei Zeilen umgebrochen ist; wie hängen Zwischensumme, Steuerbetrag und Endsumme rechnerisch zusammen, und stimmt das überhaupt. Diese Fragen zu beantworten ist der eigentliche Wert dieser Funktion — nicht das reine Auslesen des Textes, das bei den meisten Diensten längst gelöst ist.
Der Unterschied wird an einem konkreten Beispiel greifbar: Zwei benachbarte Zahlen auf einem Beleg — ein Steuersatz von 19 und eine Menge von 19 Stück — sehen für ein reines OCR-System identisch aus, sie sind beide einfach die Ziffernfolge "19". Erst die Position im Kontext der Tabelle, die Nähe zu einem Prozentzeichen oder einer Mengeneinheit, und die Konsistenz mit dem berechneten Steuerbetrag entscheiden, welche der beiden Zahlen welches Feld tatsächlich ist. Diese semantische Zuordnung, nicht das reine Erkennen der Ziffern, ist der eigentliche Kern der Funktion.
Was zurückkommt — Rechnung und Kontoauszug
Bei einer Rechnung liefert die Funktion Lieferant, Rechnungsnummer, Rechnungs- und Fälligkeitsdatum, Währung, Netto-, Steuer- und Bruttobetrag, USt-IdNr. sowie die vollständige Positionstabelle. Bei einem Kontoauszug sind es Kontoinhaber, Zeitraum, und je Buchung Datum, Verwendungszweck, Betrag und laufender Saldo, dazu eine automatische Prüfung, ob Anfangssaldo plus alle Buchungen den gedruckten Endsaldo ergeben. Beide Antworten sind flach genug, um direkt in eine eigene Tabelle gemappt zu werden, und tief genug, um nichts an Information zu verlieren, das im Original stand.
Positionstabellen über mehrere Seiten
Der Teil, an dem die meisten selbstgebauten Lösungen scheitern, ist nicht das Lesen einer einzelnen Zeile, sondern das Zusammenhalten der Tabelle über eine Seitengrenze hinweg — wenn eine Rechnung 40 Positionen auf drei Seiten verteilt, ohne dass die zweite und dritte Seite die Spaltenüberschriften wiederholen. Diese Funktion behandelt die Tabelle als ein zusammenhängendes Objekt über das ganze Dokument, nicht als unabhängige Ausschnitte je Seite — Menge, Einzelpreis, Rabatt, Steuersatz und Zeilensumme bleiben je Position korrekt zugeordnet, unabhängig davon, auf welcher Seite die Zeile tatsächlich gedruckt steht.
Konfidenzwerte auf Feldebene
Statt einer einzigen Genauigkeitsangabe für das gesamte Dokument trägt jedes Feld seinen eigenen Konfidenzwert. Der praktische Unterschied ist groß: Ein Dokument mit 40 gelesenen Feldern und einem einzigen unsicheren Wert lässt sich gezielt an dieser einen Stelle prüfen — statt das gesamte Dokument als "unsicher" einzustufen, nur weil irgendein Feld irgendwo eine niedrige Konfidenz hat. Ihre eigene Software entscheidet, wo die Schwelle zwischen automatischer Übernahme und kurzer manueller Bestätigung liegt.
Wie ein Konfidenzwert tatsächlich zustande kommt
Ein Konfidenzwert ist kein geratener Prozentsatz, sondern das Ergebnis mehrerer zusammenwirkender Signale: wie klar und eindeutig das erkannte Zeichenbild an dieser Stelle des Belegs war, ob der gelesene Wert zu seinem erwarteten Feldtyp passt — ein Datum sieht anders aus als ein Geldbetrag —, und ob er sich mit anderen, bereits gelesenen Werten auf demselben Beleg konsistent verhält. Ein Bruttobetrag etwa, der sich rechnerisch nicht aus Netto- und Steuerbetrag ergibt, senkt den Konfidenzwert genau dieses einen Felds, selbst wenn das Zeichenbild an sich klar lesbar war — die Inkonsistenz selbst ist bereits ein Signal.
Der praktische Effekt: Ein Konfidenzwert bewertet nicht nur, wie gut ein Zeichen erkannt wurde, sondern auch, ob der erkannte Wert im Kontext des gesamten Belegs plausibel ist. Für Ihre eigene Schwellenwert-Logik bedeutet das, dass ein niedriger Wert selten willkürlich ist — es lohnt sich fast immer, dem betroffenen Feld tatsächlich einen zweiten Blick zu widmen, statt die Zahl als Rauschen abzutun.
Ein synchroner Aufruf, keine Warteschlange
Der Aufruf ist synchron: Sie senden den Beleg per POST /extract, und die vollständige Antwort — inklusive aller Felder, Positionen und Konfidenzwerte — kommt auf demselben HTTP-Request zurück, typischerweise innerhalb weniger Sekunden. Es gibt keinen separaten Callback, keinen Job, den Sie abfragen müssen, und keine Warteschlange, deren Zustand Sie selbst verwalten müssten — für die meisten Integrationen in eine bestehende Upload- oder Import-Pipeline ist das der einfachere Baustein.
Mehrsprachige und mehrwährungsfähige Belege
Die Felderkennung ist nicht auf eine einzelne Sprache trainiert, sondern liest, was tatsächlich auf dem Beleg gedruckt steht — deutsche, englische, französische und spanische Belege gehören zum Alltag, inklusive der jeweils üblichen Zahlen- und Datumsformate. Auch die Spaltenbezeichnungen einer Positionstabelle werden sprachübergreifend erkannt: "Menge", "Quantity" und "Cantidad" werden derselben Feldbedeutung zugeordnet, statt als unterschiedliche, unbekannte Spalten zu erscheinen.
Für Anbieter mit international tätigen Kunden bedeutet das: eine einzige Integration, keine gesonderte Erkennungslogik je Sprache, in der Ihr eigenes Produkt verkauft wird.
Gescannte, gedrehte und fotografierte Belege
Gescannte und bildbasierte PDFs
OCR läuft als erster Schritt automatisch mit, ohne dass Ihre Software zwischen textbasierten und bildbasierten PDFs unterscheiden müsste.
Schräg eingescannte Seiten
Eine leicht gedrehte oder schräg eingezogene Seite wird vor der Felderkennung korrigiert, statt die Erkennungsqualität stillschweigend zu verschlechtern.
Mit dem Smartphone fotografierte Quittungen
Unregelmäßige Beleuchtung, Schatten und ein perspektivisch verzerrtes Foto werden vor der eigentlichen Felderkennung vorverarbeitet.
Mehrere Konten auf einem Kontoauszug
Wenn ein Auszug mehrere Konten führt, wird jede Buchung dem richtigen Konto zugeordnet, statt alle Zeilen zu einer einzigen Liste zu vermischen.
Rohes OCR-Ergebnis gegen typisiertes Schema
| Merkmal | Allgemeiner OCR-Dienst | Diese Funktion |
|---|---|---|
| Antwortformat | Text und Koordinaten | Benannte, typisierte Felder |
| Positionstabelle | Muss selbst rekonstruiert werden | Bereits als Array mit fester Struktur |
| Konfidenz | Meist nur auf Zeichenebene | Auf jedem semantischen Feld |
| Mehrseitige Belege | Seite für Seite unabhängig | Als ein zusammenhängendes Dokument |
| Sprache | Modellabhängig | Sprachübergreifend erkannt |
Ein vollständiges Beispiel
curl -X POST https://flowparse.io/api/v1/extract \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "file": "JVBERi0xLjcK...", "filename": "rechnung-2201.pdf" }'
# → { "type":"invoice", "pages":1, "billedPages":1,
# "price": { "eur":0.035, "perPageEur":0.035, "complexity":"standard" },
# "data": { "type":"invoice", "data": {
# "supplier_name":"Beispiel GmbH", "invoice_number":"RE-2201",
# "invoice_date":"2026-03-14", "due_date":"2026-04-13", "currency":"EUR",
# "subtotal":420.00, "tax_amount":79.80, "total":499.80,
# "line_items":[
# { "description":"Beratung, 6 Std.", "quantity":6, "unit_price":70.00,
# "tax_rate":19, "amount":420.00 } ] } },
# "confidence": { "supplier_name":0.99, "invoice_number":0.98, "total":0.99 } }Jedes Feld im Beispiel oben lässt sich unabhängig auslesen und einzeln gegen einen Konfidenz-Schwellenwert prüfen — es gibt keinen Punkt, an dem Ihre eigene Software das gesamte Antwortobjekt als Ganzes akzeptieren oder verwerfen müsste.
Ein zweites Beispiel: ein Kontoauszug mit Saldenprüfung
Bei einem Kontoauszug sieht dieselbe Funktion strukturell anders aus, folgt aber demselben Prinzip: eine Zeile je Buchung, mit einer zusätzlichen, rein rechnerischen Prüfung, die kein Konfidenzwert, sondern ein harter Beweis ist.
curl -X POST https://flowparse.io/api/v1/extract \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "file": "JVBERi0xLjcK...", "filename": "kontoauszug-04-2026.pdf" }'
# → { "type":"bank_statement", "pages":2, "billedPages":2,
# "price": { "eur":0.07, "perPageEur":0.035, "complexity":"standard" },
# "data": { "type":"bank_statement", "data": {
# "account_holder":"Beispiel GmbH", "opening_balance":4820.00, "closing_balance":5340.50,
# "transactions":[
# { "date":"2026-04-02", "description":"Zahlungseingang Rechnung 3391", "amount":1092.10, "balance":5912.10 },
# { "date":"2026-04-05", "description":"Lastschrift Miete", "amount":-571.60, "balance":5340.50 }
# ], "balance_check": { "status":"reconciled", "gap":0.00 } } } }balance_check ist kein geschätzter Wert, sondern eine reine Rechenprobe: Anfangssaldo plus alle Buchungen muss den gedruckten Endsaldo ergeben. Stimmt die Rechnung, kann keine Zeile fehlen — ein rechnerischer Beweis, der unabhängig von jedem einzelnen Konfidenzwert gilt und für Ihre Software eine zweite, andersartige Prüfebene liefert.
Wie ein Entwickler das einbindet
Der übliche Einbindungspunkt ist genau dort, wo heute ein interner Parser oder ein Mitarbeiter den Beleg öffnet: direkt nach dem Upload, vor der eigentlichen Weiterverarbeitung im Produkt. Ein Beleg kommt herein, Ihr Backend ruft die Funktion synchron auf, das typisierte Ergebnis landet in Ihrer eigenen Datenstruktur, und nur die Felder unterhalb Ihres Konfidenz-Schwellenwerts werden in Ihrer Oberfläche zur kurzen Bestätigung markiert. Für ein Team, das heute einen internen Microservice für diesen Schritt pflegt, ersetzt dieser eine Aufruf typischerweise den gesamten internen Dienst — inklusive dessen laufender Pflege.
Ein Detail, das die Einbindung spürbar vereinfacht: Da die Funktion synchron antwortet, braucht Ihr Backend keinen eigenen Zustand für "wird gerade verarbeitet" zu verwalten — der Aufruf blockiert einfach bis zur Antwort, genau wie jeder andere HTTP-Aufruf auch. Für die meisten Web-Backends bedeutet das: keine zusätzliche Infrastruktur, kein separates Job-System, kein Polling-Mechanismus, nur eine gewöhnliche Funktion in Ihrer bestehenden Upload-Route.
Vom Erkennungsergebnis zum Exportformat
Das Erkennungsergebnis selbst ist formatunabhängig — dieselbe Struktur lässt sich anschließend nach Excel, CSV, DATEV-EXTF oder in eines von 14 Buchhaltungszielen exportieren, ohne erneut extrahiert werden zu müssen. Details zum DATEV-spezifischen Exportformat beschreibt die Seite API für Buchhaltungssoftware-Anbieter.
Rate Limits und Skalierung
Rate Limits gelten pro API-Schlüssel und sind im Dashboard einsehbar. Für eine einzelne Integration mit gelegentlichem Beleg-Upload spielt das selten eine Rolle — relevant wird es erst bei Stapelverarbeitung, etwa wenn ein Kunde auf einmal ein ganzes Quartal an Eingangsrechnungen hochlädt. In diesem Fall lohnt sich eine einfache Warteschlange auf Ihrer Seite, die Anfragen innerhalb des Limits über die Zeit verteilt, statt alle Belege in einem Moment abzufeuern und auf eine Rate-Limit-Antwort zu stoßen.
Da der Aufruf synchron ist, lässt sich die Warteschlange ohne zusätzliche Infrastruktur umsetzen — ein einfacher Worker, der Belege nacheinander oder mit begrenzter Parallelität abarbeitet, reicht für die meisten Integrationen aus, ohne einen separaten Job-Scheduler einzuführen.
Typische Fehlerbilder und wie sie aussehen
Ein nicht unterstütztes Dateiformat
Wird mit einem eigenen Fehlercode zurückgewiesen, statt versucht und stillschweigend leer beantwortet zu werden — Ihre Fehlerbehandlung sollte diesen Fall von einer leeren, aber gültigen Antwort unterscheiden können.
Ein leeres oder beschädigtes PDF
Wird als nicht konvertierbar erkannt und nicht berechnet. Der Fehlercode benennt den Grund, statt einen generischen Serverfehler zurückzugeben.
Ein Beleg ohne erkennbaren Dokumenttyp
Kommt selten vor, ist aber möglich bei sehr ungewöhnlichen Dokumenten — die Antwort benennt diesen Fall explizit, statt eine falsche Typzuordnung zu raten.
Eine Rate-Limit-Antwort bei hohem Durchsatz
Enthält Informationen, nach welcher Zeit ein erneuter Versuch sinnvoll ist, sodass Ihre eigene Warteschlange sich daran ausrichten kann.
Wie Sie die Funktion vor einer echten Integration einschätzen
Bevor Sie die Funktion fest in Ihr Produkt einbauen, lohnt sich ein kurzer, unverbindlicher Test mit zwei bis drei echten Belegen aus Ihrem eigenen Umfeld — nicht mit einem selbst erstellten Musterdokument, sondern mit dem unordentlichsten, am schwierigsten zu lesenden Beleg, den Sie zur Hand haben. Ein sauberes Testdokument zeigt fast nie, wie sich die Funktion bei den Randfällen verhält, die in der Praxis tatsächlich vorkommen — ein gescannter, leicht schiefer Beleg mit handschriftlicher Notiz am Rand ist ein deutlich aussagekräftigerer erster Test.
Der kostenlose Plan deckt genau diesen Testzweck ab: Sie sehen die vollständige Antwortstruktur, inklusive aller Konfidenzwerte, ohne sich vorab auf einen bezahlten Plan festlegen zu müssen. Ein Blick auf die Konfidenzwerte gerade der unsicheren Felder verrät oft schon nach einem einzigen Testbeleg, ob die Funktion für Ihren konkreten Beleg-Mix gut geeignet ist.
Was diese Funktion bewusst nicht tut
Keine Kontierung
Die Funktion liefert Belegdaten, keine Buchungsentscheidung. Welches Konto bebucht wird, bleibt Ihre eigene Logik.
Kein Archiv
Der Originalbeleg wird nach der Verarbeitung gelöscht. Die Aufbewahrungspflicht bleibt bei Ihrer Software.
Kein asynchroner Job
Es gibt keine Warteschlange und keinen Callback zu verwalten — nur einen synchronen Aufruf mit sofortiger Antwort.
Ein Sonderfall: mehrere Konten auf einem Kontoauszug
Manche Banken drucken mehrere Konten eines Kunden auf einem einzigen zusammenhängenden Auszug — etwa ein Girokonto und ein Tagesgeldkonto im selben PDF. Ohne besondere Behandlung würden alle Buchungen beider Konten in einer einzigen Liste landen, mit einer Saldenprüfung, die rechnerisch nicht aufgeht, weil sie zwei getrennte Salden vermischt. Die Funktion erkennt diesen Fall am Kontowechsel innerhalb des Dokuments und trennt die Buchungen korrekt nach Konto, mit einer eigenen Saldenprüfung je Konto statt einer einzigen, irreführenden für das gesamte Dokument.
Für Ihre eigene Datenstruktur bedeutet das: Die Antwort liefert mehrere Kontoblöcke statt eines einzelnen, jeder mit eigenem Anfangs- und Endsaldo — ein Detail, das beim Mapping berücksichtigt werden sollte, damit ein mehrkontiger Auszug nicht versehentlich als ein einzelnes, inkonsistentes Konto interpretiert wird.
Preis pro Seite
Fester Preis von 0,035 € pro Seite, unabhängig von der Komplexität des Belegs — kein Preisband, das Sie vorab schätzen müssten. Nur ein tatsächlich vollständig verarbeitetes Dokument wird berechnet; ein Fehler oder ein nicht unterstütztes Format kostet keine Seite.
Ein praktischer Vorteil dieser Einfachheit für Entwickler: Die Kosten eines API-Aufrufs lassen sich vollständig aus der Seitenzahl des Dokuments vorhersagen, bevor der Aufruf überhaupt stattfindet — nützlich, wenn Ihre eigene Software dem Nutzer vorab eine Kostenschätzung anzeigen möchte, ohne den Beleg selbst schon einmal analysiert zu haben.
API-Schlüssel anlegen
Ein kostenloser Plan reicht für die ersten Tests mit echten Belegen — ohne Kreditkarte.
Sicherheit und Datenschutz
API-Schlüssel werden ausschließlich als SHA-256-Hash gespeichert. Ein hochgeladener Beleg wird unmittelbar nach der Verarbeitung gelöscht — FlowParse ist kein Archivsystem.
Verschlüsselte Übertragung, gehashte API-Schlüssel, automatische Löschung nach der Verarbeitung.