Nordlet

← Blog

Automatización de la presentación de informes de IVA por país y validación VIES

Una guía práctica para desarrolladores que integran el cumplimiento del IVA de la UE en marketplaces y plataformas mediante una API de contabilidad en la nube.

Nordlet Team · · 15 min de lectura

La mayoría de los errores relacionados con el IVA en el código de una plataforma se originan en una sola suposición: que un resultado válido de VIES significa que se puede aplicar un tipo del 0%. No es así, y basarse en ese atajo produce declaraciones que parecen correctas hasta que un auditor pregunta por qué se aplicó una exención intracomunitaria sin pruebas de transporte o un registro coherente del lugar de entrega. La brecha entre "el número de IVA es correcto" y "esta operación recibe el tratamiento fiscal adecuado" es donde la mayoría de las integraciones fallan silenciosamente.

Esta guía explica cómo automatizar la presentación de informes de IVA por país y la validación VIES con una API de contabilidad en la nube, utilizando la API de contabilidad de Nordlet como contexto de implementación. El objetivo es conseguir un sistema que capture las pruebas correctas en el momento de la venta, registre asientos inmutables en el libro mayor y produzca datos listos para declarar agrupados por régimen y Estado miembro, sin necesidad de reconstruir totales en una hoja de cálculo más tarde.

Qué indica realmente VIES y qué no

VIES es el Sistema de Intercambio de Información sobre el IVA de la UE. Cuando envías un código de país y un número de IVA, consulta la base de datos nacional correspondiente en tiempo real y devuelve si esa información de IVA es válida o no. Ese es todo su ámbito. Confirma que un número está registrado y, cuando el Estado miembro lo admite, habilitado para el comercio intracomunitario.

No establece el derecho a exentar una entrega intracomunitaria. La Comisión Europea es explícita al respecto. Una respuesta favorable de VIES es una prueba más entre varias. Aun así, debes confirmar que el cliente es el destinatario real, que la operación califica como intracomunitaria, que existen pruebas de transporte o expedición y que la factura incluye la mención requerida sobre la inversión del sujeto pasivo (reverse charge).

Por lo tanto, la primera decisión de diseño es estructural: mantén el estado de VIES y el tratamiento del IVA en campos separados. Nunca vincules directamente viesStatus: valid con zeroRated: true. En el momento en que fusionas ambos conceptos, pierdes la capacidad de defender un tratamiento fiscal cuando se cuestionen las pruebas.

Requisitos previos antes de escribir código de integración

Antes de llamar a cualquier endpoint, define el alcance de lo que vas a declarar. Esta parte es rutinaria, pero omitirla resulta costoso.

  • Los países en los que la empresa está establecida o cuenta con establecimientos permanentes.
  • Los países en los que posee registros de IVA.
  • Si vende bienes, servicios, servicios digitales o una combinación de ellos.
  • Si las operaciones son B2B, B2C o ambas.
  • Si utiliza registros nacionales, OSS, IOSS, inversión del sujeto pasivo (reverse charge) o las reglas de proveedor asumido (deemed-supplier) para marketplaces.
  • Qué salidas debe producir la API: datos para declaraciones nacionales, datos de OSS/IOSS, libros de facturas como el i.SAF de Lituania, asientos contables exclusivamente o cargas útiles (payloads) para un proveedor de presentación externo.

Esto importa porque el régimen OSS no absorbe todas las operaciones. Los servicios prestados en un país donde la empresa tiene un establecimiento suelen corresponder a la declaración nacional de ese país, y no a la declaración del OSS. Modela los establecimientos por separado desde el principio, o desviarás erróneamente esas operaciones en el momento de la agregación.

Tampoco establezcas un tipo impositivo fijo por país en el código. La UE cuenta con tipos estándar, reducidos, superreducidos, intermedios, del 0% y específicos por producto, y estos cambian. La fuente fiable para un producto específico en un Estado miembro determinado es la administración tributaria de ese país, mientras que la base de datos TEDB de la Comisión ofrece una visión general entre países. Registra la fuente y la versión detrás de cada decisión sobre tipos impositivos para que una futura actualización de la tabla de tarifas no modifique silenciosamente cómo se refleja una operación antigua.

Modelar la decisión fiscal y no solo el tipo impositivo

El núcleo de una integración sólida es una capa de categorías fiscales situada entre los productos y los tipos. Asocia los productos a categorías, las categorías a códigos fiscales específicos de cada país y, a su vez, a tipos con fechas de vigencia:

producto/servicio
    → categoría fiscal
    → código fiscal específico del país
    → tipo y tratamiento con fecha de vigencia

La práctica poco segura que provoca desviaciones en los informes es SKU del producto → 21% de IVA. El mismo producto tiene tipos diferentes según el país, y un tipo puede cambiar a mitad de período. La propia guía de cumplimiento del IVA de Nordlet recomienda precisamente este mapeo basado en categorías en lugar de vincular los productos directamente a porcentajes.

Tu taxonomía de categorías fiscales debe ser estable e interna: bienes gravados al tipo general, bienes gravados al tipo reducido, servicios prestados por vía electrónica, servicios ordinarios, operaciones exentas, operaciones sujetas al 0%, inversión del sujeto pasivo B2B intracomunitaria (intra-EU B2B reverse charge), venta intracomunitaria a distancia, importación IOSS y operación de proveedor asumido (deemed-supplier). Todo lo que se encuentra aguas abajo depende de esta taxonomía.

La validación VIES como un flujo de trabajo asíncrono de pruebas

El servicio oficial de VIES expone una interfaz SOAP/WSDL que acepta un código de país de dos letras y un número de IVA. Sus limitaciones documentadas son importantes para el manejo de errores: datos de entrada no válidos, límites de concurrencia globales y por Estado miembro, indisponibilidad del servicio, indisponibilidad del Estado miembro y tiempos de espera agotados (timeouts). Trátalos como resultados distintos, no como un único cajón de sastre de "error".

Un flujo de trabajo que resiste la carga y las auditorías funciona así:

  1. Normaliza el ID de IVA: pon el prefijo en mayúsculas, elimina los espacios o signos de puntuación permitidos y conserva por separado el valor original introducido por el usuario.
  2. Valida localmente el formato del código de país y del número antes de realizar una llamada de red.
  3. Envía el número normalizado a VIES.
  4. Almacena el ID normalizado, las marcas de tiempo de solicitud y respuesta, el estado de válido/no válido/no procesado, la respuesta sin procesar, cualquier error del servicio, los ID del cliente y de la factura, y la decisión de la aplicación.
  5. Almacena en caché los resultados exitosos durante un período definido y documentado.
  6. Reintenta los fallos técnicos transitorios aplicando un retraso incremental (backoff).
  7. Envía los casos no resueltos o contradictorios a revisión manual.
  8. Vuelve a validar cuando un resultado en caché esté obsoleto o antes de una operación en la que la prueba sea fundamental.

Nordlet comprueba un número de IVA de la UE cuando se añade un cliente y lo vuelve a comprobar antes de facturar si el resultado anterior hacaducado, que es el comportamiento que debes replicar tanto si la comprobación se realiza en la plataforma como en tu propio código.

La regla fundamental: no hagas que el proceso de pago (checkout) sea síncrono con VIES. Una interrupción del servicio no equivale a un número no válido. Si VIES agota el tiempo de espera durante una venta, retén la operación para revisión o asígnale un estado provisional. Bloquear el pago en función de la disponibilidad del servicio de la Comisión genera tickets de soporte, y clasificar erróneamente a un buen cliente como no válido es aún peor.

Separación del estado de validación y el tratamiento fiscal

Una vez que obtienes un resultado de VIES, el motor de decisiones tiene más trabajo por hacer. Almacena estos datos en campos separados:

{
  "viesStatus": "valid",
  "vatTreatment": "intra_eu_b2b_reverse_charge",
  "evidenceStatus": "reviewed",
  "placeOfSupply": "DE"
}

Antes de aplicar la inversión del sujeto pasivo o una exención, el motor debe comprobar si el cliente es realmente el destinatario, si el país del cliente y el prefijo de IVA coinciden, si la operación califica como intracomunitaria, si se aplican reglas especiales sobre el lugar de entrega, si existen pruebas de transporte, si el vendedor actúa como proveedor asumido y si la factura incluye las menciones obligatorias. Un estado VIES válido que no supere ninguna de estas otras comprobaciones no constituye una luz verde.

Creación de una decisión fiscal inmutable en el momento de la facturación

Cuando se crea la factura, guarda la decisión completa junto a ella, y no solo el tipo impositivo final:

factura
  ├─ categoría fiscal de la línea
  ├─ lugar de entrega
  ├─ régimen de IVA
  ├─ tipo impositivo específico del país
  ├─ versión de la tabla de tipos
  ├─ referencia de prueba VIES
  ├─ referencias de pruebas de ubicación
  ├─ referencia de base legal
  └─ indicadores de rol en el marketplace

Las normas de facturación de la UE exigen los datos del proveedor y del cliente, el número de factura, la descripción, la base imponible, el tipo de IVA, la cuota de IVA y cualquier información sobre inversión del sujeto pasivo o exención. Las notas de crédito y las modificaciones necesitan una referencia inequívoca a la factura original.

El libro mayor de Nordlet es inmutable, por lo que las correcciones se realizan mediante nuevos asientos, como notas de crédito o asientos de reversión, en lugar de editar registros cerrados. Diseña tu aplicación en torno a ese modelo, incluso si tu base de datos pudiera técnicamente sobrescribir los datos. Editar una factura cerrada destruye el vínculo entre la declaración original y la corrección, que es precisamente el rastro que sigue un auditor.

Registro contable (postings), webhooks e idempotencia

Una venta genera asientos contables de partida doble que preservan tanto la operación comercial como la obligación de IVA desglosada por país y régimen. Una venta nacional puede registrar:

Debe: Deudores comerciales / compensación de pagos
    Haber: Ingresos
    Haber: IVA repercutido - DE - nacional

Una venta intracomunitaria B2B con inversión del sujeto pasivo registra ingresos sin IVA repercutido y una referencia a la prueba de la inversión del sujeto pasivo. El plan contable exacto es cosa tuya; lo importante es que las dimensiones de los informes permanezcan asociadas a cada asiento: Estado miembro, régimen, categoría fiscal, tipo impositivo, período, factura de origen y trazabilidad de las correcciones.

Gestiona los cambios de estado mediante webhooks en lugar de consultas periódicas (polling). Nordlet emite eventos como sale_invoice.paid, firma las entregas y reintenta los envíos aplicando un retraso incremental. Asigna a cada operación de escritura una clave de idempotencia determinista:

sale:{platform_order_id}:invoice:{invoice_version}

Tu consumidor también debe ser idempotente. Un webhook puede llegar dos veces, llegar tarde o dispararse después de que la solicitud original ya se haya completado con éxito. Verifica las firmas, registra los ID de eventos, pon en cuarentena los eventos con formato incorrecto, procésalos a través de una cola persistente y concilia el estado de los webhooks con la API de manera programada. Si no has trabajado antes con webhooks firmados y claves de idempotencia, aquí es donde se concentran los errores de asientos duplicados más sutiles.

Agrupación para el OSS y generación de exportaciones listas para declarar

Para las operaciones de OSS que reúnan los requisitos, agrupa los datos del libro mayor por régimen, Estado miembro de consumo, tipo de operación, categoría de tipo, tipo impositivo, base imponible, cuota de IVA, Estado miembro de expedición o establecimiento, moneda y período de corrección.

La declaración del régimen de la Unión separa las entregas por Estado miembro de consumo y distingue los servicios procedentes del Estado miembro de identificación, los servicios procedentes de otros establecimientos permanentes y los bienes expedidos desde diferentes Estados miembros. Informa por separado de las bases imponibles y las cuotas de IVA para los tipos general y reducido. Las operaciones exentas y sujetas al 0% quedan totalmente fuera de la declaración OSS.

Algunos detalles operativos que suelen pasar factura:

  • Los períodos del OSS de la Unión y exterior a la Unión son trimestrales; el del IOSS es mensual. Las declaraciones y el pago deben efectuarse antes de que termine el mes siguiente.
  • Es obligatorio presentar una declaración sin actividad (nil return) en cada período, incluso cuando no se hayan realizado operaciones relevantes. Genera una lista de comprobación de períodos y crea automáticamente una declaración con valor cero.
  • Las declaraciones del OSS se realizan en euros, utilizando el tipo de cambio de referencia del BCE del último día del período impositivo cuando sea necesario realizar una conversión. Almacena la moneda de origen, el tipo de cambio, la fecha del tipo, el importe convertido y el método utilizado.

Las exportaciones deben obtenerse del libro mayor bloqueado, nunca de una hoja de cálculo paralela. Los totales en hojas de cálculo omiten correcciones, países de expedición, tipos impositivos y pruebas. Una exportación contiene el período de declaración, el régimen, el Estado miembro de consumo, el país de expedición, la categoría de la operación, el tipo impositivo, las bases imponibles y las cuotas de IVA, la moneda y el tipo de cambio aplicado, los importes de corrección del período actual y de períodos anteriores, los ID de las facturas de origen, las referencias de las notas de crédito y los totales de conciliación.

Sé preciso acerca de lo que la API proporciona aquí. Nordlet calcula las declaraciones de OSS e IOSS a partir de las facturas y del libro mayor (incluyendo las correcciones de períodos anteriores), emite paquetes de declaraciones nacionales para Lituania (FR0600), Alemania (UStVA) y Polonia (JPK_V7M), y genera los registros i.SAF listos para el VMI en Lituania. Eso constituye datos listos para declarar. Una sola llamada a la API no presenta la declaración de IVA de todos los países a través de cada pasarela nacional, y ninguna declaración se envía a una administración en tu nombre. Mantén la contabilidad, la generación de declaraciones, la exportación, el envío a la pasarela y la confirmación de pago como estados separados en tu sistema. La guía del motor de IVA de la UE documenta qué casos resuelve el motor y dónde se activan sus advertencias.

Bloqueo del período

Tras la revisión y aprobación, concilia las facturas con los asientos del libro mayor, concilia los saldos de IVA del libro mayor con el conjunto de datos de la declaración, exporta la declaración, registra las referencias de presentación y pago, y bloquea el período. Nordlet bloquea la realización de asientos en un mes cerrado, incluso a través de la API. Las correcciones posteriores al cierre se realizan en un período posterior con enlaces explícitos al documento original y al período de declaración afectado.

Modos de fallo comunes y cómo evitarlos

Modo de fallo Por qué ocurre Mitigación
Tratar un resultado VIES válido como suficiente para aplicar el 0% VIES no establece los derechos de exención Almacena las pruebas del cliente, de la operación, del transporte y de la factura junto con el resultado
Tratar un resultado no válido como prueba de la ausencia de registro Es posible que el número no esté habilitado para el comercio intracomunitaria o que la base de datos esté desactualizada Distingue entre no válido, no procesado y fallo técnico; deriva las discrepancias a revisión
Hacer que el pago (checkout) sea síncrono con VIES Límites de concurrencia, tiempos de espera agotados, interrupciones Validación asíncrona, caché de corta duración, retraso incremental, estados provisionales
Almacenar en caché los resultados para siempre El estado de registro y activación cambia Almacena marcas de tiempo y fecha de caducidad; vuelve a comprobar antes de facturar si el dato ha caducado
Asociar los productos directamente a porcentajes de IVA Los tipos y las exenciones dependen del país y de la fecha Relaciona producto con categoría, categoría con código de país y código con tipo con fecha de vigencia
Reconstruir el OSS a partir de hojas de cálculo Los totales omiten correcciones, países de expedición y pruebas Obtén los datos del libro mayor inmutable con dimensiones en cada asiento
Incluir en el OSS servicios prestados desde un establecimiento nacional Determinados servicios corresponden a la declaración nacional Modela los establecimientos por separado y enruta según el régimen antes de la agregación
Omitir las declaraciones sin actividad (nil returns) El OSS exige una declaración en cada período Genera una lista de comprobación y crea automáticamente declaraciones con valor cero
Editar facturas cerradas para corregirlas Destruye el vínculo entre la declaración y la corrección Utiliza notas de crédito y asientos de reversión en un período posterior

Qué haríamos primero

Si empezáramos esta integración mañana, construiríamos la capa de categorías fiscales y el registro de decisiones sobre el IVA antes de tocar un solo endpoint de informes. Estabilizaríamos la taxonomía, asociaríamos los productos a las categorías y haríamos que el registro de decisiones capture las señales brutas del país junto con el motivo por el cual se eligió un lugar de entrega determinado. Todo lo demás (VIES, registro contable, agrupación OSS, exportación) depende de que ese modelo sea correcto.

A continuación, configuraríamos VIES como un paso de obtención de pruebas asíncrono con los cuatro estados separados, y lo pondríamos a prueba frente a una empresa de pruebas (sandbox company) con casos complejos (tiempos de espera agotados, resultados no procesados, prefijos no coincidentes) antes de acercarlo a producción. Los modos de fallo anteriores se pueden evitar casi por completo si el modelo de datos transporta las pruebas y las dimensiones de los informes desde el primer asiento.

FAQ

¿Significa una respuesta favorable de VIES que puedo aplicar el tipo del 0% a una venta B2B intracomunitaria?

No. VIES confirma que un número de IVA está registrado y, cuando se admite, habilitado para el comercio intracomunitaria. El derecho a exentar una entrega intracomunitaria depende de pruebas adicionales: que el cliente sea el destinatario real, justificantes de transporte o expedición, un lugar de entrega correcto y la mención exigida en la factura. Almacena el resultado de VIES como un dato de entrada más, no como la decisión definitiva.

¿Debe la validación VIES bloquear el proceso de pago (checkout)?

No debería. VIES puede agotar el tiempo de espera o alcanzar los límites de concurrencia, y una interrupción del servicio no es lo mismo que un número no válido. Valida de forma asíncrona, almacena en caché los resultados exitosos durante un período documentado, reintenta los fallos transitorios y retén los casos ambiguos para su revisión asignándoles un estado provisional en lugar de cancelar la venta.

¿Puede una API de contabilidad en la nube presentar mis declaraciones de IVA automáticamente?

Puede generar datos listos para declarar agrupados por régimen y Estado miembro, calculados a partir del libro mayor inmutable e incluyendo las correcciones. Si además realiza la presentación a través de cada pasarela nacional depende del producto y del país. Nordlet calcula las declaraciones de OSS e IOSS, emite paquetes de declaraciones nacionales para Lituania, Alemania y Polonia, y genera los registros i.SAF listos para el VMI en Lituania, pero no presenta nada ante una administración tributaria en tu nombre. Trata la contabilidad, la generación de declaraciones, la exportación, el envío a la pasarela y el pago como estados separados en lugar de asumir que una sola llamada sirve para declarar en todas partes.

¿Cómo gestiono las correcciones después de que un período ha sido bloqueado?

Regístralas en un período posterior con enlaces explícitos al documento original y al período de declaración afectado. Nordlet bloquea la realización de nuevos asientos en un mes cerrado, incluso a través de la API, por lo que las correcciones se canalizan mediante notas de crédito o asientos de reversión en lugar de ediciones. Esto preserva la trazabilidad entre la declaración original y el ajuste.

Lecturas adicionales