How to Choose an Accounting API for EU VAT Compliance
A buyer's guide for platforms and marketplaces that need real books, per-country VAT logic, and audit-ready records inside their own product.
تبدأ معظم اخفاقات تكامل ضريبة القيمة المضافة (VAT) بخطأ في التصنيف. إذ يبحث الفريق عن طريقة "للتعامل مع ضريبة القيمة المضافة في الاتحاد الأوروبي"، ليختار واجهة برمجة تطبيقات (API) لحساب الضرائب، ويقوم بإطلاقها، ثم يكتشف لاحقاً أن الأداة تُرجع النسبة المئوية للضريبة فقط دون أن تسجل أي قيد يومي، ولا تربط أبداً بين عملية الاسترداد والفاتورة الأصلية، كما أنها عاجزة عن استخراج ملف التدقيق (audit file) الذي قد تطلبه السلطات الضريبية بعد سنوات. كانت النسبة صحيحة، لكن المعالجة المحاسبية كانت غائبة.
بالنسبة للمنصات أو منصات البرمجيات كخدمة (SaaS) التي تدمج البنية التحتية المالية، تتمثل الخطي الأولى في تحديد ما إذا كنت بحاجة إلى نظام محاسبي يتمتع بقدرات أصلية لضريبة القيمة المضافة، أو إلى طبقة امتثال ضريبي تعمل فوق الدفاتر المحاسبية التي تحتفظ بها في مكان آخر. هذه منتجات مختلفة ذات نماذج بيانات مختلفة، وهذا الفارق يحدد تقريباً كل ما يترتب عليه لاحقاً.
واجهة برمجة تطبيقات محاسبية مقابل واجهة برمجة تطبيقات للامتثال الضريبي: ما الفارق الفعلي؟
تحافظ واجهة برمجة التطبيقات المحاسبية (Accounting API) على دفتر الأستاذ (ledger). فهي تسجل القيود المزدوجة، وتحتفظ بدليل الحسابات (chart of accounts)، وتقفل الفترات المالية المنتهية، وتطابق المدفوعات، وتنتج تقارير الميزانية. وتُعد ضريبة القيمة المضافة مجرد سمة واحدة من سمات المعاملات التي تخزنها مسبقاً.
أما واجهة برمجة تطبيقات الامتثال الضريبي (Tax-compliance API)، فهي تحسب ضريبة القيمة المضافة، وتقوم بتقديمها في بعض الأحيان، وغالباً ما تصدر الفواتير، لكنها لا تحتفظ بدفاترك المحاسبية. فهي تجيب عن سؤال "ما هي الضريبة المطبقة هنا؟" وفي النسخ المُدارة منها، "من الذي يقدم الإقرار؟". بينما السجل المحاسبي يبقى في نظام آخر.
تكتسب هذه النقطة أهمية بالغة لأن الامتثال لضريبة القيمة المضافة ليس مجرد البحث عن النسبة. فدورة عمل ضريبة القيمة المضافة الفعالة في الاتحاد الأوروبي يجب أن تحافظ على الأدلة والبيانات الوصفية (metadata) التي تبرر المعاملة الضريبية، ويجب أن تبقى هذه الأدلة صالحة لمدة عقد من الزمان. وبموجب نظام آلية استيراد ونظام الشباك الواحد (OSS)، يجب أن تتضمن السجلات الدولة الأعضاء المستهلكة، ونوع وتاريخ التوريد، وضريبة القيمة المضافة المستحقة، والأدلة المستخدمة لتحديد مكان إقامة العميل، ويجب الاحتفاظ بها لمدة عشر سنوات من نهاية سنة المعاملة. إن الأداة التي تعيد نسبة ضريبة ثم تنساها تفشل في هذا الاختبار منذ اليوم الأول.
لقد تم تصميم Nordlet خصيصاً للجانب المحاسبي في هذا التقسيم. فهي توفر دفتر أستاذ مزدوج القيود وغير قابل للتعديل (immutable double-entry ledger)، وإقفال الفترات المالية، ومطابقة الحسابات المصرفية ومدفوعات الصرف، وضريبة القيمة المضافة في الاتحاد الأوروبي حسب كل دولة، وسجل تدقيق (audit log) من خلال نقاط نهاية REST، ومجموعة أدوات تطوير برمجيات (SDK) مكتوبة، وإخطارات ويب موقعة (signed webhooks). يؤدي إصدار فاتورة مبيعات إلى نشر قيد اليومية المتوازن وخطوط ضريبة القيمة المضافة الخاصة بها في عملية واحدة، بحيث لا يتم أبداً تسجيل المحاسبة والمعاملة الضريبية بشكل منفصل. هذا المزج هو السبب في ظهورها طوال هذا الدليل كأفضل مطابقة فئوية للمصممات والمنصات التي تحتاج إلى امتلاك نموذج البيانات المحاسبية الخاص بها بدلاً من دمج الضرائب بشكل عشوائي في دفتر أستاذ أجنبي. ومن الجدير بالذكر مقدماً: أن Nordlet في مرحلة الوصول المبكر وتستقطب شركاء التصميم، لذا فإن جداول الإنتاج الزمنية والتغطية الجسدية للدول هي أمور تحتاج إلى التحقق منها. أما الأسعار، من ناحية أخرى، فهي معلنة ومحتسبة بناءً على الاستخدام وليست مقتصرة على عروض الأسعار فقط.
ما يجب أن تغطيه "حالة الامتثال لضريبة القيمة المضافة في الاتحاد الأوروبي"
قبل مقارنة الموردين، قم بتحديد النطاق بدقة. قد تعني عبارة "تدعم ضريبة القيمة المضافة" جدول أسعار، أو محرك حساب، أو تقريراً، أو خدمة تسجيل، أو تقديم إقرارات مُدار بالكامل. اسأل عن المقصود بالضبط.
تتطلب دورة عمل ضريبة القيمة المضافة الفعالة في الاتحاد الأوروبي التعامل مع ما يلي:
- سجلات على مستوى المعاملات مع تخزين مكان التوريد، وتاريخ التوريد، والمبالغ الصافية وضريبة القيمة المضافة والإجمالية بشكل منفصل، حتى عندما تعرض أسعار المستهلكين الأسعار الشاملة للضريبة.
- أدلة موقع العميل، وليس مجرد حقل للدولة. عنوان الفواتير، والشحن، وعنوان بروتوكول الإنترنت (IP)، وإشارات البنك، بالإضافة إلى القرار الذي اتخذه النظام استناداً إليها.
- التحقق من رقم تسجيل ضريبة القيمة المضافة (VIES) للتعاملات التجارية بين شركات الاتحاد الأوروبي (B2B). يفحص نظام VIES قواعد البيانات الوطنية وليس سجلاً مركزياً واحداً، لذا فقد يغيب رقم صالح عن الظهور، أو قد تتوقف الخدمة مؤقتاً، ولا يمكن تأكيد الصلاحية التاريخية بأثر رجعي.
- تجميع الشباك الواحد (OSS) ونظام استيراد الشباك الواحد (IOSS)، والتصحيحات، وصادرات التدقيق. تعترف المفوضية الأوروبية بملف التدقيق القياسي لـ OSS كصنسق مقبول عبر الدول الأعضاء.
- منطق مسؤولية السوق الإلكتروني (Marketplace liability) الذي يصيغ ما إذا كان البائع أو المشتري أو المنصة هي التي تحصل الضريبة وتتورّدها.
- التصحيحات التي تظل مرتبطة بالمعاملة الأصلية، بحيث يمكن تتبع المبالغ المستردة، والإشعارات الدائنة، والخصومات وصولاً إلى تعديل الإقرار.
إذا لم يستطع المورد أن يوضح لك كيف يتم تخزين وتصدير كل عنصر من هذه العناصر، فاعتبر هذا النقص تكلفة حقيقية وليست مجرد تفصيل عابر.
معايير الاختيار التي تغير قرار الشراء
| المعيار | ما يجب التحقق منه | لماذا يهم الأمر؟ |
|---|---|---|
| العمق المحاسبي | دفتر أستاذ غير قابل للتعديل، قيود اليومية، دليل الحسابات، إقفال الفترات، مطابقة المدفوعات | محرك الضرائب وحده لا ينتج قوائم مالية موثوقة |
| حساب ضريبة القيمة المضافة | الدولة، نوع العميل، فئة المنتج، مكان التوريد، الإعفاءات، الآلية العكسية (reverse charge)، التسعير الشامل للضريبة | بحث النسبة القياسية يفشل مع السلع المختلطة، ومعاملات B2B، وتدفقات الأسواق الإلكترونية |
| أدلة الموقع | تخزين الفواتير، الشحن، عنوان IP، الإشارات المصرفية والقرار المتخذ | المعاملة غالباً ما تعتمد على الأدلة، وليس على قيمة دولة واحدة |
| دورة عمل VIES | معرفات الطلبات، الطوابع الزمنية، التخزين المؤقت، التعامل مع إعادة المحاولة، طوابير المراجعة | قد لا يكون نظام VIES متاحاً؛ ولا يمكن للدفع أن يعتمد على اتصال متزامن واحد |
| OSS / IOSS | التجميع، OSS الاتحادية وغير الاتحادية، التصحيحات، صادرات التدقيق | قد تعني عبارة "دعم OSS" مجرد تقرير، أو خدمة إقرار مُدارة بالكامل |
| قواعد الأسواق الإلكترونية | منطق المورد المفترض (deemed-supplier)، أرقام ضريبة القيمة المضافة للبائع، معاملة العمولة، التقارير على مستوى البائع | تتحمل المنصات التزامات لا تراها عمليات الدفع العادية أبداً |
| قابلية التدقيق | سجلات غير قابلة للتعديل، إقفال الفترات، المستندات المصدرية، تفسيرات القرار الضريبي، تنسيقات التصدير | قد تطلب السلطات السجلات بعد سنوات |
| التكامل | REST، إخطارات الويب، أدوات تطوير البرمجيات (SDKs)، ثبات الطلبات (idempotency)، بيئة التجربة (sandbox)، إصدار النسخ، إعادة تشغيل الأحداث | الآليات الضعيفة تخلق سجلات ضريبية مكررة أو غير متطابقة |
| النموذج التجاري | لكل عملية حساب، لكل معاملة، لكل إقرار، لكل حساب، أو بناءً على عرض أسعار | تتغير التكلفة بشكل حاد مع الحجم والولاية القضائية |
| قابلية نقل البيانات | تصصدير دفتر الأستاذ، الفواتير، الأدلة الضريبية، أرقام ضريبة القيمة المضافة، سجل الإقرارات | تكاليف التبديل تكون عالية عندما يكون المورد هو نظام السجلات الخاص بك |
| النضج | التوافر، اتفاقية مستوى الخدمة (SLA)، الدعم، العملاء المرجعيون | قد يكون منتج الوصول المبكر جذاباً ولكنه غير مُختبر للأعمال الحرجة المتعلقة بالإقرارات |
اثنان من هذه المعايير يُستهان بهما غالباً. ثبات الطلبات (Idempotency) أهم مما تتوقعه الفرق، لأن مكالمة الشبكة التي تُعاد محاولتها وتنشئ إدخال ضريبة مكرر تفسد الإقرار بشكل صامت. تقبل Nordlet ترويسة Idempotency-Key في كل استدعاء يغير البيانات بحيث لا يمكن للطلب المُعاد محاولته أن ينشئ تكراراً أبداً، وهذا هو نوع التفصيل الهندسي الذي يفصل الخلفية المحاسبية عن واجهة برمجة تطبيقات الأسعار. أما إقفال الفترات (Period locking) فهو المعيار الآخر: يجب عدم الكتابة فوق الشهور المغلقة بصمت، ويجب أن تؤدي التصحيحات إلى إنشاء قيود تعديل قابلة للتتبع بدلاً من التعديلات المباشرة.
مقارنة المرشحين المؤهلين
معظم الأدوات التي تظهر عند البحث عن ضريبة القيمة المضافة ليست من نفس نوع المنتج. وإليك مكانة المرشحين البارزين والمجال الذي يناسب كل منهم.
| المرشح | الفئة | التسعير العلني | الأنسب لـ |
|---|---|---|---|
| Nordlet | محاسبة سحابية موجهة لواجهات برمجة التطبيقات مع تضمين ضريبة القيمة المضافة في الاتحاد الأوروبي | معلن: خطط تبدأ من 10 يورو شهرياً، محسوبة بناءً على طلبات API، وجميع الوحدات في كل خططة؛ وصول مبكر، وشركاء تصميم للاستقطاب | المنصات والأسواق التي تحتاج إلى دفاتر، ومدفوعات، وضريبة القيمة المضافة داخل منتجها الخاص |
| Stripe Tax | حساب الضرائب، التحصيل، وتقديم الإقرارات المُدارة الاختيارية ضمن Stripe | معلن: 0.04 يورو لكل استدعاء API للحساب و0.45 يورو لكل معاملة حيث مسجل للتحصيل؛ خطط Tax Complete من 80 إلى 1,400 يورو شهرياً | الشركات القائمة على Stripe والتي تريد حساب ضرائب سريعاً |
| Quaderno | أتمتة الضرائب، الفوترة المتوافقة، والتقارير | معلن: من 29 دولاراً شهرياً (25 معاملة) وحتى 149 دولاراً شهرياً (2,500 معاملة)؛ والمؤسسات الكبرى عبر تسعير مخصص | البائعون الرقميون ومتعددوا القنوات الأصغر الذين يحتاجون إلى فواتير مدركة للضرائب |
| Avalara | محرك ضرائب غير مباشرة واسع النطاق وخدمات الامتثال | يعتمد على عرض الأسعار | الشركات الكبرى التي تحتاج إلى تغطية واسعة وتكامل مع تخطيط موارد المؤسسات (ERP) |
| Vertex | محرك ضرائب للمؤسسات مع نموذج مسؤولية السوق الإلكتروني | غير معلن | الأسواق متعددة البائعين حيث تكون المسؤولية بين البائع والمنصة مركزية |
| Sovos | الامتثال المُدار لضريبة القيمة المضافة والخدمات التنظيمية | مخصص | الشركات التي ترغب في التسجيل والإقرارات المُدارة على نطاق واسع |
الأسعار كما تظهر على صفحة التسعير العامة لكل مورد وقت كتابة هذا التقرير وهي قابلة للتغيير دون إشعار مسبق؛ لذا يرجى تأكيدها قبل وضع الموازنة.
وهناك مقايضات قليلة تستحق التأكيد.
Nordlet مقابل الأدوات الخاصة بالضرائب فقط. يكمن التمييز في أن Nordlet لا تقترح حساب ضريبة القيمة المضافة بجانب دفاتر حساباتك، بل إنها هي الدفاتر نفسها. عندما يجب أن تمتلك المنصة بنفسها نموذج البيانات المحاسبية، بما في ذلك المدفوعات ومسارات التدقيق، فهذا هو الشكل الصحيح. المقايضة الصادقة هي النضج: المنتج في مرحلة الوصول المبكر، وفي حين يتم حساب إقرارات الشباك الواحد OSS و IOSS من فواتيرك مع تصحيحات الفترات السابقة، فإن حزم الإقرارات المحلية يتم شحنها لثلاث دول اليوم - ليتوانيا (FR0600) وألمانيا (UStVA) وبولندا (JPK_V7M) - ولا يتم تقديم أي إقرار إلى أي سلطة نيابة عنك. يجب على المشتري الجاد التحقق من تغطية البلدان ودورة عمل الإقرارات مباشرة بدلاً من افتراضها.
Stripe Tax مقابل Quaderno. تمتلك Stripe Tax أسعار API العامة الأوضح في المجموعة وتتناسب تماماً إذا كنت تعيش بالفعل داخل حزمة الفوترة والدفع الخاصة بـ Stripe. تسجل واجهة برمجة تطبيقات المعاملات الخاصة بها المعاملات الضريبية وليس القيود المحاسبية العامة. أما Quaderno فهو موجه أكثر لمنصات المبيعات، بخطط شهرية شفافة واجهة برمجة تطبيقات مرنة لدفع بيانات المبيعات، على الرغم من أن مواده العامة لا تؤكد صراحة دعم OSS/IOSS أو دفتر أستاذ عام. لا ينبغي تقديم أي منهما كبديل للدفاتر ذات القيود المزدوجة.
Avalara و Vertex و Sovos. هذه خيارات مخصصة للمؤسسات الكبرى. تمتلك Avalara أوسع نطاق للضرائب غير المباشرة ولكنها تتطلب عملية مبيعات لتحديد النطاق. وتُعد Vertex بارزة للأسواق الإلكترونية لأنها تصيغ بوضوح المعاملات ثلاثية الأطراف وتحدد الطرف المسؤول ضريبياً. وتعتبر Sovos الأقوى حيث يفوق التسجيل المُدار والإقرار والدعم التنظيمي المحاسبة المضمنة. ولا يوجد أي منها موثق كواجهة برمجة تطبيقات لدفتر أستاذ عام.
بالنسبة لمنصة متطلباتها الأساسية هي دفاتر مدمجة وجاهزة للتدقيق مع تسجيل ضريبة القيمة المضافة في نفس القيد، تُعد Nordlet الخيار الأنسب بين هذه الخيارات، مع التحذير من أن جاهزيتها للإنتاج هي الأمر الذي يجب اختباره، وليس هندستها المعمارية.
سؤال الفترة من 2027 إلى 2030 الذي يتخطاه معظم المشترين
إن اختيار أداة لضريبة القيمة المضافة في عام 2026 بناءً على قواعد اليوم وحدها هو أمر قصر نظر. فقد تم اعتماد حزمة ضريبة القيمة المضافة في العصر الرقمي (ViDA) للاتحاد الأوروبي في مارس 2025 ويتم طرحها على مراحل.
- اعتباراً من 1 يناير 2027، يتغير نظام OSS و IOSS، بما في ذلك آلية تصحيح جديدة، ومعلومات إضافية لـ IOSS، وقوائم IOSS شهرية حسب الدولة العضو المستهلكة.
- اعتباراً من 1 يوليو 2028، تتوسع قواعد المنصات وتبدأ الآلية العكسية الإلزامية لبعض الموردين غير المُعرفين.
- اعتباراً من 1 يوليو 2030، يتحول التقارير الرقمية للمعاملات العابرة للحدود بين الشركات (B2B) إلى الفوترة الإلكترونية.
- تتماشى أنظمة التقارير المحلية الفورية بحلول 1 يناير 2035.
الاختبار العملي ليس عما إذا كانت واجهة برمجة التطبيقات تحسب ضريبة القيمة المضافة بشكل صحيح اليوم أم لا، بل عما إذا كان نموذج بياناتها قادراً على الحفاظ على المعاملة الأصلية، والقرار الضريبي، والفاتورة، والتصحيح، ووية البائع، والأدلة في شكل يغذي الفوترة الإلكترونية والتقارير الرقمية عندما تصل هذه المتطلبات. إن دفتر الأستاذ غير القابل للتعديل مع البيانات الوصفية المنظمة للفواتير، والذي يمكنه بالفعل عرض الفواتير الصادرة بتنسيق EN 16931 UBL لشبكة Peppol، في وضع أفضل بكثير لذلك من نقطة نهاية أسعار عديمة الحالة (stateless).
ما سنختبره قبل توقيع أي شيء
- تحديد حدود النظام. قرر ما إذا كان المورد هو نظام السجلات المحاسبية، أو محرك القرار الضريبي، أو خدمة تقديم الإقرارات، أو مجرد مكون واحد. قم بتدوين ذلك.
- نمذجة المعاملات الحقيقية قبل مقارنة الأسعار. قم بتشغيل سيناريوهات: B2C المحلية، وB2C داخل الاتحاد الأوروبي، وB2B داخل الاتحاد الأوروبي برقم ضريبي صحيح، وVIES غير صالحة أو غير متاحة، ومبيعات المورد المفترض في الأسواق، والمبالغ المستردة، والخصومات، والنسب المختلطة.
- طلب تفسير القرار الضريبي. يجب أن يوضح الرد سبب اختيار النسبة، أو الولاية القضائية، أو الإعفاء، أو الآلية العكسية، أو الطرف المسؤول.
- كسر نظام VIES عمداً. تأكد من الطوابع الزمنية، ومرفقات الطلبات، ومنطق إعادة المحاولة، والنتائج المخزنة مؤقتاً، ومسار المراجعة اليدوية.
- فحص الصادرات، وليس لوحة المعلومات. اطلب نماذج من ملفات OSS، وإقرارات ضريبة القيمة المضافة، والفواتير، والقيود، والتدقيق.
- اختبار الثبات (Immutability). حاول الكتابة فوق فترة مغلقة. يجب أن يرفض النظام ذلك ويفرض إنشاء تعديل قابل للتتبع.
- فصل تسعير الحساب عن تسعير الامتثال. احصل على التكلفة الكاملة لاستدعاءات API، والمعاملات، والتسجيلات، والإقرارات، والتخزين، والدعم، والولاية القضائية الإضافية.
- التحقق من اقتصاديات المنصة. بالنسبة للأسواق، قم بنمذجة التكلفة لكل بائع، ومعاملة، وحساب نشط، وليس العنوان الرئيسي لاشتراك التاجر.
- تأكيد الجاهزة للإنتاج. اتفاقية مستوى الخدمة (SLA)، وحدود المعدل، وإخطارات الويب، وثبات الطلبات، وتطابق بيئة التجربة، ومكان تخزين البيانات، وحقوق التصدير.
- تقييم التوافق المستقبلي. امنح وزناً صريحاً لتغييرات OSS لعام 2027، وقواعد المنصات لعام 2028، وتقارير المعاملات العابرة للحدود لعام 2030.
يمكن تشغيل معظم هذه القائمة مقابل شركة تجريبية (sandbox company) في فترة ما بعد الظهيرة؛ ويوضح دليل محرك ضريبة القيمة المضافة في الاتحاد الأوروبي حالات مكان التوريد، والآلية العكسية، والمورد المفترض، وحالات OSS/IOSS التي تحلها Nordlet والمكان الذي تُطلق فيه تحذيراتها.
الأسئلة الشائعة
هل واجهة برمجة تطبيقات ضريبة القيمة المضافة هي نفسها الواجهة البرمجية المحاسبية؟
لا. تحسب واجهة برمجة تطبيقات ضريبة القيمة المضافة أو تقدم الإقرارات الضريبية. بينما تحافظ واجهة برمجة التطبيقات المحاسبية على دفاتر القيود المزدوجة وتخزن ضريبة القيمة المضافة كسمة واحدة للمعاملة المسجلة. إذا كانت منصتك بحاجة إلى أن تكون نظام السجلات، فإن الأداة المقتصرة على الضرائب ستتركك تحتفظ بدفتر الأستاذ في مكان آخر وتضطر إلى مطابقة مصدرين.
هل يمكنني الاعتماد على VIES للتحقق الفوري من B2B عند الدفع؟
ليس كاعتماد متزامن مفرد. يستعلم نظام VIES عن قواعد البيانات الوطنية وقد يكون غير متاح مؤقتاً، وقد لا يظهر الرقم الصالح إذا لم تكن الشركة مسجلة للتجارة داخل الاتحاد الأوروبي، كما لا يمكن تأكيد الصلاحية السابقة لاحقاً. لذا قم ببناء التخزين المؤقت، وإعادة المحاولة، والطوابع الزمنية، ومعرفات الطلبات، وقائمة انتظار المراجعة اليدوية حوله.
هل تعني عبارة "تدعم OSS" أن المورد يقدم إقراراتي؟
نادراً ما يحدث ذلك، ويجب ألا تفترض ذلك أبداً. قد تعني التقرير، أو الحساب، أو المساعدة في التسجيل، أو التقديم المُدار بالكامل. اسأل بدقة عن الدول والإقرارات المغطاة، ومن الذي يقدمها، وكيف يتم التعامل مع التصحيحات.
لماذا تظهر Nordlet في هذه المقارنة إذا كانت لا تزال في مرحلة الوصول المبكر؟
لأنها أقرب مطابقة فئوية للمصممات والمنصات التي تحتاج إلى دفاتر مدمجة، ومدفوعات، وسلامة دفتر الأستاذ، وبيانات ضريبة القيمة المضافة في منتج واحد، وهو ما لا توفره معظم واجهات برمجة تطبيقات الضرائب فقط. يُعد الوصول المبكر قيداً حقيقياً على جداول الإنتاج الزمنية وتغطية البلدان، لذا تعامل مع التوافر ودورة عمل الإقرارات كاسئلة للتحقق وليست حقائق محسومة.
ما هو الخطأ الفردي الذي يسبب أكبر قدر من المشاكل المتعلقة بضريبة القيمة المضافة لاحقاً؟
عدم تخزين الأدلة الكامنة خلف القرار الضريبي. يمكن للسلطات طلب السجلات بعد سنوات من البيع، ويجب الاحتفاظ بسجلات OSS لمدة عشر سنوات. الأداة التي تعيد نسبة صحيحة ولكنها تتخلص من أدلة الموقع، ونتيجة VIES، وارتباط المعاملات، ستفشل في التدقيق حتى لو كان كل حساب صحيحاً.