Flux de comptabilisation pour les places de marché avec Stripe Connect

Q: Contre quel rapport Stripe dois-je effectuer le rapprochement ?

Le rapport de rapprochement des virements, détaillé (Payout reconciliation, itemized), car il fournit une ligne par transaction de solde dotée d'une reportingcategory, d'un automaticpayoutid, ainsi que des montants bruts, de frais et nets. Un résumé des virements du tableau de bord ne prouve que le total du lot. Lorsque les virements automatiques ne sont pas activés, utilisez plutôt le rapport de solde (Balance report).

Q: Comment sont traités les remboursements réglés dans un virement ultérieur ?

Ils arrivent sous la forme d'une ligne refund dans le rapport détaillé du virement ultérieur et sont rapprochés de l'encaissement d'origine par le biais du chargeid de l'encaissement initialement rapproché. Un remboursement synthétisé à partir d'un export de paiements au niveau des encaissements n'est dans ce cas qu'une approximation, ce qui fait du rapport détaillé la source la plus sûre.

Guide pratique de l'expert-comptable pour comptabiliser les encaissements, frais, transferts, remboursements, litiges et réserves dans un grand livre de place de marché qui se rapproche parfaitement.

La plupart des problèmes comptables sur les places de marché proviennent d'une seule et même erreur : traiter le virement bancaire Stripe comme s'il s'agissait d'un chiffre d'affaires. Le virement est le solde net de dizaines d'événements économiques distincts, et le comptabiliser sur une seule ligne de produits efface la commission de la plateforme, la dette envers le vendeur, ainsi que tous les frais et litiges qui y sont enfouis. Un flux de travail correct décompose le virement avant qu'il n'atteigne le grand livre.

Ce guide associe chaque catégorie de transaction de solde Stripe à son imputation comptable adéquate : créances, commissions sur ventes, dettes envers les vendeurs, frais de traitement et comptes d'attente. Il utilise les points de terminaison d'importation et de règlement documentés de Nordlet comme mécanisme de comptabilisation, fournit un exemple de règlement chiffré et se termine par une liste de contrôle de rapprochement à exécuter avant chaque clôture.

Identifier le modèle de frais Connect avant de concevoir quoi que ce soit

Aucune règle comptable ne peut être établie tant que vous ignorez quel modèle de frais chaque flux de paiement utilise. Ce modèle détermine quel solde Stripe supporte la charge, qui prend les frais à sa charge et où les remboursements et litiges s'imputent en premier.

Modèle Connect	Frais créés sur	Supporte les frais Stripe	Les remboursements/litiges réduisent	Conséquence comptable
Frais directs (Direct charges)	Compte connecté	Paramétrable par partie	Le solde du compte connecté	La plateforme enregistre ses frais d'application en tant que produits ; l'activité de paiement du vendeur réside principalement dans le grand livre du compte connecté
Frais de destination (Destination charges)	Plateforme, avec transfert immédiat vers un compte connecté	Plateforme	Plateforme	La plateforme enregistre la créance client et les frais Stripe ; la part du vendeur constitue un passif (dette), non un chiffre d'affaires
Frais et transferts séparés (Separate charges and transfers)	Encaissement par la plateforme, puis un ou plusieurs transferts distincts	Plateforme	Plateforme	L'encaissement et les transferts aux vendeurs sont des événements distincts ; la dette envers le vendeur est suivie indépendamment de l'encaissement client

Les recommandations officielles de Stripe sur le fonctionnement des frais dans une intégration Connect confirment que pour les frais de destination et les frais et transferts séparés, le solde de la plateforme supporte les frais de paiement, les remboursements et les refacturations (chargebacks). Pour les frais directs, le compte connecté reçoit le paiement, et les frais peuvent être prélevés sur l'une ou l'autre des parties.

La règle pratique : ne dites jamais "le virement Stripe est le chiffre d'affaires du vendeur" ou "le vendeur paie les frais" tant que vous n'avez pas consigné par écrit le modèle de frais pour chaque flux. Associez ce modèle à chaque transaction. Mélanger des frais directs et de destination sous une même règle de comptabilisation est le moyen le plus rapide d'errer à la fois sur le chiffre d'affaires et sur le passif.

Ce guide suppose l'utilisation de frais de destination ou de frais et transferts séparés, car c'est dans ces cas-là que le solde de la plateforme porte le poids comptable et que la plupart des grands livres de places de marché sont construits.

Cartographier le flux des fonds avant d'importer la moindre ligne

Avant de procéder à une importation, dessinez une carte des transactions en une page pour chaque flux :

Paiement client
  -> Encaissement Stripe / transaction de solde de paiement
  -> Frais Stripe
  -> Frais de service de la plateforme (commission)
  -> Transfert vers le compte connecté
  -> Remboursement ou litige (le cas échéant)
  -> Virement Stripe (payout)
  -> Encaissement bancaire

Chaque flèche représente une transaction de solde distincte dotée de son propre identifiant, de sa catégorie, de son montant et de ses dates. Traitez le solde Stripe comme un compte de passage de type bancaire : les encaissements entrent, les frais et les transferts sortent, et le virement transfère le reliquat vers la vraie banque. La documentation sur les importations bancaires et de paiements de Nordlet recommande exactement ce traitement pour l'activité Stripe ordinaire.

Choisir le bon rapport source Stripe

Pour les lots de règlements par virements automatiques, utilisez le rapport Rapprochement des virements, par élément (Payout reconciliation, itemized). Il fournit une ligne par transaction de solde, regroupe les lignes par reporting_category, associe chacune à un automatic_payout_id et fournit les totaux bruts, de frais et nets. Le guide de sélection des rapports de Stripe documente ce rapport et confirme que charge_id, connected_account_id et destination_payment_id sont des champs Connect disponibles.

Lorsque les virements automatiques ne sont pas activés (dans le cadre de certains arrangements avec virements manuels), utilisez plutôt le rapport de solde (Balance report). Ne considérez pas un résumé des virements du tableau de bord comme une preuve suffisante pour la comptabilisation. Le résumé prouve le total du lot ; seul le rapport détaillé en explique les composantes.

Stripe recommande de classer les opérations par reporting_category plutôt que d'utiliser l'ancien champ type, et chaque ligne comporte un identifiant source qui se rattache à l'objet sous-jacent. Notez la contrainte de calendrier : Stripe indique que les données des rapports quotidiens sont généralement disponibles au plus tard à midi le jour suivant, et que les virements instantanés ne peuvent pas être affectés clairement à des transactions individuelles, ce qui nécessite un rapprochement distinct de l'historique des transactions.

Classifier chaque transaction de solde par catégorie

Utilisez la reporting_category comme classificateur principal, puis examinez le source_id, le charge_id et les descriptions. La correspondance essentielle à retenir :

Activité Stripe	Catégorie de reporting (`reporting_category`)	Interprétation comptable
Encaissement client, carte ou moyen de paiement local	`charge`	Créance financée par le client ou règlement de vente
Remboursement	`refund`	Annulation de l'encaissement client d'origine
Frais de traitement retenus par Stripe	`fee`	Charges de traitement des paiements
Commission de la plateforme	`platform_earning`	Chiffre d'affaires de commissions
Frais d'application remboursés	`platform_earning_refund`	Réduction du chiffre d'affaires de commissions
Transfert vers un compte connecté	`transfer`	Réduction de la dette envers le vendeur
Transfert inversé (rejet de transfert)	`transfer_reversal`	Recouvrement auprès du compte connecté
Refacturation (chargeback)	`dispute`	Perte sur refacturation ; examiner l'objet litige source
Litige gagné ou inversé	`dispute_reversal`	Recouvrement d'une refacturation précédemment comptabilisée
Virement vers la banque	`payout`	Mouvement bancaire, et non un chiffre d'affaires
Virement inversé	`payout_reversal`	Retour des fonds sur le solde Stripe
Réserve retenue	`connect_reserved_funds` / `risk_reserved_funds`	Fonds restreints, pas une charge par défaut
Encaissement d'un solde débiteur de longue date	`connect_collection_transfer`	Événement de financement ou de recouvrement nécessitant une politique de risque

Une mise en garde concernant la terminologie : l'ancien champ de type de transaction de solde (balance-transaction type) utilise des libellés différents pour les mêmes événements, notamment payment, application_fee et adjustment. La documentation de Stripe sur les types de transactions de solde énumère ces deux vocabulaires. Ne mélangez pas une valeur de type (type) dans une règle de reporting_category, et n'inventez pas une catégorie telle que dispute_loss que Stripe n'exporte pas. Si un export comporte un libellé que vous ne reconnaissez pas, conservez la valeur exportée et vérifiez-la par rapport à l'objet source.

Comptabiliser l'activité normale de la place de marché dans le grand livre

Pour une plateforme appliquant des frais de destination ou des frais et transferts séparés, les écritures conceptuelles sont les suivantes.

Encaissement client (l'argent du client entre dans le solde de compensation Stripe) :

Débit Compte de compensation Stripe   Encaissement client brut
    Crédit Créances clients            Encaissement client brut

Frais de traitement Stripe :

Débit Charges de frais Stripe         Frais Stripe
    Crédit Compte de compensation Stripe  Frais Stripe

Ne déduisez pas les frais Stripe du chiffre d'affaires par compensation (netting), à moins que votre politique comptable n'exige et ne justifie expressément une présentation nette.

Commission de la plateforme (votre chiffre d'affaires, soustrait de ce qui serait autrement dû au vendeur) :

Débit Dette envers le vendeur        Montant de la commission
    Crédit Chiffre d'affaires commissions  Montant de la commission

Transfert au vendeur (règlement de l'argent dû, et non une charge) :

Débit Dette envers le vendeur        Montant du transfert
    Crédit Compte de compensation Stripe  Montant du transfert

Un transfert ne constitue jamais automatiquement une charge. La part du vendeur devient un passif dès que l'encaissement est réalisé, et le transfert éteint ce passif. Les règles de comptabilisation des règlements de Nordlet suivent cette logique : les lignes platform_earning sont portées au crédit du chiffre d'affaires de commissions tandis que les lignes transfer réduisent la dette envers le vendeur. Les clés de comptabilisation par défaut documentées sont settlements.commissionRevenue (par défaut 5001), settlements.sellerPayable (par défaut 4499), settlements.fees (par défaut 6800) et settlements.suspense (par défaut 4440), chacune pouvant être personnalisée par entreprise via les règles de comptabilisation dans l'API Nordlet.

Traiter les remboursements par rapport à la vente initiale, et non comme de simples opérations bancaires

Un remboursement est lié à l'encaissement ou à la facture d'origine. Conceptuellement :

Débit Remboursements / annulations de ventes  Montant du remboursement
    Crédit Créances clients                   Montant du remboursement

L'écriture réelle dépend du fait que la vente ait été comptabilisée, que la taxe doive faire l'objet d'un avoir et qu'une commission de plateforme ait été remboursée. Un seul remboursement peut engendrer l'annulation d'une créance, l'annulation d'une taxe, le remboursement de frais d'application, l'annulation d'un transfert ou la réduction du passif du vendeur, ainsi qu'une incidence sur les frais Stripe qu'il convient de vérifier plutôt que de supposer.

Le piège temporel : un remboursement se règle souvent dans un virement postérieur à l'encaissement d'origine. Privilégiez le rapport de rapprochement des virements détaillé (itemized payout-reconciliation) plutôt qu'un remboursement synthétisé à partir d'un export au niveau des encaissements. La documentation de Nordlet avertit explicitement qu'un remboursement synthétisé à partir d'un export de paiements n'est qu'une approximation lorsque le remboursement est réglé ultérieurement. L'importateur de règlements peut ingérer la ligne de remboursement, la faire correspondre à la vente d'origine et annuler la créance lorsque le lot est comptabilisé.

Traiter les litiges séparément des remboursements

Un litige est une réclamation émanant d'un porteur de carte ou de sa banque émettrice, et Stripe peut débiter à la fois le montant contesté et des frais de litige avant la résolution. Pour les frais de destination et les frais et transferts séparés, Stripe débute le solde de la plateforme pour les deux, conformément à ses recommandations sur les remboursements et les litiges. La plateforme peut tenter un recouvrement en inversant le transfert du vendeur.

Un litige perdu, du point de vue de la plateforme :

Débit Perte sur refacturation / créance rouverte  Montant contesté
Débit Charges de frais de litige                  Frais de litige
    Crédit Compte de compensation Stripe           Montant cumulé

Si le vendeur supporte la perte et que le recouvrement est confirmé :

Débit Dette envers le vendeur / compte de recouvrement  Montant recouvrable
    Crédit Reprise sur pertes de refacturation          Montant recouvrable

Ne comptabilisez pas un recouvrement auprès du vendeur simplement parce qu'une annulation de transfert a été demandée. Vérifiez que l'annulation a bien été créée, qu'elle a réussi et qu'elle apparaît dans le solde Stripe. Si le litige est gagné, Stripe restitue le montant contesté par le biais d'une ligne dispute_reversal ; annulez la perte sur refacturation et traitez séparément tous les frais de litige que Stripe ne rembourse pas. Nordlet associe les lignes de refacturation en utilisant le charge_id d'un encaissement précédemment rapproché, issu du même fichier ou d'une importation antérieure.

Exemple de règlement chiffré

Prenons un lot de virements automatiques. Le rapport détaillé contient :

Une ligne charge : brut 100,00, frais Stripe 3,20, net 96,80
Une ligne platform_earning : 15,00, correspondant à la commission de la plateforme
Une ligne transfer : 81,80 vers le vendeur connecté
Une ligne refund provenant d'une vente antérieure : brut 20,00, réglée dans ce lot
Une ligne payout : le total du lot transféré à la banque

La composition du virement, suivant l'identité de règlement de Stripe :

Encaissements bruts                 100,00
- remboursements                     20,00
- frais Stripe                        3,20
- transferts                         81,80
= net vers le solde de la plateforme -5,00

La ligne platform_earning ne déplace pas d'argent une seconde fois. Elle désigne les 15,00 qui restent dans le solde de la plateforme une fois les frais et le transfert au vendeur déduits, de sorte que la plateforme puisse comptabiliser un chiffre d'affaires de commissions au lieu de le déduire.

Dans cet exemple, le transfert au vendeur et le remboursement dépassent l'activité nette des encaissements, de sorte que le lot dégage un solde net légèrement négatif qui viendra réduire le virement suivant ou puiser dans le solde. Le journal comptabilisé extorne la créance remboursée, comptabilise 15,00 de chiffre d'affaires de commissions, enregistre 3,20 de charges de frais, réduit la dette envers le vendeur du montant du transfert et comptabilise l'annulation du remboursement. La ligne bancaire correspond au montant net qui parvient sur le compte. Aucun montant isolé ne représente "le chiffre d'affaires", ce qui est précisément l'enjeu.

Importer et comptabiliser via le point de terminaison des règlements de Nordlet

Pour le rapprochement au niveau des virements, utilisez :

POST /v1/bank/settlements/import

avec le fournisseur Stripe et le fichier CSV détaillé. Nordlet regroupe les lignes par automatic_payout_id, transforme chaque virement en un lot de règlement doté des totaux bruts, de frais et nets, ignore les réimportations d'un virement déjà comptabilisé, ignore les lignes payout de la composition des règlements, et associe automatiquement les lignes de charges, de remboursements et de litiges en utilisant les références de commandes, factures, PaymentIntent, encaissements, sources ou métadonnées. Stripe scinde le rapport détaillé en un fichier par section ; il convient donc d'importer simultanément les fichiers d'encaissements, de remboursements et de frais : les lignes appartenant à un virement déjà importé mais pas encore comptabilisé fusionnent dans le lot existant. Il s'agit d'un flux d'importation et de comptabilisation piloté par des fichiers et des points de terminaison de règlements, et non d'un connecteur Stripe en temps réel ; la page des fonctionnalités répertorie ce que couvrent les volets bancaires et de règlements.

Procédez au rapprochement dans l'ordre : les encaissements avec les factures, les remboursements avec les encaissements d'origine, les litiges avec les encaissements d'origine, et les lignes de commissions avec le traitement des commissions. Maintenez les frais Stripe, les ajustements, les réserves et les lignes de virements hors du rapprochement des factures. Le glossaire sur le rapprochement des paiements de Nordlet indique que les lignes de frais et d'ajustements ne peuvent pas être rapprochées des factures par conception ; acheminez les éléments monétaires non résolus vers un compte d'attente. La correction manuelle s'effectue via bank/settlements/match { lineId, invoiceId }, avec un invoiceId défini à null pour rompre le rapprochement.

Comptabilisez ensuite un lot équilibré :

POST /v1/bank/settlements/post

Cette action crée un journal équilibré, règle les factures rapprochées, débite le compte de grand livre de la banque pour le virement net, débite les frais, crédite les créances pour les encaissements, extorne les créances pour les remboursements et les refacturations, répartit les encaissements de places de marché non rapprochés entre le chiffre d'affaires de commissions et les dettes envers les vendeurs lorsque le paramètre commissionPercent est fourni, et envoie les montants non résolus vers un compte d'attente. Toute catégorie qu'il ne reconnaît pas atterrit également en compte d'attente, et la réponse indique ces catégories dans un avertissement plutôt que de les absorber silencieusement.

Liste de contrôle de rapprochement

Exécutez ces vérifications avant chaque clôture :

Absence de balance_transaction_id en double
Absence de lot de règlement (provider, payout_id) en double
La somme des montants nets des lignes est égale au net du lot
Le net du lot est égal au virement bancaire, sous réserve des règles de calendrier et de devise
Chaque remboursement dispose d'un encaissement d'origine ou d'une exception enregistrée
Chaque litige dispose d'une référence de litige ou d'encaissement
Chaque transfert dispose d'un identifiant de compte connecté
Chaque ligne platform_earning possède un traitement de commission défini
Le compte d'attente est à zéro ou a fait l'objet d'un examen complet, y compris pour toutes les catégories non reconnues mentionnées dans l'avertissement de comptabilisation
Le solde des dettes envers les vendeurs n'est pas négatif en l'absence d'une avance approuvée ou d'une politique de recouvrement
Les lots comptabilisés ne peuvent pas être réimportés ou recomptabilisés silencieusement
Un virement effectué dans une devise autre que la devise de référence de l'entreprise est converti au taux du jour du virement, l'écart par rapport au taux propre de chaque facture étant comptabilisé en gain ou perte de change réalisé ; tout virement combinant plusieurs devises est rejeté lors de l'importation

Rapprochez les données à trois niveaux : la ligne (chaque transaction conserve un identifiant, une catégorie, un montant, une devise et une source), le virement (les soldes nets détaillés correspondent au virement Stripe et à l'encaissement bancaire) et le grand livre (le journal comptabilisé est équilibré et génère les positions souhaitées en matière de chiffre d'affaires, de frais, de créances, de passifs envers les vendeurs et de comptes d'attente). En ce qui concerne spécifiquement les soldes des vendeurs, vérifiez que le passif d'ouverture envers les vendeurs, majoré de la nouvelle quote-part des vendeurs, diminué des transferts et des annulations valides, est égal au passif de clôture envers les vendeurs.

L'échec récurrent sur l'ensemble des grands livres de places de marché est toujours le même : réduire un virement structuré à un chiffre unique. Maintenez les composantes séparées, ancréz chacune à un identifiant Stripe stable, et laissez un compte d'attente enregistrer tout ce que vous ne pouvez pas encore expliquer. Une clôture propre est ce à quoi un auditeur prêtera foi.

FAQ

Le virement Stripe constitue-t-il le chiffre d'affaires de la plateforme ?

Non. Le virement est le solde net des encaissements, remboursements, frais de traitement, transferts aux vendeurs, litiges et ajustements qui ont été réglés dans le même lot. Le comptabiliser sur une seule ligne de produits efface la dette envers le vendeur et les charges de traitement qu'il contient. Pour une place de marché mandataire, le chiffre d'affaires correspond à la commission, que les lignes platform_earning permettent d'identifier.

Contre quel rapport Stripe dois-je effectuer le rapprochement ?

Le rapport de rapprochement des virements, détaillé (Payout reconciliation, itemized), car il fournit une ligne par transaction de solde dotée d'une reporting_category, d'un automatic_payout_id, ainsi que des montants bruts, de frais et nets. Un résumé des virements du tableau de bord ne prouve que le total du lot. Lorsque les virements automatiques ne sont pas activés, utilisez plutôt le rapport de solde (Balance report).

Un transfert vers un vendeur doit-il être comptabilisé en tant que charge ?

Non. La part du vendeur devient un passif dès l'instant où l'encaissement client est réalisé, et le transfert éteint ce passif. Comptabiliser les transferts en charges revient à comptabiliser deux fois le coût et laisse le passif du vendeur artificiellement et durablement majoré.

Que devient une ligne Stripe dont l'importateur ne reconnaît pas la catégorie ?

Elle est portée au crédit ou au débit du compte d'attente des règlements (par défaut le 4440), et la réponse de la comptabilisation renvoie un avertissement nommant les catégories qui y ont été acheminées. Les réserves et les ajustements inhabituels atterrissent généralement de cette manière, ce qui est délibéré : l'argent reste visible et le journal demeure équilibré jusqu'à ce qu'une personne détermine où il doit être rattaché.

Comment sont traités les remboursements réglés dans un virement ultérieur ?

Ils arrivent sous la forme d'une ligne refund dans le rapport détaillé du virement ultérieur et sont rapprochés de l'encaissement d'origine par le biais du charge_id de l'encaissement initialement rapproché. Un remboursement synthétisé à partir d'un export de paiements au niveau des encaissements n'est dans ce cas qu'une approximation, ce qui fait du rapport détaillé la source la plus sûre.