Por Kristijan Sekereš

La EET 2.0 checa desde el 1 de enero de 2027: qué tiene que hacer el software de TPV y de quioscos a medida

Una tarjeta de pago introducida en un datáfono portátil sobre la mesa de un restaurante

Vuelve el registro de ventas checo. El presidente Petr Pavel firmó la ley de la EET 2.0 el 17 de septiembre de 2026, y el comunicado de la Administración Financiera es claro sobre la fecha: la obligación de registrar las ventas empieza el 1 de enero de 2027. Cubre los pagos presenciales entre empresa y cliente, incluido todo el efectivo. Efectivo, tarjeta, móvil o código QR: si el cliente paga en persona o en tu local, la venta se envía a la administración tributaria en el momento en que se produce.

Para la mayoría de los pequeños comercios, esto significa una actualización del proveedor o una aplicación web gratuita del Estado. Para las cadenas con software de caja propio, quioscos de autoservicio o una aplicación de cobro que el personal lleva por la sala, es un proyecto de integración al que le quedan unos 90 días. Este artículo es para ellas.

Qué ha cambiado desde la primera EET

La EET original se suprimió en 2022. La EET 2.0 mantiene la idea central (cada venta incluida se envía en línea y el Estado acusa recibo) y se quita mucho peso de encima:

  • Datos mínimos. El sistema antiguo desglosaba cada venta por tipo de IVA. La EET 2.0 envía un único total, IVA incluido, sean cuales sean los tipos.
  • Sin obligación de tique. Las empresas ya no tienen que emitir un tique a efectos de la EET, y el código de confirmación no tiene por qué figurar en él.
  • Un ámbito más estrecho. Solo se registran los pagos presenciales entre cliente y empresa; el sistema antiguo cubría una gama más amplia de pagos.
  • Una opción gratuita del Estado. MOJE eet, una aplicación web para las empresas más pequeñas, más una exclusión voluntaria llamada EET OFF para algunos autónomos en régimen de tarifa plana.

El cambio técnico es mayor de lo que sugiere la lista. El transporte es conocido: SOAP 1.1 sobre HTTPS con firmas WS-Security, como antes. El mensaje, no. La nueva interfaz es la versión 4.1, la antigua era la 3.1, y la especificación dice que los cambios de 2026 «son incompatibles con el sistema anterior». La presentación del seminario para desarrolladores enumera como eliminados el código de seguridad BKP, el indicador de modo simplificado y las partidas de IVA. El código de la antigua EET sirve de referencia para la fontanería y nada más.

Qué entra en el ámbito

La página oficial sobre quién tiene que registrar las ventas fija tres condiciones: el pago es presencial o es cualquier pago en efectivo, es un ingreso empresarial y no se aplica ninguna exención.

Un pago presencial se produce en contacto personal contigo o con tu personal, o bien en tu local o tu vehículo en relación con el bien o el servicio. La presentación del seminario dice abiertamente que la segunda regla apunta a las cajas de autoservicio y a los locales de autoservicio. Un quiosco dentro de tu tienda entra en el ámbito aunque ningún empleado toque la transacción. El efectivo se registra siempre, incluso fuera de tu local, salvo el contra reembolso cobrado por un servicio postal.

El medio de pago no importa. Figuran en la lista el efectivo, la tarjeta, el código QR, una transferencia bancaria o un adeudo directo hechos en el punto de venta, los criptoactivos, las tarjetas regalo, los vales de comida y las tarjetas prepago.

Los pagos a distancia quedan fuera: una tienda online cobrada a través de una pasarela de pago, o una factura que el cliente paga desde su oficina. Lo que cuenta es cómo se movió realmente el dinero, no lo que dice la factura. Si un cliente paga 200 CZK con tarjeta en el mostrador y los 800 CZK restantes por transferencia desde casa al día siguiente, solo se registran los 200 CZK.

Las máquinas expendedoras que son un local en sí mismas (la máquina de café es el ejemplo oficial) están exentas, igual que los puestos de autoservicio fuera de tu local en los que el registro no sería práctico. La lista de exenciones cubre también, entre otros, a los organismos públicos, los bancos, el juego y la energía.

Quién puede saltarse la mayor parte de esto

Las microempresas pueden usar MOJE eet, que se lanza el 1 de diciembre de 2026. El seminario para desarrolladores de junio la orientó a empresas con hasta dos unidades de registro y dos empleados. Los autónomos en régimen de tarifa plana del primer tramo, con ingresos de hasta 1 millón de CZK, pueden excluirse mediante EET OFF.

Las empresas con un TPV estándar de los habituales deberían recibir una actualización de su proveedor. Pregunta cuándo sale y qué pasa durante una caída, y después regístrate en el portal tributario e instala el certificado.

Todos los demás deberían seguir leyendo: software de caja propio o personalizado, quioscos que has construido tú, aplicaciones de cobro para el personal, o un grupo en el que un mismo pago puede corresponder a dos empresas.

Qué hay que construir

Todo está en la página de documentos para desarrolladores: la descripción de la interfaz (la versión en inglés no es vinculante), el XSD y el WSDL, solicitudes firmadas de ejemplo y certificados para el entorno de pruebas.

Unidades de registro e identificadores de dispositivo

Cada mensaje lleva un ID de unidad de registro. Creas las unidades (una tienda, un puesto móvil, un vehículo de reparto) en DIS+, el portal tributario, y el sistema asigna a cada una un número. Las cadenas pueden importar unidades de forma masiva, y los cambios tienen que comunicarse en un plazo de 15 días. Tu TPV necesita una correspondencia mantenida entre cada local y su ID de unidad, más un ID de dispositivo de hasta 20 caracteres que sea único dentro de la unidad.

Certificados

Aquí es donde los sistemas a medida suelen perder tiempo. El procedimiento de certificados establece los pasos:

  • El par de claves lo genera la autoridad de certificación de la EET, no tu dispositivo. Descargas un fichero PKCS#12 protegido con contraseña, disponible hasta que confirmas la descarga y durante 30 días como máximo.
  • El fichero usa el antiguo cifrado 3DES por compatibilidad con las cajas más viejas. El documento advierte de que puede no cargarse en OpenSSL 3 sin el proveedor legacy, y recomienda volver a empaquetarlo o trasladar la clave a un almacén seguro.
  • Los certificados son válidos durante un año. Un certificado puede servir a uno o a varios dispositivos; cuántos emites lo decides tú.
  • La renovación puede automatizarse con una API REST: un JWT de vida corta firmado con el certificado que se renueva, y después consultar la solicitud, descargar y confirmar. La autoridad recomienda renovar entre dos y tres semanas antes del vencimiento. Una vez caducado el certificado, la vía de la API queda cerrada, y alguien tiene que renovarlo a mano.
  • Proteger la clave privada es una obligación legal del contribuyente. Un único fichero de clave copiado en cuarenta cajas es una revocación esperando a ocurrir.

El mensaje de datos

La cabecera lleva un UUID nuevo para cada intento, la hora de envío, un indicador de primer intento y un indicador opcional de verificación. La parte de datos lleva el EIČ del contribuyente, el ID de unidad, el ID de dispositivo, un número de secuencia (de hasta 25 caracteres, único por unidad y dispositivo), la hora de la venta con su desfase horario y el total en CZK con exactamente dos decimales. Dos importes opcionales cubren las recargas de prepago y los consumos con cargo a ellas; otros dos campos cubren el registro en nombre de otro contribuyente.

Registra lo que realmente se ha cobrado: una cuenta en efectivo de 78,90 redondeada a 79 se registra como 79,00; la misma cuenta con tarjeta, como 78,90. Una cuenta pagada en parte con vales de comida y en parte con tarjeta es un solo mensaje con el total.

Firma y envío

Cada mensaje se firma con XML Signature en la cabecera WS-Security: canonicalización exclusiva, un resumen SHA-256, RSA-SHA256, el certificado adjunto como BinarySecurityToken y solo el cuerpo SOAP firmado. No añadas cabeceras adicionales como Timestamp o WS-Addressing: los mensajes de más de 12 kB se rechazan, y un mensaje que parezca un ataque puede no recibir respuesta alguna. TLS 1.2 o superior es obligatorio, y el cliente tiene que verificar el certificado del servidor. Producción usa balanceo por DNS, así que resuelve el nombre de host en cada conexión en lugar de fijar una IP.

Desde la versión 1.2, el endpoint admite CORS, así que un TPV basado en navegador puede llamarlo directamente. Decide dónde vive la clave privada antes de que nadie escriba ese JavaScript.

Respuestas, caídas y la regla de las 48 horas

Un mensaje válido recibe una respuesta síncrona con un código de confirmación de 39 caracteres (POK), firmado por la administración tributaria. Verifica esa firma y guarda el POK con la venta. Uno no válido recibe un código de error; -1 significa un fallo temporal, así que vuelve a enviarlo más tarde. Los problemas menores vuelven como advertencias, una de ellas cuando la hora de la venta va más de dos horas por delante del reloj del servidor. Los relojes de los quioscos se desvían. Sincronízalos.

El tiempo de espera de la respuesta lo fijas tú, en no menos de dos segundos. Si no llega un POK a tiempo, la venta va a una cola. Según la presentación del seminario, el reintento reutiliza el cuerpo original con una cabecera nueva: UUID nuevo, indicador de primer intento a falso, nueva hora de envío y la hora original de la venta. Sale en cuanto vuelve la conexión y nunca más de 48 horas después de la venta. La obligación tampoco caduca a las 48 horas: un mensaje tardío sigue siendo debido.

Así que la cola tiene que sobrevivir a un reinicio y lanzar una alerta bastante antes de que se cumplan las 48 horas. Una trampa más: si el certificado caduca mientras hay ventas esperando, tienen que firmarse con uno que esté vigente.

Devoluciones, correcciones y duplicados

Una devolución o anulación es un mensaje nuevo con importe negativo, fechado en el momento actual y sin vínculo con el original. Una corrección es o bien una anulación seguida del mensaje correcto, o bien un único mensaje por la diferencia. Los duplicados se detectan por seis campos (EIČ, unidad, dispositivo, número de secuencia, hora de la venta y total), así que un reintento con el mismo cuerpo es seguro. Un reintento que regenera el número de secuencia es una segunda venta.

Tiques

Menos trabajo que con la primera EET: no hace falta tique a efectos de la EET, y el POK no tiene por qué figurar en él. Elimina cualquier código que retenga la impresión hasta que llegue el POK. Cuando emitas tiques por la normativa de consumo, mantén el número de secuencia de la EET alineado con el número del tique; la especificación señala que en la práctica ambos suelen coincidir.

Casos límite con los que se topan las cadenas

  • Tarjetas prepago, pulseras y monederos: se registran la recarga y cada consumo, con los campos de importe adicionales cumplimentados.
  • Un pago, dos contribuyentes: el ejemplo de la gasolinera de la presentación (combustible vendido por cuenta de otra empresa, café por cuenta propia) necesita dos mensajes, cada uno con los datos de su propio contribuyente.

El calendario

  • 5 de junio de 2026: publicación de la documentación técnica.
  • 1 de julio de 2026: apertura del entorno de pruebas. Entre el 26 de julio y el 26 de agosto procesó 170.389 transacciones de prueba desde 624 direcciones IP de clientes, el 94,6% de ellas con éxito.
  • 1 de noviembre de 2026: la EET en DIS+, las unidades de registro y los certificados de producción.
  • 1 de diciembre de 2026: lanzamiento de MOJE eet.
  • 1 de enero de 2027: la obligación empieza para todos a la vez, sin fases.

El calendario oficial llama a enero mes piloto y después añade que ya será un registro normal. Un comunicado anterior describía el piloto como voluntario. Mientras no se aclare, planifica enviar mensajes reales desde el 1 de enero.

Queda un paso formal: cuando se anunció la firma, el 22 de septiembre, todavía faltaba la publicación en la Recopilación de Leyes. Es un trámite rutinario.

Un plan de 90 días

Octubre: alcance y desarrollo.

  1. Haz una lista de todos los puntos donde cambia de manos el dinero: cajas, quioscos, terminales portátiles, pedidos en mesa pagados en el local y tus propios repartidores que cobran en efectivo. Asigna cada uno a un contribuyente y a una futura unidad de registro.
  2. Elige la arquitectura: firmar en cada dispositivo, o tener un servicio que firme y encole por todos. El sistema acepta ambas. En una cadena suele ganar la central: un almacén de claves, una cola, un sitio que vigilar.
  3. Desarrolla el generador de mensajes, el firmante y la cola contra el entorno de pruebas con los certificados de prueba compartidos. Valida cada mensaje contra el XSD en CI.

Noviembre: credenciales de producción.

  1. A partir del 1 de noviembre, activa la EET en DIS+, crea las unidades (con importación masiva si tienes muchas) y emite los certificados de producción. Guárdalos en un almacén seguro, no en memorias USB.
  2. La especificación fija el 1 de noviembre de 2026 como la fecha de venta válida más temprana en producción. Envía mensajes en modo de verificación con el certificado real: prueban toda la cadena sin registrar una venta.
  3. Termina las devoluciones, los flujos de prepago, la renovación de certificados y las alertas sobre la antigüedad de la cola.

Diciembre: ensayo.

  1. Despliega en un local. Desconecta el cable de red en el pico de la hora de comer y observa cómo se vacía la cola después.
  2. Haz una prueba de carga de tu hora de más actividad a través del firmante.
  3. Congela los cambios antes del pico de Navidad. Explica al personal cómo se ve una caída; si la cola funciona, no tienen que hacer nada.

Enero: el mes piloto.

  1. Concilia a diario. Compara los totales de tu TPV con las sumas agregadas de DIS+, donde también puedes solicitar una exportación CSV detallada con todos los POK.

Dónde conseguir ayuda

Construimos y modificamos integraciones de TPV: el generador de mensajes y el firmante, la cola para las caídas, el almacenamiento y la renovación de certificados, la correspondencia de unidades y la conciliación con DIS+. Cuando el software de caja es antiguo y sus autores se han ido, nuestro servicio de mantenimiento de sistemas heredados es donde empieza ese trabajo. Si tu propio equipo conoce el sistema pero le faltan manos antes de enero, podemos sumarle desarrolladores.

Si tienes tus propias cajas o quioscos en Chequia y todavía no has enviado un mensaje al entorno de pruebas, escribe a office@c9group.dev.