Un passaggio che nessun software copre
Chi lavora su commessa conosce la sequenza. Il lavoro viene eseguito, si emette il SAL, il committente lo verifica e poi — solo poi — arriva la mail che autorizza a fatturare. Può chiamarsi benestare alla fatturazione, autorizzazione all'emissione, approvazione del SAL o semplicemente «può procedere con la fattura». In tutti i casi è il momento in cui nasce il diritto a emettere il documento.
Quella mail viene letta da una persona. La stessa persona cerca il riferimento d'ordine, controlla l'importo autorizzato, verifica che sia il SAL giusto e apre il gestionale per compilare la bozza. È un lavoro di trascrizione, e come tutti i lavori di trascrizione produce due categorie di errori: quelli che si notano subito e quelli che si notano a fine trimestre.
La cosa che colpisce, esaminando i gestionali di fatturazione elettronica italiani, è che nessuno copre questo passaggio. Emettono, trasmettono, conservano, tengono i registri. Ma il momento in cui si decide che una fattura va emessa resta fuori dal software.
Perché i gestionali non lo fanno
Non è una dimenticanza. Un gestionale di fatturazione ha una responsabilità precisa: produrre documenti fiscalmente corretti e conservarli a norma. Il suo dato di ingresso è una decisione già presa da un essere umano. Estendere il perimetro fino a interpretare la corrispondenza significherebbe assumersi il rischio di sbagliare quell'interpretazione, e il costo di un errore in quel punto non è tecnico ma fiscale.
La funzione che più si avvicina è la digitalizzazione automatica delle fatture ricevute, presente in diversi gestionali: legge il documento del fornitore e ne estrae i dati. Ma è un documento fiscale strutturato, emesso da un altro software, con campi in posizioni prevedibili. Una mail di autorizzazione è testo libero scritto da una persona che non sa e non deve sapere che verrà letta da un programma.
Che cosa rende difficile riconoscere un'autorizzazione
Il problema non è trovare la parola «benestare». È distinguere quattro casi che si somigliano molto.
Il primo è l'autorizzazione vera: «si autorizza l'emissione della fattura per il SAL n. 3». Chiara, esplicita, senza margine di dubbio.
Il secondo è l'approvazione tecnica, che spesso viene confusa con la prima: «il SAL n. 3 è approvato». Un SAL approvato dalla direzione lavori non è ancora un'autorizzazione amministrativa a fatturare, e trattare le due cose allo stesso modo produce fatture emesse prima del dovuto.
Il terzo è la negazione, che è il caso pericoloso: «non si autorizza la fatturazione fino alla verifica delle quantità». Contiene tutte le parole giuste e significa l'opposto. Un riconoscimento basato sulla presenza di parole chiave qui produce esattamente l'errore che non si può permettere.
Il quarto è la citazione: una mail nuova che riporta in coda il testo di un'autorizzazione già ricevuta e già fatturata. Se il programma non separa il testo nuovo dal thread citato, la stessa autorizzazione viene riconosciuta due volte.
Come si costruisce un riconoscimento affidabile
La logica che funziona non somma parole: pesa segnali indipendenti fra loro e li fa concorrere a un punteggio.
Il lessico è il segnale principale, ma con pesi differenziati. «Si autorizza l'emissione della fattura» non ha la stessa forza di «attendiamo fattura», e assegnare a entrambe lo stesso valore significa scegliere fra troppi falsi positivi o troppi mancati riconoscimenti. Serve inoltre un elenco di formule di negazione che bloccano il riconoscimento indipendentemente dal resto: «non si autorizza», «benestare negato», «sospendere la fatturazione», «fatturazione da non effettuare».
La struttura del messaggio è un segnale indipendente. La presenza di un riferimento d'ordine, di un numero di SAL, di un importo espresso in cifre e di un codice CIG o CUP aumenta la probabilità che si tratti di una comunicazione amministrativa e non di uno scambio informale.
Il mittente conta perché un'autorizzazione arriva dall'ufficio acquisti o dall'amministrazione del committente, non da un indirizzo qualsiasi. Un mittente già associato a un'autorizzazione confermata in passato è un indizio più forte di uno mai visto.
Gli allegati vanno letti, non solo contati: un PDF firmato di approvazione del SAL contiene spesso l'unica formulazione esplicita, mentre il corpo della mail si limita a «in allegato». Un sistema che ignora gli allegati non vede il documento che decide.
Il punto in cui l'automazione deve fermarsi
Qui sta la scelta che distingue un sistema utilizzabile da uno pericoloso. Una fattura elettronica trasmessa allo SDI non è modificabile e non è annullabile. L'unico rimedio a un errore è la nota di credito, che resta nei registri di entrambe le parti e va spiegata al committente e al commercialista.
Questo rende l'asimmetria fra i due errori possibili molto forte. Un'autorizzazione non riconosciuta produce un ritardo, che si recupera. Un'autorizzazione riconosciuta per sbaglio produce un documento fiscale non dovuto verso un cliente, che non si recupera senza costi.
La conseguenza pratica è che la trasmissione non va automatizzata, anche quando sarebbe tecnicamente possibile. Il compito del software si ferma alla bozza: XML generato, dati compilati, riferimenti inseriti, documento pre-validato sui codici di scarto. La conferma resta a chi si assume la responsabilità dell'emissione. L'automazione elimina la trascrizione, non la decisione.
Che cosa fare delle bozze incomplete
Un dettaglio apparentemente minore che decide se il sistema viene usato o abbandonato. Quando l'autorizzazione viene riconosciuta ma manca un dato — il cliente non è in anagrafica, l'importo non è espresso in cifre — la tentazione è di non produrre nulla e attendere.
È la scelta sbagliata. Chi guarda il programma vede una scansione che dichiara di aver esaminato venti messaggi e non mostra alcun risultato, e conclude che non funziona. La bozza va predisposta comunque, marcata come da completare, con l'indicazione esplicita di cosa manca. Un elenco di cose da sistemare è utilizzabile; il silenzio no.
Lo stesso vale per i messaggi con segnali rimasti sotto la soglia di riconoscimento: vanno conservati e consultabili. Sono i casi più istruttivi, perché mostrano il lessico reale dei propri committenti e permettono di capire se la soglia è tarata bene.
Quando questo tipo di automazione non ha senso
Se fatturate a scadenza fissa senza attendere autorizzazioni, non c'è nulla da riconoscere. Se il committente comunica il benestare per telefono o attraverso un proprio portale, la mail non esiste e il problema è diverso. Se emettete poche fatture l'anno, il tempo risparmiato non giustifica né la spesa né l'apprendimento.
Ha senso quando il volume delle autorizzazioni rende la trascrizione un lavoro ricorrente, e quando un benestare passato inosservato ha già ritardato un incasso. In quel caso il guadagno non è tanto la velocità, quanto il fatto che nessuna autorizzazione resti in fondo a una casella per tre settimane.
In pratica
Il riconoscimento del benestare è un problema circoscritto e risolvibile, che si colloca fra la corrispondenza e il gestionale senza sostituire nessuno dei due. Nexfatt è il programma per Windows che abbiamo costruito su questa logica: legge la posta via IMAP, riconosce le autorizzazioni pesando oltre cento formule italiane e inglesi, estrae i riferimenti e predispone l'XML FatturaPA con il PDF di cortesia. La conferma prima della trasmissione resta sempre all'operatore.
Il confronto con i gestionali di fatturazione spiega punto per punto cosa fa ciascuno, comprese le funzioni che il gestionale ha e Nexfatt non ha. La prova dura ventuno giorni e comprende la generazione dell'XML, così si può verificare sul lessico dei propri committenti prima di decidere.