Stablecoins et Pennylane : relevé bancaire ou écritures ?

En bref

Avec le règlement ANC n° 2026-01, un wallet d'USDC ou d'EURC se tient comme une disponibilité (compte 513). Dans Pennylane, la représentation la plus proche est un compte bancaire : une transaction par transfert, datée, valorisée en euros, avec un libellé qui porte le hash de la transaction ; le comptable catégorise et rapproche comme pour un relevé. Les écritures de journal restent nécessaires pour ce qui n'est pas un flux : la réévaluation de clôture (écart de change) et, le cas échéant, l'écriture d'ouverture. Cinqtreize combine les deux.

Que permet l'API publique de Pennylane ?

D'après la documentation publique de l'API externe v2 (lue le 13 octobre 2026) :

• POST /api/external/v2/bank_accounts crée un compte bancaire (name, currency, account_type : checking, savings, card…). Il n'est pas rattaché à une banque réelle : c'est un compte de trésorerie que le cabinet affecte au compte comptable de son choix, par exemple 5131.
• POST /api/external/v2/transactions crée une transaction dans ce compte (bank_account_id, label, date, amount en chaîne, fee facultatif). Le schéma est fermé : pas de champ devise ni de référence externe. La référence unique doit donc tenir dans le libellé.
• POST /api/external/v2/ledger_entries crée une écriture de journal équilibrée (lignes débit/crédit par compte comptable), avec la portée ledger_entries:all.
• Le rapprochement d'une facture client et d'une transaction se fait par POST /customer_invoices/{id}/matched_transactions, ou automatiquement si la facture porte une transaction_reference contenue dans le libellé de la transaction.
• Aucune idempotence n'est garantie sur les créations : renvoyer la même requête crée un doublon. L'outil qui pousse les données doit tenir sa propre protection contre les doubles envois.

Ces points sont tirés de la documentation publique ; le comportement exact d'un compte en devise (currency: USD) et de l'import manuel d'un relevé n'ont pas été vérifiés en bac à sable.

Relevé ou écritures : quel choix pour quoi ?

Sans accès à l'API, la même logique vaut avec un relevé CSV importé à la main (Date;Libellé;Montant), puis une écriture de clôture saisie par le cabinet.

Comment garantir l'unicité de chaque ligne ?

Chaque transfert porte dans son libellé une référence ss:<chaîne>:<hash>:<empreinte> construite à partir du hash de la transaction et de sa position. Avant tout envoi, la ligne passe au statut « envoi en cours » ; après une coupure ou une réponse perdue, l'outil recherche la référence dans Pennylane avant de renvoyer quoi que ce soit. Un wallet relu, une synchro relancée ou un passage du CSV à l'API ne créent pas de doublon.

Que faut-il dans l'annexe ?

L'article 838-15 b) du PCG, modifié par le règlement, demande « le nombre et le montant des crypto-actifs et assimilés détenus […] en précisant les modalités de détermination de leur valeur vénale (plateformes / sources de données utilisées, horaire de valorisation…) ». Le compte bancaire Pennylane donne le montant ; l'outil conserve le nombre de jetons, la source du taux (BCE, série et date) et l'horaire de référence pour rédiger cette note. Rédaction à valider par l'expert-comptable.

Dans Cinqtreize

Les flux partent comme transactions bancaires (ou en CSV), la clôture comme brouillon d'écriture validé par le cabinet, et les rapprochements sont proposés avant d'être enregistrés. La méthode comptable décrit la piste d'audit ; l'outil gratuit montre, pour une adresse, ce que deviendrait le relevé.