Eslovaquia pasa a Peppol el 1 de enero de 2027: facturación electrónica para ERP a medida y flujos EDI

Desde el 1 de enero de 2027, un sujeto pasivo de IVA establecido en Eslovaquia ya no puede enviar un PDF por correo a otra empresa eslovaca y llamarlo factura. Las facturas B2B y B2G nacionales tienen que ser XML estructurado conforme a la norma europea EN 16931, entregado por la red Peppol a través de un proveedor certificado, al que la Administración Financiera llama «digitálny poštár», un cartero digital. Todas las empresas, autónomos y organismos públicos eslovacos tienen que poder recibirlas, incluidos los que no son sujetos pasivos de IVA.

A principios de octubre de 2026, eso deja unos 90 días.

Si usas Pohoda, KROS, Money o un programa de contabilidad estándar parecido, esto es sobre todo trabajo de tu proveedor. Están incorporando Peppol, y el propio manual de la Administración Financiera de 26 de agosto de 2026 dice que en la mayoría de los casos bastará con actualizar el sistema existente. Instala la actualización, elige un proveedor y acuerda la rutina con tu gestor contable.

Este artículo es para todos los demás: empresas cuyas facturas salen de un ERP propio, de un sistema muy personalizado o al final de su vida útil, de un motor de facturación dentro de su propio producto o de un enlace EDIFACT con clientes de la gran distribución.

Qué exige la ley

La obligación procede de la Ley del IVA modificada (222/2004 Z. z., cambiada por la 385/2025 Z. z.). A grandes rasgos, según la página eFaktúra de la Administración Financiera y el manual:

• Emisión. Los sujetos pasivos de IVA establecidos en Eslovaquia tienen que emitir facturas electrónicas por las entregas nacionales, y por los cobros recibidos antes de la entrega, cuando el cliente es un sujeto pasivo eslovaco o cualquier persona jurídica eslovaca. Los consumidores quedan fuera. También las operaciones exentas de IVA y las facturas simplificadas (un tique de hasta 100 €, o un tique de eKasa de hasta 400 € IVA incluido). Por lo demás, el importe de la factura ya no importa.
• Recepción. Todo sujeto pasivo eslovaco, esté o no registrado a efectos del IVA, y toda persona jurídica eslovaca tienen que poder recibir facturas electrónicas a través de un proveedor certificado.
• Formato. XML conforme a la EN 16931, en UBL 2.1 o CII D16B. En la red, eso significa Peppol BIS Billing 3.0, que es UBL.
• Entrega. A través de un proveedor certificado por Peppol. Las partes pueden acordar otro canal, como el correo electrónico o un enlace EDI existente, pero solo con el consentimiento previo del comprador; la factura tiene que seguir siendo XML EN 16931, y ambas partes tienen que seguir siendo localizables a través de un proveedor.
• Plazo. 15 días desde la entrega, como hasta ahora. En una factura enviada por la red, la fecha de emisión es el día en que se entregó al proveedor.
• Comunicación. El proveedor extrae los datos fiscales y los comunica a la Administración Financiera, y la ley da por cumplida tu obligación de comunicar en cuanto le entregas la factura. El kontrolný výkaz (la declaración de control del IVA) se mantiene hasta el 1 de julio de 2030.
• Archivo. Los sujetos pasivos de IVA conservan el XML durante diez años desde el final del año al que se refiere. Una representación en PDF no es la factura.
• Sanciones. Incumplir las obligaciones de facturación electrónica o enviar datos incorrectos puede sancionarse con hasta 10.000 €, y con hasta 100.000 € en caso de reincidencia, según el manual y las preguntas frecuentes de 15 de septiembre de 2026. Un error evidente corregido con rapidez, o un fallo demostrable del proveedor, no se sanciona.

El cambio sigue al devengo. Si la obligación de emitir una factura nació a más tardar el 31 de diciembre de 2026, se aplican las normas antiguas, aunque se cobre en 2027.

Hay dos cambios menores que pillan desprevenido a más de uno. Un calendario de pagos (splátkový kalendár) de un alquiler o un leasing ya no vale como factura recapitulativa: cada entrega periódica necesita su propia factura electrónica. Y las empresas extranjeras que solo están registradas a efectos del IVA en Eslovaquia quedan fuera del ámbito hasta el 30 de junio de 2030.

Las facturas EDIFACT dejan de contar

Esta es la parte que afecta a los fabricantes y a los proveedores de las cadenas de distribución. Las preguntas frecuentes son tajantes. Puedes seguir intercambiando EDIFACT con tus clientes después del 1 de enero de 2027, pero en las operaciones nacionales una factura EDIFACT dejará de cumplir la definición de factura electrónica a efectos del IVA. Con sus palabras, «vy alebo váš poskytovateľ IT služieb musí vykonať konverziu»: tú o tu proveedor de servicios de TI tenéis que convertir esas facturas a UBL o CII EN 16931.

Las preguntas frecuentes llegan a indicar la vía. La CEN/TS 16931-3-4 establece la correspondencia entre EDIFACT INVOIC D16B y el modelo semántico de la EN 16931, y desde ahí se mapea a UBL. Su ejemplo: el número de factura de EDIFACT pasa a ser el término de negocio BT-1, que en UBL es cbc:ID.

De ahí salen dos decisiones de diseño.

Dónde se hace la conversión. O tu sistema genera UBL a partir de los mismos datos que alimentan el mensaje EDIFACT, o tu proveedor de servicios EDI convierte a la salida. Si lo hace él, pídele sus informes de validación, porque la multa es tuya.

Qué canal la transporta. Si el UBL va por Peppol como Peppol BIS, lo comunica el proveedor. Si mantienes el canal EDI por acuerdo con el comprador, no se comunica nada automáticamente, y sigues necesitando un endpoint Peppol para todo lo demás.

Las normas se refieren a facturas, notas de crédito y autofacturas. Los pedidos y los avisos de expedición pueden seguir como están.

Qué tienes que construir realmente

En un sistema a medida, el trabajo se divide en cuatro piezas. La conexión con el proveedor suele ser la más pequeña.

1. Salida: UBL que pase la validación

Mapea los datos de tus facturas a los términos de negocio de la EN 16931 y, de ahí, a UBL. La página eFaktúra publica una hoja de cálculo de transposición (en la versión 1.11 cuando se escribió esto) que relaciona los términos de negocio con los preceptos de la ley eslovaca que los sustentan, con la cardinalidad eslovaca por encima de Peppol BIS. Trátala como tu especificación.

Los campos que dan problemas rara vez son los evidentes:

• El DIČ del destinatario. Los participantes eslovacos se direccionan en Peppol como 0245:DIČ, el número de identificación fiscal, no el IČO ni el IČ DPH. Una empresa que ya está en Peppol con un identificador 9950 sigue necesitando un registro 0245 en el SMP eslovaco. Si tu maestro de clientes solo tiene IČO e IČ DPH, tienes un trabajo de datos antes que uno de código.
• Los códigos de categoría de IVA. S, Z, E, AE y O, cada uno con sus reglas de negocio de Peppol. La categoría O (fuera del ámbito del IVA) prohíbe los identificadores de IVA en la factura y no puede compartir factura con líneas al tipo general. El texto del motivo de exención (BT-120) es para las operaciones exentas; rellenarlo en una factura al tipo general invalida el XML.
• Las unidades de medida, de las listas de códigos de la CEPE/ONU, no texto libre. Cada línea necesita una.
• Los tipos de documento que olvidaste. Las correcciones como nota de crédito más una factura nueva, o una factura rectificativa que remite a la original en BT-25. Los documentos fiscales de los anticipos usan el código de tipo 388. Las autofacturas son el tipo 389.

Valida antes de enviar, contra Peppol BIS y las reglas eslovacas, y deriva los errores a alguien que pueda corregirlos. Bloquea la factura una vez entregada, y haz que los reintentos sean idempotentes: la misma factura enviada dos veces con dos números es un problema fiscal.

2. La conexión con el proveedor

El registro de 1 de octubre de 2026 recoge 79 proveedores certificados, eslovacos y extranjeros. Cada uno tiene su propia API y su propia autenticación. No hay una plataforma estatal central en el recorrido de la factura: el plan para crearla se abandonó en 2024, y las facturas viajan directamente entre proveedores. Puntos prácticos de las preguntas frecuentes:

• Solo puedes registrar un proveedor de recepción por cada ID de participante, pero puedes enviar a través de varios.
• Registrar tu proveedor de recepción a través del portal de la Administración Financiera es un requisito legal, y quien lo haga necesita autorización para actuar en nombre de la empresa en ese portal. Resuélvelo esta semana. Es el paso más lento que no implica código.
• Si el destinatario no está en Peppol, la entrega falla, pero tu obligación como emisor queda cumplida y los datos se comunican igualmente. Tu código tiene que registrar el fallo y avisar a alguien, no reintentar indefinidamente ni bloquear la facturación.

Tener tu propio punto de acceso implica la certificación de OpenPeppol, la acreditación de la Administración Financiera y, desde el 1 de julio de 2027, la ISO/IEC 27001. Para una empresa que solo envía sus propias facturas, un proveedor es la respuesta sensata.

3. Entrada hacia cuentas a pagar

Desde enero, tu compañía eléctrica, tu operador de telecomunicaciones y tus proveedores de software te enviarán UBL. El manual atribuye al destinatario la responsabilidad de poder recibir: un proveedor que envía correctamente por la red ha cumplido con su parte.

El trabajo de entrada consiste en recoger los documentos de la API del proveedor, validarlos, identificar al proveedor, mapear las líneas a tu modelo de cuentas a pagar, conciliar con los pedidos de compra donde lo hagas y alimentar el circuito de aprobación existente, que la ley no toca. También necesitas una representación legible del XML a demanda y el archivo del XML durante diez años. Aquí Peppol no transporta ningún mensaje de rechazo, así que las discrepancias se resuelven con el proveedor como siempre.

4. Comunicación y conciliación

El proveedor construye el documento de datos fiscales y lo comunica. Tu trabajo es asegurarte de que lo que entregas es correcto, y de que tus declaraciones de IVA siguen cuadrando, porque el kontrolný výkaz continúa hasta 2030. Guarda con cada factura los identificadores de mensaje y los estados de entrega del proveedor, para que, cuando las cifras no coincidan, puedas averiguar por qué.

Cuánto se tarda

La estimación de la propia Administración Financiera: si tu software ya está conectado a Peppol, la activación es inmediata. Para soluciones a medida o complejas, la integración «môže trvať niekoľko dní až týždňov», entre varios días y varias semanas.

Es una estimación justa para la conexión en sí. Las semanas se van en los datos: encontrar el DIČ de cada cliente y proveedor, acertar con la categoría de IVA de cada producto y servicio, y construir un procesamiento de entrada que no dependa de que alguien abra cada documento.

Las pruebas irán más despacio de lo que esperas. El monitor de Peppol de epostari.sk, gestionado por Verteco, que es a su vez uno de los proveedores certificados, contaba el 2 de octubre de 2026 3.332 de 235.518 sujetos pasivos de IVA eslovacos capaces de recibir facturas Peppol, alrededor del 1,4%. Solo mide sujetos pasivos de IVA y presenta sus cifras como orientativas. Aun así, pocos de tus clientes pueden recibir hoy una factura de prueba, y enero traerá muchos errores de «destinatario no encontrado». Trátalos como un caso normal.

Un plan de 90 días

Semanas 1 y 2: inventario y decisiones. Haz una lista de todos los sistemas que emiten facturas a empresas eslovacas: el ERP, el motor de facturación, la pasarela EDI, la hoja de cálculo que alguien de ventas sigue usando. Haz lo mismo con la entrada. Comprueba la cobertura del DIČ en los datos maestros de clientes y proveedores. Elige proveedor, resuelve la autorización en el portal y regístrate para recibir.

Semanas 3 a 6: salida. Construye el mapeo a UBL y la validación, conéctate al entorno de pruebas del proveedor y convierte las facturas EDIFACT o acuerda la conversión con tu proveedor de EDI. Cubre las notas de crédito, los anticipos y la autofacturación, no solo el camino feliz.

Semanas 5 a 9: entrada. Recogida, validación, identificación del proveedor, mapeo a cuentas a pagar, representación y archivo.

Semanas 9 a 11: en producción en 2026. Este año se permite el uso voluntario. Envía facturas reales a clientes que ya estén registrados y recibe de proveedores que lo estén. Aquí es donde aparecen los errores de mapeo, mientras no cuestan nada.

Semanas 12 y 13: paso a producción. Haz que el cambio dependa del devengo, no de la fecha de contabilización. Planifica teniendo en cuenta las fiestas: las dos últimas semanas de diciembre no son una ventana de pruebas.

Si el desarrollo no va a llegar a tiempo, ten un plan alternativo. La aplicación web independiente de un proveedor, la opción que el manual sugiere para las pequeñas empresas, basta para recibir facturas el 1 de enero mientras se termina la integración. Es un parche para recibir, no una forma de emitir en volumen.

Qué sigue en movimiento

Las preguntas frecuentes mencionan una EN 16931 revisada, aprobada en octubre de 2025, y dicen que todavía no pueden describir su impacto; Peppol BIS seguirá a la norma. La hoja de transposición va por la versión 1.11 y las preguntas frecuentes se han reeditado una y otra vez. Mantén el mapeo versionado y en un solo sitio, no repartido por el código de facturación.

La segunda fase ya está en el calendario. Desde el 1 de julio de 2030 se espera que la obligación se extienda a las operaciones transfronterizas, que el plazo de emisión baje a 10 días y que desaparezca el kontrolný výkaz. No dejes fijado en el diseño «solo clientes eslovacos».

Dónde conseguir ayuda

Construimos la conexión entre el sistema que genera tus facturas y la red que ahora tiene que transportarlas: mapeo a UBL y validación, integración con la API del proveedor, conversión de EDIFACT y procesamiento de entrada hasta cuentas a pagar. Nuestro servicio de integración de facturación electrónica explica cómo trabajamos, y si el problema de verdad es el sistema que hay debajo, consulta modernización de ERP. Si el trabajo está definido y te faltan manos, también incorporamos desarrolladores con experiencia a equipos existentes.

Para hablar de tu caso, escribe a office@c9group.dev.