Perché il nostro strumento per le fatture chiede invece di indovinare

Un tipo di errore per cui vale la pena progettare

In strumenti come questo, a leggere sono soprattutto due componenti:

• l'OCR (riconoscimento ottico dei caratteri), che trasforma una scansione in testo;
• facoltativamente, i modelli linguistici di IA, a cui si possono chiedere i campi che le regole non hanno trovato.

Entrambi possono produrre risultati dall'aspetto pulito ma sbagliati. Un "8" sfocato può essere letto come "3"; un totale può essere preso dalla riga del subtotale; il simbolo della valuta può sparire. Se nulla controlla il risultato, l'errore può restare nel foglio di calcolo finché qualcuno non riconcilia i conti.

Quindi una domanda utile per qualsiasi strumento di estrazione non è solo "quanto è preciso?" ma anche "cosa succede quando sbaglia?". Come confronto ipotetico: uno strumento che segnala i documenti dubbi può far risparmiare più tempo di controllo di uno leggermente più preciso che non segnala nulla, perché sai dove guardare.

I controlli che le fatture rendono possibili

I numeri di una fattura sono legati tra loro, e doc2data usa queste relazioni come controlli su ogni documento:

• Imponibile + IVA = totale.
• IVA = aliquota × imponibile, salvo arrotondamenti. Questo controllo presuppone una fattura supportata con una sola aliquota IVA; più aliquote nella stessa fattura non sono ancora gestite.
• Le righe sommano all'imponibile (o al totale lordo negli scontrini).
• Quantità × prezzo unitario = importo della riga per ogni riga.
• Le date sono plausibili e le partite IVA rispettano il formato del loro paese.
• I campi obbligatori ci sono. Una valuta mancante resta vuota; non si presume mai che sia l'euro.

Quando un controllo fallisce, il documento finisce in un foglio "Da controllare" con il motivo. Nulla viene corretto in silenzio. Un'incongruenza può nascere dall'estrazione o dalla fattura stessa: un motivo in più perché la guardi una persona. E vale anche il contrario: superare questi controlli non dimostra che ogni campo sia corretto.

Se un campo è stato compilato dal passaggio di IA facoltativo, viene segnalato anche quello. Se attivi l'opzione cloud, invia fino ai primi 6.000 caratteri del testo estratto a un fornitore compatibile con OpenAI scelto da te, usando la tua chiave API. Il passaggio facoltativo con Ollama gira sullo stesso computer (localhost); nulla lascia il computer. Entrambe sono realizzate e coperte da test unitari, non ancora provate con un modello reale.

Cosa abbiamo misurato, su documenti sintetici

Misurato il 2 ottobre 2026 nella nostra build Docker, su documenti generati da un nostro script (aziende, indirizzi e partite IVA inventati):

• 3 set puliti da 16 documenti ciascuno: 0 errori su 189 campi, 0 su 191 e 0 su 178 (sintetici). Con 16 documenti per set, questo non giustifica alcuna soglia di precisione per fatture reali.
• Scansioni volutamente degradate (110 dpi, inclinazione di 1,5°, sfocatura, forte compressione), 12 documenti per set: 131 campi su 141 (92,9%, sintetici) sul set usato durante lo sviluppo di una correzione, e 127 su 139 (91,4%, sintetici) su un set che, secondo il registro dello sviluppatore, non è stato guardato durante quella correzione. Questi piccoli set sintetici non stabiliscono una differenza affidabile nelle prestazioni generali; non è stata eseguita un'analisi che tenga conto del raggruppamento dei campi per documento.
• Ogni set conteneva una fattura con un errore di calcolo voluto. È stata segnalata in ogni set.
• Sui due set degradati sono state segnalate anche 6 fatture altrimenti valide su 11 e 7 su 11, soprattutto perché un totale non era leggibile. Sono falsi allarmi, e li accettiamo come prezzo per non far passare in silenzio un numero sbagliato.

Il set pulito di verifica usa gli stessi formati con valori nuovi, e il terzo set pulito faceva parte dei test automatici per tutto lo sviluppo. Quindi nessuno di questi set prova formati mai visti.

Cosa i controlli non possono scoprire

L'aritmetica scopre alcuni numeri sbagliati, non le lettere sbagliate. Su un set degradato, un documento ha superato tutti i controlli con un errore nel nome del fornitore: "S.n.C." invece di "S.n.c.". Lo chiamiamo errore silenzioso:

• 0 errori silenziosi sui tre set puliti (sintetici);
• 1 sul set degradato di sviluppo (sintetico);
• 0 sul set degradato di verifica (sintetico).

Un errore di un solo carattere in un nome o in una partita IVA non si scopre con le somme. doc2data controlla le partite IVA solo nel formato, non con la cifra di controllo né sul registro europeo VIES. Per quei campi le difese sono un OCR migliore, un controllo sul registro dove opportuno e controlli a campione da parte di una persona.

Cosa questi numeri non dicono

Le fatture sintetiche vengono da 2 formati più uno scontrino, e le regole sono state scritte conoscendoli. Zero errori sui set sintetici puliti dimostra che il flusso funziona dall'inizio alla fine su quei formati. Le prestazioni su documenti reali di fornitori non sono state misurate e possono essere diverse, anche più basse. Altri formati di fornitori e scansioni scadenti reali non sono stati provati; le scansioni sintetiche degradate sono state provate come descritto sopra. Anche tabelle su più pagine, sconti e più aliquote IVA non sono stati provati. Per questo un progetto partirebbe misurando sugli esempi del cliente.

Tre domande da fare a qualsiasi automazione dei documenti

1. Come viene misurata la precisione, e su quali documenti? Sintetici, pubblici o tuoi? I documenti di prova sono stati usati mentre si costruiva lo strumento?
2. Come ti mostra lo strumento dove potrebbe sbagliare? Cosa fa finire un documento nell'elenco da controllare?
3. Quali errori non riesce a scoprire? Un fornitore attento sa rispondere.

Provalo sulle tue fatture

Inviaci 3 documenti di esempio, senza dati sensibili, per una verifica di fattibilità gratuita. Tre esempi danno un primo sguardo, non una stima affidabile della precisione. Verifica di fattibilità gratuita

Fonti

• Report di valutazione di doc2data, cinque set sintetici con conteggi dei campi, segnalazioni ed errori silenziosi; generati il 2 ottobre 2026 (commit e4bfc58), ricontrollati da company-engineer lo stesso giorno alla revisione 708168d con risultati identici. Risultati pubblicati con denominatori e limiti: evidenze dei test di doc2data.
• Verifica dei fatti di company-engineer, 3 ottobre 2026 (interna).