في الفاتورة الاعتيادية يُصدر البائع فاتورته بنفسه عن سلعة باعها أو خدمة قدّمها. لكن منظومة الفوترة الإلكترونية في السعودية تسمح بحالة معاكسة تمامًا: أن يصدر المشتري الفاتورة الضريبية نيابةً عن البائع. هذا النمط اسمه الفوترة الذاتية (Self-Billing)، وفيه يتولّى المشتري بناء المستند وتوقيعه وإرساله للمقاصة باسم البائع، بناءً على اتفاقية مكتوبة سابقة بينهما. على مستوى ملف XML، هذه الحالة لها راية خاصة في رمز النوع، واتفاقية تحكمها، وتوزيع مسؤولية مختلف عن الفاتورة الاعتيادية.
هذا الدليل التقني موجَّه للمطوّرين والمحاسبين التقنيين الذين يريدون فهم الفوترة الذاتية (Self-Billing) من الداخل: متى يحقّ للمشتري أن يصدر الفاتورة، وكيف تُرفع راية الفوترة الذاتية داخل خاصية name في حقل InvoiceTypeCode، ومن يحمل معرّف الختم CSID ويوقّع، وكيف توزَّع المسؤولية القانونية بين البائع والمشتري المُصدِر. يندرج هذا الدليل ضمن سلسلة التوثيق التقني للفوترة الإلكترونية.
يبني برنامج الفاتورة الإلكترونية من قيود الفاتورة بحقولها الإلزامية كاملة تلقائيًا، فلا تحتاج لكتابة XML بيدك. لكن فهم متى تُرفع راية الفوترة الذاتية، ومن يتحمّل التزام التوقيع والإرسال، يساعدك على ضبط الاتفاقية مع مورّدك، وقراءة الفاتورة المُولَّدة بدقة قبل اعتمادها.
الفرق الجوهري عن الفاتورة الاعتيادية ليس في محتوى الفاتورة، بل في هوية مُصدِرها. التوريد توريد البائع، والفاتورة فاتورته قانونًا، لكن من بناها ووقّعها وأرسلها هو المشتري. لذلك تحتاج المنظومة إشارة تقول إن مُصدِر هذا المستند هو المشتري لا البائع. هذه الإشارة هي راية الفوترة الذاتية، وهي ما يميّز هذا النوع داخل XML.
من المهم ألا نخلط بين الفوترة الذاتية والفوترة عبر طرف ثالث. في الفوترة الذاتية يصدر المشتري الفاتورة، أي أن مُصدِرها طرف داخل عملية البيع نفسها. أما في الفوترة عبر طرف ثالث (Third Party Billing) فالمُصدِر طرف خارج العملية تمامًا: ليس بائعًا ولا مشتريًا، بل وكيل تشغيلي أو منصة فوترة. هذا التمييز يقود اختلاف الخانة المرفوعة في رمز النوع، واختلاف من تقع عليه المسؤولية.
نتناول في هذا الدليل خمسة محاور تميّز الفوترة الذاتية: راية الفوترة الذاتية في رمز النوع، والاتفاقية التي تحكم العلاقة، ومن يحمل معرّف الختم CSID ويوقّع، وكيف توزَّع المسؤولية بين البائع والمشتري، والفرق العملي عن الفوترة عبر طرف ثالث. ثم نجمعها في مثال مستند، ونختم بأكثر الأخطاء البنيوية تكرارًا في هذا النمط.
راية الفوترة الذاتية: كيف يعرف النظام أن المُصدِر مشترٍ؟
يبدأ تمييز هذا النوع من الحقل نفسه الذي يميّز كل الفواتير: InvoiceTypeCode في الترويسة. القيمة 388 تعني «فاتورة ضريبية» بمعيار UBL، وخاصية name تحمل سلسلة من سبعة أرقام كل خانة فيها راية تصف صفة في الفاتورة. الخانتان الأوليان تحدّدان النوع: 01 فاتورة قياسية موجَّهة لمنشأة، و02 فاتورة مبسّطة موجَّهة لفرد. أما رايات الحالات الخاصة فتأتي في الخانات الخمس التالية.
راية الفوترة الذاتية تعيش في الخانة السابعة (الأخيرة) من السلسلة. عندما يصدر المشتري الفاتورة نيابةً عن البائع، تُرفع هذه الخانة من 0 إلى 1. ففاتورة قياسية اعتيادية تقرأ سلسلتها 0100000، بينما فاتورة قياسية صادرة عن المشتري بالفوترة الذاتية تقرأ 0100001. الرقم السابع هو الفارق الوحيد المرئي في الراية، لكنه يغيّر معنى المستند للمنظومة كليًا.
ترتيب الخانات السبع ثابت ومعروف في معيار الهيئة. الخانة الأولى والثانية للنوع، ثم الخانة الثالثة لراية الطرف الثالث، فالرابعة للفاتورة الصورية (Nominal)، فالخامسة للتصدير، فالسادسة للفاتورة المجمّعة (Summary)، فالسابعة لراية الفوترة الذاتية. لذلك يختلف موضع راية الفوترة الذاتية (الخانة السابعة) عن موضع راية الطرف الثالث (الخانة الثالثة)، رغم أن كليهما يصف من أصدر الفاتورة بدل البائع.
هذه الراية لا تغيّر كون الفاتورة قياسية أو مبسّطة. يمكن أن يصدر المشتري المنشأة فاتورة قياسية ذاتية عن مشترياته فتقرأ السلسلة 0100001، أو فاتورة مبسّطة ذاتية فتقرأ 0200001. الخانتان الأوليان تبقيان تصفان النوع، والخانة السابعة وحدها تعلن أن المُصدِر مشترٍ يصدر عن مورّده.
الدرس هنا أن راية الفوترة الذاتية صفة تكميلية تُضاف فوق نوع الفاتورة، لا نوع مستقل بذاته. المنظومة تقرأ السلسلة كاملة: النوع أولًا، ثم الرايات الخاصة. رفع الخانة السابعة يخبر المنظومة أن تتوقّع توقيعًا من شهادة المشتري، وأن تربط الفاتورة باتفاقية فوترة ذاتية قائمة، لا أن تتعامل معها كفاتورة أصدرها البائع بنفسه.
كتابة هذه السلسلة يدويًا مدخل مباشر للأخطاء، لأن خانة واحدة خاطئة تقلب معنى المستند. لو رُفعت الخانة الثالثة بدل السابعة لأعلنت المنظومة طرفًا ثالثًا لا فوترة ذاتية. أي محرّر فواتير سليم يبني الراية آليًا بناءً على إعداد الحساب: إذا كان الحساب مهيّأً كمشترٍ يصدر ذاتيًا عن مورّد، يرفع النظام الخانة السابعة دون تدخّل المستخدم.
الخانتان 1–2: نوع الفاتورة (قياسية/مبسّطة)
الخانة 3: الفوترة عبر طرف ثالث
الخانة 7: الفوترة الذاتية (المشتري يصدر)
0100000 اعتيادية ← 0100001 فوترة ذاتية
الاتفاقية المسبقة: شرط لا إجراء لاحق
لا يجوز للمشتري أن يصدر فاتورة باسم البائع لمجرد رغبته في ذلك. الأساس القانوني للفوترة الذاتية اتفاقية مكتوبة بين البائع والمشتري تنصّ صراحةً على أن المشتري مخوَّل بإنشاء الفواتير الضريبية عن مشترياته من هذا البائع، وتوقيعها وإرسالها للمقاصة نيابةً عنه. هذه الاتفاقية شرط سابق لرفع الراية، لا إجراء لاحق يُكمَّل بعد الإصدار.
تشترط الهيئة في هذا الترتيب عدة عناصر جوهرية. يجب أن يكون البائع والمشتري كلاهما مسجّلين في ضريبة القيمة المضافة، وأن تحدّد الاتفاقية نطاق التوريدات التي تشملها الفوترة الذاتية، وأن يقرّ البائع بأنه لن يصدر فواتير عن التوريدات نفسها حتى لا تتكرر الفاتورة عن المعاملة الواحدة. هذا الإقرار المتبادل هو ما يمنع ازدواج الفاتورة بين الطرفين.
على مستوى المستند، لا تظهر الاتفاقية نصًّا داخل XML، لكن أثرها يظهر في طرفين: راية الفوترة الذاتية المرفوعة في رمز النوع، وهوية الشهادة التي وُقّعت بها الفاتورة. المنظومة لا تطلب إرفاق الاتفاقية مع كل فاتورة، لكنها تتوقّع أن يكون البائع قد فوّض المشتري فعلًا، وأن تكون شهادة التوقيع مسجّلة للمشتري المُصدِر لا للبائع.
هذا يعني أن إعداد الفوترة الذاتية يبدأ خارج لحظة الإصدار. قبل أن تصدر أول فاتورة ذاتية، يجب أن تكون الاتفاقية قائمة، وأن يكون المشتري قد استخرج شهادة الختم الخاصة به من الهيئة، وأن يكون نظامه مهيّأً لربط فواتير هذا المورّد بحسابه كمُصدِر ذاتي. هذه التهيئة المسبقة هي ما يجعل الراية صادقة عندما تُرفع.
من يحمل معرّف الختم CSID ويوقّع؟
معرّف الختم CSID شهادة تشفير تُصدرها الهيئة لكل جهة على حدة بعد تسجيلها في منصة فاتورة. في الفوترة الذاتية، المشتري هو من يبني الفاتورة ويوقّعها، فيوقّع بشهادته هو لا بشهادة البائع. الشهادة تثبت للمنظومة أن من بنى المستند ووقّعه هو هذا المشتري تحديدًا، وأن الراية المرفوعة صادقة.
التمييز عملي ومهم. لو رفع المشتري راية الفوترة الذاتية لكنه وقّع بشهادة البائع لا بشهادته، لظهر تعارض بين الراية والتوقيع، فتردّ المنظومة المستند. الراية تعلن «مشترٍ أصدر هذا ذاتيًا»، والتوقيع يجب أن يثبت أن المشتري نفسه هو من وقّع. اتساق الراية مع الشهادة شرط لقبول الفاتورة.
قسم البائع داخل المستند لا يتغيّر رغم ذلك. الرقم الضريبي للبائع وعنوانه يبقيان في عنصر AccountingSupplierParty كما لو أصدر الفاتورة بنفسه، لأن التوريد توريده والفاتورة فاتورته قانونًا. والمشتري يبقى في عنصر AccountingCustomerParty كطرف المعاملة. الذي يختلف هو الشهادة التي وُقّع بها المستند والراية التي تعلن أن الإصدار تمّ ذاتيًا من جهة المشتري. البائع صاحب الفاتورة، والمشتري مُصدِرها.
هذا الفصل بين «صاحب الفاتورة» و«مُصدِرها» هو جوهر النمط. مصنع كبير يشتري مواد خام من عشرات الموردين الصغار قد يفوّض نفسه بإصدار الفواتير عنهم، فيوقّعها كلها بشهادته الواحدة، بينما يبقى كل مورّد هو البائع المعرَّف في فاتورته. الراية والشهادة معًا تخبران المنظومة بهذا الترتيب دون لبس.
المشتري يبني الفاتورة بيانات البائع داخلها
يوقّع بشهادته CSID ويرفع علم الخانة 7
المقاصة أو الإبلاغ عبر منصة فاتورة
البائع يبقى مالك التوريد
توزيع المسؤولية بين البائع والمشتري
المشتري المُصدِر مسؤول عن الجانب التقني: بناء المستند وفق المعيار، والتوقيع بشهادته الصحيحة، ورفع راية الفوترة الذاتية في الخانة السابعة، والإرسال للمقاصة في وقتها. إذا أصدر المشتري فاتورة ببنية خاطئة أو بتوقيع غير صالح، فالخلل التشغيلي مسؤوليته، حتى لو ظلّت المسؤولية القانونية عن التوريد على البائع.
يبقى البائع مسؤولًا عن صحة بيانات التوريد التي تُبنى عليها الفاتورة: القيمة، ونسبة الضريبة، ووصف السلعة أو الخدمة. لا يعفيه تفويض المشتري بالإصدار من مسؤوليته عن صحة ما تتضمّنه فاتورته، لأنها فاتورته هو قانونًا. لذلك تشترط الاتفاقية عادةً آلية يراجع بها البائع الفواتير الصادرة عنه ذاتيًا، أو يعترض عليها خلال مدة محدّدة.
كذلك تتعامل المعاملات التصحيحية مع المسؤولية بالمنطق نفسه. عند إصدار إشعار دائن أو مدين ذاتيًا، يرث الإشعار راية الفوترة الذاتية وشهادة المشتري ذاتها، ويربط بالفاتورة الأصلية التي يصحّحها. يبقى البائع مسؤولًا عن صحة التصحيح، والمشتري مسؤولًا عن إصداره التقني السليم. هذا الاتساق بين الفاتورة وإشعاراتها التصحيحية شرط لقبول المنظومة لها معًا.
هذا التوزيع يجعل الفوترة الذاتية ترتيبًا يحتاج ثقة وانضباطًا بين الطرفين. البائع يسلّم جزءًا من سيطرته على إصدار فواتيره للمشتري، والمشتري يتحمّل عبء بناء المستند سليمًا. لذلك ينتشر هذا النمط أكثر في علاقات التوريد المستقرّة طويلة الأمد، حيث المشتري طرف كبير منظّم والموردون أطراف صغيرة متكرّرة.
دع النظام يبني راية الفوترة الذاتية نيابةً عنك
يبني قيود سلسلة InvoiceTypeCode الصحيحة ويوقّع بشهادتك ويرسل للمقاصة تلقائيًا، فلا تكتب XML بيدك ولا تخطئ في موضع الراية بين الخانة الثالثة والسابعة.
الفرق العملي عن الفوترة عبر طرف ثالث
يخلط كثير من المطوّرين بين الفوترة الذاتية والفوترة عبر طرف ثالث، لأن كليهما يصدر فيه طرف غير البائع الفاتورة. لكن الفرق جوهري ويظهر في موضع الراية ومن يحملها. في الفوترة الذاتية المُصدِر هو المشتري، طرف داخل المعاملة، والراية في الخانة السابعة. في الفوترة عبر طرف ثالث المُصدِر وكيل خارج المعاملة، والراية في الخانة الثالثة.
يترتّب على هذا الفرق اختلاف في الشهادة أيضًا. في الفوترة الذاتية يوقّع المشتري بشهادته، وهو طرف معرَّف في الفاتورة نفسها ضمن قسم المشتري. في الفوترة عبر طرف ثالث يوقّع الوكيل بشهادته، وهو طرف لا يظهر في قسمي البائع والمشتري إطلاقًا، بل يظهر أثره فقط في الراية والتوقيع. هذا يجعل قراءة المستندين مختلفة عند التدقيق.
الجدول التالي يلخّص الفروق الثلاثة الأبرز بين النمطين:
| الوجه | الفوترة الذاتية (Self-Billing) | الفوترة عبر طرف ثالث (Third Party) |
|---|---|---|
| من يُصدر؟ | المشتري (طرف داخل المعاملة) | وكيل أو منصة (طرف خارج المعاملة) |
| موضع الراية | الخانة السابعة (مثل 0100001) |
الخانة الثالثة (مثل 0110000) |
| شهادة التوقيع | شهادة المشتري المُصدِر | شهادة الوكيل |
يمكن نظريًا أن تجتمع الرايتان في فاتورة واحدة لو أصدر وكيل فاتورة ذاتية نيابةً عن مشترٍ، فترتفع الخانتان الثالثة والسابعة معًا. لكن هذه حالة نادرة ومتقدّمة، والأصل أن ترفع كل حالة رايتها وحدها. الأهم أن تعرف أن موضع الراية ليس تفصيلًا شكليًا، بل هو ما يحدّد كيف تقرأ المنظومة المستند ومن تتوقّع توقيعه.
| المعيار | الفوترة الذاتية | طرف ثالث |
|---|---|---|
| جهة الإصدار | المشتري | وكيل/طرف خارجي |
| موقع العلم | الخانة 7 (0100001) | الخانة 3 (0110000) |
| حامل الشهادة | المشتري | الطرف الثالث |
الفوترة الذاتية في الفواتير القياسية والمبسّطة
راية الفوترة الذاتية تعمل فوق نوع الفاتورة لا بدلًا منه، فتظهر في النوعين القياسي والمبسّط. لكل نوع منهما مسار اعتماد وتوقيت مختلف، وراية الفوترة الذاتية لا تغيّر هذا المسار، بل تضيف صفة المُصدِر فوقه.
في الفاتورة القياسية الموجَّهة لمنشأة، يبني المشتري المستند برفع الخانة السابعة، فتقرأ السلسلة 0100001. يرسل المشتري الفاتورة للمقاصة الفورية قبل تسليمها، فتتحقق منصة فاتورة من البنية والحقول والتوقيع والراية، ثم تعيد الفاتورة مختومة باعتمادها. عندها فقط تكون الفاتورة سارية، ويسلّمها المشتري أو يحفظها بصفته مُصدِرها عن البائع.
أما في الفاتورة المبسّطة الموجَّهة لفرد، فتقرأ السلسلة 0200001، ويسلّمها المشتري فورًا دون انتظار المقاصة، ثم تُبلَّغ بها الهيئة خلال أربع وعشرين ساعة. الفرق أن المبلِّغ هنا هو المشتري المُصدِر، فهو من يتحمّل التزام الإبلاغ في موعده. تأخّر الإبلاغ أو إغفاله يقع على المشتري لا البائع، لأن المشتري هو من تولّى الإصدار.
هذا يعني أن من يفوّض نفسه بالفوترة الذاتية يرث التزامات الإصدار كاملة بحسب نوع الفاتورة: المقاصة الفورية في القياسية، والإبلاغ خلال أربع وعشرين ساعة في المبسّطة. لا يكفي أن يبني المستند سليمًا، بل عليه أن يلتزم بالمسار الزمني الذي يحدّده النوع، وإلا اعتُبر مخلًّا بالتزام كان على البائع لولا التفويض.
لذلك يجب أن يكون نظام المشتري قادرًا على التفريق بين النوعين آليًا. إذا كان المورّد منشأة مسجّلة، تبني الفاتورة قياسية وتمرّ بالمقاصة. وإذا كانت المعاملة موجَّهة لفرد، تبني الفاتورة مبسّطة وتُبلَّغ بها لاحقًا. الخلط بين النوعين يرفع الخانة الخطأ في الخانتين الأوليين، فترفض المنظومة المستند حتى لو كانت راية الفوترة الذاتية في موضعها الصحيح.
متى تختار الفوترة الذاتية؟
الفوترة الذاتية ليست خيارًا افتراضيًا لكل علاقة توريد، بل ترتيب يناسب حالات محدّدة. ينتشر هذا النمط حين يكون المشتري طرفًا كبيرًا منظّمًا يتعامل مع موردين كثر صغار، فيكون أقدر منهم على بناء الفواتير سليمة وإرسالها في وقتها. مصانع تشتري مواد خام من مزارع أو ورش صغيرة مثال متكرّر على ذلك.
يستفيد البائع الصغير من هذا الترتيب لأنه يعفيه من عبء بناء فاتورة متوافقة وإرسالها للمقاصة، خاصة إذا لم يكن لديه نظام فوترة إلكترونية مهيّأ. ويستفيد المشتري الكبير لأنه يضمن أن الفواتير الواردة إليه مبنية بالشكل الذي يناسب أنظمته، فلا ينتظر تصحيحات من موردين متفاوتي القدرة التقنية.
في المقابل، يتحمّل المشتري في هذا الترتيب عبئًا تقنيًا وقانونيًا أكبر. عليه أن يحفظ شهادته، ويبني كل فاتورة سليمة، ويلتزم بمسار المقاصة أو الإبلاغ، ويحتفظ بالاتفاقيات الموقّعة مع كل مورّد. لذلك لا يُنصح بالفوترة الذاتية إلا حين يكون حجم التوريد كبيرًا بما يبرّر هذا العبء، ويكون المشتري مجهّزًا بنظام يتولّى رفع الراية والتوقيع والإرسال نيابةً عنه.
مثال مستند فوترة ذاتية
لنجمع ما سبق في مستند واحد مختصر. الفاتورة التالية فاتورة قياسية صادرة ذاتيًا عن المشتري: لاحظ راية الفوترة الذاتية المرفوعة في السلسلة 0100001، وقسم البائع الذي يحمل بيانات البائع الأصلي لا المشتري، وقسم المشتري الذي يحمل بيانات الجهة التي بنت المستند ووقّعته.
اقرأ المستند من أعلاه: راية الفوترة الذاتية في رمز النوع تخبرك أن المُصدِر مشترٍ، ثم يأتي البائع ببياناته الأصلية في قسم البائع، ثم المشتري ببياناته في قسمه، فالبنود، فالإجماليات. عند الإرسال يوقّع المشتري المستند بشهادته الخاصة، فتعرف المنظومة أن الراية صادقة. أي تعارض بين الراية والشهادة وبيانات الأطراف يوقف المقاصة فورًا.
راية الفوترة الذاتية لا تغيّر مسار الاعتماد الذي يحدّده نوع الفاتورة. الفاتورة القياسية الموجَّهة لمنشأة تمرّ بالمقاصة الفورية (Clearance) قبل التسليم سواء أصدرها البائع أم المشتري ذاتيًا. والفاتورة المبسّطة تُسلَّم فورًا ثم تُبلَّغ بها الهيئة خلال أربع وعشرين ساعة. ما يحدّد المسار هو نوع الفاتورة لا هوية مُصدِرها.
أكثر الأخطاء البنيوية تكرارًا
معظم حالات الرفض في هذا النمط تعود إلى عدم اتساق الراية مع التوقيع أو الإعداد. هذه أكثر الأخطاء تكرارًا وكيف تقرأها:
- راية مرفوعة بلا اتفاقية: رُفعت الخانة السابعة دون اتفاقية فوترة ذاتية قائمة أو دون تهيئة الحساب، فظهرت فاتورة تعلن فوترة ذاتية لا أساس لها.
- توقيع بشهادة البائع لا المشتري: رُفعت راية الفوترة الذاتية لكن المستند وُقّع بمعرّف ختم البائع، فظهر تعارض بين الراية والشهادة.
- راية في الخانة الخطأ: رُفعت الراية في الخانة الثالثة بدل السابعة، فقرأتها المنظومة راية طرف ثالث لا فوترة ذاتية، فاختلّ معنى المستند كليًا.
- ازدواج الفاتورة: أصدر المشتري فاتورة ذاتية عن التوريد، وأصدر البائع فاتورة عن التوريد نفسه، فتكرّرت الفاتورة الواحدة عن معاملة واحدة.
لاحظ أن هذه الأخطاء تتركّز في موضعين: راية رمز النوع، وشهادة التوقيع. نادرًا ما تُرفض فاتورة ذاتية بسبب البنود أو الإجماليات، لأن هذه أقسام مشتركة مع كل الفواتير. أما الراية في الخانة السابعة والشهادة العائدة للمشتري فهما ما يميّز هذا النمط، وهنا يقع الخطأ غالبًا. ضبط جودة الفوترة الذاتية يبدأ من ضبط الاتفاقية وإعداد حساب المشتري وشهادته قبل إصدار أي فاتورة.
القاعدة الحاكمة: الراية والتوقيع والاتفاقية يجب أن تتسق معًا. الفاتورة التي تعلن أن مشتريًا أصدرها ذاتيًا يجب أن تُوقَّع بشهادة ذلك المشتري، وأن تستند إلى اتفاقية فوترة ذاتية قائمة، وأن تحمل بيانات البائع الأصلي في قسم البائع، وإلا رفضتها المقاصة قبل أن تصل البائع.
كيف يساعدك قيود
تكمن صعوبة الفوترة الذاتية في موضع الراية والشهادة، وهما تحديدًا ما يتولّاه النظام عنك دون تدخّل يدوي:
- تحديد النوع تلقائيًا: يبني قيود سلسلة
InvoiceTypeCodeالصحيحة حسب نوع الفاتورة وإعداد الحساب، ويرفع الخانة السابعة عند الفوترة الذاتية دون أن تكتب السلسلة بيدك. - توقيع بالشهادة الصحيحة: يوقّع النظام كل مستند بمعرّف الختم CSID العائد لحسابك المُصدِر، فيضمن اتساق الراية مع الشهادة الذي تشترطه المقاصة.
- إرسال للمقاصة في وقته: يرسل قيود الفاتورة القياسية للمقاصة الفورية، ويبلّغ عن المبسّطة خلال أربع وعشرين ساعة، وفق المسار الذي يحدّده نوع الفاتورة.
- الإشعارات التصحيحية: يبني الإشعارات الدائنة والمدينة براية الفوترة الذاتية نفسها وربطها بالفاتورة الأصلية، فتبقى متّسقة معها.
للفرق التقني أثر مباشر على من يبنون تكاملًا برمجيًا. إذا كنت تطوّر نظامًا يصدر فواتير ذاتية عن مورّديك، فعليك أن ترفع الراية في الخانة السابعة لا الثالثة، وأن توقّع كل مستند بشهادتك أنت لا بشهادة البائع، وأن تضع بيانات البائع الصحيحة في قسم البائع وبياناتك في قسم المشتري. خلط هذه العناصر هو السبب الأشيع لفشل المقاصة في هذا النمط، لأن المنظومة ترفض التعارض بين الراية والشهادة وبيانات الأطراف.
لمزيد من السياق التقني حول بنية الفاتورة وحقولها، راجع دليل ترويسة الفاتورة (Invoice Header) في XML الذي يشرح كل حقل في الترويسة بصياغته الفعلية، ودليل فواتير B2B بين المنشآت تقنيًا الذي يتناول نوع الفاتورة القياسية ومسار اعتمادها. الفوترة الذاتية تبني فوق هذين الأساسين برفع راية واحدة في الخانة السابعة، وبتغيير من يوقّع ويرسل، مع بقاء بنية المستند كما هي.
