Your January payouts came from Lemon Squeezy and your August payouts come from Paddle, and now your accountant is asking a question neither dashboard can answer on its own: how much subscription revenue did you actually earn this year? The old provider collected under one fee schedule, one payout cadence, and one set of tax invoices issued from its own entities. The new provider does the same job with different reports, different fee lines, and different paperwork. Between them sits a deferred-revenue balance, a stack of annual plans sold on one platform and serviced on another, and a year-end close that has to stitch two incompatible ledgers into one believable set of books. That stitching — not the API integration, which takes days — is where merchant-of-record migrations quietly fail.
This is a live decision for thousands of sellers right now. Stripe acquired Lemon Squeezy in July 2024, and Lemon Squeezy's January 2026 update said its future is an easy migration path to Stripe Managed Payments, Stripe's own merchant-of-record product. No deadline has been published and Lemon Squeezy still works, but sellers who do not want to be migrated on someone else's timetable are evaluating the independents: Paddle and Polar, both genuine merchants of record at the same 5 percent plus 50 cents headline rate. If you are one of them, the billing switch is the easy part. Keeping the books believable through it is the real project.
What a merchant of record actually is on your books
A merchant of record is the legal seller of your product, not just your payment processor. When a customer buys through Paddle, Polar, or Lemon Squeezy, the card statement names the provider, the tax invoice is issued from one of the provider's own entities, and the sales-tax and VAT registrations in Germany, Japan, or Texas belong to the provider rather than to you. The provider calculates, collects, files, and remits the tax, absorbs chargeback liability, and sends you a payout for the rest.
That legal structure decides what your accounting records look like. The buyer invoice documents the provider's sale to your customer — it is their invoice, not yours. Your side of the transaction is documented by seller-side records: a reverse invoice describing your supply to the provider and remittance advice recording each payout amount. Your revenue is a payout, net of the provider's fee, arriving on the provider's schedule rather than continuously. Every provider's version of those documents looks different, which is exactly why running two of them in one year splits your records in two.
The gross-versus-net decision you must make once
Before you touch either platform, settle the one accounting policy the migration forces you to defend: do you recognize the full amount the customer paid as revenue (gross), or only the payout you received (net)?
Under ASC 606, this is the principal-versus-agent question, and it is answered by control — not by who issued the invoice or whose name is on the card statement. The guidance sits in ASC 606-10-55-36 through 55-40: an entity is a principal if it controls the specified good or service before it transfers to the customer, and reports revenue gross; if its promise is only to arrange for another party to provide it, the entity is an agent and reports only its fee or commission net. For a software vendor selling through a reseller-style merchant of record, the same analysis decides who your customer is. If your customer is the end user, revenue is the end-user price and the provider's cut is a selling cost below the revenue line. If your customer is the provider itself, revenue is the price the provider paid you — the payout.
Gross profit is identical either way. Reported revenue is not, and that number feeds your growth rate, your revenue multiples in a fundraise or acquisition, and every period-over-period comparison your board reads. Most software vendors selling through marketplaces and resellers land on gross treatment, but either answer is defensible if your analysis supports it. What is not defensible is drifting: booking Lemon Squeezy payouts net in the first half of the year and Paddle payouts gross in the second half because the new provider's reports made gross easier. Pick one policy, write down the control analysis in a memo your auditor can read, and apply it identically to both providers' payouts for the whole year.
The five seams where the year splits in two
1. Subscriptions do not migrate; customers re-subscribe. There is no automatic token migration between payment processors. Saved cards generally cannot be exported from a merchant of record in usable form, so plan for subscribers to re-enter payment details on the new platform — or confirm in writing, before you commit, that the new provider can move active subscriptions and saved cards for you. Until each customer re-subscribes, the old platform keeps billing them, which means the two systems run side by side for months and every month's close reconciles two payout streams.
2. Grandfathered prices and renewal anchors must be rebuilt by hand. Every active subscription carries a price, a renewal date, and often a grandfathered plan no longer sold. The new platform knows none of this until you recreate it: products, prices, legacy plans held only by existing customers, trial behavior, coupons, tax-inclusive rules, and renewal anchors. Miss a grandfathered price and a loyal customer gets charged the new rate — a support disaster that also books revenue you then have to reverse.
3. Annual plans create a deferred-revenue cutover. A customer who bought a $1,200 annual plan in March paid the old provider, but you earn that revenue month by month through the following February. At the cutover date, part of that cash is still unearned, and it stays on your balance sheet as deferred revenue no matter which platform services the remaining months. The new platform's reports will never show that liability — it only knows about sales made through it — so the migration must carry the balance forward explicitly or your second-half revenue is overstated by money you already collected.
4. Refunds and chargebacks straddle the cutover. A refund issued in August for a sale made in May lives in the old provider's system, under the old fee rules, while the revenue it reverses may already have been recognized across two quarters. Each provider absorbs chargebacks as merchant of record, but the accounting entries — reversing revenue, recording any non-refundable fee, adjusting the payout you already received — land in your books, and each provider's adjustment reports format them differently.
5. Payout timing, currency, and tax paperwork all change at once. Payout schedules differ by provider, so the same week's sales can land in different months' bank statements before and after the switch. Cross-border sellers face new foreign-exchange lines and new fee breakdowns. And each provider reports its own tax filings under its own registrations, while US sellers may receive separate payout reporting from each platform for the year. None of these are errors; they are two correct systems disagreeing in format, and your close has to normalize all of them onto one chart of accounts.
The finance-safe migration playbook
Work through these in order, and do not compress the parallel run.
1. Set the cutover date on a period boundary. Mid-month cutovers split subscription periods, proration, and payout batches across the seam. A month-end or quarter-end cutover gives you clean before-and-after populations and one close that contains the entire transition.
2. Freeze and export everything from the old platform. Lock the accounting periods the old provider already billed. Export the full plan catalog, every active subscription with its price and renewal date, the complete invoice history, and every payout report with fee breakdowns. Keep the old account read-only, not deleted, for at least a full audit cycle — auditors and tax authorities ask about the migration year specifically because they expect the seam.
3. Recreate the plan catalog, including plans you no longer sell. Legacy and grandfathered plans must exist in the new system before the first migrated customer renews there. Document every mapping from an old plan ID to a new one; that mapping table is the audit trail that explains why July invoices look different from June invoices for the same customer.
4. Put new customers on the new platform first. Run the new provider in parallel for new sales while existing subscriptions ride to renewal on the old one, then move cohorts at natural boundaries — renewal dates, month-ends, never mid-cycle. Each cohort gets its own reconciliation before the next begins. A big-bang cutover concentrates every re-subscription failure, every grandfathering miss, and every proration edge case into a single close.
5. Map both payout reports onto one chart of accounts. Before the first close that includes both providers, build the translation: each fee line, tax line, adjustment, and refund code on each report maps to one of your ledger accounts. The two providers will never use the same labels. Without the mapping, your bookkeeper invents it differently every month.
6. True up deferred revenue explicitly. Reconcile the unearned balance plan by plan at the cutover date, and book any difference between the old platform's records and your ledger as an explicit adjustment with a documented cause — not a plug. From the cutover forward, recognize the remaining balance on schedule regardless of which platform services the customer.
How the cutover month looks in your ledger
The bookkeeping connection is straightforward once you separate the two providers with distinct fee tracking instead of letting both post straight to revenue. Recognize each payout gross — the full customer payment as revenue, the provider's cut as a selling expense — and keep recognizing pre-cutover deferred balances on their original schedule. The Beancount documentation covers the ledger syntax used below if any of it is unfamiliar.
Suppose a customer bought a $1,200 annual plan through Lemon Squeezy in mid-March. The March payout arrived net of the 5 percent plus 50 cent fee ($60.50), and by June 30 you have recognized four months of revenue ($400), leaving $800 unearned. July 1 is your cutover date, and a new $49 monthly subscription sells through Paddle in July. In a plain-text ledger that looks like this:
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 USDThree details carry the whole migration. First, each provider's fees post to its own subaccount, so the year-end totals show exactly what each platform cost you and the two fee schedules never mingle. Second, the July recognition entry for the March sale is unchanged by the cutover — deferred revenue is your liability, earned on your schedule, and it does not care which platform collected the cash. Third, every entry ties to a specific payout report: the March Lemon Squeezy remittance advice for the first, the July Paddle payout for the third. When your accountant asks how the year's revenue was earned, each number points at exactly one provider's paperwork.
Close the seam deliberately
A merchant-of-record migration is two projects wearing one name: moving the billing, which your engineers finish in weeks, and moving the books, which your accountant lives with for a year. The billing project ends when the last customer re-subscribes. The books project ends when every payout from both providers ties to the bank, every fee line maps to one chart of accounts, the deferred-revenue balance walks cleanly across the cutover date, and the gross-versus-net memo in your audit file covers both halves of the year under one policy. Schedule the cutover on a period boundary, run new sales on the new platform while old subscriptions ride to renewal, and keep the old system readable until the auditors have seen the migration year. Do that, and the switch is a footnote in next year's financials instead of the variance nobody can explain.
