Basware نے Trustpair خریدا، درست invoice کے بعد bank account بھی چیک ہوگا
Basware نے 26 اگست 2026 کو Trustpair خریدنے کے لیے پابند معاہدہ کیا، مگر transaction ابھی مکمل نہیں ہوئی۔ پیرس سے جاری Basware کے باضابطہ اعلان کے مطابق مجوزہ امتزاج invoice کی درستی اور منظوری کے بعد یہ بھی جانچے گا کہ ادائیگی مطلوبہ supplier کے bank account ہی میں جا رہی ہے۔
اسی 26 اگست کے معاہدے کی closing روایتی شرائط سے مشروط ہے اور 2026 کے بعد کے حصے میں متوقع ہے۔ ChannelPro کی 28 اگست کی رپورٹ کے مطابق مالی شرائط ظاہر نہیں کی گئیں؛ Trustpair تکمیل کے بعد آزادانہ طور پر کام جاری رکھے گی اور اس کی account-validation صلاحیت Basware کے invoice lifecycle کے ساتھ جوڑی جائے گی۔
درست invoice اور درست bank account دو الگ فیصلے ہیں
اس سودے سے fraud-prevention workflow میں شامل ہونے والا اہم مرحلہ beneficiary-account validation ہے۔ Invoice checks یہ ثابت کر سکتی ہیں کہ supplier موجود ہے، خریداری ہوئی، رقم درست ہے، invoice duplicate نہیں اور ضروری منظوری مکمل ہے؛ لیکن ان checks سے لازماً یہ ثابت نہیں ہوتا کہ ERP میں درج bank account اسی supplier کا ہے۔
Ardent Partners کے تجزیے کے مطابق Basware کا دائرہ invoice کو capture، match، validate اور approve کرنے پر مرکوز ہے، جبکہ Trustpair supplier کی شناخت، bank-account ownership، vendor data میں تبدیلی اور ادائیگی سے پہلے account کی توثیق کرتی ہے۔ اس لیے مجوزہ امتزاج دو الگ سوالات رکھتا ہے: کیا invoice قابلِ ادائیگی ہے، اور کیا رقم درست beneficiary کو ملے گی؟
ایک فرضی مثال میں purchase order، goods receipt، رقم اور invoice سب باہم درست ہیں اور finance manager منظوری دے چکا ہے۔ اگر حملہ آور supplier کا mailbox سنبھال کر bank details بدلوا دے تو invoice approval کامیاب رہ سکتی ہے؛ نئی account instruction کو supplier کی تصدیق شدہ شناخت کے مقابل الگ جانچنا ہوگا۔
Account validation تین مقامات پر آئے گی
Trustpair کی جانچ صرف payment run کے آخری لمحے تک محدود نہیں۔ اعلان میں supplier record کے دوران تین الگ مواقع بیان کیے گئے ہیں، اور ہر موقع ایک مختلف failure point کو روکتا ہے۔
- Supplier onboarding: نیا vendor شامل کرتے وقت اس کی شناخت اور دیے گئے payment account کا تعلق جانچا جاتا ہے، تاکہ غلط beneficiary ابتدا ہی سے master data کا معتبر حصہ نہ بنے۔
- Account-detail change: موجودہ supplier کے bank details بدلنے پر نئی معلومات دوبارہ verify ہوتی ہیں۔ سابقہ ادائیگیوں کا درست ہونا نئی instruction کو خودکار طور پر معتبر نہیں بناتا۔
- Pre-payment authorization: رقم جاری ہونے سے پہلے beneficiary account کو مطلوبہ supplier کے مقابل جانچا جاتا ہے۔ mismatch ملنے پر invoice لازماً غلط نہیں ہوتی، مگر payment روک کر account detail کی تحقیق ضروری ہو جاتی ہے۔
Basware نے SAP، Oracle، Coupa، Ivalua، JAGGAER، Zycus اور Kyriba جیسے ERP، procurement اور treasury ماحول کا ذکر کیا ہے، مگر اعلان پاکستان کے لیے مخصوص bank-data coverage، rollout date یا integration configuration نہیں دیتا۔ لہٰذا پاکستانی اداروں میں account ownership کی خودکار تصدیق کتنی مکمل ہوگی، یہ ابھی ایک عملی سوال ہے، ثابت شدہ دستیابی نہیں۔
پاکستانی finance teams کے لیے BEC والا خلا
Business email compromise، یا BEC، میں حملہ آور کسی supplier یا executive جیسا پیغام بھیج کر bank account بدلنے یا فوری ادائیگی کی ہدایت دے سکتا ہے۔ کبھی جعلی address استعمال ہوتا ہے اور کبھی اصل mailbox compromise ہو جاتا ہے؛ اس صورت میں پرانی email thread بھی نئی banking instruction کی آزاد تصدیق نہیں بنتی۔
INTERPOL کی BEC رہنمائی بتاتی ہے کہ مجرم email systems یا social engineering سے corporate payment process کی معلومات حاصل کرکے ملازمین کو اپنے account میں رقم بھیجنے پر آمادہ کرتے ہیں۔ bank account یا payment method بدلنے والی email آئے تو ادارہ اسی پیغام کا جواب دینے کے بجائے پہلے سے معلوم دوسرے رابطہ ذریعے، مثلاً فون، سے recipient کی تصدیق کرے۔
پاکستانی finance workflow میں procurement supplier relationship سنبھال سکتی ہے، accounts payable invoice approve کرتی ہے، ERP team master record بدلتی ہے اور treasury رقم جاری کرتی ہے۔ خطرہ اس handoff میں پیدا ہوتا ہے: ایک مرحلے کا “approved” status اگلے مرحلے میں bank detail کی صحت کا ثبوت سمجھ لیا جائے۔ Trustpair کا validation signal اس خلا کو نمایاں کر سکتا ہے، لیکن مقامی data coverage اور exception handling کی کیفیت integration پر منحصر رہے گی۔
Automation انسانی dual approval کی جگہ نہیں
Account match ایک اضافی control ہے، مکمل فیصلہ نہیں۔ خودکار validation یہ جانچ سکتی ہے کہ account اور supplier کے درمیان قابلِ تصدیق تعلق ہے، مگر صرف اسی سے یہ طے نہیں ہوتا کہ تبدیلی مجاز شخص نے مانگی، اس کی کاروباری وجہ درست ہے یا کسی exception کو قبول کرنے کا اختیار کس کے پاس ہے۔
اسی لیے account change بنانے اور منظور کرنے والے افراد کا الگ ہونا، پہلے سے محفوظ contact details کے ذریعے out-of-band confirmation، اور override کی وجہ کا audit trail اہم رہتے ہیں۔ خاص طور پر نام کی مختلف spelling، نئی قانونی entity، intermediary bank یا غیر واضح match میں انسانی review درکار ہو سکتا ہے۔ acquisition announcement میں کہیں یہ دعویٰ نہیں کہ automation dual approval کو ختم کر دے گی۔
“Validated” کو مستقل مہر بھی نہیں سمجھنا چاہیے۔ onboarding کے وقت درست account بعد میں بدل سکتا ہے، یا payment file میں master record سے مختلف detail آ سکتی ہے؛ اسی وجہ سے onboarding، account change اور pre-payment authorization الگ control points ہیں۔
Closing اور پاکستانی دستیابی ابھی واضح نہیں
موجودہ حیثیت پابند معاہدے کی ہے، مکمل acquisition کی نہیں۔ Corporate Compliance Insights کی 28 اگست کی خبر کے مطابق قیمت ظاہر نہیں کی گئی، closing 2026 میں متوقع ہے اور تکمیل کے بعد Trustpair شریک بانی اور CEO Baptiste Collot کی قیادت میں کام جاری رکھے گی۔
ابھی Basware نے پاکستان کے لیے rollout، commercial packaging، bank-account data coverage یا مشترکہ workflow کی حتمی شکل نہیں بتائی۔ تصدیق شدہ تبدیلی فی الحال control architecture کی سمت ہے: invoice کی منظوری کے بعد beneficiary account کو الگ gate پر جانچنا۔ اگلی اہم پیش رفت transaction کی closing اور اس کے بعد integration، علاقائی coverage اور دستیابی کی تفصیلات ہوں گی۔
یہ بھی پڑھیں:
ہمارا نیوز لیٹر سبسکرائب کریں
ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔