Guida
Algoritmo Codice Fiscale: Come Funziona il Calcolo Ufficiale (DM 12/03/1974)
Il codice fiscale italiano è il risultato di un algoritmo di calcolo definito dal Decreto Ministeriale del 12 marzo 1974 e rimasto invariato fino a oggi. Non è una convenzione amministrativa: è un sistema di compressione deterministica dei dati anagrafici in 16 caratteri, progettato per funzionare su schede perforate, resistere agli errori di trascrizione manuale e consentire la verifica matematica della propria correttezza senza accedere ad alcuna banca dati.
Questa pagina documenta la logica tecnica dell'intero algoritmo, spiega perché ogni regola è stata progettata in quel modo specifico e fornisce indicazioni pratiche per chi vuole implementare il calcolo del codice fiscale in Excel, Java, Python o qualsiasi altro linguaggio.
Nota: qualsiasi strumento online che implementa questo algoritmo produce un risultato presunto. Il codice fiscale definitivo e legalmente valido è esclusivamente quello assegnato dal Ministero dell'Economia e delle Finanze, che gestisce anche i conflitti di omonimia attraverso il meccanismo dell'omocodia.

Come Funziona l'Algoritmo del Codice Fiscale: la Logica del DM 1974
Il DM del 12 marzo 1974 ha affrontato un problema di ingegneria dei sistemi: creare un identificatore unico per ogni cittadino italiano che potesse essere calcolato localmente da qualsiasi ufficio anagrafico del paese, senza connessione a un registro centrale, usando solo carta, penna e una tabella di riferimento.
Il risultato è un algoritmo a cinque blocchi sequenziali dove i primi quattro codificano i dati anagrafici e il quinto verifica matematicamente che i precedenti siano coerenti. Ogni scelta tecnica riflette i vincoli hardware e operativi degli anni Settanta: lunghezza fissa a 16 caratteri per compatibilità con i moduli a larghezza predefinita, uso di lettere al posto di numeri in alcune posizioni per evitare confusione visiva su terminali a bassa risoluzione, asimmetria nei valori di conversione per rilevare gli errori di trasposizione più comuni.
La struttura completa blocco per blocco, con il significato di ogni singola posizione, è documentata nella guida su come si legge il codice fiscale. Questa pagina si concentra sul perché tecnico di ogni scelta progettuale e su come implementarla correttamente.
Le Scelte Tecniche di Cognome e Nome: Perché Funzionano così
La Compressione del Cognome: Consonanti Prima delle Vocali
La gerarchia consonanti-vocali-X non è arbitraria. Le consonanti di un cognome italiano hanno un potere discriminante statisticamente superiore alle vocali: due cognomi con le stesse consonanti in ordine (RSS per Rossi, Russo, Rossini) sono già una minoranza rispetto all'universo dei cognomi. Aggiungere le vocali solo quando le consonanti sono insufficienti mantiene il massimo contenuto informativo nel minimo numero di caratteri.
Il trattamento dei cognomi composti come stringa continua, ignorando spazi e apostrofi, risponde allo stesso principio: eliminare ambiguità interpretative che avrebbero generato calcoli diversi per lo stesso cognome a seconda dell'operatore che lo elaborava.
La Regola delle 4 Consonanti nel Nome: la Scelta Progettuale
La regola che per nomi con quattro o più consonanti si usano la prima, la terza e la quarta saltando la seconda è la scelta che aumenta di più la capacità discriminante del blocco nome. Prendere le prime tre consonanti per nomi comuni con molte consonanti, come Roberto o Giovanni, avrebbe prodotto collisioni frequenti tra nomi diversi che condividono lo stesso prefisso consonantico. Saltare la seconda consonante rompe quella simmetria e riduce le collisioni in modo statisticamente significativo.
Questa è anche la regola che genera il maggior numero di errori nelle implementazioni di terze parti. Un calcolatore che applica la regola standard a tutti i nomi indipendentemente dal numero di consonanti produce un codice sbagliato per qualsiasi nome con quattro o più consonanti, senza segnalare alcun errore.
La Codifica della Data di Nascita: le Decisioni Tecniche
Anno su Due Cifre: il Compromesso del 1974
Ridurre l'anno alle ultime due cifre è stato un compromesso esplicito di compatibilità con i sistemi di archiviazione dell'epoca, dove ogni carattere aggiuntivo aveva un costo reale in termini di spazio su scheda perforata e larghezza di modulo. Nel 1974 l'ambiguità di secolo era irrilevante: nessun sistema dell'epoca prevedeva di dover gestire codici per persone nate dopo il 2000 o prima del 1900. Cinquant'anni dopo, quella scelta è rimasta invariata per retrocompatibilità con tutti gli archivi e i sistemi esistenti.
Il Mese come Lettera: Perché Non Due Cifre Numeriche
Usare una lettera per il mese invece di due cifre numeriche (01–12) ha liberato una posizione rispetto all'alternativa, consentendo di mantenere il codice a 16 caratteri totali anziché 17. Le 12 lettere scelte non sono consecutive perché alcune lettere dell'alfabeto, come F e I, presentavano troppa somiglianza visiva con le cifre 1 e 5 sui terminali e sulle stampanti a aghi dell'epoca. La sequenza è stata ottimizzata per la leggibilità su hardware a bassa risoluzione, non per la memorizzabilità umana. Per la tabella completa e gli errori di lettura più comuni, la pagina dedicata alle lettere dei mesi nel codice fiscale è il riferimento diretto.
Giorno e Sesso in Due Cifre: l'Eleganza dell'Algoritmo
Codificare giorno e sesso nello stesso campo da due cifre è la scelta più elegante dell'intero sistema. Aggiungere 40 al giorno delle donne garantisce che i range maschile (01–31) e femminile (41–71) non si sovrappongano mai, trasformando la distinzione di sesso in una semplice soglia numerica senza bisogno di un bit o un campo aggiuntivo. Un campo separato avrebbe richiesto un ulteriore carattere nel codice; la sovrapposizione dei range avrebbe richiesto logica condizionale complessa. Il meccanismo +40 risolve entrambi i problemi in zero caratteri aggiuntivi.
Il Codice Belfiore: Come Funziona l'Assegnazione (Posizioni 12–15)
Le posizioni 12–15 contengono il codice Belfiore: un codice catastale di quattro caratteri alfanumerici assegnato dall'Agenzia delle Entrate a ogni comune italiano e a ogni Stato estero di nascita. Non è un CAP né una sigla automobilistica ed è completamente indipendente da entrambi.
La separazione tra codici comunali e codici esteri è netta e visiva: tutti i codici degli Stati esteri iniziano con Z, tutti i codici dei comuni italiani iniziano con un'altra lettera. Questo permette di identificare a colpo d'occhio se una persona è nata in Italia o all'estero senza consultare nessuna tabella.
Un dettaglio implementativo critico riguarda i comuni soppressi: quando un comune viene accorpato o rinominato, il suo codice Belfiore storico non viene trasferito al comune che lo assorbe ma rimane assegnato al comune originale. Chi è nato in un comune che non esiste più deve usare il codice in vigore alla data di nascita. Qualsiasi implementazione che usa solo la lista attuale dei comuni produce risultati errati per una percentuale non trascurabile di codici fiscali reali.
Come Viene Generata l'Ultima Lettera: l'Algoritmo di Controllo
Il 16° carattere, il carattere di controllo (CIN), viene calcolato applicando un algoritmo a somma ponderata ai primi 15 caratteri. La distinzione tra posizioni dispari e pari, con due tabelle di conversione diverse, è la scelta che rende l'algoritmo sensibile non solo agli errori su singolo carattere ma anche agli errori di trasposizione, cioè lo scambio di due caratteri adiacenti che è statisticamente l'errore di battitura più frequente. Una tabella unica per tutte le posizioni non avrebbe questa proprietà.
Il risultato è che modificare qualsiasi singolo carattere tra i 15 produce quasi sempre un CIN diverso, e lo scambio di due caratteri adiacenti viene rilevato nella quasi totalità dei casi. Il calcolo è interamente locale e deterministico: non richiede connessione a reti esterne ed è eseguibile istantaneamente su qualsiasi dispositivo.
Le tabelle di conversione complete con tutti i valori per entrambe le serie di posizioni, la tabella di conversione del resto in lettera e un esempio numerico completo riga per riga sono nella pagina dedicata a come funziona e come si calcola il carattere di controllo del codice fiscale.

Algoritmo Inverso: Estrarre i Dati da un Codice Fiscale Esistente
L'algoritmo inverso applica le stesse regole del DM 1974 in direzione opposta: a partire da un codice a 16 caratteri, si estraggono data di nascita, sesso e comune di nascita. Il processo è deterministico per la data e il luogo. Non lo è per il nome e il cognome: da tre consonanti non è possibile risalire univocamente al cognome completo, perché molti cognomi diversi producono la stessa tripletta consonantica.
Il punto critico dell'algoritmo inverso è la verifica del CIN prima di procedere alla decodifica. Se il carattere in posizione 16 non corrisponde al risultato dell'algoritmo applicato ai 15 precedenti, il codice contiene un errore di trascrizione oppure è un codice omocodico, nel qual caso le posizioni numeriche contengono lettere che devono essere convertite nelle cifre originali prima che la decodifica produca dati corretti.
Come Implementare l'Algoritmo Codice Fiscale: Java, Python e Excel
Implementazione in Java: i Punti Critici
In Java l'algoritmo si struttura con due array statici per i valori dispari e pari e un metodo che itera sui primi 15 caratteri. I punti critici che generano errori nelle implementazioni reali sono tre.
Primo: normalizzazione obbligatoria in maiuscolo prima dell'elaborazione. Un input non normalizzato produce un risultato silenziosamente errato senza sollevare eccezioni.
Secondo: tutti i 15 caratteri devono essere trattati come char, mai come int. I codici omocodici contengono lettere nelle posizioni numeriche: qualsiasi cast a int su quei caratteri genera un'eccezione a runtime che interrompe il flusso senza gestione dell'errore.
Terzo: l'indice Java parte da 0, ma l'algoritmo conta le posizioni da 1. La posizione 1 dell'algoritmo corrisponde all'indice 0 di Java, quindi la distinzione pari/dispari si inverte rispetto all'intuizione: index%2==0 in Java corrisponde a posizione dispari nell'algoritmo. Questa inversione è la fonte del bug più frequente nelle implementazioni Java del codice fiscale.
Implementazione in Python: Dizionari e Gestione Omocodia
In Python l'algoritmo del codice fiscale si esprime con due dizionari odd_values e even_values e una funzione che itera con enumerate. La stessa inversione indice/posizione di Java si applica: index%2==0 corrisponde a posizione dispari.
Il caso omocodia in Python richiede un passaggio di normalizzazione preventiva: convertire le eventuali lettere omocodia (L, M, N, P, Q, R, S, T, U, V) nelle cifre corrispondenti prima di applicare le tabelle. Senza questo passaggio, la funzione calcola un CIN su un input che mescola il codice modificato con le tabelle del codice standard, producendo un risultato sempre errato per i codici omocodici.
Lo stesso schema di dizionari si adatta senza modifiche strutturali a PHP, C#, Go, Kotlin e Swift. La logica è identica; cambia solo la sintassi.
Implementazione in Excel: Dove la Maggior Parte degli Esempi Online è Sbagliata
La formula Excel per il calcolo del codice fiscale è tecnicamente possibile ma presenta tre problemi ricorrenti nelle implementazioni che si trovano online.
Il primo è usare una sola tabella di lookup per tutte le posizioni invece di due tabelle distinte. Questo produce un CIN sistematicamente sbagliato senza che la formula segnali alcun errore.
Il secondo è non gestire la distinzione pari/dispari correttamente. La colonna ausiliaria da 1 a 15 con MOD(n;2) è il modo più leggibile; in alternativa si può usare MOD(COLONNA();2) se si lavora orizzontalmente, ma l'inversione indice/posizione si applica anche qui.
Il terzo è non normalizzare l'input in maiuscolo. VLOOKUP su una tabella in maiuscolo con un input in minuscolo restituisce un errore #N/D silenzioso se la funzione non è avvolta in MAIUSC().
Per chi usa Excel per calcolare l'età dal codice fiscale, la formula specifica con il passaggio di decodifica della data è già documentata nella pagina dedicata al calcolo dell'età dal codice fiscale.
Per chi vuole integrare la validazione in un flusso applicativo senza implementare l'algoritmo manualmente, le nostre API per la validazione del codice fiscale sono la via diretta.
Verifica e Controllo: Cosa Può e Cosa Non Può Rilevare l'Algoritmo
Il Limite Strutturale della Verifica Algoritmica
La verifica algoritmica del codice fiscale, cioè il controllo che il CIN in posizione 16 corrisponda al risultato del calcolo sui 15 precedenti, è un controllo di coerenza matematica interna. Rileva errori di trascrizione e trasposizione. Non verifica che il codice esista nell'anagrafe tributaria, non verifica che sia stato assegnato a una persona reale e non verifica che i dati anagrafici codificati corrispondano a quelli del titolare.
Un codice costruito con dati inventati ma formalmente corretti supera la verifica algoritmica. Un codice ufficialmente assegnato a un soggetto omocodico può fallire la verifica algoritmica sul codice standard, perché il CIN è stato ricalcolato sulla variante con le lettere di sostituzione.
Omocodia e Ricalcolo del CIN: il Caso che Blocca le Implementazioni
Quando l'Agenzia delle Entrate assegna un codice omocodico, alcune cifre nelle posizioni numeriche vengono sostituite con lettere secondo la tabella fissa. Dopo ogni sostituzione il CIN viene ricalcolato sull'intera stringa modificata. Questo ha una conseguenza diretta per chi implementa la validazione: non è possibile costruire correttamente un codice omocodico sostituendo una cifra con la lettera corrispondente senza ricalcolare anche il CIN. Il codice risultante avrebbe una lettera giusta in posizione interna ma un CIN sbagliato, e verrebbe rifiutato da qualsiasi sistema che implementa correttamente l'algoritmo di controllo.
Nelle discussioni tecniche tra sviluppatori italiani su come migliorare il sistema di gestione dell'omonimia, questo è il punto identificato come la fonte di errori più sottile nell'integrazione di validatori CF in applicazioni esterne. Chi vuole approfondire come riformare il sistema di omonimia e le proposte alternative può trovare il dibattito tecnico tra gli sviluppatori che hanno discusso questi limiti.
Conclusione
L'algoritmo del codice fiscale italiano definito dal DM 12/03/1974 è uno degli standard tecnici più longevi in uso su scala nazionale. Cinquant'anni di invarianza significano che la stessa logica progettuale degli anni Settanta, con i suoi compromessi e le sue eleganze, governa ancora ogni sistema che gestisce identità fiscali in Italia.
Conoscere il perché tecnico di ogni scelta, dalla regola delle 4 consonanti alla scelta delle 12 lettere per i mesi, fino all'asimmetria delle tabelle CIN, permette di implementare la validazione correttamente, di anticipare i casi limite e di non introdurre bug silenziosi che producono risultati sbagliati senza segnalare errori. Per chi vuole approfondire esclusivamente il calcolo del carattere di controllo con le tabelle complete, la pagina dedicata al carattere di controllo del codice fiscale tratta quel componente in modo esaustivo. Per chi vuole usare la validazione direttamente senza implementare nulla, le nostre API per la validazione del codice fiscale sono la via più rapida.
Domande Frequenti sull'Algoritmo del Codice Fiscale
Qual è il decreto che definisce l'algoritmo del codice fiscale?
Il riferimento principale è il Decreto Ministeriale del 12 marzo 1974, che stabilisce le regole di estrazione di cognome e nome, la codifica della data di nascita, il codice Belfiore e le regole di omocodia. Il calcolo del carattere di controllo è stato formalizzato con il Decreto Ministeriale n. 345 del 23 dicembre 1976.
Perché la regola delle 4 consonanti nel nome salta la seconda e non la prima o la terza?
Saltare la seconda consonante massimizza la distinzione tra nomi che condividono un prefisso consonantico comune. Saltare la prima avrebbe eliminato il carattere più identificativo; saltare la terza avrebbe prodotto collisioni simili a prendere le prime tre. La scelta della seconda come elemento da escludere è quella che riduce statisticamente il numero di collisioni tra nomi diversi nelle posizioni 4–6.
Perché l'anno nel codice fiscale usa solo due cifre invece di quattro?
È un compromesso di compatibilità con i sistemi di archiviazione del 1974, dove ogni carattere aggiuntivo aveva un costo reale. La scelta ha creato un'ambiguità di secolo irrilevante nel 1974 ma presente oggi per i nati dopo il 2000. Non è stata modificata per garantire retrocompatibilità con tutti gli archivi esistenti.
Come verificare l'ultima lettera del codice fiscale?
Si applica l'algoritmo pari/dispari ai 15 caratteri precedenti e si verifica che il risultato corrisponda al 16° carattere. Le tabelle di conversione complete con tutti i valori e un esempio numerico riga per riga sono nella pagina dedicata al carattere di controllo del codice fiscale.
Come gestire i codici omocodici in Java e Python?
Aggiungere un passaggio di normalizzazione preventiva che converte le lettere omocodia (L, M, N, P, Q, R, S, T, U, V) nelle cifre corrispondenti (0–9) prima di applicare le tabelle. Senza questo passaggio, il CIN viene calcolato su un input ibrido che mescola il codice omocodico con le tabelle del codice standard, producendo sempre un risultato errato per quei codici.
L'algoritmo funziona per i codici fiscali delle aziende?
No. Le persone giuridiche ricevono un codice fiscale numerico a 11 cifre con una cifra di controllo calcolata con un algoritmo di tipo Luhn, completamente diverso dall'algoritmo delle persone fisiche descritto in questa pagina.

Fonti e Riferimenti Normativi
- Decreto Ministeriale 12 marzo 1974, testo integrale dell'algoritmo ufficiale (Normattiva)
- Decreto Ministeriale n. 345 del 23 dicembre 1976, formalizzazione del calcolo del CIN (Normattiva)
- Agenzia delle Entrate, servizio di verifica ufficiale del codice fiscale
- Discussione tecnica tra sviluppatori italiani sull'algoritmo e le sue limitazioni (ItalyInformatica)
Prova lo strumento di decodifica
Inserisci un codice fiscale e scopri subito data di nascita, sesso e comune. Tutto nel browser.
Decodifica un codice fiscale