Análisis exhaustivo por expertos del cumplimiento fiscal alemán para sistemas de gestión de propiedades que integran el middleware fiskaltrust y sistemas de seguridad técnica basados en la nube.

El marco regulatorio que rige los sistemas de registro electrónico en Alemania ha experimentado una profunda transformación desde la entrada en vigor de la Ley de Protección contra la Manipulación de Registros Básicos Digitales a finales de 2016. Para los operadores de Sistemas de Gestión de Propiedades (PMS) que incorporan funcionalidades de Punto de Venta (TPV), comprender la intersección del Código Fiscal Alemán (Abgabenordnung, AO), la Ordenanza de Seguridad de Cajas (KassenSichV) y los Principios para la Gestión y Almacenamiento Correctos de Libros, Registros y Documentos en Formato Electrónico (GoBD) ya no es una tarea administrativa opcional, sino un requisito fundamental para operar legalmente. Este informe ofrece un análisis detallado de un sistema que utiliza la caja de seguridad en la nube fiskaltrust Sorglos junto con un Sistema de Seguridad Técnica (TSE) de Fiskaly, abordando específicamente los matices de la gestión de saldos y la legalidad de las estructuras de informes exclusivamente digitales.

La evolución del artículo 146a de la Ley de Procedimiento Administrativo y el marco jurídico KassenSichV

El pilar fundamental del cumplimiento fiscal alemán es el artículo 146a de la Ley de Registro de Transacciones (Abgabenordnung), que exige que todos los sistemas de registro electrónico utilizados para documentar transacciones comerciales registren cada transacción de forma individual, completa, correcta, oportuna y ordenada. Para evitar la manipulación posterior de estos registros digitales, la ley exige que dichos sistemas estén equipados con un Sistema de Seguridad Técnica (TSE) certificado. La Ley de Seguridad de Cajas (KassenSichV), que entró en vigor el 1 de enero de 2020, establece las especificaciones técnicas para estos requisitos, definiendo los componentes obligatorios de un TSE: un módulo de seguridad, un soporte de almacenamiento y una interfaz digital.

Para sistemas integrados donde un PMS gestiona las reservas de habitaciones y un pequeño TPV gestiona las ventas de hostelería o comercio en el establecimiento, todo el ecosistema debe evaluarse como un sistema de registro electrónico (Elektronisches Aufzeichnungssystem). El período de transición para los sistemas que no eran técnicamente aptos para la adaptación con un TSE finalizó el 31 de diciembre de 2022, lo que significa que, a partir de 2023, todos los sistemas activos deben cumplir plenamente con las normas KassenSichV. El sistema en revisión, que utiliza un TSE basado en la nube proporcionado por Fiskaly y gestionado mediante el middleware fiskaltrust, representa el estándar moderno de “Cumplimiento como servicio”, transfiriendo la responsabilidad del mantenimiento técnico del operador hotelero a proveedores de servicios especializados.

Componente regulatorio	Objetivo principal	Requisito clave de implementación
§ 146a AO	Protección contra manipulación	Uso obligatorio de un TSE certificado.
KassenSichV	Estandarización técnica	Definición de los componentes de las ETS y datos de recepción.
GoBD	Contabilidad ordenada	Inmutabilidad, integridad y trazabilidad.
DSFinV-K	Eficiencia de la auditoría	Interfaz digital estandarizada para la exportación de datos.

Arquitectura técnica de la caja de efectivo en la nube Sorglos de fiskaltrust

El uso de fiskaltrust Sorglos Cloud Cashbox indica una estrategia de middleware sofisticada. El paquete “Sorglos” (sin preocupaciones) está diseñado para proporcionar a los creadores y operadores de puntos de venta una solución integral que gestiona la firma de recibos, la numeración secuencial y el archivo a largo plazo de forma segura para las revisiones. En esta arquitectura, el middleware actúa como un búfer seguro entre la aplicación PMS y el TSE.

El papel de la caja registradora y el mecanismo de colas

CashBox es un contenedor de configuración lógica dentro del portal fiskaltrust. Define cómo interactúan los distintos componentes: la cola, la unidad de creación de firmas (SCU) y el TSE. La cola sirve como punto de entrada para que el PMS envíe sus datos de transacción. Cada transacción enviada a la cola se somete a una función hash, se le asigna un número único y secuencial, y se vincula con la transacción anterior, creando así una cadena criptográficamente segura.

El número de serie específico proporcionado, WqK0pGTB0eSazQFMgKXuA, corresponde a ftCashboxIdentification. Este es un identificador único codificado en Base64 que debe imprimirse en los recibos o codificarse en un código QR. Permite a los auditores fiscales rastrear un recibo específico hasta un sistema de registro lógico único dentro de la infraestructura del operador. La designación "Cloud" significa que todo este conjunto de software intermedio está alojado en centros de datos de alta disponibilidad (como Microsoft Azure), lo que garantiza que la lógica fiscal se actualice y esté disponible de forma constante sin necesidad de mantenimiento de servidores locales.

Fiskaly como sistema de seguridad técnica basado en la nube

La selección de Fiskaly como proveedor de TSE es un elemento crucial del perfil de cumplimiento. Fiskaly ofrece un TSE basado en la nube 100% totalmente certificado por la Oficina Federal de Seguridad de la Información (BSI). A diferencia de los TSE basados en hardware (memorias USB o tarjetas SD), que son susceptibles a robos o fallos físicos, un TSE en la nube garantiza que los registros de transacciones se almacenen en un entorno distribuido y seguro. La fecha de puesta en marcha del 22 de julio de 2025 indica que el sistema opera bajo las certificaciones más recientes y está preparado para los rigurosos requisitos de informes que entrarán en vigor a mediados de 2025.

Gestión del saldo y cumplimiento de GoBD

El sistema del usuario utiliza diferentes “saldos” para categorizar los flujos de pago, como un saldo específico para los pagos presenciales. Esta separación metodológica de los flujos de pago se ajusta plenamente a los principios de orden y claridad del Gobierno de Bangladesh.

Categorización y trazabilidad

Según la normativa GoBD, un requisito fundamental es que las transacciones comerciales sean rastreables desde su origen hasta su registro final en los estados financieros (la “función contable”). Al crear un saldo específico para los pagos presenciales, el sistema facilita la “capacidad de control de efectivo” (Kassensturzfähigkeit), es decir, la posibilidad de que un auditor fiscal realice un recuento de efectivo sin previo aviso y compare el efectivo real disponible con los registros electrónicos. La separación de los pagos en línea (que a menudo se procesan mediante plataformas de terceros) de los pagos presenciales en efectivo o con tarjeta garantiza que el libro mayor electrónico refleje con precisión la realidad física en el punto de venta.

La función de "Cierre automático" mencionada en la documentación de gestión de saldos es especialmente relevante para el requisito de puntualidad (Zeitgerechtheit) del Gobierno de Bangladesh. Idealmente, las transacciones en efectivo deberían registrarse diariamente para evitar la pérdida de datos o la posible manipulación retroactiva. Los cierres diarios automatizados que se envían a fiskaltrust proporcionan una capa adicional de seguridad, ya que el propio cierre es una transacción firmada que reinicia los contadores diarios y archiva los totales del día de forma inalterable.

Tipo de equilibrio	Relevancia del GoBD	Beneficio de cumplimiento
Efectivo en persona	Kassensturzfähigkeit	Permite la verificación en tiempo real del efectivo físico frente a los registros digitales.
Pagos en línea	Separación clara	Evita que los fondos procesados se mezclen con los flujos de efectivo físicos.
Cierre automático diario	Oportunidad	Garantiza que los registros se finalicen y firmen dentro de los plazos legales.

Validez jurídica del entorno de informes exclusivamente digitales

Una cuestión central que se plantea es si la imposibilidad de descargar los informes Z y X como archivos —y, en su lugar, visualizarlos únicamente dentro de la aplicación— afecta al cumplimiento normativo del sistema. Para abordar esta cuestión, es necesario analizar la transición de la auditoría en papel a la auditoría digital en la legislación fiscal alemana.

El cambio de los recibos Z a las exportaciones DSFinV-K

Tradicionalmente, el “Z-Bon” o recibo Z era el documento más importante para la verificación diaria de los ingresos. Representaba el total diario final y el cierre del registro. Sin embargo, con la introducción del DSFinV-K (Interfaz digital de la administración tributaria para sistemas de caja registradora) y el TSE, el énfasis legal ha cambiado del informe visual hacia datos subyacentes.

El formato DSFinV-K es un formato de datos estandarizado que todo sistema de registro electrónico debe poder exportar. Contiene varios módulos, incluido el módulo "Kassendatenabschluss" (Cierre de datos de caja), que captura exactamente la misma información que un informe Z tradicional (totales por tipo impositivo, métodos de pago y estado de la ventanilla), pero en un formato legible por máquina (CSV o JSON).

Evaluabilidad de máquinas y acceso a datos (Z1, Z2, Z3)

Según el artículo 147 de la Ley de Impuestos y la Ley de Impuestos sobre la Renta, la autoridad tributaria tiene derecho a tres tipos de acceso a los datos:

1. Z1 (Unmittelbarer Datenzugriff): El auditor utiliza el software del contribuyente para consultar los registros.
2. Z2 (Mittelbarer Datenzugriff): El contribuyente proporciona los datos a través de las evaluaciones solicitadas por el auditor.
3. Z3 (Datenträgerüberlassung): El contribuyente proporciona una exportación de datos legible por máquina.

Dado que el sistema permite al usuario visualizar los informes Z y X dentro de la aplicación, cumple con el requisito "Z1". Asimismo, al permitir la descarga de una exportación DSFinV-K, cumple con el requisito "Z3", considerado el estándar de referencia para las auditorías modernas. De hecho, muchos auditores fiscales modernos prefieren la exportación DSFinV-K a una colección de informes Z en formato PDF, ya que la exportación puede integrarse directamente en su software de auditoría (como IDEA) para la comparación automatizada con los registros de transacciones individuales. Por lo tanto, la ausencia de un botón de descarga del informe Z no constituye un incumplimiento normativo; los datos se archivan y se proporcionan en el formato DSFinV-K, que ofrece mayor solidez legal.

La obligación de emisión de recibos y las normas de 2024

Desde el 1 de enero de 2020, la obligación de emitir recibos es un principio fundamental de la Ley de Servicios Financieros (KassenSichV). Toda transacción debe generar un recibo que se entrega al cliente. A partir del 1 de enero de 2024, los requisitos para el contenido de estos recibos se vuelven aún más específicos.

Datos obligatorios en el recibo

Un recibo que cumpla con la normativa en 2024 deberá incluir identificadores específicos tanto para el sistema de registro como para el dispositivo de seguridad técnica. El sistema en cuestión genera estos identificadores mediante el middleware fiskaltrust y Fiskaly TSE.

Campo obligatorio (2024)	Descripción	Fuente en fiskaltrust/Fiskaly
Nombre/Dirección del operador	Información completa sobre el negocio.	Datos maestros en el portal.
Fecha y hora	Hora de inicio y hora de finalización de la transacción.	hora_inicio, hora_fin.
Cantidad y descripción	Artículos vendidos y tipos impositivos aplicables.	Datos de transacciones del PMS.
Número de serie ERS	Identificador del sistema de grabación.	ftIdentificación de la caja registradora.
Número de serie TSS	Identificador único del módulo de seguridad.	tss_número_de_serie.
Contador de firmas	Número consecutivo de la firma.	Registro TSE.
Valor de comprobación	Firma digital de la transacción.	valor de la firma.

La ley permite que estos detalles técnicos (número de serie TSE, firma, etc.) se proporcionen en texto plano o como código QR. Las autoridades fiscales recomiendan encarecidamente la solución del código QR, ya que facilita la inspección de efectivo sin previo aviso, donde un funcionario puede escanear rápidamente el código para verificar que la transacción se registró en el TSE en tiempo real. Dado que el sistema del usuario es un PMS integrado en la nube, probablemente genere recibos digitales o recibos listos para imprimir a través de la API de fiskaltrust que incluyan estos elementos requeridos.

DSFinV-K: El estándar para auditorías digitales

El usuario señaló que se puede descargar una exportación DSFinV-K desde la aplicación fiskaltrust dentro del PMS. Esta es la característica técnica más importante para garantizar el cumplimiento de las auditorías. El DSFinV-K asegura que los datos estén estructurados de forma independiente del proveedor de software, lo que permite un proceso de revisión estandarizado en todos los sectores de Alemania.

Módulos de la exportación DSFinV-K

Una exportación típica de DSFinV-K desde el sistema fiskaltrust consta de varios archivos CSV interconectados, generalmente categorizados en tres bloques:

• El módulo de registro individual: Este archivo contiene los archivos bonkopf.csv y bonpositionen.csv, que documentan cada artículo vendido y cada cambio realizado en una transacción.
• El módulo de datos maestros: Esto incluye información sobre la ubicación, las cajas registradoras específicas y los tipos impositivos aplicados.
• Módulo de cierre de datos de efectivo: Este módulo sustituye al informe Z tradicional. Resume todas las transacciones, los métodos de pago y los totales de IVA correspondientes al cierre diario.

El hecho de que esta exportación esté disponible significa que el sistema está preparado para auditorías. Durante una auditoría externa completa, el contribuyente suele disponer de un plazo muy breve (a veces de 24 a 48 horas) para proporcionar esta exportación específica. Tenerla accesible directamente desde la aplicación PMS supone una importante ventaja en materia de cumplimiento normativo.

Revisiones y retención de datos a largo plazo-Sicherheit

La GoBD exige que todos los datos relevantes para fines fiscales se almacenen durante diez años (u ocho años para ciertos comprobantes) de una manera que sea "revisionssicher", lo que significa que debe ser imposible cambiar los datos sin dejar un registro permanente de la modificación.

El papel del fiskaltrust PosArchive

El paquete fiskaltrust Sorglos incluye el “PosArchive”, un sistema de almacenamiento centralizado en la nube diseñado específicamente para cumplir con las normativas nacionales de retención de datos. Cuando el usuario crea un cierre diario, los datos no solo se muestran en la aplicación, sino que se transmiten al PosArchive, donde se cifran y almacenan de forma inalterable. Esto garantiza que, incluso si el proveedor del PMS cesara su actividad o el hotel modificara su infraestructura informática local, los datos fiscales permanezcan disponibles y verificables durante el período de retención de diez años.

Nuevas obligaciones de información para 2025

Un requisito crucial que el usuario debe conocer es la obligación de informar a la oficina tributaria sobre todos los sistemas de registro electrónico, lo cual comenzará en 2025. Esto está estipulado en el artículo 146a (4) del Reglamento de Obligaciones.

Requisitos y plazos de inscripción

Las empresas deben registrar sus sistemas de punto de venta a través del portal oficial de ELSTER o mediante una API integrada. El sistema descrito por el usuario, cuya puesta en marcha está prevista para julio de 2025, se encuentra dentro del período de aplicación principal de la normativa.

Evento	Fecha límite para la presentación de informes	Información requerida
Puesta en marcha inicial	Dentro de un mes.	Nombre, número de identificación fiscal, número de serie ERS, número de serie TSE.
Sistema en uso antes de julio de 2025	Para el 31 de julio de 2025.	Todos los identificadores técnicos de la pila existente.
Desmantelamiento	Dentro de un mes.	Fecha de eliminación y registro de transacciones final.

El paquete “Sorglos” y la integración con Fiskaly están diseñados para facilitar la presentación de estos datos. El número de serie WqK0pGTB0eSazQFMgKXuA (ftCashboxIdentification) y el número de serie TSE de Fiskaly son los identificadores principales que deben presentarse ante la oficina tributaria. El incumplimiento de este requisito puede considerarse una infracción administrativa, con posibles multas de hasta 25 000 €.

Síntesis del cumplimiento: El veredicto sobre el sistema

Para determinar si el sistema cumple con la legislación vigente, lo evaluamos en función de los cuatro requisitos legales principales del sistema fiscal alemán.

1. Protección contra la manipulación (§ 146a AO)

El sistema utiliza un TSE en la nube certificado (Fiskaly) y un middleware certificado (fiskaltrust). Cada transacción está firmada digitalmente y la secuencia está encadenada criptográficamente. El número de serie y la fecha de puesta en marcha proporcionados indican una configuración moderna y certificada. Este requisito es Totalmente satisfecho.

2. Exportación estandarizada (DSFinV-K)

El usuario declara explícitamente que se puede descargar una exportación DSFinV-K. Esto cumple con la obligación de proporcionar una interfaz digital estandarizada para auditorías fiscales e inspecciones sin previo aviso. Este requisito es Totalmente satisfecho.

3. Contabilidad y archivo ordenados (GoBD)

El sistema gestiona saldos separados, utiliza un cierre diario automatizado y archiva los datos en un archivo en la nube seguro para revisiones (fiskaltrust PosArchive). Se permite la naturaleza de "solo lectura" de los informes Z siempre que esté disponible el acceso a los datos "Z3" (DSFinV-K). Este requisito es Totalmente satisfecho.

4. Emisión de recibos (KassenSichV)

La integración permite la creación de recibos con los datos TSE obligatorios. Siempre que estos recibos se ofrezcan al huésped (ya sea en formato impreso o digital con su consentimiento), se cumple el requisito. Este requisito es Satisfecho.

Documentación de procedimientos: El eslabón perdido

Mientras que el técnico Los componentes del sistema cumplen, el cumplimiento legal también depende de ello. del operador acciones. La deficiencia más frecuente encontrada durante las auditorías es la falta de una “Verfahrensdokumentation” (documentación de procedimientos).

El GoBD exige que cada empresa mantenga un documento que describa todo el proceso de contabilidad electrónica. Este documento debe incluir:

• Descripción de la arquitectura del sistema (PMS + fiskaltrust + Fiskaly).
• La organización de los saldos (Presencial vs. Online).
• El sistema de control interno (quién tiene acceso, cómo se corrigen los errores, cómo se verifican los cierres diarios).
• Los detalles técnicos del TSE (números de serie, validez del certificado).
• El procedimiento para el archivo y la recuperación de datos.

Dado que el sistema se basa en Sorglos Cloud y en la plataforma TSE en la nube, el operador puede confiar plenamente en la documentación técnica proporcionada por fiskaltrust y Fiskaly para las secciones específicas del sistema. Sin embargo, los procesos internos de negocio (la parte organizativa) deben ser documentados por el operador del hotel.

Análisis detallado del mecanismo de cierre diario

La descripción que el usuario hace del “cierre diario automático” que se envía a fiskaltrust es un requisito fundamental para el cumplimiento normativo. En el contexto de la KassenSichV, un cierre diario es más que un simple resumen de las ventas; es un “Sicherungsbeleg” (recibo de seguridad).

Registros de recibos cero y cierres

Cuando se realiza el cierre diario en el sistema fiskaltrust, el middleware suele generar un recibo nulo (Nullbeleg). Este recibo especializado no contiene transacciones ni pagos, pero activa un cambio de estado en el TSE, finalizando la secuencia actual de transacciones. Este evento se registra en el diario de transacciones del portal fiskaltrust. Para el auditor, la coherencia entre los totales diarios reportados por el PMS y estos recibos nulos firmados criptográficamente en el diario fiskaltrust demuestra que el sistema no ha sido manipulado para ocultar transacciones entre turnos.

Implicaciones del formato del número de serie

El número de serie, por ejemplo WqK0p…, sigue el formato estándar para ftCashboxIdentification. Esta cadena alfanumérica es la codificación Base64 del ID interno de CashBox. En caso de una inspección fiscal, el auditor escaneará el código QR del recibo y esperará ver este identificador. A continuación, lo comparará con el archivo cashregister.csv de la exportación DSFinV-K, específicamente con el campo KASSE_SERIENNR. El hecho de que esta información sea claramente visible en la aplicación PMS garantiza que el operador pueda proporcionarla inmediatamente si se le solicita durante una revisión de caja.“

Conclusión y recomendaciones prácticas para campings

Con base en la configuración técnica descrita, el sistema es legalmente conforme Conforme a la normativa fiscal alemana vigente, la combinación de fiskaltrust Sorglos Cloud Cashbox y Fiskaly cloud-TSE satisface los requisitos de protección contra manipulaciones, informes estandarizados y archivo a largo plazo. La ausencia de un formato PDF descargable para los informes Z y X no constituye una infracción legal, ya que el sistema proporciona los datos de "Kassendatenabschluss" necesarios mediante la exportación DSFinV-K, más rigurosa.

Para mantener este cumplimiento y prepararse para futuras auditorías, se recomiendan los siguientes pasos para los propietarios de campings:

• Elaborar documentación de procedimientos: El camping debe integrar las especificaciones técnicas de fiskaltrust Cloud Cashbox y Fiskaly TSE en un documento de procedimiento completo que cumpla con GoBD. Un ejemplo de documento se puede encontrar aquí.
• Informar a través del portal ELSTER: Inicie sesión en el portal de fiskaltrust para obtener las fechas de activación y los números de serie necesarios para el proceso de declaración de ELSTER. Asegúrese de que, como camping, el sistema esté registrado en la oficina tributaria local.