StabilideaStabilidea
  • Case study
  • Risorse
  • Chi siamo
Parliamone
  1. Home
  2. Risorse
  3. Processo

ProcessoAdiuto

Quando l'OCR non basta

DDT fotografati storti, venti fornitori con venti layout, tabelle spezzate su due pagine. Perché l'OCR classico si ferma lì, cosa cambia con i modelli che leggono il documento, e come si misura l'accuratezza prima di mandarlo in produzione.

Quasi tutte le aziende che ci chiamano per il ciclo passivo hanno già provato a leggere i documenti in automatico. Spesso hanno anche già comprato qualcosa. La frase con cui iniziano è sempre la stessa: «l'OCR ce l'abbiamo, ma i documenti li controlliamo lo stesso».

Non è un problema di prodotto scadente. È che l'OCR classico risolve un problema diverso da quello che hanno.

Cosa fa un OCR, e cosa gli si chiede

Un OCR riconosce caratteri: guarda dei pixel e dice che quella forma è una "3". È un lavoro che sa fare benissimo da vent'anni.

Quello che serve a un ufficio acquisti è un'altra cosa: capire che quel documento è un DDT, che ha una tabella, che ogni riga della tabella è un articolo, e che il numero in fondo a destra su quella riga è la quantità consegnata — non il prezzo, non il numero di colli, non il progressivo di riga.

I sistemi tradizionali colmano la distanza con le maschere: si dice al software che su quel modulo, per quel fornitore, la quantità sta in un certo rettangolo. Funziona, finché il documento sta nel rettangolo.

I quattro casi che rompono tutto

Il documento fotografato. Il DDT arriva in magazzino, il magazziniere lo fotografa col telefono sotto il portico. Storto, con l'ombra della mano su due righe e il riflesso della pellicola sopra il totale. Nessuna maschera regge una foto: le coordinate non esistono più.

Venti fornitori, venti layout. Ogni fornitore ha il suo modulo, e in un'azienda manifatturiera i fornitori sono decine. Ogni layout è una maschera da disegnare e da mantenere. Il conto si ribalta prima di arrivare a metà anagrafica: si spende più a configurare che a digitare.

La tabella che si spezza. Un ordine da quaranta righe arriva su tre pagine. La tabella riparte a pagina due senza intestazione, e a pagina tre ci sono in mezzo le condizioni di trasporto. Un lettore che ragiona per rettangoli vede tre tabelle diverse — o una sola con dentro del testo che non c'entra.

Il campo letto bene e attribuito male. È il caso peggiore perché non sembra un errore. L'OCR legge "340" correttamente e lo mette nel campo quantità: peccato che su quel modulo 340 fossero i chili, e i pezzi fossero 12. Il dato è giusto, il significato no, e a valle il riscontro a tre vie salta senza che si capisca perché.

Leggere il documento invece di riconoscerne i caratteri

La differenza è tutta qui: il modello guarda la struttura, non le coordinate. Riconosce che c'è una tabella perché ne capisce la forma, che quella colonna è una quantità perché ne capisce il ruolo nel documento, e che la riga a pagina due è la continuazione di quella a pagina uno.

È il motivo per cui abbiamo costruito DoqEngine, il motore che usiamo per questa parte: non riconosce caratteri, interpreta layout complessi, tabelle e grafici e trasforma una scansione in dati con un significato. Su Co.Mas è quello che ha reso possibile il resto — circa 12.000 documenti l'anno prelevati da Adiuto, letti e riconsegnati al flusso come dati confrontabili.

La conseguenza pratica che interessa a chi paga: un fornitore nuovo, o un fornitore che cambia modulo, di solito non richiede nessun lavoro di configurazione. È il costo che con le maschere non finiva mai.

Come si misura l'accuratezza prima della produzione

Questa è la parte che chi vende estrazione dati salta volentieri, e che invece decide se il progetto funziona.

Non si misura "l'accuratezza del sistema": si misura campo per campo, su documenti veri dell'azienda. Numero documento, data, partita IVA fornitore, codice articolo, quantità, prezzo unitario, totale riga. Sono sette campi con sette accuratezze diverse, e la media fra loro non vuol dire niente — un sistema al 96% che sbaglia sistematicamente la quantità è inutile, uno all'88% che sbaglia solo la data di consegna è già in produzione.

Il metodo è noioso e non ha alternative: si prende un campione di documenti reali, si estrae, e si confronta con quello che una persona ha letto sugli stessi documenti. Da lì escono due numeri per campo — quante volte il sistema risponde, e quante volte risponde giusto — e si decide quali campi vanno in automatico e quali restano in verifica umana. Si parte da pochi campi sicuri e si allarga con lo storico, non il contrario.

Cosa fare dei casi che il modello non chiude

Nessun sistema chiude il 100%, e uno che dichiara di farlo sta nascondendo qualcosa in una coda che nessuno guarda.

Il valore sta nella forma dell'eccezione. «Documento non elaborato» non serve a niente. «Riga 7: quantità illeggibile, il resto del documento è a posto» è una cosa che una persona chiude in venti secondi guardando l'originale — e quel documento contribuisce comunque a tutte le altre sei righe.

La regola che seguiamo è che un'eccezione deve dire cosa manca e su quale riga, e deve avere un posto e un nome. Se la coda non ha un responsabile, dopo tre mesi qualcuno la svuota di corsa e siamo tornati al punto di partenza — con in più una licenza da pagare.

Quando non conviene

Quando i documenti sono già dati: se il ciclo è tutto su fattura elettronica e ordini fatti a sistema, non c'è niente da leggere e il problema è un altro.

Quando il volume è basso e i fornitori sono pochi: con sei fornitori che mandano sempre lo stesso formato, il tempo di lettura a mano è già poco e il margine è sottile.

Quando i documenti non vengono archiviati. Se il DDT resta nel raccoglitore in magazzino o su WhatsApp, il primo problema da risolvere non è leggerlo: è averlo.

Domande frequenti

Le domande che tornano

Abbiamo già un OCR nel documentale. Non basta quello?
Basta finché i documenti sono strutturati e sempre uguali: una fattura elettronica non ha bisogno di essere letta, è già dati. Il punto in cui l'OCR del documentale si ferma è il documento di trasporto scansionato, dove non serve riconoscere i caratteri ma capire che quella tabella ha una riga per articolo e che la colonna a destra è la quantità. Se oggi qualcuno ricontrolla a mano quello che l'OCR ha estratto, l'OCR non sta facendo il lavoro: lo sta spostando.
Quanto deve essere accurato per andare in produzione?
La domanda giusta non è la percentuale, è cosa succede all'errore. Un campo sbagliato che finisce in una coda di eccezioni costa trenta secondi; un campo sbagliato che entra in una registrazione costa una fattura pagata male. Noi misuriamo su un campione di documenti veri dell'azienda, campo per campo, e mandiamo in produzione solo i campi che stanno sopra la soglia — gli altri restano in verifica umana finché non ci arrivano anche loro.
I documenti escono dall'azienda?
È una scelta che si fa prima e si mette per iscritto, non una conseguenza di quale servizio era più comodo da chiamare. L'estrazione può girare su macchine vostre quando i documenti sono sensibili o quando il cliente lo chiede; in altri casi il cloud costa molto meno e non tocca niente di riservato. Quello che non facciamo è deciderlo dopo.
Cosa succede quando un fornitore cambia il modulo?
Con l'OCR a maschere si rompe tutto e qualcuno se ne accorge dalle anomalie in coda. Con un modello che legge la struttura del documento invece delle coordinate, un layout nuovo di solito passa senza che nessuno tocchi niente — ed è il motivo principale per cui abbiamo smesso di usare le maschere.

In questa pagina

  • Cosa fa un OCR, e cosa gli si chiede
  • I quattro casi che rompono tutto
  • Leggere il documento invece di riconoscerne i caratteri
  • Come si misura l'accuratezza prima della produzione
  • Cosa fare dei casi che il modello non chiude
  • Quando non conviene

Questa pagina è per te se

Hai un problema che ti costa ore e non sai ancora con quale software si risolve.

Gestionali
Adiuto
Aggiornata
2 settembre 2026

Da qui si continua

  • Processo

    Il riscontro a tre vie: dove si rompe davvero in una PMI

    Non la definizione da manuale: i cinque punti in cui il match fra ordine, DDT e fattura salta, e cosa è successo quando li abbiamo chiusi tutti in un'azienda da 12.000 documenti l'anno.

    Apri
  • Processo

    Integrare l'AI in un gestionale che l'azienda usa già

    Non si sostituisce il gestionale: ci si attacca sopra. Dove si aggancia davvero un'automazione, cosa non si tocca mai, e le tre domande da farsi prima di iniziare.

    Apri
  • Sistema

    Il ciclo passivo end-to-end dentro Adiuto

    Dall'arrivo del documento alla registrazione: cosa copre Adiuto di suo, dove finisce il suo perimetro, e cosa serve aggiungere perché il ciclo si chiuda senza che tre persone incrocino documenti a mano.

    Apri
  • Case study

    189 ore al mese recuperate sul riscontro fatture–DDT–ordini

    Scopri come Co.Mas (settore gru) ha eliminato l'inserimento manuale dei dati e automatizzato il 3-way match tra ordini, DDT e fatture.

    Apri

Una domanda che questa pagina non ha risolto?

Raccontaci il processo vostro: rispondiamo entro un giorno lavorativo, anche quando la risposta è che non vi conviene farlo.

Parliamone

Oppure guarda i progetti che abbiamo consegnato o l'adeguamento all'AI Act.

    Contatti

    Che processo vuoi togliere di mezzo?

    Raccontaci l'attività che vi ruba più tempo: ti rispondiamo entro 1 giorno lavorativo con un primo parere onesto, anche se la risposta è "non vi serve".

    ScriviciVieni a conoscerci

    Email

    [email protected]

    Telefono

    +39 (0423) 1858206

    Sede

    Via Contea 60, 31044 Montebelluna (TV)

    Automazioni AI

    • Automazioni di processo
    • Software su misura
    • Consulenza strategica AI
    • Formazione avanzata
    • Infrastrutture AI dedicate
    • Agenti AI
    • Software house a Treviso
    • Software house a Padova
    • Software house a Vicenza
    • Case study
    • Recensioni
    • Parliamone

    Adeguamento AI Act

    • Sei a rischio sanzioni?
    • Prezzi e calcolatore
    • Liberi professionisti

    Azienda

    • Chi siamo
    • Eventi
    • Risorse
    • Posizioni aperte
    • Contatti
    • Politiche sistema di gestione
    Certificazione ISO 9001 - Sistema Management Services
    Privacy PolicyTermini e condizioniCookie PolicyDPAAddendum AI Act

    © 2026 Stabilidea Srl - Sede operativa: Via Contea 60, 31044 Montebelluna - P.IVA 05389850263
    REA 440242 - Cap.sociale € 14.000,00 i.v.