La validación de número de identificación fiscal es el proceso por el que se decide si el identificador tributario que alguien ha escrito puede aceptarse. El problema es que bajo esa etiqueta se esconden comprobaciones muy distintas, con costes y garantías muy distintas, y mezclarlas produce formularios lentos que rechazan datos correctos o que dan por buenos datos que no existen. Este artículo separa las capas, explica qué se puede afirmar en cada una y propone una forma de organizar el flujo para que el resultado sea útil de verdad.
¿Qué comprueba realmente una validación de identificación fiscal?
Depende de la capa. Hay tres, y conviene tenerlas nombradas por separado.
La primera es la capa de forma. Comprueba que lo escrito se parece a un identificador fiscal: longitud plausible, caracteres admitidos, prefijo coherente con el país. Es local, inmediata y no necesita red.
La segunda es la capa aritmética. Comprueba el dígito de control cuando el identificador lo incorpora. También es local y sirve para detectar errores de tecleo antes de gastar una consulta.
La tercera es la capa de registro. Comprueba si ese identificador corresponde a un contribuyente dado de alta. Requiere consultar una fuente oficial, tarda y puede fallar.
La mayoría de las discusiones sobre este campo se deben a que alguien está usando el resultado de una capa para responder a la pregunta de otra. Que la forma sea correcta no dice nada sobre el registro; que el dígito cuadre tampoco.
Un detalle importante: no todos los países incluyen dígito de control en su identificador fiscal, y no todos los publican si lo incluyen. Por eso no tiene sentido escribir de memoria qué país lleva dígito y cuál no; lo correcto es tratar esa característica como configuración.
¿Por qué el mismo identificador no valida en todos los países?
Porque su composición la fija la administración tributaria de cada territorio. Hay países donde el identificador de una persona jurídica y el de una persona física se construyen con reglas distintas, otros donde el número coincide con el de registro mercantil y otros donde se añade un prefijo para indicar la provincia o el tipo de contribuyente.
Esa diversidad se traduce en cuatro situaciones que tu sistema debe poder representar:
| Situación | Qué significa | Qué hacer |
|---|---|---|
| Forma válida y dígito correcto | Podría ser un identificador de ese país | Pasar a la capa de registro si el flujo lo exige |
| Forma válida y dígito incorrecto | Hay un error de transcripción | Rechazar y pedir corrección |
| Forma no reconocida | No encaja con lo esperado para ese país | Avisar sin bloquear si no hay regla fiable |
| Sin regla disponible | No hay validación fiable para ese país | Comprobar solo forma amplia y documentar la limitación |
La cuarta fila es la más incómoda y la más honesta. Cuando no tienes una regla fiable, inventarla es peor que reconocer que no la tienes: produce rechazos falsos que el usuario no puede resolver, porque el dato que escribe es correcto.
¿Qué se puede afirmar y qué no con el resultado?
Con una validación de forma puedes afirmar que el dato está bien escrito o mal escrito. Nada más.
Con una validación aritmética puedes afirmar que el dato no contiene un error de tecleo detectable. Tampoco más.
Con una consulta al registro puedes afirmar, en el momento de la consulta, que la fuente oficial reconoce ese identificador y devuelve cierta información asociada. Y esa afirmación caduca: la situación del contribuyente puede cambiar después.
Lo que nunca puedes afirmar a partir de una validación es que la empresa exista en el sentido jurídico pleno, que esté al corriente de sus obligaciones, que sea solvente, que sea de fiar o que la persona que teclea el número tenga derecho a usarlo. Esa lista de conclusiones es la fuente de casi todos los malentendidos sobre este campo.
Conviene además distinguir tres estados en la respuesta, y no dos. Un booleano de válido o no válido obliga a tratar «no he podido comprobarlo» como si fuera «no existe», y esa equivalencia es incorrecta. El tercer estado, no comprobado, es necesario para que un fallo de red no se convierta en un rechazo del usuario.
¿Cómo se organiza el flujo de validación?
Un flujo que funciona bien en producción sigue este orden:
- Normaliza la entrada y comprueba que el país del identificador está entre los que atiendes.
- Aplica la validación de forma de ese país y avisa al usuario en el momento.
- Si el identificador lleva dígito de control, verifícalo y rechaza solo cuando el cálculo no cuadra.
- Consulta el registro oficial únicamente en los pasos donde el proceso lo requiera.
- Guarda el resultado con la fecha y el origen de la consulta.
- Si la consulta falla, marca el dato como no comprobado y no como inválido.
Dos matices sobre el paso cuatro. El primero es que no todo flujo necesita consultar el registro: si solo estás guardando datos de contacto, una validación de forma puede ser suficiente y mucho más rápida. El segundo es que la consulta en línea tiene un coste de latencia y de disponibilidad, así que no debe bloquear el guardado del formulario ni ejecutarse en cada pulsación de tecla.
En el generador de este sitio
En el generador de datos de empresa para pruebas los identificadores que se generan respetan la forma que corresponde al país elegido, y la ficha incluye el nombre, el domicilio social y el tipo de empresa. Es exactamente el material que necesitas para ver si tu validación de forma rechaza datos bien construidos.
Todos los datos son sintéticos y se generan para pruebas de software, demostraciones y entornos de desarrollo. No corresponden a ningún contribuyente real, no acreditan ninguna situación ante la administración y no deben emplearse en trámites ni en facturación real.
Para quien programa
Aquí conviene resistir la tentación de escribir un validador universal. Cinco decisiones que sostienen el diseño:
- Tres resultados, no dos. Válido, inválido y no comprobado. El tercero es el que salva la experiencia cuando la fuente externa falla.
- Motivo estructurado. Cada resultado debe llevar un código de motivo que distinga fallo de forma, fallo de dígito, no encontrado, servicio no disponible y país sin regla.
- Reglas como datos. La longitud, el juego de caracteres y la presencia de dígito de control son configuración con su fuente y su fecha de revisión, no constantes dentro de una expresión regular.
- Sin expresiones regulares copiadas. Una expresión regular escrita para un país y aplicada a otro rechaza datos válidos. Si no tienes la regla, no la inventes: acepta forma amplia.
- Validación no bloqueante en la escritura. Valida al salir del campo o al enviar, y muestra el mensaje con la certeza que corresponde. Nunca presentes «no comprobado» como un error.
Y una recomendación sobre el almacenamiento: guarda el identificador como texto, normalizado para comparar pero conservando la forma original. Los prefijos alfabéticos y los ceros iniciales son parte del dato, no ruido de formato.
Siguientes pasos
Si necesitas ejemplos por país para probar el campo, el generador de datos de empresa los devuelve junto con el resto de la ficha. Para entender cómo se relacionan los distintos números de una misma empresa, las guías del número de registro de empresa y del formato de número de VAT cubren los otros dos identificadores que suelen convivir con este. Y si lo que estás montando es una batería de pruebas, los casos de prueba del formulario de facturación recogen las combinaciones que más fallos revelan.