El formato de número de VAT es una de esas cosas que parecen universales hasta que intentas validarlas de verdad. Ese número, que en español también se ve como número de IVA o número de identificación a efectos del impuesto sobre el valor añadido, es la referencia con la que una empresa se identifica ante la administración tributaria de su país para operar con este impuesto. Aquí verás por qué su estructura cambia tanto de un territorio a otro, cómo distinguir «está bien escrito» de «está registrado» y qué se puede automatizar sin inventarse reglas.
¿Qué es el número de VAT y para qué se pide?
Es el número con el que un sujeto queda identificado a efectos del impuesto sobre el valor añadido. Aparece en las facturas entre empresas, en las declaraciones y en los trámites de devolución o de recuperación del impuesto pagado en otro país.
La razón por la que se pide tanto en contextos internacionales es que este impuesto funciona por territorio. Una factura entre dos empresas del mismo país y una factura entre empresas de países distintos no se tratan igual, y la administración necesita saber a quién corresponde cada operación. El número es esa referencia.
De ahí salen tres ideas que conviene tener claras desde el principio:
- El número lo emite la administración tributaria, no el registro mercantil.
- Su estructura la decide cada país según su normativa.
- Que un número esté bien escrito no implica que exista ni que esté en situación regular.
La segunda idea es la que rompe casi todas las validaciones demasiado estrictas, y la tercera es la que rompe casi todas las conclusiones demasiado rápidas.
Una estructura parecida, reglas distintas
Lo que más se repite es el arranque: dos letras que identifican el país, seguidas del cuerpo del número. Es una convención extendida porque facilita la lectura de una factura sin conocer al emisor, pero no es una ley universal y convive con países que usan prefijos de otra forma o que no usan prefijo en absoluto.
El cuerpo posterior también varía. Algunos territorios usan solo dígitos, otros mezclan letras y dígitos, y el conjunto puede incluir un dígito de control cuya posición y cálculo dependen de la normativa local. La comparación siguiente resume lo que cambia:
| Aspecto | Lo que se observa con frecuencia | Consecuencia para tu sistema |
|---|---|---|
| Prefijo de país | Dos letras al principio | Un campo de texto, no un número |
| Cuerpo | Dígitos, o letras y dígitos | No filtres por tipo de carácter |
| Longitud | Distinta según el país | No fijes una longitud única |
| Separadores | Espacios, guiones o puntos | Normaliza antes de comparar |
| Dígito de control | Presente en algunos territorios | Verifícalo solo donde exista |
La conclusión práctica es que el número de VAT es un dato de texto con reglas que dependen de un valor que ya tienes en la ficha: el país. Si ese país no está, la validación de formato no tiene nada que aplicar.
¿Es lo mismo un formato correcto que un número en el registro?
No, y esta es la confusión más cara de todo este terreno. Que un número tenga la estructura esperada solo significa que podría ser un número de VAT de ese país. Que esté dado de alta es otra pregunta, y la responde una consulta al registro correspondiente.
En el ámbito de la Unión Europea existe un servicio público de consulta que permite comprobar si un número de identificación a efectos del impuesto sobre el valor añadido está registrado. Es gratuito y accesible, y basta con conocer su nombre para encontrarlo. Lo importante no es memorizar la dirección, sino entender que ese servicio existe y que responde a la segunda pregunta, no a la primera.
Esa separación se traduce en dos comprobaciones que nunca debes mezclar en el mismo paso:
- Comprobación local. Forma, longitud razonable y, donde exista, dígito de control. No sale a la red, es inmediata y sirve para dar respuesta al usuario mientras escribe.
- Comprobación en el registro. Consulta a la fuente oficial. Tarda, puede fallar y su resultado tiene fecha de caducidad.
Si las juntas, el formulario se vuelve lento y frágil, y además empiezas a tratar un problema de red como si fuera un error de tecleo.
¿Qué se puede automatizar sin inventarse las reglas?
Se puede automatizar bastante, siempre que aceptes que no vas a implementar la normativa de todos los países. Un enfoque realista para una empresa que opera en varios mercados:
- Normaliza la entrada: mayúsculas, sin espacios ni separadores.
- Comprueba que el prefijo de país es uno de los que atiendes.
- Aplica una validación de forma amplia para ese país y solo para ese país.
- Consulta el registro oficial solo en los flujos que lo necesiten de verdad.
- Guarda el resultado de la consulta con la fecha en que se hizo.
El paso tres es donde se cometen los abusos, porque es tentador escribir de memoria las reglas de longitud de cada país. Si no vas a mantener esas reglas al día, es más honesto comprobar solo que la forma es plausible —caracteres admitidos y un rango de longitud generoso— y dejar la verificación de fondo al paso cuatro.
También conviene decidir qué hacer cuando la consulta al registro no responde. Un servicio externo puede estar caído, lento o devolver un error ambiguo. Tratar ese fallo como «el número no existe» es un error clásico: la respuesta correcta es distinguir los tres estados, a saber, válido, no válido y no comprobado.
En el generador de este sitio
En el generador de datos de empresa para pruebas puedes elegir un país y obtener un número de VAT con la forma que ese territorio usa, acompañado del nombre, la forma jurídica, el domicilio social y el número de registro de la misma empresa ficticia. Es el material adecuado para comprobar que tu formulario acepta lo que debe aceptar y rechaza lo que debe rechazar.
Todo lo que se genera es sintético. Está pensado para pruebas de software, demostraciones y entornos de desarrollo; no corresponde a ningún sujeto registrado, no acredita ninguna situación fiscal ante nadie y no debe usarse para emitir facturas ni para solicitar devoluciones.
Para quien programa
Aquí es donde más se nota si el campo estaba bien pensado desde el principio. Cinco decisiones que ahorran meses de incidencias:
- Dos capas separadas y con nombres distintos. Una función de forma y una función de consulta. Nunca una que haga las dos cosas y devuelva un valor booleano, porque entonces nadie sabe qué falló.
- Nada de implementar la normativa de cada país. Las reglas cambian y tú no vas a ir detrás de todas. Si necesitas alguna, guárdala como configuración con una nota de su origen y una fecha de revisión.
- Resultado con motivo. Devuelve un estado que distinga forma inválida, no encontrado, no comprobado y servicio no disponible. El mensaje que ve el usuario sale de ese estado.
- Tiempo de espera y reintento. La consulta al registro debe tener un límite de tiempo razonable y no debe bloquear el guardado del formulario. Si la usa un proceso por lotes, separa el lote de la respuesta al usuario.
- Caché con fecha. El estado de alta puede cambiar. Guarda el resultado con la fecha de la consulta y decide cuánto tiempo lo consideras fresco, en lugar de conservarlo para siempre.
Y una precisión sobre el almacenamiento: el número de VAT es texto. Pasarlo a entero destruye los prefijos de letras y los ceros iniciales, y en muchos países el cuerpo del número admite ambos tipos de carácter.
Siguientes pasos
Si lo que necesitas ahora es un ejemplo con la forma correcta para probar un formulario, el generador de datos de empresa lo devuelve en un par de clics. Si el problema es que no tienes claro qué identificador te están pidiendo, el artículo sobre el número de registro de empresa y el de validación del número de identificación fiscal despejan esa duda, porque en la práctica conviven tres números distintos en la misma ficha. Y si estás montando la batería de pruebas de un formulario de facturación, los casos de prueba del formulario de facturación recogen las combinaciones que más fallos destapan.