Cos'è l'estrazione dati da fatture e DDT?

È la conversione del documento del fornitore, che sia PDF, scansione, CSV o Excel, in righe strutturate importabili da un sistema. La forma d'arrivo è sempre la stessa: una testata con fornitore, numero documento, data, valuta e totali, più le righe articolo che dicono cosa è stato addebitato, in che quantità e a che prezzo.

Qual è il metodo migliore per estrarre dati dalle fatture nel 2026?

L'estrazione con LLM contro uno schema JSON definito è il metodo che regge meglio la varietà reale dei fornitori. A differenza dell'OCR a template non richiede configurazione per fornitore, i cambi di layout non lo rompono e i nomi colonna si risolvono dal contesto. Il rovescio è che fallisce con educazione: numeri sbagliati dentro JSON valido, quindi la validazione aritmetica è obbligatoria.

Come si validano i dati estratti prima dell'import?

Verificando le affermazioni l'una contro l'altra con l'aritmetica. Controlla i conti di riga (quantità per costo unitario uguale totale riga), confronta la somma delle righe con i totali dichiarati, valida il check digit degli EAN-13 e incrocia le quantità di fattura, DDT e ordine. Le discrepanze passano da una revisione umana prima che qualcosa tocchi il magazzino.

L'AI riesce a estrarre dati da PDF scansionati o di bassa qualità?

Sì: scansioni e PDF fotografati vanno a un modello multimodale come immagini, mentre i PDF nativi con un livello testo usabile si estraggono direttamente dal testo. Sulle scansioni davvero brutte resta un tasso di errore residuo: progetta assumendo un'estrazione al 95 per cento con la validazione che prende il resto, e ai fornitori recidivi chiedi l'export CSV.

Estrazione Dati da Fatture e DDT con OCR e AI

TL;DR

L'estrazione dati da fatture e DDT converte il documento del fornitore (PDF, scansione, CSV o Excel) in righe strutturate importabili: codici, quantità, costi unitari, totali. Nel 2026 il metodo che regge la varietà reale dei fornitori è l'estrazione con LLM contro uno schema JSON definito, seguita da validazione aritmetica. Mai far entrare righe estratte in magazzino senza un controllo dei totali e una revisione visibile a un umano.

Estrarre i dati da una fattura o da un DDT significa trasformare il documento che il fornitore manda in righe leggibili da una macchina. La forma d'arrivo è sempre la stessa: una testata (fornitore, numero documento, data, valuta, totali) e le righe articolo (cosa è stato addebitato, in che quantità, a che prezzo). Quello che varia selvaggiamente è l'ingresso. Lo stesso distributore può mandare un CSV pulito una settimana e un PDF scansionato di tre pagine con celle unite quella dopo.

Una nota italiana prima di cominciare: la fattura elettronica via SDI è già XML strutturato, e se il tuo fornitore è italiano quella parte del problema è risolta alla fonte. Ma i documenti che guidano il carico merce (DDT, packing list, conferme d'ordine, listini) e le fatture dei fornitori esteri restano PDF, scansioni e fogli Excel. È lì che l'estrazione serve davvero.

Questo tutorial copre i metodi disponibili nel 2026, il formato JSON che regge il lavoro per righe, e la validazione che separa una pipeline usabile da un pericolo. Gli esempi vengono dall'ingrosso moda, dove le righe portano varianti taglia-colore con barcode EAN, ma la struttura vale per qualsiasi dominio a righe.

I Tre Metodi di Estrazione

OCR a template. L'OCR fatture classico: definisci zone o ancore per ogni layout di fornitore, estrai il testo per posizione. Funziona quando ricevi migliaia di fatture identiche da pochi mittenti. Fallisce esattamente dove vive l'ingrosso moda: decine di fornitori, ognuno con un layout diverso che cambia senza preavviso. Ogni layout nuovo è lavoro di configurazione.

Parsing a regole per i file strutturati. CSV ed export Excel non hanno bisogno di OCR, ma di interpretazione sì: quale colonna è l'EAN, se "colore" e "col." sono lo stesso campo, cosa fare con le righe di subtotale in mezzo alla tabella. I parser scritti a mano per fornitore si fossilizzano in fretta. Utile come scorciatoia, non come strategia.

Estrazione LLM contro uno schema. Un modello multimodale legge il documento (PDF nativo, scansione o testo di foglio di calcolo) e restituisce JSON conforme a uno schema che definisci tu. Niente template per fornitore. I cambi di layout non lo rompono. Le varianti dei nomi colonna ("qty", "q.tà", "pz") si risolvono dal contesto. È il metodo che finalmente regge la varietà dei documenti veri, ed è come Agilo estrae ogni tipo di documento che ingerisce.

Il problema dell'estrazione LLM è che fallisce con educazione: numeri sbagliati arrivano dentro JSON perfettamente valido. Questo sposta lo sforzo ingegneristico dal parsing alla validazione, che è lo scambio giusto perché la validazione è aritmetica verificabile.

Classifica Prima di Estrarre

Una pipeline che riceve "quello che il fornitore ha mandato" non può assumere che ogni file sia una fattura. Lo stesso giro di allegati mescola tipicamente una conferma d'ordine, un DDT, un listino e la fattura, e ognuno risponde a una domanda diversa. La conferma d'ordine porta quantità ordinate e costi concordati; il DDT porta quantità spedite; il listino non porta quantità affatto, solo l'assortimento e i prezzi.

La classificazione è quindi la prima chiamata di estrazione: dato il documento, restituisci tipo e ruolo. È un compito economico e affidabile per un modello, e determina quale schema usa l'estrazione vera e come le righe risultanti possono toccare il magazzino. Le righe di un listino non devono mai creare stock; le quantità di un ordine sono aspettative, non arrivi. Saltare la classificazione ed estrarre tutto "come fattura" è il modo in cui un listino diventa 4.000 pezzi fantasma.

Il Formato JSON che Funziona

Chiedi la struttura più piccola che risponde alla domanda di business, non una trascrizione della pagina. Per documenti a righe:

{
  "tipoDocumento": "fattura",
  "fornitore": "Example Fashion Srl",
  "numeroDocumento": "2026/0417",
  "dataDocumento": "2026-06-11",
  "valuta": "EUR",
  "righe": [
    {
      "sku": "KMS26167",
      "ean": "8051234560011",
      "descrizione": "Sovracamicia Lana Boxy",
      "colore": "Cammello",
      "taglia": "M",
      "quantita": 4,
      "costoUnitario": 62.5,
      "totaleRiga": 250.0
    }
  ],
  "pezziDichiarati": 96,
  "totaleDichiarato": 6120.0
}

Scelte di progettazione che ripagano dopo:

Chiedi totaleRiga e i totali dichiarati del documento anche se sono ridondanti. La ridondanza è ciò che rende possibile la validazione.
Tieni gli identificativi separati (sku e ean): i fornitori li usano in modo incoerente e abbinerai sull'uno o sull'altro.
Estrai gli attributi (colore, taglia) come li scrive il documento. La normalizzazione ("IT 50" in "50") è un passo deterministico separato; mischiarla nell'estrazione nasconde gli errori.
Uno schema per tipo di documento. Fattura, conferma d'ordine e DDT condividono la struttura delle righe ma differiscono nella semantica di testata: classifica prima, poi estrai con lo schema giusto.

Valida con l'Aritmetica, Non a Occhio

Il JSON estratto è un'affermazione. Prima che tocchi il magazzino, verifica le affermazioni l'una contro l'altra:

Conti di riga: quantita × costoUnitario ≈ totaleRiga per ogni riga, con tolleranza di arrotondamento.
Conti di documento: somma delle quantità contro pezziDichiarati; somma dei totali riga contro totaleDichiarato.
Sanità degli identificativi: il check digit dell'EAN-13 deve tornare. Una cifra trasposta fallisce il checksum e viene presa gratis.
Controlli incrociati: quantità in fattura contro quantità sul DDT contro quantità ordinate, abbinate per EAN.

Il punto 4 è dove l'estrazione diventa operativamente preziosa. Una spedizione che fattura 100 pezzi mentre il DDT ne dichiara 96 è una contestazione reale che vale la pena scoprire il giorno zero. La pipeline di import di Agilo esegue esattamente questo confronto ed emette anomalie (corto consegnato, ecceduto, spedito non ordinato, totali che non tornano) che un umano risolve prima che lo stock si muova; il lato ricevimento di quel flusso è descritto in Gestione Magazzino Abbigliamento: Dal DDT allo Scaffale.

Un totale che non torna non è un fallimento dell'estrazione; è la pipeline che fa il suo lavoro. Metà delle volte il modello ha letto bene e sono i documenti a essere davvero in disaccordo. La revisione esiste per distinguere i due casi.

Scansioni e PDF di Bassa Qualità

I PDF nativi portano un livello testo che vale la pena controllare per primo: se ha densità ragionevole, estrai dal testo e salta del tutto l'elaborazione immagini. Scansioni e PDF fotografati vanno al modello multimodale come immagini.

Soglie pratiche dall'uso in produzione: tratta una pagina PDF con meno di un paio di centinaia di caratteri estraibili come una scansione, e metti un tetto alle dimensioni dei file perché un DDT fotografato da 40MB non blocchi la coda. Spezza i documenti lunghi in blocchi con righe sovrapposte, così le righe di tabella tagliate dal cambio pagina non si perdono tra un blocco e l'altro.

Aspettati un tasso di errore residuo sulle scansioni davvero brutte, qualunque sia il modello. L'assunzione di progetto deve essere "l'estrazione è al 95 per cento, la validazione prende il resto", mai "l'estrazione è perfetta". E quando le scansioni di un fornitore falliscono ripetutamente, la soluzione più economica è a monte: chiedigli l'export CSV che il suo gestionale già produce.

Misura l'Accuratezza sui Tuoi Documenti

I benchmark dei fornitori di tecnologia non ti dicono niente sui tuoi documenti. La misura utile si fa una volta e costa poco: prendi venti documenti rappresentativi (i tuoi fornitori peggiori inclusi), verificali a mano una volta, e calcola il tasso di errore per campo. Scoprirai quasi sempre che quantità e totali sono affidabili, che le taglie si confondono dove il fornitore usa sistemi misti, e che i colori scritti in abbreviazioni proprietarie sono il campo più fragile. Quella mappa decide dove la validazione deve essere severa e dove basta il campionamento, ed è anche l'argomento con cui rispondere a chi in azienda chiede "ma possiamo fidarci?": non con una promessa, con un numero misurato sui vostri documenti.

Dalle Righe Estratte al Magazzino

L'estrazione è la prima metà. La seconda è abbinare le righe al tuo catalogo:

EAN che corrisponde a una variante esistente: aggancia, porta il costo.
EAN sconosciuto, codice articolo noto: probabile variante nuova di un prodotto esistente (una taglia o un colore in più).
Entrambi sconosciuti: crea prodotto e varianti, segnalati per revisione.

Questo abbinamento è il motivo per cui l'estrazione va dentro il gestionale e non in uno strumento a parte che ti manda un foglio Excel via email. L'output di una buona pipeline non è JSON; sono righe di catalogo in bozza con uno stato per riga che un umano approva. Il modello dati in cui atterrano è descritto in Gestionale Abbigliamento: Guida alla Scelta.

Costruire o Comprare nel 2026

Costruire una pipeline solida significa: classificazione dei documenti, schemi per tipo, chiamata di estrazione multimodale, validazione aritmetica, riconciliazione tra documenti, abbinamento a catalogo e un'interfaccia di revisione. Ogni pezzo è fattibile; l'integrazione è il progetto.

Comprare ha senso quando l'estrazione è un mezzo e non il tuo prodotto. Per le aziende moda è il motivo per cui abbiamo costruito la pipeline direttamente dentro Agilo: il risultato non è JSON estratto ma un carico verificato pronto a chiudersi in magazzino.

Qualunque strada tu scelga, tienila alla stessa asticella: documenti veri in ingresso, righe di variante validate in uscita, ogni discrepanza visibile, niente che entra in magazzino senza revisione.