OCR - Rechnungserkennung, wie geht das genau?

beta20

Top Contributor
Hallo zusammen,

ich würde gerne eine automatische Rechnungserkennung programmieren.
Ich frage mich jedoch gerade wie das technisch genau abläuft, wie erkennt mein OCR den Rechnungsbetrag, Datum etc.?

Hier meine Idee...
1) Ich scanne ein PDF / Image ein
2) Jage das über den OCR (z.B. Tessa4j OCR).
3) Nun erhalte ich einen String zurück
4) Ich prüfe den String nun auf verschiedene String ab (z.B. "Rechnungsdatum", "Rechnungsbetrag"; dahinter sollte dann i.d.R. der Rechnungsbetrag etc. stehen...
5) Wie erhalte ich den Betrag / Datum aber nun?

Danke für jede Hilfe.
 
z.B. durch DMS mit OCR erreichen, soweit mir bekannt kann dieses z.B. Alfresco.
Alfresco hatte ich mir zwar vor vielen Jahren mal flüchtig angesehen, kenne es aber im Grunde nur dem Namen nach. Aber egal welches DMS man nutzt: entweder muß man eine KI trainieren oder ein Regelwerk aufbauen. Beides wird im Laufe der Jahre immer weiter verbessert und stellt dann einen eigenen Wert dar. Deshalb sollte man sich überlegen, ob man den Klassifizierungsprozess überhaupt mit DMS-Funktionalität realisieren möchte oder doch lieber an eine unabhängige Lösung auslagert (erst mal egal, ob Eigenprogrammierung oder eine Lösung, wie sie @X2X offenbar anbietet). Wenn man das DMS dann mal wechseln möchte, kann man den bestehenden Klassifizierungsprozess behalten und muss an der Stelle keinen großen Migrationsaufwand betreiben.
 
Wenn man die Sammlung der Templates als das Wissen des Software-Roboters betrachtet, dann ist es Machine-Learning, weil ja immer wieder neue Lieferanten/Templates dazukommen oder auch mal erweitert werden müssen.
Äh... damit ich es richtig verstehe: wenn ich ein Template erweitere, dann ist es Machine-Learning, weil ich der Maschine was lerne?
 
Ich suche auch gerade sowas...
Was kostet denn die "OCR OnPremise-SDK" ?
Von was redest Du genau? Meinst Du Googles OCR On-Prem Lösung wie unter https://cloud.google.com/vision/on-prem beschrieben oder meinst Du etwas anders?

Bei Google On-Prem brauchst Du einen GKE oder Anthos Cluster - da wäre evtl. erst einmal die Frage, ob sowas vorhanden ist... und wenn, dann könnte man das da mit den Verantwortlichen abklären denke ich mal 🙂
 
Kanadier hier,

ich habe euch ueber Google gefunden, nachdem ich neugierig war, wie deutsche Firmen das handhaben.
Wir arbeiten an demselben Problem in eine der groessten Steuerfirmen unseres Landes in Kanada.

Lass uns ueber die Extrahierung von Key-Value Paaren reden (Tabellen sind eine Sache fuer sich).

Ich habe lange ueber dieses Problem nachgedacht, und bin schliesslich auf die fuer mich "weiseste" Loesung gekommen, die "gut genug" zu sein scheint, eine simple Loesung zu einem sehr komplizierten Thema. (Ich habe spaeter auch herausgefunden, dass Google einen aehnlichen Ansatz mit ihrem System verfolgt, das hier schon empfohlen wurde. Nein, nicht nur im aehnlichen Ansatz... die machen es haargenauso)

Du erstellst dir zuerst "Kandidaten", das sind Tokens, also "Woerter" die von ihrer Zusammensetzung aus Buchstaben ein moeglicher Match sein koennen.
Danach schaust du dir die Nachbarn von jedem Kandidaten "nach links" an und wenn du nicht fuendig wirst um 10% "nach oben" (behalte beim OCR-Prozess also die x-y Koordinaten, die sind wichtig)

Der "weise" Teil ist ein Verifizierungsprozess, um "Fehltreffer" auszuwerfen. Du kannst schon von vornherein einige Heuristiken aufstellen:
Die Gesamtsumme ist der hoechste Geldbetrag.
Mehrwertsteuer ist bei euch ~19% von der Gesamtsumme; neben der Gesamtsumme wuerde nicht ein anderes Keyword (z.B. "Rueckgeld") stehen.
Das Zahldatum kommt nach dem Rechnungsdatum etc. etc.

Es gibt knapp ueber 500 Keywords in Rechnungen bei uns, nach denen wir suchen. Alles KI ist nur "Kurvenanpassung."

Ich habe meiner Assitentin gesagt, 80% Treffsicherheit ist top. 90% Erfolgsrate ist 5 Jahre Entwicklungszeit und um von 90% auf 95% zu kommen sind nochmal 10 Jahre. Ich denke, jeder der aus diesem Bereich kommt, wird bestaetigen: Bei 95% flacht auch dann diese Kurve ab.

So gut wie alle Forschungspapiere ueber dieses Thema gelesen zu haben gebietet mir diesen Loesungsweg zu favoritisieren (obgleich ich auch widersprochen werden moechte). TensorFlow, um auf Fabian von dem Link zu entwickler.de einzugehen, ist eine gute Idee, bis du skalieren musst. Daniel Holanda Noronha hat mit LeFlow versucht TensorFlow auf FPGAs zu werfen. FPGAs sind eine gute Idee.

Wir brauchen definitiv mehr FPGA-OCR Forschungen. Ich habe auch einige Ideen zum Thema OCR, aber ich moechte damit nicht mein Leben verschwenden.

"Wahre Semantik" in Rechnungen reinzubringen... dazu muesstest du vorerst ein System wie Cyc haben, das ueber die "groessere Welt" bescheid weiss. Der Kerninterpreter von CYC ist im Wesentlichen wie ein metazirkulaerer Lisp Interpreter. Die Inferenzregeln koennen etwa zwei Dutzend sein und sind im Wesentlichen Einzeiler im Pradikatenkalkuel 2. Ordnung. Der Rest von CYC besteht im Wesentlichen aus verschiedenen Arten von Wissen, die als Beziehungen und Kausalketten kodiert sind.

Die Inferenzmaschine ist pille-palle, wenn man die praktische Vergroesserung dieser Regeln zur Optimierung ignoriert. Die Einstein-Frage lautet, "Was genau muss es wissen - und wie viel, um das ganze praktisch zu machen?"
 

Neue Themen


Zurück
Oben