پرداخت‌های ژانویهٔ شما از Lemon Squeezy آمده و پرداخت‌های اوت شما از Paddle، و حالا حسابدارتان سؤالی می‌پرسد که هیچ‌کدام از این دو داشبورد به‌تنهایی نمی‌تواند پاسخ دهد: امسال واقعاً چقدر درآمد اشتراک کسب کردید؟ ارائه‌دهندهٔ قدیمی بر اساس یک برنامهٔ کارمزد، یک دورهٔ پرداخت، و مجموعه‌ای از فاکتورهای مالیاتی صادرشده از نهادهای حقوقی خودش عمل می‌کرد. ارائه‌دهندهٔ جدید همان کار را با گزارش‌های متفاوت، ردیف‌های کارمزد متفاوت و مستندات متفاوت انجام می‌دهد. میان آن دو، یک ماندهٔ درآمد معوق قرار دارد، انبوهی از طرح‌های سالانه که در یک پلتفرم فروخته شده و در پلتفرم دیگر خدمات می‌گیرند، و یک بستن حساب‌های پایان سال که باید دو دفتر کل ناسازگار را به یک مجموعهٔ قابل‌اعتماد از دفاتر بدوزد. همین دوخت است — نه یکپارچه‌سازی API که چند روز طول می‌کشد — که مهاجرت‌های ثبت‌کنندهٔ فروش آرام‌آرام شکست می‌خورند.
این امروز یک تصمیم زنده برای هزاران فروشنده است. Stripe در ژوئیهٔ ۲۰۲۴ Lemon Squeezy را خرید، و به‌روزرسانی ژانویهٔ ۲۰۲۶ Lemon Squeezy گفت که آیندهٔ آن یک مسیر مهاجرت آسان به Stripe Managed Payments است، محصول ثبت‌کنندهٔ فروش خود Stripe. هیچ مهلتی منتشر نشده و Lemon Squeezy هنوز کار می‌کند، اما فروشندگانی که نمی‌خواهند طبق برنامهٔ زمانی دیگری مهاجرت داده شوند، در حال ارزیابی مستقل‌ها هستند: Paddle و Polar، که هر دو ثبت‌کنندهٔ فروش واقعی با همان نرخ سرصفحه‌ای ۵ درصد به‌علاوهٔ ۵۰ سنت هستند. اگر شما یکی از آن‌ها هستید، تغییر سیستم صورتحساب بخش آسان ماجراست. قابل‌اعتماد نگه‌داشتن دفاتر در طول آن، پروژهٔ واقعی است.
ثبت‌کنندهٔ فروش در دفاتر شما واقعاً چیست
ثبت‌کنندهٔ فروش، فروشندهٔ قانونی محصول شماست، نه فقط پردازشگر پرداخت شما. وقتی مشتری از طریق Paddle، Polar یا Lemon Squeezy خرید می‌کند، صورتحساب بانکی نام ارائه‌دهنده را نشان می‌دهد، فاکتور مالیاتی از یکی از نهادهای حقوقی خودِ ارائه‌دهنده صادر می‌شود، و ثبت‌های مالیات بر فروش و مالیات بر ارزش افزوده در آلمان، ژاپن یا تگزاس متعلق به ارائه‌دهنده است نه شما. ارائه‌دهنده مالیات را محاسبه، دریافت، اظهار و پرداخت می‌کند، مسئولیت بازپرداخت (chargeback) را می‌پذیرد، و بقیه را به‌صورت پرداخت به شما می‌فرستد.
همین ساختار حقوقی تعیین می‌کند که سوابق حسابداری شما چه شکلی داشته باشند. فاکتور خریدار، فروش ارائه‌دهنده به مشتری شما را مستند می‌کند — این فاکتور آن‌هاست، نه شما. سمت شما از معامله با سوابق سمت فروشنده مستند می‌شود: یک فاکتور معکوس که عرضهٔ شما به ارائه‌دهنده را توصیف می‌کند و اعلامیهٔ حواله که مبلغ هر پرداخت را ثبت می‌کند. درآمد شما همان پرداخت است، خالص پس از کسر کارمزد ارائه‌دهنده، که طبق برنامهٔ زمانی ارائه‌دهنده می‌رسد نه به‌صورت پیوسته. نسخهٔ هر ارائه‌دهنده از این اسناد متفاوت است، و دقیقاً به همین دلیل اجرای دو مورد از آن‌ها در یک سال، سوابق شما را به دو بخش تقسیم می‌کند.
تصمیم ناخالص در برابر خالص که باید یک‌بار برای همیشه بگیرید
پیش از دست زدن به هر یک از دو پلتفرم، تنها سیاست حسابداری‌ای را که مهاجرت شما را مجبور به دفاع از آن می‌کند مشخص کنید: آیا کل مبلغی که مشتری پرداخت کرده را به‌عنوان درآمد شناسایی می‌کنید (ناخالص)، یا فقط پرداختی که دریافت کرده‌اید را (خالص)?
بر اساس ASC 606، این همان پرسش اصل در برابر نماینده است و با کنترل پاسخ داده می‌شود — نه با اینکه چه کسی فاکتور را صادر کرده یا نام چه کسی روی صورتحساب بانکی است. راهنما در ASC 606-10-55-36 تا 55-40 آمده است: یک واحد تجاری اصل است اگر کالا یا خدمت مشخص‌شده را پیش از انتقال به مشتری کنترل کند و درآمد را ناخالص گزارش دهد؛ اگر تعهدش فقط ترتیب دادن برای ارائهٔ آن توسط طرف دیگر باشد، واحد تجاری نماینده است و فقط کارمزد یا کمیسیون خود را خالص گزارش می‌دهد. برای یک فروشندهٔ نرم‌افزار که از طریق یک ثبت‌کنندهٔ فروش به سبک فروشندهٔ مجدد می‌فروشد، همین تحلیل تعیین می‌کند مشتری شما کیست. اگر مشتری شما کاربر نهایی است، درآمد همان قیمت کاربر نهایی است و سهم ارائه‌دهنده یک هزینهٔ فروش زیر خط درآمد است. اگر مشتری شما خودِ ارائه‌دهنده است، درآمد همان قیمتی است که ارائه‌دهنده به شما پرداخته — یعنی پرداخت.
سود ناخالص در هر دو حالت یکسان است. درآمد گزارش‌شده یکسان نیست، و همین عدد به نرخ رشد شما، به ضرایب درآمدتان در یک دور جذب سرمایه یا خرید، و به هر مقایسهٔ دوره‌به‌دوره‌ای که هیئت‌مدیرهٔ شما می‌خواند، راه می‌یابد. بیشتر فروشندگان نرم‌افزار که از طریق بازارگاه‌ها و فروشندگان مجدد می‌فروشند به درمان ناخالص می‌رسند، اما هر دو پاسخ در صورتی که تحلیلتان پشتیبان آن باشد قابل دفاع است. آنچه قابل دفاع نیست، سرگردانی است: ثبت پرداخت‌های Lemon Squeezy خالص در نیمهٔ اول سال و پرداخت‌های Paddle ناخالص در نیمهٔ دوم چون گزارش‌های ارائه‌دهندهٔ جدید کار ناخالص را آسان‌تر کرده بود. یک سیاست را انتخاب کنید، تحلیل کنترل را در یادداشتی بنویسید که حسابرس شما بتواند بخواند، و آن را به‌طور یکسان بر پرداخت‌های هر دو ارائه‌دهنده برای تمام سال اعمال کنید.
پنج درزی که سال را به دو نیم می‌شکند
۱. اشتراک‌ها مهاجرت نمی‌کنند؛ مشتریان دوباره مشترک می‌شوند. هیچ انتقال خودکار توکن بین پردازشگرهای پرداخت وجود ندارد. کارت‌های ذخیره‌شده عموماً به‌صورت قابل‌استفاده از یک ثبت‌کنندهٔ فروش قابل استخراج نیستند، پس برای آن برنامه‌ریزی کنید که مشترکان جزئیات پرداخت را در پلتفرم جدید دوباره وارد کنند — یا پیش از تعهد، به‌صورت کتبی تأیید کنید که ارائه‌دهندهٔ جدید می‌تواند اشتراک‌های فعال و کارت‌های ذخیره‌شده را برای شما منتقل کند. تا زمانی که هر مشتری دوباره مشترک شود، پلتفرم قدیمی به‌صورت آن‌ها ادامه می‌دهد، یعنی دو سیستم ماه‌ها کنار هم کار می‌کنند و بستن حساب‌های هر ماه دو جریان پرداخت را تطبیق می‌دهد.
۲. قیمت‌های تثبیت‌شده و لنگرهای تمدید باید دستی بازسازی شوند. هر اشتراک فعال یک قیمت، یک تاریخ تمدید، و اغلب یک طرح تثبیت‌شدهٔ دیگر‌فروش‌نشده را با خود دارد. پلتفرم جدید هیچ‌کدام از این‌ها را نمی‌داند تا شما بازسازی کنید: محصولات، قیمت‌ها، طرح‌های میراثی که فقط مشتریان فعلی دارند، رفتار دورهٔ آزمایشی، کوپن‌ها، قواعد شامل مالیات، و لنگرهای تمدید. اگر یک قیمت تثبیت‌شده را از دست بدهید، یک مشتری وفادار با نرخ جدید شارژ می‌شود — یک فاجعهٔ پشتیبانی که درآمدی را هم ثبت می‌کند که بعداً باید معکوس کنید.
۳. طرح‌های سالانه یک انتقال درآمد معوق ایجاد می‌کنند. مشتری‌ای که در مارس یک طرح سالانهٔ ۱٬۲۰۰ دلاری خریده، به ارائه‌دهندهٔ قدیمی پرداخت کرده، اما شما آن درآمد را ماه‌به‌ماه تا فوریهٔ بعد کسب می‌کنید. در تاریخ تغییر، بخشی از آن وجه نقد هنوز کسب‌نشده است و روی ترازنامهٔ شما به‌عنوان درآمد معوق باقی می‌ماند، بدون توجه به اینکه کدام پلتفرم ماه‌های باقی‌مانده را خدمات می‌دهد. گزارش‌های پلتفرم جدید هرگز آن بدهی را نشان نخواهند داد — آن فقط فروش‌های انجام‌شده از طریق خودش را می‌شناسد — پس مهاجرت باید این مانده را صریحاً به جلو حمل کند، وگرنه درآمد نیمهٔ دوم شما با پولی که قبلاً جمع کرده‌اید بیش‌نمایی می‌شود.
۴. بازپرداخت‌ها و chargebackها از تاریخ تغییر عبور می‌کنند. بازپرداختی که در اوت برای فروشی در مه صادر می‌شود، در سیستم ارائه‌دهندهٔ قدیمی و تحت قواعد کارمزد قدیمی زندگی می‌کند، در حالی که درآمدی که معکوس می‌کند ممکن است پیش‌تر در طول دو فصل شناسایی شده باشد. هر ارائه‌دهنده به‌عنوان ثبت‌کنندهٔ فروش chargebackها را جذب می‌کند، اما ثبت‌های حسابداری — معکوس کردن درآمد، ثبت هر کارمزد غیرقابل‌بازگشت، تعدیل پرداختی که قبلاً دریافت کرده‌اید — در دفاتر شما فرود می‌آیند، و گزارش‌های تعدیل هر ارائه‌دهنده آن‌ها را متفاوت قالب‌بندی می‌کند.
۵. زمان‌بندی پرداخت، ارز، و مستندات مالیاتی همه یک‌جا تغییر می‌کنند. برنامه‌های پرداخت از ارائه‌دهنده‌ای به ارائه‌دهندهٔ دیگر متفاوت است، پس فروش‌های یک هفته ممکن است پیش و پس از تغییر در صورت‌حساب‌های بانکی ماه‌های متفاوت فرود بیایند. فروشندگان فرامرزی با ردیف‌های جدید ارز خارجی و تفکیک کارمزدهای جدید روبه‌رو می‌شوند. و هر ارائه‌دهنده اظهارنامه‌های مالیاتی خودش را تحت ثبت‌های خودش گزارش می‌کند، در حالی که فروشندگان آمریکایی ممکن است برای آن سال گزارش پرداخت جداگانه‌ای از هر پلتفرم دریافت کنند. هیچ‌کدام از این‌ها خطا نیستند؛ این‌ها دو سیستم صحیح هستند که در قالب اختلاف دارند، و بستن حساب‌های شما باید همهٔ آن‌ها را روی یک دفتر حساب‌ها یکسان‌سازی کند.
کتاب راهنمای مهاجرت امن برای امور مالی
این مراحل را به ترتیب انجام دهید، و اجرای موازی را فشرده نکنید.
۱. تاریخ تغییر را روی مرز یک دوره تنظیم کنید. تغییرهای میان‌ماه دوره‌های اشتراک، تقسیم‌بندی نسبی و دسته‌های پرداخت را در درز تقسیم می‌کنند. تغییر در پایان ماه یا پایان فصل به شما جمعیت‌های پیش و پس از تغییرِ تمیز و یک بستن حساب که تمام انتقال را در بر می‌گیرد می‌دهد.
۲. همه‌چیز را از پلتفرم قدیمی قفل و صادر کنید. دوره‌های حسابداری‌ای را که ارائه‌دهندهٔ قدیمی قبلاً صورتحساب کرده قفل کنید. کل کاتالوگ طرح‌ها، هر اشتراک فعال با قیمت و تاریخ تمدیدش، تاریخچهٔ کامل فاکتورها، و هر گزارش پرداخت با تفکیک کارمزدها را صادر کنید. حساب قدیمی را فقط‌خواندنی نگه دارید، نه حذف‌شده، برای حداقل یک چرخهٔ حسابرسی کامل — حسابرسان و مراجع مالیاتی به‌طور خاص دربارهٔ سال مهاجرت می‌پرسند چون انتظار این درز را دارند.
۳. کاتالوگ طرح‌ها را بازسازی کنید، از جمله طرح‌هایی که دیگر نمی‌فروشید. طرح‌های میراثی و تثبیت‌شده باید پیش از آنکه اولین مشتری مهاجرت‌کرده در سیستم جدید تمدید کند، در آن وجود داشته باشند. هر نگاشت از شناسهٔ طرح قدیمی به جدید را مستند کنید؛ آن جدول نگاشت همان رد حسابرسی است که توضیح می‌دهد چرا فاکتورهای ژوئیه برای همان مشتری با فاکتورهای ژوئن متفاوت به نظر می‌رسند.
۴. مشتریان جدید را ابتدا روی پلتفرم جدید ببرید. ارائه‌دهندهٔ جدید را برای فروش‌های جدید به‌صورت موازی اجرا کنید در حالی که اشتراک‌های موجود در پلتفرم قدیمی تا تمدید پیش می‌روند، سپس گروه‌ها را در مرزهای طبیعی جابه‌جا کنید — تاریخ‌های تمدید، پایان ماه‌ها، هرگز در میانهٔ چرخه. هر گروه تطبیق خودش را پیش از شروع گروه بعدی دریافت می‌کند. یک تغییر یک‌بارهٔ کل‌نگر، هر شکست در اشتراک مجدد، هر از دست رفتن طرح تثبیت‌شده، و هر حالت خاص تقسیم‌بندی نسبی را در یک بستن حساب متمرکز می‌کند.
۵. هر دو گزارش پرداخت را روی یک دفتر حساب‌ها نگاشت کنید. پیش از اولین بستن حسابی که هر دو ارائه‌دهنده را در بر می‌گیرد، ترجمه را بسازید: هر ردیف کارمزد، ردیف مالیات، تعدیل، و کد بازپرداخت در هر گزارش به یکی از حساب‌های دفتر کل شما نگاشت می‌شود. دو ارائه‌دهنده هرگز از برچسب‌های یکسان استفاده نخواهند کرد. بدون نگاشت، حسابدار شما هر ماه آن را متفاوت اختراع می‌کند.
۶. درآمد معوق را صریحاً تعدیل کنید. ماندهٔ کسب‌نشده را در تاریخ تغییر طرح‌به‌طرح تطبیق دهید، و هر تفاوت میان سوابق پلتفرم قدیمی و دفتر کل خود را به‌عنوان یک تعدیل صریح با علت مستند ثبت کنید — نه یک عدد پرکننده. از تاریخ تغییر به بعد، ماندهٔ باقی‌مانده را طبق برنامه شناسایی کنید، بدون توجه به اینکه کدام پلتفرم به مشتری خدمات می‌دهد.
ماه تغییر در دفتر کل شما چگونه به نظر می‌رسد
ارتباط حسابداری وقتی دو ارائه‌دهنده را با پیگیری کارمزد متمایز از هم جدا کنید، به‌جای اینکه بگذارید هر دو مستقیم به درآمد ثبت شوند، سرراست می‌شود. هر پرداخت را ناخالص شناسایی کنید — کل پرداخت مشتری به‌عنوان درآمد، سهم ارائه‌دهنده به‌عنوان هزینهٔ فروش — و مانده‌های معوق پیش از تغییر را طبق برنامهٔ اصلی‌شان به شناسایی ادامه دهید. مستندات Beancount دستور زبان دفتر کل استفاده‌شده در زیر را پوشش می‌دهد اگر بخشی از آن ناآشنا باشد.
فرض کنید مشتری‌ای در اواسط مارس یک طرح سالانهٔ ۱٬۲۰۰ دلاری از طریق Lemon Squeezy خریده است. پرداخت مارس خالصِ کارمزد ۵ درصد به‌علاوهٔ ۵۰ سنت (۶۰٫۵۰ دلار) رسیده و تا ۳۰ ژوئن چهار ماه درآمد (۴۰۰ دلار) شناسایی کرده‌اید و ۸۰۰ دلار کسب‌نشده باقی مانده است. ۱ ژوئیه تاریخ تغییر شماست، و یک اشتراک ماهانهٔ ۴۹ دلاری جدید در ژوئیه از طریق Paddle فروخته می‌شود. در یک دفتر کل متن‌ساده چنین می‌شود:
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 USDسه جزئیات کل مهاجرت را حمل می‌کنند. اول، کارمزدهای هر ارائه‌دهنده به حساب فرعی خودش ثبت می‌شود، پس جمع‌های پایان سال دقیقاً نشان می‌دهند هر پلتفرم چه هزینه‌ای برای شما داشته و دو برنامهٔ کارمزد هرگز در هم نمی‌آمیزند. دوم، ثبت شناسایی ژوئیه برای فروش مارس با تغییر دست‌نخورده است — درآمد معوق بدهی شماست، طبق برنامهٔ شما کسب می‌شود، و اهمیتی ندارد کدام پلتفرم وجه نقد را جمع کرده. سوم، هر ثبت به یک گزارش پرداخت مشخص گره می‌خورد: اعلامیهٔ حوالهٔ مارس Lemon Squeezy برای اولی، و پرداخت ژوئیهٔ Paddle برای سومی. وقتی حسابدار شما می‌پرسد درآمد سال چگونه کسب شده، هر عدد دقیقاً به مستندات یک ارائه‌دهنده اشاره می‌کند.
درز را عمداً ببندید
مهاجرت ثبت‌کنندهٔ فروش دو پروژه است با یک نام: جابه‌جایی صورتحساب، که مهندسان شما در چند هفته تمامش می‌کنند، و جابه‌جایی دفاتر، که حسابدار شما یک سال با آن زندگی می‌کند. پروژهٔ صورتحساب وقتی تمام می‌شود که آخرین مشتری دوباره مشترک شود. پروژهٔ دفاتر وقتی تمام می‌شود که هر پرداخت از هر دو ارائه‌دهنده به بانک گره بخورد، هر ردیف کارمزد به یک دفتر حساب‌ها نگاشت شود، ماندهٔ درآمد معوق به‌تمیزی از تاریخ تغییر عبور کند، و یادداشت ناخالص در برابر خالص در پروندهٔ حسابرسی شما هر دو نیمهٔ سال را تحت یک سیاست پوشش دهد. تغییر را در مرز یک دوره برنامه‌ریزی کنید، فروش‌های جدید را روی پلتفرم جدید اجرا کنید در حالی که اشتراک‌های قدیمی تا تمدید پیش می‌روند، و سیستم قدیمی را تا وقتی حسابرسان سال مهاجرت را دیده‌اند خوانا نگه دارید. این کار را بکنید، و تغییر به یک پانویس در صورت‌های مالی سال بعد تبدیل می‌شود به‌جای مغایرتی که هیچ‌کس نمی‌تواند توضیح دهد.
