Nei prossimi anni quasi ogni azienda bulgara affronterà la stessa prova: il SAF-T. Il file contabile standardizzato per l'Agenzia nazionale delle entrate bulgara (NAP) viene introdotto a ondate dal 2026 al 2030, in base al § 17 delle disposizioni transitorie e finali della legge bulgara sul bilancio dello Stato per il 2025: prima le grandi imprese sopra le soglie ed entro il 2030 tutte le altre, comprese le microimprese registrate ai fini IVA. Il ritmo è mensile: il file si presenta entro la fine del mese successivo a quello di riferimento, e in caso di rifiuto ci sono solo 7 giorni per correggerlo. In altre parole, gli errori costano cari e il tempo per reagire è poco.
In questo contesto il nostro team ha costruito SAFTCheck, uno strumento gratuito per verificare i file SAF-T con una particolarità architetturale insolita: il file non lascia mai il browser dell'utente. In questo articolo raccontiamo con franchezza (il progetto è nostro) quali decisioni abbiamo preso, perché e cosa abbiamo imparato lungo la strada. Non per darci una pacca sulla spalla, ma perché gli stessi principi valgono per qualsiasi prodotto che lavora con dati sensibili.
Se stai pensando a uno strumento simile per la tua attività, questo è il case study che avremmo voluto leggere prima di iniziare.
La sfida: come conquisti la fiducia quando chiedi dati contabili
Un file SAF-T non è semplicemente un XML. Dentro c'è l'intera contabilità dell'azienda per il mese: movimenti dei conti, saldi, controparti, documenti. Sono dati che i contabili, per abitudine (e a ragione), custodiscono come la pupilla dei loro occhi. Il classico modello SaaS, “carica il file da noi e lo controlliamo”, parte con un enorme svantaggio davanti a questo pubblico. Ogni caricamento su un server è una domanda a cui devi rispondere: dove vanno i dati, chi vi ha accesso, per quanto tempo vengono conservati, cosa succede in caso di violazione.
La seconda particolarità del compito era il tempo. Il SAF-T arriva a ondate e il mercato si sta appena formando: la prima ondata riguarda le grandi imprese dal 2026, ma le domande iniziano molto prima. Volevamo uno strumento utile già nel momento in cui il contabile si scontra per la prima volta con l'obbligo, non solo quando ha un file pronto da presentare.
Abbiamo formulato il compito così: togliere tutte le barriere tra l'utente e la verifica. Niente registrazione, niente email, niente caricamento, niente prezzo. Ogni barriera eliminata è un motivo in meno per non provare.
Le tre decisioni che hanno definito il progetto
La verifica avviene nel browser
La validazione avviene in locale grazie a libxml2 compilata in WebAssembly. Non c'è un server che riceve file, quindi non c'è niente che possa trapelare.
Un sito statico
Circa 120 KB al primo caricamento, compressione brotli, cache immutable. Si apre all'istante anche su un portatile aziendale tramite la VPN dell'ufficio.
Solo fonti primarie
Tutto sul sito si basa direttamente sui documenti della NAP, non su rielaborazioni. Quando un tema è nuovo, la precisione è l'unica moneta.
Decisione n. 1: la verifica avviene interamente nel browser
La decisione architetturale più importante l'abbiamo presa fin dall'inizio: la validazione viene eseguita in locale, nel browser dell'utente, tramite WebAssembly. Abbiamo compilato libxml2, la stessa libreria che da decenni si occupa della validazione XML nel settore, in un modulo WASM che carica lo schema XSD ufficiale della NAP (v1.0.2) e controlla il file sul posto.
Ma lo schema è solo l'inizio. L'XSD dice se il file è strutturalmente valido, non se ha senso dal punto di vista contabile. Per questo ci abbiamo aggiunto sopra controlli nostri:
- Quadrature dei saldi per conto e corrispondenza di TotalDebit/TotalCredit
- Riferimenti incrociati: ogni documento deve rimandare a una controparte realmente dichiarata
- Codifica UTF-8 e nome del file secondo l'Allegato 3
- Cifra di controllo dell'EIK (il codice identificativo bulgaro delle imprese): un piccolo dettaglio che può far fallire un file altrimenti perfetto
Il vantaggio dell'elaborazione locale è doppio. Per l'utente: non c'è niente che possa trapelare, perché non viene caricato nulla. La promessa di riservatezza non è un paragrafo in un'informativa sulla privacy, ma una proprietà dell'architettura, che chiunque può verificare nel pannello Rete del proprio browser. Per noi: non c'è un server che elabora dati contabili altrui, quindi non c'è nemmeno tutto il carico operativo e legale che ne deriva.
Decisione n. 2: un sito statico invece di una piattaforma
Dato che la validazione avviene sul client, il server non ha niente da calcolare. Per questo l'intero sito è statico: il caricamento iniziale è di circa 120 KB, tutto passa per la compressione brotli e gli asset vengono messi in cache come immutable. In pratica lo strumento si apre all'istante anche su un portatile aziendale tramite la VPN dell'ufficio: proprio l'ambiente in cui lavora il nostro pubblico reale.
L'architettura statica ci ha permesso anche di essere coerenti fino in fondo: il sito non ha cookie né tracker esterni, e le statistiche sono nostre e anonime. Sarebbe stato assurdo promettere che il file non lascia il browser e allo stesso tempo inviare il comportamento dell'utente a tre piattaforme pubblicitarie.
Decisione n. 3: contenuti solo da fonti primarie
La terza decisione non è tecnica ma editoriale: tutto sul sito si basa direttamente sui documenti della NAP, non su rielaborazioni. Quando un tema è nuovo e carico di tensione, la precisione è l'unica moneta.
Così intorno alla verifica vera e propria è cresciuto un intero livello di strumenti di supporto. Abbiamo realizzato una guida a tutti i 347 elementi dello schema con le descrizioni ufficiali della NAP, più le nomenclature e il piano dei conti nazionale. Abbiamo aggiunto un calcolatore “In quale ondata sono?” per le scadenze 2026-2030, un glossario degli errori con dieci pagine di approfondimento e uno strumento in cui incollare l'errore, “Spiegami l'errore”, oltre a un indice di tutte le 188 domande e risposte ufficiali del documento della NAP (versione 2, 2026).
Il pezzo più recente è un convertitore in beta: fornisci il bilancio di verifica e il libro giornale in CSV e ottieni un SAF-T XML mensile, di nuovo interamente nel browser e gratis durante la beta. È il seguito logico dello stesso principio: se la verifica può essere locale, perché non anche la compilazione? Puoi vederlo all'opera nell'app del convertitore.
Cosa abbiamo imparato
La velocità fa parte della fiducia
Siamo abituati a pensare alla velocità come a una metrica SEO. Qui si è rivelata qualcosa di più: uno strumento che si apre all'istante e funziona senza registrazione trasmette un segnale di serietà. Vale anche il contrario: un sito lento con un modulo per l'email prima del risultato dice “prima tu dai qualcosa a noi, poi noi a te”.
La privacy si dimostra, non si dichiara
La differenza tra “non condividiamo i tuoi dati” e “i tuoi dati fisicamente non arrivano a noi” è la differenza tra una promessa e un fatto. La seconda è più difficile da costruire, ma incomparabilmente più facile da comunicare: si spiega in una frase e la può verificare qualsiasi utente con un minimo di competenze tecniche.
Le fonti primarie sono un vantaggio competitivo
Ricavare contenuti direttamente dallo schema e dalle risposte ufficiali della NAP è un lavoro lento e noioso. Proprio per questo quasi nessuno lo fa, e proprio per questo ripaga. Davanti a un pubblico professionale non c'è argomento più forte che citare con precisione la fonte primaria.
Cosa significa per te
Se la tua azienda sta valutando uno strumento che lavora con dati sensibili (finanziari, medici, personali), il caso SAFTCheck si riduce a tre lezioni trasferibili:
- L'elaborazione lato client oggi è un'opzione realistica. WebAssembly permette calcoli seri direttamente nel browser. Se i dati non devono lasciare l'utente, ormai non hanno più bisogno di farlo.
- Non tutto ha bisogno di una piattaforma. Un sito statico con un frontend intelligente può reggere un prodotto completo: più veloce, più economico e più sicuro dell'equivalente SaaS, quando i calcoli si fanno in locale.
- Togli le barriere al primo utilizzo. Registrazione, caricamento e prezzo sono tre porte che l'utente deve attraversare prima di vedere un valore. Ogni porta chiusa ti costa utenti che non saprai mai di aver perso.
Non tutti i prodotti possono (o devono) stare interamente nel browser. Ma la domanda “questa elaborazione può avvenire sul client?” merita di essere posta all'inizio di ogni progetto con dati sensibili. Se la risposta è “sì”, ottieni un'architettura in cui la fiducia non si costruisce con le parole: è integrata. E se cerchi un partner che si ponga questa domanda insieme a te, sai dove trovarci.
