التمويل المدمج Embedded financeEmbedded finance and B2B

«التمويل المضمّن» Embedded finance أن تظهر خدمة مالية داخل برنامج ليس مالياً أصلاً، في اللحظة التي يحتاجها المستخدم فيها. وفي حالة الأعمال، يكون ذلك البرنامج هو ما يدير به التاجر يومه: نقطة البيع، أو المخزون، أو الرواتب.

وليس المقصود أن برنامج المحاسبة تحوّل فجأة إلى بنك. فشركة برمجيات قد تعرض تمويلاً لفاتورة غير محصّلة، بينما تعرض منصة جملة دفعاً مبكراً لبائع ينتظر مستحقاته. وتبدو الأولى أداة محاسبية والثانية سوقاً رقمية. والمشترك أن التمويل وصل في موضع العمل نفسه، لا عبر رحلة منفصلة إلى فرع أو تطبيق مصرفي.

ليش برنامج محاسبة يعرض عليّ تمويلاً؟

وهذا يبدو خروجاً عن تخصصه. فما علاقة برنامج يصدر الفواتير بالإقراض؟

والجواب أن البرنامج يعرف عنك ما لا يعرفه البنك. فحين يطلب البنك تمويلاً لمتجرك، يطلب كشوف حسابات وقوائم مالية وضماناً، ثم يدرسها أسابيع، ويقرر بناءً على صورة عمرها ثلاثة أشهر.

أما برنامج المحاسبة أو نظام نقاط البيع فيرى مبيعاتك اليوم بيوم. ويعرف من عملاؤك، ومن يسدّد في موعده، وكم يتذبذب دخلك بين المواسم. وهو لا يحتاج أن يسألك عن شيء، فالبيانات عنده أصلاً وأحدث مما ستقدّمه أنت.

ولهذا يستطيع أن يعرض عليك مبلغاً في لحظة، ويسترده من مبيعاتك القادمة تلقائياً بدل أقساط شهرية ثابتة.

وهنا الفكرة التي تفسّر هذا المجال كله: المزيّة ليست في التقنية ولا في المال، بل في موضع البيانات. فمن يرى تدفّق أعمالك لحظياً يستطيع أن يقرض بثقة أعلى وتكلفة أقل ممن ينتظر منك أوراقاً.

المضمّن يغيّر مكان القرار

ويبدأ المنتج المالي المستقل من واجهة مالية. فتفتح تطبيق بنك، وتبحث عن قرض، وتملأ طلباً، ثم ترفع كشوفاً تثبت مبيعاتك. ويبدأ المنتج المضمّن من مهمة غير مالية كنت تؤديها أصلاً. فترسل فاتورة من برنامج المحاسبة، ويظهر بجوارها خيار الحصول على قيمتها اليوم.

وهذا الفرق في السياق أهم من شكل الزر. فالتاجر لا يترك عمله ليصف حاجته بل يجد العرض عند ظهورها. وبرنامج المحاسبة يعرف قيمة الفواتير ومواعيدها وتاريخ تحصيلها. ومنصة التجارة تعرف المبيعات والمرتجعات والمخزون. وتصبح هذه البيانات جزءاً من قرار الائتمان بعد موافقة العميل واكتمال المتطلبات النظامية.

ولا يعني ذلك أن كل زر مالي منتج مضمّن. فرابط يحوّلك إلى صفحة بنك عامة ليس إلا إحالة رقمية. ويصبح التمويل مضمّناً حين تنتقل بيانات السياق، ويكتمل معظم المسار داخل البرنامج، وتعود النتيجة إلى المهمة الأصلية. فالفاتورة تتغير حالتها بعد التمويل، أو يظهر موعد السداد داخل لوحة التاجر نفسها.

وتظهر منصات أعمال سعودية مثل فودكس نمطاً مألوفاً: برنامج يدير نقاط البيع والمخزون والطلبات، ثم يظهر عرض تمويل أو تسهيل داخل الرحلة نفسها عبر شريك مرخّص. ولا تحتاج أن تعرف تفاصيل كل عقد كي تفهم الفكرة. فالمهم أن السياق من البرنامج، والالتزام من المموّل، والنتيجة تعود إلى لوحة التاجر.

فاتورة رابحة ونقد غائب

ويحتاج هذا الباب إلى فصل الربح عن التدفق النقدي. فالربح نتيجة محاسبية تقارن الإيراد بالتكلفة خلال فترة. وأما «التدفق النقدي» Cash flow فهو توقيت دخول الريالات وخروجها فعلاً. وقد تكون الشركة رابحة على الورق وعاجزة عن دفع راتب يوم الخميس.

وفكّر في متجر يبيع بضاعة لشركة كبيرة بقيمة ١٠٠ ألف ريال. فيسجّل المتجر الإيراد اليوم، لكن العقد يمنح المشتري ٦٠ يوماً للسداد. ويطلب المورد ثمن المخزون الجديد خلال ١٤ يوماً، وينزل راتب الموظف بعد ٢٠ يوماً. فالبيع مربح، لكن النقد يصل بعد الالتزامات.

وهنا يظهر «تمويل الفواتير» Invoice financing لسد هذه الفجوة. فتدفع جهة ممولة معظم قيمة الفاتورة الآن، ثم تحصل المبلغ عند موعدها وفق الهيكل المتفق عليه. ويدفع المتجر رسماً مقابل تقديم الزمن وتقليل فجوة النقد. ولا يصنع التمويل ربحاً جديداً، بل يقدّم نقداً مستقبلياً مع تكلفة واضحة.

ويظهر نموذج مختلف عند سائق التوصيل. فالمنصة قد تجمع أجرة رحلاته طوال الأسبوع، بينما يحتاج الوقود مساء اليوم. فتتيح له صرف الرصيد المكتسب مبكراً مقابل رسم صغير. وليست هناك فاتورة بين شركتين في هذا المثال، لكن المشكلة واحدة: حق مالي تحقق قبل أن يحين موعد دفعه المعتاد.

ولا ينبغي أن يخفي سهولة الزر تكلفة التمويل. فالرسم الثابت على فترة قصيرة قد يبدو صغيراً، لكنه يصبح مرتفعاً عند مقارنته سنوياً. ويجب أن يرى التاجر المبلغ الذي سيستلمه، والمبلغ الذي سيرده، والرسوم، وموعد الخصم. فالمنتج المضمّن الجيد يقلّل النقرات ولا يقلّل الإفصاح.

من يملك العميل ومن يحمل الالتزام

وغالباً تملك شركة البرمجيات علاقة العميل وتجربة الاستخدام. فهي تعرف أين يوضع العرض، ومتى يحتاجه المتجر، وكيف يظهر السداد في لوحة الحساب. ولكن الشريك المرخّص قد يملك عقد التمويل، ويصرف المال، ويسجّل التعثر، ويتحمل الالتزام النظامي والائتماني.

وهذا التقسيم ليس تجميلاً قانونياً. فلو أخطأ برنامج المحاسبة في نقل الإيرادات، قد يصدر الشريك قراراً ائتمانياً سيئاً. ولو أخفى الشريك رسماً، ستصل الشكوى أولاً إلى شركة البرمجيات التي يراها العميل. ولهذا تحدد العقود من يوافق على الإعلان، ومن يتحقق من هويتك، ومن يعالج الاعتراض، ومن يحفظ السجلات.

وقد تختار شركة كبيرة الحصول على ترخيصها بنفسها. وعندها لا تعود واجهة فقط، بل تحمل واجبات النشاط المرخّص أيضاً. وقد تختار شركة ناشئة صغيرة شريكاً مصرفياً أو شركة تمويل مرخّصة. وعندها لا يجوز لها تقديم الشريك كاسم صغير في الهامش، لأن المنتج يعتمد عليه عند الصرف والتحصيل والتعثر.

دفاتر من؟

ونظام الحقيقة للالتزام المالي هو دفاتر الشريك المرخّص، لا جدول الفواتير وحده في برنامج المحاسبة. فواجهة السياق ترسل بيانات مسموحاً بها عن المبيعات أو الفاتورة. والمموّل يقرر ويصرف ويسجّل الدين. ثم يعيد حالة إلى البرنامج المضيف كي تتغير الفاتورة أو يظهر جدول السداد. وإذا انقطع الاتصال بعد الصرف، يجب ألا يُنشأ التزام ثان بالمعرّف نفسه.

ويربط هذا بما رأيته في الإقراض والسجلات. فالعرض داخل البرنامج توزيع. والاكتتاب والصرف ائتمان. والمطابقة بين لوحة التاجر وكشف المموّل تكشف حين تغيّرت حالة الفاتورة بلا قيد مقابل.

لماذا ينمو هذا النموذج سريعاً

وينمو التمويل المضمّن لأن لحظة العرض غنية بالسياق. فالبنك الذي يستقبل طلباً جديداً يرى مستندات جمعها العميل لهذا الطلب. وأما منصة تدير مبيعات المتجر منذ سنتين فترى الموسمية، ومتوسط السلة، والمرتجعات، وأيام الركود. وتسمح هذه الصورة بتسعير أدق ومراجعة أسرع عندما تكون البيانات موثوقة ومسموحاً باستخدامها.

ويقلّ أيضاً ما يسمى تكلفة اكتساب العميل. فشركة التمويل المستقلة تدفع لإعلان يقنع التاجر بزيارة موقعها. وأما برنامج الأعمال فلديه تاجر نشط يفتح الشاشة كل صباح. ويمكنه تقديم المنتج عند الحاجة بدلاً من شراء انتباه عشوائي.

ولكن السياق قد يتحول إلى فخ. فإذا قرأت المنصة ارتفاع المبيعات دون ارتفاع المرتجعات المتأخرة، فقد تبالغ في قدرة المتجر. وإذا اعتمدت على شهر موسمي واحد، فقد تموّل مستوى لا يتكرر. وإذا لم يفهم العميل سبب رفضه، يصبح القرار السريع صندوقاً مغلقاً يصعب الاعتراض عليه.

ولهذا تحتاج البيانات إلى تعريفات ثابتة واختبارات جودة. فهل تعني «المبيعات» الطلبات المنشأة أم المدفوعة أم المسلّمة؟ وهل خُصمت الضرائب والمرتجعات من الرقم المعروض؟ وهل يستطيع المتجر تصحيح سجل خاطئ؟ فالقرار الأسرع لا يكون أفضل إلا إذا أمكن تفسير مدخلاته ومراجعتها.

الرقيب ينظر إلى النشاط والشاشة معاً

وفي السعودية يبدأ التخمين الصحيح من طبيعة المنتج، لا من اسم البرنامج. فإذا كان الزر يمنح تمويلاً أو يشتري ذممًا وفق نشاط تمويلي، فالبنك المركزي السعودي هو نقطة البداية المعتادة لترخيص الممول. وإذا كان يعرض استثماراً أو أوراقاً مالية، فتدخل هيئة السوق المالية. وإذا كان يبيع حماية تأمينية، فتدخل هيئة التأمين.

ولا تختفي المسؤولية لأن الخدمة داخل برنامج غير مالي. فالرقيب ينظر إلى صاحب الترخيص، لكنه ينظر أيضاً إلى الإعلان والإفصاح والبيانات ومسار الشكوى. وقد تكون العبارة المضللة كتبها فريق البرمجيات، بينما العقد أصدره الشريك المرخّص. ولذلك يراجع الطرفان المنتج قبل الإطلاق ويراقبان أداءه بعده.

ويهمّ أيضاً فصل الموافقة على استخدام البيانات عن الموافقة على التمويل. فربط حساب المتجر لا يمنح كل شريك حق استعمال كل سجل لأي غرض. ويحتاج التصميم إلى تحديد البيانات المطلوبة، وسبب طلبها، ومدة حفظها، ومن يستطيع الوصول إليها. وهذا عمل منتج وامتثال معاً، لا مربعاً يضاف في آخر الشاشة.

اختبار بسيط لأي عرض

وعندما ترى منتجاً كهذا، ابدأ بالمهمة الأصلية. فهل كان التاجر يحاسب أو يبيع أو يدير مخزوناً قبل ظهور المال؟ ثم حدّد المنتج المالي نفسه: قرض، أو تمويل فاتورة، أو دفع مبكر، أو تأمين. وبعدها اسأل من يملك الترخيص والعقد والرصيد والمخاطر.

وفرّق أخيراً بين تحسين التوزيع وتغيير طبيعة الالتزام. فالواجهة المضمّنة تجعل الوصول أسرع، لكنها لا تلغي تكلفة الزمن ولا خطر التعثر. والبيانات السياقية تجعل القرار أغنى، لكنها لا تحول كل متجر إلى مقترض جيد. وما تغيّر فعلاً هو أن المال صار جزءاً من سير العمل، بينما بقيت قواعد المال قائمة.