Un paiement par carte parvient à votre comptabilité via un relevé de l'acquéreur qui mentionne déjà la commande. Un virement en USDC vous parvient avec une adresse, un montant et un hash de transaction, et rien d'autre. Le rapprochement des paiements en cryptomonnaies fonctionne lorsque la facture porte la référence de l'entreprise, car le virement ne peut pas la porter.
Ce guide s'adresse aux équipes finance et opérations des marchands, PSP et EMI qui acceptent des stablecoins et règlent en euros. Il énumère les champs que doit contenir chaque enregistrement de facture, explique comment traiter les paiements partiels et les paiements dans une mauvaise devise, comment les webhooks et l'API alimentent le grand livre, et quelles règles de l'UE déterminent la durée de conservation de l'ensemble.
Moments clés
En bref
- Un transfert ERC-20 ne contient que l'expéditeur, le destinataire et le montant. La référence de commande doit figurer sur la facture, pas dans le paiement.
- Facturez en EUR et comptabilisez ce montant en euros. Le montant en cryptomonnaie est un chiffre dérivé que vous conservez pour la piste d'audit.
- L'essentiel du travail porte sur les exceptions : paiements partiels, factures expirées, mauvaise devise. Examinez-les chaque jour, pas en fin de mois.
- Utilisez le webhook comme déclencheur, relisez la facture par son ID comme référence, et extrayez la liste des factures chaque nuit comme filet de sécurité et source de votre export CSV.
Pourquoi le rapprochement des paiements en cryptomonnaies est-il plus difficile que celui des cartes ?#
Le rapprochement des paiements en cryptomonnaies est plus difficile parce qu'un virement sur blockchain ne possède aucun champ pour votre numéro de commande. Sur Ethereum, la norme de jeton ERC-20 (EIP-20) définit l'événement de transfert comme `Transfer(address _from, address _to, uint256 _value)` : qui envoie, qui reçoit, combien. Il n'y a ni mémo, ni numéro de facture, ni nom du client.
Les paiements bancaires et par carte fonctionnent à l'inverse. Un virement SEPA comporte un champ de référence que le payeur renseigne, et le relevé de règlement d'un acquéreur liste chaque transaction par carte en face de votre référence marchand. Votre système comptable effectue la correspondance sur cette référence.
Avec les stablecoins, trois autres éléments compliquent la tâche :
- Le montant est rarement rond. Une facture de 250 EUR libellée en USDC devient un chiffre tel que 279,2846 USDC, de sorte que deux factures de taille similaire peuvent se ressembler.
- Le paiement n'est pas définitif immédiatement. Ethereum produit un bloc toutes les 12 secondes, mais selon ethereum.org (page mise à jour en octobre 2026), « il faut environ 15 minutes pour qu'un bloc Ethereum soit finalisé ». Un transfert peut être visible sans encore compter.
- Les payeurs commettent des erreurs. Ils envoient un montant insuffisant, envoient deux fois, envoient une autre devise ou paient après l'expiration de la facture.
Le lien doit donc exister avant que le payeur ne paie : une facture par commande, portant votre identifiant de commande et sa propre adresse de paiement, afin que chaque virement entrant se rattache à un enregistrement qui sait déjà à quoi il correspond.
Quels champs chaque enregistrement de facture en cryptomonnaie doit-il contenir ?#
Chaque facture doit contenir un ensemble fixe de champs qui relient quatre éléments : votre commande, le prix en euros, le transfert on-chain et le statut final. Si l'un manque, quelqu'un finit par faire la correspondance à la main. Le tableau ci-dessous reprend les noms de champs de l'API de facturation d'ItisPay ; d'autres prestataires utilisent des noms différents pour les mêmes notions.
| Champ | Contenu | Pourquoi la comptabilité en a besoin |
|---|---|---|
| invoice_id | Identifiant unique attribué par le prestataire | Clé primaire de chaque recherche et de chaque ligne du grand livre |
| order_id | Numéro de votre commande ou de votre contrat, unique par commande | Le lien avec votre ERP, boutique ou CRM ; la référence que les cartes vous fournissent gratuitement |
| order_name | Brève description de la commande | Permet à une personne de vérifier une exception sans ouvrir la boutique |
| fiat_amount, fiat_currency | Prix en EUR | Le chiffre d'affaires que vous comptabilisez |
| currency, crypto_amount | Devise facturée et montant dû | Indique ce que le payeur devait envoyer |
| actual_crypto_amount_paid | Montant effectivement reçu | Détecte les paiements insuffisants et excédentaires |
| currency_paid | Devise utilisée, si différente de celle facturée | Signale les paiements dans une mauvaise devise pour examen |
| network, address | Réseau blockchain et adresse de paiement | Prouve où les fonds ont été envoyés ; nécessaire pour tout suivi ou remboursement |
| transactions (tx_hash, amount, status) | Une ligne par virement entrant | Une facture peut recevoir plusieurs virements ; chaque hash constitue votre preuve on-chain |
| status | new, pending, completed, expired, cancelled, paid_partial | Détermine si vous comptabilisez, expédiez, relancez ou clôturez |
| created_at, updated_at, expires_at | Horodatages | Arrêté en fin de mois et preuve de la date de paiement de la commande |
Deux de ces champs font l'essentiel du travail. `order_id` est la référence qu'un virement sur blockchain ne peut pas porter : définissez-la depuis votre propre système et rendez-la unique par commande, jamais par client. La liste `transactions` est importante, car une facture n'est pas toujours payée en une seule fois : chaque virement obtient sa propre ligne avec un hash et un statut, afin que vous voyiez quels virements composent le montant payé.
Conservez le montant en cryptomonnaie avec toutes ses décimales dans une colonne séparée. Votre grand livre général fonctionne en centimes d'euro ; les colonnes crypto sont des justificatifs, non des valeurs comptables.
Quel montant en euros doit être comptabilisé ?#
Comptabilisez le prix en euros figurant sur la facture. Lorsque la facture est émise en EUR, le prestataire la convertit en montant en cryptoactifs au taux en vigueur, et le payeur envoie ce montant. Si le paiement est réglé en euros sur votre compte, le montant en euros figurant sur la facture constitue votre chiffre d'affaires, et le montant en cryptoactifs n'est qu'un détail technique de la façon dont le paiement est arrivé.
C'est la principale raison pour laquelle les équipes qui acceptent automatiquement des paiements en cryptoactifs avec conversion en EUR ont rarement besoin d'une comptabilité des cryptoactifs : aucun jeton ne figure au bilan à évaluer en fin de mois.
La situation change si vous conservez des stablecoins. En juin 2019, le Comité d'interprétation des IFRS a décidé que les détentions de cryptomonnaies relèvent de l'IAS 2 (stocks) lorsqu'elles sont détenues en vue de la vente dans le cours normal de l'activité, et de l'IAS 38 (immobilisations incorporelles) dans le cas contraire. Sa définition d'une cryptomonnaie exclut les actifs qui créent un contrat entre le détenteur et une autre partie. L'USDC est différent : Circle indique qu'il est « remboursable 1:1 en dollars américains » et, depuis juillet 2024, Circle émet l'USDC et l'EURC dans l'UE en tant que jetons de monnaie électronique, au titre d'un agrément de monnaie électronique délivré par l'autorité française ACPR. La manière de classer un stablecoin détenu relève de votre commissaire aux comptes. Un règlement en EUR dès réception permet d'éviter cette question.
Comment gérez-vous les paiements partiels et les mauvaises devises ?#
Traitez chaque facture qui n'est pas `completed` comme une exception dotée d'un responsable et d'une échéance. La majeure partie des efforts de rapprochement des paiements en cryptoactifs se concentre ici ; une facture entièrement payée se rapproche d'elle-même.
Voici ce que signifie chaque statut pour la finance, selon les statuts ItisPay :
| Statut | Ce qui s'est passé | Ce que fait la finance | Expédier ou libérer ? |
|---|---|---|---|
| new | Facture ouverte, rien reçu | Rien à comptabiliser | Non |
| pending | Un transfert est constaté, pas encore définitif | Attendre que le statut évolue | Non |
| completed | Payée intégralement | Comptabiliser le chiffre d'affaires au prix en EUR, libérer la commande | Oui |
| paid_partial | Une partie du montant est arrivée | Réclamer le solde, rembourser, ou clôturer d'un commun accord | Dépend |
| expired | Le délai est écoulé sans paiement intégral | Clôturer la commande ; vérifier les transferts tardifs | Non |
| cancelled | Vous avez annulé la facture | Aucune écriture ; réémettre si le client souhaite toujours payer | Non |
Paiements partiels#
Un paiement partiel signifie généralement que le portefeuille ou la plateforme d'échange du payeur a prélevé des frais sur le montant, ou que le payeur s'est trompé en le saisissant. ItisPay enregistre chaque transfert séparément, de sorte qu'un second transfert peut compléter la facture. La facture dispose également d'un paramètre `allowed_error_percent` : une petite tolérance, définie par facture, qui fait qu'un paiement inférieur de quelques fractions reste considéré comme payé. Fixez-le une fois pour toutes comme règle, par exemple à un niveau que vous passeriez aussi en pertes pour un virement bancaire, et ne le modifiez pas au cas par cas.
Si le solde n'arrive jamais, décidez dans un délai fixe de jours : acceptez l'écart et passez-le en pertes, remboursez ce qui a été reçu, ou annulez la commande. Consignez la décision sur l'enregistrement de la facture afin que le commissaire aux comptes comprenne pourquoi une commande payée est adossée à moins d'argent.
Mauvaise devise ou paiement tardif#
Lorsqu'un payeur envoie un stablecoin différent de celui qui a été facturé, le champ `currency_paid` l'indique. Ne le comptabilisez pas automatiquement : vérifiez le montant et la valeur en euros, puis acceptez-le ou remboursez-le. Un transfert vers une facture expirée est similaire. Les fonds sont sur la blockchain, mais votre commande est close, et quelqu'un doit décider s'il faut rouvrir la commande ou restituer les fonds. Si une commande est annulée de votre côté, annulez la facture via l'API (mise à jour du statut) afin que vos registres la montrent comme close avant l'arrivée de tout paiement tardif.
Comment les webhooks et l'API doivent-ils alimenter le rapprochement des paiements en cryptoactifs ?#
Utilisez trois niveaux : le webhook vous indique qu'un élément a changé, une relecture à jour de la facture vous indique ce qui est vrai, et une extraction nocturne de toutes les factures capte tout ce que les deux premiers ont manqué.
- Chaque facture peut porter un `callback_url` ; le prestataire y envoie les mises à jour de statut. Traitez le message comme un déclencheur, et non comme une preuve.
- À chaque webhook, appelez `GET /invoices/{invoice_id}` et agissez selon le statut et les montants de cette réponse. Cela vous protège contre les appels falsifiés ou rejoués vers votre point d'accès, puisque l'appel à l'API nécessite votre clé API.
- Rendez le gestionnaire idempotent : le même statut peut arriver deux fois. Indexez votre écriture de registre sur `invoice_id` et le statut, de sorte qu'une répétition ne change rien.
- Chaque nuit, listez les factures triées par `updated_at`, les plus récentes en premier, et remontez jusqu'à votre dernière exécution ; revérifiez aussi chaque facture encore `new`, `pending` ou `paid_partial`. Comparez-les à votre registre. Toute facture payée dans les registres du prestataire mais encore ouverte chez vous constitue une exception.
Pour les tests, ItisPay propose un point d'accès qui simule un changement de statut d'une facture, et un autre qui renvoie le dernier webhook par `invoice_id` ou `order_id`. Utilisez ce renvoi lorsque votre serveur était indisponible. Les équipes qui acheminent plusieurs moyens de paiement via une couche d'orchestration des paiements appliquent le même schéma à chaque canal.
Comment construire un export CSV pour la comptabilité ?#
Construisez l'export à partir de l'API de liste des factures, avec une ligne par facture et une ligne par transfert. Dans ItisPay, `GET /invoices` filtre par statut, crypto-actif et date de création, trie par date ou par montant, et renvoie jusqu'à 100 factures par page avec le nombre de pages. Un petit script peut parcourir les pages d'un jour ou d'un mois et écrire les colonnes à partir du tableau des champs ci-dessus.
Deux fichiers fonctionnent mieux qu'un seul :
- `invoices.csv` : invoice_id, order_id, fiat_amount, fiat_currency, currency, crypto_amount, actual_crypto_amount_paid, status, created_at, updated_at. C'est le fichier que le comptable importe et rapproche des ventes.
- `transfers.csv` : invoice_id, tx_hash, amount, currency, transfer status, time. C'est le fichier de preuves destiné à l'auditeur.
Importez le fichier des factures dans votre outil comptable comme vous le feriez pour un rapport de règlement par carte : une ligne par commande, en euros, avec l'identifiant de commande comme clé de rapprochement.
Quelles règles européennes encadrent les justificatifs de paiement en crypto-actifs ?#
Trois règles européennes posent le cadre. Aucune ne fait d'un marchand un prestataire de services sur crypto-actifs (CASP), mais elles déterminent les données qui existent et la durée pendant laquelle elles sont conservées.
- Règlement sur les transferts de fonds (UE) 2023/1113. Depuis le 30 décembre 2024, le CASP du payeur doit s'assurer que chaque transfert est accompagné d'informations sur le payeur et le bénéficiaire, comme les noms et les adresses sur registre distribué (article 14). Ces données voyagent avec le transfert, et non à l'intérieur de celui-ci. Pour les transferts supérieurs à 1 000 EUR à destination ou en provenance d'un portefeuille auto-hébergé, le prestataire de la partie concernée doit évaluer si ce portefeuille appartient à son propre client (articles 14 et 16). C'est le rôle du prestataire agréé, et c'est l'une des raisons pour lesquelles un paiement peut être mis en attente d'examen.
- Conservation des données. En vertu de la directive AML actuelle (UE) 2015/849, article 40, les entités assujetties conservent les enregistrements de transactions pendant cinq ans après la fin de la relation d'affaires ou la date de la transaction. Le nouveau règlement AML (UE) 2024/1624 maintient la période de cinq ans (article 77) et s'applique à partir du 10 juillet 2027.
- DAC8, directive (UE) 2023/2226. À partir du 1er janvier 2026, les CASP déclarent aux autorités fiscales les transactions en crypto-actifs de leurs utilisateurs. Vos propres registres doivent concorder avec ce que déclare votre prestataire.
Si vous passez par un partenaire agréé, c'est lui qui assume les obligations CASP au titre de MiCA et de ces règles, comme l'explique notre guide sur la licence CASP MiCA. Vous conservez malgré tout vos registres de commandes et votre part de la piste d'audit.
Où la réconciliation des paiements en crypto-actifs nécessite-t-elle encore une intervention humaine ?#
L'automatisation gère le cas du paiement intégral. Le reste demande un responsable désigné et une courte politique écrite.
Où cela n'aide pas
- Les remboursements sont de nouveaux transferts sortants, et non des annulations. Ils nécessitent un versement vers une adresse ou un IBAN, ainsi que leurs propres registres.
- Un payeur qui envoie depuis un compte d'échange ne peut pas toujours être identifié par l'adresse d'envoi. Rapprochez toujours sur la facture, jamais sur l'expéditeur.
- Les paiements vers une facture expirée, les paiements en double et les mauvais crypto-actifs nécessitent tous une décision humaine.
- Les frais de réseau et les arrondis créent de petits écarts. Fixez une tolérance une fois pour toutes et tenez-vous-y.
Une routine quotidienne de réconciliation des paiements en crypto-actifs en cinq étapes#
Une courte routine quotidienne rend la clôture de fin de mois presque une formalité :
- Récupérez via l'API les factures créées ou mises à jour depuis la dernière exécution, puis mettez à jour les fichiers de factures et de transferts.
- Vérifiez que chaque facture `completed` correspond à une commande payée dans votre boutique ou votre ERP, et inversement.
- Traitez la liste des exceptions : `paid_partial`, paiements vers des factures expirées, mauvais crypto-actifs. Clôturez chaque cas par une décision écrite.
- Rapprochez le règlement en euros sur votre compte bancaire du total des factures complétées pour la période. Le règlement vers un IBAN est l'étape où les IBAN virtuels aident à séparer les flux par ligne d'activité.
- Archivez les deux fichiers pendant au moins cinq ans.
Si vous souhaitez accepter des stablecoins et recevoir des euros sans construire cette infrastructure vous-même, ItisPay fournit l'API, la facturation et les données de réconciliation : identifiants de facture et de commande, hachages de transfert par transaction, statuts et webhooks. L'agrément, le KYC et le règlement vers votre IBAN passent par notre partenaire CASP + établissement de paiement agréé dans l'UE, et la plupart des équipes passent du KYB à la première transaction en moins d'une semaine.
Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil juridique ou réglementaire.
