L’equivoco più comodo è pensare che la fatturazione elettronica europea sia un altro tracciato da produrre. Si apre il programma, si aggiunge un ramo, si testa una casistica, si manda in produzione. Non è un problema di XML. È un problema di calendario normativo, e il calendario non sta fermo mentre il gestionale invecchia.
Prima di toccare un programma, un responsabile applicativo può consultare https://www.recordinformatica.it/ e poi rientrare sul proprio gestionale con una domanda molto concreta: quante decisioni fiscali sono scritte nel sorgente, invece che in dati modificabili e tracciati? Se la risposta è molte, la prossima scadenza europea non chiederà solo sviluppo. Chiederà manutenzione ordinata.
Dal 2030 all’indietro: la fattura cambia data prima di cambiare formato
Aruba Magazine indica il 1° luglio 2030 come data per l’obbligo di fatturazione elettronica nelle transazioni intra-UE previsto dal progetto ViDA. Presa da sola, la data sembra lontana. Vista da un gestionale IBM i, invece, dice altro: una fattura non sarà più governata soltanto dalla partita IVA del cliente o dal sezionale contabile. Dovrà essere letta dentro una combinazione di Paese, tipo operazione, formato richiesto e canale di invio.
Qui la vecchia prassi pesa. Per anni molte aziende hanno trattato la fatturazione elettronica come una specializzazione nazionale: per l’Italia un flusso, per l’estero un altro, per la pubblica amministrazione una deviazione, per il B2B domestico una procedura separata. Ha funzionato perché il numero di varianti era governabile. Ma quando le regole si muovono per Paese e per data, la specializzazione diventa frammentazione interna.
Immaginiamo un gestionale con clienti in più Stati europei. La procedura di emissione legge il Paese, sceglie il formato, decide se serve un canale accreditato, applica controlli prima dell’invio e produce il pacchetto per la conservazione. Se queste scelte stanno dentro una serie di IF sparsi in programmi RPG o COBOL, ogni modifica normativa costringe a cercare pezzi di logica in punti diversi. Il test non riguarda più una funzione. Riguarda il comportamento complessivo della catena.
La fattura del 2030, letta al contrario, suggerisce una manutenzione già molto pratica: non aspettare il nuovo obbligo per capire dove sono le regole. Bisogna sapere quali programmi decidono il formato, quali tabelle contengono i Paesi, quali job schedulati preparano i file e dove vengono registrati gli esiti. Senza questa mappa, la scadenza diventa una caccia al sorgente.
La Germania dal gennaio 2025 rompe l’abitudine del caso speciale
La seconda data da tenere in mano è più vicina nella cronologia normativa: ARXivar cita l’avvio, dal gennaio 2025, del percorso di obbligo B2B in Germania, partito dall’obbligo di ricezione e destinato a estendersi all’emissione nei passi successivi. Questo passaggio è interessante perché costringe molte aziende italiane con rapporti commerciali tedeschi a uscire dal riflesso più diffuso: trattare ogni nuovo Paese come un’eccezione aggiunta alla fine del programma.
La tentazione è nota. Si prende il codice Paese DE, si lega a un formato, si aggiunge una validazione, si replica una parte di gestione già usata altrove. In emergenza sembra una scelta ragionevole. Però produce un effetto tecnico preciso: la norma finisce nel programma, il programma finisce nel ciclo di rilascio, e ogni variante futura richiede sviluppo applicativo dove bastava una modifica controllata di configurazione.
Su IBM i questo meccanismo si vede bene perché molte applicazioni gestionali hanno una storia lunga. Hanno superato cambi di aliquote, nuove causali, nuovi tracciati, aggiornamenti di stampa, conversioni di file, interfacce EDI, passaggi da spool a PDF. La loro forza è la continuità. Ma la continuità diventa rigida quando una regola fiscale viene saldata al codice invece di essere isolata in una tabella versionata.
Il caso tedesco citato da ARXivar, preso come segnale tecnico e non come notizia isolata, dice una cosa semplice: l’eccezione nazionale non è più un’eccezione sicura. Oggi riguarda la Germania, domani un altro Stato, poi una transazione intra-UE, poi una modifica al canale. Una riga di codice che lega Paese e formato sembra economica solo nel giorno in cui viene scritta. Dopo, obbliga a riaprire il programma per una decisione che dovrebbe stare nei dati di governo.
Quella riga andava in tabella. Nel sorgente deve restare il criterio con cui il sistema legge la configurazione, non l’elenco delle scadenze fiscali europee. È una scelta piccola, quasi banale, ma separa la manutenzione controllata dalla rincorsa periodica.
Dentro IBM i le regole devono diventare dati con validità
Scendiamo nel gestionale. Il primo campo da rendere configurabile è il Paese, ma non basta una sigla ISO buttata in anagrafica. Serve una relazione tra Paese, data di validità e regime applicabile. La stessa anagrafica cliente può produrre comportamenti diversi a seconda della data documento, della natura dell’operazione e del canale richiesto. Se il programma decide tutto leggendo solo il cliente, sta semplificando troppo.
Il secondo elemento è il formato. XML non significa una cosa sola. Ogni formato porta con sé campi obbligatori, valori ammessi, controlli sintattici, regole di arrotondamento, allegati e messaggi di scarto. In un impianto ben mantenibile, il formato non dovrebbe essere scelto da una condizione fissa nel programma di emissione. Dovrebbe essere un valore associato a una regola valida da una certa data, con una priorità chiara rispetto ad altre regole.
Il terzo elemento è il canale. La fattura può passare da una piattaforma nazionale, da un intermediario, da un canale accreditato, da una procedura interna che prepara file per l’invio esterno. Il gestionale deve sapere quale canale usare e deve conservare l’esito. Non basta produrre il file giusto se poi non resta traccia del percorso seguito. Su sistemi IBM i, spesso, questo pezzo viene ricostruito guardando code, spool, log applicativi e cartelle IFS. È lavoro da officina, non da manuale.
Il quarto elemento è la validazione. Una regola di validazione deve poter cambiare senza riscrivere mezza procedura. Se un Paese richiede un campo in più o un controllo diverso su un identificativo, il sistema dovrebbe permettere di aggiungere o disattivare quel controllo per una finestra temporale definita. Qui il versionamento conta più della brillantezza del singolo controllo, perché consente di spiegare perché una fattura emessa in una certa data è stata trattata in quel modo.
Il quinto elemento è la conservazione. Non parlo solo di archiviare il documento finale. Parlo del pacchetto informativo che consente di ricostruire formato usato, canale, ricevute, scarti, correzioni e nuovo invio. Se la conservazione viene vista come coda del processo, il rischio è perdere pezzi tecnici che servono quando qualcuno chiede conto dell’operazione. La conservazione va agganciata alla regola applicata, non solo al numero fattura.
Infine c’è il log degli aggiornamenti. Chi ha cambiato una regola? Da quale data? Con quale ticket interno o verbale di rilascio? Quale versione era attiva quando la fattura è uscita? Su un gestionale IBM i maturo queste informazioni non sono lusso documentale. Sono ciò che evita discussioni infinite tra amministrazione, IT e consulente fiscale quando una fattura viene respinta o contestata.
La manutenzione del calendario è una disciplina, non un promemoria
Fisco e Tasse, commentando la pubblicazione in Gazzetta Ufficiale UE, ha ricordato che dal 14 aprile 2025 gli Stati dell’Unione possono imporre obblighi domestici di fatturazione elettronica senza attendere deroghe specifiche. Questo dato si lega bene alla survey internazionale dell’Osservatorio Digital B2B del Politecnico di Milano su 17 Stati europei: la frammentazione non è una percezione di chi gestisce software vecchi, è una condizione concreta del mercato europeo.
Per questo la manutenzione del calendario non può essere affidata a un file Excel tenuto da una persona sola, né a una mail salvata nella cartella del progetto. Serve un flusso interno con responsabilità chiare: chi intercetta la novità normativa, chi la traduce in regola applicativa, chi la carica in ambiente di test, chi verifica i casi già emessi, chi autorizza il passaggio in produzione. Il gestionale non risolve l’organizzazione, però deve darle appigli solidi.
Ipotizziamo una modifica sul formato richiesto da un Paese. Se la regola è in tabella, si crea una nuova versione con data di inizio, si agganciano le validazioni, si eseguono test su fatture campione e si mantiene la versione precedente per i documenti con data anteriore. Se la regola è nel sorgente, si apre una modifica, si compila, si distribuisce, si spera di non aver toccato una casistica collaterale. La differenza pratica sta nel rischio operativo, non nella purezza dell’architettura.
Un vecchio AS/400 può reggere benissimo questa evoluzione, se lo si tratta per quello che è: una piattaforma transazionale robusta che ha bisogno di regole esterne al codice quando il contesto cambia spesso. Pretendere che ogni nuova scadenza europea passi da una modifica RPG o COBOL è una scelta faticosa da difendere. Sposta sul reparto IT un lavoro che appartiene alla governance applicativa.
La fatturazione elettronica europea, letta dalla manutenzione, chiede quindi una pulizia precisa: tabelle parametriche con validità temporale, log delle modifiche, separazione tra regola fiscale e programma, test ripetibili per Paese e formato, conservazione collegata al percorso reale della fattura. Se questo tema viene ignorato, la prossima modifica normativa non arriverà come un semplice aggiornamento: arriverà come fermo operativo, rilascio urgente e verifica manuale di ciò che il sistema avrebbe dovuto sapere già.
