Estrazione dei dati dalle fatture: deep learning vs machine learning vs LLM (guida 2026)

Cinque anni fa, estrarre dati strutturati dalle fatture significava una pipeline di deep learning: una fase OCR, un modello consapevole del layout (LayoutLM, Donut) ottimizzato su migliaia di documenti annotati manualmente e un onere di manutenzione ogni volta che un fornitore modificava il proprio modello. Nel 2026 l'intera pipeline si riduce a una chiamata API a un vision LLM: immagine in ingresso, JSON convalidato dallo schema in uscita — zero dati di addestramento, zero modelli ospitati e nuovi layout gestiti zero-shot. Questa guida di Kunavo — un gateway indipendente compatibile con OpenAI verso i modelli visivi su cui si basa questo approccio — mostra il pattern completo funzionante, il costo per fattura misurato sulle nostre tariffe pubblicate e come mantenere un'accuratezza adatta alla produzione.

Confronto tra gli approcci all'estrazione delle fatture: regole, machine learning, deep learning, LLM

Sono state utilizzate quattro generazioni di tecniche per ottenere dati strutturati da una fattura. Vale la pena metterle a confronto, perché il compromesso che per due decenni ha deciso la scelta tra loro — accuratezza acquistata con dati annotati — è proprio quello che ha smesso di essere applicabile.

I primi tre condividono tutti una proprietà: l'accuratezza si acquista con dati annotati. Ogni modello di fornitore, ogni caratteristica CRF, ogni fine-tuning di LayoutLM è un progetto di annotazione. Un vision LLM ha già sostenuto quel costo durante il pretraining, quindi il costo marginale di un nuovo layout è zero. Questo è l'intero cambiamento — non che i metodi precedenti abbiano smesso di funzionare, ma che ciò su cui spendevano il budget è diventato gratuito.

Deep learning ottimizzato rispetto a vision LLM, nel dettaglio

Un estrattore ottimizzato può ancora prevalere su un singolo layout stabile ad alto volume, ma per la lunga coda delle fatture del mondo reale — fornitori, lingue e qualità delle scansioni differenti — il vision LLM zero-shot è più accurato nella pratica e molto più economico da gestire. Altri pattern per questo tipo di carico di lavoro sono disponibili nel caso d'uso dell'estrazione dati.

Il pattern completo: immagine → JSON convalidato dallo schema

Tutto ciò che segue viene eseguito sull'endpoint compatibile con OpenAI di Kunavo — punta base_url a https://api.kunavo.com/v1 e lo stesso codice può usare Claude o GPT modificando una sola stringa:

from openai import OpenAI
import base64, json

client = OpenAI(
    base_url="https://api.kunavo.com/v1",
    api_key="sk-kn-...",
)

SCHEMA = {
    "name": "invoice",
    "schema": {
        "type": "object",
        "properties": {
            "vendor_name":    {"type": "string"},
            "vendor_tax_id":  {"type": ["string", "null"]},
            "invoice_number": {"type": "string"},
            "invoice_date":   {"type": "string", "description": "ISO 8601"},
            "due_date":       {"type": ["string", "null"]},
            "currency":       {"type": "string", "description": "ISO 4217"},
            "line_items": {
                "type": "array",
                "items": {
                    "type": "object",
                    "properties": {
                        "description": {"type": "string"},
                        "quantity":    {"type": "number"},
                        "unit_price":  {"type": "number"},
                        "amount":      {"type": "number"},
                    },
                    "required": ["description", "amount"],
                },
            },
            "subtotal":  {"type": ["number", "null"]},
            "tax":       {"type": ["number", "null"]},
            "total":     {"type": "number"},
        },
        "required": ["vendor_name", "invoice_number", "invoice_date",
                     "currency", "line_items", "total"],
    },
}

def extract(path: str) -> dict:
    image_b64 = base64.b64encode(open(path, "rb").read()).decode()
    resp = client.chat.completions.create(
        model="claude-haiku-4-5",   # the cheapest capable model for clean invoices
        response_format={"type": "json_schema", "json_schema": SCHEMA},
        messages=[
            {"role": "system", "content":
                "Extract the invoice into the schema. Copy values exactly as "
                "printed; use null when a field is absent. Never invent data."},
            {"role": "user", "content": [
                {"type": "image_url",
                 "image_url": {"url": f"data:image/png;base64,{image_b64}"}},
            ]},
        ],
    )
    return json.loads(resp.choices[0].message.content)

inv = extract("invoice_0231.png")

# Cheap arithmetic guardrail: reject when the line items don't add up.
delta = abs(sum(li["amount"] for li in inv["line_items"])
            + (inv.get("tax") or 0) - inv["total"])
if delta > 0.02:
    raise ValueError(f"line items disagree with total by {delta:.2f}")

print(inv["vendor_name"], inv["total"], inv["currency"])

Tre dettagli svolgono la maggior parte del lavoro: lo schema JSON in response_format (su Claude il modello non può emettere altro — consulta la nota su GPT nel riferimento collegato qui sotto), la regola del prompt di sistema «copia i valori esattamente; null quando assenti; non inventare mai» (elimina gli ID fiscali inventati) e la protezione aritmetica — voci + imposta devono corrispondere al totale, altrimenti il documento passa a un modello più forte o a una persona. Consulta il riferimento sui completamenti chat per ciò che response_format impone su ciascuna famiglia di modelli.

Lo stesso schema come modello Pydantic tipizzato

Un dizionario JSON-schema grezzo va bene per un endpoint e diventa problematico per dieci. In produzione, la maggior parte dei team definisce lo schema una sola volta come modello Pydantic e da questo ricava sia il vincolo sia l'oggetto analizzato, così l'estrattore e il resto del codebase non possono mai essere in disaccordo sulla struttura:

from pydantic import BaseModel, Field
from typing import Literal
from openai import OpenAI

client = OpenAI(base_url="https://api.kunavo.com/v1", api_key=KEY)

class LineItem(BaseModel):
    description: str
    quantity: float | None = None
    unit_price: float | None = None
    amount: float

class Invoice(BaseModel):
    vendor_name: str
    vendor_tax_id: str | None = None
    invoice_number: str
    invoice_date: str = Field(description="ISO 8601")
    currency: str = Field(description="ISO 4217")
    line_items: list[LineItem]
    tax: float | None = None
    total: float
    # A confidence field the model fills in itself is a cheap, surprisingly
    # reliable router: low self-reported confidence correlates well with the
    # documents a human should see.
    confidence: Literal["high", "medium", "low"]

resp = client.chat.completions.create(
    model="claude-haiku-4-5",
    response_format={
        "type": "json_schema",
        "json_schema": {"name": "invoice", "schema": Invoice.model_json_schema()},
    },
    messages=[...],
)

invoice = Invoice.model_validate_json(resp.choices[0].message.content)

Qui vale la pena copiare due elementi. I campi tipizzati come float | None invece di float offrono al modello un modo legale per dire «assente» — senza questa possibilità, una riga d'imposta mancante spinge fortemente a inventare uno zero. Inoltre, il campo confidence autodichiarato costa tre token di output e instrada sorprendentemente bene; non è calibrato, ma «basso» è un segnale affidabile che una persona dovrebbe controllare.

Routing a due livelli: cosa viene realmente eseguito in produzione

Usare un unico modello per ogni documento è la struttura sbagliata. Le fatture stampate pulite — la stragrande maggioranza — vengono gestite dal vision model economico disponibile; la coda difficile (grafia manuale, scansioni scadenti, layout insoliti) è il punto in cui un modello più forte giustifica la propria tariffa. Escala in base all'errore di convalida, non a una supposizione:

CHEAP, STRONG = "claude-haiku-4-5", "claude-sonnet-5"

def valid(inv: dict) -> bool:
    """Arithmetic is the guardrail no confidence score replaces."""
    items = sum(li["amount"] for li in inv["line_items"])
    return abs(items + (inv.get("tax") or 0) - inv["total"]) <= 0.02

def extract_routed(path: str) -> tuple[dict, str]:
    inv = extract(path, model=CHEAP)
    if valid(inv) and inv.get("confidence") != "low":
        return inv, CHEAP

    # Escalate: same prompt, same schema, stronger model. Only the failures
    # pay the higher rate, which is what keeps the blended cost near the
    # cheap tier's.
    inv = extract(path, model=STRONG)
    if not valid(inv):
        raise NeedsHumanReview(path, inv)
    return inv, STRONG

# Blended cost at a 90/10 split, per 10,000 invoices:
#   9,000 x $0.00248 + 1,000 x $0.00497
#   = $27.29

Il controllo aritmetico svolge il lavoro reale: è l'unico segnale indipendente dall'opinione che il modello ha di sé. Un documento le cui voci corrispondono al totale dichiarato è quasi sempre corretto nei modi importanti; uno che non supera il controllo merita il modello più forte o una persona, qualunque cosa dichiari il campo della confidenza.

Costo per fattura, per modello

Una fattura di una pagina ≈ 1.800 token di input (inviata come immagine) + circa 350 token di output JSON:

Le tariffe sono aggiornate nella pagina dei prezzi (circa il 30% in meno rispetto ai prezzi di listino dei fornitori) e le richieste non riuscite non vengono fatturate. Con il routing a due livelli — tutto tramite Haiku, gli errori del controllo aritmetico inoltrati a Sonnet — 10.000 fatture al mese costano in genere meno di $27,29.

Accuratezza: la checklist per arrivare in produzione

1. Prima lo schema. Contrassegna i campi realmente obbligatori come required, consenti null ovunque altro — imporre un valore impone un'allucinazione.
2. Invia l'immagine, non il testo OCR. Il layout trasmette significato (colonne, riquadri dei totali); i modelli visivi lo leggono direttamente. Ricorri al testo solo per i PDF nativamente digitali da cui puoi estrarre un livello di testo pulito.
3. Convalida l'aritmetica nel codice. Voci + imposta = totale rileva gratuitamente la maggior parte degli errori di estrazione.
4. Escala, non riprovare alla cieca. Gli errori passano a Sonnet con l'errore di convalida incluso nel prompt; gli errori persistenti passano a una coda umana.
5. Usa few-shot per i veri casi limite. Due o tre esempi dei tuoi layout peggiori (note di credito, più valute) nel prompt di sistema sono più efficaci di qualsiasi quantità di instruction tuning.

Oltre le fatture

Lo stesso pattern vincolato allo schema copre ricevute, ordini di acquisto, bolle di consegna, moduli doganali ed estratti conto — sostituisci lo schema e mantieni le protezioni. Esplora il più ampio caso d'uso dell'estrazione di dati strutturati per pattern adiacenti al RAG, oppure la guida all'ottimizzazione dei costi per le strategie di routing quando il volume cresce. Una sola chiave Kunavo copre ogni livello di modello utilizzato qui — registrati gratuitamente e crea una chiave per eseguire lo snippet così com'è.

Domande frequenti