---
title: "La contabilità è un problema di memoria, non di modello: i numeri"
canonical: https://mastro.tax/guida-contabilita-memoria-non-modello
source: rendered-html
---

# La contabilità è un problema di memoria, non di modello: i numeri

> Mirror markdown per LLM. HTML canonico: https://mastro.tax/guida-contabilita-memoria-non-modello

## 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.

DatasetContenutoVolume

**D1** — fatture multi-aziendaFatture ricevute e registrate di 45 aziende, con il conto usato dallo studio6.226 fatture, 2.013 fornitori
**D2** — movimenti bancariEstratto conto di un'azienda con la contabilizzazione reale di ogni movimento2.324 movimenti
**D3** — prima nota triennaleRegistro acquisti completo di una stessa azienda su tre esercizi (2023–2025), dal gestionale dello studio3.518 fatture, 71 conti
**D4** — banco end-to-endFatture elettroniche XML per il collaudo della catena completa fino ai registri4 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.

MisuraRisultato

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. [Clerk](/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.