پرش به محتوای اصلی

چگونه پرداخت‌های Stripe را وقتی سالانه صورت‌حساب می‌کنید اما ماهانه شناسایی می‌کنید، تطبیق دهید

منتشر شده زمان مطالعه 10 دقیقهMike ThriftMike Thrift
چگونه پرداخت‌های Stripe را وقتی سالانه صورت‌حساب می‌کنید اما ماهانه شناسایی می‌کنید، تطبیق دهید
فهرست مطالب این صفحه

شما در ماه مارس پنج قرارداد سالانه بستید و ۶۰٬۰۰۰ دلار به حساب Stripe شما واریز شد. داشبورد شما می‌درخشد، موجودی بانکی‌تان قهرمانانه به نظر می‌رسد — و حسابدارتان تازه به شما گفته که درآمد مارس ۵٬۰۰۰ دلار بوده است. هیچ‌کس اشتباه نمی‌کند. شما به دو عدد متفاوت نگاه می‌کنید که تصادفاً در همان حساب Stripe زندگی می‌کنند: نقدی که جمع‌آوری کرده‌اید و درآمدی که واقعاً کسب کرده‌اید. تا زمانی که این دو را تطبیق ندهید، هر پرداختی که Stripe برایتان می‌فرستد معمایی است که دفاتر شما باید حل کنند.

این راهنما نشان می‌دهد چگونه شرکت‌های SaaS که سالانه صورت‌حساب می‌کنند اما ماهانه درآمد را شناسایی می‌کنند، پرداخت‌های Stripe را بدون دوباره‌شماری درآمد، بدون ارائه نادرست درآمد معوق، یا فریب خوردن توسط متریکی که کل شکاف را پنهان می‌کند، تطبیق می‌دهند.

چرا پرداخت‌های Stripe نقطه شروع اشتباهی برای درآمد هستند​

یک پرداخت Stripe شبیه درآمد به نظر می‌رسد. به‌صورت یک واریز واحد به حساب بانکی شما می‌رسد، تاریخی روی آن است، و حس می‌کنید که درآمد آن ماه است. هیچ‌کدام از این‌ها نیست. یک پرداخت، تسویه خالص است: هزینه‌های ناخالص منهای کارمزد پردازش، منهای بازپرداخت‌ها، منهای برداشت‌های مربوط به اختلافات، که بر اساس برنامه پرداخت Stripe و نه برنامه شما، در یک دسته جمع می‌شوند.

اگر پرداخت‌ها را به‌عنوان درآمد ثبت کنید، دو تحریف جداگانه ایجاد می‌شود.

نخست، درآمد را کم‌نمایی می‌کنید. اگر مشتری ۱۲٬۰۰۰ دلار برای یک پلن سالانه پرداخت کرده باشد، Stripe تقریباً ۳۴۸ دلار به‌علاوه ۳۰ سنت را نگه می‌دارد و بقیه را پرداخت می‌کند. ثبت پرداخت، خالص را به‌عنوان فروش شما ثبت می‌کند و کارمزد را جایی دفن می‌کند که هرگز نمی‌توانید آن را تحلیل کنید — یا به‌طور تمیز کسر کنید.

دوم، و برای صورت‌حساب سالانه بسیار خطرناک‌تر، زمان‌بندی را نادرست ثبت می‌کنید. کل ۱۲٬۰۰۰ دلار در یک پرداخت در ژانویه می‌رسد، اما تحت حسابداری تعهدی شما آن را به‌میزان ۱٬۰۰۰ دلار در ماه، همگام با ارائه خدمات، کسب می‌کنید. پرداخت را به‌عنوان درآمد ژانویه ثبت کنید و ژانویه باشکوه به نظر می‌رسد در حالی که فوریه تا دسامبر مرده به نظر می‌رسند، حتی اگر کسب‌وکار هر ماه دقیقاً همان کار را انجام داده باشد.

راه‌حل این است که پرداخت را همان‌طور که هست — یک انتقال نقدی — در نظر بگیرید و درآمد را در مسیری کاملاً جداگانه، که توسط قراردادهای شما و نه واریزهایتان هدایت می‌شود، شناسایی کنید.

سه عددی که بنیان‌گذاران اشتباه می‌گیرند: سفارش‌ها، صورت‌حساب‌ها و درآمد​

هر تطبیق صورت‌حساب سالانه با جدا نگه‌داشتن سه عدد آغاز می‌شود:

  • سفارش‌ها (Bookings) ارزش کل قراردادهای امضاشده هستند. مشتری در ژانویه یک قرارداد سالانه ۱۲٬۰۰۰ دلاری امضا می‌کند: ۱۲٬۰۰۰ دلار سفارش در ژانویه. سفارش یک تعهد است، نه نقد و نه درآمد.
  • صورت‌حساب‌ها (Billings) چیزی است که صورتحساب می‌کنید و جمع‌آوری می‌کنید. اگر قرارداد سالانه پیش‌پرداخت صورت‌حساب شود، صورت‌حساب ژانویه ۱۲٬۰۰۰ دلار است. اگر ماهانه صورت‌حساب شود، صورت‌حساب ژانویه ۱٬۰۰۰ دلار است حتی اگر سفارش ۱۲٬۰۰۰ دلار بوده باشد.
  • درآمد (Revenue) چیزی است که با ارائه خدمات کسب کرده‌اید. یک ماه از یک قرارداد دوازده‌ماهه، یک‌دوازدهم کسب می‌شود: ۱٬۰۰۰ دلار درآمد ژانویه در هر حالت.

فاصله بین صورت‌حساب‌ها و درآمد، درآمد معوق (که درآمد تحقق‌نیافته نیز نامیده می‌شود) است، یک بدهی در ترازنامه شما که نمایانگر خدماتی است که هنوز بدهکار هستید. ۱۲٬۰۰۰ دلار در ژانویه جمع‌آوری کنید و ۱٬۰۰۰ دلار شناسایی کنید، و ۱۱٬۰۰۰ دلار درآمد معوق را به فوریه می‌برید. آن بدهی مشکلی نیست — بلکه اثبات صادق بودن دفاتر شماست. هر ماه ۱٬۰۰۰ دلار کاهش می‌یابد تا قرارداد پایان یابد.

به‌زبان ساده: سفارش‌ها به شما می‌گویند فروش چگونه پیش می‌رود، صورت‌حساب‌ها می‌گویند نقدینگی چگونه پیش می‌رود، و درآمد می‌گوید کسب‌وکار واقعاً چگونه عمل کرده است. تطبیق در همان لحظه‌ای می‌شکند که بگذارید یکی از این‌ها جای دیگری را بگیرد.

جدول درآمد معوق را بسازید که شناسایی ماهانه را هدایت می‌کند​

جدول درآمد معوق موتور کل فرآیند است. یک جدول ساده به‌ازای هر قرارداد — مشتری، شروع قرارداد، مدت، ارزش کل قرارداد، مبلغ شناسایی ماهانه، درآمد شناسایی‌شده تا به امروز، مانده معوق باقی‌مانده — و تنها سندی است که هرگز باید یک ثبت روزنامه درآمد را ایجاد کند.

برای یک پلن سالانه ۱۲٬۰۰۰ دلاری که از اول ژانویه شروع می‌شود، ثبت‌ها این‌گونه به نظر می‌رسند:

On collection (January):
  Dr  Stripe clearing          $12,000
      Cr  Deferred revenue              $12,000
 
Each month, January–December:
  Dr  Deferred revenue          $1,000
      Cr  Subscription revenue            $1,000

توجه کنید چه چیزی غایب است: پرداخت هیچ‌جایی در ثبت‌های درآمد ظاهر نمی‌شود. جمع‌آوری نقدی به درآمد معوق، که یک بدهی است، بستانکار می‌شود. درآمد بعداً، ماه‌به‌ماه، از جدول متولد می‌شود.

دو نکته انضباطی وجود جدول را می‌سازند یا می‌شکنند. نخست، هر قرارداد سالانه جدید، تمدید و گسترش باید در ماه شروعش روی جدول بنشیند — قراردادی که از جدول جا بماند، درآمدی است که هرگز شناسایی نخواهد شد. دوم، هر ماه جدول را با دفتر کل تطبیق دهید: مانده معوق ابتدای دوره، به‌علاوه صورت‌حساب‌های جدید، منهای درآمد شناسایی‌شده، باید برابر با مانده معوق پایان دوره باشد. اگر نیست، چیزی جدول را دور زده است — معمولاً یک بازپرداخت، یک تغییر میان‌دوره‌ای، یا یک پرداخت که کسی مستقیماً به درآمد ثبت کرده است.

خود پرداخت را با یک حساب تسویه تطبیق دهید​

در حالی که جدول زمان‌بندی درآمد را مدیریت می‌کند، هنوز باید پولی که از طریق Stripe حرکت می‌کند را حساب کنید. روش تمیز، استفاده از یک حساب تسویه Stripe است — یک حساب دارایی که نمایانگر «نقدی که داخل Stripe نشسته است» می‌باشد.

هر رویداد Stripe با مبلغ ناخالص به حساب تسویه ثبت می‌شود:

Customer charged $1,000:
  Dr  Stripe clearing            $1,000
      Cr  Deferred revenue                $1,000
 
Stripe fee of $29.30 on that charge:
  Dr  Processing fees              $29.30
      Cr  Stripe clearing                   $29.30
 
Payout of $970.70 lands in your bank:
  Dr  Bank checking               $970.70
      Cr  Stripe clearing                  $970.70

بازپرداخت‌ها و برداشت‌های مربوط به اختلافات به همان روش، اما معکوس، ثبت می‌شوند. هنگامی که برداشت پرداخت تسویه می‌شود، حساب تسویه برای اقلام آن پرداخت به صفر می‌رسد — و این دقیقاً همان چیزی است که آن را به یک ابزار تطبیق، و نه صرفاً یک قرارداد دفترداری، تبدیل می‌کند. باقی‌مانده غیرصفر یعنی یک کارمزد، بازپرداخت یا تعدیل ثبت‌نشده باقی مانده است.

برای پیوند دادن هر پرداخت به محتویاتش، از گزارش تطبیق پرداخت Stripe استفاده کنید که هر هزینه، بازپرداخت، کارمزد و تعدیل داخل یک پرداخت را جزء‌به‌جزء فهرست می‌کند، و تأیید کنید که ناخالص منهای کارمزدها منهای بازپرداخت‌ها برابر با واریز بانکی است. این کار را پرداخت‌به‌پرداخت انجام دهید، نه ماه‌به‌ماه: پرداخت‌ها مدام از مرزهای ماه عبور می‌کنند، و دسته‌بندی ماهانه جایی است که معماهای «بانک هرگز با Stripe مطابقت نمی‌کند» از آن نشأت می‌گیرند. اگر حجم شما کم است، یک ریتم هفتگی با حساب تسویه، اختلافات کوچک را در حالی که هنوز ردیابی‌شان آسان است، شناسایی می‌کند.

اصلاحات (True-Ups): تغییرات میان‌دوره‌ای که جدول‌ها را می‌شکنند​

قراردادهای سالانه به‌ندرت دوازده ماه ثابت می‌مانند، و هر تغییر نیازمند یک ثبت اصلاحی در برابر جدول معوق است:

  • ارتقاها و گسترش صندلی‌ها به مانده معوق باقی‌مانده می‌افزایند. مشتری‌ای که با شش ماه باقی‌مانده از ۱۲٬۰۰۰ به ۱۸٬۰۰۰ دلار در سال ارتقا می‌دهد، حدود ۳٬۰۰۰ دلار درآمد معوق جدید (شش ماه با ۵۰۰ دلار اضافی در ماه) به مانده شناسایی‌نشده اضافه می‌کند.
  • تنزل‌ها آن را کوچک می‌کنند. پلن را با شش ماه باقی‌مانده کاهش دهید و تفاوت را از درآمد معوق خارج می‌کنید — اغلب به‌عنوان اعتباری برای صورت‌حساب‌های آینده به‌جای بازپرداخت نقدی، که همچنان نیازمند یک ثبت روزنامه است حتی اگر پولی جابه‌جا نشود.
  • تناسب‌بندی‌ها (Prorations) سازوکار هستند: Stripe تغییرات اشتراک را با اعتبارات زمان استفاده‌نشده مدیریت می‌کند، و آن اعتبارات دقیقاً به شما می‌گویند چه مقدار درآمد معوق باید بین پلن قدیمی و جدید جابه‌جا شود.
  • لغوها با بازپرداخت زمان پیش‌پرداخت‌شده درآمد معوق را کاهش می‌دهند، هرگز درآمد ماه جاری را. بازپرداخت شش ماه استفاده‌نشده از یک پلن ۱۲٬۰۰۰ دلاری، یک بدهکار ۶٬۰۰۰ دلاری به درآمد معوق است — ثبت آن در برابر درآمد این ماه، ماهی را که هیچ اشتباهی نکرده کم‌نمایی می‌کند.
  • پرداخت‌های ناموفق در تمدیدهای سالانه نیازمند نظارت در جهت دیگر هستند: نقد جمع‌آوری‌نشده یعنی مانده معوق جدیدی وجود ندارد، پس جدول نباید به شناسایی درآمد برای قراردادی که تأمین مالی‌اش متوقف شده ادامه دهد.

قاعده عملی: هیچ تغییر اشتراکی در Stripe بدون به‌روزرسانی متناظر در جدول در همان ماه. تیم‌هایی که اجازه می‌دهند این دو از هم دور شوند، هر پایان فصل را صرف بازسازی آنچه اتفاق افتاده از فایل‌های PDF صورت‌حساب می‌کنند.

متریک SaaS که همه چیز را پنهان می‌کند: MRR داشبورد درآمد نیست​

این تله‌ای است که کل این ساختار پنهان می‌کند. داشبورد Stripe شما نشان می‌دهد MRR به‌زیبایی بالا می‌رود — پلن‌های سالانه به معادل‌های ماهانه تبدیل می‌شوند، ارتقاها فوراً MRR گسترش را اضافه می‌کنند، و نمودار به سمت بالا و راست شیب می‌گیرد. بنیان‌گذاران کاملاً طبیعی شروع به فکر کردن به آن عدد به‌عنوان «آنچه در ماه کسب می‌کنیم» می‌کنند.

این‌طور نیست. MRR یک متریک نرخ اجرای نرمال‌شده است: ارزش ماهانه اشتراک‌های فعال اگر هیچ چیز تغییر نکند. درآمد شناسایی‌شده چیزی است که واقعاً تحت حسابداری تعهدی این ماه کسب کرده‌اید. این دو مدام واگرا می‌شوند — پیش‌پرداخت‌های سالانه‌ای که این ماه جمع‌آوری می‌شوند به‌سختی درآمد این ماه هستند، MRR گسترش از یک ارتقای میان‌ماه فقط نیم ماه درآمد است، و هیچ‌یک از اعداد داشبورد از جدول معوق، بازپرداخت‌ها یا اصلاحات شما خبر ندارد.

این واگرایی تا زمانی که ضربه نزند نامرئی است. درآمد مشمول مالیات از درآمد شناسایی‌شده پیروی می‌کند، نه MRR، پس یک فصل بزرگ سفارش می‌تواند صورت‌حساب مالیاتی تولید کند که بنیان‌گذارانی را که داشبورد را تماشا می‌کردند غافلگیر کند. و خریداران و وام‌دهندگان در بررسی‌های خود درآمد GAAP را بررسی می‌کنند، نه MRR — هر دلار «درآمدی» که واقعاً صورت‌حساب شناسایی‌نشده بود از گفتگوی ارزش‌گذاری تعدیل می‌شود.

هر دو عدد را نگه دارید، اما هرگز نگذارید یکی کار دیگری را انجام دهد. یک بررسی سلامت ماهانه مفید: درآمد شناسایی‌شده برای ماه، به‌علاوه تغییر در مانده معوق شما، باید به صورت‌حساب‌ها تطبیق یابد. اگر MRR می‌گوید رشد کرده‌اید و آن معادله چیز دیگری می‌گوید، به معادله اعتماد کنید.

چک‌لیست بستن ماهانه شما برای SaaS روی Stripe​

این را هر ماه اجرا کنید و اجزا به هم پیوسته می‌مانند:

  1. پرداخت‌ها را به بانک پیوند دهید. داده‌های تطبیق پرداخت را صادر کنید، تأیید کنید که ناخالص منهای کارمزدها منهای بازپرداخت‌ها برابر با هر واریز است، و برداشت را از طریق حساب تسویه ثبت کنید.
  2. حساب تسویه را به‌ازای هر پرداخت صفر کنید. هر مانده باقی‌مانده یک کارمزد، بازپرداخت، اختلاف یا تعدیل ثبت‌نشده است — آن را قبل از پایان ماه پیدا کنید.
  3. جدول معوق را به‌روز کنید. قراردادها و تمدیدهای جدید را اضافه کنید، ثبت‌های شناسایی ماه را ثبت کنید، و تأیید کنید که مانده ابتدای دوره به‌علاوه صورت‌حساب‌ها منهای درآمد شناسایی‌شده برابر با مانده پایان دوره است.
  4. تغییرات میان‌دوره‌ای را اصلاح کنید. هر ارتقا، تنزل، تناسب‌بندی، لغو و بازپرداخت در Stripe را به یک تعدیل جدول مطابقت دهید.
  5. MRR را با درآمد شناسایی‌شده تطبیق دهید. شکاف بین نرخ اجرای داشبورد و درآمد کسب‌شده را توضیح دهید؛ هر چیزی را که نمی‌توانید در یک جمله توضیح دهید بررسی کنید.
  6. کارمزدها و بازپرداخت‌ها را جداگانه بررسی کنید. درآمد ناخالص، کارمزد پردازش و بازپرداخت‌ها هرکدام داستان خودشان را می‌گویند — خالص‌سازی آن‌ها هر سه را پنهان می‌کند.

اگر به‌طور مداوم انجام شود، این کار پایان ماه را از یک کاوش پزشکی‌قانونی به یک روال تبدیل می‌کند: سمت پرداخت ثابت می‌کند نقدینگی شما کامل است، و سمت جدول ثابت می‌کند درآمد شما کسب شده است.

درآمد SaaS خود را آماده سرمایه‌گذاری نگه دارید​

همگام با مقیاس‌گیری صورت‌حساب سالانه، پیوند دادن درآمد شناسایی‌شده، مانده‌های معوق و نقدینگی Stripe در هر ماه همان چیزی است که اعداد شما را برای حسابداران، مقامات مالیاتی و خریداران آینده معتبر می‌کند. Beancount.io حسابداری متن‌ساده ارائه می‌دهد که به شما شفافیت و کنترل کامل بر داده‌های مالی‌تان می‌دهد — بدون جعبه سیاه، بدون قفل شدن به فروشنده. رایگان شروع کنید و ببینید چرا توسعه‌دهندگان و متخصصان مالی به حسابداری متن‌ساده روی می‌آورند.

منبع: https://beancount.io/fa/blog/2026/10/11/stripe-payout-reconciliation-annual-billing-monthly-recognition-saas-guide

منتشر شده: ۱۹ مهر ۱۴۰۵

زمان مطالعه 10 دقیقه

چگونه مشارکت‌های آب‌وهوایی Stripe، پرداخت‌های فوری و ذخایر را بدون ایجاد هزینهٔ خیالی مغایرت‌گیری کنیم

هدایای آب‌وهوایی، کارمزدهای پرداخت فوری و ذخایر نگه‌داشته‌شده، پرداخت‌های…

reconciliation
payments
زمان مطالعه 15 دقیقه

چگونه تسویهحسابهای Stripe را بدون از دست دادن ردی از درآمد واقعی خود تطبیق دهید

Stripe کارمزدها را کسر میکند، بازپرداختها را نگه میدارد و مبلغ خالص را تسویه…

reconciliation
payments
زمان مطالعه 11 دقیقه

حسابداری توسعه‌دهندگان اکستنشن کروم: تطبیق پرداخت‌ها پس از حذف پرداخت درون‌برنامه‌ای گوگل

گوگل در سال 2021 سیستم پرداخت فروشگاه وب کروم را کنار گذاشت و توسعه‌دهندگان…

reconciliation
saas
زمان مطالعه 20 دقیقه

میکرو-SaaS و حسابداری API: صورتحساب مبتنی بر مصرف، تطبیق پردازشگر پرداخت، و چرا حاشیه سود ۷۰٪ همچنان به دفتر واقعی نیاز دارد

کسب‌وکارهای میکرو-SaaS و API با حاشیه سود ناخالص ۷۰٪ یا بیشتر همچنان به…

saas
bookkeeping
زمان مطالعه 10 دقیقه

دفترداری افزونه و قالب وردپرس: تمدید مجوز، مالیات فروشنده رسمی (Merchant of Record) و تطبیق پرداخت‌های Envato، Freemius و Stripe

اقدام Envato در تاریخ 1 جولای 2026 برای تغییر به سهم ثابت 50 درصدی درآمد…

plugins
revenue-recognition