Il problema che sembra di AI, e non lo è
Registrare una fattura passiva significa, tra le altre cose, scegliere il conto di costo dentro un piano dei conti di ~1.600 voci. Sembra il compito perfetto per un modello linguistico: leggi il documento, capisci di cosa parla, scegli la voce. E infatti un buon classificatore lo fa — fino a un certo punto.
Il punto è che l'informazione decisiva spesso non sta nel documento. La stessa fattura di energia elettrica va su "uffici" o su "produzione e forza motrice" a seconda della sede. Le spese di un ristorante possono essere mensa dipendenti o rappresentanza. La deducibilità di un'auto dipende dall'uso che ne fa l'azienda. Nessun modello, per quanto grande, può leggere nel documento ciò che il documento non contiene: quelle risposte vivono nella storia dello studio.
I dataset
Per misurare quanto pesa quella storia abbiamo raccolto quattro dataset reali, tutti con la verità a terra: il conto su cui lo studio ha registrato davvero ogni documento.
| Dataset | Contenuto | Volume |
|---|---|---|
| D1 — fatture multi-azienda | Fatture ricevute e registrate di 45 aziende, con il conto usato dallo studio | 6.226 fatture, 2.013 fornitori |
| D2 — movimenti bancari | Estratto conto di un'azienda con la contabilizzazione reale di ogni movimento | 2.324 movimenti |
| D3 — prima nota triennale | Registro acquisti completo di una stessa azienda su tre esercizi (2023–2025), dal gestionale dello studio | 3.518 fatture, 71 conti |
| D4 — banco end-to-end | Fatture elettroniche XML per il collaudo della catena completa fino ai registri | 4 fatture |
Tre piani dei conti diversi (i gestionali non parlano la stessa lingua) sono stati riportati a un piano canonico unico da 1.590 conti con una mappatura semantica dedicata — 368 codici mappati, e ogni mappatura incerta lasciata esplicitamente in revisione anziché forzata.
L'esperimento: il replay cronologico
La misura è volutamente severa. Ordiniamo le fatture per data e, per ciascuna, chiediamo a una regola costruita solo sul passato di quel fornitore di predire il conto. Niente informazioni dal futuro, niente aggiustamenti: la prima volta che un fornitore compare, la regola non esiste e lo ammette.
| Misura | Risultato |
|---|---|
| Fornitori "deterministici" (usano sempre lo stesso conto) | 71% |
| Replay su D1, conto esatto (codici nativi) | 58% |
| Replay su D1, conto esatto (piano canonico) | 82% |
| Replay su D2 (movimenti bancari) | 70% |
| Replay su D3, attraverso tre esercizi | 86% (94% sul singolo anno) |
Il dato longitudinale è il più significativo: su tre anni della stessa azienda solo il 14% delle fatture è "prima volta", e la regola fornitore→conto regge l'86% attraverso gli esercizi. Non è un artefatto di breve periodo: è come lavora davvero uno studio.
Curioso anche il salto 58→82% col piano canonico: metà degli "errori" della memoria erano distinzioni tra sotto-conti gemelli del gestionale di origine che sul gestionale di destinazione non esistono nemmeno. Standardizzare il piano dei conti non è plumbing — assorbe da solo un quarto dell'errore apparente.
E il modello da solo?
Il nostro classificatore a tre stadi (voce di bilancio → shortlist su embeddings → scelta finale con LLM) è buono, e lo abbiamo misurato senza sconti: su 228 documenti sintetici avversariali, mai visti, campionati uniformemente su tutto il piano dei conti, sceglie il conto esatto nel 36% dei casi e il mastro giusto nel 64%; sul set curato dei casi comuni arriva al 75%. Aggiungere il registro dei conti che l'azienda usa davvero porta 4 punti; nient'altro, a livello di prompt, ne porta di significativi.
La gerarchia che emerge dai dati
Regola per-azienda: 86% · Prior di rete (dove applicabile): 64% · Modello da solo: 36–75% a seconda del set. L'implicazione architetturale: il modello è il fallback per i fornitori mai visti, non il centro del sistema. Il centro è la memoria organizzata dello studio.
L'effetto rete, misurato
C'è un terzo strato tra la regola e il modello. Abbiamo rifatto il replay in modalità leave-one-out: prevedere le fatture di un'azienda usando solo le regole delle altre 44. Risultato: il 34% delle fatture di un'azienda arriva da fornitori già visti altrove (109 fornitori condivisi — utility, telco, big tech, logistica), e su quelli la previsione cross-azienda azzecca il 64%.
Tradotto: circa un quinto del ciclo passivo di un cliente appena acquisito, a storico zero, è già noto al sistema il primo giorno. E ogni studio che si aggiunge allarga la copertura per tutti gli altri. È un effetto rete classico, ma misurato su registrazioni contabili vere — non dichiarato in una slide.
Quello che non funziona (e perché lo diciamo)
Tre risultati negativi, che valgono quanto i positivi:
- Il contesto sintattico non aiuta. Arricchire le regole con aliquota IVA, tipo documento o fascia di importo non muove l'accuratezza (82→83%). L'errore residuo è drift semantico vero — riclassificazioni, casi una tantum — e si chiude solo con la revisione umana, che alla conferma diventa regola.
- La confidenza del modello non è un segnale di correttezza. Nella mappatura tra piani dei conti abbiamo trovato errori sistematici dichiarati a confidenza 0.9–1.0: affitti passivi classificati come utenze, licenze software come servizi telematici, perfino risconti attivi come sponsorizzazioni. La review umana a tappeto li ha corretti; i controlli, da allora, sono strutturali (perimetri verificati, quadrature, maggioranze) e non probabilistici.
- Esistono conti-contenitore che nessuna AI può sciogliere. "Costi auto deducibili" di uno studio raccoglie carburanti, manutenzioni e pedaggi che nel piano canonico vivono su conti diversi: non è un errore di classificazione, è una decisione di migrazione che spetta allo studio. Una risposta umana riattiva in blocco centinaia di regole.
Dai numeri ai libri: la catena eseguita
Tutto questo non vive in un notebook. La catena completa — fattura elettronica XML → parser → proposta (conto, causale, codice IVA, quadratura) → registrazione in prima nota IVA sul gestionale — è stata eseguita e verificata end-to-end in ambiente di collaudo su Genya (Wolters Kluwer), controllando l'esito nei registri: protocolli assegnati, movimenti in lista, partite aperte e poi chiuse col pagamento. Delle quattro fatture del banco di prova, due sono entrate nei libri da sole; due — una multi-aliquota, una estera in reverse charge — sono state trattenute con motivazione, perché fuori dal perimetro collaudato.
L'astensione è una feature
In contabilità il costo dell'errore è asimmetrico: una registrazione sbagliata va trovata e stornata nei libri veri; un documento in revisione costa trenta secondi di un professionista. Con un 15–20% di casi oggettivamente non deducibili dal documento, l'astensione selettiva con motivazione leggibile non è prudenza: è ciò che rende il sistema utilizzabile da uno studio professionale.
Cosa ne facciamo
Il replay che misura è lo stesso processo che semina: dallo storico sono state distillate ~2.470 regole fornitore→conto in codici canonici (solo maggioranze vere; le contese restano al classificatore), pronte a precaricare la memoria di ogni azienda. Uno studio che porta il proprio storico non parte da zero: parte dall'86%.
Il resto della roadmap segue i dati, non il contrario: allargare il perimetro collaudato del connettore (aliquote, note di credito, reverse charge), leggere le fatture direttamente dal gestionale, e trasformare ogni correzione dell'operatore in una regola che non si ripete. Optlyx Clerk è costruito così — e ora sappiamo anche dire, con i numeri, perché.
Domande frequenti
Perché un modello AI generico non basta per scegliere il conto di una fattura?
Perché l'informazione decisiva spesso non sta nel documento: la stessa fattura di energia può andare su "uffici" o "produzione" a seconda della sede. Nei nostri test il miglior classificatore sceglie il conto esatto nel 36% dei casi su documenti mai visti (75% sui casi comuni); la regola imparata dallo storico dello studio arriva all'86%.
Cosa succede quando il sistema non è sicuro?
Si astiene e passa il caso in revisione con una motivazione leggibile. Ogni correzione dell'operatore diventa una regola: il sistema impara dallo studio, non lo sostituisce.
Come fa un cliente nuovo, senza storico, a partire?
Con il prior di rete: il 34% delle fatture di un'azienda arriva da fornitori già visti presso altre aziende, e su quelli la previsione cross-azienda azzecca il 64%. Circa un quinto del ciclo passivo è già noto il primo giorno — e cresce con ogni studio che si aggiunge.
Le registrazioni finiscono davvero nel gestionale?
Sì: la catena completa è stata eseguita e verificata end-to-end in ambiente di collaudo su Genya (Wolters Kluwer), controllando i registri a valle. Le fatture fuori perimetro vengono trattenute con motivazione, non registrate a caso.