Un pagamento con carta arriva nella contabilità attraverso un report dell'acquirer che già indica l'ordine. Un trasferimento in USDC arriva con un indirizzo, un importo e un hash di transazione, e nient'altro. La riconciliazione dei pagamenti in criptovalute funziona quando la fattura riporta il riferimento aziendale, perché il trasferimento non può farlo.
Questa guida è rivolta ai team finanziari e operativi di merchant, PSP ed EMI che accettano stablecoin e regolano in euro. Elenca i campi che ogni record di fattura richiede, come gestire i pagamenti parziali e quelli in una moneta sbagliata, come webhook e API alimentano il registro contabile, e quali norme UE stabiliscono per quanto tempo conservare il tutto.
Momenti chiave
In breve
- Un trasferimento ERC-20 contiene solo mittente, destinatario e importo. Il riferimento dell'ordine deve risiedere nella fattura, non nel pagamento.
- Prezzare la fattura in EUR e registrare quell'importo in euro. L'importo in criptovaluta è un dato derivato che si conserva per la traccia di audit.
- La maggior parte del lavoro riguarda le eccezioni: pagamenti parziali, fatture scadute, la moneta sbagliata. Vanno verificate ogni giorno, non a fine mese.
- Usa il webhook come trigger, rileggi la fattura tramite ID come fonte di verità e scarica ogni notte l'elenco delle fatture come rete di sicurezza e come fonte della tua esportazione CSV.
Perché la riconciliazione dei pagamenti in criptovalute è più difficile di quella con le carte?#
La riconciliazione dei pagamenti in criptovalute è più difficile perché un trasferimento su blockchain non ha un campo per il numero del tuo ordine. Su Ethereum, lo standard di token ERC-20 (EIP-20) definisce l'evento di trasferimento come `Transfer(address _from, address _to, uint256 _value)`: chi ha inviato, chi ha ricevuto, quanto. Non esistono memo, numero di fattura o nome del cliente.
I pagamenti bancari e con carta sono costruiti in modo opposto. Un bonifico SEPA ha un campo causale che il pagatore compila, e il report di regolamento dell'acquirer elenca ogni transazione con carta in base al riferimento del merchant. Il tuo sistema contabile effettua l'abbinamento su quel riferimento.
Con le stablecoin, altri tre fattori creano ostacoli:
- L'importo raramente è tondo. Una fattura di 250 EUR prezzata in USDC diventa una cifra come 279,2846 USDC, quindi due fatture di dimensioni simili possono sembrare identiche.
- Il pagamento non è definitivo subito. Ethereum produce un blocco ogni 12 secondi, ma secondo ethereum.org (pagina aggiornata a ottobre 2026) «ci vogliono circa 15 minuti perché un blocco di Ethereum venga finalizzato». Un trasferimento può essere visibile e non essere ancora valido.
- I pagatori commettono errori. Inviano un importo insufficiente, inviano due volte, inviano una moneta diversa o pagano dopo la scadenza della fattura.
Quindi il collegamento deve esistere prima che il pagatore paghi: una fattura per ordine, con il tuo ID ordine e un proprio indirizzo di pagamento, in modo che ogni trasferimento in entrata finisca su un record che già sa a cosa si riferisce.
Quali campi deve contenere il record di ogni fattura in criptovalute?#
Ogni fattura richiede un insieme fisso di campi che collegano quattro elementi: l'ordine, il prezzo in euro, il trasferimento on-chain e lo stato finale. Se ne manca uno, qualcuno finisce per abbinare i dati a mano. La tabella seguente usa i nomi dei campi dell'API delle fatture di ItisPay; altri provider usano nomi diversi per le stesse informazioni.
| Campo | Contenuto | Perché serve alla contabilità |
|---|---|---|
| invoice_id | ID univoco assegnato dal provider | Chiave primaria per ogni ricerca e ogni riga del registro |
| order_id | Numero del tuo ordine o contratto, univoco per ordine | Il collegamento al tuo ERP, shop o CRM; il riferimento che le carte ti danno gratuitamente |
| order_name | Breve descrizione dell'ordine | Permette a una persona di verificare un'eccezione senza aprire lo shop |
| fiat_amount, fiat_currency | Prezzo in EUR | Il dato di ricavo che registri |
| currency, crypto_amount | Moneta fatturata e importo dovuto | Mostra cosa è stato chiesto al pagatore di inviare |
| actual_crypto_amount_paid | Quanto è effettivamente arrivato | Rileva pagamenti insufficienti ed eccedenti |
| currency_paid | Moneta usata, se diversa da quella fatturata | Segnala per verifica i pagamenti in una moneta sbagliata |
| network, address | Rete blockchain e indirizzo di pagamento | Dimostra dove è stato inviato il denaro; necessario per qualsiasi tracciamento o rimborso |
| transactions (tx_hash, amount, status) | Una riga per ogni trasferimento in entrata | Una fattura può ricevere più trasferimenti; ogni hash è la tua prova on-chain |
| status | new, pending, completed, expired, cancelled, paid_partial | Decide se registrare, spedire, sollecitare o chiudere |
| created_at, updated_at, expires_at | Marcature temporali | Limite di chiusura a fine mese e prova di quando l'ordine è stato pagato |
Due di questi campi svolgono gran parte del lavoro. `order_id` è il riferimento che un trasferimento su blockchain non può trasportare, quindi impostalo dal tuo sistema e rendilo univoco per ordine, mai per cliente. La lista `transactions` è importante perché una fattura non sempre viene pagata in un'unica soluzione: ogni trasferimento ha la propria riga con un hash e uno stato, così puoi vedere quali trasferimenti compongono l'importo pagato.
Conserva l'importo in criptovaluta con tutte le sue cifre decimali in una colonna separata. Il tuo libro mastro lavora in centesimi di euro; le colonne crypto sono prove, non valori contabili.
Quale importo in euro va registrato a bilancio?#
Registra a bilancio il prezzo in euro indicato in fattura. Quando la fattura è emessa in EUR, il provider converte l'importo in una cifra in criptovaluta al tasso corrente, e il pagatore invia tale importo. Se il pagamento viene regolato in euro sul tuo conto, la cifra in euro in fattura è il tuo ricavo, mentre l'importo in criptovaluta è un dettaglio tecnico di come il pagamento è arrivato.
Questo è il motivo principale per cui i team che accettano pagamenti in criptovaluta automaticamente con conversione in EUR raramente hanno bisogno di una contabilità delle criptovalute: non c'è alcuna moneta nel bilancio da valutare a fine mese.
Le cose cambiano se si detengono le stablecoin. L'IFRS Interpretations Committee ha stabilito nel giugno 2019 che le detenzioni di criptovalute rientrano nello IAS 2 (rimanenze) quando sono detenute per la vendita nel normale corso dell'attività, e nello IAS 38 (attività immateriali) negli altri casi. La sua definizione di criptovaluta esclude le attività che creano un contratto tra il detentore e un'altra parte. USDC è diverso: Circle dichiara che è «rimborsabile 1:1 in dollari statunitensi» e, dal luglio 2024, Circle emette USDC ed EURC nell'UE come token di moneta elettronica, in base a una licenza di moneta elettronica rilasciata dall'autorità di vigilanza francese ACPR. Come classificare una stablecoin detenuta è una questione da discutere con il revisore. Regolare in EUR al momento della ricezione evita il problema.
Come gestire pagamenti parziali e monete sbagliate?#
Tratta ogni fattura che non è `completed` come un'eccezione con un responsabile e una scadenza. Gran parte dello sforzo di riconciliazione dei pagamenti in criptovaluta si concentra qui; una fattura pagata integralmente si riconcilia da sola.
Ecco cosa significa ogni stato per la finanza, usando gli stati di ItisPay:
| Stato | Cosa è successo | Cosa fa la finanza | Spedire o rilasciare? |
|---|---|---|---|
| new | Fattura aperta, nulla ricevuto | Nulla da registrare | No |
| pending | Un trasferimento è visibile, non ancora definitivo | Attendere il cambio di stato | No |
| completed | Pagato integralmente | Registrare il ricavo al prezzo in EUR, rilasciare l'ordine | Sì |
| paid_partial | È arrivata una parte dell'importo | Chiedere il saldo, rimborsare o chiudere di comune accordo | Dipende |
| expired | Il tempo è scaduto senza pagamento integrale | Chiudere l'ordine; verificare eventuali trasferimenti tardivi | No |
| cancelled | Hai annullato la fattura | Nessuna registrazione; riemettere se il cliente vuole ancora pagare | No |
Pagamenti parziali#
Un pagamento parziale di solito significa che il wallet o l'exchange del pagatore ha trattenuto una commissione sull'importo, oppure che il pagatore ha digitato l'importo in modo errato. ItisPay registra ogni trasferimento separatamente, quindi un secondo trasferimento può completare la fattura. La fattura ha anche un'impostazione `allowed_error_percent`: una piccola tolleranza, definita per ogni fattura, in modo che un pagamento leggermente inferiore risulti comunque pagato. Impostala una volta come policy, ad esempio a un livello che accetteresti di stornare anche su un bonifico bancario, e non modificarla caso per caso.
Se il saldo non arriva mai, decidi entro un numero fisso di giorni: accetta la differenza e stornala, rimborsa quanto ricevuto, oppure annulla l'ordine. Annota la decisione nella scheda della fattura, così il revisore vede perché un ordine pagato ha dietro meno denaro.
Moneta sbagliata o pagamento tardivo#
Quando un pagatore invia una stablecoin diversa da quella fatturata, il campo `currency_paid` lo indica. Non registrarlo automaticamente: verifica l'importo e il valore in euro, poi accettalo o rimborsalo. Un trasferimento su una fattura scaduta è simile. Il denaro è on-chain, ma il tuo ordine è chiuso, quindi qualcuno deve decidere se riaprire l'ordine o restituire i fondi. Se un ordine viene annullato da parte tua, annulla la fattura tramite API (un aggiornamento di stato), così i tuoi registri la mostrano come chiusa prima che arrivi un eventuale pagamento tardivo.
Come devono alimentare la riconciliazione i webhook e l'API?#
Usa tre livelli: il webhook ti segnala che qualcosa è cambiato, una lettura aggiornata della fattura ti dice qual è la situazione reale, e un'estrazione notturna di tutte le fatture intercetta quanto sfuggito ai primi due.
- Ogni fattura può includere un `callback_url`; il provider invia lì gli aggiornamenti di stato. Considera il messaggio un trigger, non una prova.
- A ogni webhook, chiama `GET /invoices/{invoice_id}` e agisci in base allo stato e agli importi contenuti in quella risposta. Questo ti protegge da chiamate falsificate o riprodotte verso il tuo endpoint, dato che la chiamata API richiede la tua chiave API.
- Rendi il gestore idempotente: lo stesso stato può arrivare due volte. Associa la registrazione contabile a `invoice_id` più lo stato, così una ripetizione non modifica nulla.
- Ogni notte, elenca le fatture ordinate per `updated_at`, dalla più recente, e scorri fino alla tua ultima esecuzione; ricontrolla anche ogni fattura ancora `new`, `pending` o `paid_partial`. Confrontale con i tuoi registri. Qualsiasi fattura pagata nei registri del provider ma aperta nei tuoi è un'eccezione.
Per i test, ItisPay dispone di un endpoint che simula un cambio di stato per una fattura, e di uno che rinvia l'ultimo webhook tramite `invoice_id` o `order_id`. Usa il reinvio quando il tuo server era non disponibile. I team che instradano più metodi di pagamento attraverso un unico livello di orchestrazione dei pagamenti applicano lo stesso schema a ogni canale.
Come si costruisce un export CSV per la contabilità?#
Costruisci l'export a partire dall'API dell'elenco delle fatture, con una riga per fattura e una riga per ogni trasferimento. In ItisPay, `GET /invoices` filtra per stato, moneta e data di creazione, ordina per data o importo e restituisce fino a 100 fatture per pagina insieme al numero di pagine. Un piccolo script può scorrere le pagine di un giorno o di un mese e scrivere le colonne seguendo la tabella dei campi sopra.
Due file funzionano meglio di uno:
- `invoices.csv`: invoice_id, order_id, fiat_amount, fiat_currency, currency, crypto_amount, actual_crypto_amount_paid, status, created_at, updated_at. È il file che il contabile importa e abbina alle vendite.
- `transfers.csv`: invoice_id, tx_hash, amount, currency, transfer status, time. È il file di prova per il revisore.
Importa il file delle fatture nello strumento contabile come faresti con un report di regolamento delle carte: una riga per ordine, in euro, con l'ID ordine come chiave di abbinamento.
Quali norme UE regolano le registrazioni dei pagamenti in cripto-attività?#
Tre norme UE definiscono il contesto. Nessuna di esse fa di un esercente un prestatore di servizi per le cripto-attività (CASP), ma stabiliscono quali dati esistono e per quanto tempo vanno conservati.
- Regolamento sul trasferimento di fondi (UE) 2023/1113. Dal 30 dicembre 2024, il CASP del pagatore deve assicurarsi che ogni trasferimento sia accompagnato da informazioni sul pagatore e sul beneficiario, come nomi e indirizzi di registro (articolo 14). I dati viaggiano insieme al trasferimento, non al suo interno. Per i trasferimenti superiori a 1.000 EUR da o verso un portafoglio self-hosted, il prestatore sul lato interessato deve valutare se quel portafoglio appartiene al proprio cliente (articoli 14 e 16). Questo è compito del prestatore autorizzato, ed è uno dei motivi per cui un pagamento può restare in verifica.
- Conservazione delle registrazioni. Ai sensi dell'attuale direttiva AML (UE) 2015/849, articolo 40, i soggetti obbligati conservano le registrazioni delle operazioni per cinque anni dalla fine del rapporto d'affari o dalla data dell'operazione. Il nuovo regolamento AML (UE) 2024/1624 mantiene il periodo di cinque anni (articolo 77) e si applica dal 10 luglio 2027.
- DAC8, direttiva (UE) 2023/2226. Dal 1° gennaio 2026, i CASP comunicano alle autorità fiscali le operazioni in cripto-attività dei propri utenti. Le tue registrazioni dovrebbero corrispondere a quanto comunica il tuo prestatore.
Se lavori tramite un partner autorizzato, il partner si fa carico degli obblighi del CASP ai sensi del MiCA e di queste norme, come spiegato nella nostra guida alla licenza CASP MiCA. Tu conservi comunque le registrazioni degli ordini e la tua parte della traccia.
Dove la riconciliazione delle cripto-attività richiede ancora una persona?#
L'automazione gestisce il caso del pagamento integrale. Il resto richiede un responsabile designato e una breve policy scritta.
Dove non aiuta
- I rimborsi sono nuovi trasferimenti in uscita, non storni. Richiedono un pagamento verso un indirizzo o un IBAN, e registrazioni proprie.
- Un pagatore che invia da un conto presso un exchange non sempre può essere identificato dall'indirizzo mittente. Abbina sempre sulla fattura, mai sul mittente.
- I pagamenti a una fattura scaduta, i pagamenti duplicati e le monete sbagliate richiedono tutti una decisione umana.
- Le commissioni di rete e gli arrotondamenti producono piccole differenze. Stabilisci una volta per tutte una tolleranza e mantienila.
Una routine giornaliera di riconciliazione dei pagamenti in cripto-attività in cinque passaggi#
Una breve routine quotidiana rende la chiusura di fine mese una formalità:
- Recupera dall'API le fatture create o aggiornate dall'ultima esecuzione e aggiorna i file di fatture e trasferimenti.
- Verifica che ogni fattura `completed` abbia un ordine pagato corrispondente nel tuo shop o ERP, e viceversa.
- Lavora l'elenco delle eccezioni: `paid_partial`, pagamenti a fatture scadute, monete sbagliate. Chiudi ciascuna con una decisione scritta.
- Confronta il regolamento in euro sul tuo conto bancario con la somma delle fatture completate nel periodo. Il regolamento su un IBAN è il punto in cui gli IBAN virtuali aiutano a separare i flussi per linea di business.
- Archivia entrambi i file per almeno cinque anni.
Se vuoi accettare stablecoin e ricevere euro senza costruire tu stesso questa infrastruttura, ItisPay fornisce API, fatturazione e dati di riconciliazione: ID di fattura e ordine, hash per ogni trasferimento, stati e webhook. Licenze, KYC e regolamento sul tuo IBAN passano attraverso il nostro partner autorizzato nell'UE come CASP + istituto di pagamento, e la maggior parte dei team passa da KYB alla prima transazione in meno di una settimana.
Questo articolo è solo a scopo informativo e non costituisce consulenza legale o regolamentare.
