سير عمل محاسبة الأسواق الإلكترونية عبر Stripe Connect
دليل عملي للمحاسبين لتسجيل المدفوعات، والرسوم، والتحويلات، والاستردادات، والنزاعات، والمخصصات في دفتر أستاذ السوق الإلكتروني مع مطابقة دقيقة.
تعود معظم مشكلات محاسبة الأسواق الإلكترونية (Marketplace) إلى خطأ واحد أساسي: التعامل مع تحويلات البنك من Stripe على أنها إيرادات. فالتحويل هو المحصلة الصافية لعشرات العمليات الاقتصادية المنفصلة، وتسجيله كبند إيراد واحد يمحو عمولة المنصة، والتزام البائع، وكل رسوم أو نزاع مدفون داخله. يفكك سير العمل الصحيح هذا التحويل إلى مكوناته قبل أن يلمس أي شيء دفتر الأستاذ (ledger).
يتتبع هذا الدليل كل فئة من فئات معاملات رصيد Stripe Connect إلى موطنها المحاسبي الصحيح: الذمم المدينة، وإيرادات العمولات، والتزامات البائعين، ومصروفات المعالجة، والحسابات المعلقة. ويستخدم هذا الدليل نقاط النهاية (endpoints) للاستيراد والتسوية الموثقة في Nordletآليةً للتسجيل، ويحتوي على مثال عملي للتسوية، ويُختتم بقائمة تحقق للمطابقة يمكنك تنفيذها قبل كل إغلاق مالي.
حدد نموذج رسوم Connect قبل تصميم أي شيء
لا يمكن صياغة القواعد المحاسبية إلا بعد معرفة نموذج الرسوم الذي يستخدمه كل تدفق دفع. يحدد هذا النموذج رصيد Stripe الذي يتحمل الرسوم، ومن يتحمل تكلفتها، والمكان الذي تتأثر فيه الاستردادات والنزاعات أولاً.
| نموذج Connect | مكان إنشاء الدفع | يتحمل رسوم Stripe | الاستردادات والنزاعات تخفض | الأثر المحاسبي |
|---|---|---|---|---|
| المدفوعات المباشرة (Direct charges) | الحساب المرتبط (Connected account) | قابل للتخصيص لكل طرف | رصيد الحساب المرتبط | تسجل المنصة رسوم التطبيق الخاصة بها كإيرادات؛ وتتركز معظم أنشطة دفع البائع في دفتر أستاذ الحساب المرتبط |
| المدفوعات الموجّهة (Destination charges) | المنصة، مع تحويل فوري إلى حساب مرتبط واحد | المنصة | المنصة | تسجل المنصة الذمم المدينة للعميل ورسوم Stripe؛ وتُعد حصة البائع التزاماً (payable) وليست إيراداً |
| المدفوعات والتحويلات المنفصلة (Separate charges and transfers) | دفع عبر المنصة، يليه تحويل مستقل أو أكثر | المنصة | المنصة | يُعد الدفع وتحويلات البائع حدثين منفصلين؛ ويتم تتبع التزام البائع بشكل مستقل عن دفعة العميل |
تؤكد إرشادات Stripe الخاصة حول كيفية عمل المدفوعات في تكامل Connect أنه بالنسبة للمدفوعات الموجّهة والمدفوعات والتحويلات المنفصلة، فإن رصيد المنصة يتحمل رسوم الدفع، والاستردادات، واسترداد المبالغ المدفوعة (chargebacks). أما في المدفوعات المباشرة، فيتلقى الحساب المرتبط الدفع، ويمكن خصم الرسوم من أي من الطرفين.
القاعدة العملية هي: لا تقل إن "تحويل Stripe هو إيراد البائع" أو إن "البائع يدفع الرسوم" حتى تقوم بتدوين نموذج الرسوم لكل تدفق. احفظ هذا النموذج بجانب كل معاملة. فخلط المدفوعات المباشرة والموجّهة تحت قاعدة تسجيل واحدة هو أسرع طريق لتسجيل خطأ في كل من الإيرادات والالتزامات.
يفترض هذا الدليل استخدام المدفوعات الموجّهة أو المدفوعات والتحويلات المنفصلة، نظراً لأن رصيد المنصة فيها يتحمل الثقل المحاسبي، وهو المكان الذي تُبنى فيه معظم دفاتر أستاذ الأسواق الإلكترونية.
ارسم تدفق الأموال قبل استيراد صف واحد
قبل الشروع في أي عملية استيراد، ارسم خريطة معاملات من صفحة واحدة لكل تدفق:
Customer payment
-> Stripe charge / payment balance transaction
-> Stripe fee
-> platform application fee (commission)
-> transfer to connected account
-> refund or dispute (if applicable)
-> Stripe payout
-> bank receipt
كل سهم هنا يمثل معاملة رصيد مستقلة لها مُعرّف (ID)، وفئة، ومبلغ، وتواريخ خاصة بها. تعامل مع رصيد Stripe كحساب مقاصة شبيه بالحساب البنكي: تتدفق المدفوعات للداخل، بينما تتدفق الرسوم والتحويلات للخارج، وينقل التحويل البنكي المتبقي إلى البنك الحقيقي. توصي توثيق استيراد البنوك والمدفوعات الخاص بNordlet بهذا التعامل تماماً مع أنشطة Stripe الاعتيادية.
اختر تقرير Stripe المصدر الصحيح
بالنسبة لدفعات التسوية التلقائية، استخدم تقرير مطابقة المدفوعات المفصل (Payout reconciliation, itemized) من Stripe. فهو يمنحك صفاً لكل معاملة رصيد، ويُجمّع الصفوف حسب فئة التقارير reporting_category، ويربط كل صف بمُعرّف التحويل التلقائي automatic_payout_id، ويوفر إجماليات الإيرادات، والرسوم، والصافي. توثق دليل اختيار التقارير من Stripe هذا التقرير وتؤكد أن charge_id وconnected_account_id وdestination_payment_id هي حقول Connect متاحة.
في حال لم تكن الدفعات التلقائية مُفعّلة (كما في بعض ترتيبات الدفع اليدوي)، فاستخدم تقرير الرصيد (Balance report) بدلاً من ذلك. ولا تعتبر ملخص مدفوعات لوحة التحكم (Dashboard) دليلاً كافياً للتسجيل؛ فالملخص يثبت إجمالي الدفعة، بينما وحدها التقارير المفصلة تفسر المكونات.
توصي Stripe بالتصنيف حسب reporting_category بدلاً من حقل النوع الأقدم type، ويحمل كل صف مُعرّف مصدر source يربط الكائن الأساسي. انتبه لقيد التوقيت: تشير Stripe إلى أن بيانات التقارير اليومية تصبح متاحة عادةً بحلول الظهر في اليوم التالي، ولا يمكن تعيين الدفعات الفورية بدقة لمعاملات فردية، لذا فهي تحتاج إلى مطابقة منفصلة لسجل المعاملات.
صنّف كل معاملة رصيد حسب الفئة
استخدم reporting_category المُصنّف الأساسي، ثم تفقد source_id وcharge_id والأوصاف. إليك جدول الربط المهم:
| نشاط Stripe | فئة التقارير (Reporting category) | التفسير المحاسبي |
|---|---|---|
| دفعة العميل، عبر البطاقة أو طريقة دفع محليّة | charge |
الذمم المدينة الممولة من العميل أو تسوية المبيعات |
| الاسترداد | refund |
عكس دفعة العميل الأصلية |
| رسوم المعالجة المقتطعة بواسطة Stripe | fee |
مصروف معالجة المدفوعات |
| رسوم تطبيق المنصة | platform_earning |
إيرادات العمولات |
| رسوم التطبيق المستردة | platform_earning_refund |
تخفيض إيرادات العمولات |
| التحويل إلى الحساب المرتبط | transfer |
تخفيض التزامات البائع |
| التحويل المعكوس | transfer_reversal |
الاسترداد من الحساب المرتبط |
| استرداد المبلغ المدفوع (Chargeback) | dispute |
خسارة استرداد المبالغ؛ تفقد كائن النزاع المصدر |
| استرداد المبلغ المدفوع بنجاح أو عكسه | dispute_reversal |
استرداد لمبلغ استرداد مدفوع تم تسجيله مسبقاً |
| التحويل إلى البنك | payout |
حركة بنكية، وليست إيراداً |
| التحويل البنكي المعكوس | payout_reversal |
عودة الأموال إلى رصيد Stripe |
| المخصص المحتجز | connect_reserved_funds / risk_reserved_funds |
أموال مقيدة، وليست مصروفاً بشكل افتراضي |
| تحصيل رصيد سالب طويل الأمد | connect_collection_transfer |
حدث تمويل أو استرداد يتطلب سياسة مخاطر |
تنبيه بشأن المصطلحات: يستخدم حقل نوع معاملة الرصيد الأقدم type تسميات مختلفة لنفس الأحداث، ومنها payment وapplication_fee وadjustment. تسرد توثيق أنواع معاملات الرصيد من Stripe كلا القاموسين. لا تدمج قيمة type في قاعدة تخص reporting_category، ولا تبتكر فئة غير موجودة في تقارير Stripe مثل dispute_loss. وإذا احتوى التصدير على تسمية لا تعرفها، فاحتفظ بالقيمة المُصدّرة وتحقق منها مقابل الكائن المصدر.
سجل نشاط السوق الإلكتروني العادي في دفتر الأستاذ
بالنسبة لمنصة تعتمد على المدفوعات الموجّهة أو المدفوعات والتحويلات المنفصلة، تكون القيود المحاسبية المفاهيمية كالتالي:
دفعة العميل (تدخل أموال العميل إلى رصيد مقاصة Stripe):
Dr Stripe clearing Gross customer charge
Cr Trade receivables Gross customer charge
رسوم معالجة Stripe:
Dr Stripe fee expense Stripe fee
Cr Stripe clearing Stripe fee
لا تقم بمقاصة رسوم Stripe مع الإيرادات إلا إذا كانت سياساتك المحاسبية تتطلب وتدعم صراحة العرض الصافي.
عمولة المنصة (إيراداتك، والمقتطعة مما كان سيُستحق للبائع لولا ذلك):
Dr Seller payable Commission amount
Cr Commission revenue Commission amount
تحويل البائع (تسوية الأموال المستحقة، وليس مصروفاً):
Dr Seller payable Transfer amount
Cr Stripe clearing Transfer amount
التحويل ليس مصروفاً تلقائياً أبداً. تصبح حصة البائع التزاماً بمجرد وصول الدفعة، وينهي التحويل هذا الالتزام. تتبع قواعد تسجيل التسوية في Nordlet هذا المبدأ: تُسجل صفوف platform_earning في إيرادات العمولات بينما تخفض صفوف transfer التزامات البائع. مفاتيح التسجيل الافتراضية الموثقة هي settlements.commissionRevenue (الافتراضي 5001)، وsettlements.sellerPayable (الافتراضي 4499)، وsettlements.fees (الافتراضي 6800)، وsettlements.suspense (الافتراضي 4440)، ويمكن تجاوز كل منها لكل شركة عبر قواعد التسجيل في واجهة برمجة تطبيقات Nordlet (Nordlet API).
معالجة الاستردادات مقابل البيع الأصلي، وليس كعناصر بنكية سائبة
يرتبط الاسترداد بالدفعة أو الفاتورة الأصلية. مفاهيمياً:
Dr Refunds / sales reversals Refund amount
Cr Trade receivables Refund amount
يعتمد القيد الحقيقي على ما إذا كان البيع قد تم الاعتراف به، وما إذا كان يجب عكس الضريبة، وما إذا تم استرداد رسوم تطبيق المنصة. يمكن أن ينتج عن عملية استرداد واحدة: عكس ذمم مدينة، وعكس ضريبة، واسترداد رسوم تطبيق، وعكس تحويل أو تخفيض التزام البائع، وتأثير لرسوم Stripe يجب التحقق منه لا افتراضه.
فخ التوقيت: غالباً ما تستقر عملية الاسترداد في تحويل لاحق لتاريخ الدفعة الأصلية. يفضل استخدام تقرير مطابقة المدفوعات المفصل على استرداد مُصطنع من تصصدير مستوى الدفعات. تحذر توثيق Nordlet صراحةً من أن الاسترداد المُصنّع من تصدير المدفوعات (Payments) لا يُعد سوى تقريبي عندما يتم تسوية الاسترداد لاحقاً. يمكن لمستورد التسوية استيعاب صف الاسترداد ومطابقته مع البيع الأصلي وعكس الذمم المدينة عند ترحيل الدفعة.
تعامل مع النزاعات بشكل منفصل عن الاستردادات
النزاع هو مطالبة يتقدم بها صاحب البطاقة أو البنك المُصْدِر، ويمكن لـ Stripe خصم كل من المبلغ المتنازع عليه ورسوم النزاع قبل حل المشكلة. بالنسبة للمدفوعات الموجّهة والمدفوعات والتحويلات المنفصلة، تخصم Stripe رصيد المنصة مقابل الاثنين، وفقاً لـ إرشادات الاستردادات والنزاعات الخاصة بها. ويمكن للمنصة محاولة استرداد الأموال عن طريق عكس تحويل البائع.
النزاع الخاسر، من جانب المنصة:
Dr Chargeback loss / receivable reopened Disputed amount
Dr Dispute-fee expense Dispute fee
Cr Stripe clearing Combined amount
إذا كان البائع يتحمل الخسارة وتم تأكيد الاسترداد:
Dr Seller payable / recovery account Recoverable amount
Cr Chargeback recovery Recoverable amount
لا تقيد استرداد البائع لمجرد طلب عكس التحويل. تأكد من إنشاء عملية العكس، ونجاحها، وظهورها في رصيد Stripe. إذا تم كسب النزاع، تعيد Stripe المبلغ المتنازع عليه عبر صف dispute_reversal؛ اعكس خسارة استرداد المبالغ وتعامل بشكل منفصل مع أي رسوم نزاع لا تعيدها Stripe. تطابق Nordlet صفوف استرداد المبالغ المدفوعة باستخدام charge_id لدفعة سابقة تمت مطابقتها، إما من نفس الملف أو من عملية استيراد سابقة.
مثال عملي للتسوية
خذ بعين الاعتبار دفعة تسوية تلقائية واحدة. يحتوي التقرير المفصل على:
- صف
charge: الإجمالي 100.00، رسوم Stripe 3.20، الصافي 96.80 - صف
platform_earning: بمبلغ 15.00، وهي عمولة المنصة - صف
transfer: بمبلغ 81.80 إلى البائع المرتبط - صف
refundلبيع سابق: الإجمالي 20.00، يتم تسويته في هذه الدفعة - صف
payout: إجمالي الدفعة المتجه إلى البنك
تركيبة الدفعة، وفقاً لهوية تسوية Stripe:
Gross charges 100.00
- refunds 20.00
- Stripe fees 3.20
- transfers 81.80
= net to platform balance -5.00
لا يقوم صف platform_earning بتحريك الأموال مرة أخرى. فهو يُسمّي مبلغ 15.00 الذي يبقى في رصيد المنصة بمجرد خصم الرسوم وتحويل البائع، لكي تتمكن المنصة من الاعتراف بإيرادات العمولات بدلاً من استنتاجها.
هنا يتجاوز تحويل البائع مضافاً إليه الاسترداد نشاط الدفعات الصافي، لذا فإن الدفعة تصبح صافية بسالب طفيف وتخفض الدفعة التالية أو تسحب من الرصيد. يعكس القيد المُرحّل الذمم المدينة المستردة، ويعترف بـ 15.00 إيرادات عمولات، ويسجل 3.20 مصروف رسوم، ويخفض التزامات البائع بالتحويل، ويسجل عكس الاسترداد. يتطابق السطر البنكي مع الصافي الذي يصل إلى الحساب. ولا يساوي أي رقم بمفرده "الإيرادات"، وهذا هو جوهر الأمر.
الاستيراد والتسجيل عبر نقطة نهاية التسوية في Nordlet
لمطابقة مستوى الدفعات، استخدم:
POST /v1/bank/settlements/import
مع مزود Stripe وملف CSV المفصل. تقوم Nordlet بتجميع الصفوف حسب automatic_payout_id، وتحويل كل دفعة إلى دفعة تسوية بإجماليات الإيرادات، والرسوم، والصافي، وتتجاوز إعادة استيراد دفعة مُرحّلة مسبقاً، وتتجاوز صفوف payout من تركيبة التسوية، وتقوم تلقائياً بمطابقة صفوف المدفوعات، والاسترداد، والنزاعات باستخدام مراجع الطلبات، أو الفواتير، أو PaymentIntent، أو المدفوعات، أو المصادر، أو بيانات التعريف (metadata). تقسم Stripe التقرير المفصل إلى ملف واحد لكل قسم، لذا استورد ملفات المدفوعات، والاسترداد، والرسوم معاً: تُدمج الصفوف التي تنتمي إلى دفعة تم استيرادها مسبقاً ولكن لم تُرحّل بعد في الدفعة الحالية. يُعد هذا سير عمل استيراد وتسجيل مدفوع عبر الملفات ونقاط نهاية التسوية، وليس موصلاً لـ Stripe يعمل بشكل مباشر؛ وتُدرج صفحة الميزات ما يغطيه جانب البنوك والتسويات.
قم بالمطابقة بالترتيب: المدفوعات بالفواتير، والاستردادات بالمدفوعات الأصلية، والنزاعات بالمدفوعات الأصلية، وصفوف العمولات بمعالجة العمولات. ابقِ رسوم Stripe، والتعديلات، والمخصصات، وصفوف الدفعات بعيداً عن مطابقة الفواتير. ينص مسرد مطابقة المدفوعات الخاص بـ Nordlet على أن خطوط الرسوم والتعديلات غير قابلة للمطابقة مع الفواتير بحكم التصميم؛ وقم بتوجيه العناصر المالية غيرResolved إلى الحساب المعلق (suspense). يستخدم التصحيح اليدوي bank/settlements/match { lineId, invoiceId }، مع تعيين قيمة null لـ invoiceId لإلغاء المطابقة.
ثم رحّل دفعة متوازنة واحدة:
POST /v1/bank/settlements/post
ينشئ هذا القيد محاسبياً متوازناً واحداً، ويسوي الفواتير المتطابقة، ويسجل مديونية لحساب دفتر الأستاذ للحساب البنكي لصافي الدفعة، ويسجل مديونية للمصروفات، ودائماً للذمم المدينة للمدفوعات، ويعكس الذمم المدينة للاستردادات واسترداد المبالغ المدفوعة، ويقسم مدفوعات السوق الإلكتروني غير المتطابقة بين إيرادات العمولات والتزامات البائعين عند توفير commissionPercent، ويرسل المبالغ غير المُسواة إلى الحساب المعلق. وأي فئة لا تتعرف عليها تذهب أيضاً إلى الحساب المعلق، وتُسمّي الاستجابة هذه الفئات في تحذير بدلاً من استيعابها بصمت.
قائمة تحقق المطابقة
نفذ هذه التأكيدات قبل كل عملية إغلاق مالي:
- لا يوجد
balance_transaction_idمكرر - لا توجد دفعة تسوية متطابقة مكررة لـ
(provider, payout_id) - مجموع صافي السطر (
net) يساوي صافي الدفعة - صافي الدفعة يساوي التحويل البنكي، مع مراعاة سياسات التوقيت والعملة
- كل عملية استرداد لها دفعة أصلية أو استثناء مسجل
- كل نزاع له مرجع نزاع أو دفعة
- كل تحويل له مُعرّف حساب مرتبط
- كل صف
platform_earningله معاملة عمولة محددة - الحساب المعلق يساوي صفراً أو تمت مراجعته بالكامل، بما في ذلك أي فئات غير معروفة تم ذكرها في تحذير التسجيل
- التزامات البائع ليست سالبة بدون سياسة سحب أو استرداد معتمدة
- لا يمكن إعادة استيراد الدفعات المُرحّلة أو إعادة ترحيلها بصمت
- التحويل بعملة غير العملة الأساسية للشركة يتحول بسعر تاريخ التحويل، مع تسجيل الفرق مقابل سعر الفاتورة الخاصة كأرباح أو خسائر عملة محققّة؛ ويتم رفض التحويل الذي يجمع عملات مختلفة عند الاستيراد
قم بالمطابقة على ثلاثة مستويات: السطر (كل معاملة لها مُعرّف محفوظ، وفئة، ومبلغ، وعملة، ومصدر)، والدفعة (الصافي المفصل يساوي تحويل Stripe والإيصال البنكي)، ودفتر الأستاذ (القيد المُرحّل متوازن وينتج عنها مواقع الإيرادات، والرسوم، والذمم المدينة، والتزامات البائع، والحسابات المعلقة المستهدفة). بالنسبة لأرصدة البائعين تحديداً، تحقق من أن رصيد التزامات البائع الافتتاحي مضافاً إليه حصة البائع الجديدة، مطروحاً منه التحويلات وعكس العمليات الصحيحة، يساوي رصيد التزامات البائع الختامي.
الفشل المتكرر عبر كل دفاتر أستاذ الأسواق الإلكترونية هو نفسه الذي بدأ به: طي تحويل هيكلي إلى رقم واحد. حافظ على فصل المكونات، واجعل كل منها مرتبطاً بمُعرّف مستقر لـ Stripe، ودع الحساب المعلق يحتفظ بأي شيء لا يمكنك تفسيره بعد. الإغلاق النظيف هو ما يثق به المراجع المالي (Auditor).
FAQ
هل تحويل Stripe هو إيراد المنصة؟
لا. التحويل هو صافي المدفوعات، والاستردادات، ورفوم المعالجة، وتحويلات البائعين، والنزاعات، والتعديلات التي حدثت لتستقر في نفس الدفعة. تسجيله كبند دخل واحد يمحو التزام البائع ومصروف المعالجة داخله. بالنسبة لسوق إلكتروني وسيط (agent marketplace)، الإيرادات هي العمولة، والتي تحددها صفوف platform_earning.
أي تقرير من Stripe يجب أن أطابقه؟
تقرير مطابقة المدفوعات المفصل (Payout reconciliation, itemized)، لأنه يمنحك صفاً واحداً لكل معاملة رصيد يتضمن reporting_category وautomatic_payout_id ومبالغ إجمالية ورسوم وصافية. ملخص مدفوعات لوحة التحكم يثبت فقط إجمالي الدفعة. وفي حال عدم تفعيل التحويلات التلقائية، استخدم تقرير الرصيد بدلاً من ذلك.
هل ينبغي تسجيل التحويل إلى البائع كمصروف؟
لا. تصبح حصة البائع التزاماً بمجرد وصول دفعة العميل، ويُنهي التحويل هذا الالتزام. تسجيل التحويلات كمصروفات يضاعف احتساب التكلفة ويترك التزامات البائع مبالغاً فيها بشكل دائم.
ماذا يحدث لصف في Stripe لا يتعرف المستورد على فئته؟
يتم ترحيله إلى حساب تسوية الحساب المعلق (suspense)، الافتراضي 4440، وترجع استجابة الترحيل تحذيراً يسمي الفئات التي ذهبت إلى هناك. عادةً ما تذهب المخصصات والتعديلات غير المعتادة بهذه الطريقة، وهذا مقصود: تبقى الأموال مرئية ويبقى القيد متوازناً حتى يقرر شخص ما أين تنتمي.
كيف تتم معالجة الاستردادات التي تستقر في تحويل لاحق؟
تصل كصف refund في التقرير المفصل للتحويل اللاحق وتتم مطابقتها مرة أخرى بالدفعة الأصلية من خلال charge_id للدفعة المطابقة السابقة. الاسترداد المُصنّع من تصدير المدفوعات على مستوى الدفعات هو مجرد تقريب في هذه الحالة، لذا يُعد التقرير المفصل هو المصدر الأكثر أماناً.