Analisi completa degli esperti sulla conformità fiscale tedesca per i sistemi di gestione immobiliare che integrano il middleware fiskaltrust e i sistemi di sicurezza tecnica basati su cloud

Il panorama normativo che disciplina i sistemi di registrazione elettronica in Germania ha subito una profonda trasformazione dall'entrata in vigore della Legge sulla protezione contro la manipolazione dei documenti contabili digitali alla fine del 2016. Per gli operatori di sistemi di gestione immobiliare (PMS) che integrano funzionalità di punto vendita (POS), destreggiarsi tra il Codice fiscale tedesco (Abgabenordnung, AO), l'Ordinanza sulla sicurezza dei registratori di cassa (KassenSichV) e i Principi per la corretta gestione e conservazione di libri, registri e documenti in formato elettronico (GoBD) non è più un compito amministrativo facoltativo, ma un requisito fondamentale per un funzionamento legale. Questo rapporto fornisce un'analisi dettagliata di un sistema che utilizza il sistema di cassa cloud Sorglos di fiskaltrust in combinazione con un sistema di sicurezza tecnica (TSE) di Fiskaly, affrontando specificamente le sfumature della gestione del saldo e la legalità delle strutture di rendicontazione esclusivamente digitali.

L'evoluzione del § 146a AO e del quadro KassenSichV

Il principale pilastro giuridico della conformità fiscale tedesca è l'articolo 146a dell'Abgabenordnung, che impone a tutti i sistemi di registrazione elettronica utilizzati per documentare le transazioni commerciali di registrare ogni transazione in modo individuale, completo, corretto, tempestivo e ordinato. Per impedire la successiva manipolazione di questi documenti digitali, la legge richiede che tali sistemi siano dotati di un Sistema Tecnico di Sicurezza (TSE) certificato. Il KassenSichV, entrato in vigore il 1° gennaio 2020, fornisce le specifiche tecniche per questi requisiti, definendo i componenti obbligatori di un TSE: un modulo di sicurezza, un supporto di memorizzazione e un'interfaccia digitale.

Per i sistemi integrati in cui un PMS gestisce le prenotazioni delle camere e un piccolo POS gestisce l'ospitalità in loco o le vendite al dettaglio, l'intero ecosistema deve essere valutato come un sistema di registrazione elettronica (Elektronisches Aufzeichnungssystem). Il periodo di transizione per i sistemi che non erano tecnicamente in grado di essere dotati di un TSE si è concluso il 31 dicembre 2022, il che significa che a partire dal 2023, ogni sistema attivo dovrà essere pienamente conforme agli standard KassenSichV. Il sistema in esame, che utilizza un TSE basato su cloud fornito da Fiskaly e gestito tramite il middleware fiskaltrust, rappresenta il moderno standard di "Compliance-as-a-Service", spostando l'onere della manutenzione tecnica dal gestore dell'hotel a fornitori di servizi specializzati.

Componente regolamentare	Obiettivo primario	Requisito chiave di implementazione
§ 146a AO	Protezione dalla manipolazione	Utilizzo obbligatorio di un TSE certificato.
KassenSichV	Standardizzazione tecnica	Definizione dei componenti TSE e dei dati di ricezione.
GoBD	Contabilità ordinata	Immutabilità, completezza e tracciabilità.
DSFinV-K	Efficienza dell'audit	Interfaccia digitale standardizzata per l'esportazione dei dati.

Architettura tecnica del fiskaltrust Sorglos Cloud Cashbox

L'utilizzo del sistema Sorglos Cloud Cashbox di fiskaltrust è indice di una sofisticata strategia middleware. Il pacchetto "Sorglos" (senza pensieri) è progettato per fornire ai creatori e agli operatori POS una soluzione completa che gestisce la firma delle ricevute, la numerazione sequenziale e l'archiviazione a lungo termine in modo sicuro e senza revisioni. In questa architettura, il middleware funge da buffer sicuro tra l'applicazione PMS e il TSE.

Il ruolo del meccanismo CashBox e Queue

CashBox è un contenitore di configurazione logica all'interno del portale fiskaltrust. Definisce le modalità di interazione tra i vari componenti: la Coda, la Signature Creation Unit (SCU) e il TSE. La Coda funge da punto di ingresso per il PMS per l'invio dei dati delle transazioni. Ogni transazione inviata alla Coda viene sottoposta a hashing, le viene assegnato un numero univoco progressivo e viene collegata alla transazione precedente, creando una catena crittograficamente sicura.

Il numero di serie specifico fornito, WqK0pGTB0eSazQFMgKXuA, corrisponde a ftCashboxIdentification. Si tratta di un identificativo univoco, codificato in Base64, che deve essere stampato sulle ricevute o codificato in un codice QR. Consente ai revisori fiscali di ricondurre una specifica ricevuta a un sistema di registrazione logica univoco all'interno dell'infrastruttura dell'operatore. La designazione "Cloud" significa che l'intero stack middleware è ospitato in data center ad alta disponibilità (come Microsoft Azure), garantendo che la logica fiscale sia costantemente aggiornata e disponibile senza la necessità di manutenzione del server locale.

Fiskaly come sistema di sicurezza tecnica basato sul cloud

La scelta di Fiskaly come fornitore di TSE è un elemento fondamentale del profilo di conformità. Fiskaly offre un TSE basato su cloud 100%, completamente certificato dall'Ufficio Federale per la Sicurezza Informatica (BSI). A differenza dei TSE basati su hardware (chiavette USB o schede SD), soggetti a furto fisico o guasti, un TSE basato su cloud garantisce che i log delle transazioni siano archiviati in un ambiente distribuito e sicuro. La "data di messa in servizio" del 22/07/2025 indica un sistema operativo con le certificazioni più recenti ed è pronto per i rigorosi requisiti di reporting che entreranno in vigore a metà del 2025.

Gestione del saldo e conformità GoBD

Il sistema dell'utente utilizza diversi "saldi" per categorizzare i flussi di pagamento, ad esempio un saldo specifico per i pagamenti di persona. Questa separazione metodologica dei flussi di pagamento è strettamente allineata ai principi di ordine e chiarezza del GoBD.

Categorizzazione e tracciabilità

Ai sensi del GoBD, un requisito fondamentale è che le transazioni commerciali siano tracciabili dall'inizio alla registrazione finale nei bilanci (la "Belegfunktion"). Creando un saldo dedicato per i pagamenti di persona, il sistema facilita la "Kassensturzfähigkeit", ovvero la possibilità per un revisore fiscale di effettuare un conteggio non annunciato della cassa e confrontare il denaro effettivamente disponibile con i registri elettronici. La separazione dei pagamenti online (spesso elaborati da gateway di terze parti) dai pagamenti di persona in contanti o con carta garantisce che il registro elettronico rifletta accuratamente la realtà fisica presso il punto vendita.

La funzionalità di "Autoclose" menzionata nella documentazione di gestione del saldo è particolarmente rilevante per il requisito di "Zeitgerechtheit" (tempestività) del GoBD. Le transazioni in contanti dovrebbero idealmente essere registrate quotidianamente per prevenire la perdita di dati o il rischio di manipolazioni retrospettive. Le chiusure giornaliere automatiche inviate a fiskaltrust forniscono un ulteriore livello di sicurezza, poiché l'evento di chiusura stesso è una transazione firmata che azzera i contatori giornalieri e archivia i totali giornalieri in modo a prova di manomissione.

Tipo di saldo	Rilevanza GoBD	Beneficio di conformità
Contanti di persona	Kassensturzfähigkeit	Consente la verifica in tempo reale del denaro contante rispetto ai registri digitali.
Pagamenti online	Separazione netta	Impedisce la commistione di fondi elaborati con flussi di cassa fisici.
Chiusura automatica giornaliera	Tempestività	Garantisce che i documenti siano finalizzati e firmati entro i termini di legge.

Validità giuridica dell'ambiente di reporting esclusivamente digitale

Una questione centrale è se l'impossibilità di scaricare i report Z e X come file, ma di visualizzarli solo all'interno dell'applicazione, influisca sulla conformità del sistema. Per rispondere a questa domanda, è necessario analizzare la transizione dalla revisione contabile cartacea alla revisione contabile digitale nel diritto tributario tedesco.

Il passaggio dalle ricevute Z alle esportazioni DSFinV-K

Tradizionalmente, lo "Z-Bon" o ricevuta Z era il documento più importante per la verifica giornaliera delle entrate. Rappresentava il totale giornaliero finale e l'azzeramento del registratore di cassa. Tuttavia, con l'introduzione del DSFinV-K (Interfaccia digitale dell'Amministrazione fiscale per i sistemi di registrazione della cassa) e del TSE, l'enfasi giuridica si è spostata dal rapporto visivo al dati sottostanti.

Il DSFinV-K è un formato dati standardizzato che ogni sistema di registrazione elettronica deve essere in grado di esportare. Contiene diversi moduli, tra cui il modulo "Kassendatenabschluss" (Chiusura dei dati di cassa), che acquisisce esattamente le stesse informazioni di un tradizionale Z-report (totali per aliquota fiscale, metodi di pagamento e stato dello sportello), ma in un formato leggibile da computer (CSV o JSON).

Valutabilità della macchina e accesso ai dati (Z1, Z2, Z3)

Ai sensi del § 147 AO e del GoBD, l'autorità fiscale ha diritto a tre tipi di accesso ai dati:

1. Z1 (Unmittelbarer Datenzugriff): Il revisore utilizza il software del contribuente per visualizzare i registri.
2. Z2 (Mittelbarer Datenzugriff): Il contribuente fornisce i dati attraverso le valutazioni richieste dal revisore.
3. Z3 (Datenträgerüberlassung): Il contribuente fornisce un'esportazione di dati leggibile dalla macchina.

Poiché il sistema consente all'utente di visualizzare lo Z-report e l'X-report all'interno dell'applicazione, soddisfa il requisito "Z1". Poiché il sistema consente il download di un'esportazione DSFinV-K, soddisfa il requisito "Z3", che rappresenta il gold standard per le revisioni contabili moderne. Infatti, molti revisori fiscali moderni preferiscono l'esportazione DSFinV-K rispetto a una raccolta di Z-report in formato PDF, poiché l'esportazione può essere importata direttamente nel loro software di revisione (come IDEA) per un controllo incrociato automatico con i singoli registri delle transazioni. Pertanto, l'assenza di un pulsante "download" per lo Z-report non costituisce un problema di conformità; i dati vengono archiviati e forniti nel formato DSFinV-K, più solido dal punto di vista legale.

L'obbligo di emissione delle ricevute e gli standard del 2024

Dal 1° gennaio 2020, l'obbligo di emissione di una ricevuta (Belegausgabepflicht) è un principio fondamentale del KassenSichV. Ogni transazione deve essere accompagnata da una ricevuta che viene consegnata al cliente. Dal 1° gennaio 2024, i requisiti relativi al contenuto di queste ricevute sono diventati ancora più specifici.

Punti dati obbligatori sulla ricevuta

Una ricevuta conforme nel 2024 deve includere identificativi specifici sia per il sistema di registrazione che per il dispositivo tecnico di sicurezza. Il sistema in esame li genera tramite il middleware fiskaltrust e Fiskaly TSE.

Campo obbligatorio (2024)	Descrizione	Fonte in fiskaltrust/Fiskaly
Nome/indirizzo dell'operatore	Tutti i dettagli dell'attività.	Dati master nel portale.
Data e ora	Ora di inizio e fine della transazione.	ora_inizio, ora_fine.
Importo e descrizione	Articoli venduti e aliquote fiscali applicabili.	Dati sulle transazioni PMS.
Numero di serie ERS	Identificatore del sistema di registrazione.	ftCashboxIdentification.
Numero di serie TSS	ID univoco del modulo di sicurezza.	numero_di_serie_tss.
Contatore delle firme	Numero progressivo della firma.	Registro TSE.
Controlla il valore	Firma digitale della transazione.	valore della firma.

La legge consente che questi dettagli tecnici (numero di serie TSE, firma, ecc.) siano forniti come testo normale o come codice QR. Le autorità fiscali raccomandano vivamente la soluzione del codice QR, in quanto facilita il "Kassen-Nachschau" (controllo di cassa) non annunciato, durante il quale un funzionario può rapidamente scansionare il codice per verificare che la transazione sia stata registrata nel TSE in tempo reale. Poiché il sistema dell'utente è un PMS integrato nel cloud, è probabile che generi ricevute digitali o pronte per la stampa tramite l'API fiskaltrust che includono questi elementi richiesti.

DSFinV-K: lo standard per gli audit digitali

L'utente ha notato che è possibile scaricare un'esportazione DSFinV-K dall'app fiskaltrust all'interno del PMS. Questa è la caratteristica tecnica più importante per garantire la conformità agli audit. Il DSFinV-K garantisce che i dati siano strutturati in modo indipendente dal fornitore del software specifico, consentendo un processo di revisione standardizzato in tutti i settori in Germania.

Moduli dell'esportazione DSFinV-K

Una tipica esportazione DSFinV-K dal sistema fiskaltrust è costituita da diversi file CSV interconnessi, solitamente classificati in tre blocchi:

• Il modulo di registrazione individuale: Contiene bonkopf.csv e bonpositionen.csv, che documentano ogni articolo venduto e ogni modifica apportata a una transazione.
• Il modulo Master Data: Sono incluse informazioni sulla posizione, sui registratori di cassa specifici e sulle aliquote fiscali applicate.
• Modulo di chiusura dei dati in contanti: Questo modulo sostituisce il tradizionale Z-report. Riepiloga tutte le transazioni, i metodi di pagamento e i totali IVA per il periodo di chiusura giornaliero.

La disponibilità di questa esportazione significa che il sistema è "pronto per la verifica". Durante una "Kassen-Nachschau" o una verifica esterna completa, al contribuente viene spesso concesso un lasso di tempo molto breve (a volte 24-48 ore) per fornire questa specifica esportazione. Averla a disposizione direttamente nell'applicazione PMS rappresenta un significativo vantaggio in termini di conformità.

Conservazione dei dati a lungo termine e revisioni-Sicherheit

Il GoBD impone che tutti i dati rilevanti ai fini fiscali vengano conservati per dieci anni (o otto anni per determinati voucher) in modo "revisionssicher", ovvero che sia impossibile modificare i dati senza lasciare una traccia permanente della modifica.

Il ruolo del fiskaltrust PosArchive

Il pacchetto fiskaltrust Sorglos include "PosArchive", un sistema di archiviazione centralizzato basato su cloud, progettato specificamente per soddisfare le normative nazionali in materia di conservazione. Quando l'utente crea una chiusura giornaliera, i dati non vengono solo visualizzati nell'app, ma vengono trasmessi a PosArchive, dove vengono sottoposti a hash e archiviati in modo antimanomissione. Ciò garantisce che, anche se il fornitore del PMS dovesse cessare l'attività o l'hotel dovesse modificare la propria infrastruttura IT locale, i dati fiscali rimangano disponibili e verificabili per tutta la durata del periodo di conservazione di dieci anni.

Nuovi obblighi di rendicontazione per il 2025

Un requisito critico futuro di cui l'utente deve essere a conoscenza è la segnalazione obbligatoria di tutti i sistemi di registrazione elettronica all'ufficio delle imposte, che entrerà in vigore nel 2025. Ciò è imposto dalla Sezione 146a (4) dell'Abgabenordnung.

Requisiti e scadenze per la registrazione

Le aziende devono registrare i propri sistemi POS tramite il portale ufficiale ELSTER o tramite un'API integrata. Il sistema descritto dall'utente, la cui messa in servizio è prevista per luglio 2025, rientra direttamente nella finestra di applicazione primaria.

Evento	Scadenza per la segnalazione	Informazioni richieste
Messa in servizio iniziale	Entro un mese.	Nome, codice fiscale, numero di serie ERS, numero di serie TSE.
Sistema in uso prima di luglio 2025	Entro il 31 luglio 2025.	Tutti gli identificatori tecnici dello stack esistente.
Dismissione	Entro un mese.	Data di rimozione e registro delle transazioni finali.

Il pacchetto "Sorglos" e l'integrazione Fiskaly sono progettati per fornire facilmente questi dettagli di segnalazione. Il numero di serie WqK0pGTB0eSazQFMgKXuA (ftCashboxIdentification) e il numero di serie Fiskaly TSE sono i principali identificativi che devono essere presentati all'ufficio delle imposte. La mancata registrazione può essere considerata un illecito amministrativo, con possibili sanzioni fino a 25.000 euro.

Sintesi della conformità: il verdetto sul sistema

Per determinare se il sistema è conforme alla legge, lo valutiamo in base ai quattro requisiti legali principali del sistema fiscale tedesco.

1. Protezione contro la manipolazione (§ 146a AO)

Il sistema utilizza un TSE cloud certificato (Fiskaly) e un middleware certificato (fiskaltrust). Ogni transazione è firmata digitalmente e la sequenza è concatenata crittograficamente. Il numero di serie e la data di messa in servizio forniti indicano una configurazione moderna e certificata. Questo requisito è Completamente soddisfatto.

2. Esportazione standardizzata (DSFinV-K)

L'utente dichiara esplicitamente che è possibile scaricare un'esportazione DSFinV-K. Ciò soddisfa l'obbligo di fornire un'interfaccia digitale standardizzata per le verifiche fiscali e le ispezioni a sorpresa. Questo requisito è Completamente soddisfatto.

3. Contabilità e archiviazione ordinate (GoBD)

Il sistema gestisce saldi separati, utilizza una chiusura giornaliera automatizzata e archivia i dati in un archivio cloud a revisione sicura (fiskaltrust PosArchive). La modalità di "sola visualizzazione" dei report Z è consentita purché sia disponibile l'accesso ai dati "Z3" (DSFinV-K). Questo requisito è Completamente soddisfatto.

4. Emissione di ricevute (KassenSichV)

L'integrazione consente la creazione di ricevute con i dati TSE obbligatori. Il requisito è soddisfatto se queste ricevute vengono fornite all'ospite (in formato cartaceo o digitale, con il suo consenso). Questo requisito è Soddisfatto.

Documentazione procedurale: l'anello mancante

Mentre il tecnico componenti del sistema sono conformi, la conformità legale dipende anche dalla dell'operatore azioni. La carenza più frequente riscontrata durante gli audit è la mancanza di una “Verfahrensdokumentation” (documentazione procedurale).

Il GoBD richiede che ogni azienda conservi un documento che descriva l'intero processo di contabilità elettronica. Questo documento deve includere:

• Descrizione dell'architettura del sistema (PMS + fiskaltrust + Fiskaly).
• L'organizzazione dei saldi (di persona vs. online).
• Il sistema di controllo interno (chi ha accesso, come vengono corretti gli errori, come vengono verificate le chiusure giornaliere).
• I dettagli tecnici del TSE (numeri di serie, validità del certificato).
• La procedura per l'archiviazione e il recupero dei dati.

Poiché il sistema è basato su "Sorglos Cloud" e cloud-TSE, l'operatore può fare ampio affidamento sulla documentazione tecnica fornita da fiskaltrust e Fiskaly per le sezioni specifiche del sistema. Tuttavia, i processi aziendali interni (la parte "organizzativa") devono comunque essere documentati dall'operatore alberghiero.

Analisi dettagliata del meccanismo di chiusura giornaliera

La descrizione dell'utente relativa alla "chiusura giornaliera automatica" inviata a fiskaltrust è un elemento essenziale per la conformità. Nel contesto del KassenSichV, una chiusura giornaliera è più di un semplice riepilogo delle vendite: è una "Sicherungsbeleg" (ricevuta di sicurezza).

Zero ricevute e registri di chiusura

Quando viene eseguita una chiusura giornaliera nel sistema fiskaltrust, il middleware genera spesso una "Ricevuta Zero" (Nullbeleg). Si tratta di una ricevuta specializzata che non contiene voci o pagamenti, ma innesca un cambiamento di stato nel TSE, finalizzando la sequenza corrente di transazioni. Questo evento viene quindi registrato nell'"ActionJournal" del portale fiskaltrust. Per il revisore, la coerenza tra i totali giornalieri riportati dal PMS e queste "Ricevute Zero" firmate crittograficamente nel registro fiskaltrust è la prova che il sistema non è stato manipolato per "nascondere" le transazioni tra i turni.

Implicazione del formato del numero di serie

Il numero di serie, ad esempio WqK0p……., segue il formato standard per ftCashboxIdentification. Questa stringa alfanumerica è la codifica Base64 dell'ID interno di CashBox. In caso di controllo fiscale, il revisore scannerizzerà il codice QR su una ricevuta e si aspetterà di vedere questo identificativo. Quindi, abbinerà questo identificativo al file cashregister.csv dell'esportazione DSFinV-K, in particolare al campo KASSE_SERIENNR. Il fatto che queste informazioni siano chiaramente visibili all'interno dell'applicazione PMS garantisce che l'operatore possa fornirle immediatamente su richiesta durante un "Kassen-Nachschau".“

Conclusione e raccomandazioni attuabili per campeggi

Sulla base della configurazione tecnica descritta, il sistema è conforme alla legge con le attuali normative fiscali tedesche. La combinazione di Fiskaltrust Sorglos Cloud Cashbox e Fiskaly cloud-TSE soddisfa i requisiti di protezione da manipolazioni, reporting standardizzato e archiviazione a lungo termine. L'assenza di un formato PDF scaricabile per i report Z e X non costituisce una violazione legale, poiché il sistema fornisce i dati "Kassendatenabschluss" richiesti tramite l'esportazione DSFinV-K più rigorosa.

Per mantenere questa conformità e prepararsi per i futuri audit, si consiglia ai proprietari di campeggi di seguire i seguenti passaggi:

• Compilare una documentazione procedurale: Il campeggio deve integrare le specifiche tecniche di Fiskaltrust Cloud Cashbox e Fiskaly TSE in un documento procedurale completo e conforme al GoBD. Un esempio di documento è disponibile qui. Qui.
• Segnalazione del portale ELSTER: Accedi al portale fiskaltrust per recuperare le date di attivazione precise e i numeri di serie necessari per la procedura di rendicontazione ELSTER. Assicurati che, in quanto campeggio, il sistema sia registrato presso l'ufficio delle imposte locale.