Hace unos meses estaba integrando validación de identificadores fiscales en un proyecto. Busqué en Google, encontré una función de 30 líneas en JavaScript, la copié, la probé con cuatro casos y funcionó. La metí en el código y la olvidé.
Tres meses después, un usuario nos mandó un email: su CIF no validaba. Era un CIF perfectamente válido.
Ese día entendí que hay una diferencia entre implementar la validación y mantenerla correctamente.
El problema no es que sea difícil
Validar un NIF es sencillo en apariencia: 8 dígitos, una letra, módulo 23. Cualquier dev lo implementa en diez minutos.
El problema aparece cuando rascas un poco:
NIF: el algoritmo básico funciona, pero hay formatos especiales — NIFs K, L y M para casos específicos que muchas implementaciones directamente ignoran.
NIE: empieza por X, Y o Z, luego sigue el algoritmo del NIF con sustitución. La mayoría de regex que encontrarás online aceptan tanto 7 como 8 dígitos indistintamente, cuando el formato correcto depende del prefijo.
CIF: aquí es donde casi todo falla. El dígito de control puede ser una letra o un número dependiendo del tipo de entidad (primera letra del CIF). La mayoría de implementaciones lo aceptan indistintamente para todos los tipos, lo cual es incorrecto. Además, cuando (10 - suma % 10) % 10 === 0, el carácter de control debería ser J en ciertos casos — un edge case que genera bugs silenciosos muy difíciles de detectar.
IBAN: el algoritmo MOD-97 requiere aritmética con números muy grandes. En JavaScript necesitas BigInt, y en entornos donde no está disponible o se implementa mal, falla sin error visible.
Ninguno de estos bugs explota en desarrollo. Explotan en producción, con identificadores reales de usuarios reales.
El bug silencioso es el peor tipo de bug
Cuando una validación falla de forma visible — lanza una excepción, devuelve un error — lo detectas y lo corriges. El problema real con los bugs de validación fiscal es que aceptan identificadores inválidos sin avisar.
Un usuario introduce un CIF con el dígito de control incorrecto. Tu código dice "válido". El dato entra en base de datos. Meses después, cuando intentas hacer una operación fiscal con ese dato, el problema emerge — pero ya no sabes de dónde viene.
El mantenimiento que nadie contabiliza
Aunque implementes todo correctamente hoy, hay otro problema: la normativa puede cambiar.
España ha actualizado el formato de los identificadores fiscales en el pasado. Los formatos de NIE han evolucionado. Cuando eso pasa, alguien tiene que actualizar el código — y ese alguien podría no ser la misma persona que lo escribió, ni estar en el mismo equipo, ni recordar por qué se tomó cada decisión.
Con una API, ese problema es de quien mantiene la API. Tú consumes el endpoint, ellos mantienen los algoritmos actualizados.
Lo que hicimos
Construimos Valix — una API REST que valida NIF, NIE, CIF e IBAN usando los algoritmos oficiales, con detección automática del tipo de identificador y respuesta JSON estructurada.
import requests
response = requests.post(
"https://api.getvalix.io/v1/validate/trial",
json={
"items": [
{"value": "12345678Z", "type": "AUTO"},
{"value": "X1234567L", "type": "AUTO"},
{"value": "A12345674", "type": "AUTO"},
{"value": "ES9121000418450200051332", "type": "AUTO"}
]
}
)
resultado = response.json()
for item in resultado["results"]:
estado = "válido" if item["valid"] else f"inválido: {', '.join(item['errors'])}"
print(f"{item['value']} → {item['detected_type']} — {estado}")
Salida:
12345678Z → NIF — válido
X1234567L → NIE — válido
A12345674 → CIF — válido
ES9121000418450200051332 → IBAN — válido
El endpoint trial no requiere registro ni API key — 50 validaciones diarias por IP para que puedas probarlo antes de comprometerte con nada.
¿Cuándo tiene sentido implementarlo tú mismo?
Siendo honestos: si tu volumen de validaciones es muy bajo, el identificador que validas es siempre el mismo tipo y tienes tests exhaustivos con casos reales, implementarlo internamente puede tener sentido.
Pero si validas identificadores de usuarios de producción, mezclas tipos (NIF + NIE + CIF + IBAN), o simplemente no quieres dedicar tiempo a mantener esto — una API es la opción más sensata.
Recursos
- API y documentación: getvalix.io
- Ejemplos en Python, JavaScript, PHP y cURL: github.com/getvalix/valix-examples
- SDK para JavaScript/TypeScript: npm @valix/sdk
Disclaimer: soy el autor de Valix.
Top comments (0)