Vai al contenuto
Validazione anagrafica

Validatore anagrafica italiana

Verifica formale di Codice Fiscale (DM 12/03/1974 con calcolo CIN), Partita IVA (Luhn a 11 cifre), IBAN (MOD-97 ISO 13616), CAP (formato e mapping regione) e PEC (regex e lista domini certificati italiani). Single check con feedback in tempo reale, batch CSV per liste fino a 10.000 righe, export JSON pronto per integrazione in gestionale.

Come usare il validatore

  1. 1

    Validazione singola

    Compila uno o più dei cinque campi (codice fiscale, partita IVA, IBAN, CAP, PEC) e premi Verifica. Per ogni campo compilato vedrai stato (valido/non valido), formato verificato, checksum verificato (dove applicabile) e dettagli aggiuntivi (es. provincia per CF, regione per CAP, dominio PEC riconosciuto).

  2. 2

    Batch CSV per liste lunghe

    Apri la tab Batch CSV, incolla le righe (header consigliato: cf, piva, iban, cap, pec). Il parser RFC 4180 gestisce virgole, escape con quote, valori con newline. Il tool produce una tabella con stato per ogni riga e ogni campo. Limit pratico: 10.000 righe (oltre il browser rallenta sensibilmente).

  3. 3

    Export JSON

    Apri la tab Output JSON: il tool produce un payload strutturato con risultato di tutte le validazioni della sessione. Pronto per essere incollato in API client, Postman, integration test o pipeline CI.

  4. 4

    Privacy zero-server

    I dati anagrafici reali (CF, P.IVA, IBAN dei clienti) non sono dati di test. Caricarli su un servizio web pubblico per validarli è una pratica sconsigliata sia in ottica GDPR che in ottica brand reputation. Tutta la logica qui è in JavaScript nel browser: nessuna richiesta XHR, nessun cookie analytics, nessun log lato server.

Perché un validatore offline è meglio di un'API REST

GDPR e proporzionalita'. Un codice fiscale o un IBAN sono dati personali (CF) e finanziari (IBAN). Caricarli su un servizio web di terze parti per validarli è una pratica diffusa ma sproporzionata: la validazione è un calcolo deterministico locale, non richiede nessuna lookup remota. Mandare quei dati a un server esterno espone il titolare del trattamento a un'analisi di base giuridica supplementare (legittimo interesse? consenso?) per qualcosa che non serve.

Latenza e disponibilità. Un'API REST aggiunge un round-trip per ogni validazione: 50-200 ms in condizioni normali, 1-3 secondi se il provider ha problemi, errore se l'API è giu'. Un validatore offline ritorna in <1 ms a record. Per batch da migliaia di righe la differenza è fra istantaneo e dieci-trenta minuti reali.

Algoritmi documentati e auditabili. Le validazioni qui usano algoritmi standard pubblicati: codice fiscale dal Decreto del Ministero delle Finanze del 12 marzo 1974 (controllo CIN modulare 26); partita IVA dalla circolare ministeriale che definisce la verifica modulare 10 (variante italiana del Luhn); IBAN dalla ISO 13616 con MOD-97. Sono algoritmi deterministici noti da decenni. Reimplementarli lato client è centinaia di righe di codice testabili contro RFC e test vector ufficiali.

Caveat di scope. Questo strumento valida la correttezza formale degli identificatori (formato + checksum). NON verifica che siano realmente esistenti nei registri (Anagrafe Tributaria per CF/P.IVA, registro IBAN bancario, ufficio postale per CAP). Per quella verifica serve un'integrazione con i sistemi di Agenzia delle Entrate o servizi commerciali. Il caso d'uso tipico di questo validatore e': pulire dataset prima di import in gestionale, intercettare errori di battitura in form di registrazione, sanity check su anagrafiche legacy.

Algoritmi implementati

Codice Fiscale (16 char, DM 12/03/1974). Pos 1-3 cognome (consonanti+vocali, padding X), pos 4-6 nome (1+3+4 consonanti per >=4 consonanti, altrimenti tutte consonanti+vocali, padding X), pos 7-8 anno (ultime 2 cifre), pos 9 mese (A-E-H-L-M-P-R-S-T), pos 10-11 giorno (per donne +40), pos 12-15 codice catastale comune (es. F205 = Milano, H501 = Roma), pos 16 CIN. Il CIN si calcola con due tabelle di conversione (caratteri dispari e pari) e modulo 26 -> A-Z. Il tool verifica formato e CIN; non decodifica il comune (richiederebbe il database catastale di 8.000 entry).

Partita IVA (11 cifre). Le prime 7 sono il codice azienda, le successive 3 il codice ufficio provinciale, l'ultima è il check Luhn (variante italiana modulare 10): somma cifre in posizione dispari (1, 3, 5, 7, 9) + somma cifre in posizione pari (2, 4, 6, 8, 10) ognuna raddoppiata e ridotta di 9 se >9. Check digit = (10 - (somma % 10)) % 10. Vale anche come CF di persona giuridica.

IBAN (variabile, ISO 13616). Riarrangia: codice paese + check digit IBAN spostati alla fine, sostituisce lettere con numeri (A=10, B=11..., Z=35), calcola modulo 97. IBAN valido se mod = 1. L'algoritmo usa modulo a chunk per evitare overflow numerico (no BigInt necessario).

CAP italiano (5 cifre). Validazione formale del formato (5 cifre numeriche) + mapping primi 1-2 caratteri al macro-territorio (00xxx Roma e Lazio sud, 10xxx Torino e Piemonte ovest, 20xxx Milano area, 30xxx Veneto, 40xxx Emilia-Romagna...). Non sostituisce un database CAP completo (che ha 200.000+ entry per via dei codici di avviamento postale aziendali, ma è utile come sanity check.

PEC italiano. Regex email standard (RFC 5322 semplificata) + verifica che il dominio sia in lista nota di domini PEC italiani (Aruba, Legalmail/InfoCert, Postecert, Actalis, Namirial, Register.it, ecc). Lista non esaustiva: ci sono provider piccoli e PEC custom su domini propri. Il flag verde indica 'molto probabilmente PEC', il giallo 'formato email valido ma dominio non riconosciuto come PEC'.

Glossario

Termini tecnici usati in questa pagina, spiegati in due righe.

Codice Fiscale #
Identificativo univoco delle persone fisiche italiane (16 caratteri alfanumerici) e delle persone giuridiche (11 cifre, coincide con la P.IVA). Definito dal DM 12 marzo 1974 (Min. Finanze).
CIN #
Carattere di controllo del codice fiscale (pos 16). Calcolato dai primi 15 caratteri tramite due tabelle di conversione (dispari/pari) e modulo 26. Permette di intercettare errori di battitura sui primi 15 caratteri.
Omocodia #
Quando due o più persone hanno gli stessi 15 caratteri di codice fiscale (cognome+nome+data+sesso+comune coincidono). Risolta dall'Agenzia delle Entrate sostituendo cifre numeriche con lettere secondo regole specifiche, generando 128 varianti possibili.
Partita IVA #
Codice identificativo a 11 cifre attribuito dall'Agenzia delle Entrate alle persone giuridiche e ai professionisti con P.IVA. Le prime 7 cifre sono il codice azienda, le successive 3 il codice ufficio, l'ultima il check Luhn.
Algoritmo di Luhn #
Metodo modulare 10 (mod-10) per validare numeri identificativi. Inventato da Hans Peter Luhn IBM nel 1954. Usato per partita IVA italiana, carte di credito (con varianti specifiche), numeri IMEI.
IBAN #
International Bank Account Number, ISO 13616. Lunghezza variabile per paese (IT: 27, DE: 22, GB: 22...). Check digit modulo 97 sui primi 2 caratteri (codice paese + check).
CAP #
Codice di Avviamento Postale italiano (5 cifre). Introdotto nel 1967, derivato dal regio decreto del 1900. I primi 2 caratteri identificano la macro-zona territoriale, gli ultimi 3 il distretto postale specifico.
PEC #
Posta Elettronica Certificata (DPR 68/2005). Email con valore legale di raccomandata con ricevuta di ritorno. Forniti da provider iscritti all'AGID (Aruba, InfoCert, Postecert, Actalis, Namirial, Register, ecc).
RFC 4180 #
Standard del 2005 che formalizza il formato CSV (Comma-Separated Values): record terminati da CRLF, campi separati da virgola, escape via quote doppie, valori con virgola/newline circondati da quote.

Domande frequenti sul validatore

Il validatore controlla che il CF sia realmente esistente all'Agenzia delle Entrate?
No. Verifica solo la correttezza formale (lunghezza, charset, CIN). Per la verifica anagrafica reale serve l'integrazione con il servizio Verifica CF/Partita IVA dell'Agenzia delle Entrate (servizio Entratel/Fisconline, gratuito ma con CAPTCHA e rate limit) oppure servizi commerciali tipo Cerved o Cribis. Il check formale qui intercetta il 80-90% degli errori di trascrizione: i casi rari di CF formalmente corretti ma non assegnati a nessuno richiedono la verifica online.
Posso validare codici fiscali di persone giuridiche?
Si. La P.IVA italiana (11 cifre) coincide con il CF della persona giuridica. Il tool ti permette di inserirla come 'P.IVA' con check Luhn dedicato. Se ti aspetti CF di 11 cifre per giuridica, usa il campo P.IVA, non quello CF (che valida 16 char per persone fisiche).
Il batch CSV gestisce file di grandi dimensioni?
Tecnicamente nessun limit hard-coded. Pratico: il parser RFC 4180 processa 10.000 righe in 1-3 secondi su hardware desktop medio. Oltre 50.000 righe il browser rallenta visibilmente (DOM updates, memoria). Per dataset enterprise serve uno script lato server (PHP/Python/Node) che usi le stesse formule di validazione.
Come gestite l'omocodia nei CF?
Riconosciamo le 128 varianti omocode standard (sostituzione di cifre numeriche con lettere O-L-Q-P-R-S-T-U-V-X). Il check CIN viene applicato sulla forma omocoda. Nota: il tool non distingue fra CF originale e variante omocoda: dichiara 'formato valido' in entrambi i casi. Per discriminarli serve la decodifica del campo data nascita (che contiene lettere se omocoda).
Il check IBAN funziona anche per IBAN non italiani?
Si. L'algoritmo MOD-97 ISO 13616 è identico per tutti i paesi: cambia solo la lunghezza attesa (IT: 27, DE: 22, FR: 27, GB: 22, ES: 24, NL: 18...). Il check digit dei primi 2 char è valido cross-country. Il tool accetta qualsiasi codice paese a 2 char che rispetti il formato BBAN del paese. Se hai un IBAN tedesco o britannico, incollalo: viene validato correttamente.
Cosa succede se inserisco una PEC su dominio non standard (custom)?
Il tool segna 'formato email valido ma dominio non riconosciuto come PEC' (giallo). Le PEC su domini custom (es. azienda con dominio proprio gestito tramite SLA con un provider AGID) sono possibili ma minoritarie. La verifica reale richiede: (1) record MX puntante a server PEC (impossibile da verificare senza DNS over HTTPS), (2) iscrizione AGID del provider. Senza queste due, il dominio può essere fake. Il flag giallo significa 'controlla manualmente'.
Il CAP da 00100 a 00199 è Roma?
Si, 00xxx è Roma e provincia, con sotto-distretti. 00121 è specifico per Lido di Ostia, 00187 per centro storico, 00198 per quartiere Trieste. Il tool mappa solo la macro-area (00=Roma, 10=Torino, 20=Milano...) per evitare di portare un database CAP da 50.000+ entry nel browser. Per la decodifica completa serve il database Poste Italiane (servizio commerciale).
Il payload JSON di output è compatibile con quale formato standard?
Schema custom semplice: array di oggetti, ogni oggetto ha le chiavi cf, piva, iban, cap, pec con sub-oggetto {value, valid, format, checksum, details}. Mappabile facilmente in qualsiasi schema custom (JSON Schema, OpenAPI). Per pipeline ETL: incolla il JSON come body di un POST verso il tuo endpoint di import, oppure usa jq per trasformazioni intermedie.
Ho una PEC come [email protected], come la valido?
Il dominio pec.aruba.it è nella lista riconosciuta del tool. Il check restituisce 'PEC valida' (verde). Le PEC Aruba sono il provider più diffuso in Italia (~40% del mercato), insieme a Legalmail/InfoCert (~30%) e Postecert/Poste (~15%).
Posso usare le formule di validazione nel mio gestionale PHP?
Si, gli algoritmi sono pubblici. Per CF, P.IVA, IBAN trovi implementazioni mature in librerie PHP open source: italia/codice-fiscale di Italia Foundation, league/iso3166 per i codici paese IBAN, laravel-validation-rules per le regole di validazione complete italiane. Le stesse formule di questo tool, in PHP server-side.

Stai costruendo un gestionale che valida codici fiscali, IBAN o PEC?

Questo validatore è utile per controlli puntuali e batch occasionali. Se devi integrare validazioni anagrafiche dentro un backend di produzione (gestionale, CRM, e-commerce, portale registrazione utenti), posso integrare le librerie corrette nel tuo stack PHP, Laravel, Symfony o Node.

Integra validazione nel tuo backend

Vuoi una stima realistica per il tuo progetto?

Wizard di 7 domande, 2 minuti, gratuito. Output: range di giorni-uomo, range di prezzo orientativo e raccomandazione di ingaggio. Tariffa di riferimento 300 euro al giorno. Pensato per progetti backend custom, integrazioni, audit di sicurezza o automazione AI.

Calcola il preventivo