فاتورة فندق واحدة، تسعة عشر خصمًا من البنك

فاتورة فندق واحدة، تسعة عشر خصمًا من البنك.

أحد عملائنا يدير تسويات السفر لعدة شركات. أرسل لنا مؤخرًا لقطات شاشة لأسبوعه: خمسة أيام في فندق Vittori Palace بجدة. في نهاية الإقامة أصدر الفندق فاتورة مجمّعة واحدة — لكن بطاقة شركته خُصمت تسع عشرة مرة.

ثمانية خصومات بقيمة 47.02 ريالًا من مطعم الفندق. أربعة خصومات بقيمة 90.13 ريالًا من بار البهو. ثم الغرفة وفعالية في قاعة الاحتفالات وبضع بنود خدمة غرف، كلها فوترها الفندق نفسه. ثلاثة كيانات قانونية، ثلاثة أرقام ضريبة قيمة مضافة مختلفة، حجز واحد.

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

يدويًا: هذا كابوس إكسل بامتياز. تفتح كشف الحساب، تفتح الفاتورة، وتبدأ التخمين — «هاتان الـ47.02 غالبًا الإيصال رقم 14… لا، انتظر، رقم 14 هو 90.13…».

بالنسبة لـSnapLedger، هذه ليست خمّنات بوليسية، بل مطابقة مجموعات: مجموع كل خصومات البطاقة يجب أن يساوي الفاتورة المجمّعة، وكل إيصال يجب أن يُستخدم مرة واحدة بالضبط. النظام يجرّب الترتيبات ككل، لا سطرًا بسطر — ويعمل هذا مع متعدد-بمتعدد، لأن المطابقة ليست «فاتورة واحدة ← دفعة واحدة»، بل «مجموعة أدلة ← مجموعة خصومات».

النمط نفسه يظهر أينما وُجد تجميع:

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

في فندق Caravelle بسايغون رأينا نسخة مختلفة: فاتورة مجمّعة واحدة تُغلق بخصمين على Visa — واحد يغطي بعض الإيصالات، والآخر يغطي الباقي. دفعة مقسّمة: إيجاد أيّ المجموعات الجزئية من الإيصالات تجمع إلى كل خصم. الهيكل نفسه، والشكل مختلف.

وكالة السفن: PDA وFDA. يرسل وكيل السفينة حساب صرف تقديريًا PDA (Pro-forma Disbursement Account) — فاتورة تقديرية لرسوم الميناء قبل وصول السفينة. يدفع مالك السفينة مقدمًا. ثم، مع تنفيذ الأعمال، تتدفق فواتير الموردين الفعلية — رسوم الميناء، الإرشاد، القطر، الوقود — وغالبًا تُسدَّد عبر تحويلات متعددة ومقاصّات. وفي النهاية يصدر الوكيل حساب الصرف النهائي FDA (Final Disbursement Account): مطابقة حركات أموال متعددة مع فواتير موردين متعددة وتسوية الفرق. هذه بالضبط بنية متعدد-بمتعدد.

في كل هذه الحالات، التسوية اليدوية تعني أن شخصًا ما يحمل في رأسه: «هذه المجموعة من الخصومات تقابل تلك المجموعة من الأدلة». المُنهِك ليس السطور المفردة، بل البنية — وحمل البنية في الرأس مكلف، وسهل الخطأ بعد ساعتين.

SnapLedger يقلب هذه العلاقة. بدل «طابق هذا الإيصال مع ذلك الخصم» — «ضع كل شيء على الطاولة وطابقه ككل». ينظر الذكاء الاصطناعي إلى مجموعة الأدلة ومجموعة الخصومات نظرة شاملة، ويجرّب ترتيبات متسقة: هذه الخصومات الثمانية بـ47.02 والأربعة بـ90.13 مع بنود الغرفة تجمع إلى الفاتورة المجمّعة، وكل إيصال مستخدم مرة واحدة بالضبط، ولا شيء متبقٍّ.

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

وإن لم يتطابق؟ SnapLedger لا يخمّن بالقوة. يقول ما لا يستطيع تسويته — ويبقى الحكم للإنسان.

لأن التسوية في السفر والوكالات والشحن البحري ليست أبدًا «فاتورة واحدة، دفعة واحدة». هي دائمًا: كومة أدلة، كومة خصومات — وعلى أحدهم أن يضعها جنبًا إلى جنب ويرى هل تكتمل الصورة.

تركيب الأدلة في قيود محاسبية عملٌ للآلة. أما الحكم فللإنسان.