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

Costs of developing the core payment platform, apps and risk/fraud engines can only be capitalized as internally generated intangible assets once strict development-phase criteria are met (technical feasibility, intention and ability to complete and use, probable future economic benefits, ability to measure cost reliably); research and routine maintenance are expensed, and over-capitalizing engineering spend inflates assets and understates current-period expense, masking the true cost of running the platform.

هل انتقلت مبادرة هندسية محددة من مرحلة البحث الاستكشافي إلى مرحلة تطوير بتصميم تقني محدد؟ هل يمكن للمنشأة عند تلك النقطة إثبات الجدوى التقنية والنية والقدرة المالية والتقنية على إكمال الميزة واستخدامها؟ هل يُتابَع وقت المطورين (كتخصيص السبرنتات) للفصل بين التطوير القابل للرسملة والصيانة وإصلاح الأخطاء غير القابلين للرسملة؟

Has the specific engineering initiative moved from exploratory research into a development phase with a defined technical design? Can the entity evidence, at that point, technical feasibility, intention, and financial/technical ability to complete and use the feature? Is developer time tracked (e.g., via sprint allocation) to separate capitalizable development from non-capitalizable maintenance and bug-fixing?

١) اربط كل مبادرة هندسية بمشروع وصنّفها كبحث (استكشافي، بلا تصميم تقني محدد) أو تطوير (تصميم محدد يتجه نحو البناء). ٢) حمّل جميع إنفاق مرحلة البحث والاستكشاف كمصروف عند تكبده. ٣) بالنسبة لأعمال مرحلة التطوير، اختبر معايير المعيار 38 الستة معا: الجدوى التقنية، النية على الإكمال، القدرة على الاستخدام أو البيع، كيفية تحقيق منافع اقتصادية مستقبلية محتملة، توفر الموارد للإكمال، والقدرة على قياس التكلفة بموثوقية. ٤) ارسمل فقط من لحظة استيفاء جميع المعايير (لا بأثر رجعي) حتى جاهزية الميزة للاستخدام المقصود. ٥) تتبع وقت المطورين عبر سجلات الوقت أو تخصيص السبرنت بين التطوير القابل للرسملة والصيانة أو إصلاح الأخطاء غير القابلة للرسملة. ٦) ابدأ الإطفاء عند جاهزية الأصل للاستخدام، وأعد تقييم العمر الإنتاجي دوريا نظرا لتسارع دورات التقنية.

1) Map each engineering initiative to a project and classify it as research (exploratory, no defined technical design) or development (defined design, moving toward build). 2) Expense all research-phase and exploratory spend as incurred. 3) For development-phase work, test all six IAS 38 criteria together: technical feasibility, intention to complete, ability to use/sell, how it will generate probable future economic benefits, availability of resources to complete, and ability to measure cost reliably. 4) Capitalize only from the point all criteria are met (not retrospectively) until the feature is ready for its intended use. 5) Track developer time via timesheets or sprint allocation between capitalizable development and non-capitalizable maintenance/bug-fixing. 6) Begin amortizing once the asset is available for use, and reassess useful life periodically given fast technology cycles.

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

Measure at cost including directly attributable payroll and infrastructure costs (e.g., cloud compute directly tied to building the feature, not general hosting); exclude general overheads, training costs, and post-launch operating costs; amortize over the useful life once available for use, reassessing useful life as technology and product cycles evolve quickly in fintech; test for impairment if a capitalized feature is later abandoned, replaced, or a major re-platforming supersedes it.

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

Disclose: the accounting policy for distinguishing research from development; amounts capitalized during the period by major project/platform component; the amortization method and useful lives applied to platform intangibles; impairment losses recognized on abandoned or superseded features; and the total R&D expense recognized (research plus expensed development).

• رسملة كامل رواتب الهندسة بغض النظر عن مرحلة المشروع
• رسملة الصيانة الجارية وإصلاح الأخطاء والتعديلات الطفيفة على الواجهة
• عدم إعادة تقييم أو اضمحلال التكاليف المرسملة للميزات المهجورة أو المستبدلة لاحقا
• رسملة وقت السبرنتات الرشيقة دون منهجية موثقة تفصل تطوير الميزات الجديدة عن الصيانة
• الاستمرار بالرسملة بعد جاهزية الميزة تقنيا للاستخدام لكن قبل '
• الإطلاق'
• الرسمي (يجب التوقف عند الجاهزية التقنية لا تاريخ الإطلاق)
• رسملة النفقات العامة للبحث والتطوير ووقت الإدارة غير المنسوب مباشرة لمشروع محدد.

• Capitalizing all engineering payroll regardless of project phase
• capitalizing ongoing maintenance, bug fixes and minor UI changes
• failing to reassess or impair capitalized costs for features later abandoned or replaced
• capitalizing time spent on agile sprints without a documented methodology separating new-feature development from maintenance
• continuing to capitalize after the feature is technically ready for use but before formal '
• go-live'
• (should stop at technical readiness, not launch date)
• capitalizing general R&
• D overhead and management time not directly attributable to a specific project.