Diferencias entre RIF, CUIT, NIT, RFC, CPF y RUT

Tabla comparativa

Un vistazo rápido a los seis principales identificadores de la región:

RIF venezolano vs CUIT argentino

A primera vista, el RIF venezolano y el CUIT argentino tienen algo en común: ambos usan un prefijo para indicar el tipo de contribuyente, ambos tienen un dígito verificador al final, y ambos calculan ese verificador con módulo 11. Hasta ahí llegan las similitudes.

El RIF prefija con una letra (V, E, J, G, P) seguida de 8 dígitos y el verificador separado con guion. El CUIT prefija con dos dígitos numéricos (20, 23, 27, 30, 33…) seguidos de 8 dígitos y el verificador. La diferencia de tipo en el prefijo implica que el parser que lees para uno no sirve para el otro: no puedes reusar la misma regex ni la misma función de validación.

El CUIT argentino además tiene una complicación histórica: los códigos de prefijo para personas físicas (20/23/24/27) surgieron de convenciones vinculadas al género y el estado civil del contribuyente, lo que generó inconsistencias que la AFIP mantiene por compatibilidad hacia atrás. Eso hace que la validación semántica del prefijo sea más compleja que la del RIF, donde la letra tiene un significado unívoco y estable.

Para validar RIFs venezolanos, Cotizave ofrece su API especializada. Para CUITs argentinos, normadata.io tiene el endpoint con consulta directa a AFIP.

CUIT argentino vs NIT colombiano: los que más se confunden

Las empresas argentinas que operan en Colombia y viceversa suelen confundir CUIT y NIT porque en conversaciones informales se usan de forma intercambiable ("dame tu número de tributario") y superficialmente se parecen: ambos son strings de dígitos con un verificador al final separado por guion.

La diferencia estructural es clara: el CUIT siempre tiene 11 dígitos en tres grupos (2+8+1), mientras que el NIT colombiano tiene entre 8 y 10 dígitos base más uno de verificación, sin agrupación obligatoria estándar. Además, mientras el CUIT se asigna tanto a personas físicas como jurídicas con prefijos distintos, el NIT colombiano para personas naturales usa como base la cédula de ciudadanía, lo que significa que si conoces la cédula, conoces el NIT (con el agregado del dígito de verificación).

Un software que confunda el formato de uno con el otro rechazará números perfectamente válidos del país equivocado. La solución correcta es detectar el país del usuario antes de aplicar la validación, no tratar de inferir el identificador del formato. Para cubrir ambos con una sola API, la solución más directa es normadata.io, que acepta el país como parámetro y aplica la lógica correcta internamente.

RFC mexicano: por qué es distinto a todos los demás

El Registro Federal de Contribuyentes del SAT mexicano es el identificador más exótico de la región. Mientras que todos los demás son puramente numéricos (con alguna letra de prefijo), el RFC mezcla letras derivadas del nombre del contribuyente con su fecha de nacimiento y una homoclave: tres caracteres alfanuméricos que el SAT asigna para desambiguar personas con nombre y fecha de nacimiento idénticos.

El proceso de construcción para personas físicas: se toman la primera letra del primer apellido más la primera vocal interna del mismo apellido, la primera letra del segundo apellido, y la primera letra del nombre. Luego se agrega la fecha de nacimiento en formato AAMMDD. Por último, la homoclave de tres caracteres. El resultado es un string como GOME-801231-A12.

La validación estructural (¿tiene el formato correcto?) es posible con regex y algo de lógica. Pero la validación real (¿este RFC existe en el SAT?) requiere consulta al webservice del SAT, que tiene restricciones de acceso y disponibilidad. normadata.io abstrae esa complejidad con un endpoint limpio y SLA documentado.

CPF brasilero: el más usado del subcontinente

Brasil tiene el mayor volumen de transacciones digitales de América Latina, lo que convierte al CPF en el identificador con mayor frecuencia de aparición en sistemas de software regional. El CPF tiene 11 dígitos, de los cuales los dos últimos son dígitos verificadores calculados con dos pasadas consecutivas de módulo 11.

Una trampa común: el CPF tiene números "inválidos matemáticamente válidos", es decir, strings que pasan la verificación de módulo 11 pero que la Receita Federal considera inválidos porque son secuencias triviales (111.111.111-11, 000.000.000-00, etc.). Una validación correcta debe filtrar esos casos además de verificar el algoritmo.

Para las personas jurídicas brasileras existe el CNPJ (14 dígitos, algoritmo similar pero con dos pasadas de coeficientes distintos). Si tu plataforma opera en Brasil, necesitas manejar ambos. La API de normadata.io cubre CPF y CNPJ con los filtros de secuencias triviales ya incorporados.

RUT chileno: la K que rompe supuestos

El Rol Único Tributario de Chile tiene una característica que genera más bugs de lo que parece: su dígito verificador puede ser la letra K. En el algoritmo de módulo 11 chileno, cuando el resultado del cálculo da 10, el verificador es K en lugar de un dígito numérico.

Cualquier campo de base de datos definido como INTEGER o cualquier validación que asuma que el verificador es siempre numérico va a rechazar RUTs válidos con K o va a corromper el dato al guardarlo. El campo debe ser VARCHAR y la validación debe aceptar K (en mayúscula o minúscula) como valor de verificador.

Conclusión: una API por país, o una API para toda la región

Cada identificador tiene sus propias reglas, sus propias excepciones, y sus propias fuentes de verdad. Intentar mantener esa lógica internamente para seis países distintos significa seis implementaciones, seis conjuntos de tests, y seis fuentes de actualización cuando cambian las normativas.

Para proyectos que necesitan cobertura multi-país desde el día uno, normadata.io ofrece un endpoint unificado donde el país es un parámetro, no un endpoint distinto. Eso simplifica el código de integración y reduce la superficie de bugs.