VERI*FACTU وبرمجيات الفوترة المخصصة: ما تشترطه إسبانيا بحلول 1 يناير 2027

قبل 1 يناير 2027، يجب على كل شركة في إسبانيا تقدّم إقرار ضريبة الشركات (Impuesto sobre Sociedades) وتُصدر فواتيرها ببرمجيات أن تستخدم برمجيات مكيَّفة وفق Real Decreto 1007/2023. كل فاتورة يُنشأ لها سجل بتجزئة (hash) مربوط بالسجل الذي يسبقه، ورمز QR يستطيع العميل التحقق منه لدى مصلحة الضرائب. أما بقية الخاضعين، ومعظمهم من العاملين لحسابهم الخاص، فأمامهم حتى 1 يوليو 2027.

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

المواعيد، والتأجيلان

هذه ثالث مجموعة مواعيد، فبعض التشكك مفهوم.

• Real Decreto 1007/2023 منح الشركات في الأصل مهلة حتى 1 يوليو 2025.
• Real Decreto 254/2025، الصادر في 1 أبريل 2025، نقل الموعد إلى 1 يناير 2026 لمقدمي إقرار ضريبة الشركات، وإلى 1 يوليو 2026 للبقية. وكان السبب محدداً: الأمر التقني Orden HAC/1177/2024 لم يُنشر إلا في 28 أكتوبر 2024.
• Real Decreto-ley 15/2025، الصادر في 2 ديسمبر 2025، أجّل الموعدين سنة كاملة. نصه منشور في الجريدة الرسمية BOE، وأقرّه الكونغرس في الشهر نفسه.

ومذكرة مصلحة الضرائب الإسبانية (AEAT) بشأن التمديد، المحدّثة في 26 مارس 2026، لا تحتمل اللبس: "las entidades que presenten el Impuesto sobre Sociedades deberán tener adaptados sus SIF antes del 1 de enero de 2027. El resto de obligados tributarios, antes del 1 de julio de 2027." أي إن الجهات التي تقدّم إقرار ضريبة الشركات يجب أن تكيّف أنظمة الفوترة لديها (SIF) قبل 1 يناير 2027، وبقية الملزمين قبل 1 يوليو 2027.

هل يمكن أن يتغير الموعد مجدداً؟ لا شيء رسمياً يشير إلى ذلك حتى أكتوبر 2026. التأجيل الأول كان له سبب تقني لم يعد قائماً. فخدمات الإرسال لدى AEAT تعمل في بيئة الإنتاج منذ 23 أبريل 2025، ومنذ 29 يوليو 2025 لا يجوز لمورّدي البرمجيات أن يعرضوا إلا أنظمة مكيَّفة. التخطيط على أساس تأجيل ثالث رهان، لا خطة.

أي موعد يخصك؟ الشركة من نوع SL أو SA تقدّم إقرار Impuesto sobre Sociedades، لذا فالشركة التي تشغّل نظام ERP خاصاً بها تخضع على الأرجح لموعد 1 يناير 2027. وهذا بعد أقل من ثلاثة أشهر. أما موعد يوليو فللعاملين لحسابهم الخاص ولبقية المكلفين الخاضعين.

من يقع داخل النطاق ومن لا يقع

تختصر الأسئلة الشائعة حول النطاق لدى AEAT الأمر في أربعة شروط نافية. أنت داخل النطاق إن لم تكن تفوتر يدوياً حصراً، ولم تكن ضمن نظام SII (إلزامياً أو اختيارياً)، ولم يكن موطنك الضريبي في إقليم الباسك أو نافارا، ولم تحصل على قرار إعفاء.

الاستثناءات عملياً:

• الخاضعون لنظام SII. نظام Suministro Inmediato de Información إلزامي للشركات التي تتجاوز مبيعاتها 6 ملايين يورو، ولمجموعات ضريبة القيمة المضافة، وللشركات المسجلة في سجل الاسترداد الشهري لضريبة القيمة المضافة (REDEME)، ويجوز لغيرها الانضمام اختيارياً. وتقولها AEAT بوضوح: "El ámbito subjetivo de ambos proyectos es excluyente."، أي إن نطاق الخاضعين للنظامين متنافٍ. فإن انتقلت إلى SII، توقفت عن إرسال سجلات VERI*FACTU وعن طباعة رمز QR.
• إقليم الباسك ونافارا. الشركات التي يقع موطنها الضريبي هناك تخضع للسلطات الضريبية الإقليمية (foral) وقواعدها الخاصة، لا لـ RD 1007/2023.
• الفوترة اليدوية البحتة. دفتر الفواتير الورقي خارج النطاق. وكذلك جدول البيانات المستخدم فقط لكتابة الفواتير وطباعتها وحفظها؛ أما الذي ينتج أيضاً دفاتر ضريبة القيمة المضافة لديك فليس خارجه.

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

إن كنت تفوتر من حزمة تجارية (A3 وSage وHolded وما شابهها)، فالمورّد هو المنتِج، وعليه أن يوفّر نسخة مكيَّفة مع إقراره الخاص. حدّثها، وتأكد من وجود الإقرار، ويمكنك التوقف عن القراءة هنا.

هذا المقال للبقية: نظام ERP مخصص، أو برنامج Access أو Delphi أو FileMaker كُتب قبل خمس عشرة سنة، أو وحدة فوترة داخل منصتك الإلكترونية الخاصة.

شركتك هي المنتِج

تُلقي المادة 13.1 من اللائحة مسؤولية الاعتماد على من ينتج النظام، عبر declaración responsable (إقرار المسؤولية). والأسئلة الشائعة حول الاعتماد لدى AEAT تجيب عن حالة الأنظمة الداخلية مباشرة: "Cada sistema en operación debe disponer de una Certificación emitida mediante declaración responsable de su productor (artículo 13.1 RRSIF). Si el software hubiera sido desarrollado por la propia empresa, será esta la que deba certificarlo." أي إن كل نظام قيد التشغيل يجب أن يحمل اعتماداً صادراً بإقرار مسؤولية من منتِجه، وإن كانت الشركة نفسها هي من طوّر البرمجيات، فهي من يجب أن يعتمدها.

ما يعنيه ذلك عملياً:

• لا يوجد تدقيق خارجي. تسميه AEAT "auto-certificación"، أي اعتماداً ذاتياً من المنتِج. لا أحد يوافق على نظامك مسبقاً. أنت توقّع، وأنت تُسأل عنه.
• المقاول الذي يبني لك امتداداً بوصفه منتجاً هو من يعتمد ذلك الامتداد. وإن بنيته بنفسك، فأنت من يعتمده.
• يجب أن يكون الإقرار ظاهراً داخل النظام، في كل إصدار، وأن يمكن الوصول إليه من خارجه أيضاً، بمعزل عن المنتج.
• محتواه محدد في المادة 15 من Orden HAC/1177/2024: ومن ذلك اسم النظام ومعرّفه وإصداره، ومكوّناته، وهل يعمل بنمط VERI*FACTU فقط، واسم المنتِج ورقم NIF الخاص به وعنوانه، وتاريخ التوقيع ومكانه.

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

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

وحجم المخاطرة تحدده المادة 201 bis من القانون الضريبي العام: غرامة ثابتة قدرها 150,000 يورو عن كل سنة مالية وكل نوع من الأنظمة على إنتاج أنظمة لا تستوفي المتطلبات، و50,000 يورو عن كل سنة مالية على حيازة نظام كان يجب اعتماده ولم يُعتمد، أو جرى العبث به. أيّ الغرامتين تنطبق على نظام بنيته بنفسك سؤال لمستشارك الضريبي. ولا أيّ من الرقمين صغير.

ما الذي يجب أن تفعله البرمجيات

سجل لكل فاتورة، لحظة إصدارها

تشترط المادة 9.1 أن يُنشئ النظام registro de facturación de alta (سجل فوترة للإصدار) "de forma simultánea o inmediatamente anterior a la expedición de cada factura"، أي في الوقت نفسه الذي تُصدر فيه كل فاتورة أو قبله مباشرة. والفاتورة الملغاة يُنشأ لها سجل إلغاء (registro de anulación).

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

في الأنظمة القديمة، هنا يختبئ العمل:

• تفاصيل ضريبة القيمة المضافة تُحتسب غالباً وقت الطباعة ولا تُحفظ أبداً. يجب أن تكون موجودة كبيانات لحظة الإصدار.
• "الإصدار" كثيراً ما يكون مجرد طباعة تقرير. يجب أن تكون هناك نقطة صريحة تتحول عندها المسودة إلى فاتورة، ويُنشأ السجل عندها.
• انتهى زمن إعادة استخدام الأرقام. حذف فاتورة وإعادة استخدام رقمها، وهي عادة في كثير من الأنظمة الصغيرة، يفشل الآن: ترفض AEAT السجل الثاني برسالة "Registro de facturación duplicado." (سجل فوترة مكرر). والفواتير التجريبية الصادرة في بيئة الإنتاج فواتير حقيقية ويجب إلغاؤها.
• لا أحد يعدّل السجلات. تقول الأسئلة الشائعة لدى AEAT إن التعديل المباشر في قاعدة بيانات السجلات الصادرة يجب ألا يكون عملية مسموحة. إن كان الموظفون يصلحون الفواتير اليوم بأوامر SQL، فهذا يتوقف. التصحيحات تمر عبر فواتير تصحيحية.

سلسلة التجزئة

يحمل كل سجل سلسلة السجل السابق ورقمه وتاريخه وجزءاً من بصمته (huella). الخوارزمية SHA-256، والحقول الدقيقة وطريقة ضمّها مذكورة في الوثائق التقنية لدى AEAT، إلى جانب تصاميم السجلات ومخططات XSD وملف WSDL وكتالوج التحقق والأخطاء.

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

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

ويُعرَّف كل نظام برقم NIF للمكلف، ومعرّف للنظام من حرفين، ورقم تثبيت لا يجوز أن يتكرر أبداً، حتى عند إعادة تثبيت البرمجيات نفسها على الجهاز نفسه.

رمز QR على الفاتورة

تحمل كل فاتورة رمز QR وفق ISO/IEC 18004، بمقاس يتراوح بين 30x30 و40x40 مم، بمستوى تصحيح الأخطاء M. ويرمّز رابطاً يتضمن رقم NIF للمُصدر، والسلسلة والرقم، وتاريخ الإصدار، والإجمالي، ويستطيع العميل التحقق منه لدى AEAT. وفي نمط VERI*FACTU تذكر الفاتورة أيضاً "VERI*FACTU" أو "Factura verificable en la sede electrónica de la AEAT" (فاتورة قابلة للتحقق على البوابة الإلكترونية لـ AEAT).

بالنسبة للبرمجيات القديمة، يعني هذا إعادة العمل على قالب الفاتورة (تقرير Access، أو تخطيط FileMaker، أو مولّد PDF) وإضافة مكتبة QR إلى منظومة لم تحتوِ واحدة قط.

نمطان: VERI*FACTU أو غيره

نمط VERI*FACTU. يرسل النظام كل سجل إلى AEAT تلقائياً لحظة إنشائه. وفي المقابل، تحتاج السجلات إلى تجزئة دون توقيع إلكتروني، وتحتفظ بها AEAT، والنظام الذي يعمل بهذا النمط فقط لا يحتاج إلى سجل أحداث. تحتاج إلى عميل SOAP يتصل بخدمات AEAT المنشورة، وشهادة إلكترونية مؤهلة، وطابور لحالات انقطاع الاتصال. وتعامل الأسئلة الشائعة للمطورين لدى AEAT الانقطاع كحادث عارض: تنتظر السجلات في الطابور ويُعاد إرسالها، وتستمر الفوترة.

النمط غير VERI*FACTU. تبقى السجلات لديك، ويجب توقيع كل منها (XAdES Enveloped وفق ETSI EN 319 132) بشهادة مؤهلة. ويجب أن يحتفظ النظام أيضاً بسجل أحداث موقَّع يغطي بدء التشغيل وإيقافه في هذا النمط، وفحوص الحالات الشاذة ونتائجها، واستعادة النسخ الاحتياطية والتصدير، مع حدث ملخص كل ست ساعات تشغيل على الأقل، ويجب أن يسلّم السجلات حين تطلبها AEAT.

بالنسبة لنظام مفصّل حسب الطلب، يكون نمط VERI*FACTU وحده عادة البناء الأصغر. لا بنية تحتية للتوقيع، ولا سجل أحداث، ولا أدوات لرصد الحالات الشاذة. أما النظام الذي يوفّر النمطين فعليه أن ينفّذ كل ذلك.

خطة تتسع قبل 1 يناير 2027

من بداية أكتوبر، أمام مقدّم إقرار ضريبة الشركات نحو ثلاثة عشر أسبوعاً. وهذا هو الترتيب الذي ينجح.

1. الأسبوع 1: الحصر. اسرد كل نظام يُصدر فواتير: نظام ERP، ووحدة الفوترة في المتجر الإلكتروني، وسكربت الاشتراكات، وجهاز نقطة البيع. تأكد من أنك لست ضمن SII ولا تخضع للقواعد الإقليمية (foral).
2. من الأسبوع 1 إلى الأسبوع 2: قرر من يوقّع وأي نمط تعتمد. سمِّ المنتِج لكل نظام. اختر VERI*FACTU وحده ما لم يكن لديك سبب لغير ذلك. تأكد من وجود الشهادة المؤهلة للشركة ومن وجود مسؤول عنها، لأن الأسئلة الشائعة للمطورين لدى AEAT تشير إلى أن النظام لا يعمل بدونها.
3. من الأسبوع 2 إلى الأسبوع 4: تحليل فجوات البيانات. قارن ما يخزّنه نظامك بالمادة 10 وبتصميم السجل لدى AEAT. هنا تظهر تفاصيل ضريبة القيمة المضافة الناقصة، ورموز أنواع الفواتير، ومراجع التصحيح.
4. من الأسبوع 3 إلى الأسبوع 8: البناء. إنشاء السجل عند الإصدار، والسلسلة وفحوصها، والتخزين غير القابل للتعديل، والإلغاء، ورمز QR في كل قالب، وعميل الإرسال مع طابور إعادة المحاولة. وأزِل إمكانية التعديل المباشر على السجلات الصادرة.
5. من الأسبوع 6 إلى الأسبوع 10: الاختبار. ابدأ في بيئة الاختبار لدى AEAT، ثم أرسل سجلات حقيقية. تعامل AEAT الفترة السابقة لموعدك كفترة اختبار، يجوز لك خلالها التوقف عن الإرسال والعودة إلى نظام آخر. اقرأ الأسئلة الشائعة للمطورين قبل كتابة مسارات الإلغاء والتصحيح: فهي تغطي معظم الحالات الحدّية.
6. من الأسبوع 9 إلى الأسبوع 12: الإقرار والتدريب. اكتب الـ declaración responsable، واعرضها داخل التطبيق وخارجه، وسجّل الإصدار. أبلغ الإدارة المالية أن الأرقام لا يُعاد استخدامها أبداً، وأن الأخطاء تُصحَّح بفواتير تصحيحية.
7. منتصف ديسمبر: بدء التشغيل. الموعد الذي يقول "antes del 1 de enero" (قبل 1 يناير) ليس تاريخ بدء تشغيل. ابدأ قبله بأسبوعين، حتى تظهر المشكلات الأولى ولا يزال هناك وقت.

بالنسبة لموعد 1 يوليو 2027، تنطبق الخطة نفسها بهامش أوسع. ابدأ في يناير، لا في مايو.

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

أين تحصل على المساعدة

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

إن كان موعدك 1 يناير 2027 ولديك نظام مخصص، راسلنا على office@c9group.dev. نحن مهندسون لا مستشارون ضريبيون: أسئلة النطاق والمسؤولية مكانها لدى مستشاريك، ونحن نبني وفق الجواب الذي يقدمونه.