Estrazione dati fatture AI: la precisione reale in produzione

Chi valuta oggi un progetto di estrazione dati fatture AI si trova davanti a un mercato che promette tutto: precisione quasi perfetta, nessun template da configurare, sistema attivo in un pomeriggio. Poi arriva il pilota, si caricano trecento fatture vere prese dalla posta dell’amministrazione, e i numeri non tornano. Non perché i fornitori mentano, ma perché il numero che pubblicano e il numero che conta al vostro budget non sono lo stesso numero. In mezzo c’è una moltiplicazione che nessuno scrive nei materiali commerciali, e ci sono i documenti italiani, che hanno una loro anatomia particolare. Questa è una guida operativa a entrambe le cose: come si scelgono modelli e pipeline, e perché la distanza fra un proof of concept che funziona e una produzione che regge si copre con un lavoro di affiancamento, non con una licenza software.

In questo articolo scoprirai:

• Perché il 98% di precisione dichiarato non è il 98% che vedrete in produzione
• Quale pipeline conviene per estrarre dati da fatture: OCR a template, modelli di layout o vision LLM
• Fattura elettronica italiana: perché l’XML FatturaPA non risolve il problema (e a volte lo crea)
• Gli errori tipici che i parser generici commettono sui documenti italiani
• Come si valuta davvero un fornitore: il pilota sul vostro corpus, non sulla demo

Perché il 98% di precisione dichiarato non è il 98% che vedrete in produzione

La prima cosa da fare è smettere di parlare di precisione al singolare. Chi lavora seriamente su document processing distingue almeno cinque metriche diverse, e i fornitori tendono a citare quella che li fa apparire meglio. Artsyl le separa così: character accuracy (l’OCR ha letto correttamente i caratteri stampati), field accuracy (il valore è stato assegnato al campo giusto), line-item accuracy (descrizioni, quantità e prezzi sono rimasti associati alla riga corretta), document accuracy (ogni campo richiesto su quella fattura supera la soglia di qualità) e touchless rate, cioè la percentuale di fatture che completano acquisizione, validazione e instradamento senza alcun intervento manuale.

La matematica che trasforma il 98% per campo in un 60% per documento

Ecco il conto che cambia tutto. La precisione dichiarata è quasi sempre per campo. Ma una fattura non è un campo: è un insieme di campi che devono essere corretti tutti insieme perché il documento passi senza che qualcuno lo apra. Se un fornitore vi garantisce il 98% per campo e la vostra fattura tipo ha 25 valori da estrarre fra testata e riepilogo, la probabilità che l’intero documento sia corretto è 0,98²⁵, cioè circa il 60%. Quattro fatture su dieci finiranno sulla scrivania di un umano. Se invece contate anche le righe di dettaglio, dieci righe da cinque campi ciascuna fanno una sessantina di valori, quello stesso 98% per campo produce un documento corretto solo nel 30% dei casi.

L’unica metrica che potete portare in un business case

Per questo la metrica onesta è il touchless rate, o STP (straight-through processing): quante fatture non tocca nessuno. Nanonets, che sui numeri dei propri clienti è piuttosto esplicito, indica come obiettivo realistico un STP superiore all’80%, con casi documentati all’88%. È un dato molto più utile di una percentuale di precisione: si traduce direttamente in ore di lavoro, le stesse che si contano quando si valuta se automatizzare i processi ripetitivi del back-office. E siccome il risparmio si calcola sulle fatture che non passano dalle mani di nessuno, è anche l’unico numero che regge quando dovete presentare il progetto alla direzione. Chiedete il touchless rate, non l’accuratezza: se il fornitore non ve lo sa dire sul vostro corpus, non lo sa dire e basta.

Quale pipeline conviene per estrarre dati da fatture: OCR a template, modelli di layout o vision LLM

Le architetture disponibili oggi sono tre, e la differenza fra loro è misurabile. L’OCR a template, il vecchio approccio in cui si disegnano le zone del documento, regge finché i fornitori sono pochi e stabili: le stime di settore lo collocano intorno all’80-85% di precisione, e crolla al primo layout nuovo. I modelli di document understanding con analisi del layout (la famiglia LayoutLM, Docling e simili) leggono la geometria della pagina. I vision LLM, infine, guardano la pagina come immagine e restituiscono direttamente JSON strutturato.

I numeri di un confronto indipendente fra Docling e un estrattore LLM

Un lavoro pubblicato su arXiv da Sai Yashwant e colleghi (ottobre 2025) confronta le due famiglie su un dataset di 102 fatture PDF e JPEG, annotate manualmente, in inglese e tedesco, digitali e scansionate. Il risultato è netto: l’estrattore basato su LLM con output vincolato a schema arriva al 94% di accuratezza complessiva, la pipeline layout+OCR al 63%. Un limite del confronto va detto subito: gli autori non dichiarano il modello usato dietro l’estrattore, che descrivono solo come basato su utilità di estrazione strutturata, quindi quel 94% non è attribuibile a un modello specifico. Sulle righe di dettaglio il divario si allarga, 91% contro 58%, e gli errori di validazione matematica (i totali che non tornano) passano dal 5% al 20%. Il prezzo è il tempo: circa 30 secondi per pagina contro 10. Gli autori annotano anche dove si concentrano i fallimenti residui: fatture con scenari multi-aliquota complessi e tabelle annidate. Tenete a mente questo dettaglio, perché in Italia è la norma, non l’eccezione. Un secondo lavoro, sempre su arXiv, di Berghaus, Berger, Hillebrand, Cvejoski e Sifa, mette a confronto parsing visuale e parsing testuale sui dataset ICDAR-2019-SROIE, Donut invoices e INV-CDIP: segno che la questione “immagine o testo” è ancora aperta in letteratura, non risolta dal marketing.

Cosa vi danno davvero i servizi gestiti, limiti inclusi

Sui servizi pronti all’uso conviene leggere la documentazione primaria invece delle brochure. Il modello prebuilt-invoice di Azure Document Intelligence v4.0 dichiara supporto per 27 lingue, fino a 2.000 pagine per PDF e 500 MB sul tier a pagamento, ma pone un vincolo che sfugge sempre: l’altezza minima del testo estraibile è di 12 pixel su un’immagine 1024×768, cioè circa 8 punti a 150 dpi. Le scansioni a bassa risoluzione dei fornitori piccoli cadono sotto quella soglia. L’Invoice parser di Google Document AI supporta 12 lingue fra cui l’italiano, con righe di dettaglio complete, ma si ferma a 15 pagine in modalità sincrona e 200 in batch. Claude accetta PDF fino a 32 MB e 600 pagine per richiesta e non apre i file protetti da password. Sono vincoli banali sulla carta e letali in produzione, quando il flusso reale contiene allegati cifrati e fatture di 40 pagine.

Sul fronte dei modelli generalisti, Mistral ha mostrato di poter portare la ricerca agentica su documenti finanziari dal 27% all’86% di accuratezza, con un approccio diverso da quello dei parser specialistici.

Fattura elettronica italiana: perché l’XML FatturaPA non risolve il problema (e a volte lo crea)

Qui casca l’obiezione più frequente: in Italia le fatture sono già XML, quindi a cosa serve l’AI. È un’obiezione seria e va presa sul serio, ma è vera solo per metà. Il formato è pubblico e strutturato: gli schemi XSD in vigore sono FatturaPA e Fattura Ordinaria versione 1.2.3, Fattura Semplificata 1.0.2, con le specifiche tecniche di formato alla versione 1.4. Sul fronte del Sistema di Interscambio, le specifiche tecniche sono passate alla versione 1.8.4 a partire dal 15 maggio 2026, accompagnate dall’Elenco controlli versione 2.0. Chi costruisce un parser deve seguire questo versionamento, non fotografarlo una volta sola.

Cosa garantisce l’XML FatturaPA e cosa resta all’estrazione dati

Il punto è che l’XML garantisce la struttura sintattica, non l’informazione che vi serve. Il blocco DettaglioLinee contiene una descrizione in testo libero: dentro ci finisce di tutto, codici commessa, riferimenti d’ordine, centri di costo, matricole, scritti come pare al fornitore. Se il vostro obiettivo è riconciliare le righe con gli ordini o attribuire i costi a una commessa, l’XML vi consegna una stringa e il lavoro semantico resta interamente da fare. È esattamente il territorio dei modelli linguistici, ed è anche il motivo per cui la preparazione dei dati aziendali pesa più della scelta del modello.

Lo stesso documento, cinque impaginazioni: il problema dei fogli di stile

C’è poi un secondo effetto, meno noto. La stessa fattura XML viene visualizzata attraverso fogli di stile XSLT (versione 1.2.3 per l’ordinaria), ma ogni intermediario e ogni gestionale applica il proprio, o ne genera una cortesia PDF su misura. Risultato: lo stesso documento fiscale può arrivarvi in cinque impaginazioni diverse a seconda di chi lo ha emesso. Un modello addestrato sulla resa grafica di un provider sbaglia su quella di un altro. E soprattutto: tutto ciò vale per il ciclo passivo domestico. Fornitori esteri, note spese, DDT, contratti e ordini fuori SDI restano PDF puri, e sono spesso la quota di documenti che costa più tempo all’amministrazione.

Gli errori tipici che i parser generici commettono sui documenti italiani

Le pipeline generiche, addestrate in prevalenza su corpus anglosassoni, sbagliano in modo ricorrente e prevedibile su alcune specificità nostrane. Vale la pena elencarle, perché sono esattamente i casi da mettere nel piano di test prima di firmare qualsiasi contratto.

IVA, ritenuta e bollo: dove l’estrazione dati sbaglia sulle fatture italiane

Lo split payment e il reverse charge sono i due che producono i danni maggiori: il modello vede un’aliquota, calcola un totale e lo trova incoerente con l’imponibile, oppure, peggio, corregge il valore per farlo tornare. Ricordate il dato del paper arXiv: i fallimenti di consistenza si concentravano proprio sulle fatture con scenari multi-aliquota. Una fattura italiana con tre aliquote diverse, natura IVA N6.x e riepilogo per esigibilità è precisamente quel caso limite. La ritenuta d’acconto genera lo stesso errore al contrario: il netto a pagare non coincide con il totale documento, e un sistema che valida sull’uguaglianza rigida scarta fatture perfettamente corrette. Poi c’è il bollo virtuale, che compare come voce o come annotazione a seconda dell’emittente, e le date multiple, data documento, data operazione, scadenze del piano rateale, che i modelli tendono a confondere quando il layout le avvicina.

Formato numerico e controlli deterministici a valle dell’estrazione

Aggiungete il formato numerico: la virgola decimale e il punto delle migliaia sono invertiti rispetto alla convenzione anglosassone, e un modello incerto può leggere 1.250,00 come milleduecentocinquanta o come uno-virgola-venticinque. Su un singolo documento è un fastidio; su un flusso di ventimila fatture l’anno è un rischio contabile. Il rimedio non è un modello migliore: sono i controlli deterministici a valle dell’estrazione, somma delle righe uguale all’imponibile, imponibile per aliquota uguale al riepilogo, partita IVA validata con il carattere di controllo, fornitore riconosciuto in anagrafica. È la parte meno affascinante del progetto e quella che decide se funziona. Ed è anche il perimetro in cui vanno valutati gli obblighi dell’AI Act e la tracciabilità delle decisioni automatiche.

Come si valuta davvero un fornitore: il pilota sul vostro corpus, non sulla demo

Nessun benchmark pubblico vi dirà come si comporterà un sistema sulle vostre fatture, e la ragione è metodologica prima che commerciale. Un’analisi comparativa delle API di invoice OCR pubblicata nel marzo 2026 nota che le precisioni dichiarate dal settore oscillano fra l’85% e il 99% a livello di campo, con il 95% raggiunto sui soli campi di testata su documenti puliti, e che è sulle righe di dettaglio che le prestazioni dei fornitori divergono davvero. La stessa analisi è severa con i benchmark in circolazione: campioni di venti fatture, nessun intervallo di confidenza dichiarato, nessun test di significatività. Su venti documenti, la differenza fra il 95% e il 90% è una fattura. Vale per i benchmark come per i fornitori: i criteri con cui si sceglie un partner AI in Italia contano più della classifica del momento.

Come si costruisce un pilota di estrazione dati fatture sul corpus reale

Un pilota serio si costruisce diversamente. Prendete almeno 300-500 fatture reali estratte a caso da un trimestre intero, non le più belle, assicurandovi che il campione rispetti la distribuzione vera dei fornitori, incluse le code lunghe. Annotate a mano la verità di riferimento sui campi che vi servono davvero (spesso sono otto, non quaranta). Misurate separatamente testata e righe. Fissate soglie di confidenza diverse per campo: sull’IBAN e sul totale volete una soglia alta con revisione obbligatoria, sulla descrizione potete permettervi molto meno. Infine misurate il touchless rate a valle dei controlli, non l’accuratezza a monte. È il contenuto di un assessment del corpus reale, e si fa prima di scegliere la tecnologia, non dopo.

Costo per pagina e costo delle eccezioni nell’estrazione dati fatture

Sul costo, l’ordine di grandezza cambia di due zeri a seconda dell’architettura: sempre secondo quell’analisi comparativa, a 100.000 pagine al mese si va da circa 150 dollari con i servizi più economici a cifre nell’ordine delle decine di migliaia con altri. La latenza dichiarata va da 1 a 15 secondi per pagina. Sono numeri da verificare al momento della scelta, ma la lezione strutturale resta: il costo per pagina è quasi sempre trascurabile rispetto al costo delle eccezioni. Ottimizzare il primo mentre si ignora il secondo è l’errore classico, ed è una variante dello stesso problema per cui l’AI generativa spesso non genera ROI.

Dal POC alla produzione: cosa cambia con un onboarding dedicato

C’è una asimmetria che chiunque abbia portato in produzione un sistema documentale conosce: il proof of concept si fa in due settimane, la produzione si stabilizza in due-tre mesi. Non perché la tecnologia sia immatura, ma perché il lavoro vero è tutto nel mezzo, e nessun prodotto lo fa al posto vostro. Le ragioni per cui i progetti si arenano dopo il pilota sono ricorrenti e le abbiamo mappate altrove, parlando delle cause per cui gli agenti AI si bloccano dopo il POC.

Le tre gambe del lavoro fra pilota e produzione

Nell’estrazione documentale, il lavoro di mezzo ha tre gambe. La prima è la mappatura dei casi limite: si prende il corpus reale, si isolano i fornitori problematici, quello che manda scansioni storte, quello con la tabella su due pagine, quello estero con la valuta in dollari, e si scrive per ciascuno una regola o un’eccezione gestita. È un lavoro di settimane, si fa una volta, e determina il touchless rate finale più della scelta del modello. La seconda è l’integrazione con il gestionale: leggere una fattura è metà del problema, scriverla nel ciclo passivo con il conto corretto, la commessa giusta e il flusso di approvazione previsto è l’altra metà, e vive dentro il vostro ERP, non dentro l’AI. La terza è il tuning sul vostro corpus: prompt, schema di output, soglie e regole di validazione calibrati sui documenti che ricevete voi, non su una media di mercato.

Onboarding e affiancamento: dove si decide il touchless rate

È questa la distinzione fra vendere un prodotto e accompagnare un’adozione, ed è il modo in cui lavoriamo in MIMIR: un agente che legge fatture è la parte facile, mentre l’onboarding in azienda, assessment del corpus, definizione delle soglie, integrazione, formazione di chi gestirà le eccezioni, è il servizio che trasforma una demo convincente in un processo che regge il carico di un’amministrazione manifatturiera o farmaceutica. Nei primi 30 giorni si guarda quasi solo ai dati e ai casi limite: è lì che si decide quale sarà il touchless rate a regime.

Se in azienda avete un flusso di fatture o documenti che oggi passa dalle mani di qualcuno e volete capire quanta parte è realmente automatizzabile, con numeri sul vostro corpus, non su una media di mercato, potete parlarne con noi di MIMIR. Il primo passo è sempre lo stesso: guardare i vostri documenti veri e misurare quante fatture passerebbero senza intervento. È una conversazione che chiarisce le idee anche a chi decide poi di fare da sé.

Fonti:

• Confronto fra pipeline layout+OCR ed estrattore LLM su 102 fatture (arXiv, ottobre 2025)
• Berghaus et al., parsing visuale contro parsing testuale sui documenti (arXiv)
• Azure Document Intelligence, modello prebuilt-invoice v4.0: lingue e limiti
• Google Document AI, elenco dei processori e lingue dell’Invoice parser
• Claude, supporto PDF: limiti di dimensione e di pagine per richiesta
• Analisi comparativa delle API di invoice OCR: precisione, costi e latenza
• AIMultiple, panoramica sulle tecnologie di invoice OCR e sui loro limiti
• Artsyl, le cinque metriche di accuratezza nell’estrazione dati da fatture
• Nanonets, guida all’estrazione dati da fatture e obiettivi di straight-through processing