Il totale è facile. La tabella è la parte difficile
Quasi qualsiasi servizio OCR riesce a trovare un totale su una fattura — di solito è il numero più grande vicino a una parola come "Totale" o "Totale documento", e un riconoscimento di pattern arriva quasi sempre a quel risultato. Ricostruire correttamente la tabella di righe che sta dietro quel totale — ogni quantità, ogni prezzo unitario, nell'ordine giusto, senza unire o spezzare righe — è un problema strutturalmente più difficile, ed è quello che conta davvero per un gestionale.
Questa pagina descrive proprio quella capacità: leggere una tabella completa di righe, quante che siano e su quante pagine, e restituirla come un array pulito che la tua logica può usare direttamente.
Vale per qualsiasi documento che porti una tabella di righe, non solo per le fatture — uno scontrino con più articoli, un DDT con colli e quantità, una nota spese con più voci seguono tutti la stessa struttura sottostante, e vengono letti dalla stessa capacità descritta qui.
Perché conta soprattutto per le fatture fuori SDI
Una fattura elettronica italiana che passa dallo SDI arriva già come XML strutturato — le righe sono già dati, non un problema di lettura. Dove questa capacità conta davvero è esattamente ciò che non passa da quel canale: una fattura di un fornitore estero, uno scontrino con più articoli, un DDT con una tabella di colli e quantità. Qui la tabella di righe è ancora un'immagine di una pagina, e la sua qualità di lettura determina se quel documento diventa dato utilizzabile o resta un PDF allegato a una registrazione manuale.
Un gestionale la cui estrazione legge in modo affidabile solo i campi di intestazione e un totale sta, in pratica, ancora chiedendo a una persona di aprire ogni documento fuori SDI e ridigitare le righe prima che qualsiasi confronto automatico sia possibile — il che vanifica gran parte del senso di automatizzare quella parte del flusso.
Questo divario diventa più visibile man mano che un gestionale cresce, non meno. Un cliente con pochi fornitori esteri occasionali tollera bene una lettura solo a livello di intestazione — le poche eccezioni si gestiscono a mano senza troppo sforzo. Un cliente che importa regolarmente da una dozzina di fornitori diversi rende quella stessa lacuna un collo di bottiglia mensile ricorrente, non un'eccezione occasionale.
Cosa questa funzione non decide
Non esegue il confronto con un ordine o un DDT
Restituisce dati di riga puliti e tipizzati. Confrontarli con i tuoi record interni resta la logica del tuo gestionale.
Non decide la tolleranza di scostamento
Una piccola differenza di quantità o prezzo tra il documento e l'atteso è una scelta del tuo prodotto — l'estrazione ti dà solo numeri accurati da confrontare.
Non assegna la riga a un conto o a una categoria
Restituisce la descrizione così come stampata sul documento. Mapparla a un conto del piano contabile resta la logica di categorizzazione del tuo gestionale.
La forma del JSON delle righe
{
"line_items": [
{
"description": "Componente elettronico, riferimento X-410",
"quantity": 25,
"unit_price": 18.50,
"tax_rate": 22,
"amount": 462.50,
"confidence": 0.99
},
{
"description": "Spese di trasporto",
"quantity": 1,
"unit_price": 35.00,
"tax_rate": 22,
"amount": 35.00,
"confidence": 0.95
}
]
}Ogni riga porta gli stessi cinque campi più il proprio indice di affidabilità, che si tratti di una riga di prodotto normale o di una voce accessoria come il trasporto o uno sconto — la forma non cambia in base al tipo di riga.
Mantenere la forma uniforme su ogni tipo di riga conta per il tuo codice a valle — una funzione di matching che deve distinguere tra riga "normale" e riga "speciale" è più codice da scrivere e più codice che può sbagliare. Una forma coerente significa che un unico percorso di codice gestisce ogni riga dell'array, indipendentemente da cosa rappresenti sulla fattura stampata.
Cosa viene letto per ogni riga
| Campo | Tipo |
|---|---|
| description | Testo, inclusi i ritorni a capo dentro la riga |
| quantity | Numero decimale |
| unit_price | Numero decimale |
| tax_rate | Numero decimale (percentuale) |
| amount | Numero decimale, il totale di riga |
I numeri tornano come numeri JSON veri, non come stringhe nel formato "1.840,00" — la tua logica di calcolo li usa direttamente, indipendentemente dal paese o dal formato numerico del documento originale.
Questo vale anche per un fornitore estero che usa il punto come separatore decimale invece della virgola — la normalizzazione avviene prima che il numero raggiunga la tua applicazione, così il tuo codice non deve mai controllare da quale paese provenga il documento per interpretare correttamente un importo.
Tabelle su più pagine, nello specifico
Una tabella di righe che continua su una seconda o terza pagina è uno dei punti dove una pipeline di estrazione costruita in casa cede più spesso — l'intestazione della tabella non si ripete, lo spezzamento della pagina cade a metà riga, o l'analisi tratta ogni pagina come una tabella separata e restituisce due array scollegati invece di uno solo.
Qui il documento intero viene trattato come un'unica tabella logica a prescindere dai cambi di pagina — una riga visivamente divisa su un confine di pagina viene comunque letta e restituita come una sola riga, e l'array risultante conserva l'ordine originale sull'intero documento.
Un'intestazione di tabella che si ripete sulla pagina due e tre viene riconosciuta come tale, non contata per errore come una riga aggiuntiva — un errore che gonfierebbe il conteggio delle righe e manderebbe fuori quadratura qualsiasi controllo a valle che confronta quel conteggio con il numero di righe atteso da un ordine o un DDT.
Come funziona
Invia il documento a /extract
Una sola chiamata, il documento intero, qualsiasi numero di pagine.
La tabella viene individuata e ricostruita
Confini di colonna e di riga identificati dal layout proprio del documento, non da un modello fisso.
Ogni riga viene tipizzata e verificata
Quantità × prezzo unitario confrontato con l'importo di riga; la somma delle righe confrontata con il totale.
L'array torna insieme al resto del documento
line_items compare accanto ai campi di intestazione e ai totali nella stessa risposta.
Una fattura estera di trentotto righe
La fattura di un fornitore tedesco, fuori dal circuito SDI, ha 38 righe su due pagine, con l'intestazione della tabella che si ripete sulla seconda pagina e una riga divisa visivamente sul confine tra le due.
| Verifica | Risultato |
|---|---|
| Righe restituite | 38 su 38, nell'ordine originale |
| Riga sul confine di pagina | Letta come una sola riga, non spezzata in due |
| Somma delle righe contro il totale | Corrispondente, conferma che nessuna riga è persa o duplicata |
| Righe segnalate per revisione | 1, un prezzo unitario poco leggibile alla riga 22 |
L'unica riga segnalata non ha richiesto di rivedere le altre 37 — la coda di revisione del gestionale ha mostrato solo quella riga specifica, con il campo incerto evidenziato, mentre le restanti 37 righe sono confluite direttamente nella registrazione.
Per confronto, la stessa fattura elaborata con un approccio solo a livello di intestazione avrebbe restituito un unico totale, lasciando tutte le 38 righe da ridigitare a mano prima di qualsiasi confronto reale — la differenza tra due minuti di revisione e un'ora di inserimento manuale, su una sola fattura.
Layout di tabella che sa gestire
Un fornitore che omette la colonna IVA
Restituisce le colonne effettivamente presenti; tax_rate risulta assente invece di far fallire tutta l'estrazione.
Subtotali annidati dentro la tabella
Una riga di subtotale per categoria dentro la tabella viene riconosciuta come tale, non contata per errore come una riga di prodotto.
Righe di sconto o nota di credito con importo negativo
Lette con il segno negativo conservato, così la somma delle righe continua a quadrare con il totale.
Una tabella con descrizione e codice articolo nella stessa colonna
Il testo combinato torna nel campo description; separare un codice articolo, se serve, è un passaggio che il tuo gestionale può applicare sulla stringa restituita.
Come verificarlo davvero prima di impegnarti
Una percentuale di precisione su una pagina di marketing raramente dice ciò che serve sapere. Il numero che vale la pena chiedere — e verificare da soli prima di integrare — è la precisione sulle righe, misurata su un campione reale dei tuoi fornitori, non su un set di demo scelto per fare bella figura.
Un test pratico prende venti o trenta documenti rappresentativi del tuo parco fornitori reale, inclusi alcuni multi-pagina e alcuni scansionati o di qualità inferiore, e controlla due cose: se il numero di righe corrisponde esattamente al documento, e se la somma degli importi di riga restituiti quadra con il totale stampato. Entrambi i controlli sono abbastanza meccanici da poter essere scriptati, e insieme intercettano i due modi di fallire che contano di più per un matching a valle — righe perse o duplicate, e importi singoli letti male.
Poiché /validate è gratuito e un piano gratuito permette di far girare documenti reali su /extract, questo test si può eseguire prima di qualsiasi impegno commerciale — una risposta concreta sui tuoi documenti, invece di una dichiarazione di precisione generica presa per buona.
Solo intestazione contro con le righe
| Solo intestazione | Con le righe |
|---|---|
| Conferma che il documento esiste e il suo totale | Conferma esattamente cosa è stato fatturato, quantità e prezzo per articolo |
| Confronto a due vie solo sul totale | Confronto reale riga per riga contro un ordine o un DDT |
| Una persona ridigita ogni riga per la categorizzazione | La categorizzazione lavora direttamente sui dati di riga strutturati |
| Un errore compensato su due righe passa inosservato | Gli scostamenti per riga sono visibili, non nascosti dentro un totale che torna |
Chi la usa
Team di sviluppo di gestionali
Dati di riga strutturati abbastanza bene da alimentare un confronto reale con ordini e DDT, non solo un controllo a livello di intestazione.
Fornitori di software per l'acquisto
Confronti tra quantità ordinata e quantità fatturata costruiti su dati di riga tipizzati e affidabili.
Piattaforme di nota spese e gestione costi
Categorizzazione e controllo budget a livello di riga alimentati direttamente dai dati estratti.
Team di integrazione contabile
Uno schema di riga coerente da mappare su un piano dei conti, indipendentemente dal fornitore o dal layout.
Ognuno di questi ruoli dipende in fondo dalla stessa capacità, applicata a una decisione diversa a valle — una piattaforma di acquisto che confronta quantità ordinata e fatturata e uno strumento di gestione spese che categorizza per riga stanno entrambi, alla base, consumando lo stesso array line_items tipizzato, solo per scopi diversi.
Perché le righe sono dove si vede davvero la qualità
Qualsiasi strumento di estrazione può sembrare accurato su un campo di intestazione — ci sono solo poche possibilità candidate sulla pagina, e un riconoscimento di pattern basato su etichette come "Numero fattura" copre gran parte del lavoro. Una tabella di righe non ha questa scorciatoia: quaranta righe significano quaranta occasioni indipendenti di unire due righe, perderne una o disallineare una colonna, e una tabella su più pagine moltiplica ulteriormente quel rischio.
Per questo la precisione sulle righe, più della precisione sui campi di intestazione, è il numero da chiedere quando si valuta un'API di estrazione per un gestionale — un fornitore che dà solo la precisione complessiva senza scomporre quella sulle righe sta rispondendo alla metà più facile del problema.
Un modo pratico per verificare questo, quando confronti un vendor: chiedi specificamente come gestisce un documento multi-pagina con l'intestazione della tabella che si ripete, e osserva se la risposta è concreta e specifica o generica e vaga. Un fornitore che ha davvero risolto la ricostruzione di righe multi-pagina la descrive nel dettaglio; uno che non l'ha risolta tende a rispondere con frasi generiche sull'"OCR avanzato" senza affrontare il caso specifico.
Ottieni la tua chiave API
Manda un documento reale con più righe su /extracte guarda tu stesso l'array line_items. Vedi la panoramica completa dell'API per come questa funzione si inserisce nel resto del flusso di estrazione.
Una sola chiamata di prova è di solito sufficiente per rispondere alla domanda specifica di questa pagina: manda una tua fattura multi-riga reale e verifica se l'array restituito corrisponde a ogni riga, nell'ordine giusto, con le quantità e i prezzi corretti.
Sicurezza e privacy
Caricamento cifrato con TLS end-to-end.
Elaborazione su infrastruttura con controlli allineati a SOC 2.
Il documento originale viene eliminato subito dopo l'elaborazione.
Nulla di ciò che carichi viene mai usato per addestrare modelli di IA.
Dettagli completi nella pagina sulla sicurezza. Gli stessi controlli si applicano indipendentemente da quante righe contenga un singolo documento.
Per documenti che espongono prezzi unitari e volumi commerciali — informazioni spesso sensibili dal punto di vista competitivo — questo conta particolarmente, dato che ogni riga estratta porta con sé lo stesso livello di riservatezza dell'intestazione del documento.