Value Proposition: مخصص مشتريات غير مفوترة هو الفرق بين إقفال “شكلي” وإقفال يعتمد على Cut‑off حقيقي: بضائع/خدمات تم استلامها أو قبولها خلال الفترة، لكن الفاتورة لم تصل حتى تاريخ الإقفال. إذا تركتها بدون معالجة، ستظهر مصروفات ناقصة في الشهر الحالي ثم “قفزة” في الشهر التالي، وسيبقى سؤال المراجع ثابت: أين مصروفات الفترة غير المفوترة؟ هذا Accrued Purchases يضع مسار تشغيل من استخراج البنود غير المفوترة → احتساب الاستحقاق بناءً على أدلة (GRN/Service acceptance/PO) → إعداد قيود الاستحقاق للمشتريات → ثم عكس الاستحقاقات Reversal ومطابقة الفاتورة عند وصولها.

في 20 ثانية: ماذا ستحصل عليه؟

• Accrual Template يجمّع البنود غير المفوترة (Goods/Services) ويحوّلها إلى Schedule للإقفال.
• مصروفات مستحقة بدون فاتورة: تصنيف واضح (خدمة/توريد/مقاول/مصروف تشغيل) مع مرجع أدلة.
• قيود الاستحقاق للمشتريات جاهزة للترحيل (JE lines) مع Mapping للحسابات ومراكز التكلفة.
• عكس الاستحقاقات Reversal في بداية الفترة التالية مع جدول Reversal date ومرجع القيد الأصلي.
• True‑up Tracker عند وصول الفاتورة: مطابقة الفرق (invoice vs accrual) وتوثيق سبب الفرق.
• Evidence Index: فهرسة GRN/قبول خدمة/PO/مراسلات/تقدير يدعم القيد.
• Month‑End Pack: تسليم مختصر داخل Closing Pack يوضح: ما تم إثباته، ما تم عكسه، وما بقي مفتوحًا.

CTA مرتبط بالمخرجات: استلم Accrual schedule + JE log + Reversal schedule + Evidence pack جاهزين لـMonth‑End.

مناسبة لـ

• GL / Controller: تثبيت Cut‑off للإقفال وإخراج قيود استحقاق موثقة تؤثر مباشرة على TB.
• Accounts Payable (AP): فصل البنود غير المفوترة عن البنود المستحقة للدفع وتتبّع وصول الفاتورة.
• Procurement / Operations: ربط الاستحقاق بأدلة الاستلام/قبول الخدمة وتحديد Owners للبنود المفتوحة.

غير مناسبة لـ

• إذا لا يوجد أي دليل استلام/قبول خدمة (GRN/Service acceptance) ولا يمكن تحديد ما تم خلال الفترة — سيصبح الاستحقاق “تقديرًا بلا أساس”.
• إذا شركتك تعمل Cash‑basis ولا تقوم بإقفال على أساس الاستحقاق — استخدامه سيخلق قيود لا تناسب سياستك.

بدون المخصص / مع المخصص (مقارنة قصيرة)

قبل الاستخدام: 5 أعراض أن مخصص المشتريات غير المفوترة يسبب مشاكل في الإقفال

• فروقات كبيرة في مصروفات الخدمات/المقاولين بين الأشهر بسبب وصول الفواتير متأخرًا.
• قائمة GRN/قبول خدمة موجودة لكن لا تُترجم إلى استحقاق محاسبي عند Month‑End.
• لا يوجد سجل يوضح “ما تم استحقاقه” و“متى سنعكسه” و“متى وصلَت الفاتورة”.
• عند التدقيق: لا توجد أدلة تربط قيد الاستحقاق بـPO/استلام/قبول خدمة (Traceability ضعيف).
• في الشهر التالي: يحدث Duplicate expense أو true‑up غير مفسر عند تسجيل الفاتورة.

كيف يُدار مخصص مشتريات غير مفوترة عمليًا في Month‑End؟

الفكرة العملية: أي بند تم استلامه أو قبول خدمته قبل تاريخ الإقفال، لكنه لم يُفوتر بعد، يجب أن يظهر كاستحقاق (Liability) مقابل المصروف/COGS في نفس الفترة. هذا النموذج يبدأ من مصادر التشغيل (GRN/Service acceptance/PO open receipts) ثم يحدد ما ينطبق عليه الاستحقاق، ويحسب القيمة (حسب الكمية/السعر المتفق أو تقدير قابل للتفسير)، ثم يُخرج قيود الاستحقاق للمشتريات في JE log. بعد ذلك يضع عكس الاستحقاقات Reversal في أول يوم من الفترة التالية، ثم عند وصول الفاتورة يطابقها مع الاستحقاق ويسجل أي فرق كـtrue‑up موثق.

طريقة التطبيق (3 خطوات)

الخطوة 1: التحضير وجمع التقارير

• استخراج أدلة الفترة: GRN (للبضائع) + محاضر قبول خدمة/Timesheets (لـخدمات غير مفوترة).
• استخراج PO lines المفتوحة/المستلمة وغير المفوترة + قائمة فواتير AP المسجلة حتى تاريخ الإقفال.
• تحديد سياسة Cut‑off: تاريخ الإقفال، حدود Materiality، وما يعتبر “مستلم/مقبول” داخليًا.
• تجهيز Mapping للحسابات: Expense/COGS/Inventory/Accrued liabilities + Cost centers/Projects.

الخطوة 2: احتساب Accrued Purchases + JE Log

• تسجيل كل بند غير مفوتر في Schedule: Vendor/PO/GRN أو Service acceptance + الفترة + GL/CC + مبلغ الاستحقاق.
• تحديد طريقة الاحتساب:
  • Goods: على أساس الكمية المستلمة × سعر PO/اتفاق.
  • Services: على أساس نسبة إنجاز/ساعات/قبول خدمة حتى تاريخ الإقفال.
  • Tax: عادة لا يتم إثبات VAT input بدون فاتورة (حسب السياسة والنظام)، ويُذكر ذلك كقاعدة داخل النموذج.
• إخراج قيود الاستحقاق للمشتريات:
  • Dr Expense/COGS (أو Inventory حسب الحالة)
  • Cr Accrued purchases / Accrued liabilities
• توثيق Prepared/Reviewed/Approved + مرجع الأدلة لكل سطر.

الخطوة 3: Reversal + مطابقة الفاتورة + True‑up

• إنشاء جدول عكس الاستحقاقات Reversal (تاريخ عكس تلقائي في بداية الشهر التالي) وربطه برقم القيد الأصلي.
• عند وصول الفاتورة:
  • مطابقة الفاتورة على نفس المرجع (PO/GRN/Service acceptance/Project).
  • إغلاق البند في tracker (Accrued → Invoiced).
  • إذا اختلف مبلغ الفاتورة عن الاستحقاق: تسجيل true‑up مع سبب (سعر/كمية/ملاحق/ضريبة).
• إخراج Month‑End Pack: قائمة البنود المستحقة + ما تم عكسه + ما تم فوترته + البنود المفتوحة مع أسبابها.

مكونات النموذج (جرد واضح)

1. Accrued Purchases Schedule
   • الغرض العملي: سجل البنود غير المفوترة القابلة للاستحقاق مع مراجعها.
   • متى يُستخدم: عند Month‑End قبل إعداد JE.
   • الدليل الناتج: Schedule يربط كل مبلغ بمرجع (GRN/قبول خدمة/PO).
2. Unbilled Services Intake (خدمات غير مفوترة)
   • الغرض العملي: توحيد مدخلات الخدمات المستلمة بدون فاتورة (محاضر قبول/ساعات/نسبة إنجاز).
   • متى يُستخدم: أسبوع 4 + Month‑End.
   • الدليل الناتج: ملف قبول خدمة/تقدير مع Owner واعتماد.
3. Accrual Rules & Assumptions
   • الغرض العملي: تثبيت قواعد الاحتساب (سعر PO/نسبة إنجاز/Materiality) بدل التقديرات غير الموثقة.
   • متى يُستخدم: عند بدء التطبيق + تحديث عند تغيير السياسة.
   • الدليل الناتج: Assumptions log يُسلم للمراجعة عند الحاجة.
4. JE Log (قيود الاستحقاق للمشتريات)
   • الغرض العملي: إخراج قيود قابلة للترحيل داخل ERP مع GL/CC/Project ومراجع.
   • متى يُستخدم: يوم الإقفال (Month‑End JE batch).
   • الدليل الناتج: JE log موقّع (Prepared/Reviewed) وقابل للتتبع.
5. Reversal Schedule (عكس الاستحقاقات Reversal)
   • الغرض العملي: ضمان عكس الاستحقاق في الفترة التالية بشكل منظم وربطه بالقيد الأصلي.
   • متى يُستخدم: أول يوم في الشهر التالي أو عند فتح الفترة.
   • الدليل الناتج: جدول Reversal + مرجع JE numbers.
6. Invoice Matching & True‑up Tracker
   • الغرض العملي: مطابقة الفاتورة عند وصولها وإغلاق الاستحقاق وتوثيق أي فرق.
   • متى يُستخدم: خلال الشهر التالي (Daily/Weekly في AP).
   • الدليل الناتج: سجل إغلاق (Accrued → Invoiced) + سبب الفروق.
7. Evidence Index
   • الغرض العملي: فهرسة أدلة الاستحقاق (GRN/قبول خدمة/PO/مراسلات) وربطها بكل سطر.
   • متى يُستخدم: مع تجهيز Month‑End pack.
   • الدليل الناتج: Evidence index قابل للتسليم الداخلي والخارجي.
8. Month‑End Accrual Pack
   • الغرض العملي: تسليم موحد داخل Closing Pack: ماذا استُحق، ماذا عُكس، ماذا فُوتر، وما بقي مفتوحًا.
   • متى يُستخدم: Month‑End وYear‑End.
   • الدليل الناتج: Pack موقّع يشرح أثر الاستحقاق وTraceability.

ما الذي يجب أن يكون موجودًا داخل التسليم؟

• 01-Accrued-Purchases-Template.xlsx: الملف الرئيسي (Schedule + JE log + Reversal + Dashboards).
• 02-GRN-Unbilled-Import.xlsx: قالب استيراد الاستلامات غير المفوترة (GRN/receipts).
• 03-Unbilled-Services-Intake.xlsx: خدمات غير مفوترة (قبول خدمة/ساعات/نسبة إنجاز) + Owners.
• 04-Accrual-Rules-Assumptions.xlsx: قواعد الاحتساب + حدود Materiality + سياسة VAT/WHT داخل الاستحقاق.
• 05-JE-Log-Accruals.xlsx: قيود الاستحقاق للمشتريات (Dr/Cr + GL/CC/Project + refs).
• 06-Reversal-Schedule.xlsx: عكس الاستحقاقات Reversal (تاريخ العكس + مرجع القيد الأصلي).
• 07-Invoice-Matching-TrueUp-Tracker.xlsx: مطابقة الفاتورة/إغلاق الاستحقاق + توثيق الفروق.
• 08-Open-Accruals-Aging.xlsx: Aging للبنود المفتوحة (0–30/31–60/60+ يوم) لتحديد المخاطر.
• 09-Evidence-Index.xlsx: فهرس الأدلة (GRN/Service acceptance/PO/Correspondence) + روابط/مسارات حفظ.
• 10-MonthEnd-Accrual-Pack.xlsx: Pack للتسليم داخل Closing Pack + Sign‑off.
• 11-Runbook.pdf: تشغيل عملي (Extract → Calculate → JE → Reversal → Match → True‑up → Pack).
• 12-Controls-Checklist.pdf: نقاط رقابة Month‑End (Completeness/Cut‑off/Approval/VAT handling/Duplicates).
• 13-Archiving-Map.docx: شجرة حفظ (Year/Month/Accruals/Inputs/Outputs/Evidence) + Naming convention.
• 14-Signoff-Page.docx: Prepared/Reviewed/Approved + نطاق الفترة (مثلاً Nov‑2025).

بعد التطبيق (نقطتان فقط)

• نتيجة تشغيلية للفريق: عند Month‑End يصبح لديك قائمة محددة: ما الذي يجب استحقاقه الآن، وما الذي سيعكس تلقائيًا، وكيف سيتم إغلاقه عند وصول الفاتورة—بدل تقديرات مبعثرة في آخر يوم.
• نتيجة رقابية/تدقيقية: كل قيد استحقاق مرتبط بمرجع استلام/قبول خدمة وبسجل فرضيات، مع Evidence index وTrue‑up tracker يشرح أي فرق بين الاستحقاق والفاتورة.

FAQ — أسئلة قبل الشراء

هل يناسب أي نظام ERP؟

نعم. تحتاج فقط استخراج GRN/قبول خدمة و/أو PO receipts و/أو AP open items. الترحيل يتم بقيد داخل ERP حسب شجرة حساباتك.

هل يغطي بضائع (GRN) وخدمات غير مفوترة؟

نعم. للبضائع يعتمد على الاستلام (GRN/receipts)، وللخدمات يعتمد على إثبات قبول الخدمة أو نسبة الإنجاز أو الساعات حسب ما هو متاح.

كيف يتعامل مع VAT عند الاستحقاق بدون فاتورة؟

افتراضيًا: يتم إثبات المصروف/الالتزام بدون VAT input حتى تصل الفاتورة (وفق سياسات كثير من الشركات). القالب يتيح توثيق القاعدة المتبعة داخل Assumptions log.

ما الحد الأدنى من البيانات المطلوبة لعمل الاستحقاق؟

مرجع استلام/قبول خدمة + وصف البند + مبلغ تقديري أو كمية وسعر + مورد/مستفيد + GL/Cost center. بدون مرجع استلام/قبول يصبح الاستحقاق صعب الدفاع عنه.

هل يدعم عكس الاستحقاقات Reversal تلقائيًا؟

يدعم “جدول عكس” واضح (Reversal schedule) وتنتج منه قيود العكس. تنفيذ العكس نفسه يتم داخل ERP (قيد عكس/Auto reversal حسب إعداداتك).

ماذا لو جاءت الفاتورة بمبلغ مختلف عن الاستحقاق؟

يتم تسجيل الفرق في True‑up tracker وتوثيق السبب (سعر/كمية/ملاحق/ضريبة)، ثم يُعالج محاسبيًا حسب سياستك (قيد فرق أو تعديل على المصروف).

هل يصلح للMonth‑End فقط أم Year‑End أيضًا؟

مناسب للاثنين. Year‑End عادة يحتاج توثيق أقوى وAging للبنود المفتوحة، والقالب يخرج Month‑End/Year‑End pack بنفس المنطق.

هل يمكن ربطه مع GR/IR Reconciliation أو 3‑Way match؟

نعم. البنود غير المفوترة غالبًا تتقاطع مع GR/IR أو فروقات 3‑Way match. القالب يسمح بوضع مرجع GR/IR/PO/GRN لتسهيل الربط في ملف Reconciliations.

هل ينتج أثر واضح على TB؟

نعم: يخرج JE lines توضح حساب المصروف/COGS مقابل Accrued liabilities. أثرها يظهر في TB بعد الترحيل (مع إمكانية ربطها بقيد رقم/Batch ID).

جاهز تثبت Cut‑off وتطلع الاستحقاقات بملف أدلة بدل “تقديرات”؟

المخرجات: Accrued Purchases schedule + قيود الاستحقاق + Reversal + True‑up + Evidence pack.