Die Erkennungsschicht hinter jeder Rechnungsfreigabe-Software
Eine Software zur Rechnungsverarbeitung lebt von ihrem Freigabe-Workflow — wer eine Rechnung prüft, wer sie freigibt, wie sie gegen eine Bestellung abgeglichen wird. All das setzt aber voraus, dass die Rechnung vorher zuverlässig zu Daten geworden ist. Diese Seite beschreibt genau diesen vorgelagerten Schritt: eine API, die auf Eingangsrechnungen spezialisiert ist und ein bereits typisiertes Ergebnis liefert, statt eines rohen OCR-Outputs, den Sie selbst erst interpretieren müssten.
Warum die eigene Erkennung eng an den Freigabe-Workflow gekoppelt ist
Eine Freigabe-Entscheidung ist nur so gut wie die Daten darunter
Ein falsch gelesener Bruttobetrag oder eine falsch zugeordnete Position wandert direkt in die Freigabe-Logik — Fehler an dieser Stelle sind teurer als anderswo im Produkt, weil sie unbemerkt bis zur Zahlung durchlaufen können.
Positionsgenaue Steuersätze sind kein Nebenfeature
Eine Rechnung mit mehreren Steuersätzen auf verschiedenen Positionen ist im deutschen Geschäftsalltag üblich, nicht der Ausnahmefall — eine Erkennung, die nur einen Satz je Dokument liest, produziert hier regelmäßig falsche Daten.
Neue Lieferantenlayouts treffen die Freigabe direkt
Ein Layout, das die eigene Erkennung nicht kennt, blockiert nicht nur die Datenerfassung, sondern den gesamten Freigabeprozess für diese Rechnung — mit direkter Sichtbarkeit für den Endnutzer.
Der Freigebende ist selten die Person, die den Fehler beheben kann
Wenn die Erkennung an einer Rechnung scheitert, landet das Problem beim Freigebenden in der Fachabteilung, nicht beim Entwicklerteam — eine zuverlässige Erkennung verhindert genau diese Lücke zwischen Ursache und Zuständigkeit.
Was diese API nicht entscheidet
Keine Freigabe-Entscheidung
Wer eine Rechnung freigibt und ab welchem Schwellenwert, bleibt vollständig Ihre eigene Logik.
Kein PO-Matching
Der Abgleich gegen eine Bestellung setzt Daten voraus, die nur Ihr System kennt — die API liefert die sauberen Rechnungsdaten, gegen die dieser Abgleich stattfindet.
Keine rechtliche Bewertung der Pflichtangaben
Die API liest die vorhandenen Angaben strukturiert aus. Ob damit alle Pflichtangaben nach §14 UStG vollständig erfüllt sind, bleibt eine fachliche Prüfung.
Die Aufrufe, auf die es ankommt
Alle Endpunkte sind vollständig dokumentiert auf der API-Dokumentationsseite. Der zentrale Aufruf für eine Freigabe-Software ist /extract:
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-3391.pdf" }'
# → { "type":"invoice", "pages":1, "billedPages":1,
# "price": { "eur":0.035, "perPageEur":0.035, "complexity":"standard" },
# "data": { "type":"invoice", "data": {
# "supplier_name":"Lieferant AG", "invoice_number":"RE-3391",
# "invoice_date":"2026-04-02", "due_date":"2026-05-02", "currency":"EUR",
# "subtotal":950.00, "tax_amount":142.10, "total":1092.10,
# "line_items":[
# { "description":"Material A", "quantity":10, "unit_price":75.00, "tax_rate":19, "amount":750.00 },
# { "description":"Dienstleistung B", "quantity":1, "unit_price":200.00, "tax_rate":7, "amount":200.00 }
# ] } } }POST /validate ist kostenlos und prüft nur den Datenvertrag — nützlich, um Ihre eigene Freigabelogik gegen die erwartete Struktur zu testen, bevor echte Rechnungen verarbeitet werden.
Was aus einer Eingangsrechnung ausgelesen wird
Lieferant, Rechnungsnummer, Rechnungs- und Fälligkeitsdatum, Netto-, Steuer- und Bruttobetrag, USt-IdNr., dazu die vollständige Positionstabelle mit Bezeichnung, Menge, Einzelpreis, Rabatt, Steuersatz und Zeilensumme je Position — auch über mehrere Seiten hinweg korrekt zugeordnet. Jedes Feld trägt einen eigenen Konfidenzwert, sodass Ihre Freigabe-Software gezielt nur die unsicheren Werte markieren kann.
Pflichtangaben nach §14 UStG und Steuersätze je Position
Für eine deutsche Rechnungsverarbeitung reicht ein einzelner Steuersatz je Dokument selten aus — Lieferanten mit gemischten Leistungen stellen regelmäßig Rechnungen mit mehreren Steuersätzen auf verschiedenen Positionen. Die API liest jede Position mit ihrem eigenen Steuersatz aus, statt einen einzelnen Satz für die gesamte Rechnung anzunehmen, und liefert zusätzlich die für die Pflichtangaben nach §14 UStG relevanten Felder — Steuernummer beziehungsweise USt-IdNr., fortlaufende Rechnungsnummer, Ausstellungsdatum und Leistungsbeschreibung — strukturiert zur Weiterverarbeitung. Eine vertiefende Übersicht der elf Pflichtangaben selbst und wie eine Prüfung Schritt für Schritt abläuft, beschreibt die Anleitung Vorsteuerabzug richtig prüfen.
EU-Rechnungen und Reverse Charge
Eingangsrechnungen von Lieferanten aus anderen EU-Mitgliedstaaten folgen häufig einer anderen Logik als inländische Rechnungen — statt eines ausgewiesenen deutschen Steuersatzes trägt die Rechnung einen Hinweis auf das Reverse-Charge-Verfahren sowie die USt-IdNr. beider Parteien. Die API liest diese Angaben strukturiert aus wie jedes andere Feld auch: Hinweistext, USt-IdNr. des Lieferanten und des Empfängers, Nettobetrag ohne ausgewiesene Steuer. Die eigentliche steuerliche Behandlung — dass die Steuerschuld beim Empfänger liegt und dieser sie selbst in der Umsatzsteuervoranmeldung erklärt — bleibt eine fachliche Einordnung durch Ihre Software oder eine Steuerberatung, nicht etwas, das die API selbst entscheidet.
Für eine Rechnungsverarbeitungs-Software, die Lieferanten aus mehreren Ländern bedient, bedeutet das: Eine Rechnung aus Frankreich, den Niederlanden oder Italien wird strukturell genauso gelesen wie eine deutsche Rechnung, nur mit anderen Feldwerten — keine gesonderte Erkennungslogik je Herkunftsland.
Wie die Abrechnung funktioniert
Ein fester Satz von 0,035 € pro Seite, unabhängig von der Anzahl der Positionen oder Steuersätze auf der Rechnung — kein Preisband nach Komplexität. Jede Antwort trägt ein eigenes price-Objekt, sodass sich Ausgaben ohne eigene Schätzung nachvollziehen lassen.
| Rechnungen pro Monat | Angenommene Seiten (⌀ 1,5 je Rechnung) | Kosten pro Monat |
|---|---|---|
| 200 | 300 | 10,50 € |
| 1.000 | 1.500 | 52,50 € |
| 5.000 | 7.500 | 262,50 € |
| 20.000 | 30.000 | 1.050,00 € |
Diese Beispielrechnung nimmt bewusst einen einfachen Durchschnittswert von 1,5 Seiten je Rechnung an — die tatsächliche Zahl hängt von Ihrem eigenen Rechnungsmix ab und lässt sich nach den ersten produktiv verarbeiteten Rechnungen direkt aus GET https://flowparse.io/api/v1/usage ablesen, statt weiter geschätzt werden zu müssen.
So fügt sich die API in eine Freigabe-Software ein
Der übliche Einbindungspunkt liegt zwischen dem Rechnungseingang — E-Mail, Upload-Portal, Scan-Ordner — und der eigentlichen Freigabemaske. Ihre Software ruft/extractauf, sobald eine neue Rechnung eingeht, und zeigt dem Freigebenden nur noch die Felder mit niedrigem Konfidenzwert zur kurzen Prüfung — statt der gesamten Rechnung im Rohformat.
Ein zweiter, ebenso häufiger Einbindungspunkt ist die nachträgliche Sammelverarbeitung: ein Mandant liefert einen ganzen Ordner mit Rechnungen aus einem Quartal auf einmal. Hier lohnt es sich, die Aufrufe nicht seriell, sondern mit begrenzter Parallelität abzuarbeiten — genug, um den Durchsatz zu erhöhen, aber innerhalb der geltenden Rate Limits, damit kein einzelner Großauftrag die Verarbeitung anderer, gleichzeitig laufender Kunden verzögert.
Stapelverarbeitung für Rechnungsstapel
Ein typisches Szenario in der Rechnungsverarbeitung ist nicht der Einzelbeleg, sondern ein ganzer Stapel — ein neuer Mandant bringt ein halbes Jahr unbearbeiteter Rechnungen mit, oder ein Kunde lädt monatlich fünfzig bis hundert Belege auf einmal hoch. Für diesen Fall gibt es zwei sinnvolle Muster: entweder eine eigene Warteschlange, die jeden Beleg einzeln über /extract schickt und das Ergebnis sammelt, oder — wenn am Ende ohnehin eine zusammengeführte Übersicht gewünscht ist — Smart Merge, das mehrere bereits extrahierte Rechnungen in eine einzige, reconciled Arbeitsmappe zusammenführt, inklusive einer Herkunftsspalte je Zeile.
Für eine Freigabe-Software ist die Warteschlangen-Variante meist die passendere: Jede Rechnung durchläuft ihren eigenen Freigabeprozess einzeln, mit eigenem Konfidenz-Schwellenwert und eigener Prüfoberfläche, statt als Teil eines gesammelten Exports behandelt zu werden. Smart Merge eignet sich eher für den nachgelagerten Auswertungsfall — etwa wenn ein Mandant am Quartalsende eine Gesamtübersicht aller verarbeiteten Rechnungen wünscht.
Ein durchgerechnetes Beispiel: Rechnung bis Freigabe
Eine Rechnung mit gemischten Steuersätzen — Material zu 19 %, eine Dienstleistung zu 7 % — kommt über den Upload-Ordner an. Der Aufruf von /extractliefert nach rund zwei Sekunden beide Positionen korrekt mit ihrem jeweiligen Steuersatz. Alle Felder liegen über der Konfidenz-Schwelle von 0,90 und werden automatisch in die Freigabemaske übernommen; der Freigebende sieht nur noch die fertige Zusammenfassung und bestätigt mit einem Klick. Kosten für den gesamten Vorgang: eine Seite zum festen Satz.
Typische Fehlerbilder bei automatischer Rechnungsverarbeitung
Ein Rabatt wird nicht von der Zeilensumme getrennt
Ohne eigenes Rabattfeld landet ein prozentualer Nachlass manchmal fälschlich im Einzelpreis — die Positionstabelle liest Rabatt und Zeilensumme getrennt aus, statt sie zu vermischen.
Eine Gutschrift wird wie eine normale Rechnung behandelt
Ein negativer Gesamtbetrag oder ein expliziter Gutschrift-Hinweis wird als solcher erkannt, nicht einfach als Rechnung mit negativem Vorzeichen missverstanden.
Ein Kleinbetrag ohne vollständige Pflichtangaben wird falsch behandelt
Rechnungen bis 250 € brutto unterliegen vereinfachten Anforderungen — die vorhandenen Felder werden trotzdem strukturiert ausgelesen, auch wenn nicht alle elf regulären Pflichtangaben vorhanden sind.
Zwischensummen mitten in der Tabelle verwirren die Zuordnung
Eine Zwischensumme zwischen zwei Gruppen von Positionen wird als das erkannt, was sie ist, statt versehentlich als zusätzliche Position gezählt zu werden.
Eigenbau oder API, im Vergleich
| Kriterium | Eigene Erkennung | FlowParse-API |
|---|---|---|
| Steuersätze je Position | Eigene Parsing-Logik nötig | Bereits Teil jeder Position |
| Neue Lieferantenlayouts | Laufende Entwicklerpflege | Ohne Vorlage pro Aussteller gelesen |
| Konfidenzwerte je Feld | Eigenes Kalibrierungsprojekt | In jeder Antwort enthalten |
| Erste funktionierende Version | Mehrere Monate | Ein bis zwei Tage |
Genauigkeit und Konfidenzwerte
Rund 99 % Feldgenauigkeit bei üblichen Rechnungslayouts. Entscheidend für eine Freigabe-Software ist dabei weniger die Durchschnittszahl als der Konfidenzwert auf jedem einzelnen Feld — Ihre Software entscheidet selbst, ab welcher Schwelle ein Wert automatisch in die Freigabe übernommen wird und ab welcher ein Mensch kurz bestätigen muss.
Ein praktischer Startwert für die meisten Freigabe-Workflows liegt bei etwa 0,90 als globaler Schwelle, mit einer strengeren Schwelle speziell für den Bruttobetrag — das Feld, dessen falsche automatische Übernahme den direktesten finanziellen Schaden anrichten kann. Nach den ersten produktiv verarbeiteten Rechnungen lässt sich diese Startkonfiguration anhand der tatsächlich beobachteten Konfidenzverteilung feiner justieren.
Exportformate
Dieselbe geprüfte Rechnungsstruktur lässt sich zusätzlich zu DATEV auch nach Xero, QuickBooks, Sage, Zoho Books, NetSuite und neun weiteren Zielen exportieren — praktisch, wenn Ihre Freigabe-Software mehrere Buchhaltungssysteme parallel bedienen muss.
Mehrstufige Genehmigung und PO-Matching
Je mehr Stufen ein Freigabe-Workflow hat, desto wichtiger wird es, dass jede Stufe auf denselben, bereits geprüften Daten aufbaut, statt den Beleg mehrfach unabhängig zu lesen — ein Muster, das bei einer selbstgebauten Lösung leicht entsteht, wenn verschiedene Teile des Produkts zu unterschiedlichen Zeiten mit unterschiedlicher Erkennungslogik gebaut wurden.
Viele Freigabe-Workflows sind mehrstufig: eine erste Sichtprüfung, danach eine fachliche Freigabe ab einem bestimmten Betrag, gegebenenfalls eine zusätzliche Stufe bei Abweichung von einer hinterlegten Bestellung. Die API liefert für jede dieser Stufen dieselben Basisdaten, aber mit unterschiedlicher Relevanz: Die erste Stufe profitiert vor allem von den Konfidenzwerten auf Kopfebene, die spätere PO-Matching-Stufe braucht vor allem die positionsgenauen Mengen und Einzelpreise, um sie gegen die eigene Bestelldatenbank abzugleichen.
Ein praktisches Muster für mehrstufige Workflows: Die erste Stufe automatisiert anhand der Kopf-Konfidenzwerte, während die PO-Matching-Stufe zusätzlich eine eigene Toleranzregel braucht — etwa eine Mengenabweichung von bis zu 2 % gegenüber der Bestellung, bevor eine Rechnung tatsächlich als "abweichend" markiert wird. Diese Toleranzregel ist reine Produktlogik Ihrer Software; die API liefert nur die exakten, geprüften Werte, gegen die sie angewendet wird.
Vom Prototyp zum Produktivbetrieb
Ein kostenloser Plan reicht, um die Erkennung an echten, bereits bekannten Problemrechnungen aus dem eigenen Kundenbestand zu testen. Sobald die Schwellenwert-Logik für Ihre Freigabemaske steht, ist der Wechsel auf ein höheres Seitenkontingent eine reine Kontoänderung.
Ein sinnvoller Zwischenschritt vor dem vollen Produktivbetrieb ist ein begrenzter Pilotbetrieb mit einer kleinen Gruppe von Kunden oder Mandanten, deren Rechnungsvolumen und Lieferantenmix möglichst breit gestreut sind. Zeigt sich in diesem Pilotbetrieb über mehrere Wochen eine stabile Konfidenzverteilung, ist das ein deutlich verlässlicheres Signal für die Produktionsreife als ein einmaliger Test mit einer Handvoll ausgewählter Belege.
Prüfpfad und Nachvollziehbarkeit
Für eine Rechnungsfreigabe-Software zählt nicht nur, dass ein Wert korrekt gelesen wurde, sondern auch, dass sich im Zweifel nachvollziehen lässt, warum ein Feld automatisch übernommen und ein anderes zur Prüfung markiert wurde. Der Konfidenzwert jedes Felds lässt sich zusammen mit dem extrahierten Wert dauerhaft in Ihrer eigenen Datenbank speichern — damit entsteht ein Prüfpfad, der zeigt, auf welcher Grundlage eine Freigabe-Entscheidung getroffen wurde, ohne dass Sie diese Nachvollziehbarkeit selbst konstruieren müssten.
Das ist besonders bei einer späteren internen oder externen Prüfung relevant: Statt nur zu zeigen, dass ein Betrag korrekt war, lässt sich zeigen, dass er zum Zeitpunkt der Freigabe mit einem bestimmten, dokumentierten Konfidenzwert automatisch übernommen wurde — ein klarer Unterschied zu einer Blackbox-Erkennung ohne einsehbare Begründung.
Migration von einer bestehenden Erkennung
Für eine Freigabe-Software, die bereits eine eigene oder eine andere externe Erkennung im Einsatz hat, muss der Wechsel nicht als harter Schnitt erfolgen. Der risikoärmste Weg ist ein Parallelbetrieb: Neue Rechnungen laufen zusätzlich über /extract, ohne den bisherigen Erkennungspfad sofort abzuschalten. Nach einigen Wochen echten Betriebs zeigt der Vergleich der beiden Ergebnisse — insbesondere bei Rechnungen mit gemischten Steuersätzen oder ungewöhnlichen Layouts — objektiv, wo die neue Erkennung einen Unterschied macht.
Die bestehende Freigabeoberfläche, Ihre Kontierungslogik und der Export in DATEV oder ein anderes Zielformat bleiben bei diesem Weg vollständig unverändert — ausgetauscht wird ausschließlich der Erkennungsschritt selbst, was die Migration deutlich risikoärmer macht als ein vollständiger Neuaufbau der Freigabe-Software.
Für wen sich das eignet
Anbieter von Software zur Rechnungsfreigabe, AP-Automatisierung und Kreditorenbuchhaltung, die Belegerkennung als Teil des eigenen Produkts anbieten wollen, ohne dafür ein eigenes OCR-Team aufzubauen. Das reicht von kleineren SaaS-Anbietern mit begrenztem Entwicklerteam bis zu etablierten Anbietern, die eine bestehende Erkennung ablösen wollen, sowie Beratungshäusern, die individuelle Freigabe-Lösungen für einzelne Kunden umsetzen.
Gemeinsam ist allen diesen Anbietern eine Sache: Die Erkennung ist für sie ein notwendiger, aber nicht der eigentlich wertschöpfende Teil des Produkts — der eigentliche Wert liegt im Freigabe-Workflow, der Kontierungslogik oder der Mandantenverwaltung darüber. Genau deshalb lohnt es sich, die Erkennung selbst nicht zum internen Entwicklungsprojekt werden zu lassen.
API-Schlüssel anlegen
Ein kostenloser Plan reicht für die ersten Tests — 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.