La prima comunicazione DAC8 nei Paesi Bassi si prepara costruendo correttamente i dati su clienti e operazioni per tutto il 2026.
Durante una riunione del lunedì, il fondatore di un’impresa crypto apre tre schermate. La prima mostra i clienti verificati, la seconda i movimenti dei wallet, la terza la contabilità. Tutto sembra in ordine. Eppure gli identificativi dei clienti non coincidono, gli orari delle operazioni non sono allineati e la residenza fiscale è conservata in un sistema di onboarding separato.
È qui che l’obbligo DAC8 nei Paesi Bassi diventa concreto.
La legge olandese di recepimento è stata pubblicata il 10 aprile 2026 e si applica dal 1° gennaio 2026. La Belastingdienst richiede ai prestatori che rientrano nell’ambito della normativa di raccogliere i dati relativi ai clienti e alle operazioni per l’anno solare 2026. La prima comunicazione annuale dovrà essere presentata entro il 31 gennaio 2027.
L’anno oggetto di comunicazione è già in corso. Nel frattempo, l’infrastruttura tecnica ha continuato a evolversi attraverso specifiche, strumenti di test e aggiornamenti pubblicati nei mesi di luglio e agosto.
La scadenza è solo l’ultimo passaggio
DAC8 richiede molto più di una semplice esportazione delle operazioni dalla piattaforma. I dati da comunicare possono comprendere identità, indirizzo, residenza fiscale e codice di identificazione fiscale del cliente. Possono inoltre riguardare determinati scambi, trasferimenti e pagamenti.
Il prestatore deve collegare questi elementi al cliente e al Paese di comunicazione corretti. Entro il 31 gennaio successivo deve anche informare i clienti dei dati che ha trasmesso.
Prima di essere un problema di invio, è un problema di governance. La comunicazione annuale alla Belastingdienst è soltanto l’ultimo passaggio. Il vero lavoro consiste nelle centinaia di decisioni prese prima, in merito a clienti, wallet, giurisdizioni e tipologie di operazioni.
Torniamo alle tre schermate del fondatore. Un cliente può superare i controlli d’identità a gennaio, cambiare residenza a giugno e utilizzare più conti dopo la migrazione della piattaforma. Un sistema conserva il vecchio indirizzo. Un altro adotta un nuovo numero di conto. La contabilità raggruppa le operazioni in base alla data di regolamento, mentre il sistema di prodotto registra l’ora di esecuzione.
Ogni differenza può sembrare trascurabile. Nel loro insieme, però, queste discrepanze possono produrre una comunicazione incompleta o incoerente.
Anche i prestatori di minori dimensioni devono tenere sotto controllo i costi. La qualità della comunicazione richiede richieste integrative ai clienti, sviluppo software, test e tempo per risolvere le operazioni anomale. Correzioni manuali possono sembrare sostenibili con poche centinaia di clienti. Quando aumentano volumi, prodotti e giurisdizioni, diventano una questione di margini.
Lo status MiCA non basta a dare la risposta
Il registro dell’AFM identifica i prestatori di servizi crypto autorizzati o notificati nei Paesi Bassi e in altri Stati dell’Unione europea. È uno status rilevante. La posizione di un’impresa ai fini DAC8 dipende però anche dalle attività svolte, dal luogo di stabilimento e dai collegamenti che determinano gli obblighi di comunicazione.
È un tema che merita l’attenzione diretta dei fondatori. MiCA, adeguata verifica della clientela, controlli sulle sanzioni e comunicazioni fiscali possono utilizzare informazioni in parte sovrapponibili, ma ciascun sistema le impiega per uno scopo diverso. Quando reparti o fornitori distinti raccolgono gli stessi dati, la duplicazione può nascondere divergenze.
Una residenza fiscale inserita durante l’onboarding potrebbe non arrivare mai alla contabilità. Una classificazione del wallet effettuata dalla compliance potrebbe non comparire nel motore di reporting. Uno storno accettato dalle operations potrebbe risultare altrove come operazione completata.
La domanda utile per la direzione non è semplicemente: «Chi si occupa di DAC8?». È piuttosto: «Chi sa spiegare l’intero percorso, dall’accettazione del cliente fino al dato comunicato?». Una responsabilità condivisa può sembrare collaborativa, ma lasciare le eccezioni più difficili senza un responsabile.
Anche la tempistica aggiunge complessità. La legge si applica dal 1° gennaio, sebbene sia stata pubblicata ad aprile. Un prestatore che abbia atteso il testo olandese definitivo potrebbe ora dover riesaminare dati e decisioni dei primi mesi dell’anno. Ricostruire a posteriori richiede più tempo e produce evidenze meno solide rispetto alla risoluzione tempestiva delle lacune, quando il personale ricorda ancora l’accaduto.
Per le imprese ordinarie l’esposizione è diversa
La maggior parte delle piccole imprese olandesi non presta servizi crypto. Possedere crypto o accettarle in pagamento da un cliente non rende l’impresa responsabile della comunicazione annuale del prestatore. DAC8 modifica la comunicazione e lo scambio di informazioni, mentre il trattamento fiscale olandese delle crypto continua a dipendere dalle regole fiscali esistenti.
Immaginiamo che una BV di design emetta una fattura da 4.000 euro e accetti il pagamento in crypto. La società deve convertire il corrispettivo in euro ai fini dei ricavi e dell’IVA. Le successive variazioni di valore incidono sull’utile o sulla perdita. Le crypto ancora detenute alla data di chiusura del bilancio seguono il trattamento fiscale descritto dalla Belastingdienst.
La documentazione contabile dovrebbe collegare la fattura, la transazione sul wallet, la conversione in euro, la registrazione IVA e la successiva cessione o valutazione. Uno screenshot del saldo del wallet raramente ricostruisce l’intera operazione economica. Anche un file scaricato da un exchange dice poco se nessuno è in grado di collegarne gli identificativi a clienti, fatture e registrazioni contabili.
L’ampliamento degli obblighi di comunicazione cambierà il contesto operativo. Le autorità fiscali potranno utilizzare le informazioni ricevute per l’analisi del rischio. I dati DAC8 aggregati non compileranno automaticamente una dichiarazione fiscale, ma renderanno più facili da individuare le differenze tra le informazioni esterne sulle operazioni e la documentazione dell’impresa.
Torniamo alla riunione del lunedì. Il fondatore non ha bisogno dell’ennesima presentazione generale sulle policy. Serve una conversazione più mirata. Quali anagrafiche clienti sono prive del codice fiscale? Quali cambi di residenza non sono stati risolti? La contabilità riesce a riconciliare l’intera popolazione delle operazioni con il dataset da comunicare? Quale specifica tecnica utilizza il software? Chi approva le eccezioni?
Gennaio comincia ad agosto
La prima scadenza può sembrare lontana. In una piccola impresa, però, cinque mesi scompaiono rapidamente tra sviluppo del prodotto, problemi dei clienti, chiusura dei conti e ferie del personale. Iniziare i test a gennaio lascia poco spazio per correggere dati raccolti nei dodici mesi precedenti.
Una preparazione solida è discreta e ripetitiva. I team confrontano gli identificativi dei clienti nei diversi sistemi. Recuperano le informazioni mancanti sulla residenza fiscale. Attribuiscono responsabilità chiare per la classificazione dei wallet e delle operazioni. Storni e migrazioni restano visibili. Le modifiche tecniche vengono datate, testate e comprese prima di entrare in produzione.
Per una BV che utilizza le crypto soltanto come attività patrimoniale o mezzo di pagamento, lo stesso principio vale su scala minore. Una riconciliazione mensile costa meno della ricostruzione di un anno di movimenti dei wallet al momento della dichiarazione fiscale.
DAC8 porta una quantità maggiore di informazioni sulle crypto nel sistema formale di scambio fiscale. Il suo effetto più profondo è più semplice: riduce la distanza tra wallet, anagrafica del cliente e contabilità. Le imprese che colmano quella distanza adesso arriveranno a gennaio con meno spiegazioni da ricostruire e più fatti già documentati.
Se il percorso verso la prima comunicazione DAC8 presenta ancora lacune, questo è il momento di chiarire dati, controlli e responsabilità.
I dati, le fonti e l’analisi di questo articolo sono stati curati da Linda Pavan Geraedts. L’IA non è stata usata per individuare le fonti, costruire la base fattuale o produrre il giudizio analitico. L’IA è stata usata solo come aiuto di redazione. Il testo italiano finale è stato rivisto, corretto e approvato personalmente da Linda Pavan Geraedts prima della pubblicazione.
Riferimenti
- Documenten openbaar over voorbereiding Belastingdienst op nieuwe regels voor digitale gegevensuitwisseling - Taxence
- Wettenbank - National legal implementation and effective date
- Belastingdienst - Who reports, what data is collected and first filing deadline
- Belastingdienst, Ondersteuning Digitaal Berichtenverkeer - Technical delivery remains an active implementation project
- Belastingdienst, Ondersteuning Digitaal Berichtenverkeer - Recent technical releases and reporting documentation
- Autoriteit Financiële Markten - MiCA authorisation, supervision and overlap with financial-crime controls
- Belastingdienst - Tax position of crypto users and businesses that hold or receive crypto
- Belastingdienst, Ondersteuning Digitaal Berichtenverkeer - CARF/DAC8 release notes
