يستطيع Claude و Gemini إنتاج نتيجة تبدو وكأنها تسوية بنكية. لكن لا أيٌّ منهما يستطيع إثبات أن هذه النتيجة كاملة وصحيحة. كلاهما نموذج لغوي للأغراض العامة: يولّد استجابة معقولة انطلاقاً من الملفات والتعليمات التي يتلقاها. التسوية الموثوقة تستلزم أن يُحسَب كل صف في كلا الملفين، وأن يكون كل تطابق قابلاً للتتبع، وأن يظل كل فارق مرئياً.
هذا الفرق يجيب عن السؤال العملي. قد يُعيد Claude أو Gemini ملاحظات عن بعض المعاملات، أو اقتراحات لمطابقة الأعمدة، أو صيغة أولية لمعادلة. عامِل هذه المخرجات كمادة عمل غير مُتحقَّق منها. التسوية البنكية التي ستُراجَع أو تتكرر أو تُسلَّم لعميل تحتاج أكثر من مجرد رد من نموذج المحادثة.
قراءة كشف الحساب ليست تسوية له
التسوية البنكية تبدأ من مصدرين: كشف حساب البنك والأستاذ العام أو دفتر النقدية أو تصدير المعاملات الذي تريد مقارنته. المهمة ليست وصف هذين الملفين. المهمة مقارنتهما دون أن تفقد أي صف.
لكل صف، يجب أن تُجيب النتيجة عن هذه الأسئلة:
- ما الصف المقابل له في الملف الآخر؟
- ما الحقل أو مجموعة الحقول التي أسّست التطابق؟
- هل تتفق المبالغ تماماً؟
- هل يُسمح بفارق التاريخ، وبموجب أي قاعدة؟
- إن لم يكن ثمة مقابل، في أي ملف يقع الصف غير المُسوَّى؟
- هل يحتوي أحد المصدرين على سجل مكرر جعل التطابق غامضاً؟
Claude و Gemini يستطيعان قراءة المحتوى الجدولي وصياغة ملخص مقنع. هذا لا يُثبت أن كل صف مصدر مر بعملية مطابقة متسقة. فقرة تقول إن 184 معاملة جرى تطابقها ليست دليلاً على أن 184 زوجاً محدداً قد قورن.
يتضح الفرق حين تُحدَّد متطلبات النتيجة صراحةً:
| متطلب التسوية | ما تحتاجه المهمة | ما يقدمه رد النموذج عادةً |
|---|---|---|
| تغطية المصادر | كل صف من كلا الملفين يظهر في النتيجة | ملخص، أو عينة، أو جدول مختصر |
| أزواج التطابق | صف محدد من الملف A مرتبط بصف محدد من الملف B | عدد التطابقات أو وصف نصي |
| أساس التطابق | مرجع، مبلغ، تاريخ، أو مجموعة محددة مبيَّنة لكل زوج | تفسير مستنتج للأساس المحتمل |
| الاستثناءات | كل صف غير مُسوَّى أو غامض محتفظ به | اختيار للفوارق التي رُئيت ذات أهمية |
| التحقق | مجاميع وأعداد مستخرجة من مجموعة الصفوف الكاملة | أرقام مقدَّمة بلا سلسلة صيغ قابلة للفحص |
| سجل التدقيق | دليل قابل للتصدير على مستوى الصف | إجابة محادثاتية قد تتغير عند إعادة التشغيل |
هذا هو الفارق الجوهري: السؤال عمّا إذا كان Claude أو Gemini قادراً على إجراء تسوية بنكية يختلف عن السؤال عمّا إذا كانا قادرَين على قراءة CSV. قراءة الملف مجرد خطوة إدخال. التسوية هي المقارنة المضبوطة وسجل ما حدث لكل صف.
الخلل هيكلي، لا خاص بنموذج بعينه
Claude و Gemini يتمايزان كمنتجَين، لكن هذه المقارنة لا تحل مشكلة التسوية. القيد الهيكلي مشترك بين جميع نماذج اللغة الكبيرة للأغراض العامة: صُمِّمت لتوليد إجابة، لا للحفاظ على سجل محاسبي حتمي.
الـ prompt نفسه يمكنه إنتاج صياغات مختلفة، أو تجميع الاستثناءات بشكل آخر، أو اختيار تطابق مختلف حين تبدو عدة مرشحات معقولة. هذا التفاوت مقبول عند صياغة بريد إلكتروني. ليس مقبولاً حين يوجد دفعتان بمبلغ 250.00 وواحدة منهما فحسب تنتمي إلى الفاتورة INV-1048.
تأمَّل هذه الصفوف:
| Bank row | Date | Description | Amount |
|---|---|---|---|
| B-118 | 2026-05-06 | TRANSFER HOLT | 250.00 |
| B-119 | 2026-05-06 | TRANSFER PINE | 250.00 |
| Ledger row | Date | Reference | Customer | Amount |
|---|---|---|---|---|
| L-442 | 2026-05-05 | INV-1048 | Pine Studio | 250.00 |
مقارنة المبلغ والتاريخ تُنتج مرشّحَين. لا تُعدّ النتيجة «مُسوَّاة» حتى يربط مفتاح موثوق إضافي L-442 بـ B-119. يستطيع النموذج استنتاج من الوصف أن PINE هي على الأرجح Pine Studio. قد يكون اقتراحاً مفيداً، لكنه يبقى استنتاجاً. يجب أن تُظهر النتيجة القاعدة التي قبلت التطابق، أو أن يُعلَّم المرشحان كلاهما للمراجعة.
هذا الغموض شائع مع المستحقات المتكررة والاشتراكات والرواتب والتحويلات ذات المبالغ المستديرة والمدفوعات المتكررة للموردين. نظام يخفي الغموض يمكنه إنتاج نتيجة تبدو نظيفة لكنها خاطئة.
تطابق الأرصدة لا يُثبت دقة المعاملات
خطأ ثانٍ هو قبول تطابق أرصدة الإغلاق دليلاً على أن المعاملات الأساسية قد سُوِّيت. قد يُحدد Claude أو Gemini أن كشف حساب البنك والأستاذ العام كلاهما يُغلَق على $48,730. هذا يؤكد رقماً واحداً. لا يؤكد الصفوف التي أنتجته.
خطآن يمكنهما إلغاء أحدهما الآخر. إيداع $900 مفقود ودفعة $900 مفقودة يُبقيان رصيد الإغلاق دون تغيير. كذلك نفقة مسجَّلة مرتين مع نفقة مُغفَلة بالمبلغ نفسه. إجابة تعتمد على الأرصدة فحسب ستُفوِّت كلا المشكلتين لأن الفارق الصافي صفر.
لذا تحتاج التسوية ضبطَين اثنين:
- ضبط الأرصدة. الرصيد الافتتاحي مضافاً إليه النشاط يجب أن يساوي رصيد الإغلاق في كل مصدر.
- ضبط المعاملات. كل صف يجب أن يُسوَّى أو يُترك بلا مقابل أو يُعلَّم بوصفه غامضاً.
كلا الضبطين ضروريان. نتيجة على مستوى المعاملات برصيد افتتاحي خاطئ غير مكتملة. أرصدة تتطابق مع صفوف غير مُفسَّرة كذلك.
هذا الفرق يهم حين يُقدَّم كشف الحساب البنكي بصيغة PDF. استخراج الصفوف من المستند يُدخل نقطة تحكم إضافية قبل بدء التسوية. يجب أن يتفق عدد المعاملات المستخرجة والرصيد الافتتاحي والرصيد الختامي وإجمالي المدينات والدائنات مع الكشف الأصلي. إن تحوَّل وصف ملتفّ إلى صفَّين، أو ضاع إشارة سالبة، أو أُغفلت صفحة، تبدأ المقارنة اللاحقة من بيانات فاسدة.
رد نموذج المحادثة نادراً ما يفصل بين التحقق من صحة الاستخراج والتحقق من صحة التسوية. قد ينتقل مباشرةً من قراءة الكشف إلى وصف النتيجة. منهجية العمل الموثوقة تُثبت أولاً أن الكشف التُقط بالكامل، ثم تُثبت كيف تقارن هذه الصفوف المُلتقَطة مع الأستاذ العام.
ثلاثة أسباب تجعل النتيجة المقنعة غير موثوقة
النموذج قد لا يعالج الملف بالكامل
ملفات المعاملات تستنزف السياق المتاح سريعاً لأن كل صف يتضمن تواريخ ومراجع وأوصافاً وعملات ومبالغ. حين يتخطى مجموع الملفين والـ prompt ما يستطيع النموذج معالجته، قد يعمل انطلاقاً من جزء من المحتوى المُقدَّم فحسب، أو من تمثيل مُكثَّف.
الإجابة الناتجة يمكن أن تبدو مكتملة مع ذلك. قد تتضمن مجاميع وفئات استثناءات وشرحاً واثقاً. ما لم تُثبت النتيجة أن كل صف مصدر ممثَّل، لا يمكنك معرفة من الإجابة وحدها ما إذا كانت صفوف قد أُغفلت.
الضبط الأول إذن ليس «هل يبدو المجموع معقولاً؟» بل: «هل أستطيع تتبع عدد الصفوف المصدرية في النتيجة؟» إن كان الملف A يحتوي على 2,416 صف بيانات والملف B يحتوي على 2,389، يجب أن يُحاسب التقرير النهائي عن جميع 4,805 ظهورات صف: مُسوَّاة أو غير مُسوَّاة أو مكررة أو مُعلَّمة.
الأرقام بلا سلسلة حسابية قابلة للفحص
مجموع مطبوع في رد نموذج محادثة لا يعادل مجموعاً ناتجاً عن صيغة جدول بيانات قابلة للفحص أو تقرير مطابقة حتمي. تحتاج أن تعرف أي الصفوف ساهمت فيه.
لنفترض أن النموذج أفاد بالتالي:
- 2,350 معاملة مُطابَقة
- 31 معاملة موجودة في البنك فحسب
- 8 معاملات موجودة في الأستاذ العام فحسب
- الفارق غير المفسَّر هو $0
هذه الأرقام تبدو متسقة داخلياً. لكنها لا تزال تحتاج دليلاً. يجب أن يحتوي قسم التطابقات على 2,350 زوجاً محدداً. يجب أن تحتوي أقسام الاستثناءات على 39 صفاً محدداً. مبالغ هذه الصفوف يجب أن تُعيد إنتاج المجاميع المُعلَنة. بلا هذه السلسلة، لا يمكن التحقق من الملخص بشكل مستقل.
النتيجة قد لا تحفظ سجل التطابق
حتى نتيجة صحيحة تكون هشة إن لم تستطع إظهار كيف تم الوصول إليها. سجل التطابق الصارم يُحدد كلا الصفَّين المصدريَّين والأساس الدقيق المُستخدَم.
| صف الملف A | صف الملف B | أساس التطابق | الحالة |
|---|---|---|---|
| B-118 | — | مبلغ مكرر؛ لا مرجع فريد | مراجعة مطلوبة |
| B-119 | L-442 | الوصف/العميل والمبلغ المطابق تماماً | مُسوَّى |
| B-120 | — | المرجع غير موجود في الأستاذ العام | غير مُسوَّى (البنك) |
هذا الجدول قابل للمراجعة. «جرى تطابق الدفعة 250.00 مع Pine Studio» لا يمكن مراجعتها ما لم تُحفَظ معرِّفات المصدر والأساس.
هذا أيضاً هو السبب في أن prompt جديداً لا يُشكِّل مسار تدقيق. مطالبة Claude أو Gemini بشرح الإجابة السابقة تُنشئ إجابة مُولَّدة أخرى. لا تُعيد بناء سجل حتمي جرى التقاطه حين أُجريت المقارنة.
كيف تتحقق من تسوية بنكية أنتجها الذكاء الاصطناعي
إن كنت قد استخدمت Claude أو Gemini بالفعل، لا تتخلَّ عن العمل فوراً. عامِل النتيجة كمسودة واختبرها مقابل الملفات المصدرية.
- سجِّل عدد الصفوف المصدرية. استبعد الترويسات والصفوف الفارغة. احتفظ بالعدد لكل ملف على حدة.
- اطلب نتيجة على مستوى الصف. كل صف مصدري يحتاج معرِّفاً ثابتاً. أضف واحداً قبل الرفع إن لم تكن الملفات تحتوي عليه.
- افحص التغطية الكاملة. كل معرِّف من كلا الملفين يجب أن يظهر مرة واحدة في النتيجة: مُسوَّى، أو غير مُسوَّى، أو مكرر، أو قيد المراجعة.
- افحص أزواج التطابق. تأكد أن كل زوج يُظهر الحقول المُستخدَمة لتحديده. المبلغ وحده لا يكفي حين توجد تكرارات.
- أعد حساب جميع المجاميع خارج النموذج. اجمع قسمَي التطابقات والاستثناءات مباشرةً من النتيجة المستندة إلى المصادر.
- ابحث عن الصفوف المُعاد استخدامها. صف بنكي واحد لا يجب أن يُفي بصفَّين من الأستاذ العام، إلا إن كانت التسوية تُجيز تطابق واحد-إلى-كثير وتوثِّقه صراحةً.
- أعِد تشغيل عينة من الاستثناءات يدوياً. ابدأ بالمبالغ المتكررة والتواريخ المتقاربة والمراجع الفارغة والقيود العكسية والمبالغ المُستردة والأوصاف المُعدَّلة.
إن لم يستطع النموذج إرجاع معرِّفات صفوف ثابتة وتغطية كاملة للمصادر وقائمة استثناءات قابلة للإعادة، فالنتيجة ليست جاهزة لإقفال نهاية الشهر أو التسليم للعميل. استخدمها كنقطة انطلاق للتحقيق، لا كتسوية مكتملة.
للاطلاع على مقارنة أوسع للمشكلة ذاتها في واجهة محادثة أخرى، راجع ما إذا كان ChatGPT يستطيع تسوية ملفات CSV لكشوف الحسابات البنكية. اسم النموذج يتغير. متطلب التحقق لا يتغير. المسألة ذات الصلة هي لماذا لا يمكن الوثوق بمطابقة الذكاء الاصطناعي بلا مسار تدقيق، إذ إن النتيجة المعقولة والنتيجة المُثبَتة مخرجان مختلفان.
ما يجب أن تحتويه نتيجة التسوية البنكية الدقيقة
الدقة ليست نسبة مئوية مطبوعة في رأس التقرير. هي القدرة على فحص النتيجة وصولاً إلى الصف المصدري.
النتيجة القابلة للاستخدام تحتوي على:
- كل صف من الملف البنكي
- كل صف من ملف الأستاذ العام
- رابط مرئي بين كل زوج مُسوَّى
- الأساس الدقيق لكل تطابق
- قوائم منفصلة للسجلات الموجودة في البنك فحسب وفي الأستاذ العام فحسب
- المرشحات المكررة والغامضة مُستبعَدة من التطابقات المؤكدة
- أعداد ومجاميع يمكن إعادة حسابها من الصفوف التفصيلية
- القيم المصدرية الأصلية محفوظة للمراجعة
هذا الهيكل يتيح لشخص آخر إعادة إنتاج الاستنتاج. كما يمنع خطأً شائعاً: إجبار التسوية على الوصول إلى صفر بقبول تطابق معقول لكنه غير مدعوم.
قد يقترح Claude أو Gemini أن «Transaction Date» يقابل «Posting Date»، أو يشرح لماذا قد تكون نافذة تحمُّل للتاريخ ضرورية، أو يُعد قائمة مراجعة. هذه المخرجات تبقى خارج الأدلة النهائية. إنها استشارية. التطابق النهائي يحتاج عملية حتمية تقرأ كلا الملفَين كاملَين وتكشف كل قرار.
الإجابة الدقيقة إذن مشروطة. يستطيع Claude و Gemini المساعدة في فهم بيانات كشف الحساب البنكي وإنتاج مسودة تشبه التسوية. لا يستطيعان، من خلال رد نموذج محادثة للأغراض العامة وحده، توفير التغطية الكاملة للصفوف وسجل المطابقة الحتمي والأدلة الجاهزة للتدقيق اللازمة لإثبات أن التسوية دقيقة.
