তিন-মুখী ম্যাচ অটোমেশন: AP হোল্ডের জন্য টেবিল ও ওয়ার্কফ্লো

তিন-মুখী ম্যাচ আসলে কী সমস্যার সমাধান করে

তিন-মুখী ম্যাচ অটোমেশন খুব সোজা: আপনি শুধুমাত্র তখনই একটি ইনভয়েস পেড করবেন যখন তা আপনি অর্ডার করা (PO), বাস্তবে যা পেয়েছেন (receipt), এবং সরবরাহকারীর বিল (invoice) - এই তিনটির সঙ্গে মিলবে। ওই তিনটি ডকুমেন্ট হল Purchase Order (PO), Receiving record (receipt), এবং Supplier Invoice।

এই চেক ছাড়া Accounts Payable অনেকসময় একটি ভুল বা অসম্পূর্ণ ডকুমেন্টের ওপর ভিত্তি করে পেমেন্ট করে দিতে পারে। একজন সরবরাহকারী হয়তো ডেলিভারি করা ইউনিটের চেয়ে বেশি বিল পাঠায়, সম্মত মূল্য ছাড়া অন্য দাম ব্যবহার করে, বা মেইল থ্রেডে নতুন বলে দেখানো একটি duplicate invoice পাঠাতে পারে।

এই ব্যর্থতাগুলো প্রথম দিনে বেশ নাটকীয় নজর রাখে না। এগুলো ছোট ছোট রসাহের মতো দেখা দেয়: একটি লাইন আইটেম দুইবার বিল হয়েছে, শিপমেন্ট কিছু ইউনিট কমে এসেছে, কখনও অনুমোদন করা হয়নি এমন দাম বাড়ানো হয়েছে, বা অনর্থকভাবে ফ্রেইট যুক্ত হয়েছে। সময়ের সাথে সেই ছোট ভুলগুলো মূলধন হয়ে ওঠে।

উদ্দেশ্য সিনেমা-ধাঁচে “invoice অনুমোদন” করা নয়। উদ্দেশ্য হল পেমেন্ট ব্লক করা যতক্ষণ না আপনি নির্ধারিত প্রধান ফিল্ডগুলো (সাধারণত পরিমাণ, ইউনিট মূল্য, এবং টোটাল) PO, receipt, এবং invoice-এ মিলছে। যদি মিল না হয়, ইনভয়েস ইমেইলে হারিয়ে যাওয়া উচিত নয়। সেটি একটি exception queue-তে যেতে হবে যেখানে পরিষ্কার reason code এবং ঠিক কোন ফিল্ডগুলো আলাদা তা দেখাবে।

তিন-মুখী ম্যাচ টিমগুলোর মধ্যে একটি পরিষ্কার বিভাজনও করে। Procurement কন্ট্রোল করে কি অর্ডার করা হয়েছিল (শর্ত ও দাম)। Receiving নিশ্চিত করে কি পৌঁছেছে (পরিমাণ ও তারিখ)। Finance নিয়ন্ত্রণ করে কী পে করা হবে (invoice রিভিউ ও রিলিজ)।

শুরুতেই প্রত্যাশা সেট করুন: এটি একটি প্রক্রিয়া এবং ডেটা সমস্যা, approval বাটন নয়। যদি PO লাইনের বিবরণ অস্বচ্ছ থাকে, receipts রেকর্ড না করা হয়, বা ইনভয়েস PO লাইনের সাথে যুক্ত না করা যায়, অটোমেশন আপনাকে বাঁচাতে পারবে না।

ডকুমেন্ট এবং দায়িত্ব: PO, receipt, invoice, এবং কে কোনটা দায়িত্বে

তিন-মুখী ম্যাচ তখনই কাজ করে যখন প্রতিটি ডকুমেন্টের স্পষ্ট মালিক থাকে। “কে কি আপডেট করে” যদি অস্পষ্ট থাকে, সিস্টেম ভালো পেমেন্টগুলো ব্লক করে বা খারাপগুলিকে ছাড়িয়ে দেয়।

একটি বাস্তবসম্মত ownership মডেল হতে পারে:

• Requester ক্রয় অনুরোধ তৈরি করে এবং প্রয়োজন নিশ্চিত করে।
• Procurement PO তৈরি ও রক্ষণাবেক্ষণ করে (supplier, price, terms)।
• Warehouse/receiver (বা সার্ভিস মালিক) receipt বা acceptance পোস্ট করে।
• AP/Finance ইনভয়েস রেকর্ড করে এবং পেমেন্ট নিয়ন্ত্রণ করে।

প্রতিটি ডকুমেন্টের জন্য matching গ্যাসে না হয়ে যাতে নির্ভরযোগ্য হয় তার জন্য ন্যূনতম কিছু ফিল্ড দরকার।

PO (ক্রয় অর্ডার)-এ প্রয়োজন supplier ID, PO number, line items (SKU বা সার্ভিস), ordered quantity, unit price, currency, tax rules, এবং payment terms।

Receipt-এ প্রয়োজন PO রেফারেন্স, receipt date, PO লাইনে প্রাপ্ত পরিমাণ এবং যারা পেয়েছে তাদের তথ্য। সার্ভিসের ক্ষেত্রে এটিকে acceptance হিসেবে বিবেচনা করুন এবং approver রেকর্ড করুন।

Invoice-এ প্রয়োজন supplier invoice number, invoice date, PO রেফারেন্স (বা PO খুঁজে পাওয়ার নিরাপদ উপায়), লাইন বিবরণ (qty, unit price), taxes/shipping, এবং total।

এছাড়াও ঠিক করে নিন কখন ম্যাচ চালানো হবে। এটি এককালীন ইভেন্ট হওয়া উচিত নয়। যখনই বাস্তবতা বদলায় তখন ট্রিগার করুন:

1. একটি ইনভয়েস ক্যাপচার করা হলে (যাতে আপনি তৎক্ষণাৎ পে বনাম হোল্ড সিদ্ধান্ত নিতে পারেন)।
2. একটি receipt পোস্ট করা হলে (একটি হোল্ড থাকা ইনভয়েস payable হতে পারে)।
3. একটি PO পরিবর্তিত হলে (খোলা ইনভয়েসগুলো পুনরায় চেক করা হবে)।

আংশিক রিসিপ্ট এবং একাধিক ইনভয়েস স্বাভাবিক। একটি PO লাইন তিনটি ডেলিভারিতে আসতে পারে এবং দুইটি ইনভয়েসে বিল হতে পারে। আপনার লজিকটি PO লাইনের প্রতি cumulative received বনাম cumulative invoiced তুলনা করবে, কেবল এক সিংহদস্তর ডকুমেন্ট নয়।

কিছু নিয়ম আগে ঠিক করে নিন (build করার আগে)

টেবিল বা ওয়ার্কফ্লো স্টেপগুলোর আগে পুরো সিস্টেম চালানো যে নিয়মগুলো থাকবে তা নিয়ে একমত হন। অস্পষ্ট নিয়ম predictable ব্যর্থতা তৈরি করে: অথবা সিস্টেম খুব বেশি ব্লক করে (মানুষ বাইপাস করে), বা খুব কম ব্লক করে (খারাপ ইনভয়েস পে হয়ে যায়)।

ম্যাচিং লেভেল নির্ধারণ করুন। Header-only matching কেবল নথির মোটগুলো চেক করে। সহজ মনে হলেও এটি আংশিক ডেলিভারি, ব্যাকঅর্ডার, ফ্রেইট লাইন বা মিশ্র ট্যাক্স রেটের ক্ষেত্রে দ্রুত ভেঙে পড়ে। Line-level matching সেটআপে বেশি সময় নেয়, কিন্তু এটি নিরাপদ ডিফল্ট কারণ আপনি PO, receipt, এবং invoice-এ একই লাইন, তার পরিমাণ, এবং ইউনিট মূল্য তুলনা করেন।

কখন হার্ড ব্লক বনাম সতর্কবার্তা (warning)। হার্ড ব্লক মানে পেমেন্ট চলবে না যতক্ষণ না সমস্যা মেটানো হয়। Warning মানে ইনভয়েস এগোতে পারে, কিন্তু কেউ ঝুঁকি স্বীকার করবে।

সাধারণ শুরু পয়েন্টগুলো:

• হার্ড ব্লক: ইনভয়েসকৃত পরিমাণ প্রাপ্ত পরিমাণের চেয়ে বেশি (পণ্যগুলির জন্য)।
• হার্ড ব্লক: ইউনিট মূল্য PO মূল্যের তুলনায় নির্দিষ্ট সহনশীলতা ছাড়িয়ে গেছে।
• ওয়ার্নিং: হালকা রাউন্ডিং পার্থক্য।
• ওয়ার্নিং: ট্যাক্স বা শিপিং পার্থক্য যা আলাদাভাবে প্রত্যাশিত এবং কোড করা হয়।

সহনশীলতার নিয়মগুলো স্পষ্ট রাখুন। পদ্ধতি নির্ধারণ করুন (শতাংশ, অ্যাবসোলিউট পরিমাণ, বা উভয়ের মধ্যে বড়), এবং কে এর মালিক হবে। উদাহরণ: প্রতি লাইনের জন্য +/- 1% বা +/- $5 অনুমতিযোগ্য, এবং finance শুধুমাত্র একটি audit note সহই tolerances পরিবর্তন করতে পারবে।

একটি ছোট, শেয়ার করা status সেট ব্যবহার করুন। প্রতি টিম আলাদা কাস্টম স্ট্যাটাস এড়িয়ে চলুন। সাধারণত একটি পরিষ্কার সেট যথেষ্ট: Matched, Hold, Exception, Approved. “Hold” মানে পেমেন্ট ব্লক আছে। “Exception” মানে একজন মানুষ রিভিউ করা দরকার। “Approved” মানে একজন নামকৃত ব্যক্তি অমিলটি অনুমোদন করেছে এবং কেন তা রেকর্ড করেছে।

ডেটা মডেল: দরকারি টেবিলগুলো (এবং কেন)

তিন-মুখী ম্যাচ অটোমেশন তখনই কাজ করে যখন আপনার ডেটা মডেল একটি PO লাইন, কী এসেছে, এবং কী ইনভয়েস করা হয়েছে—এই তিনটিকে সাজাতে পারে। প্রতিটি invoice line একটি নির্দিষ্ট PO line-এ matchable হওয়া উচিত (অথবা স্পষ্টভাবে non-PO হিসেবে চিহ্নিত), এবং প্রতিটি receipt line সেই PO লাইনের বাকি পরিমাণ কমিয়ে দিতে হবে।

কোর পারচেসিং টেবিলগুলো দিয়ে শুরু করুন:

• Vendors: প্রতিটি supplier-এর জন্য একটি পঙক্তি (name, terms, tax info).
• ItemsServices: ঐচ্ছিক, কিন্তু consistency-র জন্য সহায়ক (SKU, description, unit of measure).
• PurchaseOrders: PO হেডার (vendor_id, currency, requested_by, status).
• PO_Lines: মিলানোর এঙ্কর (po_id, item_id/description, ordered_qty, unit_price).

Receiving-কে আলাদা রেকর্ড রাখতে হবে, এমনকি যদি একটি “receipt” শুধুমাত্র কনফার্মেশনই হয়। receipts আলাদা রাখুন যাতে আপনি কী এসেছে এবং কখন এসেছে প্রমাণ করতে পারেন:

• Receipts: receipt হেডার (vendor_id, received_date, location, status).
• Receipt_Lines: প্রতিটি লাইন PO লাইনকে রেফার করে (receipt_id, po_line_id, received_qty, notes).

Invoicing receiving-এর মতই মিরর করবে। সরবরাহকারী যা বিল করেছে সেটি লাইন লেভেলে সংরক্ষণ করুন এবং এটি যে PO লাইনের আওতায় তা সংযুক্ত করুন:

• Invoices: invoice হেডার (vendor_id, invoice_number, invoice_date, due_date, status).
• Invoice_Lines: (invoice_id, po_line_id যখন প্রযোজ্য, invoiced_qty, unit_price, tax, line_total).

অবশেষে, একটি payment-facing রেকর্ড তৈরি করুন যাকে আপনার ওয়ার্কফ্লো ব্লক করতে পারে। কিছু টিম এটিকে bill বা payment request বলে:

• PaymentRequests (বা Bills): invoice_id-র সঙ্গে টাই করা এবং payment_hold (true/false) ও hold_reason অন্তর্ভুক্ত।

অডিট ও পরিষ্কার exception হ্যান্ডলিং-এর জন্য, হেডারগুলোর (POs, receipts, invoices, payments) উপর সাধারণ lifecycle ফিল্ড যোগ করুন: status, created_at/created_by, approved_at/approved_by, posted_at, এবং (ঐচ্ছিক) source_document_id ইম্পোর্টের জন্য।

ম্যাচিংকে নির্ভরযোগ্য করে তোলার জন্য প্রধান ফিল্ড ও সম্পর্কগুলো

ম্যাচিং সবচেয়ে ভালো কাজ করে যখন প্রতিটি ডকুমেন্ট একই লাইন আইটেমকে ট্রেস করে। এর মানে স্থিতিশীল IDs, পরিষ্কার লিঙ্ক, এবং লাইনের থেকে পুনরায় হিসাব যোগফল যাতে মোটগুলো পুনরায় গননা করা যায়।

নিশ্চিত করুন প্রতিটি টেবিলে একটি স্থিতিশীল অভ্যন্তরীণ ID এবং মানুষ যে বাইখোঁজ করে সেই বাইরের নম্বর দুটোই আছে:

• PO header: po_id, po_number, vendor_id, currency, status, po_date
• PO lines: po_line_id, po_id, item_id or description, ordered_qty, unit_price, tax_rate, line_total
• Receipts: receipt_id, receipt_number, vendor_id, received_date; receipt_line_id, receipt_id, po_line_id, received_qty
• Invoices: invoice_id, vendor_id, vendor_invoice_number, invoice_date, currency, subtotal, tax_total, total; invoice_line_id, invoice_id, po_line_id, qty, unit_price, tax_amount, line_total
• Vendors and items: vendor_id, payment_terms, default_currency; item_id, uom, tax_code

সবচেয়ে গুরুত্বপূর্ণ লিঙ্কগুলো হল লাইন-লেভেল:

• invoice_line.po_line_id উচিত PO লাইনের দিকে ইঙ্গিত করা।
• receipt_line.po_line_id উচিত একই PO লাইনকে নির্দেশ করা।

এটাই আপনাকে quantity এবং price তুলনা করতে দেয়, অনুমান না করে।

আংশিকতার জন্য, PO লাইনের প্রতি চালমান মোট হিসাব করুন: received_qty (receipt linesের যোগফল) এবং invoiced_qty (invoice linesের যোগফল)। তারপর remaining_qty = ordered_qty - received_qty এবং open_to_invoice_qty = received_qty - invoiced_qty গণনা করুন। এই মানগুলো স্পষ্ট করে দেয় যে একটি ইনভয়েস আগেই এসেছে, পরে এসেছে, বা বেশি বিল করা হয়েছে।

PO বদলালে ইতিহাস ওভাররাইট করবেন না। PO revision number রাখুন এবং পুরনো PO লাইনগুলো রেখেই একটি active flag দিন (বা পরিবর্তনের লগ লিখুন - কে কি বদলাল, কখন, পুরোনো মান ও নতুন মান)।

ডুপ্লিকেট ও খারাপ জয়েন প্রতিরোধে মৌলিক গার্ডরেইল যোগ করুন:

• Unique (vendor_id, vendor_invoice_number)
• Unique receipt_number and po_number
• Not null on currency, quantities, and unit_price
• Check constraints like qty >= 0 and unit_price >= 0
• Foreign keys from invoice_line and receipt_line to po_line

ধাপে ধাপে ওয়ার্কফ্লো: ইনভয়েস ইন্টেক থেকে পেমেন্ট হোল্ড পর্যন্ত

তিন-মুখী ম্যাচ অটোমেশন সাধারণত তিনটি এন্ট্রি পয়েন্ট থাকে: একটি ইনভয়েস আসে (ইমেইল, আপলোড, EDI), একটি receipt পোস্ট করা হয়, বা একটি PO পরিবর্তিত হয় (দাম, পরিমাণ, স্ট্যাটাস)। ওয়ার্কফ্লোকে যেকোনো এগুলোর প্রতিক্রিয়া জানানো উচিত যাতে একটি ইনভয়েস যত তাড়াতাড়ি অনুপস্থিত অংশ পায় তত তাড়াতাড়ি হোল্ড থেকে মুক্ত হতে পারে।

1) প্রথমে ইনভয়েসের বেসিক যাচাই করুন। নিশ্চিত করুন vendor active, PO আছে, currency PO-র সঙ্গে মেলে, এবং মোটগুলো অভ্যন্তরীণভাবে সঙ্গতিপূর্ণ (লাইন মোটগুলো যোগ করলে সামঞ্জস্য আছে, ট্যাক্স যুক্তির মধ্যে, নেগেটিভ পরিমাণ না চেয়ে ব্যতীত ক্রেডিট সাপোর্ট করলে সে অনুযায়ী)। যদি এই যাচাই ব্যর্থ হয়, ইনভয়েস সরাসরি Hold-এ পাঠান একটি স্পষ্ট কারণ দেখিয়ে।

2) লাইন-ভিত্তিক ম্যাচ করুন, কেবল হেডার নয়। প্রতিটি invoice line-এর জন্য সম্পর্কিত PO line এবং ততকালীন receipt totals খুঁজে বের করুন। তুলনা করুন:

• Invoiced পরিমাণ বনাম received পরিমাণ (অথবা received থেকে ইতিমধ্যে invoiced কেটে দেয়া)
• Invoiced ইউনিট মূল্য বনাম PO-র ইউনিট মূল্য
• সহনশীলতার নিয়ম
• PO লাইন এখনও invoicing-এ খোলা আছে কি না

3) স্ট্যাটাস সেট করুন এবং ব্লক প্রয়োগ করুন। একটি সাধারণ প্যাটার্ন:

• Matched: সব লাইনে চেক পাস, কোন ওপেন exception নেই।
• Hold: অন্তত একটি লাইন ব্যর্থ, বা প্রয়োজনীয় ডেটা অনুপস্থিত।

যখন Hold সেট করা হয়, একটি payment hold রেকর্ড তৈরি করুন যা payment run অবশ্যই সম্মান করবে। holds গুলো ইনভয়েস থেকে আলাদা রাখুন যাতে হোল্ড যোগ/রিলিজ/প্রতিস্থাপন করা যায় ইনভয়েস ইতিহাস না বদলে।

4) ফাইন্যান্স যাকে বিশ্বাস করবে এমন রিজন কোড রেকর্ড করুন। শুধুমাত্র ফ্রি-টেক্সট হোল্ড এড়িয়ে চলুন। PRICE_OVER_TOLERANCE, QTY_NOT_RECEIVED, PO_CLOSED, VENDOR_MISMATCH, বা CURRENCY_MISMATCH-এর মত কোড ব্যবহার করুন এবং একটি সংক্ষিপ্ত নোট রাখুন।

ফাইন্যান্সের জন্য exception queue ডিজাইন (কি স্টোর করবেন এবং কি দেখাবেন)

একটি exception queue-ই মিলানোর কাজটিকে ব্যবহারযোগ্য করে, কেবল কঠোর নিয়ম নয়। ফাইন্যান্সকে কেবল সেই ইনভয়েসগুলো দেখান যেগুলো সিদ্ধান্তের জন্য দরকার, পর্যাপ্ত প্রেক্ষাপটের সঙ্গে যাতে তারা দ্রুত সিদ্ধান্ত নিতে পারে এবং একটি পরিষ্কার অডিট ট্রেল রেখে যাবে।

একটি সাধারণ পদ্ধতি হলো একটি ডেডিকেটেড টেবিল ExceptionCases রাখা। প্রতিটি সারি একটি ব্লক করা ইনভয়েস (অথবা ইনভয়েস লাইনে) প্রতিনিধিত্ব করে এবং invoice, PO, ও receipt রেকর্ডগুলোর দিকে ইঙ্গিত করে। matching engine এখানে রিড-অনলি রাখুন। কিউ শুধু সিদ্ধান্ত এবং ডকুমেন্টেশনের জন্য।

ExceptionCases-এ কি স্টোর করবেন

কি ভুল হয়েছে, কতটা বড়, কে মালিক, এবং পরের পদক্ষেপ কি—এগুলো রাখুন:

• Type (missing receipt, price variance, quantity variance, PO not found, duplicate invoice)
• Severity (info, warning, block) এবং ইউজার-ফ্রেন্ডলি কারণ
• Owner (ব্যক্তি বা টিম) এবং status (open, waiting on vendor, waiting on warehouse, resolved, overridden)
• Variance snapshot as sortable numbers (invoice amount, matched amount, price delta, quantity delta)
• SLA ফিল্ড (due date, escalation flag, reassigned_at, reassignment_reason)

সহযোগিতা ও অডিট ডেটাও রাখুন: comments (author, timestamp) এবং attachment metadata (file name, type, uploaded_by, uploaded_at)। ফাইলগুলো অন্য কোথাও থাকলেও, মেটাডেটা কেসে থাকা উচিত যাতে ইতিহাস অক্ষুণ্ণ থাকে।

ফাইন্যান্স কি দেখতে পাবে (এবং কি করতে পাবে)

কিউ ভিউটি একটি টাইট ওয়ার্কলিস্ট হওয়া উচিত: vendor, invoice number, exception type, severity, amount, due date, owner, এবং একটি স্পষ্ট “কেন ব্লক হয়েছে” মেসেজ।

কেস ওপেন করলে একটি সাইড-বাই-সাই সামারি দেখান: PO লাইনের তালিকা, receipt পরিমাণ, invoice লাইন এবং ঠিক কোন ফিল্ডগুলো ব্যর্থ হয়েছে।

অ্যাকশনগুলো সীমিত ও নিরাপদ রাখুন:

• Request receipt (receiving-কে রাউট করে, status waiting করে)
• Request credit memo (vendor-কে রাউট করে, প্রত্যাশিত সমন্বয় রেকর্ড করে)
• Approve override (কারণ প্রয়োজন, approver ও timestamp ধরবে)
• Reassign (owner আপডেট করে, reassignment ইতিহাস রাখে)
• Close as resolved (শুধু তখনই যখন পরিবর্তনগুলো match পাস করে)

উদাহরণ: একটি ইনভয়েস ব্লক হয় কারণ 8 ইউনিট পাওয়া গেছে কিন্তু 10 ইউনিট বিল করা হয়েছে। ফাইন্যান্স একটি কেস দেখে পরিষ্কার কারণ (Quantity variance: +20) এবং দ্রুত সিদ্ধান্ত নিতে পারে—রিসিভারকে কনফার্ম করতে অনুরোধ করা অথবা বায়ারকে ফলো-আপ করতে বলা।

বাস্তবসম্মত উদাহরণ: আংশিক রিসিপ্ট এবং mismatch ইনভয়েস

একজন buyer 100 ইউনিট আইটেম A PO করে, ইউনিট দরে $10.00। PO মোট $1,000। দুই দিন পরে warehouse 80 ইউনিটের একটি receipt পোস্ট করে।

তারপর একটি ইনভয়েস আসে 100 ইউনিটের জন্য $10.00 প্রতি ইউনিটে। ম্যাচিং উচিত invoice লাইনের তুলনা করা যা প্রাপ্ত হয়েছে, কেবল অর্ডার করা ছিল তার সঙ্গে নয়।

সেই লাইনে:

• Ordered: 100 ইউনিট
• Received: 80 ইউনিট
• Invoiced: 100 ইউনিট
• Matched quantity: min(Received, Invoiced) = 80 ইউনিট
• Unmatched quantity: Invoiced - Matched = 20 ইউনিট

ইনভয়েসটি “On hold” হবে কারণ 20 ইউনিটের কোন receipt নেই। ফাইন্যান্স একটি কেস দেখে যেখানে স্পষ্ট কারণ আছে (Quantity variance: +20) এবং প্রধান সংখ্যাগুলো পাশে পাশে প্রদর্শিত।

নোটিফিকেশনগুলো দ্রুত সমস্যা ঠিক করতে পারে এমন ব্যক্তিদের যাবে: সাধারণত receiver (যদি কোন receipt মিসিং থাকে তা নিশ্চিত করার জন্য) এবং buyer (যদি শিপমেন্ট সত্যিই কম ছিল তবেই ফলো-আপের জন্য)।

বাকি 20 ইউনিট আসলে যখন আসে, warehouse একটি দ্বিতীয় receipt পোস্ট করে 20 ইউনিটের জন্য। সিস্টেম পুনরায় ম্যাচ চালায়: received হয় 100, unmatched 0 হয়, ইনভয়েস Matched-এ চলে যায় এবং হোল্ড রিলিজ হয়।

এবার যদি দামেও অমিল থাকে: সরবরাহকারী 100 ইউনিট $10.50 করে ইনভয়েস করে, তবে পরিমাণ মিলেছে কিন্তু দাম মিলছে না। প্রত্যাশিত রেজাল্ট: ইনভয়েস হোল্ড থাকবে এবং "Price variance: +$0.50/unit (+$50 total)" মতো একটি কারণের সঙ্গে রুট করা হবে।

সাধারণ ভুলs যা তিন-মুখী ম্যাচ ওয়ার্কফ্লো ভেঙে দেয়

অধিকাংশ ম্যাচিং ব্যর্থতা গনিত সম্পর্কিত নয়। সেগুলো আসে দুর্বল ডেটা লিঙ্ক এবং পোস্ট করা ডকুমেন্টগুলোর উপর আলোকিত নিয়ন্ত্রণের অভাব থেকে।

শুধুমাত্র ইনভয়েস টোটালে ম্যাচ করা। একটি হেডার ঠিক মনে হতে পারে যখন একটি লাইন বেশি দামি বা কমে আছে। লাইন-লেভেল ম্যাচ করুন, এবং স্পষ্ট করুন কি ভিন্ন হতে পারে (প্রায়ই freight) এবং কি হতে পারবে না (প্রাপ্ত পরিমাণ ও ইউনিট মূল্য)।

একটি receipt এবং একটি invoice-ই থাকবে ধরে নেওয়া। বাস্তব পারচেসিংয়ে বিভক্ত শিপমেন্ট ও আংশিক বিলিং থাকে। একই PO লাইনের বিরুদ্ধে অনেক receipt ও অনেক invoice সাপোর্ট করুন এবং প্রতি লাইনের বাকি ওপেন পরিমাণ ট্র্যাক করুন।

পোস্ট করা receipts বা invoices সম্পাদনা করার অনুমতি দিন কিন্তু ট্রেইল না রাখুন। কেউ যদি পরপর পরিমাণ চেঞ্জ করতে পারে, ম্যাচ প্রমাণ হওয়া বন্ধ হয়ে যাবে। পোস্ট করা রেকর্ড লক করুন এবং পরিবর্তনগুলো adjustment ডকুমেন্টের মাধ্যমে করুন যাতে ইতিহাস রক্ষিত থাকে।

ডুপ্লিকেট প্রতিরোধ না থাকা। একই vendor invoice number দুইবার এন্ট্রি হতে পারে, বা PDF অন্য কেউ আবার আপলোড করতে পারে। শুরুতেই uniqueness যোগ করুন (vendor + invoice number, এবং ঐচ্ছিকভাবে date/amount) এবং ডুপ্লিকেট ধরা পড়লে স্পষ্ট মেসেজ দেখান।

অস্পষ্ট exception কারণ। ফাইন্যান্সকে অনুমান করতে হবে না। reason code ব্যবহার করুন যা পরিষ্কারভাবে রুট করে: price mismatch, quantity mismatch, missing receipt, duplicate suspected, PO not found, vendor mismatch।

পেমেন্ট ব্লক চালু করার আগে দ্রুত চেকলিস্ট

পেমেন্ট ব্লকিং হল যেখানে ম্যাচ রিপোর্ট থেকে নিয়ন্ত্রণে পরিণত হয়। যদি বেসিকগুলো শক্ত না হয়, আপনি ফাইন্যান্সের জন্য শব্দ-আবর্জনা তৈরি করবেন এবং ভেন্ডারদের কাছে বিল বিলম্ব হবে।

কিছু ইনভয়েস নিয়ে পরীক্ষা-নিরীক্ষা চালান: একটি পরিষ্কার ম্যাচ, একটি আংশিক receipt, একটি দাম পরিবর্তন, এবং একটি ট্যাক্স পার্থক্য। যদি কোনোটি পরিষ্কারভাবে ম্যাচ না হয়, ডেটা ও নিয়ম আগে ঠিক করুন।

চেকলিস্ট:

• Reference completeness: প্রতিটি ইনভয়েসে vendor ও PO রেফারেন্স আছে, এবং প্রতিটি invoice line একটি নির্দিষ্ট PO line-এ ম্যাপ করতে পারে (শুধু “PO total” নয়)। সিদ্ধান্ত নিন vendor কেবল PO header নম্বর পাঠালে কী হবে।
• Consistent math: পরিমাণ, ইউনিট মূল্য, এবং মোটগুলো একইভাবে প্রতিবার পুনরায় গণনা করা যায়। ট্যাক্স, ফ্রেইট, ডিসকাউন্ট, ও রাউন্ডিং (উদাহরণ: per-line রাউন্ডিং বনাম কেবল invoice total এ) সম্পর্কে স্পষ্ট হন।
• Statuses আগেভাগে ব্লক করে: কোনো payment request বা payout রেকর্ড তৈরি হওয়ার আগে “on hold” সেট করুন।
• Structured exceptions: প্রতিটি হোল্ড একটি reason code এবং owner (AP, buyer, receiver) স্টোর করে। due dates যোগ করুন যাতে হোল্ড অবিরত থাকে না।
• Real audit trail: ওভাররাইডগুলো কে অনুমোদন করেছে, কখন, এবং কি অনুমোদিত তা রেকর্ড করে। যদি এডিট করার অনুমতি থাকে, আগে ও পরে মান লগ করুন।

পরবর্তী ধাপ: প্রক্রিয়া পাইলট করুন এবং ভিজ্যুয়ালি তৈরি করুন

তিন-মুখী ম্যাচ অটোমেশনকে যেকোনো কন্ট্রোলের মতো বিবেচনা করুন: প্রথমে একটি ছোট ব্যাবহারে প্রমাণ করুন, তারপর রোলআউট করুন।

পাইলট শুরু করুন যা সহজে পর্যবেক্ষণযোগ্য। একটি ব্যবসায়িক ইউনিট, কিছু পরিষ্কার ইনভয়েস পাঠানো ভেন্ডার গ্রুপ, বা একটি একক আইটেম ক্যাটেগরি বেছে নিন। প্রথমে নিয়ম কঠোর রাখুন (নিখুঁত পরিমাণ ও মূল্য মিল) যাতে ডেটা কোয়ালিটি সমস্যা দ্রুত উঠে আসে।

সফলের মাপান একটি সরল ফাইন্যান্স ভিউ দিয়ে: প্রতি সপ্তাহে হোল্ড সংখ্যা, শীর্ষ reason কোড, হোল্ড থেকে রিলিজের সময়, কতগুলো হোল্ড প্রকৃত অমিল ছিল, এবং কোন ভেন্ডার বারবার exception করছে।

দ্রুত প্রোটোটাইপ করতে চাইলে, একটি no-code প্ল্যাটফর্ম সহায়ক হতে পারে কারণ আপনি টেবিল, matching নিয়ম, এবং রাউটিং কোড না লিখেই মডেল করতে পারবেন। উদাহরণস্বরূপ AppMaster (appmaster.io)-এ আপনি PO, receipt, invoice, এবং exception টেবিলগুলো বানিয়ে hold লজিক ভিজ্যুয়াল বিজনেস প্রসেসে কানেক্ট করতে পারেন যাতে একই নিয়ম প্রতিটি ট্রিগারে চলে।

পাইলট গ্রুপের আসল ইনভয়েস নিয়ে টেস্ট করুন, আংশিক receipt ও সাধারণ ভেন্ডার ভুলসমেত। প্যাটার্নগুলো দেখার পরই matching কী ব্যবহার করা হবে এবং ছোট সহনশীলতা যোগ করার মতো সিদ্ধান্ত নিন। একবার হোল্ডগুলো যুক্তিযুক্ত মনে হলে এবং রেজোলিউশন সময় উন্নত হলে, পরিসর বাড়ান এবং আরও সমৃদ্ধ নিয়ম যোগ করুন (ট্যাক্স ও ফ্রেইট হ্যান্ডলিং, unit-of-measure কনভার্সন, split shipments) কিন্তু মূল কন্ট্রোল রাখুন: ম্যাচ ক্লিয়ার না হওয়া পর্যন্ত পেমেন্ট রিলিজ হয়নি।