Un cliente paga un flat white en una cafetería de Múnich. La tableta del mostrador envía la venta a un servicio de firma, recibe una firma de vuelta y la imprime en el ticket antes de que la leche termine de calentarse. En el mostrador nadie piensa en ello, pero en ese paso de un segundo intervienen los cuatro actores de la fiscalización: la cafetería, la empresa que desarrolló el software de TPV de la tableta, el proveedor del componente de seguridad que firmó la venta y la autoridad fiscal que hace cumplir las normas que hicieron necesaria la firma.
Cada uno se encarga de una parte distinta del trabajo, y la ley reparte esas partes de forma diferente en cada país. Saber quién es responsable de qué importa sobre todo si desarrollas software de TPV, porque tu producto es donde se encuentran los otros tres.
En resumen
El negocio registra la venta y conserva la obligación legal sobre sus registros, aunque compre a terceros cada pieza técnica. El proveedor de EPOS o MPOS entrega el sistema y, en varios mercados, tiene obligaciones legales propias. El proveedor del componente de seguridad firma cada transacción para que no pueda modificarse sin que se note. La autoridad fiscal recibe los datos por transmisión (a diario en Italia, registro a registro en la modalidad Verifactu en España) o a petición durante una inspección (Alemania, Austria, Francia, Suecia).
¿Quiénes son los actores de la fiscalización?
La fiscalización tiene cuatro actores: el negocio que registra las ventas, el proveedor de EPOS o MPOS que desarrolla su sistema de punto de venta, el proveedor del componente de seguridad cuya firma hace detectable cualquier manipulación de una venta y la autoridad fiscal, que hace cumplir las normas y recibe los datos. Los tres primeros están unidos por contratos e integraciones; la ley impone obligaciones a cada uno de ellos directamente.
Ayuda imaginar un triángulo. El negocio, el proveedor del TPV y el proveedor del componente de seguridad ocupan los vértices, conectados por licencias y llamadas a la API. La autoridad fiscal está en el centro, porque las normas que aplica llegan a cada vértice por sí mismas, sin pasar de uno a otro a lo largo de la cadena.
El reparto tiene un motivo: ninguna parte puede hacer fiable un registro de ventas por sí sola. Un registro que el negocio controla de principio a fin demuestra poco ante un inspector, ya que es el propio negocio quien paga impuestos por él. El proveedor escribe el software, pero no puede dar fe de cada venta que se hace con él. El mecanismo de seguridad aporta la prueba de que un registro no se ha modificado desde que se creó: en la mayoría de los mercados, una firma de un componente que el negocio no controla.
El negocio: tiene la obligación y los registros
La mayoría de las leyes de fiscalización se dirigen primero al negocio. El § 146a del Código Tributario alemán (Abgabenordnung, AO) establece que quien registra operaciones comerciales con un sistema electrónico debe protegerlo con una TSE (Technische Sicherheitseinrichtung, el dispositivo técnico de seguridad alemán) certificada por el BSI y mantener los registros disponibles para las inspecciones fiscales. El mismo artículo obliga a ese negocio a comunicar a su oficina tributaria los sistemas que utiliza. Los negocios austriacos registran sus unidades de firma en FinanzOnline, y los suecos registran sus cajas registradoras en Skatteverket y comunican los cambios en un plazo de dos semanas.
En pocas palabras: el negocio debe el impuesto, así que la prueba es suya.
Esto se mantiene incluso cuando compra a terceros cada pieza técnica. Un restaurante puede contratar la licencia de su TPV a una empresa y su servicio de firma a otra, pero cuando llega un inspector y pide los datos de las transacciones, la petición va al restaurante. Externalizar la tecnología no externaliza la obligación.
Eso define lo que el negocio necesita de los otros dos vértices. Necesita un sistema que registre cada venta como exigen las normas. Y necesita que ese sistema le entregue todo lo que tiene que presentar o aportar: datos de registro, exportaciones, tickets. Las guías de fiskaly sobre la KassenSichV en Alemania y la RKSV en Austria explican esas obligaciones mercado por mercado.
El proveedor de EPOS o MPOS: desarrolla el sistema en el que encajan los demás
Los proveedores desarrollan y entregan el sistema de punto de venta: un EPOS (punto de venta electrónico) en una caja fija o un servidor de back office, o un MPOS (punto de venta móvil) en un móvil o una tableta. Es el vértice que convierte un requisito legal en un botón que pulsa un cajero. También es donde se conectan los otros dos vértices, ya que el negocio trabaja en el sistema y el componente de seguridad funciona dentro de él.
Es fácil suponer que la obligación termina en el comerciante. En varios mercados, la ley dice otra cosa:
- Alemania: el § 146a(1) AO prohíbe anunciar comercialmente o comercializar sistemas, software o TSE que no cumplan los requisitos.
- España: según el artículo 13 del Real Decreto 1007/2023, el productor certifica cada versión de su software de facturación en una declaración responsable, una declaración firmada de cumplimiento que entrega a sus clientes. Desde el 29 de julio de 2025, los productores tienen que ofrecer software adaptado. Está previsto que las obligaciones propias de los negocios empiecen en octubre de 2028, a falta de confirmación oficial a fecha de octubre de 2026.
- Francia: el propio software de TPV tiene que demostrar su conformidad, mediante una certificación de terceros o una declaración de conformidad en dos partes. El editor firma la primera parte y el comerciante, la segunda. La declaración solo es válida con ambas.
- Suecia: la propia caja registradora está cubierta por una declaración del fabricante según SKVFS 2014:9, la normativa de Skatteverket sobre los requisitos de las cajas registradoras.
Los comercios que desarrollan su propio TPV ocupan dos vértices a la vez, con las obligaciones del comerciante y las del proveedor en la misma empresa. Francia muestra lo que eso puede suponer: un editor que vende a terceros puede declarar él mismo su conformidad, pero el software desarrollado solo para uso interno necesita una certificación de terceros.
El proveedor del componente de seguridad: firma cada transacción
Un componente de seguridad es la parte del sistema que hace demostrable un registro. Firma cada transacción en el momento de registrarla y, en varios mercados, la encadena con la anterior, de modo que una edición o un borrado posterior rompe la cadena y aparece en una auditoría. Según el mercado, es un módulo de hardware, una tarjeta inteligente o un servicio en la nube al que el TPV llama a través de una API.
La Oficina Federal de Seguridad de la Información de Alemania (BSI) describe el reparto del trabajo con claridad: los fabricantes de TPV suelen integrar una TSE ya certificada en lugar de desarrollar y certificar una propia, y la certificación cubre solo la TSE, no el TPV ni su software. Donde un mercado tiene un componente separado, el patrón se repite: el TPV lo integra, y la aprobación que exija el mercado viene con el componente y no con el TPV.
Lo que significa esa aprobación varía más de lo que sugiere la palabra "certificado": va desde un certificado del BSI en Alemania hasta ninguna certificación de producto en Austria. En España y Francia, la ley ni siquiera contempla un componente separado. La tabla de más abajo compara seis mercados.
Para el proveedor, eso suele significar un conjunto distinto de requisitos y papeleo en cada mercado. Para el negocio, significa que el componente suele ser invisible: aparece como un código o una firma en el ticket y, donde se exige registro, en los datos presentados ante la autoridad fiscal.
La autoridad fiscal: hace cumplir las normas y recibe los datos
En la mayoría de los mercados, el cuarto actor es una autoridad fiscal nacional: el Ministerio de Finanzas de Austria a través de FinanzOnline, la Agenzia delle Entrate (AdE) en Italia, la AEAT en España, la DGFiP en Francia y Skatteverket en Suecia. España tiene excepciones regionales: las Haciendas Forales vascas gestionan TicketBAI, y la Hacienda Foral de Navarra gestiona NaTicket.
Alemania divide aún más el papel. El Ministerio Federal de Finanzas (BMF) dicta el reglamento KassenSichV, el BSI fija los requisitos técnicos consultando al BMF (§ 5 KassenSichV), y las oficinas tributarias de los estados federados (Finanzämter) reciben la comunicación de cada negocio y realizan las inspecciones.
La forma en que los datos llegan a la autoridad sigue uno de dos modelos. En el modelo de transmisión, la autoridad recibe los datos sin pedirlos. Los registratori telematici (RT) italianos envían a la AdE los datos de ventas del día una vez al día. En España, el software que funciona en modalidad Verifactu envía cada registro de facturación a la AEAT, mientras que los sistemas que no usan esa modalidad conservan los registros.
En el modelo a petición, los datos se quedan en el negocio hasta que un inspector los pide. Según la RKSV austriaca (§ 7 y § 19), el negocio exporta su registro de captura de datos (DEP) del periodo solicitado. Alemania, Francia y Suecia también comprueban los registros en las inspecciones.
Los dos modelos ponen el peso en lugares distintos. En el modelo a petición, la firma lo sostiene todo, porque la autoridad ve los datos meses o años después y confía en ella para demostrar que nada cambió entretanto. La transmisión necesita conectividad y una gestión adecuada de los reenvíos.
Cómo se ven los cuatro papeles en seis mercados
Los cuatro papeles son los mismos en todas partes; lo que cambia es la forma del componente de seguridad, quién lo avala y cómo viajan los datos.
| Mercado | Componente de seguridad | Quién lo avala | Cómo recibe los datos la autoridad fiscal |
|---|---|---|---|
| Alemania | Dispositivo técnico de seguridad (TSE), hardware o en la nube | Certificación del BSI | A petición, en las inspecciones |
| Austria | Unidad de creación de firma, tarjeta inteligente o en la nube | Certificado cualificado de un prestador de servicios de confianza eIDAS; la unidad debe cumplir los requisitos de eIDAS, sin certificación fiscal separada | A petición, como exportación del DEP (§ 7, § 19 RKSV) |
| Italia | Registratore telematico (RT) | Modelo de RT aprobado por la AdE | Transmisión diaria a la AdE |
| España | Requisitos integrados en el software de facturación | Declaración responsable del productor (art. 13, RD 1007/2023) | Cada registro en modalidad Verifactu; si no, conservado para inspección (obligaciones de los negocios desde 2028) |
| Francia | Requisitos integrados en el software de TPV | Certificación de terceros (LNE o InfoCert) o autodeclaración del editor (restablecida desde el 21 de febrero de 2026) | A petición, en una auditoría de la DGFiP |
| Suecia | Unidad de control (kontrollenhet, hardware) o sistema de control en la nube (kontrollsystem) | Organismo de certificación acreditado | A petición, en las visitas de control de Skatteverket |
Si lees la columna central de arriba abajo, salta a la vista una cosa: la autoridad fiscal rara vez aprueba el componente de seguridad en sí. Italia es el caso claro en que sí lo hace, mediante la aprobación de los modelos de RT por parte de la AdE. En los demás casos, lo avala un organismo de certificación, un prestador de servicios de confianza o la declaración firmada del propio productor. Las guías de fiskaly sobre certificación de terceros frente a autocertificación y sobre componentes de hardware frente a la nube profundizan en ambas cuestiones.
Qué significa esto si desarrollas software de TPV
"El cumplimiento es cosa del comerciante, no nuestra." Legalmente, eso es cierto en gran parte: la obligación recae en el negocio, y en Alemania, Austria y Suecia es el negocio quien se registra ante la autoridad fiscal.
Pero el comerciante solo puede cumplir esa obligación a través del sistema que tú entregas, así que hay tres decisiones que caen de tu lado del triángulo:
- Qué componente de seguridad usar en cada mercado, y si su aprobación cubre la forma en que lo despliegas.
- Si cada transacción pasa por él. Una venta que se salta el paso de la firma, por una ruta de código sin probar o una caída que el software no gestiona, deja un hueco en los registros del comerciante que el comerciante no puede ver.
- Qué necesita el negocio de ti para hacer sus trámites. Un comerciante austriaco que se registra en FinanzOnline tiene que comunicar el número de serie del certificado, el tipo de unidad de firma y los identificadores de las cajas registradoras. Si tu sistema no los muestra, o tu proveedor no automatiza el registro, el comerciante no puede completarlo.
Si desarrollas un TPV, el cumplimiento es a la vez la obligación legal del comerciante y una función de tu producto.
Puntos clave
- La obligación sigue siendo del negocio. Comprar software de TPV y un servicio de firma traslada el trabajo técnico, no la obligación legal ni los registros.
- Los proveedores tienen obligaciones propias. En varios mercados, quien fabrica o vende el sistema tiene obligaciones legales, así que "el responsable es el comerciante" nunca es la respuesta completa.
- "Certificado" necesita matiz. Comprueba quién avala el componente de seguridad en cada mercado antes de fiarte de la palabra.
- El modelo de datos marca la ingeniería. Donde los datos se transmiten, planifica caídas y reenvíos; donde esperan a un inspector, la firma y la exportación tienen que aguantar durante años.
Cómo encaja fiskaly
fiskaly es un proveedor de API en la nube para la fiscalización y el cumplimiento del IVA: el vértice del componente de seguridad en el triángulo. No vende sistemas de TPV ni procesa pagos.
En Alemania, SIGN DE es la Cloud-TSE líder del mercado y certificada por el BSI. SIGN SE es un sistema de control en la nube (kontrollsystem) conforme a SKVFS 2020:9, certificado por un organismo de certificación acreditado, y SIGN ES cubre Verifactu, TicketBAI y NaTicket con una sola API. SIGN AT firma los tickets, genera el DEP y automatiza el registro en FinanzOnline.
Los vértices son los mismos en todos los mercados; lo que cambia son las reglas del centro.
