TL;DR
Un remboursement, c’est rarement “juste un détail” : c’est souvent là que les trous apparaissent.
Le piège classique : vente par carte, remboursement autrement (cash/virement) → chaîne brisée.
Les plateformes traitent les remboursements comme des opérations qui affectent ton solde et tes dépôts. (Stripe Docs)
Si tu veux une compta traçable : une vente doit pouvoir être reliée à sa preuve et à son remboursement, sans interprétation.
Pour qui
- Fermes qui vendent en direct (marché, kiosque, autocueillette, paniers).
- Toute ferme qui fait des retours, erreurs de prix, annulations, ajustements clients.
Quand
- Dès que tu prends la carte, ou que tu acceptes des acomptes/virements.
- Dès que plus d’une personne touche à l’encaisse ou au terminal.
Quand pas
- Si tu ne fais jamais de remboursements (rare), l’article sert surtout à te protéger le jour où ça arrive.
Pourquoi les remboursements font mal à la compta
Une vente “normale” laisse déjà plusieurs traces : transaction, frais, dépôt, relevé bancaire.
Le remboursement, lui, vient souvent après (dans une autre journée, un autre lot, parfois même un autre mois). Et c’est là que le cerveau déraille : “ça s’est réglé”, mais la preuve, elle, peut être éparpillée.
Deux réalités qui se mélangent :
- la réalité du client (“j’ai été remboursé”)
- la réalité comptable (“où est la trace qui relie vente → remboursement → dépôt?”)
Quand ces deux réalités ne se parlent pas, tu finis par faire de la compta à la mémoire.
Ce que “même canal” veut dire (concret)
“Même canal” = même route d’argent que celle qui a encaissé.
- Vente par terminal/carte → remboursement via la fonction refund du même système.
- Vente par virement → remboursement par virement avec une référence claire.
- Vente cash → remboursement cash, mais il faut une trace écrite (sinon c’est un trou noir).
Ce n’est pas une question de morale. C’est une question de traçabilité : si l’argent ne repasse pas par le même tuyau, tu crées un écart permanent entre ce que le terminal raconte et ce que la banque montre.
“Annuler” vs “rembourser” : deux bêtes différentes
Beaucoup de systèmes distinguent :
- annuler/canceller un paiement avant qu’il soit complété
- rembourser après qu’il ait réussi
Stripe documente clairement cette distinction : annulation avant complétion vs remboursement après succès. (Stripe Docs)
Sur le terrain, l’impact est simple :
- annulation rapide = souvent moins de traces, moins de “décalage”
- remboursement après coup = traces plus nombreuses, plus de timing, plus de lots, plus de risques de confusion
Le timing : pourquoi “le remboursement” ne tombe pas quand tu veux
Côté client, un remboursement peut apparaître “pending” puis se poster plus tard, selon la banque émettrice. Square mentionne une fenêtre typique de 1–3 jours ouvrables pour voir la transaction apparaître, avec dépendance à la banque. (Square)
Côté ferme, l’impact est encore plus important : un remboursement peut affecter :
- ton solde chez le processeur
- tes dépôts (payouts)
- ta capacité à encaisser si ton solde devient trop bas
Stripe indique que les remboursements utilisent le solde disponible (et pas les montants encore “pending”). (Stripe Docs)
Stripe parle aussi de gestion de cash-flow pour couvrir remboursements et frais qui peuvent mener à des soldes négatifs. (Stripe Docs)
Traduction terrain : tu peux “rembourser aujourd’hui”, et voir l’effet réel se manifester dans tes dépôts demain ou plus tard, selon le cycle.
Les 3 scénarios qui créent des trous (et pourquoi)
1) Vente carte → remboursement cash
C’est le champion toutes catégories.
Le terminal montre une vente; la banque montre un dépôt net; le cash n’apparaît nulle part.
Résultat : tu as créé une baisse réelle de ton revenu net, mais sans trace symétrique dans le même système.
2) Vente carte → remboursement par virement
Même problème, autre forme. La banque montre un virement sortant, mais tu n’as plus le lien naturel avec la vente initiale dans le terminal/processeur.
3) Vente sur facture → “ajustement verbal”
Quand tu factures, le remboursement comptable propre ressemble souvent à une note de crédit / avoir (une preuve documentaire qui explique l’ajustement). Revenu Québec rappelle qu’en TPS/TVQ il n’y a pas toujours un format unique de facture imposé (sauf secteurs particuliers), mais tu as quand même besoin d’une pièce justificative claire. (Revenu Québec)
Ce qui doit rester vrai pour que ton dossier soit “travaillable”
Quand quelqu’un (toi, ton comptable, un vérificateur) tombe sur un remboursement, il doit pouvoir répondre sans deviner :
- Quelle vente ça corrige?
- Quel montant (total ou partiel)?
- À quelle date?
- Par quel canal l’argent est sorti?
- Où est la preuve (reçu/refund, note de crédit, transaction)?
Certaines plateformes aident : Square explique comment filtrer/voir les remboursements dans ses rapports “Transactions” (Refunds/Exchanges). (Square)
Chez Stripe, les remboursements font partie du flux officiel et affectent le solde (donc les rapports et la conciliation). (Stripe Docs)
Les remboursements partiels : la zone grise fréquente
Les remboursements partiels sont corrects… mais ils augmentent la confusion parce qu’ils créent :
- une vente initiale
- une correction partielle
- parfois une deuxième correction plus tard
Stripe indique explicitement la possibilité de rembourser tout ou partie d’un paiement. (Stripe Docs)
Sur le terrain, ce qui tue, ce n’est pas le remboursement partiel : c’est l’absence de référence claire entre la vente et les remboursements.
Les disputes/chargebacks : pas un remboursement, mais même douleur documentaire
Une contestation (chargeback) n’est pas un remboursement volontaire, mais comptablement ça ressemble à un retrait forcé + frais + délais.
Stripe (Connect) mentionne l’impact des disputes et les mécanismes de recouvrement/solde négatif possibles. (Stripe Docs)
Même principe : si tu n’as pas une trace propre, tu te retrouves à expliquer après coup, et ça coûte du temps et des frais.
Références externes (à quoi elles servent)
- Stripe — Refund and cancel payments (anglais : sert à clarifier annuler vs rembourser, remboursement partiel, et impact sur le solde). (Stripe Docs)
- Stripe — Receive payouts (anglais : sert à comprendre pourquoi remboursements/frais peuvent affecter les dépôts et la gestion de solde). (Stripe Docs)
- Stripe — Balance transaction types (anglais : sert à situer les types d’ajustements et ce qui affecte le solde en dehors du flux charge/refund). (Stripe Docs)
- Square (Canada) — Process refunds (anglais : sert à comprendre le délai côté client et le comportement bancaire). (Square)
- Square (Canada) — View refunds/exchanges in reports (anglais : sert à localiser où voir les remboursements dans les rapports). (Square)
- Revenu Québec — Préparation des factures (sert à cadrer l’idée de facture/pièce justificative en contexte TPS/TVQ, sans surcharger le sujet). (Revenu Québec)