فاتورتي مرفوضة من الهيئة: كيف تقرأ سبب الرفض وتصلحه

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

أول ستين ثانية: ثلاث حقائق تطمئنك

• الرفض يعني «لم تُسجَّل»، لا «مخالفة». لم يُنشأ عنها التزام ضريبي عند الهيئة، ولا سجل مخالفة باسمك.
• المهلة تُحسب من الإصدار لا من الرفض. إن أصدرت الفاتورة الساعة العاشرة صباحًا ورُفضت الحادية عشرة، فأمامك حتى العاشرة من الغد لتبليغها مصحّحة.
• لا تحتاج إشعارًا دائنًا. الإشعار الدائن يصحّح فاتورة مُسجَّلة، وهذه لم تُسجَّل. أرسل الفاتورة نفسها بعد التصحيح.

أين يقع سبب الرفض في رد الهيئة

الهيئة لا ترسل رسالة نصية، بل كائن JSON فيه validationResults وداخله ثلاث قوائم. هذا رد رفض حقيقي:

{
  "validationResults": {
    "infoMessages":    [{ "code": "XSD_ZATCA_VALID", "status": "PASS"  }],
    "warningMessages": [],
    "errorMessages":   [{ "code": "BR-CUSTOM-VALIDATION-01",
                          "category": "KSA",
                          "status": "ERROR" }],
    "status": "ERROR"
  },
  "reportingStatus": "NOT_REPORTED"
}

ثلاثة أشياء تُقرأ من هذا الرد:

• errorMessages — هنا سبب الرفض. ما في هذه القائمة هو ما أوقف فاتورتك.
• warningMessages — ملاحظات لم تمنع القبول. لا تضيّع وقتك فيها قبل إصلاح الأولى.
• XSD_ZATCA_VALID بحالة PASS — بنية ملف XML سليمة تمامًا. الرفض جاء من قاعدة عمل لا من صيغة الملف، وهذا يوفّر عليك البحث في المكان الخطأ.
• reportingStatus: NOT_REPORTED — الفاتورة لم تُسجَّل، فمهلة الـ24 ساعة تعمل ضدك الآن.

إن لم يعرض نظامك هذا الرد الخام، فهذه مشكلة في نظامك لا في الهيئة: بلا الكود لا يمكن معرفة السبب، والتخمين يستهلك المهلة.

«مقبولة مع تحذيرات»: مقبولة فعلًا؟

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

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

الأكواد التي توقف الفواتير عمليًا

لكل كود من هذه صفحة تشرح معناه وسببه وخطوات تصحيحه، بنص الرسالة الرسمي من الهيئة:

رقم البائع الضريبي = رقم المشتري

BR-CUSTOM-VALIDATION-01 — أنت أصدرت فاتورة لنفسك. السبب دائمًا بيانات لا مفهوم: عميل افتراضي في نقطة البيع أُنشئ بنسخ بيانات المنشأة، أو بيانات تجريبية بقيت في سجل العميل، أو محاولة إصدار فاتورة بين فرعين. وهذا من أكثر ما نراه فعليًا في ردود الرفض.

البصمة والعدّاد: سلسلة الفواتير

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

• BR-KSA-26 — بصمة الفاتورة السابقة بصيغة غير صحيحة (hex بدلًا من Base64 هو أشيع سبب).
• BR-KSA-61 — البصمة غير موجودة في الفاتورة أصلًا.
• BR-KSA-33 — عدّاد الفاتورة (ICV) مفقود أو مُصفَّر أو مكرر.

الأرقام الضريبية

• BR-KSA-40 — رقم البائع: 15 خانة تبدأ وتنتهي بالرقم 3.
• BR-KSA-44 — رقم المشتري: نفس القاعدة، ومتى يجب أن يُترك فارغًا.
• BR-KSA-F-13 — المعرّف الإضافي (سجل تجاري أو ترخيص) بقيمة لا تناسب نوعه.

العنوان الوطني

• BR-KSA-09 — عنوان البائع ناقص. أكثر عنصر ناقص هو الحي، لأنه لا يوجد في معظم المستندات التجارية.
• BR-KSA-66 — الرمز البريدي ليس 5 خانات، وغالبًا لأن الرقم الإضافي (4 خانات) كُتب مكانه.

نوع المستند وترميز المعاملة

• BR-KSA-05 — نوع الفاتورة: ثلاث قيم فقط مقبولة، ولا يوجد نوع «فاتورة ملغاة».
• BR-KSA-06 — ترميز المعاملة بسبع خانات (NNPNESB)، وهو من أكثر الحقول التي تُملأ خطأ.
• BR-KSA-56 — إشعار دائن أو مدين بلا مرجع للفاتورة الأصلية.

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

متى يكون الخطأ في بياناتك ومتى في نظامك

هذا أهم تصنيف في المقالة، لأنه يحدد هل تستطيع الإصلاح بنفسك أم لا:

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

افحص فاتورتك بنفسك الآن

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

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

قائمة تحقّق قبل إعادة الإرسال

1. اقرأ الكود من errorMessages لا من رسالة نظامك.
2. افتح صفحة الكود وتحقق: هل يرفض الفاتورة أم تحذير؟
3. صحّح المصدر لا الفاتورة. إن كان العنوان ناقصًا فأصلحه في إعدادات المنشأة، وإلا تكرر الرفض في كل فاتورة.
4. تأكد أن العدّاد لم يُستهلك مرتين. الفاتورة المرفوضة استهلكت قيمة عدّاد؛ التالية تأخذ الرقم الذي بعده.
5. استخدم بصمة آخر فاتورة قُبلت، لا بصمة المرفوضة.
6. أعد الإرسال وتحقق من الحالة صراحةً — لا تفترض النجاح لأن الطباعة نجحت.

الخلاصة

الفاتورة المرفوضة مشكلة يوم واحد إن قرأت الكود، ومشكلة شهر إن خمّنت. أكواد الأرقام والعناوين تصلحها أنت في دقائق؛ وأكواد البصمة والعدّاد والتوقيع يصلحها نظام يبنيها صحيحة من البداية.

هذا ما يفعله ZATCA Tools: البصمة والعدّاد والترميز والتوقيع تُبنى تلقائيًا ولا يوجد حقل تكتبه، والفاتورة تُتحقَّق منها قبل إرسالها للهيئة، وحالة كل فاتورة تُعرض صراحةً — مقبولة، أو مقبولة مع تحذيرات، أو مرفوضة ومعها الكود ورابط تصحيحه.