أسباب رفض الفواتير منصة فاتورة | أهم الأخطاء وكيفية حلها

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

فمع تفعيل الربط والتكامل ضمن المرحلة الثانية من الفوترة الإلكترونية، أصبح رفض الفاتورة تجربة يومية لكثير من المنشآت التي لم تفهم بعد آلية عمل منصة فاتورة بشكل كامل.

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

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

ما هي المرحلة الثانية من الفوترة الإلكترونية؟

المرحلة الثانية، المعروفة باسم “الربط والتكامل”، هي المرحلة التي يُطلب فيها من المنشأة ربط نظام الفوترة الخاص بها (سواء كان نقطة بيع POS أو نظام ERP) مباشرة مع منصة فاتورة التابعة لهيئة الزكاة والضريبة والجمارك عبر واجهة برمجة تطبيقات API.

بدأت هذه المرحلة اعتبارًا من 1 يناير 2023م، ويتم تطبيقها بشكل تدريجي على المنشآت عبر ما يُعرف بـ”موجات التفعيل”، بحيث تُخطر الهيئة كل موجة قبل موعد دخولها الإلزامي.

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

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

لمعرفة المزيد عن الجهة المسؤولة عن هذا النظام وآلية عملها، يمكنك الاطلاع على مقالنا عن هيئة الزكاة والدخل والمرحلة الثانية بمزيد من التفصيل.

الفرق بين التخليص الفوري والإبلاغ خلال 24 ساعة

من أهم النقاط التي يجب فهمها قبل الحديث عن أسباب الرفض، هو أن منصة فاتورة تتعامل مع نوعين مختلفين من الفواتير بآليتين مختلفتين تمامًا:

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

أخطاء المرحلة الأولى التي لا تزال تسبب مشاكل

رغم أن التركيز الأكبر اليوم منصب على المرحلة الثانية، إلا أن كثيرًا من المنشآت لا تزال تقع في أخطاء أساسية موروثة من المرحلة الأولى، وأهمها:

• إغفال حقل إلزامي من حقول الفاتورة الضريبية المبسطة أو القياسية.
• عدم توليد رمز QR على الفاتورة، أو توليده بترميز غير صحيح.
• إصدار الفاتورة بصيغة غير معتمدة لا تدعم الأرشفة الرقمية بصيغة PDF/A-3.
• استخدام توقيع إلكتروني غير صالح أو منتهٍ.
• الاستمرار في إصدار فواتير ورقية بعد صدور الإلزام النظامي بالفوترة الإلكترونية.
• عدم الاحتفاظ بنسخة إلكترونية من الفاتورة لدى المنشأة نفسها.

هذه الأخطاء غالبًا ما تكون السبب الجذري وراء أخطاء لاحقة في المرحلة الثانية، لأن أي خلل في بنية الفاتورة الأساسية ينتقل مباشرة إلى ملف XML الذي يُرسل إلى منصة فاتورة.

أسباب رفض الفواتير الأكثر شيوعًا في منصة فاتورة

فيما يلي أبرز الأسباب التي تقف خلف رسالة “الفاتورة مرفوضة”، مرتبة حسب شدة تكرارها في الحالات الفعلية:

1. مشاكل شهادة الختم الرقمي CSID

شهادة CSID هي شهادة رقمية من نوع X.509 صالحة لمدة سنة واحدة فقط من تاريخ إصدارها، وتُستخدم لتوقيع الفاتورة إلكترونيًا وإثبات صحة مصدرها.

عند انتهاء صلاحيتها يصدر النظام خطأ مصادقة (401)، وتُرفض جميع الفواتير المرسلة تلقائيًا حتى يتم تجديدها. من الأخطاء الشائعة أيضًا استخدام شهادة الاختبار (Compliance CSID) في بيئة الإنتاج الفعلية بدلًا من شهادة الإنتاج، وهو ما ينتج عنه خطأ مميز برمز API-403.

2. انكسار سلسلة ICV و PIH

تعتمد منصة فاتورة على مبدأ “سلسلة التجزئة”، حيث يحمل كل فاتورة رقمًا تسلسليًا متزايدًا (ICV) لا يقبل التكرار أو التخطي، بالإضافة إلى بصمة الفاتورة السابقة (PIH) التي يجب تضمينها في كل فاتورة تالية.

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

3. أخطاء رمز الاستجابة السريعة QR / TLV

يجب أن يحتوي رمز QR على خمسة حقول إلزامية بترميز TLV وهي: اسم البائع، الرقم الضريبي، تاريخ ووقت الفاتورة، الإجمالي شامل الضريبة، وقيمة الضريبة.

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

4. أخطاء مخطط XML و UBL 2.1

تعتمد منصة فاتورة على معيار UBL 2.1 المعدَّل بمتطلبات الهيئة السعودية، وأي خطأ في بنية ملف XML، سواء كان حقلًا مفقودًا أو ترتيبًا غير صحيح للعناصر أو مساحة اسم (Namespace) خاطئة، يؤدي إلى فشل التحقق من المخطط ورفض الفاتورة قبل حتى الوصول إلى مرحلة التحقق من قواعد العمل التجارية.

5. رفض الفاتورة بسبب التكرار وأهمية المعرّفات الفريدة

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

6. أخطاء ترميز الحقول العربية

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

7. أخطاء الإشعارات الدائنة والمدينة

يجب استخدام كود المستند 381 للإشعار الدائن، و383 للإشعار المدين، والخلط بين الكودين ينتج رفضًا فوريًا. والأهم من ذلك أن أكثر من 70% من حالات رفض الإشعارات سببها خطأ في حقل الرقم المرجعي (BillingReference)، حيث يجب أن يحتوي هذا الحقل حصرًا على معرّف UUID الخاص بالفاتورة الأصلية، وليس رقم الفاتورة كما يظن كثيرون.

كما لا يجوز إصدار إشعار على فاتورة أصلية لا تزال في حالة “مسودة” ولم تُقبل من الهيئة بعد، ولا يجوز تعديل أي حقل بعد توليد بصمة الفاتورة (Hash) لأن ذلك يكسر التوقيع بالكامل. لمزيد من التفصيل حول هذا الموضوع، اطّلع على مقالنا عن الفرق بين الإشعار الدائن والمدين.

جدول رموز الأخطاء الأكثر شيوعًا وطرق إصلاحها

الفرق بين الفاتورة “المقبولة مع تحذير” و”المرفوضة فعليًا”

هذه نقطة تسبب لبسًا كبيرًا لدى كثير من المستخدمين. عند إرسال الفاتورة، تعيد منصة فاتورة استجابة تحتوي على حالة (status) وحقل رسائل الخطأ (errorMessages):

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

أما بالنسبة لفواتير B2B فيظهر حقل منفصل باسم clearanceStatus بقيمة CLEARED أو NOT_CLEARED، بينما تظهر فواتير B2C بحقل reportingStatus بقيمة REPORTED أو NOT_REPORTED.

القاعدة الذهبية هنا هي عدم الاعتماد على رمز حالة HTTP وحده لتحديد النتيجة، بل يجب قراءة محتوى الاستجابة كاملًا دائمًا، لأن بعض الطلبات قد تنجح على مستوى الاتصال (HTTP 200) لكنها تحمل رفضًا فعليًا داخل جسم الرسالة.

منظور المطورين: بنية استجابة API وسلوك إعادة المحاولة

لمن يعمل على تكامل نظام الفوترة الداخلي مع منصة فاتورة عبر API مباشرة، فإن فهم رموز حالة HTTP وسلوك إعادة المحاولة (Retry Logic) أمر بالغ الأهمية لتجنّب تراكم الأخطاء أو إغراق الخادم بطلبات غير ضرورية:

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

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

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

خطوات عملية لمعالجة الفاتورة المرفوضة

1. رصد حالة الرفض (NOT_CLEARED أو ERROR) وتسجيلها بشكل كامل فور حدوثها.
2. قراءة رسالة الخطأ (errorMessages) وترجمتها إلى سبب مفهوم بلغة غير تقنية إن لزم.
3. تصحيح السبب الجذري للمشكلة في البيانات الفعلية، وليس مجرد إخفاء العرض الظاهري للخطأ.
4. توليد رقم تسلسلي (ICV) ومعرّف (UUID) جديدين تمامًا، دون إعادة استخدام المعرّفات القديمة المرفوضة.
5. إعادة إرسال الفاتورة والتحقق من أن النتيجة أصبحت CLEARED أو REPORTED.
6. الاحتفاظ بالفاتورة المرفوضة الأصلية كسجل تدقيق داخلي، دون حذفها نهائيًا.

خطوات تشخيص تعذّر الربط مع منصة فاتورة

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

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

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

غرامات وعقوبات عدم الامتثال

يترتب على عدم الالتزام بمتطلبات الفوترة الإلكترونية مجموعة من الغرامات المنصوص عليها في نظام ضريبة القيمة المضافة ولائحته التنفيذية، وتشمل بشكل عام:

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

أهمية الربط المبكر قبل الموعد النهائي

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

خطوات عملية للربط مع منصة فاتورة (المرحلة الثانية)

لمن يريد فهم الخطوات العملية للربط بشكل مبسط، إليك التسلسل العام الذي تتبعه معظم الأنظمة المتوافقة:

1. الدخول إلى الموقع الرسمي والانتقال إلى قسم التسجيل، ثم اختيار الخيار المناسب وإدخال البيانات المطلوبة.
2. إدخال كلمة المرور والضغط على “موافق” لتأكيد الدخول.
3. اختيار “إنشاء إعداد جديد” ثم إكمال الخطوات المطلوبة داخل النظام الرئيسي لبدء عملية الربط.
4. فتح الإعدادات ثم الانتقال إلى قسم الفوترة الإلكترونية، واختيار المرحلة الثانية، ثم البدء بعملية الإنشاء.
5. إضافة الاسم والبيانات المطلوبة وتصنيف الملفات، مع اختيار نوع B2B وإدخال البيانات كما هي مسجلة رسميًا، وتحديد باقي المعايير المطلوبة.
6. إكمال بقية الإعدادات، والتأكد من ضرورة إضافة العنوان الوطني بشكل صحيح ودقيق.
7. إدخال بيانات العنوان الوطني كاملة: رقم المبنى، اسم الشارع، الحي، المدينة، والرمز البريدي، وهي من أهم البيانات التي يجب التركيز عليها لتفادي رفض عملية الربط نفسها.

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

كيف تتجنب أخطاء رفض الفواتير مستقبلًا

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

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

متى تتصل بمزود النظام ومتى تتصل بهيئة الزكاة مباشرة؟

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

أما إذا كانت المشكلة متعلقة بحالة الخدمة على منصة فاتورة نفسها، أو استفسارًا تنظيميًا حول غرامة أو موعد موجة، أو انقطاعًا عامًا في خدمات الهيئة، فالجهة الرسمية المختصة هي مركز الاتصال الموحد على الرقم 19993 المتاح على مدار الساعة، أو عبر البريد الرسمي info@zatca.gov.sa.

الأسئلة الشائعة حول رفض الفواتير في منصة فاتورة

ماذا أفعل فور رفض الفاتورة؟

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

ما الفرق بين CLEARED و NOT_CLEARED؟

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

هل يمكن استخدام نظام ERP الحالي دون تغييره بالكامل؟

نعم في الغالب، بشرط أن يدعم النظام الربط عبر API مع منصة فاتورة وتوليد ملفات XML متوافقة مع معيار UBL 2.1، وإلا يلزم استخدام حل وسيط متوافق يقوم بهذه المهمة.

ماذا يحدث إذا تعطلت منصة فاتورة من جهة الهيئة؟

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

كم مدة الاحتفاظ بالفواتير الإلكترونية؟

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

هل أحتاج شهادة CSID منفصلة لكل فرع؟

نعم، كل جهاز أو حل فوترة مستقل (EGS) يحتاج شهادة CSID خاصة به، بينما يكفي الخادم المركزي شهادة واحدة إذا كانت جميع الفروع تُصدر الفواتير من خلاله مباشرة.

هل يمكن إصدار فواتير بعملة أجنبية؟

نعم، لكن يجب ذكر القيمة المكافئة بالريال السعودي كعملة ثانوية على الفاتورة وفق سعر الصرف المعتمد بتاريخ إصدار الفاتورة.

ماذا لو لم تظهر الفاتورة في منصة فاتورة رغم إرسالها؟

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

خلاصة القول

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

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

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