¿Deben los vendedores externalizar el fulfillment paneuropeo?
24 mayo 2026
Qué significa la multa DSA a Temu para las obligaciones de seguridad de producto de los vendedores cross-border en la UE
30 mayo 2026
FLEX. Logistics
Ofrecemos servicios de logística a los minoristas en línea en Europa: preparación para Amazon FBA, procesamiento de órdenes de eliminación de FBA, reenvío a Centros de Cumplimiento — tanto para envíos FBA como de Vendedores.
El Programa de Trabajo 2026 de la Comisión Europea para el IVA en la Era Digital (ViDA) no es una discusión política lejana. Es un mandato técnico secuenciado con una fecha límite de la primera ola en enero de 2027 que afecta directamente a cómo los vendedores transfronterizos de la UE se registran, reportan y mueven inventario a través de los estados miembros. Para las marcas que operan redes de distribución en múltiples países, la pregunta ya no es si adaptarse, sino qué obligaciones llegan primero, quién dentro de la organización es responsable de cada una y si el stack tecnológico de IVA actual puede realmente producir los campos de datos que la nueva arquitectura exige. Este artículo desglosa los seis actos de ejecución, mapea el despliegue por etapas desde 2027 hasta 2030 e identifica los puntos de control operativos donde las configuraciones heredadas fragmentadas tienen más probabilidades de fallar bajo el modelo de reporte centralizado entrante.
Los Seis Actos de Ejecución: Desglosando el Programa de Trabajo 2026
El Programa de Trabajo 2026 estructura la transición de ViDA en seis actos de ejecución distintos, cada uno dirigido a una capa específica de la infraestructura de IVA existente. El primer acto aborda la estandarización técnica de los campos de datos requeridos para las transacciones intracomunitarias, estableciendo el conjunto mínimo de datos que toda presentación de reporte digital debe llevar. El segundo acto rige el rediseño del Sistema de Intercambio de Información sobre el IVA (VIES), moviéndolo de un modelo de consulta por lotes periódico hacia una arquitectura de verificación casi en tiempo real. El tercer acto define los módulos ampliados de la Ventanilla Única de la Unión (OSS), incluyendo nuevas categorías para suministros de servicios públicos específicos que entrarán en vigor el 1 de enero de 2027. Los actos cuarto y quinto sientan las bases legales y técnicas para los marcos obligatorios de Registro Único de IVA (SVR) y Transferencia de Bienes Propios (TOOG), ambos previstos para julio de 2028. El sexto acto cubre las disposiciones transitorias y las ventanas de derogación de los estados miembros. Cada acto crea una capa de cumplimiento distinta, y los vendedores que los traten como una reforma indiferenciada única mal asignarán el esfuerzo de preparación y perderán por completo la lógica de secuenciación.
Requisitos de Reporte Digital: Qué Debe Capturarse
Los Requisitos de Reporte Digital (DRR) bajo ViDA exigen que los datos a nivel de transacción estén estructurados, con marca de tiempo y transmisibles en un formato estandarizado en el punto de suministro. Para los vendedores transfronterizos, esto significa que toda transacción B2B intracomunitaria debe llevar un conjunto definido de campos de datos: número de IVA del proveedor, número de IVA del cliente, fecha de la factura, importe imponible, tipo de IVA aplicado y una referencia de transacción que pueda coincidir con el registro entrante del comprador. El punto de control operativo crítico es que estos datos deben existir en un estado limpio y extraíble antes de que la transacción se reporte — no reconstruidos después del hecho a partir de registros de gestión de almacén o manifiestos de transportistas. Los vendedores que dependen de sistemas ERP que agregan datos de transacciones mensualmente en lugar de capturarlos a nivel de línea de pedido enfrentarán una incompatibilidad estructural con la arquitectura DRR. La capa de datos debe integrarse en el flujo de trabajo de pedido a factura, no añadirse en la etapa de reporte.
Qué Falla Cuando Falta la Capa de Datos
Cuando el stack tecnológico de IVA de un vendedor no puede producir datos de transacción limpios a nivel de campo bajo demanda, las consecuencias bajo el nuevo modelo DRR no se limitan a una presentación retrasada. El VIES rediseñado cruzará las presentaciones del proveedor con los registros del lado del comprador en casi tiempo real. Una discrepancia — causada por un número de IVA faltante, una fecha de factura incorrecta o un importe imponible que no concilia con la entrada declarada del comprador — activa una bandera de discrepancia automatizada. Bajo el sistema periódico actual, tales discrepancias a menudo se resuelven silenciosamente durante la conciliación anual. Bajo la arquitectura entrante, una discrepancia señalada puede suspender el estado de reclamación de IVA de la transacción hasta que el error se corrija y se vuelva a presentar. Para los vendedores que mueven altos volúmenes de stock B2B a través de múltiples fronteras de la UE, un patrón de banderas de discrepancia no es una molestia de cumplimiento. Es un riesgo de flujo de caja que se acumula en cada transacción afectada hasta que la fuente de datos se arregle a nivel del sistema.
El Rediseño de VIES: Preparándose para la Auditoría en Tiempo Real
El rediseño técnico de VIES es el cambio de infraestructura que hace que el resto de ViDA sea exigible. En su forma actual, VIES permite la verificación del número de IVA sobre una base de consulta, pero no cruza los datos de transacciones entre estados miembros en tiempo real. El sistema rediseñado ingerirá registros de transacciones estructurados de ambos lados de un suministro intracomunitario y señalará automáticamente las asimetrías. Para los vendedores, esto cambia fundamentalmente el modelo de exposición a auditorías. Anteriormente, una auditoría de IVA era un proceso periódico y pesado en documentos activado por una señal de riesgo específica. Bajo la nueva arquitectura VIES, cada transacción intracomunitaria está efectivamente pre-auditada en la capa de datos antes de que un inspector humano esté alguna vez involucrado. Los vendedores que han dependido de la conciliación manual de IVA o software de IVA heredado de un solo país descubrirán que esas herramientas no producen la salida estructurada que el nuevo sistema espera. El paso práctico de preparación es un análisis de brechas de los campos de datos de facturas actuales frente al conjunto de datos DRR estandarizado, completado mucho antes de la fecha límite de la primera ola de 2027.
Expansión de OSS y la Ruta hacia el Registro Único de IVA
El marco de la Ventanilla Única (One Stop Shop) se está expandiendo significativamente bajo ViDA, y los cambios de enero de 2027 introducen nuevos módulos OSS de la Unión que cubren categorías de suministro no previamente elegibles para el reporte centralizado. Para el comercio electrónico los vendedores que ya usan OSS para ventas a distancia B2C, el alcance expandido significa revisar si los tipos de suministro recién elegibles en su mix de productos pueden consolidarse en el registro OSS existente o requieren una elección de módulo separada. El cambio estructuralmente más significativo es la introducción en julio de 2028 del Registro Único de IVA (SVR) obligatorio, que reemplazará el requisito actual de que los vendedores mantengan registros de IVA locales en cada estado miembro donde tienen stock. Bajo SVR, un vendedor que mueve inventario a un centro de cumplimiento en Polonia, un hub de distribución en Alemania y una instalación de procesamiento de devoluciones en Francia gestionará esas obligaciones a través de un único punto de registro en lugar de tres presentaciones nacionales separadas. El mecanismo de Transferencia de Bienes Propios (TOOG), que se lanza junto con SVR, manejará el tratamiento de IVA de los movimientos de stock transfronterizo entre los propios almacenes de un vendedor — un tipo de transacción que actualmente requiere un tratamiento manual cuidadoso en cada jurisdicción. Para los vendedores que operan una estrategia de distribución pan-UE a través de múltiples nodos de almacén, SVR y TOOG juntos representan el cambio operativamente más significativo en todo el paquete ViDA.
What to Audit Before January 2027
The first practical step is a structured audit of the current VAT registration footprint against the incoming OSS module scope. Sellers should confirm which supply types in their EU product catalogue are newly eligible for Union OSS reporting from January 2027 and whether their current OSS filing covers those categories or excludes them by default. The second audit layer is the invoice data architecture: does the current ERP or order management system capture the standardised DRR fields at transaction level, or does it aggregate data in ways that would require manual extraction and reformatting before submission? The third check is the EORI and VAT number consistency across all active trade lanes — any mismatch between the identifiers used in inbound customs declarations and those used in OSS filings creates a reconciliation gap that the new VIES cross-referencing will surface. Sellers using EU customs clearance services should confirm that their customs broker is capturing and transmitting the same VAT identifiers used in their OSS account.
Where Fragmented VAT Stacks Fail Under SVR
The most common weak assumption among multi-country sellers is that the July 2028 SVR deadline gives them sufficient runway to defer preparation. In practice, the SVR transition requires sellers to map every current local VAT registration to the new single registration structure, migrate historical filing data, and ensure that their warehouse management and order routing systems can correctly attribute stock movements to the TOOG framework from day one of the transition. Sellers who have grown their EU presence incrementally — adding a German warehouse, then a French returns hub, then a Polish fulfilment node — often have VAT registrations managed by different local advisors using different software outputs. Consolidating those into a single coherent SVR filing requires data standardisation work that cannot be completed in the final weeks before the deadline. The failure mode is not a missed filing date. It is arriving at the SVR transition with incompatible data formats across three jurisdictions and no unified record of historical intra-community stock movements.
Owner Map: Who Holds Each ViDA Obligation
A practical owner map for ViDA compliance separates the obligations by function rather than treating them as a single tax department task. The DRR data architecture is owned by the ERP or order management system operator — typically the IT or finance systems team — because the structured data fields must be built into the transaction capture layer, not added downstream. The OSS filing obligation is owned by the VAT compliance function, whether in-house or outsourced to a tax advisor, but that function depends on clean data inputs from the systems layer. The TOOG framework, once live, will require the logistics operations team to flag every cross-border stock movement between owned warehouse nodes as a distinct transaction type with its own VAT treatment. If the warehouse management system does not distinguish between a customer order shipment and an inter-warehouse stock transfer, the TOOG record will be incomplete. For sellers using a third-party logistics provider for EU warehousing, the contractual question is whether the 3PL's warehouse management system produces the movement-level data that the TOOG framework will require.
The Staged Blueprint: Transitioning to Single VAT Registration
The ViDA rollout follows a deliberate staging logic that sellers can use to sequence their own preparation. The January 2027 wave is primarily a scope expansion for OSS and the introduction of DRR technical standards — it does not yet mandate real-time transaction reporting for all sellers, but it establishes the data format requirements that subsequent waves will enforce. The July 2028 wave is where the structural change lands: SVR becomes mandatory, TOOG goes live, and the VIES redesign reaches operational status. The 2030 phase extends DRR obligations to additional transaction categories and closes remaining derogation windows for member states that have been permitted to maintain legacy reporting systems. The practical preparation error is treating 2028 as the planning horizon when the data infrastructure work required to support SVR and TOOG must be completed well before the transition date. A seller who begins their ERP data architecture review in early 2027 — after the first-wave changes are live — will have approximately twelve months to complete a data standardisation project that typically takes six to nine months in a complex multi-country setup. That is a workable but tight window, and it assumes no significant rework cycles. Sellers who defer the review to late 2027 are building in execution risk that the staging logic was specifically designed to avoid. The Commission's sequencing is not arbitrary: the 2027 changes are the technical foundation that the 2028 structural changes are built on top of.
Pre-2027 Data Readiness Checklist
- DRR field mapping: Confirm your ERP captures supplier VAT number, customer VAT number, invoice date, taxable amount, VAT rate, and transaction reference at line-item level.
- OSS scope review: Identify all supply types in your EU catalogue and confirm which are newly eligible for Union OSS modules from January 2027.
- EORI and VAT identifier consistency: Verify that identifiers used in customs declarations match those in your OSS account exactly.
- Invoice data extraction test: Run a sample extraction of last quarter's intra-community transactions in DRR-compatible format and check for gaps.
- Customs broker data alignment: Confirm your EU customs clearance provider transmits the same VAT identifiers used in your OSS filing.
Pre-2028 SVR and TOOG Readiness Checklist
- VAT registration audit: Map every active local VAT registration across EU member states and identify the advisor or system managing each one.
- Historical filing consolidation: Assess whether historical filing data from each jurisdiction is in a format that can be migrated to the SVR structure.
- Warehouse movement tagging: Confirm your warehouse management system distinguishes customer order shipments from inter-warehouse stock transfers as separate transaction types.
- 3PL data contract review: Check whether your logistics provider's system produces movement-level data compatible with TOOG reporting requirements.
- SVR transition timeline: Build a project plan with a data standardisation phase completing no later than Q1 2028 to allow testing before the July deadline.
Building the VAT Tech Stack for the 2027–2030 Window
The practical implementation sequence starts with the data layer, not the filing layer. Before a seller can evaluate which OSS modules apply, which TOOG movements need to be tracked, or whether their SVR transition plan is viable, they need to know whether their current systems produce clean, structured, field-level transaction data. That assessment should be completed as a discrete project with a defined output: a gap analysis document that maps current ERP data fields against the DRR standard and identifies every field that is missing, aggregated, or inconsistently populated. The second phase is remediation — either configuring the existing ERP to capture missing fields, or implementing a middleware layer that extracts and structures data before it reaches the VAT reporting system. The third phase is testing: running a parallel DRR-format submission against actual transaction data to verify that the output is clean before the live deadline. The fourth phase is the OSS module review, which can only be completed accurately once the data layer is confirmed. Sellers who attempt to reverse this sequence — starting with the OSS filing question and working backward to the data architecture — typically discover the data gaps at the worst possible moment: during a live submission cycle with a deadline approaching. For sellers operating multi-node EU distribution, the physical inventory layer adds a further dimension. Every warehouse node that holds stock generates intra-community movement records, and those records must be attributable to the correct VAT treatment under both the current rules and the incoming TOOG framework. Pan-EU distribution strategy built on clean inventory movement data is not just a logistics efficiency question under ViDA — it is a compliance prerequisite.
Inventory Movement Data as a Compliance Asset
Under the incoming ViDA architecture, the record of where stock physically moves between EU warehouse nodes is not just an operational log — it is the source data for TOOG VAT treatment. A seller moving a pallet from a Dutch consolidation hub to a German fulfilment centre generates a Transfer of Own Goods event that will require a structured VAT record under the 2028 framework. If the warehouse management system records that movement only as an internal stock transfer with no VAT-relevant data fields, the TOOG record cannot be reconstructed from the available data. The practical implication is that sellers should evaluate their current warehouse management and inventory tracking systems not only for operational efficiency but for their ability to produce movement-level records in a format compatible with future automated monthly OSS reporting. Third-party logistics providers who operate multi-country warehouse infrastructure and track itemised cross-border inventory movements with clean data trails are positioned to support this requirement directly — because the compliance data and the physical movement record originate from the same system rather than being reconciled after the fact across separate platforms.
January 2027: First Wave
New Union OSS modules for specific utility supply categories go live. DRR technical data standards are published and enforceable. Sellers must confirm OSS scope coverage and complete the ERP data field gap analysis before this date.
July 2028: Structural Shift
Mandatory Single VAT Registration replaces local multi-country filings. Transfer of Own Goods framework activates for inter-warehouse stock movements. VIES near-real-time cross-referencing reaches operational status across member states.
2030: Full DRR Scope
Digital Reporting Requirements extend to additional transaction categories. Remaining member-state derogation windows close. Sellers with legacy single-country VAT software face full exposure if data architecture remediation has not been completed.
What Cross-Border Sellers Should Lock In Now
The ViDA staging logic gives sellers a preparation window, but that window is shorter than the headline deadlines suggest. The January 2027 first wave is not a soft launch — it establishes the data standards that the July 2028 structural changes depend on. A seller who treats 2027 as a monitoring year and 2028 as the action year is compressing a multi-phase data architecture project into a single execution sprint with no margin for rework. The decisions to lock in now are: which team or advisor owns the DRR gap analysis, whether the current ERP can produce field-level transaction data in the required format, and whether the logistics infrastructure generating intra-community stock movement records is capable of producing TOOG-compatible data from day one of the 2028 transition. For sellers operating across multiple EU warehouse nodes, the physical distribution layer and the VAT compliance layer are no longer separate workstreams. The inventory movement record is the compliance record. Sellers who have not yet mapped their EU distribution footprint against the incoming TOOG framework should treat that mapping as an immediate priority, not a 2027 task. The B2B European fulfillment infrastructure a seller uses today will either support or obstruct their ViDA compliance posture — and that determination can be made now, before the first implementing act goes live.
FLEX. operates multi-country warehouse infrastructure across the EU with inventory tracking systems that produce movement-level data at the transaction and transfer level. If your current logistics setup cannot cleanly distinguish customer order shipments from inter-warehouse stock transfers — or if your 3PL cannot confirm that its warehouse management system will produce TOOG-compatible records — that is an operational gap worth addressing before the 2027 deadline, not after. Verify your legal and tax obligations with a qualified VAT advisor. For the operational and logistics layer — clean inventory movement data, multi-node EU warehousing, and cross-border distribution infrastructure aligned with the incoming compliance architecture — contact FLEX. to discuss your current setup.
