Kurz: Eine Genauigkeitszahl ohne Methode ist wertlos. Wir messen getrennt nach Belegart: elektronische Rechnungen mit eingebettetem XML (dort wird gelesen, nicht erkannt), PDFs mit Text, und Scans oder Fotos. Bei den letzten beiden zählt jedes Feld einzeln, und wir zählen nur, was exakt stimmt.
Werbeaussagen wie „99 Prozent Genauigkeit" sagen nichts, solange niemand sagt, worauf sich die Zahl bezieht. Ein Anbieter kann eine Auswahl sauberer, gedruckter Rechnungen messen und damit fast jeden Wert erreichen. Mischt man Fotos vom Küchentisch dazu, sinkt die Zahl sofort.
Dazu kommt, dass „genau" unterschiedlich definiert wird. Manche zählen ein Dokument als richtig, wenn die wichtigste Zahl stimmt. Manche zählen jedes Feld. Manche zählen eine IBAN als korrekt, wenn die ersten Zeichen passen. Diesen drei Definitionen liegen Welten dazwischen.
Getrennt nach Belegart. Wir werfen nicht alles in einen Topf, weil das Ergebnis sonst von der Mischung abhängt und nicht vom Werkzeug.
Feldweise. Gezählt wird jedes einzelne Feld: Rechnungsnummer, Datum, Lieferant, Käufer, Betrag, Währung, Steuernummer, IBAN.
Strikt verglichen. Ein Wert gilt nur als richtig, wenn er dem Referenzwert exakt entspricht. Eine Zahl, die nur fast stimmt, ist falsch. Datumsangaben werden vorher normalisiert (03.01.1994, 03.01.94 und 3. Januar 1994 sind dasselbe Datum), aber sonst wird nicht gerundet und nicht geschönt.
Mit Referenz. Gemessen wird gegen einen bekannten Sollwert, nicht gegen ein Gefühl. Bei den Testdatensätzen sind die richtigen Feldwerte bekannt, sonst wäre die Zahl wertlos.
Unsere Messungen stützen sich auf öffentliche Datensätze mit hinterlegten Sollwerten sowie auf deutsche Belege aus dem Umfeld elektronischer Rechnungen:
| Datensatz | Umfang | Belegart | Zweck |
|---|---|---|---|
| Deutschsprachige E-Rechnungen (ZUGFeRD) | 149 Belege | PDF mit XML | Prüfen, was aus Strukturdaten herauskommt |
| Rechnungen mit Sollwerten (englisch) | 25 Belege | Bilder | Feldgenauigkeit bei reiner Bilderkennung |
| Rechnungen mit Sollwerten (Land mit abweichenden Formaten) | 15 Belege | Bilder | Prüfen der Länderformate bei Steuernummern und IBAN |
| Fotos echter Rechnungen | 74 Belege | Fotos | Verhalten bei schlechten Vorlagen |
Die genauen Zahlen je Datensatz ändern sich, während wir weiter messen, deshalb nennen wir hier den Stand und die Methode, nicht eine einzelne ewige Prozentzahl.
Bei Belegen mit eingebettetem XML sind Rechnungsnummer, Datum, Betrag und IBAN vollständig und korrekt, weil sie gelesen und nicht erkannt werden. Hier gibt es keine Ausreißer außer bei Belegen, in denen das Feld im Original leer ist.
Bei Bildern und Scans liegen die wichtigsten Felder (Nummer, Datum, Betrag, Lieferant, Käufer) in unseren Messungen sehr hoch, aber nicht bei hundert Prozent. Der häufigste Fehler ist nicht die Ziffer, sondern die Auswahl: Auf einer Rechnung stehen mehrere Beträge, und das System muss den richtigen wählen. Zweithäufigster Fehler sind Steuernummern in Formaten, die wir noch nicht kannten.
Wir beheben solche Fälle als Regel, nicht als Modell: Ein neues Länderformat oder eine neue Schreibweise kommt in die Liste der Muster. Deshalb ist das System auch nachvollziehbar: derselbe Beleg ergibt immer dasselbe Ergebnis.
Manche Belege lassen sich prinzipiell nicht sauber auslesen. Ein schief fotografierter Kassenzettel ohne klare Zeilen, ein Scan mit Fleck über der Rechnungsnummer, eine Rechnung, die nur aus einer handschriftlichen Notiz besteht. In solchen Fällen gibt DueBuddy lieber ein leeres, markiertes Feld zurück als einen geratenen Wert.
Wir behaupten keine Genauigkeit für Belegarten, die wir nicht gemessen haben, und wir nennen keine Zahl ohne die zugehörige Auswahl. Wir veröffentlichen auch keine Prozentwerte aus fremden Studien als wären es unsere.
Warum ist die Genauigkeit bei XML-Rechnungen höher als bei Scans? Weil dort nichts erkannt wird. Die Werte stehen als Daten in der Datei.
Zählt ein Dokument als richtig, wenn ein Feld fehlt? Nein. Nur exakte Übereinstimmung zählt.
Was macht das System bei einem unsicheren Wert? Es markiert das Feld und lässt es leer, statt zu raten.
Kann ich die Testdatensätze sehen? Die öffentlichen Datensätze sind öffentlich. Die deutschen E-Rechnungen stammen aus dem Umfeld der ZUGFeRD-Beispiele.
Stand: 5. Oktober 2026. Diese Seite beschreibt unsere Methode, nicht eine Momentaufnahme.