كيفية استيراد كشوف الحسابات البنكية إلى متتبع النفقات

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

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

لا يوفر Expense Budget Tracker معالجًا مدمجًا لرفع ملفات CSV أو PDF بنقرة واحدة، ولا يحتفظ باتصال دائم بحسابك البنكي. يستخدم سير العمل هذا وكيل ذكاء اصطناعي خارجيًا أو برنامجًا نصيًا لقراءة الكشف والتعامل مع المتتبع. يتولى الوكيل معالجة الملف، بينما تراجع أنت القيد الدقيق الذي سيُكتب في دفتر الأستاذ وتتحكم فيه.

ابدأ بمصدر واحد يمكنك الرجوع إليه

احتفظ بكشف الحساب الأصلي من دون تغيير. اعمل على نسخة، وأعطِ الوكيل مسار الملف الدقيق أو المرفق، والحساب، والعملة، وفترة الكشف المغلقة.

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

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

تختلف مخاطر الاستخراج باختلاف صيغة الملف. يبدأ استيراد كشف حساب بنكي بصيغة CSV من حقول منظمة، بينما قد يبدأ استيراد كشف بصيغة PDF من نص مستخرج أو من صورة مكوّنة من بكسلات.

• يوفر ملف CSV المنظم عادةً أنظف نقطة بداية، لكن لا يزال على الوكيل تأكيد محدِّد الحقول وتنسيق التاريخ والفاصل العشري والعملة، وما إذا كانت المبالغ موزعة على عمودين منفصلين للمدين والدائن أم موضوعة في حقل واحد ذي إشارة.
• قد يحافظ ملف PDF النصي على نص المعاملات المقروء، لكنه يفقد محاذاة الأعمدة. أعطِ كل صف في المسودة رقم الصفحة، بالإضافة إلى تسلسل المعاملة أو مرجع السطر، كي تستطيع تتبعه إلى مصدره.
• يحتاج ملف PDF الممسوح ضوئيًا أو المكوّن من صور فقط إلى OCR أو إلى أداة لفهم الصور. قد تجعل الصفحات المقتطعة والطباعة الباهتة والأعمدة المدمجة الاستخراج الدقيق مستحيلًا. إذا كان أي تاريخ أو مبلغ أو عملة أو رصيد غير واضح، فتوقف واطلب ملفًا أفضل أو تأكيدًا يدويًا.

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

استخدم جدول المراجعة هذا كما هو

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

العمود	ما الذي يوضع فيه
source_ref	رقم الصف في CSV، أو رقم الصفحة في PDF مع تسلسل المعاملة أو مرجع السطر
posted_at	تاريخ القيد ووقته إذا وفرهما المصدر؛ لا تُدرج منطقة زمنية إلا عندما يوفرها المصدر أو يؤكدها المستخدم
raw_description	نص المصدر كما يظهر تمامًا، من دون تنقيح اسم التاجر
statement_amount	القيمة في عمود المدين أو الدائن، أو المبلغ الأصلي بإشارته، كما يظهر تمامًا في المصدر
currency	عملة المصدر؛ لا تستنتجها بصمت من رمز
ledger_amount	المبلغ بعد توحيد إشارته وفق القاعدة المتبعة في المتتبع
target_account	الحساب الحالي المحدد بالضبط من بيئة العمل
proposed_kind	القيمة الدقيقة التي يسمح بها المخطط الحالي لهذه الحركة
proposed_category	الفئة الحالية الدقيقة، أو قيمة «بلا فئة» التي يفرضها المخطط الحالي على التحويل
transfer_match	الحساب المقابل ومرجع المصدر، أو unresolved
duplicate_candidate	القيد المطابق في دفتر الأستاذ وأدلة التطابق، أو none found
uncertainty	أي مشكلة غير محسومة في النص أو التاريخ أو المبلغ أو الحساب أو العملة أو التصنيف
decision	insert أو match existing أو exclude أو needs review

على سبيل المثال، يجب أن يبقى الصف المسجل سابقًا من إيصال في الجدول مع القرار match existing. فلا ينبغي أن يختفي من الأدلة أو يتحول إلى قيد ثانٍ في دفتر الأستاذ.

يظل الوصف الخام ومبلغ الكشف مهمين حتى بعد أن ينشئ الوكيل حقولًا منقحة. فهما أسرع طريق للعودة إلى المصدر عندما تبدو الفئة المقترحة أو إشارة المبلغ خاطئة.

اربط الوكيل، ثم افحص البيانات الفعلية

بالنسبة إلى وكيل يعمل من سطر الأوامر أو برنامج نصي يستخدم HTTP مباشرةً، ابدأ بالطلب الآتي:

GET https://api.expense-budget-tracker.com/v1/

اتبع استجابة الاكتشاف، وأكمل مسار التحقق بالرمز المرسل عبر البريد الإلكتروني، وخزّن ApiKey طويل الأجل الذي تحصل عليه خارج ذاكرة المحادثة. تستخدم الطلبات المصادق عليها Authorization: ApiKey <key>. يشرح دليل إعداد الوكيل تسلسل الإعداد الكامل.

قبل إنشاء أي SQL، ينبغي أن يفعل الوكيل ما يأتي:

1. يؤكد الحساب الذي سُجّل الدخول إليه وبيئة العمل المحددة بالضبط.
2. يختار بيئة العمل المقصودة أو يرسل معرّفها مع الطلب.
3. يفحص GET /v1/schema لمعرفة العلاقات والأعمدة المسموح بها حاليًا.
4. يستعلم عبر POST /v1/sql/query عن الحساب المستهدف المحدد، وعملته، والفئات الحالية، وآخر نقطة تسوية موثوقة.
5. يستعلم عن النشاط الموجود في دفتر الأستاذ خلال فترة الكشف والنطاق المستخدم للتحقق من التكرار قبل اقتراح أي عملية كتابة.

لا تنسخ قائمة أعمدة من هذا المقال إلى برنامج نصي للاستيراد. المخطط الحالي هو المرجع الملزم. يوثق مرجع API نقاط النهاية وقواعد SQL، بينما يخبر /v1/schema الوكيل بما يمكن كتابته الآن.

يمكن لعميل يدعم MCP الاتصال بدلًا من ذلك بالعنوان الآتي:

https://mcp.expense-budget-tracker.com/mcp

يستخدم هذا المسار OAuth عبر المتصفح بدلًا من ApiKey. اطلب النطاق expenses:read لاستخدام list_workspaces وget_schema وsql_query. لا تضف نطاق expenses:write الاختياري إلا عندما يصبح العميل جاهزًا لاستدعاء sql_execute. يشرح دليل موصل MCP طريقة الاتصال ونموذج الموافقة.

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

حدّد نطاقًا عمليًا لاكتشاف التكرارات

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

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

• الحساب المستهدف
• العملة
• المبلغ الدقيق بإشارته
• التاريخ ضمن ثلاثة أيام تقويمية

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

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

دع فئات دفتر الأستاذ توجه المسودة

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

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

تستحق المبالغ المستردة القدر نفسه من العناية. أبقِ إشارة المبلغ في المصدر وحركة الحساب واضحتين، ثم عالج المبلغ المسترد وفق الأسلوب المتبع حاليًا في بيئة العمل. لا تصنّف كل مبلغ موجب بصمت على أنه دخل.

لا تدع التحويلات تتحول إلى إنفاق زائف

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

يشمل ذلك الحالات الشائعة الآتية:

• التحويل من الحساب الجاري إلى حساب التوفير هو تحويل داخلي عندما يكون الحسابان متتبعين
• الشراء ببطاقة ائتمان هو إنفاق على حساب البطاقة
• الدفعة اللاحقة من الحساب الجاري إلى حساب تلك البطاقة المتتبعة هي تحويل، وليست عملية الشراء نفسها مرة أخرى
• الرسم البنكي المذكور على نحو منفصل هو إنفاق، حتى عندما يظهر بجانب تحويل
• يحتفظ كل طرف من أطراف التحويل بين العملات بالمبلغ والعملة الفعليين الواردين في كشف حسابه؛ لا تخترع مبلغًا ناتجًا عن تحويل العملة للطرف المفقود

إذا كان الحساب المقابل أو كشفه مفقودًا، فاترك transfer_match بالقيمة unresolved. لا تختلق الطرف الآخر، ولا تعتمد الصف على أنه إنفاق عادي لمجرد إنهاء الدفعة. تجد معايير القرار التفصيلية في هل تُحتسب التحويلات البنكية ضمن النفقات؟.

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

اعتمد دفعة محددة، لا نية مبهمة

بعد أن يحصل كل صف مُرحّل في المصدر على قرار، حتى لو كان ذلك القرار needs review، ينبغي أن يعرض الوكيل ما يأتي:

• بيئة العمل وحساب الكشف والعملة والفترة
• عدد صفوف المصدر المُرحّلة وإجماليات المدين أو الدائن أو المبالغ بإشاراتها في الكشف
• الصفوف المطابقة لقيود موجودة في دفتر الأستاذ
• الصفوف المستبعدة من الاستيراد وسبب استبعادها
• المعاملات المرشحة كتكرارات أو تحويلات ولم تُحسم بعد
• جملة SQL الدقيقة لدفعة صغيرة واحدة، منشأة وفق المخطط الحالي
• العدد المتوقع للصفوف المتأثرة

استخدم موافقة بهذه الدقة:

أوافق على دفعة استيراد كشف الحساب [number] فقط.
بيئة العمل: [name and ID]
حساب كشف الحساب: [account name and ID]
الفترة: [start through end]
مراجع المصدر المعتمدة: [exact list]
الصفوف المتوقع تأثرها: [count]
نفّذ فقط جملة SQL الدقيقة المعروضة في أحدث معاينة.
لا تغيّر أي صف آخر. توقف بعد التحقق بإعادة القراءة.

إذا تغيّرت بيئة العمل أو الحساب أو جملة SQL أو قائمة المصادر أو الأثر المتوقع، فلم تعد الموافقة سارية. اطلب معاينة جديدة وموافقة جديدة.

اكتب على دفعات صغيرة وأعِد قراءة كل دفعة

بالنسبة إلى واجهة API المباشرة، أرسل جملة INSERT أو UPDATE أو DELETE واحدة معتمدة في كل طلب إلى POST /v1/sql/execute. وبالنسبة إلى MCP، استخدم sql_execute مع expenses:write. يمكن أن يظل الإدراج متعدد الصفوف جملة واحدة، لكن اجعل الدفعات صغيرة بما يكفي ليقارن شخص كل صف بجدول المراجعة. ابدأ بأصغر مجموعة مترابطة: طرفا عملية تحويل واحدة أو عدد قليل من الصفوف العادية. ولا تتابع إلا بعد التأكد من سلامة البيانات عند إعادة قراءة الدفعة، وحصول الدفعة التالية على معاينتها وموافقتها الخاصتين.

بعد كل دفعة، استعلم مرة أخرى عن تلك الصفوف المحددة عبر /v1/sql/query أو sql_query. قارن الحساب والطابع الزمني والمبلغ بإشارته والعملة والنوع والفئة وعلاقة التحويل المخزنة بالمعاينة المعتمدة، ثم اربط كل صف أُعيدت قراءته بمرجع مصدره المعتمد. لا تثبت استجابة HTTP ناجحة أن دفتر الأستاذ يحتوي على ما قصدته.

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

سوِّ كل حساب تأثر بالاستيراد

إذا كان كشف الحساب يوفر رصيدين افتتاحيًا وختاميًا، فابدأ باتباع اصطلاح الكشف نفسه للمدين والدائن والرصيد:

expected source closing balance = source opening balance + sum(posted source movements)

أما في المتتبع، فاحسب الرصيد بدءًا من آخر نقطة تحقق موثوقة للحساب، بدل افتراض أن أول تاريخ في الكشف خضع للتسوية أصلًا:

expected tracker balance at cutoff = last known-good tracker balance
                                   + sum(signed ledger movements after that checkpoint through the cutoff)

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

إذا أنشأت عملية الاستيراد أو طابقت طرفي تحويل داخلي، فسوِّ كلا الحسابين المتأثرين مقابل كشف كل منهما أو نقاط تحقق موثوقة للرصيد. فقد يخفي تطابق حساب المصدر وحده طرفًا واردًا مُختلقًا أو مكررًا.

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

شرط التوقف بسيط: إذا وُجد في أي حساب فرق غير مفسر في الرصيد، أو صف مصدر غير محسوم، أو مبلغ أو عملة غير مؤكدة، أو تكرار أو تحويل ملتبس، فتوقف. لا تضف معاملة لموازنة الرصيد. احتفظ بالمسودة وتحقق من الفجوة المحددة باستخدام سير عمل تسوية الميزانية.

اعرف أين تذهب بيانات كشف الحساب

هذا متتبع نفقات من دون ربط الحسابات البنكية، لكنه لا يضمن بقاء كشف الحساب على جهازك.

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

لا تعني الاستضافة الذاتية لـ Expense Budget Tracker أن وكيل الذكاء الاصطناعي أو أداة OCR أو مزود النموذج مستضاف ذاتيًا أيضًا. فهذه أنظمة منفصلة، ولكل منها نطاق بيانات مستقل. إذا كانت الأولوية لتجنب الوصول المستمر إلى الحساب البنكي، فاقرأ كيف يمكن لتطبيق ميزانية أن يعمل من دون ربط الحسابات البنكية واختر كل جزء من سير العمل على هذا الأساس.

موجّه يمكنك إعادة استخدامه

استورد كشف الحساب البنكي أو كشف حساب البطاقة عن الفترة المغلقة الموجود في [file path or attachment] إلى Expense
Budget Tracker. وهو يخص بيئة العمل [name] والحساب [name]، ويغطي [dates].

لا تكتب أي بيانات بعد. احتفظ بالملف الأصلي. حدد ما إذا كان CSV منظمًا أو PDF نصيًا أو PDF
ممسوحًا ضوئيًا/مكوّنًا من صور، وأبلغ عن أي قيود على الاستخراج. استبعد النشاط المعلّق.
أنشئ جدول المراجعة نفسه الوارد في هذا المقال، واحتفظ بمرجع إلى المصدر ووصف خام ومبلغ
أصلي ومبلغ موحّد لدفتر الأستاذ وأوجه عدم اليقين لكل صف مُرحّل.

بالنسبة إلى HTTP المباشر، ابدأ من https://api.expense-budget-tracker.com/v1/، واتبع استجابة
الاكتشاف، واستخدم ApiKey طويل الأجل الذي تحصل عليه أو سبق تخزينه، وتحقق من /me ومن بيئة العمل
المحددة، وافحص /v1/schema، واقرأ عبر /v1/sql/query. وبالنسبة إلى MCP، استخدم
list_workspaces وget_schema وsql_query مع expenses:read؛ ولا تطلب expenses:write
إلا لعملية كتابة معتمدة باستخدام sql_execute.

قبل اقتراح SQL، استعلم عن القيود الحالية في الفترة المستهدفة مع إضافة ثلاثة أيام تقويمية قبلها
وبعدها. التزم بحد النتائج البالغ 100 صف باستخدام نطاقات غير متداخلة عند الحاجة.
ضع علامات على المعاملات المرشحة للتكرار، ولا تتخطها بصمت. أعد استخدام الفئات الحالية. تعامل
مع مدفوعات بطاقات الائتمان والحركات بين الحسابات التي يجري تتبعها كتحويلات، واربط حركتي
الحساب الفعليتين وفق المخطط الحالي، واترك الأطراف المقابلة المفقودة غير محسومة بدل اختلاقها.

اعرض جدول المراجعة المكتمل وأعداد الصفوف وإجماليات المصدر وأدلة التكرار وأزواج التحويل
والاستبعادات وكل العناصر غير المحسومة. ثم اعرض جملة SQL الدقيقة المبنية على المخطط الحالي لدفعة
صغيرة واحدة وعدد الصفوف المتوقع تأثرها. انتظر موافقتي الخاصة بهذه الدفعة.

بعد الموافقة، لا تنفذ سوى جملة INSERT أو UPDATE أو DELETE واحدة عبر
/v1/sql/execute أو sql_execute. أعد الاستعلام عن الصفوف المحددة وقارنها بالمعاينة
المعتمدة. سوِّ كل حساب متأثر مقابل الرصيد الختامي لكشفه أو مقابل نقطة تحقق دقيقة
وموثوقة للرصيد. توقف من دون إضافة صف موازن إذا بقي أي شيء بلا تفسير.

النتيجة ملموسة: الأدلة الأصلية، وقرار لكل صف في المصدر، وتغيير معتمد في دفتر الأستاذ، وأرصدة تستطيع تفسيرها.