Vos paiements de janvier proviennent de Lemon Squeezy et vos paiements d'août de Paddle, et maintenant votre comptable pose une question qu'aucun de ces tableaux de bord ne peut répondre seul : combien de revenus d'abonnement avez-vous réellement gagnés cette année ? L'ancien fournisseur percevait sous un seul barème de frais, une seule cadence de paiement et un seul ensemble de factures d'impôts émises par ses propres entités. Le nouveau fournisseur fait la même chose avec des rapports différents, des lignes de frais différentes et des documents différents. Entre les deux se trouve un solde de revenus différés, une pile de forfaits annuels vendus sur une plateforme et gérés sur une autre, et une clôture de fin d'année qui doit assembler deux grands livres incompatibles en un ensemble de livres crédible. C'est cette couture — et non l'intégration de l'API, qui prend des jours — qui fait échouer silencieusement les migrations de 'merchant-of-record'.
C'est une décision actuelle pour des milliers de vendeurs. Stripe a acquis Lemon Squeezy en juillet 2024, et la mise à jour de Lemon Squeezy de janvier 2026 a indiqué que son avenir est un chemin de migration facile vers Stripe Managed Payments, le propre produit 'merchant-of-record' de Stripe. Aucune date limite n'a été publiée et Lemon Squeezy fonctionne toujours, mais les vendeurs qui ne souhaitent pas être migrés selon le calendrier de quelqu'un d'autre évaluent les indépendants : Paddle et Polar, tous deux des 'merchants of record' légitimes au même taux de base de 5 % plus 50 centimes. Si vous en faites partie, le changement de facturation est la partie facile. Maintenir la crédibilité de vos livres à travers cela est le vrai projet.
Ce qu'est réellement un 'merchant of record' dans vos livres
Un 'merchant of record' est le vendeur légal de votre produit, pas seulement votre processeur de paiement. Lorsqu'un client achète via Paddle, Polar ou Lemon Squeezy, le relevé de carte mentionne le fournisseur, la facture d'impôt est émise par l'une des entités du fournisseur, et les immatriculations à la taxe de vente et la TVA en Allemagne, au Japon ou au Texas appartiennent au fournisseur plutôt qu'à vous. Le fournisseur calcule, perçoit, déclare et reverse les taxes, absorbe le risque de rétrofacturation et vous envoie un paiement pour le reste.
Cette structure juridique détermine l'apparence de vos écrit comptables. La facture d'achat documente la vente du fournisseur à votre client — c'est sa facture, pas la vôtre. Votre côté de la transaction est documenté par des écrit du côté vendeur : une facture inverse décrivant votre fourniture au fournisseur et un relevé de paiement enregistrant chaque montant versé. Votre revenu est un paiement, net des frais du fournisseur, arrivant selon le calendrier du fournisseur plutôt que de manière continue. Chaque version des documents de chaque fournisseur est différente, ce qui est exactement la raison pour laquelle faire deux d'eux au cours d'une année divise vos registres en deux.
La décision brut contre net que vous devez prendre une seule fois
Avant de toucher à l'une ou à l'autre plateforme, réglez la politique comptable que la migration vous oblige à défendre : reconnaissez-vous le montant total payé par le client comme revenu (brut), ou seulement le paiement que vous avez reçu (net) ?
En vertu de l'ASC 606, c'est la question principal contre agent, et elle est répondue par le contrôle — et non par qui a émis la facture ou dont le nom figure sur le relevé de carte. Les directives se trouvent dans l'ASC 606-10-55-36 à 55-40 : une entité est un principal si elle contrôle le bien ou le service spécifié avant qu'il ne soit transféré au client, et rapporte le revenu au brut ; si sa promesse est seulement d'organiser qu'une autre partie le fournisse, l'entité est un agent et ne rapporte que ses frais ou commissions net. Pour un fournisseur de logiciels vendant via un 'merchant of record' de style revente, la même analyse décide qui est votre client. Si votre client est l'utilisateur final, le revenu est le prix de l'utilisateur final et la part du fournisseur est un coût de vente en dessous de la ligne de revenus. Si votre client est le fournisseur lui-même, le revenu est le prix que le fournisseur vous a payé — le règlement.
Le bénéfice brut est identique dans les deux cas. Le revenu déclaré ne l'est pas, et ce chiffre alimente votre taux de croissance, vos multiples de revenus lors d'une levée de fonds ou d'une acquisition, et chaque comparaison d'une période à l'autre que votre conseil lira. La plupart des fournisseurs de logiciels vendant sur des marketplaces et des revendeurs optent pour le traitement au brut, mais la réponse est défendable si votre analyse le soutient. Ce qui n'est pas défendable, c'est le glissement : comptabiliser les paiements de Lemon Squeezy au net la première moitié de l'année et les paiements de Paddle au brut la seconde moitié parce que les rapports du nouveau fournisseur ont rendu le brut plus facile. Choisissez une politique, consignez l'analyse de contrôle dans une note que votre auditeur pourra lire et appliquez-la de manière identique aux paiements des deux fournisseurs pour toute l'année.
Les cinq coutures où l'année se divise en deux
1. Les abonnements ne migrent pas ; les clients se réabonnent. Il n'existe aucune migration automatique de jetons entre les processeurs de paiement. Les cartes enregistrées ne peuvent généralement pas être exportées d'un 'merchant of record' sous une forme utilisable, prévoyez donc que les abonnés réintroduisent leurs coordonnées de paiement sur la nouvelle plateforme — ou confirmez par écrit, avant de vous engager, que le nouveau fournisseur peut déplacer les abonnements actifs et les cartes enregistrées pour vous. Tant que chaque client ne se réabonne pas, l'ancienne plateforme continue de lui facturer, ce qui signifie que les deux systèmes fonctionnent côte à côte pendant des mois et que la clôture de chaque mois rapproche deux flux de paiements.
2. Les prix hérités et les ancres de renouvellement doivent être reconstruits manuellement. Chaque abonnement actif comporte un prix, une date de renouvellement et souvent un forfait hérité qui n'est plus vendu. La nouvelle plateforme ne connaît rien à tout cela tant que vous ne le recréez pas : produits, prix, plans hérités détenus uniquement par les clients existants, comportement des essais, coupons, règles incluant les taxes et ancres de renouvellement. Si vous oubliez un prix hérité, un client fidèle est facturé au nouveau tarif — une catastrophe pour le service client qui enregistre également des revenus que vous devrez ensuite annuler.
3. Les plans annuels créent un basculement de revenus différés. Un client qui a acheté un forfait annuel de 1 200 $ en mars a payé l'ancien fournisseur, mais vous gagnez ce revenu mois par mois jusqu'en février suivant. À la date de basculement, une partie de cette trésorerie n'est toujours pas gagnée et reste sur votre bilan en tant que revenu différé, peu importe laquelle des plateformes gère les mois restants. Les rapports de la nouvelle plateforme ne montreront jamais cette dette — ils ne connaissent que les ventes effectuées via celle-ci — donc la migration doit porter le solde en avant explicitement, sinon votre revenu du second semestre est surévalué par de l'argent que vous avez déjà perçu.
4. Les remboursements et les rétrofacturations chevauchent le basculement. Un remboursement émis en août pour une vente réalisée en mai réside dans le système de l'ancien fournisseur, sous les anciennes règles de frais, tandis que le revenu qu'il annule a peut-être déjà été comptabilisé sur deux trimestres. Chaque fournisseur absorbe les rétrofacturations en tant que 'merchant of record', mais les écrit comptables — annulation du revenu, enregistrement de tout frais non remboursable, ajustement du paiement déjà reçu — atterrissent dans vos livres, et le format de rapport d'ajustement de chaque fournisseur est différent.
5. Le calendrier des paiements, la devise et les documents fiscaux changent tous en même temps. Les calendriers de paiement diffèrent selon le fournisseur, de sorte que les ventes d'une même semaine peuvent apparaître sur des relevés bancaires de mois différents avant et après le changement. Les vendeurs transfrontaliers sont confrontés à de nouvelles lignes de change et à de nouvelles décomptes de frais. Et chaque fournisseur déclare ses propres impôts sous ses propres immatriculations, tandis que les vendeurs américains peuvent recevoir des rapports de paiement séparés de chaque plateforme pour l'année. Rien de cela n'est une erreur ; ce sont deux systèmes corrects qui ne sont pas d'accord sur le format, et votre clôture doit les normaliser tous sur un plan comptable unique.
Le mode de migration sécurisé pour la finance
Traitez-les dans cet ordre et ne compressez pas l'exécution parallèle.
1. Fixez la date de basculement sur une frontière de période. Les basculements en milieu de mois divisent les périodes d'abonnement, les prorata et les lots de paiements sur la couture. Un basculement de fin de mois ou de fin de trimestre vous donne des populations claires avant et après et une clôture unique qui contient toute la transition.
2. Verrouillez et exportez tout depuis l'ancienne plateforme. Bloquez les périodes comptables que l'ancien fournisseur a déjà facturées. Exportez le catalogue de plans complet, chaque abonnement actif avec son prix et sa date de renouvellement, l'historique complet des factures et chaque rapport de paiement avec les ventilations des frais. Gardez le compte ancien en lecture seule, pas supprimé, pendant au moins un cycle d'audit complet — les auditeurs et les autorités fiscales posent des questions spécifiquement sur l'année de migration parce qu'ils s'attendent à la couture.
3. Recréez le catalogue de plans, y compris les plans que vous ne vendez plus. Les plans hérités et hérités doivent exister dans le nouveau système avant que le premier client migré ne se renouvelle sur celui-ci. Documentez chaque correspondance d'un ancien ID de plan à un nouveau ; ce tableau de correspondance est la piste d'audit qui explique pourquoi les factures de juillet diffèrent des factures de juin pour le même client.
4. Mettez les nouveaux clients sur la nouvelle plateforme en premier. Faites fonctionner le nouveau fournisseur en parallèle pour les nouvelles ventes pendant que les abonnements existants attendent leur renouvellement sur l'ancien, puis déplacez les cohortes aux limites naturelles — dates de renouvellement, fins de mois, jamais en milieu de cycle. Chaque cohorte reçoit son propre rapprochement avant que la suivante ne commence. Un basculement massif concentre chaque échec de réabonnement, chaque manquement à l'héritage et chaque cas limite de prorata en une seule clôture.
5. Cartographiez les deux rapports de paiement sur un seul plan comptable. Avant la première clôture incluant les deux fournisseurs, construisez la traduction : chaque ligne de frais, ligne fiscale, ajustement et code de remboursement dans chaque rapport correspond à l'un de vos comptes de grand livre. Les deux fournisseurs n'utiliseront jamais les mêmes étiquettes. Sans la cartographie, votre comptable l'inventera différemment chaque mois.
6. Régularisez explicitement les revenus différés. Rapproche l'état non gagné plan par plan à la date de basculement, et comptabilisez toute différence entre les registres de l'ancienne plateforme et votre grand livre comme un ajustement explicite avec une cause documentée — pas un ajustement arbitraire (plug). À partir du basculement, reconnaissez le solde restant selon le calendrier, quelle que soit la plateforme qui dessert le client.
À quoi ressemble le mois de basculement dans votre grand livre
Le lien comptable est simple une fois que vous séparez les deux fournisseurs avec un suivi des frais distinct au lieu de laisser les deux directement vers le revenu. Reconnaissez chaque paiement au brut — le paiement client complet comme revenu, la part du fournisseur comme dépense de vente — et continuez à reconnaître les soldes différés avant le basculement selon leur calendrier d'origine. La documentation Beancount couvre la syntaxe de grand livre utilisée ci-dessous si vous ne la connaissez pas.
Supposons qu'un client ait acheté un plan annuel de 1 200 $ via Lemon Squeezy à la mi-mars. Le paiement de mars est arrivé net des frais de 5 % plus 50 centimes (60,50 $), et au 30 juin vous avez reconnu quatre mois de revenus (400 $), laissant 800 $ non gagnés. Le 1er juillet est votre date de basculement, et un nouvel abonnement mensuel de 49 $ se vend via Paddle en juillet. Dans un grand livre en texte simple qui ressemble à ceci :
2026-01-01 open Income:SaaS:Subscriptions
2026-01-01 open Liabilities:Deferred-Revenue
2026-01-01 open Expenses:MoR-Fees:LemonSqueezy
2026-01-01 open Expenses:MoR-Fees:Paddle
2026-01-01 open Assets:Checking
2026-03-15 * "Vente de plan annuel via Lemon Squeezy, payeur a payé 1200.00"
Assets:Checking 1139.50 USD
Expenses:MoR-Fees:LemonSqueezy 60.50 USD
Liabilities:Deferred-Revenue -1200.00 USD
2026-06-30 * "Reconnaissance de la part de juin du plan annuel"
Liabilities:Deferred-Revenue 100.00 USD
Income:SaaS:Subscriptions -100.00 USD
2026-07-15 * "Vente de plan mensuel via Paddle, payeur a payé 49.00"
Assets:Checking 46.05 USD
Expenses:MoR-Fees:Paddle 2.95 USD
Income:SaaS:Subscriptions -49.00 USD
2026-07-31 * "Reconnaissance de la part de juillet du plan annuel avant le basculement"
Liabilities:Deferred-Revenue 100.00 USD
Income:SaaS:Subscriptions -100.00 USDTrois détails soutiennent toute la migration. Premièrement, les frais de chaque fournisseur sont inscrits dans leur propre sous-compte, de sorte que les totaux de fin d'année montrent exactement combien chaque plateforme vous a coûté et les deux barèmes de frais ne se mélangent jamais. Deuxièmement, l'écriture de reconnaissance de juillet pour la vente de mars n'est pas changée par le basculement — le revenu différé est votre passif, gagné selon votre calendrier, et il se moque de la plateforme qui a encaissé l'argent. Troisièmement, chaque écriture est liée à un rapport de paiement spécifique : le relevé de remise de Lemon Squeezy de mars pour le premier, le paiement de Paddle de juillet pour le troisième. Lorsque votre comptable demande comment les revenus de l'année ont été gagnés, chaque chiffre pointe vers les documents d'un seul fournisseur.
Clôturez la couture délibérément
La migration de 'merchant-of-record' est deux projets portant un seul nom : le déplacement de la facturation, que vos ingénieurs terminent en quelques semaines, et le déplacement des livres, avec lequel votre comptable vit pendant un an. Le projet de facturation se termine lorsque le dernier client se réabonne. Le projet de livres se termine lorsque chaque paiement des deux fournisseurs est lié à la banque, que chaque ligne de frais est mappée sur un plan comptable et que le solde de revenu différé traverse proprement la date de basculement, et que la note brut contre net dans votre dossier d'audit couvre les deux moitiés de l'année sous une seule politique. Planifiez le basculement sur une frontière de période, exécutez les nouvelles ventes sur la nouvelle plateforme pendant que les anciens abonnements attendent leur renouvellement, et gardez le système ancien lisible jusqu'à ce que les auditeurs aient vu l'année de migration. Faites cela, et le changement sera une note dans les états financiers de l'année prochaine au lieu d'une variance que personne ne peut expliquer.
