Les fichiers de versements Stripe Marketplace ne se comportent pas comme un export de virement Stripe classique : le flux de trésorerie appartient à la plateforme, mais l'activité est répartie entre plusieurs comptes connectés. Un seul virement bancaire peut regrouper des dizaines de vendeurs, commissions, remboursements, annulations, virements et décalages de règlement.
C'est là que le grand livre de comptes commence à dériver.
Le fichier de versements indique que Stripe a sorti de l'argent. Le grand livre indique à quel vendeur ou compte interne le crédit doit être affecté. Ces deux fichiers répondent à des questions différentes. Une comparaison ligne à ligne génère de fausses anomalies, même quand les deux fichiers sont corrects.
Le rapprochement doit établir trois choses :
- Quel compte connecté a généré chaque mouvement de versement
- Quel compte du grand livre porte ce mouvement en interne
- Quels écarts sont attendus — commissions, remboursements, retenues ou décalages de dates
Rapprocher les fichiers de versements Stripe Marketplace avec les grands livres n'est pas une recherche d'un identifiant commun. C'est un rapprochement par couches — du versement au compte connecté, puis au compte du grand livre — en séparant les exceptions avant de valider le rapport final.
Commencez par distinguer le fichier de versements du grand livre
Un fichier de versements Stripe Marketplace contient généralement des données de mouvement : ce que Stripe a viré, annulé, ajusté ou bloqué. Un grand livre de comptes interne contient généralement des données d'appartenance : quel vendeur, fournisseur, sous-compte, portefeuille ou solde interne doit recevoir les fonds.
Ces fichiers se recoupent, mais ils ne se substituent pas l'un à l'autre.
| Champ du fichier de versements Stripe | Champ du grand livre interne | Ce qu'il établit |
|---|---|---|
payout_id | Référence du lot de versements | À quel lot de versements appartient la ligne |
connected_account_id | Identifiant vendeur / identifiant fournisseur | Quel compte porte l'opération |
balance_transaction_id | Référence de transaction | Quel mouvement Stripe a généré la ligne |
amount | Montant brut ou montant à verser | La valeur avant ou après déductions |
fee | Commission plateforme / frais de traitement | La déduction appliquée au mouvement |
net | Règlement net | L'impact de trésorerie après commissions |
available_on | Date de règlement prévue | Quand les fonds sont devenus disponibles |
type | Type d'écriture au grand livre | Si la ligne est un débit, remboursement, virement, commission, ajustement ou retenue |
La première erreur : traiter amount dans les deux fichiers comme le même type de montant. Ce n'est pas toujours le cas.
Dans le fichier Stripe, amount peut désigner le débit brut, le virement vers un compte connecté, un remboursement négatif ou un mouvement de versement. Dans le grand livre, il peut désigner le montant à verser au vendeur, le produit de la plateforme, la trésorerie nette ou la variation de solde interne. Ces nombres peuvent être liés sans être égaux.
Avant tout rapprochement, qualifiez la nature du montant dans les deux fichiers : débit brut, commission plateforme, frais de traitement, virement vers compte connecté, net du versement, remboursement, annulation, retenue ou blocage. Si la nature du montant n'est pas claire, la correspondance semblera fausse plus tard. Vous comparerez un montant à verser au vendeur avec un net de versement et qualifierez l'écart d'inexpliqué — alors que cet écart est simplement la commission plateforme ou les frais de traitement.
Construisez le rapprochement autour du compte connecté
Le compte connecté est le point de contrôle. La ligne bancaire confirme que Stripe a effectué un virement, mais elle ne prouve pas quels vendeurs figuraient dans ce versement ni si le solde du grand livre de chaque vendeur est correct.
Utilisez cet ordre de rapprochement :
| Niveau de correspondance | Côté Stripe | Côté grand livre | Objectif |
|---|---|---|---|
| Lot de versements | payout_id ou date de versement | ID de lot ou campagne de règlement | Regroupe les lignes dans le même mouvement de trésorerie |
| Compte connecté | connected_account_id | Identifiant vendeur / fournisseur / compte | Attribue chaque ligne au bon titulaire |
| Référence de transaction | balance_transaction_id, ID de débit, ID de virement | Référence paiement, commande ou grand livre | Établit l'identité au niveau de la ligne |
| Nature du montant | Brut, commission, net, virement | À verser, commission, produit, trésorerie | Évite les comparaisons entre montants incompatibles |
| Fenêtre de dates | created, available_on, date de versement | Date de transaction, date grand livre, date de règlement | Distingue les décalages des lignes manquantes |
Ne commencez pas par le montant du versement. Il est trop agrégé.
Commencez par le compte connecté. Regroupez les lignes Stripe pour ce compte. Comparez-les avec le grand livre du compte. Une fois chaque compte bouclé, remontez les résultats au niveau du lot de versements.
Cet ordre garde le rapprochement lisible. Si la plateforme est en déficit de 3,842.18, vous voulez savoir que le compte connecté acct_72K a deux lignes de remboursement manquantes, que acct_91P a une retenue et que le reste du lot est en ordre.
Pour un flux classique de versement vers banque, le problème adjacent est le rapprochement d'un CSV de versement Stripe avec votre relevé bancaire. Le travail sur les versements de place de marché ajoute une couche : le versement doit se raccorder à l'appartenance du compte, pas seulement aux encaissements.
Normalisez les deux fichiers sans modifier les sources
Ne modifiez pas les exports sources. Créez des colonnes de travail à côté.
Ces colonnes rendent les deux fichiers comparables tout en préservant les valeurs brutes issues de Stripe et du grand livre interne.
| Colonne de travail | Source Stripe | Source grand livre | Pourquoi c'est utile |
|---|---|---|---|
normalized_account_id | connected_account_id | Identifiant vendeur, fournisseur, portefeuille | Harmonise les intitulés de comptes |
normalized_reference | ID de débit, virement ou transaction de solde | ID de commande, référence paiement, référence grand livre | Crée des candidats de correspondance au niveau ligne |
signed_amount | Montant, commission, net avec signe conservé | Montant débit ou crédit avec signe harmonisé | Évite les inversions débit-crédit |
amount_basis | Type et catégorie de reporting | Compte du grand livre ou type de transaction | Élimine la confusion brut/net |
settlement_window | Date de création, de disponibilité, de versement | Date de comptabilisation ou de règlement | Gère les décalages de dates |
currency | Colonne devise | Devise du grand livre | Bloque les fausses correspondances entre devises |
Pour normalized_reference, la formule de base est :
=SUPPRESPACE(SUBSTITUE(MAJUSCULE(A2),CAR(160)," "))La colonne A est le champ référence — ID de transaction de solde, ID de débit, ID de virement ou référence du grand livre interne. SUPPRESPACE supprime les espaces standards ; CAR(160) couvre l'espace insécable que certains systèmes exportent. Si le grand livre ne stocke qu'un fragment de la référence Stripe, extrayez avec STXT ou DROITE avant de normaliser.
La colonne auxiliaire la plus importante est amount_basis.
Sans elle, une recherche peut renvoyer une correspondance mathématiquement proche mais conceptuellement fausse. Un virement de 100.00 vers un vendeur et un débit client brut de 100.00 ne sont pas la même opération. Des valeurs identiques ne prouvent pas l'identité quand les types de transaction diffèrent.
La même règle s'applique aux signes. Stripe peut exporter les remboursements, annulations et commissions en négatif. Le grand livre peut stocker le même mouvement économique comme un débit dans une colonne ou un nombre positif dans une colonne de charges. Normalisez le signe pour la comparaison, mais conservez le signe brut visible dans le rapport.
Rapprochez chaque compte connecté avant le lot de versements
La méthode correcte : d'abord le compte, ensuite le versement.
Supposons que le fichier de versements Stripe contienne ceci :
| ID versement | Compte connecté | Type | Référence | Brut | Commission | Net |
|---|---|---|---|---|---|---|
| po_8841 | acct_A | Virement | tr_1001 | 500.00 | -20.00 | 480.00 |
| po_8841 | acct_A | Remboursement | re_1008 | -75.00 | 0.00 | -75.00 |
| po_8841 | acct_B | Virement | tr_1002 | 900.00 | -36.00 | 864.00 |
| po_8841 | acct_C | Retenue | adj_4421 | -120.00 | 0.00 | -120.00 |
Le grand livre interne pourrait afficher ceci :
| Compte grand livre | Référence | Mouvement de compte | Commission plateforme | Statut de règlement |
|---|---|---|---|---|
| Vendeur A | tr_1001 | 480.00 | 20.00 | Réglé |
| Vendeur A | re_1008 | -75.00 | 0.00 | Remboursé |
| Vendeur B | tr_1002 | 864.00 | 36.00 | Réglé |
| Vendeur C | adj_4421 | 0.00 | 0.00 | Bloqué |
Si vous comparez d'abord le total du versement, la retenue ressemble à un paiement manquant. Si vous comparez d'abord chaque compte connecté, le vendeur C n'est pas manquant. Le grand livre a classé la ligne comme bloquée et non comme réglée.
Cette distinction change la réponse finale.
Le rapport ne doit pas indiquer :
Le vendeur C est en déficit de 120.00.
Il doit indiquer :
Le vendeur C a une retenue de 120.00 dans Stripe, non payable lors du règlement actuel du grand livre.
C'est une note de rapprochement exploitable. Elle indique à l'opérateur ce qui s'est passé et ce qu'il doit faire ensuite.
Procédez d'abord par correspondances candidates, puis par correspondances confirmées
Les fichiers de place de marché ne fournissent pas toujours une clé unique commune à tous les exports. La même opération peut apparaître comme un ID de débit dans un export, un ID de virement dans un autre et une référence de commande dans le grand livre.
Commencez par les correspondances candidates.
| Règle de correspondance candidate | Quand l'utiliser | Risque |
|---|---|---|
| Correspondance exacte sur référence | Le même ID de débit, virement ou transaction de solde figure dans les deux fichiers | Faible |
| Compte connecté + fragment de référence | Le grand livre ne contient qu'une partie de la référence Stripe | Moyen |
| Compte connecté + montant + fenêtre de dates | La référence est absente mais le montant et le calendrier concordent | Moyen |
| Compte connecté + ID commande + montant | Le grand livre suit la commande plutôt que le mouvement Stripe | Moyen |
| Correspondance sur montant seul | Aucune référence fiable disponible | Élevé |
Les correspondances candidates ne sont pas définitives. Ce sont des candidats à valider.
Une correspondance confirmée doit satisfaire ces conditions :
- Les comptes connectés concordent.
- Le type de transaction ou la nature du montant concordent.
- Le montant signé concorde après clarification du traitement des commissions.
- La date s'inscrit dans la fenêtre de règlement prévue.
- Les devises concordent.
- La ligne n'a pas déjà été rapprochée à une autre écriture du grand livre.
Ce dernier point est crucial. Les exports de place de marché peuvent contenir des valeurs répétées. Si le processus de correspondance autorise une ligne Stripe à se rapprocher de deux écritures du grand livre, le rapprochement s'équilibrera en apparence tout en masquant un doublon.
Séparez les commissions, remboursements, retenues et décalages de dates
La liste des exceptions ne doit pas être un seul bloc intitulé « non rapproché ».
Ce bloc est trop vague pour être clôturé. Il mélange de vraies erreurs avec des comportements attendus de la place de marché.
Utilisez des catégories d'écart qui décrivent la cause réelle :
| Catégorie d'écart | Signification | Action |
|---|---|---|
| Absent du grand livre | La ligne Stripe existe, aucune écriture au grand livre | Créer ou vérifier l'écriture au grand livre |
| Absent du fichier Stripe | L'écriture du grand livre existe, aucune ligne Stripe | Vérifier les filtres de dates, le périmètre de l'export ou la saisie manuelle |
| Discordance de compte | La référence existe mais les comptes connectés diffèrent | Vérifier le mapping vendeur |
| Discordance de nature du montant | Même opération, type de montant différent comparé | Reclassifier en brut, commission, net ou montant à verser |
| Écart de commission | La commission plateforme ou de traitement ne concorde pas | Vérifier les règles de comptabilisation des commissions |
| Décalage remboursement ou annulation | Le mouvement négatif se rattache à une transaction antérieure | Relier à l'opération d'origine |
| Retenue ou blocage | Stripe a différé le versement plutôt que de payer le vendeur | Reporter au prochain règlement |
| Décalage de dates | Même ligne, date de comptabilisation ou de versement différente | Marquer comme décalage, non comme ligne manquante |
| Écriture en doublon au grand livre | Une ligne Stripe correspond à plusieurs écritures du grand livre | Supprimer ou contrepasser le doublon |
Les remboursements et annulations méritent un traitement séparé. Un remboursement peut se rattacher à un débit d'une période antérieure mais apparaître dans le versement actuel. Si le grand livre ne contient que les commandes de la période en cours, le remboursement semblera non rapproché. La solution n'est pas de forcer le remboursement dans la liste de ventes actuelle. C'est d'identifier le débit d'origine, d'enregistrer le remboursement sur le bon compte et de montrer que le versement actuel a été réduit de ce montant.
Les abonnements ajoutent un problème de décalage connexe quand les factures, les paiements et le règlement du versement tombent dans des périodes différentes. Si des factures récurrentes font partie du flux de la place de marché, la même discipline de dates utilisée pour le rapprochement des factures d'abonnement Stripe s'applique ici : date de facturation, date de paiement, date de disponibilité et date de versement sont des champs distincts.
Ne bouclez le lot de versements qu'après le rapprochement par compte
Une fois chaque compte connecté rapproché, remontez les résultats dans un récapitulatif du versement.
Le récapitulatif doit répondre à quatre questions :
- Le total du versement Stripe concorde-t-il avec le virement bancaire ou le mouvement de trésorerie ?
- L'activité Stripe de chaque compte connecté concorde-t-elle avec le grand livre interne ?
- Les commissions, remboursements, retenues et décalages sont-ils séparés des véritables erreurs ?
- L'écart inexpliqué résiduel est-il nul ?
Un récapitulatif de versement utile se présente ainsi :
| Catégorie | Nombre | Montant |
|---|---|---|
| Virements comptes connectés rapprochés | 82 | 48,210.00 |
| Commissions plateforme rapprochées | 82 | -1,928.40 |
| Remboursements et annulations rapprochés | 9 | -1,144.20 |
| Retenues reportées | 3 | -640.00 |
| Écritures manquantes au grand livre | 2 | -318.75 |
| Écritures en doublon au grand livre | 1 | 120.00 |
| Écart inexpliqué après vérification | 0 | 0.00 |
Les libellés exacts dépendent de votre place de marché, mais la structure ne doit pas changer. Opérations rapprochées, écarts attendus et vraies exceptions doivent figurer sur des lignes distinctes.
Le rapport final doit également inclure un tableau des exceptions par compte :
| Compte connecté | Problème | Montant | Justificatif | Action |
|---|---|---|---|---|
| acct_A | Remboursement manquant au grand livre | -75.00 | Remboursement Stripe re_1008 | Enregistrer le remboursement sur le vendeur A |
| acct_C | Retenue Stripe | -120.00 | Ajustement Stripe adj_4421 | Reporter jusqu'à libération |
| acct_D | Virement en doublon au grand livre | 120.00 | Deux écritures rapprochées à tr_4410 | Contrepasser le doublon |
C'est ce tableau que l'opérateur peut utiliser. Il pointe vers des lignes, des comptes, des justificatifs et des actions. Un tableur surligné sans cette structure laisse la question ouverte.
Ce que prouve un rapprochement place de marché réussi
Un rapprochement de versements de place de marché finalisé ne prouve pas que chaque chiffre dans chaque fichier est identique. Il prouve que chaque écart a un libellé correct.
Le versement de la plateforme peut différer des ventes brutes de la place de marché parce que les virements vendeurs, commissions, remboursements, litiges, retenues et décalages de versement s'intercalent tous entre la vente et le mouvement de trésorerie. Le grand livre de comptes connectés peut différer du fichier de versements parce que certaines lignes ne sont pas encore payables, appartiennent à des transactions de périodes antérieures ou ont été comptabilisées sous une référence différente.
Le résultat correct doit indiquer :
- Ce lot de versements concorde avec la trésorerie.
- Ces comptes connectés ont été rapprochés proprement.
- Ces lignes représentent des décalages de dates, retenues, remboursements ou commissions attendus.
- Ces lignes nécessitent une correction au grand livre.
- L'écart inexpliqué résiduel est nul, ou il est isolé à des lignes précises.
C'est le standard à respecter avant de clôturer le rapprochement.
Liste de vérification avant de clôturer le fichier
Avant de remettre le rapport de versement, confirmez que le lot est identifié, que les identifiants de comptes connectés sont associés aux comptes du grand livre, que la nature du montant est qualifiée dans les deux fichiers, que les lignes brutes et nettes ne sont pas mélangées, que les remboursements et retenues sont séparés, que les doublons de correspondance sont supprimés et que les écritures vraiment manquantes au grand livre sont listées avec leurs références.
L'ordre est la clé. Le rapprochement par compte passe avant le confort au niveau du versement. Si le total du versement concorde mais que les soldes des comptes connectés ne concordent pas, le rapprochement n'est pas terminé. Si chaque compte connecté est bouclé mais que le lot de versements ne concorde pas avec la trésorerie, le mouvement de trésorerie final reste à vérifier.
Un fichier de versements de place de marché contient trop d'informations pour une seule formule de recherche. Traitez-le comme un rapprochement contrôlé : identifiez le lot, mappez les comptes connectés, rapprochez les lignes, classifiez les écarts attendus, puis consolidez le résultat dans un rapport qui explique le versement au lieu de le masquer.
