Je uitbetalingen van januari kwamen van Lemon Squeezy en je uitbetalingen van augustus komen van Paddle, en nu stelt je accountant een vraag die geen van beide dashboards op zichzelf kan beantwoorden: hoeveel abonnementsomzet heb je dit jaar nu werkelijk verdiend? De oude provider inde onder één kostenschema, één uitbetalingsritme en één set belastingfacturen die vanuit zijn eigen entiteiten werden uitgegeven. De nieuwe provider doet hetzelfde werk met andere rapporten, andere kostregels en andere papierwinkel. Daartussen zit een balans van uitgestelde omzet, een stapel jaarabonnementen die op het ene platform zijn verkocht en op het andere worden bediend, en een jaareindeafsluiting die twee onverenigbare grootboeken tot één geloofwaardige set boeken moet verbinden. Die verbinding — niet de API-integratie, die kost dagen — is waar merchant-of-record-migraties stilletjes falen.
Dit is op dit moment een actuele beslissing voor duizenden verkopers. Stripe nam Lemon Squeezy over in juli 2024, en de update van januari 2026 van Lemon Squeezy stelde dat de toekomst een eenvoudig migratiepad is naar Stripe Managed Payments, Stripe's eigen merchant-of-record-product. Er is geen deadline gepubliceerd en Lemon Squeezy werkt nog steeds, maar verkopers die niet volgens andermans tijdschema willen worden gemigreerd, beoordelen de onafhankelijken: Paddle en Polar, beide echte merchants of record tegen hetzelfde headline-tarief van 5 procent plus 50 cent. Ben je een van hen, dan is de factureringsoverstap het makkelijke deel. De boeken geloofwaardig houden gedurende die overstap is het echte project.
Wat een merchant of record feitelijk is op je boeken
Een merchant of record is de juridische verkoper van jouw product, niet slechts je betalingsverwerker. Wanneer een klant via Paddle, Polar of Lemon Squeezy koopt, staat de naam van de provider op het rekeningafschrift, wordt de belastingfactuur uitgegeven vanuit een van de eigen entiteiten van de provider, en behoren de btw- en omzetbelastingregistraties in Duitsland, Japan of Texas toe aan de provider in plaats van aan jou. De provider berekent, int, dient in en draagt de belasting af, absorbeert chargeback-risico en stuurt jou een uitbetaling voor de rest.
Die juridische structuur bepaalt hoe je boekhoudkundige gegevens eruitzien. De koperfactuur documenteert de verkoop van de provider aan jouw klant — het is hun factuur, niet de jouwe. Jouw kant van de transactie wordt gedocumenteerd door verkoperszijde-gegevens: een reverse invoice die jouw levering aan de provider beschrijft en remittance advice die elk uitbetalingsbedrag vastlegt. Jouw omzet is een uitbetaling, netto na de kosten van de provider, die aankomt volgens het schema van de provider in plaats van continu. De versie van die documenten van elke provider ziet er anders uit, en dat is precies waarom het draaien van twee ervan in één jaar je gegevens in tweeën splitst.
De bruto-versus-netto-keuze die je één keer moet maken
Voordat je een van beide platforms aanraakt, beslis je het ene boekhoudbeleid dat de migratie je dwingt te verdedigen: verantwoord je het volledige bedrag dat de klant heeft betaald als omzet (bruto), of alleen de uitbetaling die je hebt ontvangen (netto)?
Onder ASC 606 is dit de principal-versus-agent-vraag, en die wordt beantwoord door controle — niet door wie de factuur heeft uitgegeven of wiens naam op het rekeningafschrift staat. De richtlijn staat in ASC 606-10-55-36 tot en met 55-40: een entiteit is een principal als zij het gespecificeerde goed of de dienst beheerst voordat zij het aan de klant overdraagt, en verantwoordt de omzet bruto; als haar belofte slechts is om te regelen dat een andere partij het levert, is de entiteit een agent en verantwoordt zij alleen haar vergoeding of commissie netto. Voor een softwareleverancier die via een reseller-achtige merchant of record verkoopt, beslist dezelfde analyse wie je klant is. Als je klant de eindgebruiker is, is de omzet de eindgebruikersprijs en zijn de kosten van de provider een verkoopkost onder de omzetregel. Als je klant de provider zelf is, is de omzet de prijs die de provider jou betaalde — de uitbetaling.
De brutowinst is in beide gevallen identiek. De gerapporteerde omzet niet, en dat getal voedt je groeicijfer, je omzetmultiples bij een financieringsronde of overname, en elke periode-op-periode-vergelijking die je board leest. De meeste softwareleveranciers die via marketplaces en resellers verkopen, komen uit op bruto-verantwoording, maar beide antwoorden zijn verdedigbaar als je analyse ze ondersteunt. Wat niet verdedigbaar is, is afdwalen: Lemon Squeezy-uitbetalingen netto boeken in de eerste helft van het jaar en Paddle-uitbetalingen bruto in de tweede helft omdat de rapporten van de nieuwe provider bruto makkelijker maakten. Kies één beleid, schrijf de controleanalyse op in een memo die je auditor kan lezen, en pas het identiek toe op de uitbetalingen van beide providers voor het hele jaar.
De vijf naden waar het jaar in tweeën splitst
1. Abonnementen migreren niet; klanten herinschrijven zich. Er is geen automatische tokenmigratie tussen betalingsverwerkers. Opgeslagen kaarten kunnen over het algemeen niet in bruikbare vorm worden geëxporteerd uit een merchant of record, dus plan dat abonnees opnieuw hun betalingsgegevens invoeren op het nieuwe platform — of bevestig schriftelijk, voordat je je vastlegt, dat de nieuwe provider actieve abonnementen en opgeslagen kaarten voor je kan overzetten. Totdat elke klant zich opnieuw heeft ingeschreven, blijft het oude platform hen factureren, wat betekent dat de twee systemen maandenlang naast elkaar draaien en elke maandafsluiting twee uitbetalingsstromen reconcileert.
2. Grandfathered prijzen en verlengingsankers moeten handmatig worden herbouwd. Elk actief abonnement draagt een prijs, een verlengingsdatum en vaak een grandfathered plan dat niet meer wordt verkocht. Het nieuwe platform weet hier niets van totdat je het opnieuw aanmaakt: producten, prijzen, legacy-plannen die alleen nog door bestaande klanten worden gehouden, trial-gedrag, kortingsbonnen, belasting-inclusief-regels en verlengingsankers. Mis je een grandfathered prijs, dan wordt een trouwe klant het nieuwe tarief in rekening gebracht — een supportramp die ook omzet boekt die je vervolgens moet terugdraaien.
3. Jaarabonnementen creëren een cutover van uitgestelde omzet. Een klant die in maart een jaarabonnement van $1.200 kocht, betaalde de oude provider, maar je verdient die omzet maand voor maand tot en met de volgende februari. Op de cutoverdatum is een deel van dat geld nog niet verdiend, en het blijft op je balans staan als uitgestelde omzet, ongeacht welk platform de resterende maanden bedient. De rapporten van het nieuwe platform zullen die verplichting nooit tonen — het weet alleen van verkopen die via hem zijn gedaan — dus de migratie moet het saldo expliciet overdragen, anders is je omzet in de tweede helft te hoog voorgesteld met geld dat je al hebt geïnd.
4. Terugbetalingen en chargebacks overspannen de cutover. Een terugbetaling die in augustus wordt gedaan voor een verkoop uit mei, leeft in het systeem van de oude provider, onder de oude kostregels, terwijl de omzet die zij terugdraait mogelijk al over twee kwartalen is verantwoord. Elke provider absorbeert chargebacks als merchant of record, maar de boekingen — omzet terugdraaien, eventuele niet-terugbetaalbare kosten boeken, de uitbetaling die je al hebt ontvangen aanpassen — landen in jouw boeken, en de aanpassingsrapporten van elke provider formatteren ze anders.
5. Uitbetalingstiming, valuta en belastingpapierwinkel veranderen allemaal tegelijk. Uitbetalingsschema's verschillen per provider, dus de verkopen van dezelfde week kunnen voor en na de wissel in bankafschriften van verschillende maanden landen. Grensoverschrijdende verkopers krijgen te maken met nieuwe valutakoersregels en nieuwe kostenspecificaties. En elke provider rapporteert zijn eigen belastingaangiften onder zijn eigen registraties, terwijl Amerikaanse verkopers mogelijk aparte uitbetalingsrapportages van elk platform voor het jaar ontvangen. Niets hiervan zijn fouten; het zijn twee correcte systemen die het oneens zijn over het formaat, en je afsluiting moet ze allemaal normaliseren naar één rekeningschema.
Het finance-veilige migratiedraaiboek
Werk deze op volgorde af, en comprimeer de parallelle run niet.
1. Stel de cutoverdatum vast op een periodegrens. Cutovers midden in de maand splitsen abonnementsperioden, pro rata-berekeningen en uitbetalingsbatches over de naad. Een cutover aan het einde van de maand of het kwartaal geeft je schone populaties voor en na en één afsluiting die de hele overgang bevat.
2. Bevries en exporteer alles van het oude platform. Vergrendel de boekhoudperioden die de oude provider al heeft gefactureerd. Exporteer de volledige plannencatalogus, elk actief abonnement met zijn prijs en verlengingsdatum, de volledige factuurhistorie en elk uitbetalingsrapport met kostenspecificaties. Houd het oude account read-only, niet verwijderd, voor ten minste een volledige auditcyclus — auditors en belastingautoriteiten vragen specifiek naar het migratiejaar omdat ze de naad verwachten.
3. Herbouw de plannencatalogus, inclusief plannen die je niet meer verkoopt. Legacy- en grandfathered plannen moeten in het nieuwe systeem bestaan voordat de eerste gemigreerde klant daar verlengt. Documenteer elke mapping van een oud plan-ID naar een nieuw; die mappingtabel is het auditspoor dat verklaart waarom juli-facturen er anders uitzien dan juni-facturen voor dezelfde klant.
4. Zet nieuwe klanten eerst op het nieuwe platform. Draai de nieuwe provider parallel voor nieuwe verkopen terwijl bestaande abonnementen naar verlenging doorlopen op de oude, en verplaats cohorten vervolgens op natuurlijke grenzen — verlengingsdata, maandeinden, nooit midden in een cyclus. Elk cohort krijgt zijn eigen reconciliatie voordat het volgende begint. Een big-bang-cutover concentreert elke herinschrijvingsfout, elke grandfathered-misser en elk pro rata-randgeval in één afsluiting.
5. Map beide uitbetalingsrapporten op één rekeningschema. Voordat de eerste afsluiting die beide providers bevat plaatsvindt, bouw je de vertaling: elke kostregel, belastingregel, aanpassing en terugbetalingscode op elk rapport mapt op een van je grootboekrekeningen. De twee providers zullen nooit dezelfde labels gebruiken. Zonder de mapping verzint je boekhouder hem elke maand anders.
6. Zuiver de uitgestelde omzet expliciet af. Reconcilieer het onverdiende saldo plan voor plan op de cutoverdatum, en boek elk verschil tussen de gegevens van het oude platform en je grootboek als een expliciete aanpassing met een gedocumenteerde oorzaak — geen plug. Verantwoord vanaf de cutover het resterende saldo volgens schema, ongeacht welk platform de klant bedient.
Hoe de cutovermaand er in je grootboek uitziet
De boekhoudkundige verbinding is eenvoudig zodra je de twee providers scheidt met afzonderlijke kostentracking in plaats van beide rechtstreeks naar omzet te boeken. Verantwoord elke uitbetaling bruto — de volledige klantbetaling als omzet, de kosten van de provider als verkoopkost — en blijf pre-cutover uitgestelde saldi volgens hun oorspronkelijke schema verantwoorden. De Beancount-documentatie behandelt de hieronder gebruikte grootboeksyntaxis als iets daarvan onbekend is.
Stel dat een klant medio maart een jaarabonnement van $1.200 kocht via Lemon Squeezy. De uitbetaling van maart kwam binnen netto na de kosten van 5 procent plus 50 cent ($60,50), en per 30 juni heb je vier maanden omzet verantwoord ($400), waardoor $800 onverdiend overblijft. 1 juli is je cutoverdatum, en in juli wordt een nieuw maandabonnement van $49 via Paddle verkocht. In een plain-text-grootboek ziet dat er zo uit:
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 * "Annual plan sale via Lemon Squeezy, buyer paid 1200.00"
Assets:Checking 1139.50 USD
Expenses:MoR-Fees:LemonSqueezy 60.50 USD
Liabilities:Deferred-Revenue -1200.00 USD
2026-06-30 * "Recognize June portion of annual plan"
Liabilities:Deferred-Revenue 100.00 USD
Income:SaaS:Subscriptions -100.00 USD
2026-07-15 * "Monthly plan sale via Paddle, buyer paid 49.00"
Assets:Checking 46.05 USD
Expenses:MoR-Fees:Paddle 2.95 USD
Income:SaaS:Subscriptions -49.00 USD
2026-07-31 * "Recognize July portion of pre-cutover annual plan"
Liabilities:Deferred-Revenue 100.00 USD
Income:SaaS:Subscriptions -100.00 USDDrie details dragen de hele migratie. Ten eerste worden de kosten van elke provider op zijn eigen subrekening geboekt, zodat de jaareindetotalen precies tonen wat elk platform je heeft gekost en de twee kostenschema's zich nooit vermengen. Ten tweede wordt de verantwoordingsboeking van juli voor de verkoop van maart niet beïnvloed door de cutover — uitgestelde omzet is jouw verplichting, verdiend volgens jouw schema, en het maakt niet uit welk platform het geld heeft geïnd. Ten derde sluit elke boeking aan op een specifiek uitbetalingsrapport: de remittance advice van Lemon Squeezy van maart voor de eerste, de Paddle-uitbetaling van juli voor de derde. Wanneer je accountant vraagt hoe de omzet van het jaar is verdiend, wijst elk getal naar precies één papierwinkel van één provider.
Sluit de naad bewust
Een merchant-of-record-migratie zijn twee projecten onder één naam: de facturering verplaatsen, wat je engineers in weken afronden, en de boeken verplaatsen, waar je accountant een jaar lang mee leeft. Het factureringsproject eindigt wanneer de laatste klant zich opnieuw heeft ingeschreven. Het boekenproject eindigt wanneer elke uitbetaling van beide providers aansluit op de bank, elke kostregel op één rekeningschema mapt, het saldo van uitgestelde omzet schoon over de cutoverdatum wandelt, en de bruto-versus-netto-memo in je auditdossier beide helften van het jaar onder één beleid dekt. Plan de cutover op een periodegrens, draai nieuwe verkopen op het nieuwe platform terwijl oude abonnementen naar verlenging doorlopen, en houd het oude systeem leesbaar totdat de auditors het migratiejaar hebben gezien. Doe dat, en de wissel is een voetnoot in de financiële overzichten van volgend jaar in plaats van de variantie die niemand kan verklaren.
