Die Entscheidung, vor der jeder Anbieter irgendwann steht
Eine Buchhaltungssoftware lebt von einem wenig glanzvollen Schritt: aus dem PDF eines Kunden — einer Eingangsrechnung, einem Kontoauszug — werden Zeilen, mit denen die eigentliche Software überhaupt erst arbeiten kann. Kontierung, Umsatzsteuervoranmeldung, DATEV-Export, Reporting: alles setzt voraus, dass dieser erste Schritt zuverlässig funktioniert. Die meisten Teams beginnen mit einem allgemeinen Dokument-KI-Dienst und stellen erst danach fest, dass "eine OCR-API aufrufen" und "eine funktionierende Belegerkennung im Produkt haben" zwei sehr unterschiedliche Mengen an Entwicklungsarbeit bedeuten.
Diese Seite beschreibt die zweite Option direkt: eine API, die für Rechnungen und Kontoauszüge gebaut ist und ein bereits typisiertes Ergebnis liefert — Kopfdaten, Positionen, Summen, Konfidenzwerte — statt einer rohen OCR-Antwort, die Sie selbst erst in etwas Nutzbares verwandeln müssten. Für einen deutschen Markt heißt das konkret: ein Ergebnis, das sich direkt in Richtung DATEV weiterverarbeiten lässt, nicht nur in Richtung eines generischen Datenformats.
Warum die Eigenentwicklung ins Stocken gerät
Eine allgemeine OCR-API liefert Text und Koordinaten, keine Belegfelder
Textract, Google Document AI und ähnliche Dienste lesen Pixel hervorragend — supplier_name, invoice_number oder line_items mit korrekten Mengen und Einzelpreisen daraus zu machen, ist eine eigene Parsing-Schicht, die Ihr Team schreiben und dauerhaft pflegen muss.
Die Positionstabelle ist die Arbeit, die 80 % der Zeit kostet
Kopfdaten sind vergleichsweise einfach. Eine mehrseitige Positionstabelle korrekt zu rekonstruieren — mit umbrochenen Beschreibungen, Zwischensummen und uneinheitlichen Spaltenlayouts je Lieferant — ist der Punkt, an dem die meisten Eigenentwicklungen für Monate stecken bleiben.
Neue Beleglayouts kommen nach dem Start weiter dazu
Ein regelbasierter oder vorlagengetriebener Parser, der beim Start funktioniert hat, verschlechtert sich, sobald neue Lieferanten Rechnungen in Formaten senden, die niemand vorhergesehen hat — und jede Regression bedeutet einen Entwicklereinsatz, kein Support-Ticket.
Konfidenzwerte werden gern übersprungen und rächen sich später
Ohne einen verlässlichen Konfidenzwert je Feld bleibt nur die Wahl zwischen manueller Prüfung aller Belege (langsam) oder blindem Vertrauen in alle Werte (falsche Daten in der Buchhaltung) — eine gute Konfidenzschicht selbst zu bauen, ist wieder ein eigenes Projekt.
Das heißt nicht, dass eine eigene Erkennungsschicht in jedem Fall die falsche Entscheidung ist — ein Anbieter mit einem engen, stark standardisierten Kundenkreis und echter OCR-Erfahrung im Team kann das zum Laufen bringen. Es heißt, dass die ehrliche Kalkulation für "selbst bauen" meist ein mehrquartalsweises Projekt mit laufender Pflege ist, nicht ein Wochenende mit einer angebundenen API.
Was diese API nicht entscheidet
Keine Kontierung
Die API liefert strukturierte Belegdaten zurück. Welches Konto und welcher Gegenkonto-Schlüssel gebucht wird, bleibt eine fachliche Entscheidung Ihrer Software beziehungsweise ihrer Nutzer.
Kein Kontenrahmen-Wissen
Ob SKR03, SKR04 oder ein individueller Kontenrahmen — die API kennt ihn nicht und muss ihn auch nicht kennen. Sie liefert die Rohdaten des Belegs, nicht die Zuordnung zu einem bestimmten Konto.
Keine Freigabe-Workflows
Wer welchen Beleg freigibt, in welcher Reihenfolge und ab welchem Schwellenwert, ist vollständig die Logik Ihres eigenen Produkts.
Keine Aufbewahrung
Der Originalbeleg wird nach der Verarbeitung gelöscht. Die gesetzliche Aufbewahrungspflicht bleibt bei Ihrer Software und deren Nutzer, nicht bei der Erkennungsschicht.
Wo das zwischen Textract, Google Document AI und einer fertigen Suite liegt
Drei unterschiedliche Kategorien von Produkten werden in dieser Entscheidung oft verwechselt. Ein allgemeiner Dokument-KI-Dienst wie Amazon Textract oder Google Document AI ist Infrastruktur — die belegspezifische Logik bauen Sie selbst darauf auf. Eine vollständige Buchhaltungs- oder Kanzleisoftware ist ein fertiges Produkt, mit dem Sie im Wettbewerb stünden, wenn Sie selbst eine Buchhaltungssoftware anbieten, nicht etwas, das Sie einbetten würden.
Diese API liegt dazwischen: gebaut speziell für die Belegerkennung von Rechnungen und Kontoauszügen, sodass Sie ein bereits typisiertes Ergebnis erhalten statt eines rohen OCR-Outputs — aber sie hört genau dort auf, wo die Logik Ihres eigenen Produkts beginnt: Kontierung, Freigabe, Export in Ihr eigenes Format. Es ist die Schicht, die Sie sonst monatelang über einem generischen OCR-Dienst aufbauen würden, hier als ein einziger API-Aufruf.
DATEV als Zielformat — was die API konkret liefert
Für den deutschen Markt ist DATEV kein Nebenaspekt, sondern oft der eigentliche Grund für die Integration. FlowParse exportiert wahlweise direkt im DATEV-Format EXTF als "Buchungsstapel" — mit den drei Bestandteilen, die DATEV erwartet: der EXTF-Metadatenkopf (Berater- und Mandantennummer, Wirtschaftsjahr, Zeitraum, Währung), die Spaltenköpfe der Buchungssätze und darunter eine Buchungszeile je Rechnung oder Kontoauszugsposten.
Ein paar DATEV-spezifische Regeln werden dabei automatisch eingehalten: Beträge stehen mit deutschem Dezimalkomma und sind immer positiv, das Vorzeichen trägt stattdessen das Soll/Haben-Kennzeichen (S für Soll, H für Haben); das Belegdatum steht im Format TTMM, das Wirtschaftsjahr liefert der Kopf; Kontonummern und Steuerschlüssel verwenden sichere SKR03-Standardwerte, die sich überschreiben lassen. Sie erhalten also nicht nur "Daten aus einem Beleg", sondern eine Datei, die in der Form direkt zu einem DATEV-Import passt — die eigentliche Kontenzuordnung bleibt trotzdem eine fachliche Entscheidung, die bei Ihnen beziehungsweise Ihrer Software liegt.
Wer nicht direkt DATEV-Dateien erzeugen möchte, kann dieselbe geprüfte Datenstruktur auch als Excel oder CSV abrufen und in einer eigenen Zuordnungsschicht weiterverarbeiten — beide Wege laufen über denselben Aufruf, nur mit einem anderen format-Parameter.
Die Aufrufe, auf die es ankommt
Vier Endpunkte decken den gesamten Erkennungs-Workflow ab. Vollständig dokumentiert, mit jedem Parameter, finden Sie sie auf der API-Dokumentationsseite— die folgenden Beispiele zeigen die Form, die Sie tatsächlich aus der Ingestion-Pipeline einer Buchhaltungssoftware heraus aufrufen würden.
curl -X POST https://flowparse.io/api/v1/extract \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "file": "JVBERi0xLjcK...", "filename": "eingangsrechnung-1024.pdf" }'
# → { "type":"invoice", "pages":2, "billedPages":2,
# "price": { "eur":0.07, "perPageEur":0.035, "complexity":"standard" },
# "data": { "type":"invoice", "data": {
# "supplier_name":"Muster GmbH", "invoice_number":"RE-1024",
# "invoice_date":"2026-05-01", "due_date":"2026-05-31", "currency":"EUR",
# "subtotal":1840.00, "tax_amount":349.60, "total":2189.60,
# "line_items":[ { "description":"Bauteil, 10mm", "quantity":40,
# "unit_price":46.00, "tax_rate":19, "amount":1840.00 } ] } } }curl -X POST https://flowparse.io/api/v1/validate \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "type": "invoice", "data": { "supplier_name": "Muster GmbH",
"invoice_number": "RE-1024", "total": 2189.60, "currency": "EUR" } }'
# → { "valid": true, "issues": [] }/validate kostet nichts und eignet sich, um während der Entwicklung Ihren eigenen Datenvertrag gegen die Schemaprüfung zu testen — nützlich, wenn Sie erst die Struktur klären wollen, bevor echte Belege verarbeitet werden.
curl -X POST https://flowparse.io/api/v1/export \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "format": "datev", "type": "invoice", "data": { ... } }'GET /usage liefert Plan, Guthaben und den aktuellen Preis pro Seite — nützlich, um in Ihrer eigenen Oberfläche anzuzeigen, wie viel eine Kundenintegration diesen Monat bereits verbraucht hat.
curl https://flowparse.io/api/v1/usage \
-H "Authorization: Bearer pf_live_xxx"
# → { "plan":"PRO", "pricePerPageEur":0.035,
# "balance": { "pages":812, "monthlyRemaining":712, "bonusPages":100 },
# "thisMonth": { "requests":143, "pages":288, "spendEur":10.08 } }Was aus Rechnung und Kontoauszug ausgelesen wird
Bei einer Eingangsrechnung liefert die API Lieferant, Rechnungsnummer, Rechnungs- und Fälligkeitsdatum, Nettobetrag, Steuerbetrag und -satz, Bruttobetrag, USt-IdNr. sowie die vollständige Positionstabelle — Bezeichnung, Menge, Einzelpreis, Rabatt, Steuersatz und Zeilensumme je Position, auch über mehrere Seiten hinweg konsistent zugeordnet. Bei einem Kontoauszug sind es Buchungsdatum, Verwendungszweck, Soll- und Haben-Beträge sowie der laufende Saldo je Zeile, dazu eine automatische Saldenprüfung: Anfangssaldo plus alle Buchungen muss den gedruckten Endsaldo ergeben, sonst wird die Zeile mit dem Bruch markiert.
Jedes einzelne Feld trägt einen eigenen Konfidenzwert, keinen einzigen Wert für das ganze Dokument — so kann Ihre Software gezielt nur die unsicheren Felder markieren, statt einen Beleg pauschal als "zu prüfen" einzustufen, obwohl 90 % davon fehlerfrei gelesen wurden.
Referenzarchitektur: wo die API in Ihrem Stack sitzt
In den meisten Integrationen sitzt der Aufruf zwischen der Dokumenten-Aufnahme Ihrer Software — E-Mail-Postfach, Upload-Portal, Scan-Ordner — und der eigentlichen Buchhaltungslogik. Ihr Backend empfängt den Beleg, ruft /extractsynchron auf, speichert das typisierte Ergebnis inklusive Konfidenzwerten in Ihrer eigenen Datenbank, und erst danach beginnt die produktspezifische Logik: Kontierungsvorschlag, Freigabe-Workflow, DATEV-Export. Diese Trennung ist bewusst — die API kennt Ihren Kontenrahmen nicht, und Ihre Buchhaltungslogik muss sich nicht um Belegerkennung kümmern.
Für eine mandantenfähige Software empfiehlt sich zusätzlich eine dünne Konfigurationsebene zwischen Erkennung und Kontierung: Schwellenwert, bevorzugtes Exportformat und Kontenrahmen-Zuordnung lassen sich pro Mandant hinterlegen, während dieselbe zugrunde liegende Erkennung für alle Mandanten gleichermaßen genutzt wird — eine einzige Integration statt einer je Mandant.
Wie die Abrechnung funktioniert
Die Nutzung wird zu einem festen Satz von 0,035 € pro Seite abgerechnet — unabhängig davon, wie aufwendig ein Beleg zu verarbeiten ist. Keine Preisstufen nach Komplexität, kein Faktor, den Sie erst schätzen müssten: eine Seite ist eine Seite, und genau das legt auch fest, wie viele Seiten ein Aufladebetrag in Euro ergibt. Keine Sitzlizenz, keine monatliche Mindestabnahme, um zu starten.
Jede /extract-Antwort trägt ein eigenes price-Objekt — was der Beleg gekostet hat und was das pro Seite ergibt —, sodass Sie Ausgaben ohne eigene Schätzung abgleichen können. API-Nutzung wird aus einem eigenen Guthaben verrechnet, das nie verfällt, getrennt von den monatlichen Seiten des Website-Kontos.
So fügt sich die API in Ihre Software ein
Für eine Buchhaltungssoftware sitzt der Aufruf typischerweise genau an der Stelle, an der heute ein Mitarbeiter einen Beleg von Hand öffnet: nach dem Upload oder E-Mail-Import, vor der eigentlichen Kontierung. Ein Kunde lädt einen Beleg hoch, Ihr Backend ruft/extractauf, das Ergebnis landet strukturiert in Ihrer Datenbank, und Ihre eigene Oberfläche zeigt dem Kunden nur noch die Felder mit niedrigem Konfidenzwert zur kurzen Bestätigung — statt des gesamten Belegs.
Für einen Kanzlei-Workflow lässt sich das direkt auf einen Kostenpunkt je Mandant abbilden — der Preis, einen Beleg auszulesen, wird zu einer bekannten, planbaren Größe, die Sie in Ihre eigene Preisgestaltung einrechnen können, statt einer schwankenden Infrastrukturkostenzeile.
Ein durchgerechnetes Beispiel: PDF bis Buchungssatz
Eine zweiseitige Eingangsrechnung eines neuen Lieferanten kommt per E-Mail-Import an. Ihre Software ruft POST /extractauf; nach rund zwei bis vier Sekunden liegt das typisierte Ergebnis vor: Lieferant, Rechnungsnummer, Datum, sieben Rechnungspositionen, Netto-, Steuer- und Bruttobetrag, jedes Feld mit Konfidenzwert. Sechs der sieben Positionen liegen über Ihrem Schwellenwert und werden automatisch übernommen; eine Position mit einem ungewöhnlich formatierten Rabatt liegt darunter und wird in Ihrer Oberfläche markiert.
Ihr Nutzer bestätigt die eine markierte Position mit einem Blick, nicht die ganze Rechnung. Anschließend ruft Ihre Software POST /exportmit "format": "datev"auf und erhält eine DATEV-EXTF-Datei zurück, die sich direkt in den Buchungsstapel des Mandanten importieren lässt. Kosten für den gesamten Vorgang: zwei Seiten zum festen Satz, unabhängig davon, wie viele Positionen die Rechnung tatsächlich enthielt.
Eigenbau oder API, im Vergleich
| Kriterium | Eigene OCR-Pipeline | FlowParse-API |
|---|---|---|
| Erste funktionierende Version | Mehrere Monate, oft ein Quartal oder mehr | Ein bis zwei Tage bis zum ersten Aufruf |
| Positionstabellen über mehrere Seiten | Eigene Rekonstruktionslogik nötig | Bereits Teil der typisierten Antwort |
| Neue Lieferantenlayouts | Erfordert laufende Entwicklerpflege | Wird ohne Vorlage pro Aussteller gelesen |
| Konfidenzwerte je Feld | Eigene Kalibrierung, eigenes Projekt | In jeder Antwort bereits enthalten |
| DATEV-EXTF-Export | Eigene Formatimplementierung | Direkt über den Export-Endpunkt |
| Laufende Kosten | Infrastruktur plus Entwicklerzeit | Fester Preis pro Seite |
Genauigkeit und Konfidenzwerte
Bei üblichen Rechnungs- und Kontoauszugslayouts liegt die Feldgenauigkeit bei rund 99 %. Der entscheidende Punkt für eine Buchhaltungssoftware ist aber nicht die Durchschnittszahl, sondern der Konfidenzwert auf jedem einzelnen Feld: Ihre Software kann damit selbst entscheiden, ab welcher Schwelle ein Wert automatisch übernommen wird und ab welcher er einem Menschen zur kurzen Bestätigung vorgelegt wird — eine Entscheidung, die von der Risikobereitschaft Ihrer eigenen Nutzer abhängt, nicht von einem festen Wert, den die API vorgibt.
Exportformate und Buchhaltungsziele
Neben dem DATEV-EXTF-Format lässt sich dieselbe geprüfte Belegstruktur auch direkt in Xero, QuickBooks, Sage, Zoho Books, NetSuite, MYOB, Wave, FreshBooks, FreeAgent, das 1С-Austauschformat sowie OFX/QBO/QFX für Kontoauszüge exportieren — 14 Ziele insgesamt über denselben/export-Aufruf, nur mit anderem format-Parameter. Für ein Produkt, das mehrere Buchhaltungssysteme parallel bedient, bedeutet das eine Erkennungsschicht statt einer je Zielsystem.
Fehler und Rate Limits
Ein nicht konvertierbares Dokument — ein leeres PDF, ein beschädigter Scan — wird nicht berechnet und liefert einen klaren Fehlercode statt eines stillen Fehlschlags. Rate Limits gelten pro API-Schlüssel und sind im Dashboard einsehbar; für Stapelverarbeitung mit vielen Belegen gleichzeitig empfiehlt sich eine Warteschlange auf Ihrer Seite, die Anfragen innerhalb des Limits über die Zeit verteilt, statt alles in einem Moment abzufeuern.
Vom Prototyp zum Produktivbetrieb
Ein typischer Weg beginnt mit einem kostenlosen Plan und ein paar echten Belegen aus dem eigenen Kundenbestand, um Konfidenzwerte und Layoutvielfalt real einzuschätzen — nicht anhand von Beispieldaten, sondern anhand dessen, was Ihre eigenen Kunden tatsächlich hochladen. Sobald die Schwellenwert-Logik für die manuelle Prüfung steht, ist der Wechsel auf einen bezahlten Plan mit höherem Seitenkontingent eine reine Konfigurationsänderung, keine erneute Integration.
Für wen sich das eignet
Diese API richtet sich an Anbieter von Buchhaltungs-, Kanzlei- und ERP-Software, die Belegerkennung als Teil ihres eigenen Produkts anbieten wollen, ohne dafür ein eigenes OCR-Team aufzubauen — von kleineren SaaS-Anbietern mit begrenztem Entwicklerteam bis zu etablierten Anbietern, die eine bestehende, aber in die Jahre gekommene Eigenentwicklung ersetzen möchten.
Warum Teams aufhören, eigene OCR zu pflegen
Der Punkt, an dem ein Team die eigene Erkennung aufgibt, ist selten der Start des Projekts, sondern der erste größere Kundenzugang mit einem Lieferantenlayout, das die eigene Logik nicht vorgesehen hatte — und die Erkenntnis, dass jeder weitere solche Fall wieder einen Entwicklereinsatz bedeutet, nicht eine Konfiguration. Eine API, die auf beliebige Layouts liest statt auf trainierte Vorlagen, verschiebt genau dieses Risiko von Ihrem Team zur Erkennungsschicht.
API-Schlüssel anlegen
Ein kostenloser Plan reicht, um die ersten echten Belege zu testen — ohne Kreditkarte, ohne Verkaufsgespräch. Der Schlüssel lässt sich im Dashboard jederzeit widerrufen, falls er kompromittiert wurde.
Sicherheit und Datenschutz
API-Schlüssel werden ausschließlich als SHA-256-Hash gespeichert — FlowParse speichert Ihren Klartext-Schlüssel zu keinem Zeitpunkt. Ein hochgeladener Beleg wird unmittelbar nach der Verarbeitung gelöscht, nicht dauerhaft vorgehalten. FlowParse ist kein Archivsystem und macht für sich genommen keine Software GoBD-konform — die Verantwortung für Nachvollziehbarkeit, Unveränderbarkeit und Aufbewahrung bleibt bei Ihrer Software und deren Nutzer.
Verschlüsselte Übertragung, gehashte API-Schlüssel, automatische Löschung des Originalbelegs nach der Verarbeitung.