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

Getting the over-time pattern right for subscription access changes when SAR of revenue lands in each period, not just its total: recognizing an annual invoice on billing overstates current-period revenue and profit, misstates gross margin trends, and misleads on the size of the deferred revenue balance that investors and lenders use as a forward indicator of recurring revenue. Because most SaaS contracts renew automatically and bill in advance, this is a high-volume, recurring risk rather than a one-off judgment.

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

Does the customer obtain continuous access to a live, hosted platform (over-time access) rather than a copy of software delivered at a point in time? What date does access actually go live, and does revenue start there rather than at contract signing or invoicing? Is straight-line recognition still a faithful depiction of benefit transfer, or does usage vary enough that an output method would better reflect it? For annual invoices paid upfront, is the unrecognized portion correctly carried as a contract liability rather than released on billing?

1. حدد التزام الأداء: تأكد من أن العميل يحصل على وصول مستمر لمنصة مستضافة وفعّالة، وليس حقا لاستخدام نسخة برمجية محددة في نقطة زمنية.
2. حدد تاريخ بدء الوصول (تاريخ التفعيل الفعلي، لا تاريخ توقيع العقد أو الفوترة) كنقطة بدء الاعتراف.
3. اختر مقياس التقدم: القسط الثابت على مدة العقد هو الأساس الافتراضي للوصول غير المتمايز؛ وانتقل إلى طريقة المخرجات (كالاستخدام) فقط إذا تفاوت الاستخدام جوهريا وعكس نمط الاستفادة الفعلي.
4. اعترف بالإيراد كل فترة مع تقديم الوصول، بصرف النظر عن توقيت فوترة العميل أو سداده.
5. سجّل أي مبلغ مفوتر أو محصّل مقدما قبل الأداء كالتزام عقد، ولا تحرره إلى الإيراد إلا مع تقديم الخدمة فعليا.
6. أعد تقييم مقياس التقدم إذا تغيّرت طبيعة ما يُقدَّم جوهريا (كإضافة وحدة قائمة على الاستخدام بشكل كبير إلى خطة وصول بسيطة).

1. Identify the performance obligation: confirm the customer obtains continuous access to a functioning, hosted platform rather than a right to use a specific version of software at a point in time.
2. Determine the start date of access (go-live, not contract signing or invoicing) as the point recognition begins.
3. Select a measure of progress: straight-line over the contract term is the default for undifferentiated access; switch to an output method (e.g., usage) only if usage varies materially and reflects the pattern of benefit.
4. Recognize revenue each period as access is provided, regardless of when the customer is billed or pays.
5. Record any amount billed or collected in advance of performance as a contract liability, releasing it to revenue only as the service is delivered.
6. Reassess the measure of progress if the nature of what is delivered changes materially (e.g., a pure access plan adds a heavily usage-driven module).

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

Measure revenue per period as the transaction price divided evenly across the contract term (straight-line) unless a usage-based output method better depicts the transfer of benefit; the measurement base is the stand-alone transaction price for the access obligation, not the gross invoice amount if other elements are bundled. Subsequently, re-measure only for contract modifications, not for changes in estimated usage under a straight-line model; reassess the appropriateness of straight-line versus usage-based measurement whenever the delivery pattern changes.

أفصح عن: (1) السياسة المحاسبية للاعتراف بإيراد الاشتراكات على مدى الزمن ومقياس التقدم المستخدم؛ (2) تفصيل الإيراد حسب النوع (اشتراك مقابل خدمات) والتوقيت (على مدى الزمن مقابل نقطة زمنية)؛ (3) أرصدة التزامات العقد الافتتاحية والختامية مع الإيراد المعترف به من الرصيد الافتتاحي؛ (4) إجمالي سعر المعاملة المخصص لالتزامات الأداء المتبقية وتوقيت الاعتراف المتوقع به؛ (5) الحكم المطبق على الترتيبات المختلطة بين حق الوصول وحق الاستخدام.

Disclose: (1) accounting policy for recognizing subscription revenue over time and the measure of progress used; (2) disaggregation of revenue by type (subscription vs services) and by timing (over time vs point in time); (3) opening and closing contract liability balances with revenue recognized from the opening balance; (4) aggregate transaction price allocated to remaining performance obligations and when it is expected to be recognized; (5) judgment applied for hybrid access/use arrangements.

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

• Recognizing the full annual invoice as revenue when billed instead of over the service period
• treating a term license that behaves like an on-premise sale as if it were SaaS access recognized over time
• using contractual billing dates rather than the actual go-live date as the start of recognition
• failing to reduce the contract liability consistently when a customer receives free extension months as a retention concession
• ignoring a shift to material usage-based components that should change the measure of progress from straight-line to an output method.