Le comptable du client envoyait le même message chaque fin de mois depuis six mois : « L’export WooCommerce ne correspond pas au relevé bancaire, il manque toujours quelques centaines d’euros. » Personne n’avait pris le temps d’investiguer sérieusement, le service comptable ajustait manuellement à la main chaque mois en attribuant l’écart à des « frais divers ». Le jour où l’écart a dépassé mille euros sur un mois particulièrement chargé, il a fallu enfin comprendre ce qui se passait réellement.
Symptôme
L’export utilisé était une extraction simple des commandes au statut completed sur le mois, sommée par date de commande, comparée au total des virements entrants du relevé bancaire Stripe sur la même période calendaire. Un écart de plusieurs centaines d’euros apparaissait systématiquement, tantôt positif, tantôt négatif selon les mois, ce qui excluait d’emblée une erreur de calcul simple et cohérente — une vraie erreur de formule aurait produit un écart de même signe et de même proportion chaque mois.
Diagnostic : trois sources d’écart cumulées
La première source, et la plus significative, tenait à la confusion entre date de commande et date d’encaissement effectif. Une commande passée le 30 du mois peut être capturée par la passerelle de paiement (et donc réellement créditée sur le compte bancaire) seulement le 2 du mois suivant, en particulier avec un mode de paiement différé comme un virement SEPA ou une capture manuelle. L’export comptable sommait les commandes par date de création, tandis que le relevé bancaire enregistrait les fonds par date de dépôt réel — deux périodes qui ne coïncident jamais parfaitement en fin de mois.
La deuxième source concernait les remboursements partiels. WooCommerce enregistre un remboursement partiel comme un ajustement du total de la commande d’origine, visible via $order->get_total_refunded(), mais l’export utilisé sommait uniquement $order->get_total(), qui reste le montant brut initial et ne reflète pas les remboursements effectués depuis. Une commande de 150 € partiellement remboursée de 40 € apparaissait donc encore à 150 € dans l’export, alors que la banque n’avait laissé que 110 € nets sur le compte.
La troisième source, plus subtile, tenait aux frais de la passerelle de paiement elle-même. Stripe, comme la plupart des prestataires, prélève ses frais de transaction avant de créditer le compte bancaire du marchand : une commande à 100 € se traduit par un dépôt bancaire de 97,10 € environ, la différence n’apparaissant jamais dans le total de la commande WooCommerce, qui reste toujours le montant brut payé par le client.
Correctif
La solution a consisté à reconstruire l’export comptable autour de trois axes distincts plutôt qu’un total unique :
$commandes = wc_get_orders( array(
'status' => array( 'completed', 'processing' ),
'date_paid' => $debut_periode . '...' . $fin_periode, // date d'encaissement réel
'limit' => -1,
) );
$total_brut = 0;
$total_rembourse = 0;
foreach ( $commandes as $commande ) {
$total_brut += (float) $commande->get_total();
$total_rembourse += (float) $commande->get_total_refunded();
}
$net_avant_frais_passerelle = $total_brut - $total_rembourse;Le filtre sur date_paid plutôt que sur la date de création a réglé la majeure partie de l’écart en réalignant l’export sur la même logique temporelle que le relevé bancaire. Les remboursements ont été isolés dans une colonne dédiée plutôt que soustraits silencieusement du total. Restait la question des frais de passerelle, non calculables directement depuis les données WooCommerce natives.
Le rapprochement final avec les frais de passerelle
Pour ce dernier point, il a fallu s’appuyer sur les métadonnées que Stripe attache elle-même à chaque commande via son intégration WooCommerce, ou à défaut sur l’export de frais fourni directement par le tableau de bord du prestataire de paiement, qui liste précisément chaque transaction et son montant de frais prélevé. Aucune fonction WooCommerce native ne restitue ce montant, puisqu’il appartient entièrement au domaine du prestataire de paiement, pas à la boutique elle-même.
Prévention
- Toujours baser un export comptable sur la date d’encaissement (
date_paid), jamais sur la date de création de la commande. - Toujours soustraire explicitement
get_total_refunded(), dans une colonne séparée pour garder la traçabilité du geste comptable. - Ne jamais espérer que le total WooCommerce corresponde au dépôt bancaire net : les frais de passerelle doivent être rapprochés depuis une source distincte, propre au prestataire de paiement.
- Documenter cette méthodologie pour le service comptable, afin qu’un écart résiduel de quelques centimes (arrondis de conversion de devise, par exemple) ne déclenche pas une nouvelle enquête inutile chaque mois.
Un écart comptable récurrent n’est presque jamais un bug isolé. C’est en général la somme silencieuse de plusieurs petites hypothèses fausses, qui se compensent ou s’additionnent selon les mois — ce qui explique pourquoi il semblait aléatoire au premier regard.
En résumé
Ce qui ressemblait à une anomalie comptable récurrente et insoluble n’était en réalité que trois définitions différentes du mot « payé » qui ne s’accordaient jamais entre elles : date de commande contre date d’encaissement, montant brut contre montant net de remboursement, total de commande contre dépôt bancaire net de frais. Une fois ces trois notions clairement séparées dans l’export, l’écart mensuel est tombé à quelques centimes, entièrement explicables par des arrondis.
