لماذا ترفض الهيئة فاتورتي الإلكترونية؟ هو السؤال الأكثر تكرارًا مؤخرًا

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

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

• تشخيص 8 أكواد خطأ موثقة من API زاتكا وما الذي يُحفّز كل خطأ والخطوات الدقيقة لحله دون تعطيل تدفق الفواتير.
• تحديد متى يكون التخليص الفوري إلزامياً ومتى تنطبق نافذة الإبلاغ خلال 24 ساعة، والمخاطر الامتثالية الجسيمة الناجمة عن الخلط بينهما.
• كيفية ربط الإشعارات الدائنة والمدينة بـ UUID الفاتورة الأصلية بشكل صحيح (الحقل الواحد المسؤول عن أكثر من 70% من حالات رفض الإشعارات)
• لماذا ملف PDF ليس فاتورتك القانونية وما يعنيه معيار PDF/A-3b مع XML المدمج لمخاطر التدقيق الضريبي على منشأتك.

مرحلة الربط والتكامل: الامتثال التقني هو التحدي الجديد

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

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

لفهم حجم التحدي، كفى أن نعلم أن المرحلة الثانية تستلزم من كل منشأة الحصول على شهادة CSID لكل جهاز فوترة (EGS)، وتوليد UUID فريد لكل فاتورة، وتضمين رمز QR بصيغة TLV في كل فاتورة مبسطة، وحفظ سلسلة رقمية تسلسلية لا يمكن كسرها بين جميع الفواتير، وأرشفة كل وثيقة بصيغة PDF/A-3 مع تضمين XML أصيل داخلها.

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

لماذا تُعاني الشركات في المرحلة الثانية رغم وجود نظام محاسبي جيد؟

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

فيما يلي الأسباب الأكثر شيوعاً للرفض التي ترصدها فواتير واثق من خلال عمل مباشر مع مئات الشركات السعودية في مختلف موجات التفعيل:

• غياب نظام مركزي لإدارة UUID وتتبع رقم التسلسل (ICV)
• انتهاء صلاحية شهادة CSID دون تجديد مسبق أو تنبيه تلقائي.
• ترميز QR/TLV غير مكتمل أو مفقود فيه أحد الحقول الخمسة الإلزامية.
• ربط إشعارات الدائن والمدين بـ UUID خاطئ أو بفاتورة لم تُرفع بعد.
• حفظ الفاتورة بصيغة PDF عادية بدون تضمين XML المعتمد من زاتكا.
• تجاوز نافذة الـ 24 ساعة في رفع الفواتير المبسطة B2C.

أشهر أخطاء التكامل: الأسباب والحلول التفصيلية

تُصنَّف أخطاء زاتكا إلى ثلاث فئات رئيسية: أخطاء القواعد التجارية (BR)، وأخطاء التحقق من المخطط (Schema Validation)، وأخطاء البنية التحتية (Infrastructure). الفئة الأولى هي الأكثر تكراراً في مرحلة التكامل، وتشمل الأخطاء التي نستعرضها هنا تفصيلاً.

1. تضارب المعرّفات الفريدة UUID وانكسار سلسلة رقم التسلسل ICV ⚠ KSA-9 / BR-KSA-31

السبب الجذري: يتطلب كل مستند — سواء كان فاتورة ضريبية أو مبسطة أو إشعاراً دائناً أو مدياناً — معرّفاً فريداً عالمياً (UUID) مولَّداً وفق معيار RFC 4122. وبالتوازي، يجب أن يحمل كل مستند رقماً تسلسلياً (ICV) يزيد بمقدار 1 عن المستند السابق بصرامة. ينشأ الخطأ عند ترحيل البيانات من نظام قديم، أو عند وجود أكثر من خادم إصدار، أو عند حذف فاتورة من قاعدة البيانات مع الإبقاء على رقم تسلسلها في الذاكرة.

2. انتهاء صلاحية الختم الرقمي أو استخدام رمز تفعيل منتهٍ أو خاطئ ⚠ CSID Expiry / OTP Mismatch — رمز التفعيل

السبب الجذري: الختم الرقمي (CSID) هو شهادة X.509 تُصدرها زاتكا لكل جهاز فوترة مسجَّل (EGS). مدة صلاحية الشهادة عادةً سنة واحدة. بعد انتهاء صلاحيتها، يرفض API منصة فاتورة جميع الإرسالات القادمة من ذلك الجهاز بخطأ 401 Unauthorized. كذلك، عند تهيئة جهاز جديد، يُولَّد رمز تفعيل (OTP) عبر منصة فاتورة مدته 60 دقيقة فقط — استخدام OTP منتهٍ يُفشل عملية التسجيل كلياً ويستلزم بدء دورة تسجيل جديدة من الصفر.

3. ترميز TLV ناقص أو خاطئ في رمز QR — حقول إلزامية مفقودة ⚠ TLV Encoding Error / QR-VAL

السبب الجذري: تعتمد الفاتورة المبسطة على رمز QR مُرمَّز بصيغة TLV (Tag-Length-Value) يجب أن يحتوي بالترتيب الصحيح على خمسة حقول إلزامية: الوسم 01 اسم البائع، الوسم 02 رقم التسجيل الضريبي (TRN)، الوسم 03 تاريخ ووقت الإصدار بتنسيق ISO 8601، الوسم 04 إجمالي الفاتورة شاملاً ضريبة القيمة المضافة، والوسم 05 قيمة ضريبة القيمة المضافة. أي خطأ في ترتيب الوسوم أو في طول الحقل (Length) أو في القيم أو في التشفير بـ Base64 يُنتج رمز QR لا يجتاز تحقق زاتكا.

4. خطأ في التحقق من مخطط XML — نموذج UBL 2.1 المعدَّل ⚠ XML Schema Validation / UBL-2.1

السبب الجذري: تشترط زاتكا أن تكون كل فاتورة ملفاً XML يستوفي بدقة مخطط UBL 2.1 المعدَّل بمتطلبات زاتكا الخاصة. الأخطاء الشائعة: غياب مساحة الاسم الصحيحة (namespace)، أو ترتيب العناصر خاطئ وفق مخطط XSD، أو وجود قيم null في حقول إلزامية كـ InvoiceTypeCode أو TaxAmount، أو استخدام ترميز نصي خاطئ (يجب UTF-8 بدون BOM). كذلك أي حقل مُوسَّع (extension) يُضاف لغرض التوقيع أو الختم الرقمي يجب أن يتوافق مع مخطط ZATCA-extension المحدد.

جدول المرجع السريع لأخطاء الفوترة الإلكترونية (ZATCA API)



دليل مسارات سير العمل

الفرق الجوهري بين مسار التخليص الفوري ومسار الإبلاغ

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

أولاً: مسار التخليص الفوري — الفاتورة الضريبية القياسية B2B

في مسار التخليص، تُرسَل الفاتورة إلى زاتكا أولاً قبل أن تُسلَّم إلى المشتري. الخطوات التشغيلية الصحيحة هي:

• إنشاء ملف XML للفاتورة مستوفياً لجميع حقول UBL المطلوبة.
• توقيع XML بالتوقيع الإلكتروني للبائع باستخدام شهادة CSID.
• إرسال XML الموقّع إلى نقطة نهاية API الخاصة بالتخليص في منصة فاتورة.
• انتظار استجابة زاتكا التي تتضمن XML مُختوماً بختم زاتكا الرقمي.
• تضمين الـ XML المختوم في ملف PDF/A-3b ثم تسليم الفاتورة للمشتري.

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

ثانياً: مسار الإبلاغ — الفاتورة الضريبية المبسطة B2C وقاعدة 24 ساعة

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

تحديٌ عملي مهم: الشركات التي تعمل بحجم مرتفع من الفواتير المبسطة — كقطاع التجزئة ومحطات الوقود والمطاعم — قد تصدر آلاف الفواتير يومياً. إدارة إرسال هذا الحجم ضمن نافذة 24 ساعة تستلزم نظام إرسال دُفعي (Batch Reporting) موثوقاً ومُصمَّماً للمقياس العالي. فواتير واثق تتولى هذا بمحركها المدمج للإبلاغ الدُّفعي التلقائي.

مقارنة فواتير زاتكا: الفاتورة الضريبية (B2B) ضد الفاتورة المبسطة (B2C)



مقارنة بين ربط الإشعارات الدائنة والمدينة بالفوترة

الربط الصحيح بالفاتورة الأصلية — لماذا يُرفض معظمها؟

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

من الناحية التقنية، يُشترط أن يتضمن XML الإشعار الدائن أو المدين عنصر المرجع (BillingReference) يحمل UUID الفاتورة الأصلية بدقة حرفية تامة. UUID هي سلسلة من 36 حرفاً بصيغة محددة (8-4-4-4-12)، وأي خطأ حتى في حرف واحد يُنتج رفضاً فورياً من API زاتكا. علاوةً على ذلك، يجب أن تكون الفاتورة المرجعية قد مرّت بمسار التخليص أو الإبلاغ بنجاح قبل إصدار الإشعار عليها. لا يمكن إصدار إشعار دائن على فاتورة لم تُرفع بعد لمنصة فاتورة.

الحالات التي تُسبب رفض الإشعارات

• UUID الفاتورة الأصلية غير صحيح أو مكتوب بأحرف كبيرة بدلاً من صغيرة أو العكس.
• الفاتورة الأصلية لا تزال في حالة مسوّدة (Draft) ولم تُرسَل لزاتكا.
• استخدام رقم الفاتورة (Invoice Number) بدلاً من UUID في حقل BillingReference
• نوع الوثيقة (DocumentTypeCode) خاطئ — 383 للإشعار الدائن، 381 للمدين.
• سبب الإصدار (ReasonCode) غير مُدرج ضمن القائمة المعتمدة من زاتكا.
• قيم الإشعار تتجاوز قيمة الفاتورة الأصلية دون تسلسل منطقي.

تتحقق فواتير واثق أوتوماتيكياً من UUID المرجعي مقابل قاعدة بيانات الفواتير الداخلية وتُؤكد حالة الفاتورة الأصلية (مُخلَّصة أو مُبلَّغ عنها) قبل السماح بإصدار الإشعار. كما تُطبّق واثق رموز نوع الوثيقة وأسباب الإصدار الصحيحة تلقائياً وفق أكواد UBL المعتمدة من زاتكا.



الجاهزية للتدقيق الضريبي

PDF/A-3 وتضمين XML — من هو الوثيقة القانونية الحقيقية؟

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

معيار PDF/A-3 هو إصدار مُتخصَّص من تنسيق PDF مُصمَّم خصيصاً للأرشفة طويلة الأمد. الفارق الجوهري عن PDF العادي هو قدرة PDF/A-3 على تضمين ملفات مرفقة داخل بنية PDF نفسها كجزء من المواصفة. عندما تُدمج ملف XML الصادر من زاتكا (والمُختوم رقمياً) داخل ملف PDF/A-3b، فأنت تُنشئ وثيقة ثنائية الطبقة: طبقة بصرية يقرأها الإنسان، وطبقة قانونية تقرأها الأنظمة وتتحقق منها.

ما الذي يبحث عنه مدقق زاتكا في الأرشيف؟

خلال أي تدقيق ضريبي مرتبط بالمرحلة الثانية، يحق لهيئة زاتكا طلب الاطلاع على أي فاتورة من خلال قراءة XML المدمج مباشرةً والتحقق من:

• صحة التوقيع الإلكتروني للبائع وتطابقه مع CSID المسجَّل.
• صحة ختم زاتكا الرقمي وتاريخ التخليص أو الإبلاغ.
• تطابق Hash الفاتورة مع القيمة المسجلة في الختم الرقمي.
• اكتمال جميع الحقول الإلزامية في نموذج UBL 2.1
• تسلسل UUID ورقم ICV بالترتيب الصحيح.

أرشيف من ملفات PDF عادية أو من XML غير مُختوم لا يُجيب على أيٍّ من هذه النقاط — وبالتالي لا يُعدّ أرشيفاً ضريبياً ممتثلاً. الشركات التي تكتشف هذا القصور أثناء التدقيق تجد نفسها في موقف قانوني بالغ الصعوبة.

يضمن وافِق أن كل فاتورة تُحفظ بتلقائية كملف PDF/A-3b مع XML المختوم من زاتكا مدمجاً داخله، وأن الأرشيف كاملاً وقابلاً للبحث وجاهزاً لأي طلب تدقيق فوري دون الحاجة لأي تحضير مسبق.

تصنيف الوثائق وحالتها القانونية (ZATCA Compliance)



زاتكا المرحلة الثانية: المعادلة الجديدة للامتثال

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

في هذا الدليل استعرضنا الأخطاء الأكثر تكراراً في مسارات API زاتكا، ومنهجية العمل الصحيحة للتخليص الفوري والإبلاغ في 24 ساعة، وكيفية التعامل مع الإشعارات الدائنة والمدينة بالطريقة الصحيحة، والإطار القانوني لأرشفة الفواتير وفق معيار PDF/A-3b. جميع هذه التعقيدات — التقنية والقانونية والتشغيلية — تحدث تلقائياً وبالكامل خلف الكواليس عند استخدام فواتير واثق.

لماذا وافِق شريكك التقني المتكامل للامتثال لمعايير هيئة الزكاة والضريبة والجمارك

يقوم نظام "وافق" المحاسبي بإزالة التعقيدات التقنية عبر أتمتة أدق متطلبات الامتثال، مما يضمن بقاء أعمالك متوافقة مع التحديثات التنظيمية دون أي تدخل يدوي.

• توليد UUID فريد وفق RFC 4122 لكل مستند تلقائياً مع سجل ICV مركزي.
• إدارة دورة حياة CSID بالكامل مع تنبيهات تجديد مُبكِّرة قبل 30 يوماً.
• بناء رمز QR بصيغة TLV المطابقة لمواصفات زاتكا مع تحقق ذاتي من الحقول الخمسة.
• إرسال فوري للفواتير القياسية B2B ومحرك إبلاغ دُفعي تلقائي للفواتير المبسطة B2C
• تحقق كامل من ربط الإشعارات الدائنة والمدينة بالفاتورة الأصلية الصحيحة.
• حفظ أرشيف PDF/A-3b مع XML مُختوم مدمج جاهز لأي تدقيق ضريبي فوري.
• دعم فني متخصص في متطلبات زاتكا من فريق مُلمّ بالتنظيم السعودي.

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

لا تواجه موجة زاتكا وحدك. دع فواتير واثق تتولى الربط والتكامل من الألف إلى الياء — وركّز أنت وفريقك المالي على ما يُحرّك أعمالك للأمام.

اقرأ أيضًا: غرامات الفوترة الإلكترونية في السعودية: كل ما تحتاج معرفته عن عقوبات الهيئة.

الأسئلة المتداولة حول فواتير الفوترة الإلكترونية مرحلة الربط والتكامل

ما هو الحد الأدنى للإيرادات للخضوع لمرحلة الربط والتكامل؟

تشمل الموجة 23 جميع الشركات التي تجاوزت إيراداتها 750,000 ريال في 2022 أو 2023 أو 2024، بموعد امتثال 31 مارس 2026. تُخطر زاتكا كل منشأة قبل 6 أشهر من موعدها. يمكن التحقق من موجتك عبر منصة فاتورة برقم التسجيل الضريبي.

ما هي غرامات عدم الامتثال للمرحلة الثانية من زاتكا؟

الغرامات تتراوح بين 5,000 ريال عن عدم إصدار الفواتير إلكترونياً، و10,000 ريال عن غياب رمز QR أو تعديل فاتورة مرسلة، وتصل إلى 50,000 ريال عن مخالفات الإبلاغ الفوري وفق المادة 45 من نظام ضريبة القيمة المضافة.

هل يمكن استخدام نظام ERP الحالي في المرحلة الثانية؟

نعم إن كان النظام يدعم التكامل عبر API، يمكن إضافة طبقة وسيطة متوافقة مع زاتكا دون استبداله. أما إن كان غير قادر على إنتاج XML بصيغة UBL 2.1 مع توقيع ECDSA، فيلزم حل متخصص كفواتير واثق.

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

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

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

تُلزم زاتكا بحفظ الفواتير لمدة 5 سنوات كحد أدنى بصيغة آمنة وقابلة للتدقيق. الصيغة الممتثلة هي PDF/A-3b مع XML مُختوم مدمج. ملفات PDF العادية بدون XML لا تستوفي هذا الشرط.

كيف أُصلح خطأ BR-KSA-31 من زاتكا؟

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

هل أحتاج CSID منفصلاً لكل فرع أو نقطة بيع؟

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

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

نعم، لكن يجب ذكر قيمة ضريبة القيمة المضافة وإجمالي الفاتورة بالريال السعودي كعملة ثانوية في XML. يجب استخدام سعر صرف ساما المعتمد في تاريخ الفاتورة وإدراجه صراحةً، وأن يعكس رمز QR القيم المعادلة بالريال.

ما الفرق بين CSID الامتثال وCSID الإنتاج؟

CSID الامتثال للاختبار فقط ولا أثر قانوني له. CSID الإنتاج للفواتير الفعلية ذات الأثر الضريبي. استخدام شهادة الامتثال على فواتير حقيقية يُنتج خطأ API-403. يجب اجتياز 12 سيناريو اختبار من زاتكا قبل طلب شهادة الإنتاج.

كيف أتعامل مع الفواتير الصادرة لمشترين غير مسجلين أو جهات حكومية؟

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