Un flusso di elaborazione documenti in locale, senza costi API a pagina

La regola di progetto: prima il metodo affidabile più semplice

Costruiamo a strati, dal più prevedibile al più flessibile:

1. leggere il testo già incorporato nel file;
2. usare l'OCR solo per le pagine che sono solo immagine;
3. estrarre i campi con delle regole;
4. facoltativamente, chiedere a un modello di IA i campi che le regole non hanno trovato.

Ogni strato gestisce solo ciò che lo strato precedente non è riuscito a gestire. Così è più facile capire dove nascono costi ed errori.

Passo 1: leggere il livello di testo incorporato

Molte fatture prodotte da un gestionale sono PDF con un livello di testo incorporato. pdfplumber, una libreria Python open source, estrae quel testo senza OCR. Funziona meglio sui PDF generati da software. Non garantisce campi corretti: l'analisi dell'impaginazione può comunque fallire, ed è per questo che esistono i controlli successivi. Quale quota delle fatture di un certo ufficio abbia un livello di testo utilizzabile va misurato sui suoi documenti; non abbiamo dati in merito.

Passo 2: OCR per le pagine solo immagine, sul tuo computer

Le scansioni che sono solo immagine non hanno un livello di testo, quindi serve l'OCR (riconoscimento ottico dei caratteri). Alcuni PDF scansionati contengono già un livello di testo OCR creato dallo scanner. Usiamo RapidOCR su ONNX Runtime, che esegue il modello di riconoscimento sul tuo processore, senza account cloud e senza costi a pagina.

La scelta del modello è stata importante. Il nostro primo modello OCR non aveva "€" né "£" tra i caratteri riconosciuti e perdeva gli spazi tra le parole. Un modello per l'alfabeto latino (PP-OCRv5 Latin) ha risolto il problema; un altro candidato leggeva "€" come "£", quindi non l'abbiamo usato. Abbiamo anche fatto in modo che la ricostruzione delle righe segua l'inclinazione della pagina, recuperando la maggior parte delle righe sulle nostre scansioni sintetiche storte.

Abbiamo provato scansioni sintetiche, pulite e degradate. Le foto dal telefono non sono state provate. Nelle nostre esecuzioni, i risultati dell'OCR sulle scansioni degradate variavano leggermente tra Windows e Linux. Durante la verifica di fattibilità possiamo fare una prova sul computer che intendi usare.

Passo 3: regole, poi controlli

I campi vengono estratti con regole sulle etichette e schemi per fatture in italiano, inglese, tedesco e francese: "Totale", "Total", "Gesamtbetrag", formati europei di numeri e date, schemi delle partite IVA. Le regole sono prevedibili e facili da testare.

Poi arrivano i controlli: imponibile + IVA = totale, le righe tornano, date plausibili, formato valido della partita IVA. Un controllo fallito mette il documento in un elenco "Da controllare". I controlli segnalano alcune incoerenze; superarli non dimostra che un documento sia corretto. (Approfondimento in Perché il nostro strumento per le fatture chiede invece di indovinare.)

Passo 4: il passaggio di IA facoltativo, e cosa invia

Per i campi che le regole non hanno trovato, doc2data ha un passaggio di IA facoltativo, spento di default. Ecco con chiarezza cosa fa se lo attivi:

• Opzione cloud: chiede i campi mancanti, ma la richiesta include fino ai primi 6.000 caratteri del testo estratto dalla fattura, inviati a un fornitore compatibile con OpenAI scelto da te, con la tua chiave API. Quel fornitore riceve il testo e può farlo pagare.
• Opzione locale (Ollama): Il passaggio facoltativo con Ollama gira sullo stesso computer (localhost); nulla lascia il computer.
• Ogni campo compilato dall'IA viene segnalato per il controllo.
• Entrambe le opzioni sono realizzate e coperte da test unitari con un backend simulato; nessuna è ancora stata provata con un modello reale.

Requisiti e limiti

• Nessun costo API a pagina nella modalità predefinita. L'elaborazione locale usa comunque hardware ed elettricità, più un'installazione una tantum e il tempo di qualcuno sull'elenco da controllare. Il passaggio cloud facoltativo può avere un costo presso il tuo fornitore.
• Risultati sintetici (2 ottobre 2026): 0 errori su 189, 191 e 178 campi in 3 set puliti da 16 documenti; 131 campi corretti su 141 (92,9%) e 127 su 139 (91,4%) su scansioni volutamente degradate da 12 documenti ciascuna. Le prestazioni su documenti reali di fornitori non sono state misurate e possono essere diverse, anche più basse.
• Non ancora gestiti: più aliquote IVA nella stessa fattura, tabelle su più pagine, note di credito, descrizioni che vanno a capo su due righe. Le partite IVA sono controllate solo nel formato.

Impacchettare per la ripetibilità

Impacchettiamo doc2data con Docker. L'immagine contiene Python, le versioni indicate delle librerie e il modello OCR, e i 21 test automatici vengono eseguiti durante la build (tutti superati il 2 ottobre 2026, build al commit 708168d). Per ripetere esattamente un'esecuzione bisogna conservare l'immagine provata; ricostruirla più avanti può cambiare l'immagine di base e i pacchetti di sistema. Docker migliora la ripetibilità, ma non garantisce un comportamento identico su ogni computer o per sempre. Finora l'immagine è stata costruita ed eseguita solo su Windows 11 con Docker Desktop (x86-64). Le altre piattaforme vanno verificate a parte, e conserviamo le versioni dell'immagine e delle dipendenze per poter ripetere un'esecuzione.

Quando può valere la pena valutare un servizio in cloud

Il flusso locale non è sempre la scelta giusta. I servizi di elaborazione documenti in cloud sono candidati da valutare se:

• gestisci volumi molto grandi e vari;
• devi leggere scrittura a mano o fotografie difficili;
• non hai un computer su cui far girare il flusso, o nessuno che lo mantenga.

Non abbiamo confrontato alcun servizio in cloud con doc2data, quindi non facciamo confronti di precisione o velocità.

I tuoi documenti si possono elaborare in locale?

Inviaci 3 esempi, senza dati sensibili, per una verifica di fattibilità gratuita. Inviare esempi significa farli viaggiare via email; vedi la pagina Privacy. Verifica di fattibilità gratuita

Fonti

• Report di valutazione e codice di doc2data (flusso e passaggio di IA, incluso il limite di 6.000 caratteri), commit e4bfc58, 2 ottobre 2026; ricontrollati alla 708168d. Risultati pubblicati con denominatori e limiti: evidenze dei test di doc2data.
• Verifica dei fatti di company-engineer, 3 ottobre 2026 (interna).
• pdfplumber, https://github.com/jsvine/pdfplumber (consultato il 3 ottobre 2026).
• RapidOCR, https://github.com/RapidAI/RapidOCR (consultato il 3 ottobre 2026).
• ONNX Runtime, https://onnxruntime.ai/ (consultato il 3 ottobre 2026).
• Documentazione Docker, "Multi-platform builds", https://docs.docker.com/build/building/multi-platform/ (consultata il 3 ottobre 2026).
• Prezzi di Amazon Textract, https://aws.amazon.com/textract/pricing/ (consultato il 3 ottobre 2026), solo come esempio di prezzo a pagina.