منذ عام 2023، تُطبَّق المرحلة الثانية من التكامل مع منظومة الفاتورة الإلكترونية على دفعات، وبحلول 2026 أصبحت معظم المنشآت المسجلة في ضريبة القيمة المضافة داخل المملكة مشمولة بها. ومع ذلك، لا يزال حجم حالات الرفض وفشل التصديق في المرحلة الثانية الذي نلاحظه لدى المنشآت الصغيرة والمتوسطة يوحي بأن كثيرًا منها تعاملت مع تاريخ الربط باعتباره خط نهاية، لا التزامًا تشغيليًا مستمرًا. وفيما يلي أين تكمن الفجوات فعليًا.
1. الخلط بين "امتلاك نظام فوترة" و"الامتثال لمتطلبات زاتكا"
تستخدم منشآت كثيرة برمجيات تُنتج فاتورة PDF تحمل رمز استجابة سريعة (QR) وتفترض أن ذلك يحقق متطلبات المرحلة الثانية. هذا غير صحيح. تتطلب المرحلة الثانية إصدار الفواتير بصيغة XML منظّمة (UBL 2.1)، موقّعة رقميًا، وبالنسبة للفواتير الضريبية القياسية، يجب تصديقها (Clearance) مع زاتكا في الوقت الفعلي قبل إصدارها للعميل. أما الفواتير الضريبية المبسّطة (غالبًا للبيع للمستهلك) فيتم الإبلاغ عنها (Reporting) خلال 24 ساعة بدلاً من التصديق الفوري، لكن كلا المسارين يتطلبان صيغة XML المنظّمة، لا مجرد ملف PDF يحمل رمز QR. النظام الذي ينتج المستند المرئي فقط هو أداة من المرحلة الأولى ترتدي ملصق المرحلة الثانية.
2. اعتبار رمز الاستجابة السريعة القصة الكاملة للامتثال
رمز الاستجابة السريعة مهم، لكنه ملخّص مُرمّز بصيغة TLV — اسم البائع، الرقم الضريبي، الطابع الزمني، إجمالي الفاتورة، مبلغ الضريبة — وليس آلية الامتثال بحد ذاتها. نلاحظ بانتظام فواتير يحمل فيها رمز QR بيانات صحيحة، لكنها صادرة عن نظام محاسبي لم يُدمج فعليًا مع واجهة برمجة تطبيقات زاتكا للتصديق أو الإبلاغ. رمز QR عرَض للامتثال، لا سببه.
3. فجوات في الترقيم التسلسلي
يتحقق نظام زاتكا من الترقيم التسلسلي الخالي من الفجوات، مع معرّف فريد (UUID) وقيمة عداد الفاتورة (ICV) على كل مستند. المنشآت التي تُصدر فواتير من أكثر من نظام — نقطة بيع في الصندوق ونظام محاسبي منفصل للخدمات، مثلاً — تكسر هذا الشرط غالبًا دون أن تلاحظ، لأن كل نظام يُرقّم بشكل مستقل. الحل ليس حلاً بديلاً مؤقتًا، بل نظام مرجعي واحد لترقيم الفواتير، أو عداد متزامن بشكل صحيح بين الأنظمة.
4. حساب ضريبة القيمة المضافة بدقة "تقريبية"
الدقة "التقريبية" تفشل في التدقيق. أخطاء التقريب الناتجة عن الأرقام العشرية (Floating-point) التي تُظهر فرقًا بضع هللات بين إجمالي الفاتورة وبند الضريبة والمبلغ المُرمّز في رمز QR من أكثر أسباب الرفض شيوعًا التي نلاحظها، خصوصًا لدى المنشآت التي بَنت فوترتها على جدول بيانات عام أو أداة محاسبية عامة معدّلة بشكل بسيط، بدلاً من نظام يحسب الضريبة بوحدات صحيحة ثابتة منذ البداية.
5. افتراض أن مزوّد البرمجية المحاسبية معتمد من زاتكا
القول التسويقي "جاهز لمتطلبات زاتكا" شيء، والربط الرسمي عبر منظومة عمليات التكامل مع "فاتورة" شيء آخر. قبل موعد ربطك القادم، تحقق من أن مزوّدك أتم فعليًا عملية ربط الجهاز/الحل مع زاتكا — لا أن موقعه الإلكتروني يذكر فقط عبارة "متوافق مع زاتكا". إن لم يستطع إطلاعك على عملية تصديق أو إبلاغ ناجحة لمنشأة بحجم منشأتك، فهذا الادعاء غير مُثبَت.
6. غياب خطة لمستندات ثنائية اللغة وصحيحة الاتجاه
لا تُلزم المرحلة الثانية بفواتير باللغة العربية فقط، لكن المشترين السعوديين — والمدققين السعوديين بشكل متزايد — يتوقعون مستندًا يُقرأ بشكل صحيح بالعربية، بتنسيق صحيح من اليمين إلى اليسار في الفاتورة الضريبية، لا ترجمة لاحقة مُضافة. البرمجيات المصممة أساسًا لسوق آخر ثم أُضيف إليها تسمية عربية أو اثنتان تُظهر ذلك تحديدًا في أول ما ينظر إليه المدقق: الإجماليات، وتفصيل الضريبة، وبيانات البائع والمشتري.
أين يترك هذا أصحاب المنشآت الصغيرة والمتوسطة
لا يتطلب أي مما سبق تطبيق نظام تخطيط موارد مؤسسات (ERP) ضخم. ما يتطلبه هو التعامل مع الفوترة الإلكترونية كبنية تحتية — نظام واحد يجمع ترقيم الفواتير، وحساب الضريبة، وتوليد XML، والتصديق مع زاتكا، بشكل صحيح، في كل مرة — بدلاً من مربّع اختيار يُنجز مرة واحدة عند الربط.
هذه بالضبط الفجوة التي بُني Wahabooks لسدّها: منظومة فوترة ومحاسبة ثنائية اللغة للمنشآت السعودية، تُصدر فيها كل فاتورة وتُوقَّع وتُصدَّق بشكل صحيح افتراضيًا، مع حساب ضريبة القيمة المضافة بوحدات هللة صحيحة تمامًا لا بتقريب عشري. إن لم تكن واثقًا من أن إعدادك الحالي سينجو من تدقيق زاتكا اليوم، اطلب عرضًا توضيحيًا وسنُريك كيف يبدو الامتثال الافتراضي فعليًا.