داشبورد توسعهدهندگان فروشگاه وب کروم را امروز باز کنید، متوجه یک چیز غایب میشوید: تب «پرداختها». گوگل سیستم پرداخت درونبرنامهای خودش برای اکستنشنها را در سال 2021 تعطیل کرد و هرگز بازنگشت. اگر میخواهید در سال 2026 بابت یک اکستنشن کروم پول دریافت کنید، خودتان باید صورتحسابگذاری، اشتراکها، بازپرداختها، جمعآوری مالیات و — بخشی که تقریباً هیچکس برایش برنامهریزی نمیکند — تطبیق آنچه واقعاً به حساب بانکیتان رسیده با آنچه فروختهاید را انجام دهید.
همان بخش آخر بیشتر از قیمتگذاری، توسعهدهندگان مستقل را غافلگیر میکند. یک کسبوکار تکنفره که سه یا چهار اکستنشن را از طریق استرایپ، پدل یا رَپری مانند اکستنشنپی اداره میکند، با واریزهای پرداختی روبهرو میشود که بهطور تمیز به هیچ محصول خاصی نگاشت نمیشوند، جهشهای بازپرداخت که بهطور ناگهانی پس از یک تأخیر در بررسی فروشگاه وب کروم پدیدار میشوند، و مانده بانکی که هیچوقت دقیقاً با آنچه داشبورد فروش میگوید مطابقت ندارد. هیچکدام از اینها اشکالی در کسبوکار شما نیست. این نتیجه قابلپیشبینی سرهمکردن پشتهای از پرداخت است که قبلاً گوگل برایتان اداره میکرد.
در ادامه نحوه ساختن حسابداریای که در برابر این وضعیت دوام میآورد را میبینید.
چرا گوگل از کسبوکار پرداخت خارج شد
پرداختهای فروشگاه وب کروم در اوایل دهه 2010 راهاندازی شد، زمانی که گزینههای خوب چندانی برای یک توسعهدهنده مستقل برای دریافت پول بابت یک اکستنشن مرورگر وجود نداشت. تا سال 2021، استرایپ، برینتری و موجی از خدمات «بازرگان ثبتشده» بهقدری بالغ شده بودند که گوگل تصمیم گرفت دیگر نیازی به اداره سیستم پرداخت، کلید مجوز و پرداخت خودش ندارد. گوگل پرداختهای فروشگاه وب کروم را کنار گذاشت و هر اکستنشن پولی را وادار کرد بین رایگانشدن یا رفتن به سراغ یک پردازشگر شخصثالث انتخاب کند.
نتیجه عملی برای توسعهدهندگان: هر دلاری که یک اکستنشن بهدست میآورد اکنون از میان پشته پرداختی میگذرد که خودتان سرهم کردهاید، و هر مشکل تطبیقی که آن پشته ایجاد میکند برعهده خودتان است که حل کنید. دیگر یک «گزارش پرداخت فروشگاه وب کروم» واحد وجود ندارد — هرچه پردازشگرتان به شما میدهد، بهعلاوه هرچه تحلیلهای فهرست خود فروشگاه وب کروم نشان میدهد، بهعلاوه صورتحساب بانکیتان، و این سه چیز بهندرت در نگاه اول با هم همخوانی دارند.
پردازشگر پرداخت یا بازرگان ثبتشده — برای هر اکستنشن یکی را انتخاب کنید
پیش از آنکه اصلاً تطبیق آغاز شود، باید بدانید از نظر قانونی در کدام سمت معامله ایستادهاید، زیرا این تعیین میکند چه چیزی در دفاتر شما ثبت میشود.
یک پردازشگر پرداخت (استرایپ بهطور مستقیم، یا رَپری ساختهشده روی آن مانند اکستنشنپی) شما را فروشنده میکند. شما پول را جمعآوری میکنید، از نظر مالیاتی بازرگان ثبتشده هستید و مسئول تعیین تعهدات مالیات بر فروش و مالیات بر ارزشافزوده در هر حوزه قضاییای هستید که مشتری در آن زندگی میکند. کارمزدها پایینتر است — نرخ پایه استرایپ 2.9٪ بهعلاوه $0.30 به ازای هر تراکنش است و رَپری مانند اکستنشنپی معمولاً سهم خودش را روی آن اضافه میکند — اما بار انطباق برعهده شماست.
یک بازرگان ثبتشده (پدل، لموناسکوییزی، فانجیز و مشابهها) از نظر قانونی بهجای شما فروشنده میشود. آنها مالیات بر ارزشافزوده یا مالیات بر کالا و خدمات را جمعآوری میکنند، اظهارنامهها را در بیش از 140 کشوری که اکنون آن را برای کالاهای دیجیتال الزامی میدانند تسلیم میکنند، برگشت وجهها را مدیریت میکنند و مبلغ خالص را به شما پرداخت میکنند. شما 4 تا 8٪ از درآمد را واگذار میکنید بهجای حدود 3٪، اما یک دسته کامل از کار حسابداری و اظهارنامه مالیاتی ناپدید میشود. برای بررسی کامل مصالحهها و نحوه محاسبه اینکه چه زمانی این تغییر برایتان صرف میکند، به راهنمای بازرگان ثبتشده ما مراجعه کنید.
برای بیشتر توسعهدهندگان مستقل اکستنشن با درآمد زیر چند هزار دلار در ماه، 3 تا 5٪ اضافیای که یک بازرگان ثبتشده دریافت میکند، بیمهای ارزان در برابر ثبتنام دستی برای مالیات بر ارزشافزوده در دهها کشور است. زمانی که درآمد تکرارشونده واقعی را در چند اکستنشن اداره میکنید، دوباره مقایسه را انجام دهید — با رشد حجم، محاسبات تغییر میکند.
هرکدام را که انتخاب کردید، آن را مکتوب کنید. دفاتر شما نیاز به پاسخی روشن برای «چه کسی از نظر قانونی فروشنده ثبتشده این اکستنشن است» دارند، زیرا این موضوع تعیین میکند آیا اصلاً تعهد مالیات بر فروش در ترازنامه شما ظاهر میشود یا نه.
مشکل تطبیق، ساختاری است نه یک اشتباه
این بخشی است که توسعهدهندگان را غافلگیر میکند: حتی با یک پردازشگر که بهدرستی پیکربندی شده باشد، پرداختی که دریافت میکنید تقریباً هرگز با درآمدی که در آن دوره تولید کردهاید برابر نیست. سه چیز تطبیق یکبهیک را میشکند:
- پرداختهای دستهای. استرایپ و بیشتر بازرگانان ثبتشده با یک برنامه زمانی چرخشی پرداخت میکنند (اغلب 2 تا 7 روز پس از تراکنش، گاهی هفتگی)، بنابراین پرداختی که در پنجم ماه فرود میآید شامل فروشهای چند روز پایانی ماه قبل است. اگر پرداختها را همان روزی که به بانکتان میرسد بهعنوان درآمد ثبت کنید، هر ماه درآمد را به دوره اشتباه نسبت میدهید.
- چند اکستنشن، یک حساب پردازشگر. اگر چندین اکستنشن را از طریق یک حساب استرایپ یا پدل واحد اداره میکنید — امری رایج برای توسعهدهندگانی که چند ابزار کوچک را بهجای یک محصول اصلی عرضه میکنند — پرداخت یک مبلغ یکجای واحد است که همه آنها را پوشش میدهد. بدون برچسبگذاری در سطح هر اکستنشن (فیلدهای متادیتای استرایپ، یا محصولات/قیمتهای جداگانه برای هر اکستنشن)، نمیتوانید بگویید کدام اکستنشن واقعاً درآمد را ایجاد کرده، که تشخیص اینکه کدامیک ارزش زمان نگهداریتان را دارد غیرممکن میکند.
- کارمزدها، بازپرداختها و تبدیل ارز پیش از آنکه عدد را ببینید، خالص شدهاند. مبلغ پرداختی از پیش پس از کسر کارمزدهای پردازش، هر بازپرداختی که در آن دوره صادر شده، و تبدیل ارز در صورت فروش بینالمللی است. ثبت پرداخت بهعنوان درآمد ناخالص، ارقام بالای شما را بیشنمایی و حاشیه سود واقعیتان را پنهان میکند.
راهحل یک تطبیق سهطرفه است که دستکم ماهانه انجام میشود:
- گزارش فروش پردازشگر — تراکنشهای ناخالص، اگر حسابتان پشتیبانی کند به تفکیک محصول/اکستنشن، پیش از کسر کارمزدها و بازپرداختها.
- گزارش پرداخت پردازشگر — مبالغ خالصی که واقعاً به بانکتان منتقل شدهاند، با کارمزدها و بازپرداختها بهعنوان اقلام جداگانه.
- صورتحساب بانکی — واریزهایی که واقعاً تسویه شدهاند.
هر سه را تطبیق دهید. گزارش فروش میگوید چه چیزی بهدست آوردهاید (درآمد، شناساییشده هنگامی که مشتری بابت دوره خدمات پرداخت کرده). گزارش پرداخت افت کارمزد و فعالیت بازپرداخت را برای ثبت بهعنوان هزینه و کاهنده درآمد نشان میدهد. صورتحساب بانکی تأیید میکند که پول واقعاً رسیده است. هر زمان دو مورد از این سه با هم همخوانی نداشتند، این نشانهای است که چیزی نیاز به بررسی دارد — یک پرداخت ناموفق، یک برگشت وجه مورد اختلاف، یا کارمزد پردازشگری که انتظارش را نداشتید.
ریسک ویژه کروم: تأخیرهای بررسی و حذف اکستنشن
هر پشته پرداختی فعالیت بازپرداخت معمولی دارد. اکستنشنهای کروم یک حالت شکست اضافی دارند که ارزش دارد بهعنوان قلمی جداگانه ردیابی شود: تأخیرهای بررسی فروشگاه وب کروم و حذفهای ناشی از نقض سیاست.
هنگامی که تیم بررسی گوگل یک اکستنشن منتشرشده را به دلیل نقض سیاست علامتگذاری میکند، یا با حذف فوری روبهرو میشوید (نقضهای متوسط تا شدید) یا یک دوره هشدار حدود 7 تا 30 روزه برای رفع یک نقض جزئی دریافت میکنید. در هر صورت، کاربران دسترسی به اکستنشنی را از دست میدهند که در حال حاضر بابتش پول میدهند، و این جهشی قابلپیشبینی در درخواستهای بازپرداخت، برگشت وجه و تیکتهای پشتیبانی ایجاد میکند — توسعهدهندگان گزارش دادهاند که دقیقاً به همین الگو، درصدهای دورقمی از درآمد اشتراک یک ماه را از دست دادهاند، جدا از بازپرداختهای مستقیم.
دو عادت حسابداری، این وضعیت را قابلمدیریت میکند بهجای یک غافلگیری:
- بازپرداختها و برگشت وجهها را بر اساس علت برچسبگذاری کنید. بازپرداختی که به این دلیل است که مشتری از اکستنشن خوشش نیامده، هزینه معمول کسبوکار است. بازپرداختی که به این دلیل است که اکستنشن شما یک هفته حذف شده، یک ریسک کسبوکار متمایز و قابلردیابی است. جدا کردن آنها (حتی صرفاً با یک فیلد یادداشت یا یک زیرحساب) به شما اجازه میدهد در طول یک سال ببینید چقدر از نوسان درآمد از ریسک پلتفرم میآید در مقابل تناسب محصول-بازار.
- یک بررسی در حال انتظار یا یک هشدار سیاست باز را بهعنوان رویدادی درخور افشا در نظر بگیرید، همانطور که ریسک از دست دادن یک مشتری کلیدی را علامتگذاری میکنید. اگر دارید اعداد را بررسی میکنید تا تصمیم بگیرید قیمتها را بالا ببرید، نیرو استخدام کنید یا وام بگیرید، اکستنشنی که در حال حاضر تحت یک هشدار انطباق 30 روزه است «درآمد تکرارشونده پایدار» نیست — تا زمانی که از بررسی عبور نکند، آن را بهعنوان در معرض ریسک مدلسازی کنید.
درآمد را زمانی که بهدست میآورید شناسایی کنید، نه زمانی که پرداخت میرسد
اکستنشنهای اشتراکی و خرید یکباره نیاز به رفتار متفاوتی دارند، و مخلوطکردن آنها رایجترین اشتباه حسابداری در این حوزه است:
- اشتراکهای ماهانه یا سالانه: درآمد را بهطور یکنواخت در طول دورهای که مشتری بابتش پول میدهد شناسایی کنید، نه یکجا در لحظهای که تراکنش انجام میشود. یک طرح سالانه که پیشاپیش پرداخت شده یک بدهی درآمد معوق ایجاد میکند — پول را دریافت کردهاید، اما هنوز یازده ماه از دوازده ماه خدمات را ارائه ندادهاید، بنابراین فقط 1/12 در ماه فروش درآمد است و بقیه ماه به ماه از ترازنامه خارج میشود.
- معاملات مادامالعمر (یک مدل قیمتگذاری محبوب بهویژه برای اکستنشنها، چراکه کاربران نسبت به اشتراکهای مداوم برای یک ابزار مرورگر محتاط هستند): اینها همچنان یک تعهد برای ارائه بهروزرسانی و پشتیبانی بهطور نامحدود نشان میدهند، بنابراین شناسایی 100٪ پول نقد بهعنوان درآمد در روز اول، درآمد واقعاً کسبشده آن ماه را بیشنمایی میکند. رویکردی قابلدفاعتر، درآمد معامله مادامالعمر را در یک دوره خدمات تخمینی معقول شناسایی میکند (بسیاری از کسبوکارها 12 تا 36 ماه را بهعنوان تقریب استفاده میکنند) بهجای یکجا.
- خریدهای یکباره بدون تعهد مداوم: در لحظه تحویل بهطور کامل شناسایی کنید — این حالت ساده است.
MRR (درآمد تکرارشونده ماهانه) معیار رشد مفیدی است، اما با عدد درآمد شناساییشده در دفاترتان یکسان نیست. MRR نرخ اجرای اشتراکهای فعال را نشان میدهد؛ دفتر حساب شما باید آنچه واقعاً پس از معوقسازی در این دوره کسب کردهاید را منعکس کند.
ساختار دفتر حسابی که در برابر چند اکستنشن دوام میآورد
اگر دفاترتان را در یک سیستم متنساده و دوطرفه نگه میدارید، راهحل مشکل «یک پرداخت، چند اکستنشن» یک نمودار حسابها است که از روز اول درآمد را بر اساس محصول تفکیک میکند، بهعلاوه حسابهای صریح برای کسورهایی که یک گزارش پرداخت از پیش خالص کرده است:
2026-07-05 * "Stripe payout - batch #4471"
Assets:Bank:Checking 842.17 USD
Income:Extensions:FocusTimer -510.00 USD
Income:Extensions:TabArchiver -390.00 USD
Expenses:PaymentProcessing:StripeFees 41.83 USD
Expenses:Refunds:FocusTimer 16.00 USDهر پرداخت به یک تراکنش واحد تبدیل میشود که واریز بانکی را در برابر درآمد هر اکستنشن، کارمزدها و بازپرداختها بهعنوان قلمهای جداگانه تطبیق میدهد — بهجای یک خط مبهم «واریز استرایپ» که هیچچیزی درباره اینکه کدام محصول واقعاً سودآور است به شما نمیگوید. چون فایل متنساده است، میتوانید آن را بر اساس اکستنشن، ماه یا علت بازپرداخت جستوجو یا پرسوجو کنید، که دقیقاً همان دیدی است که یک گزارش پرداخت یکجا به شما نمیدهد.
چکلیست ماهانه
- گزارش فروش پردازشگر را برای آن ماه دریافت کنید (ناخالص، در صورت امکان به تفکیک محصول).
- گزارش پرداخت را دریافت کنید و کارمزدها، بازپرداختها و برگشت وجهها را به اقلام جداگانه خودشان تفکیک کنید.
- واریزهای پرداختی را در برابر صورتحساب بانکی تأیید کنید.
- درآمد اشتراک و معامله مادامالعمر را بر اساس یک برنامه شناسایی ثبت کنید، نه در لحظه دریافت.
- هر بازپرداخت مرتبط با تأخیر بررسی یا حذف فروشگاه وب کروم را جدا از ریزش معمولی برچسبگذاری کنید.
- اگر بهطور بینالمللی از طریق یک پردازشگر پرداخت ساده (نه یک بازرگان ثبتشده) میفروشید، بررسی کنید آیا فروش تجمعیتان در هر کشوری از آستانه ثبتنام مالیات بر ارزشافزوده/مالیات بر کالا و خدمات عبور کرده است یا نه.
دفاتر کسبوکار اکستنشن خود را بههمان تمیزی کدتان نگه دارید
شما بدون کنترل نسخه اکستنشنی عرضه نمیکنید، و امور مالیتان نیز شایسته همان نظم است — بهویژه وقتی پرداختها بین چند محصول و پردازشگر تقسیم شدهاند. Beancount.io حسابداری متنساده و کنترلنسخهشدهای ارائه میدهد که به شما اجازه میدهد درآمد را بر اساس اکستنشن برچسبگذاری کنید، درآمد معوق را ردیابی کنید و پرداختها را در برابر صورتحساب بانکیتان با همان دقتی که در کدتان به کار میبرید تطبیق دهید. رایگان شروع کنید و ببینید چرا توسعهدهندگان دفاترشان را به همان شیوهای که هرچیز دیگری که میسازند مدیریت میکنند، مدیریت میکنند.