المرحلة الثانية من الفوترة الإلكترونية (زاتكا): الدليل التقني المرجعي

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

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

• هيئة الزكاة والضريبة والجمارك، معيار تطبيق الفاتورة الإلكترونية XML، الإصدار 1.2 (بتاريخ 2023-05-19) — PDF
• الإرشادات الفنية التفصيلية للفوترة الإلكترونية، الإصدار 2 — PDF
• الإرشادات التفصيلية للفوترة الإلكترونية، الإصدار 2 — PDF
• دليل مستخدم بوابة المطوّرين، الإصدار 3 — PDF
• اللائحة التنفيذية لنظام ضريبة القيمة المضافة (الإصدار الثامن) — PDF

المرحلة الأولى والمرحلة الثانية مشكلتان مختلفتان

المرحلة الأولى (الإصدار)، السارية منذ 4 ديسمبر 2021، طرحت سؤالًا متواضعًا: هل يستطيع نظامك إصدار فاتورة إلكترونية منظّمة تحمل رمز استجابة سريعة، وأن يتوقف عن إصدار الفواتير اليدوية؟ أجابت أغلب المنشآت عن هذا السؤال بترقية نقاط البيع أو برنامج المحاسبة ومضت في طريقها.

أما المرحلة الثانية (الربط والتكامل) فتطرح سؤالًا آخر: هل يستطيع نظامك أن يتحدث إلى أنظمة الهيئة؟ وهي نافذة اعتبارًا من 1 يناير 2023، وتُطبَّق على مجموعات مستهدفة من المكلفين على شكل موجات. وفي مسألة التوقيت، النص واضح ومتكرر في ثلاثة مواضع مستقلة من الإرشادات التفصيلية: «سيتم إشعار المجموعات المستهدفة قبل ستة أشهر على الأقل»، و«ستُشعر الهيئة المكلفين بموجة المرحلة الثانية الخاصة بهم قبل ستة أشهر على الأقل عبر البريد الإلكتروني والرسائل النصية المسجلة لدى الهيئة».

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

التصفية مقابل الإشعار: مفترق واحد، ونظامان مختلفان

هذا أهم قرار معماري في المرحلة الثانية، وهو ليس مسألة تفضيل. نوع المستند هو ما يحدده.

المصدر: الإرشادات الفنية التفصيلية، الإصدار 2، أقسام عمليتَي الإشعار والتصفية.

نتيجتان يغفل عنهما المهندسون كثيرًا.

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

الثانية: بإمكان الهيئة تعطيل التصفية. تنص الإرشادات الفنية: «إذا عطّلت الهيئة خاصية التصفية، فيمكن حتى للمستندات القياسية (B2B) أن تُقدَّم عبر واجهة الإشعار. وفي هذه الحالة لا تختم منصة الهيئة المستندات القياسية». وتضيف الأسئلة الشائعة أن المستند المُقدَّم عندئذٍ إلى واجهة التصفية سيُعيد استجابة تحويل 303، ويجب إعادة تقديمه عبر واجهة الإشعار. فإن كان تكاملك يعامل الرمز 303 كخطأ قاتل، فسينكسر يوم تستخدم الهيئة هذا المفتاح.

المستند: UBL 2.1 ورمزان يخلط بينهما الجميع

فواتير المرحلة الثانية هي XML بصيغة UBL 2.1. ويشترط معيار التطبيق أن «تُكتب أسماء الوسوم والخصائص بشكل صحيح وأن تتبع تسلسل UBL 2.1»، وأن «تكون جميع عناصر UBL 2.1 الإلزامية موجودة».

ثلاثة حقول في الترويسة تسبب أغلب الالتباس:

• cbc:ProfileID (BT-23) — القاعدة BR-KSA-EN16931-01: يجب أن تكون قيمة عملية الأعمال «reporting:1.0». هي سلسلة ثابتة، لا تتغير بتغير نوع المستند، ولا تصبح clearance:1.0 في حالة B2B. لا وجود لهذه القيمة في المعيار إطلاقًا.
• cbc:InvoiceTypeCode (BT-3) — نوع المستند: 388 فاتورة، 383 إشعار مدين، 381 إشعار دائن. وتشترط القاعدة BR-KSA-17 أن يتضمن الإشعار المدين أو الدائن «سبب إصداره (KSA-10)».
• cbc:InvoiceTypeCode/@name (KSA-2) — نوع المعاملة. وهي السلسلة ذات السبعة أحرف التي يخطئ فيها الجميع، وهي موضوع القسم التالي.

الحقلان BT-3 وKSA-2 يسكنان العنصر نفسه في XML: أحدهما قيمة العنصر، والآخر خاصية @name فيه. يجيبان عن سؤالين مختلفين، وليسا قابلين للتبادل.

فك شفرة KSA-2: البنية NNPNESB

تنص القاعدة BR-KSA-06 حرفيًا على أن «رمز معاملة الفاتورة (KSA-2) يجب أن يوجد وأن يحترم البنية التالية: NNPNESB»، حيث:

المصدر: معيار تطبيق XML، الإصدار 1.2، القاعدة BR-KSA-06، وتنطبق على /ubl:Invoice/cbc:InvoiceTypeCode/@name.

أمثلة عملية، مفكوكة حرفيًا من الجدول أعلاه:

خرافة 0211000 — ولماذا تنقض نفسها بنفسها

تنتشر القيمة 0211000 على نطاق واسع بوصفها «رمز الفوترة الذاتية». فُكّها بمقتضى BR-KSA-06 وستجدها تقول عكس ما تدّعي:

• الموضعان 1–2 = 02 ← فاتورة مبسطة
• الموضع 3 = 1 ← طرف ثالث
• الموضع 4 = 1 ← صورية
• الموضعان 5 و6 = 0
• الموضع 7 = 0 ← الفوترة الذاتية: خطأ (غير مفعّلة)

الرمز الذي يُفترض أنه يعني «ذاتية الإصدار» يحمل علم الفوترة الذاتية مُطفأً. وهو فوق ذلك يضبط النوع على «مبسطة»، وهو أمر باطل بذاته كما سيتبيّن في القسم التالي. إن وجدت 0211000 في شيفرتك، فهي ليست فاتورة ذاتية الإصدار، بل فاتورة مبسطة صورية عبر طرف ثالث — ولن تفعل ما تظنه.

القيمة الصحيحة للفاتورة الضريبية القياسية ذاتية الإصدار هي 0100001.

الفوترة الذاتية كما ينبغي أن تُنفَّذ

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

أولًا: موافقة الهيئة المسبقة شرط نظامي. اللائحة التنفيذية لضريبة القيمة المضافة، المادة الثالثة والخمسون (الفواتير الضريبية)، الفقرة (2):

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

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

وتقول الإرشادات الفنية للهيئة الشيء نفسه بلغة تشغيلية: «المستندات القياسية (B2B) في حالة الفوترة الذاتية يقدّمها المشتري. ومن الإلزامي أن يكون البائع والمشتري طرفين في اتفاقية فوترة ذاتية معتمدة من الهيئة.»

لا يمكنك تفعيل الفوترة الذاتية لمجرد أن نظام تخطيط الموارد لديك يحوي خانة اختيار لها. رفع ذلك العلم دون موافقة الهيئة تعرّضٌ ضريبي، لا خيار إعدادات. (والمادة الثالثة والخمسون نفسها، الفقرة (3)، تفرض الشرط ذاته «بشرط موافقة الهيئة» على الفواتير الصادرة عبر طرف ثالث — وهو الموضع 3 من KSA-2. الانضباط نفسه مطلوب.)

ثانيًا: الفوترة الذاتية للأعمال فقط (B2B). وصف معيار XML لمؤشرات الفاتورة قاطع: «ذاتية الإصدار — الفاتورة يصدرها المشتري بدلًا من المورّد. وهي لا تنطبق إلا في سيناريوهات B2B. ولا أثر لها على الحقول، غير أنه يجب أن تنص الفاتورة على أنها ذاتية الإصدار.»

وهذا مفروض بنيويًا لا وصفيًا فحسب. فالقاعدة BR-KSA-31 تنص على أنه في الفواتير المبسطة وإشعاراتها («KSA-2، الموضعان 1 و2 = 02») «لا يُقبل إلا ما يلي: طرف ثالث (الموضع 3 = 1)، وتوريد صوري (الموضع 4 = 1)، والمعاملات الملخّصة (الموضع 6 = 1)». الموضع 7 ليس في القائمة. لذا لا يمكن أن يستقر علم الفوترة الذاتية على مستند من نوع 02 بأي حال — فالمعيار لا يترك له مسارًا.

ثالثًا: لا تجتمع الفوترة الذاتية مع التصدير. القاعدة BR-KSA-07: «الفوترة الذاتية غير مسموح بها (KSA-2، الموضع 7 لا يمكن أن يكون "1") لفواتير التصدير (KSA-2، الموضع 5 = 1)». فالقيمة 0100101 باطلة بحكم التركيب.

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

الختم التشفيري وسلسلة التجزئة وعدّاد الفاتورة ورمز QR

الختم التشفيري

تحدد الإرشادات الفنية التفصيلية استخدام ECDSA على منحنى secp256k1 مع تجزئة SHA-256. والمثال العملي في الإرشادات نفسها يستخدم openssl ecparam -name secp256k1 -genkey لتوليد المفتاح الخاص، وopenssl req -new -sha256 -key privateKey.pem لتوليد طلب توقيع الشهادة. وتوجب القاعدة BR-KSA-60 وجود الختم التشفيري (KSA-15) في الفواتير الضريبية المبسطة وإشعاراتها. وتوجب BR-KSA-28 أن يتضمن الختم — إن وُجد — القيمة الدقيقة urn:oasis:names:specification:ubl:signature:1 لمعرّف معلومات التوقيع.

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

PIH — تجزئة الفاتورة السابقة

القاعدة BR-KSA-61: «يجب أن توجد تجزئة الفاتورة السابقة (KSA-13) في الفاتورة». والقاعدة BR-KSA-26: «إذا تضمنت الفاتورة تجزئة الفاتورة السابقة (KSA-13)، فيجب أن تكون هذه التجزئة SHA256 مُرمّزة بـ base64».

انتبه بدقة إلى ماهية BR-KSA-26: إنها قاعدة صيغة. تقول إن قيمة PIH يجب أن تكون SHA-256 مُرمّزة بـ base64. وهي ليست قاعدة تقول «سلسلة التجزئة لديك لا تطابق سجلات الهيئة». أما دلالات سلامة السلسلة فتقع في إرشادات الأسئلة الشائعة، وفيها أكثر قاعدة يُغفل عنها في المرحلة الثانية:

«في المثال أعلاه، يجب أن تكون تجزئة الفاتورة السابقة للمستند 3 هي تجزئة المستند 2، حتى لو كان المستند 2 مرفوضًا.»

السلسلة تشمل المستندات المرفوضة. إذا رفضت الهيئة المستند 2، تبقى تجزئة المستند 2 هي PIH للمستند 3. والتطبيقات التي «تتراجع» بالسلسلة عند الرفض — فتعيد استخدام PIH الخاص بالمستند 2 للمستند 3 — تفقد التزامن مع الهيئة وتفسد كل مستند تالٍ. هذا هو الخلل الذي يحوّل بعد ظهيرة سيئة إلى ربع سنة سيئ.

ICV — عدّاد الفاتورة

القاعدة BR-KSA-33: «يجب أن تحتوي كل فاتورة على قيمة عدّاد الفاتورة (KSA-16)». والقاعدة BR-KSA-34: «قيمة عدّاد الفاتورة (KSA-16) تحتوي على أرقام فقط».

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

«لا يجوز إعادة استخدام قيمة عدّاد الفاتورة. فمتى صدر مستند بقيمة عدّاد معينة (ICV)، لا يجوز ذكر تلك القيمة في مستند آخر. وينبغي أن يكون للمستند الجديد عدّاده الخاص.»

و:

«يجب أن يكون لكل مستند تجزئته وقيمة عدّاده الخاصة به. ولا ينبغي تغيير أو تحديث تجزئة المستند المرفوض وقيمة عدّاده.»

فالخلاصة: لا تُعِد استخدام قيمة عدّاد، ولا تُعِد كتابة عدّاد مستند مرفوض، وامنح كل مستند جديد عدّادًا جديدًا. ومن يقتبس لك رقم قاعدة BR-KSA بدعوى أنها تعني «العدّاد غير متزايد»، فاسأله: في أي وثيقة؟

تباين الرفض الذي لا يوثّقه أحد

هذه نقطة دقيقة وردت في الأسئلة الشائعة للهيئة، وشقّاها مختلفان:

• رفض الإشعار (المبسطة): الفاتورة المصححة «ينبغي أن تتضمن تجزئة ومعرّف UUID وقيمة عدّاد وطابعًا زمنيًا جديدة خاصة بها. ويبقى تاريخ الفاتورة كما هو وقت وقوع المعاملة.»
• رفض التصفية (القياسية): الفاتورة المصححة «ينبغي أن تتضمن تجزئة ومعرّف UUID وقيمة عدّاد وطابعًا زمنيًا جديدة خاصة بها. ويجب تحديث تاريخ الفاتورة، لأن الفاتورة غير المصفّاة لا تُعدّ فاتورة ضريبية صحيحة من منظور الهيئة.»

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

رمز الاستجابة السريعة (QR)

إلزامي، مُرمَّز بـ Base64، بحد أقصى 700 حرف، ومبني بصيغة Tag-Length-Value (TLV): الوسم في بايت واحد، وطول مصفوفة بايتات UTF-8 في بايت واحد، ثم القيمة. الحقول ووسومها، من القسم 6 من الإرشادات الفنية التفصيلية:

وتوجب القاعدة BR-KSA-27 أن يتضمن المستند «رمز QR (KSA-14)، وأن يكون هذا الرمز base64Binary».

تسجيل شهادة الختم (CSID): نقاط النهاية الحقيقية

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

لاحظ ما ليس في الجدول: لا يوجد /compliance/csids، ولا يوجد /renew. التجديد هو PATCH على المسار ذاته /production/csids الذي يُصدر الشهادة. فإن كان تكاملك يستدعي نقطة نهاية اسمها /renew، فهو يستدعي شيئًا لم تنشره الهيئة.

الترويسات والأجسام كما هي موثّقة

• Accept-Version — إلزامية. ينص الدليل: «V2 يشير إلى إصدار الواجهات المستخدم وينبغي ذكره في الاستدعاءات (V2 هو الإصدار الصالح الوحيد حاليًا)».
• OTP — ترويسة إلزامية في استدعاء شهادة الامتثال وفي استدعاء تجديد الشهادة الإنتاجية، ويصفها الدليل بأنها «كلمة مرور لمرة واحدة تُولَّد من بوابة فاتورة».
• Accept-Language — «اللغات المدعومة حاليًا هي الإنجليزية (en) والعربية (ar)، والافتراضي الإنجليزية».
• Authorization — أساسية (Basic). وللإنتاج ينص الدليل صراحةً: «شغّل واجهة شهادة الامتثال للحصول على «binarySecurityToken» لاستخدامه اسم مستخدم، و«secret» كلمة مرور».

أجسام الطلبات، من أمثلة الدليل ذاته:

• POST /compliance ← { "csr": "<CSR بترميز base64>" }
• POST /production/csids ← { "compliance_request_id": "1234567890123" }
• POST /invoices/reporting/single ← «يجب أن يحتوي جسم الطلب على قيمتين: الأولى invoiceHash والثانية invoice».

والاستدعاء الناجح للإشعار يُعيد HTTP 200 مع كائن يحوي invoiceHash وstatus (مثل "Reported") وwarnings وerrors.

تسلسل التسجيل

1. ولّد زوج مفاتيح وطلب توقيع شهادة (CSR) مطابقًا لمواصفة الهيئة (secp256k1).
2. احصل على كلمة مرور لمرة واحدة (OTP) من بوابة فاتورة.
3. POST /compliance مع الـ CSR وترويسة OTP ← تحصل على شهادة الامتثال (CCSID) ورقم compliance_request_id.
4. نفّذ فحوصات الامتثال عبر POST /compliance/invoices بمصادقة شهادة الامتثال. والدليل واضح في أن هذه الفحوصات شرط سابق: طلب الشهادة الإنتاجية «سيُعيد استجابة غير صالحة إلى أن تكتمل» هذه الفحوصات.
5. POST /production/csids مع compliance_request_id ← تحصل على الشهادة الإنتاجية (PCSID).
6. استخدم الشهادة الإنتاجية لمصادقة استدعاءات التصفية والإشعار.
7. جدّد عبر PATCH /production/csids (بترويسة OTP) قبل انتهاء الصلاحية.

قواعد تحقق يمكنك الاستشهاد بها فعلًا

تُعيد منصة الهيئة معرّفات قواعد بصيغة BR-KSA-nn (قواعد المملكة) و**BR-KSA-EN16931-nn** (تجاوزات المملكة لمجموعة قواعد EN 16931). ويؤكد دليل بوابة المطوّرين ترتيب الأسبقية: تتحقق واجهة التصفية من «1. الامتثال لمخطط UBL2 XSD. 2. مجموعة فرعية من قواعد EN 16931. 3. مجموعة القواعد الخاصة بالمملكة. وتَجُبّ قواعد المملكة قواعد EN 16931 في حال وجود القاعدة نفسها في المجموعتين.»

كل قاعدة في الجدول التالي منقولة من معيار تطبيق XML الإصدار 1.2، دون إعادة صياغة تغيّر المعنى:

وخذ BR-KSA-15 دراسةَ حالة. إنها قاعدة عن تاريخ التوريد. ولم تكن يومًا قاعدة عن عدّاد الفاتورة. فإن أخبرك دليلٌ أو مورّدٌ أو تذكرة دعم بأن BR-KSA-15 تعني «العدّاد غير متزايد»، فذلك الدليل لا يقرأ المعيار — وكل ما يقوله لك بعد ذلك يستحق القدر نفسه من الشك.

أشياء لا وجود لها

نقولها صراحةً، لأنها تتردد في أدلة متداولة وتكلّف ساعات هندسية حقيقية:

• PINT-KSA. كلمة «PINT» ترد صفر مرة في معيار تطبيق XML، وفي الإرشادات الفنية التفصيلية، وفي الإرشادات التفصيلية للفوترة الإلكترونية. PINT بناء يخص Peppol، ولم تتبنَّه الهيئة. لا توجد مواصفة اسمها «PINT-KSA» تمتثل لها.
• رموز أخطاء بصيغة ZATCA-INV-nnn أو ZATCA-CRT-nnn. صفر ورود في الوثائق الثلاث. معرّفات التحقق لدى الهيئة هي BR-* وBR-KSA-* وBR-KSA-EN16931-*.
• نقطة نهاية /compliance/csids أو /renew. غير موجودتين في دليل بوابة المطوّرين. راجع جدول نقاط النهاية أعلاه.
• clearance:1.0 كقيمة ProfileID. القاعدة BR-KSA-EN16931-01 تثبّت BT-23 على reporting:1.0 مهما كان نوع المستند.

الحفظ والسيادة: الجزء الذي يبقى بعد انتهاء المشروع

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

• 66(1): «الفواتير والدفاتر والسجلات والمستندات المحاسبية المطلوب الاحتفاظ بها من الشخص الخاضع للضريبة… يجب حفظها مدة لا تقل عن ست (6) سنوات من نهاية الفترة الضريبية التي تتعلق بها.»
• 66(2): «تُحفظ السجلات باللغة العربية، وتُصدر جميع الفواتير الضريبية باللغة العربية إضافةً إلى أي لغة أخرى تظهر عليها كترجمة.»
• 66(3): «…تُحفظ الفواتير والسجلات والمستندات داخل المملكة، إما ماديًا أو إلكترونيًا عبر الوصول إلى الخادم أو قواعد البيانات المخزَّنة عليها من خلال نقطة طرفية أو نقطة وصول داخل المملكة.»

ولنكن دقيقين بشأن 66(3)، فكثيرًا ما يُبالَغ في تأويلها. هي لا تقول بهذه العبارات إن الخادم يجب أن يكون ماديًا داخل السعودية في كل حال — بل تتحدث عن الحفظ الإلكتروني «عبر الوصول إلى الخادم أو قواعد البيانات… من خلال نقطة طرفية أو نقطة وصول داخل المملكة»، وتسري «دون إخلال بأي نظام أو لائحة أو تعليمات سارية في المملكة تتعلق بحفظ السجلات والمستندات، أو التعاملات الإلكترونية، أو الأمن السيبراني». وقد تُلزمك أنظمة أخرى — نظام حماية البيانات الشخصية، وضوابط الهيئة الوطنية للأمن السيبراني في القطاعات المنظَّمة — بما هو أشد من المادة 66 وحدها.

وما ليس فيه لبس: عليك ست سنوات من سجلات قابلة للاسترجاع، بالعربية، عصيّة على العبث، ويمكن للهيئة طلبها. وتوجب المادة 66(3) اتخاذ «التدابير الأمنية اللازمة والضوابط الكافية القابلة للمراجعة والفحص لمنع العبث بالفواتير والمستندات والسجلات الإلكترونية».

وأبسط طريقة للوفاء بالتزام حفظٍ داخل المملكة هي أن تحفظ السجلات داخل المملكة. فإن كان النظام الذي يولّد فواتيرك الإلكترونية أو يؤرشفها يعمل اليوم على بنية تحتية في فرانكفورت أو فرجينيا، فهذا سؤال ستُسأله يومًا ما — من مراجع، أو من فريق مشتريات عميل، أو من مجلس إدارتك. «سكاي لاين كلاود» مستضافة في السعودية، بفوترة بالريال، ودعم بالعربية، ونسخ احتياطي يومي، وشهادة SSL مجانية ذاتية التجديد على كل الباقات. ابدأ تجربتك المجانية 14 يومًا — دون بطاقة ائتمانية.

ولنكن صريحين بالقدر نفسه فيما لسنا عليه: «سكاي لاين» مزوّد استضافة سحابية مُدارة وخدمات سحابية للأعمال. نحن نستضيف الأنظمة والسجلات. لا نبيع تكامل تصفية مع الهيئة، وهذا الدليل ليس بديلًا عن قراءتك للمعيار ولا عن استشارة ضريبية مهنية.

الأسئلة الشائعة

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

ما رمز معاملة الفاتورة (KSA-2) الصحيح للفاتورة ذاتية الإصدار؟ 0100001 — النوع 01 (فاتورة ضريبية قياسية) مع رفع الموضع السابع (علم الفوترة الذاتية) إلى 1، وفق BR-KSA-06. أما 0211000 المتداولة فخاطئة: تضبط النوع على «مبسطة» وتترك علم الفوترة الذاتية عند 0.

هل يمكنني إصدار فاتورة مبسطة (B2C) ذاتية الإصدار؟ لا. ينص معيار XML على أن الفوترة الذاتية «لا تنطبق إلا في سيناريوهات B2B»، وتسمح BR-KSA-31 على مستندات 02 بأعلام الطرف الثالث والتوريد الصوري والملخّصة فقط. لا يوجد تمثيل صحيح لفاتورة مبسطة ذاتية الإصدار.

هل أحتاج إلى إذن الهيئة للفوترة الذاتية؟ نعم. المادة 53(2) من اللائحة التنفيذية تجعلها «بشرط موافقة الهيئة»، وتشترط اتفاقًا مسبقًا، وأن تنص الفاتورة على أنها صادرة من العميل نيابةً عن المورّد، وأن يكون الطرفان مسجَّلين في ضريبة القيمة المضافة. وتكرر الإرشادات الفنية أن اتفاقية الفوترة الذاتية المعتمدة من الهيئة إلزامية.

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

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

ما المنحنى وخوارزمية التجزئة المستخدمان في الختم؟ ECDSA على منحنى secp256k1 مع SHA-256، بحسب الإرشادات الفنية التفصيلية.

هل هناك مواصفة PINT-KSA يلزمني دعمها؟ لا. كلمة «PINT» لا ترد إطلاقًا في معيار تطبيق XML ولا في الإرشادات الفنية التفصيلية ولا في الإرشادات التفصيلية للفوترة الإلكترونية.

كم مدة حفظ الفواتير الإلكترونية وأين؟ ست سنوات على الأقل من نهاية الفترة الضريبية المعنية، بالعربية، وداخل المملكة — المادة 66(1) و66(2) و66(3) من اللائحة التنفيذية.

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

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

قراءات ذات صلة: نظام حماية البيانات الشخصية السعودي — الدليل العملي للامتثال · معيار أرامكو SACS-002: ما تطلبه أرامكو فعلًا من المقاولين · سيادة البيانات والاستضافة السحابية في السعودية · باقات استضافة سكاي لاين كلاود · سكاي لاين كلاود في الرياض