Da scansione a dati strutturati: pipeline OCR per documenti aziendali in Italia

In molte PMI italiane i documenti «vivi» non sono ancora tutti digitali. Arrivano fatture di fornitori in PDF generato, DDT stampati e riscannati, bolle di consegna, moduli compilati a mano, estratti conto, pratiche assicurative. Il gestionale o l’ERP, però, vuole campi: numero documento, data, partita IVA, imponibile, aliquota, codice articolo, quantità.

L’OCR da solo non risolve il problema. Trasforma un’immagine in testo; quello che serve al back-office è estrarre campi affidabili, con una confidenza misurabile e un punto dove una persona può correggere i casi dubbi. In questo articolo raccontiamo come impostiamo una pipeline realistica: preprocessing, riconoscimento, estrazione, validazione e integrazione — con un occhio a privacy, layout italiani e limiti di strumenti open source come Tesseract.

Il problema non è «leggere», è «strutturare»

Una fattura PDF generata dal gestionale del fornitore spesso contiene già testo selezionabile: lì l’OCR non serve, basta un estrattore di testo (o un parser basato su layout). Una scansione a 150 dpi con pieghe, timbri e tabelle storti è un altro mondo.

In ambito PMI italiano i documenti tipici sono:

• fatture e note di credito (anche dopo l’obbligo di fattura elettronica restano molte copie PDF «di cortesia» e documenti esteri);
• DDT e bolle con tabelle di righe;
• moduli e pratiche a campi fissi (key-value);
• documenti misti: logo, intestazione, tabella, pie’ di pagina con IBAN e note.

L’obiettivo operativo non è «avere il testo completo», ma ottenere un JSON (o un Excel) con i campi che alimentano contabilità, magazzino o archiviazione. È il percorso che descriviamo anche sulla pagina dedicata all’OCR documenti per aziende: upload → estrazione e normalizzazione → validazione con log → output verso gestionale.

Architettura a due passi (e un terzo umano)

Una pipeline che regge in produzione separa tre responsabilità.

1. OCR → testo (e, se possibile, layout).

Il motore restituisce stringhe, spesso con bounding box (coordinate della parola o della riga). Qui contano qualità della scansione, lingua (ita + eventuali eng) e preprocessing.

2. Estrazione campi → struttura.

Dal testo (o dal layout) si ricavano i campi di business: con regole (regex, ancore tipo «Partita IVA», «Totale documento»), con modelli addestrati su layout ripetitivi, o con un LLM a cui si passa il testo OCR e uno schema JSON. Le regole sono prevedibili e facili da auditare; i modelli e i LLM gestiscono meglio layout variabili, ma vanno tenuti sotto controllo con esempi e soglie.

3. Revisione umana sui casi sotto soglia.

Ogni campo (o ogni documento) dovrebbe avere una confidenza. Sotto una soglia — o se fallisce un controllo di validazione — il documento finisce in coda di revisione. Solo i casi dubbi costano tempo a una persona; il resto passa in automatico.

Senza il passo 3, «automazione al 100%» diventa spesso «errori silenziosi al 5%», che in contabilità pesano più del lavoro risparmiato.

Preprocessing: dove si guadagna (o si perde) accuratezza

Prima di chiamare Tesseract o un altro motore, vale la pena sistemare l’immagine:

• Risoluzione: mirare ad almeno ~300 dpi sul testo piccolo; sotto i 200 dpi i caratteri sottili (partite IVA, decimali) degradano in fretta.
• Deskew: raddrizzare la pagina riduce errori su colonne e tabelle.
• Binarizzazione / contrasto: utile su scansioni grigie o con sfondo colorato; attenzione a non «mangiare» linee di tabella o timbri che a volte aiutano a capire il layout.
• Ritaglio e pagina: elaborare una pagina alla volta; rimuovere bordi neri dello scanner.
• PDF multi-pagina: convertire in immagini (es. con pdf2image / Poppler) e processare in sequenza, tenendo l’ordine.

Esempio minimale in Python (immagine già preparata o pagina da PDF):

from pathlib import Path
import re

import pytesseract
from PIL import Image, ImageOps, ImageFilter

def prepara(path: Path) -> Image.Image:
    img = Image.open(path).convert("L")  # scala di grigi
    img = ImageOps.autocontrast(img)
    # leggero sharpen; il deskew serio richiede OpenCV o simili
    img = img.filter(ImageFilter.SHARPEN)
    return img

def ocr_ita(img: Image.Image) -> str:
    # --psm 6: blocco di testo uniforme; da cambiare per moduli/tabelle
    return pytesseract.image_to_string(img, lang="ita", config="--psm 6")

PIVA_RE = re.compile(r"\b(?:IT)?\s*(\d{11})\b")
DATA_RE = re.compile(r"\b(\d{1,2}[/.\-]\d{1,2}[/.\-]\d{2,4})\b")

def estrai_candidati(testo: str) -> dict:
    pive = PIVA_RE.findall(testo)
    date = DATA_RE.findall(testo)
    return {
        "partite_iva": pive,
        "date": date,
        "testo_len": len(testo),
    }

Questo snip è un punto di partenza, non un motore di fatture. In produzione aggiungerete: confidenza per parola (image_to_data), normalizzazione date italiane, checksum della partita IVA, matching anagrafica fornitori, gestione multi-pagina.

Limiti di Tesseract su layout e tabelle

Tesseract resta un ottimo motore open source per testo continuo e per molti documenti semplici. Sui layout aziendali italiani mostra limiti noti:

• tabelle: le celle vicine si «attaccano»; quantità e prezzi finiscono sulla riga sbagliata;
• multi-colonna e intestazioni a blocchi: l’ordine di lettura può mescolare colonne;
• caratteri confusi: O/0, l/1, S/5, soprattutto a bassa risoluzione;
• scrittura a mano: fuori scope, salvo casi molto controllati o motori diversi.

Quando il documento è una tabella densa (DDT con molte righe), spesso conviene un approccio ibrido: OCR a livello di cella dopo aver rilevato la griglia (OpenCV / librerie di table detection), oppure un servizio di document intelligence che restituisce già strutture tabella. La scelta dipende da volume, varietà dei layout e vincoli di privacy.

Cloud API o motore locale?

Non esiste una risposta unica. Criteri che usiamo in pratica:

Fattore	Motore locale (es. Tesseract + regole)	API cloud di document AI
Privacy / GDPR	I file restano in azienda o nel vostro server	Serve DPA, valutazione trasferimento dati, eventuale regione UE
Costo a volume	Prevedibile (CPU/GPU vostre)	Cresce con pagine/mese
Layout variabili	Più lavoro di regole/modelli	Spesso più robusto out-of-the-box
Latenza / offline	Controllabile, anche senza Internet	Dipende dalla rete e dal provider
Audit	Codice e log sotto il vostro controllo	Va definito cosa logga il fornitore

Per documenti con dati personali o fiscali sensibili, molte aziende preferiscono OCR on-premise o su cloud privato europeo proprio per tenere sotto controllo dove finiscono le scansioni. Il GDPR non vieta il cloud: impone base giuridica, misure di sicurezza, accordi con il responsabile del trattamento e, se serve, valutazione d’impatto. La domanda utile in kickoff è: questi file possono lasciare il perimetro aziendale?

Validazione: la differenza tra testo e dato utilizzabile

Dopo l’estrazione, i controlli che evitano disastri contabili sono banali ma indispensabili:

• partita IVA: 11 cifre e checksum (algoritmo ufficiale);
• codice fiscale / identificativi esteri quando previsti;
• date in range plausibile e coerenti tra documento e registrazione;
• totali: somma righe ≈ imponibile; IVA ≈ imponibile × aliquota (con tolleranza di arrotondamento);
• anagrafiche: matching fuzzy con anagrafica fornitori già in gestionale;
• obbligatorietà: se manca un campo critico → revisione, non import silenzioso.

def checksum_piva(piva: str) -> bool:
    """Checksum partita IVA italiana (11 cifre)."""
    if not piva.isdigit() or len(piva) != 11:
        return False
    s = 0
    for i, ch in enumerate(piva[:10]):
        n = int(ch)
        if i % 2:  # posizioni pari (1-based): raddoppia
            n *= 2
            if n > 9:
                n -= 9
        s += n
    return (10 - s % 10) % 10 == int(piva[10])


def valida_fattura(campi: dict, soglia: float = 0.85) -> list[str]:
    errori = []
    if campi.get("confidence", 0) < soglia:
        errori.append("confidenza_bassa")
    piva = campi.get("piva_fornitore", "")
    if not checksum_piva(piva):
        errori.append("piva_non_valida")
    try:
        if abs(float(campi["imponibile"]) * float(campi["aliquota"]) / 100
               - float(campi["iva"])) > 0.05:
            errori.append("iva_incoerente")
    except (KeyError, ValueError, TypeError):
        errori.append("importi_mancanti")
    return errori

(Il checksum sopra è quello usato per le partite IVA italiane; in produzione usate una funzione collaudata e unit test su casi noti.)

Se il documento è una fattura e l’obiettivo finale è l’invio allo SdI, l’OCR è solo il primo tratto: serve poi mappare i campi nello schema FatturaPA. Per PDF già strutturati o layout fissi spesso si lavora su un convertitore PDF→XML per fattura elettronica; per scansioni il percorso è OCR + estrazione + stessa validazione XSD/semantica vista nelle integrazioni SDI.

Checklist per valutare un progetto OCR in azienda

1. Obiettivo: quali campi servono davvero a quale processo (contabilità, magazzino, archivio)?
2. Volumi e varietà: quante pagine/mese? Quanti layout distinti? Quanto cambiano nel tempo?
3. Origine file: PDF nativi, scan, foto da smartphone, mix?
4. Qualità campione: chiedete 20–50 documenti reali (anonimizzati se serve) e misurate l’accuratezza campo per campo, non solo «l’OCR ha letto qualcosa».
5. Privacy: i file possono uscire? Serve log degli accessi, cifratura, retention?
6. Soglie e coda umana: chi corregge? Con quale interfaccia? Entro quanto tempo?
7. Integrazione: JSON/CSV verso ERP, API, o data entry assistito se i volumi sono bassi e irregolari.
8. Manutenzione: chi aggiorna le regole quando un fornitore cambia modello di fattura?
9. Metriche: precision/recall sui campi critici, % documenti a revisione, tempo medio di correzione.
10. Exit strategy: formati di export e proprietà dei modelli/regole, così non restate bloccati su un vendor.

Cosa abbiamo imparato

• OCR ≠ dati strutturati: separate riconoscimento ed estrazione, e misurate la confidenza.
• Il preprocessing paga più di un cambio di motore su scan mediocri.
• Tesseract basta per molti testi semplici; tabelle e layout complessi chiedono più disegno (o un motore diverso).
• Privacy e perimetro vanno decisi in kickoff, non dopo il primo batch in cloud.
• Validazione e revisione umana sono parte del prodotto, non un optional.
• Per le fatture, collegare l’estrazione allo schema FatturaPA evita di rifare il lavoro a valle.

Se state impostando una pipeline simile e volete confrontare scelte su tabelle o su soglie di confidenza, scrivetelo nei commenti: sono dettagli su cui si impara soprattutto dai casi reali.

Scritto dal team di S-Data, software house che sviluppa gestionali e integrazioni su misura.