ما هي صيغ الفاتورة الإلكترونية المعتمدة؟

الخلاصة أولاً

في المرحلة الثانية، تصدر الفاتورة بإحدى صيغتين:

XML خالص          ←  ملف بيانات منظّم تقرؤه الأنظمةPDF/A-3 + XML مضمّن  ←  مستند يقرؤه الإنسان، وبداخله ملف XML نفسه

في الحالتين، XML هو الفاتورة. ملف PDF غلاف عرض؛ البيانات النظامية والتوقيع والختم كلها في الـXML.

XML: لماذا هو الأساس

XML صيغة بيانات منظّمة: كل حقل في الفاتورة - البائع، المشتري، البنود، المبالغ، الضريبة - عنصر مسمّى في بنية محددة يمكن للأنظمة قراءته والتحقق منه آلياً. هذا ما يتيح لمنصة فاتورة أن تتحقق من كل فاتورة فور وصولها: بنية سليمة؟ حقول مكتملة؟ توقيع صحيح؟ تسلسل متصل؟

مقابل ذلك، ملف PDF عادي أو صورة فاتورة هو "منظر" فاتورة: يقرؤه الإنسان، ولا تستطيع منظومة التحقق أن تستخرج منه شيئاً موثوقاً.

PDF/A-3: لماذا هذا النوع تحديداً

PDF/A عائلة صيغ PDF مخصصة للأرشفة طويلة الأمد: عرض ثابت لا يعتمد على خطوط أو موارد خارجية قد تختفي. والفارق الجوهري في الإصدار A-3 تحديداً: يسمح بتضمين ملفات أخرى داخل المستند - وهذا ما يجعل التركيبة ممكنة: مستند واحد يفتح كـPDF لعين الإنسان، ويحمل بداخله ملف XML لعين الأنظمة.

XML المضمّن: كيف يعمل عملياً

فاتورة PDF/A-3 واحدة├── طبقة العرض: شكل الفاتورة المطبوع، الشعار، رمز QR└── مرفق داخلي: invoice.xml - الفاتورة النظامية كاملة بتوقيعها

عندما يستلم عميلك ملف الفاتورة، فهو يستلم الاثنين معاً في ملف واحد. نظامه المحاسبي يستخرج الـXML ويستورد البيانات آلياً بلا إدخال يدوي؛ وموظفه يقرأ الـPDF كأي فاتورة.

نقطة الحسم عند أي تعارض: إذا اختلف ما يعرضه الـPDF عما يحمله الـXML، فالعبرة بالـXML - هو الذي اعتُمد ووُقِّع. تعارضهما أصلاً عيب في النظام المولِّد يجب إصلاحه فوراً.

ماذا يعني هذا للمنشأة الصغيرة

أنت لا تكتب XML ولا تبني PDF/A-3 - نظام الفوترة المتوافق يفعل. لكن فهم الصيغ يحسم أسئلة عملية: