মাসিক ক্লোজ হোক দ্রুত: নিয়ন্ত্রণ না হারিয়ে রিকনসিলিয়েশন অটোমেট করার উপায়

কল্পনা করুন তিনজনের একটি finance টিম, মাস শেষের চতুর্থ কার্যদিবসের সন্ধ্যা ৬টা ৪০ (দৃশ্যটি কাল্পনিক)। bank feed-এ ১,০০০টি লাইন। ৫৪০টি হাতে টিক দেওয়া হয়ে গেছে, কিন্তু ৯,৭১২.৪০-এর একটি gateway payout অমিল পড়ে আছে, কারণ কোনো একটি order-এর অঙ্কের সঙ্গে সেটা মেলে না।

আসলে ওটা ২৩টি order-এর টাকা: মোট ১০,০০০.০০, তা থেকে ফি ২৮৭.৬০ বাদ। accountant সেটা জানেন, কিন্তু প্রমাণ করতে হলে "final_v7" নামের spreadsheet-এ ২৩টি invoice খুলতে হবে। management meeting কাল, আর সেখানে আলোচনা হবে তিন সপ্তাহ আগের সংখ্যা নিয়ে।

ধীর closeের দোষ সাধারণত মানুষের নয়, ডিজাইনের। মাসের বেশির ভাগ কাজ শেষ কয়েক দিনের জন্য জমিয়ে রাখা হয়, আর সেই কাজের বড় অংশ হলো দুটো তালিকা হাতে ধরে মেলানো।

এই লেখায় দেখব কীভাবে কাজ এগিয়ে এনে, সাব-ledgerকে নিজে থেকে পোস্ট করতে দিয়ে আর rule দিয়ে ব্যাংক reconciliation automate করে closeের সময় কমানো যায়, অথচ প্রতিটি বিচারের সিদ্ধান্ত মানুষের হাতেই থাকে। সঙ্গে থাকছে একটি হিসাবকষা উদাহরণ, দায়িত্বশীল ব্যক্তিসহ একটি close calendar আর নজর রাখার মতো কয়েকটি metric।

ছোট টিমের close কেন দশ দিন বা তার বেশি লাগে

সংখ্যায় দেখা যাক। APQC-এর জেনারেল অ্যাকাউন্টিং বেঞ্চমার্কিং জরিপে ২,৩০০ প্রতিষ্ঠানের তথ্য ছিল; CFO.com-এর প্রতিবেদন অনুযায়ী মাস বন্ধ করতে মধ্যমা সময় ৬.৪ calendar দিন, সেরা এক-চতুর্থাংশ ৪.৮ দিন বা তার কম, আর পিছিয়ে থাকা এক-চতুর্থাংশের লাগে ১০ দিন বা তার বেশি। জরিপটি কয়েক বছরের পুরোনো এবং ট্রায়াল ব্যালেন্স থেকে calendar দিন গুনেছে, তাই এটিকে মোটামুটি মাপকাঠি ধরুন, লক্ষ্য নয়।

আসল প্রশ্ন, পিছিয়ে থাকা দলগুলো ধীর কেন। কারণগুলো প্রায় সবসময় একই:

• তথ্য দেরিতে আসে। গেটওয়ের পেআউট, courier-এর টাকা আর সরবরাহকারীর বিল নতুন মাসের প্রথম দিন থেকে তাড়া করে আনতে হয়।
• system ledgerের সঙ্গে কথা বলে না। বিক্রি, payment, বেতন আর stock-এর তথ্য আবার টাইপ করা হয় বা journal হিসেবে ইমপোর্ট হয়।
• reconciliation হাতে করা। কেউ একজন হাজার হাজার ব্যাংক লাইন invoiceের সঙ্গে একটা একটা করে টিক দিয়ে মেলান।
• সবকিছু একজনের অপেক্ষায় বসে থাকে। স্প্রেডশিট যিনি চেনেন সেই accountantই একমাত্র রিভিউয়ার।
• ভুল ধরা পড়ে দেরিতে। প্রথম সপ্তাহের একটা ভুল ট্যাক্স কোড ধরা পড়ে পঞ্চম সপ্তাহে।

continuous accounting: closeকে আর "event" বানাবেন না

সবচেয়ে দ্রুত close সেটাই, যার হাতে করার মতো কাজ প্রায় বাকি নেই। ধারণাটা (যাকে বলা হয় continuous accounting) সহজ: তথ্য পাওয়া মাত্র কাজটা করে ফেলুন, আর ledgerকে সবসময় প্রায় নির্ভুল রাখুন।

বাস্তবে এর মানে তিনটি বদল:

• ঘটনার মুহূর্তেই পোস্ট করুন। বিক্রি, refund বা বেতনের রান ঘটার সময়ই নিজের journal লিখে ফেলবে, মাস শেষে নয়।
• সাপ্তাহিক বা দৈনিক reconciliation। দশটা ছোট reconciliation একটা বিশাল reconciliationের চেয়ে দ্রুত হয়, আর সমস্যা ধরা পড়ে যখন সবার মনে আছে।
• সব নয়, শুধু exception দেখুন। রুটিন আইটেম system মিটিয়ে দিক; মানুষকে দেখান শুধু সেগুলো, যেখানে সিদ্ধান্ত লাগে।

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

যে সাব-ledger নিজেই পোস্ট করে

সাব-ledger হলো বিস্তারিত রেকর্ড, যেমন customer invoice বা stock মুভমেন্ট, যা জেনারেল ledgerের একটি control accountে গিয়ে জমা হয়। সাব-ledger নিজে থেকে পোস্ট করলে নিয়মিত কাজের জন্য জেনারেল ledgerে আর হাতে journal লিখতে হয় না।

উৎস	যা নিজে থেকে পোস্ট হওয়া উচিত	যে কন্ট্রোল রাখতে হবে
বিক্রি ও return	আয়, ট্যাক্স, প্রাপ্য বা নগদ, refund আর credit note	সেলস সাব-ledgerের মোট অঙ্ক আর আয়ের account সমান
payment ও গেটওয়ে	প্রাপ্ত নগদ, গেটওয়ে ফি, chargeback, পেআউট	প্রতিটি পেআউটের পর গেটওয়ে clearing account শূন্যে ফেরে
courier settlement	COD-তে আদায়, courier ফি, পথে থাকা return	courier ক্লিয়ারিং ব্যালান্স খোলা parcelের সঙ্গে মেলে
বেতন	মোট বেতন, কর্তন, নিয়োগকর্তার খরচ, নিট বেতনের দায়	payroll রেজিস্টার আর পোস্ট হওয়া journal সমান
inventory ও বিক্রীত পণ্যের খরচ	প্রাপ্তি, ইস্যু, অ্যাডজাস্টমেন্ট, transfer, প্রতিটি বিক্রির খরচ	stock ভ্যালুয়েশন report আর inventory account সমান

দুটি বিষয় আলাদা করে খেয়াল করুন। প্রথমত, গেটওয়ে ও courier-এর clearing account আপনার আগাম সতর্কসংকেত: শূন্যে না ফিরলে কোথাও একটা পেআউট বা parcel হারিয়েছে। দ্বিতীয়ত, প্রতিটি সাব-ledgerের দরকার একটা tie-out check, অর্থাৎ সাব-ledgerের মোট আর তার control accountের এক লাইনের তুলনা, যা মাসে একবার নয়, দৈনিক বা সাপ্তাহিক চলে।

ব্যাংক reconciliation: rule, matching আর exception

হাতের কাজের সিংহভাগ যায় ব্যাংক reconciliationে, আর automation-এর ফল সবার আগে এখানেই মেলে। লক্ষ্য হলো, rule যে লাইন মেটাতে পারেনি মানুষ শুধু সেটুকুই ছোঁবে।

matchingয়ের স্তরে স্তরে funnel

reconciliationকে একটা funnel ভাবুন। প্রতিটি স্তর যা পারে মিটিয়ে দেয়, বাকিটা নিচে পাঠায়।

1. এক্স্যাক্ট rule। একই অঙ্ক, একই রেফারেন্স বা invoice নম্বর, কয়েক দিনের মধ্যে। বড় অংশ এখানেই মিটে যায়।
2. গ্রুপড rule। একটা ব্যাংক ডিপোজিট যা অনেকগুলো order-এর যোগফল থেকে ফি বাদ দিলে হয়, যেমন gateway payout বা courier-এর remittance। ruleটি ডিপোজিটকে তার উপাদানে ভাগ করে।
3. প্রস্তাবিত ম্যাচ। প্রায় মেলে, পুরো নয়: সামান্য ফিতে অঙ্ক আলাদা, বা রেফারেন্সে বানান ভুল। system একটা ম্যাচ প্রস্তাব করে আর কারণসহ দেখায়।
4. ম্যানুয়াল exception। যা বাকি থাকে, সম্ভাব্য কারণ জুড়ে একজন মানুষের কাছে যায়।

একটি লাইনের যাত্রা: gateway payout

শুরুর দৃশ্যের সেই পেআউটটাই ধরা যাক। ব্যাংকে এসেছে ৯,৭১২.৪০-এর একটি জমা, সঙ্গে গেটওয়ের batch রেফারেন্স। এক্স্যাক্ট rule এখানে ব্যর্থ, কারণ কোনো একটি order-এর অঙ্ক এটা নয়। গ্রুপড rule তখন গেটওয়ের settlement report পড়ে সেই batch-এর ২৩টি order খুঁজে বের করে, দেখে মোট বিক্রি ১০,০০০.০০ আর ফি ২৮৭.৬০। মোট থেকে ফি বাদ দিলে ব্যাংকের জমার সমান হয়, তাই লাইনটি মিলে যায় আর একটিমাত্র journal পোস্ট হয়।

account	ডেবিট	ক্রেডিট
ব্যাংক	9,712.40
গেটওয়ে ফি (ব্যয়)	287.60
গেটওয়ে ক্লিয়ারিং		10,000.00

২৩টি order-এর টাকা আসার সময় clearing accountে ১০,০০০.০০ জমেছিল, তাই এখন সেটা শূন্যে ফেরে। ব্যাংক যদি ৯,৭০০.০০ পাঠাত, ১২.৪০-এর ফারাকে rule ভেঙে যেত আর লাইনটি "ফি অমিল" কারণ-কোড নিয়ে পরের স্তরে নামত। নকশার মূল কথা এটাই: যে পেআউটের হিসাব মেলে না, তাকে জোর করে পার করানো হয় না।

rule লিখুন নিজের প্যাটার্ন থেকে

ভালো rule আসে গত মাসে আপনি যে exceptionগুলো সামলেছেন সেখান থেকে। payment গেটওয়ে যদি ২.৯% আর একটা নির্দিষ্ট অঙ্ক ফি কাটে, সেটা গ্রুপড ruleেই লিখে দিন। courier যদি প্রতি মঙ্গলবার আগের সপ্তাহের ডেলিভারির টাকা পাঠায়, remittance batch ধরে মেলান। প্রতি মাসে ruleগুলোর হিট রেট দেখুন, আর যেগুলো ভুল ম্যাচ দেয় সেগুলো বাদ দিন।

exceptionকে data হিসেবে দেখুন

প্রতিটি exceptionের সঙ্গে একটা কারণ-কোড থাকুক: অমিল ডিপোজিট, ডুপ্লিকেট payment, invoice নেই, ব্যাংক চার্জ, সময়ের ফারাক। এক কোয়ার্টার পর গোনা দেখলেই বোঝা যায় আগের ধাপের কোন প্রক্রিয়াটা ঠিক করতে হবে। একই exception বারবার মেটানোর চেয়ে এটা অনেক বেশি কাজের।

AI কোথায় কাজে আসে, আর কোথায় সিদ্ধান্ত নেবে মানুষ

rule যেখানে শেষ, funnelের সেই প্রান্তে মেশিন লার্নিং আর ভাষা মডেল কাজে লাগে। দুটি কাজে তারা বিশেষভাবে ভালো:

• ম্যাচের পরামর্শ। আগের আচরণ দেখে বলা যে ব্যাংকের একটা অস্পষ্ট বিবরণ অমুক customer বা সরবরাহকারীর।
• অসঙ্গতির সংকেত। ডুপ্লিকেট payment, কোনো সরবরাহকারীর জন্য অস্বাভাবিক অঙ্ক, বা অদ্ভুত সময়ে পোস্ট হওয়া journal তুলে ধরা।

নিয়ন্ত্রণের নীতি সহজ: AI প্রস্তাব দেবে, মানুষ অনুমোদন করবে, system লিখে রাখবে কে করল। প্রতিটি প্রস্তাবে কনফিডেন্স স্কোর আর প্রমাণ দেখা যাবে, এবং নির্দিষ্ট অঙ্কের ওপরে বা স্পর্শকাতর account-এ মানুষের ক্লিক ছাড়া কিছুই পোস্ট হবে না। কোন প্রস্তাব গৃহীত হলো আর কোনটা বাতিল, তার লগ রাখুন; এটা যেমন audit ট্রেইল, তেমনি মডেলটা আদৌ কাজে লাগছে কি না বোঝার সেরা উপায়।

automation-এর সঙ্গে চাই দায়িত্বের বিভাজন (segregation of duties)। যিনি reconciliation তৈরি করেন, তিনিই একমাত্র অনুমোদনকারী হবেন না; যিনি matching rule বদলাতে পারেন, তিনি ফলাফলে সইও করবেন না। তিনজনের টিমেও ছোট exception report-এ আরেক জোড়া চোখ রাখা সস্তা বিমা।

অ্যাক্রুয়াল, প্রিpayment আর cut-off

অ্যাক্রুয়াল অ্যাকাউন্টিংয়ে, যা IFRS-এ বাধ্যতামূলক, আয় ও ব্যয় সেই পিরিয়ডের, যে পিরিয়ডের সঙ্গে সেগুলো সম্পর্কিত; টাকা যখন হাত বদলায়, তখনকার নয়। তাই বাকি সবকিছু যত automateেডই হোক, closeে কয়েকটা বিচারনির্ভর এন্ট্রি লাগেই।

• অ্যাক্রুয়াল হলো খরচ হয়ে গেছে কিন্তু বিল আসেনি: যেমন আগামী মাসে আসবে এমন ইউটিলিটি বিল, বা ২৮ তারিখে ঠিকাদারের শেষ করা কাজ।
• প্রিpayment আগাম দেওয়া খরচ, যেমন বার্ষিক software বা বিমা, যে মাসগুলো থেকে সুবিধা মিলবে তাতে ভাগ করে দেয়।
• cut-off ঠিক করে একটা লেনদেন কোন পিরিয়ডের: শেষ দিনে পাঠানো পণ্য, টাকা পাওয়া কিন্তু এখনো ডেলিভারি না হওয়া order, ৩০ তারিখের তারিখ দেওয়া কিন্তু ৩ তারিখে হাতে আসা সরবরাহকারীর বিল।

এর বেশির ভাগই template করা যায়। নিয়মিত প্রিpayment হয়ে যায় একটা শিডিউল, যা প্রতি মাসে এক লাইন পোস্ট করে। নিয়মিত অ্যাক্রুয়াল হয়ে যায় রিভার্সিং journal, যা system নিজেই বানায় আর পরের মাসের প্রথম দিনে উল্টে দেয়। মানুষের হাতে থাকে শুধু ব্যতিক্রম: বিতর্কিত বিল, এককালীন প্রজেক্ট, কারণ লিখে রাখার মতো একটা অনুমান।

দায়িত্বশীল ব্যক্তি আর দিনসহ close calendar

প্রতিটি কাজের একজন মালিক আর একটা নির্দিষ্ট দিন থাকলে close দ্রুত শেষ হয়; একবার লিখে রাখুন, প্রতি মাসে কাজে লাগান। নিচের calendarটি automateেড সাব-ledgerসহ একটি ছোট টিমের জন্য কাল্পনিক লক্ষ্য।

কখন	কাজ	দায়িত্বে
মাসজুড়ে প্রতিদিন	exception তালিকা দেখা; গেটওয়ে ও courier clearing account মেটানো	অ্যাকাউন্টস ক্লার্ক
প্রতি সপ্তাহে	শেষ কর্মদিবস পর্যন্ত ব্যাংক reconciliation; সাব-ledger টাই-আউট	অ্যাকাউন্টস ক্লার্ক, রিভিউ করবেন accountant
কার্যদিবস ১	cut-off চেক; শিপমেন্ট, প্রাপ্তি আর বেতন সঠিক পিরিয়ডে আছে কি না নিশ্চিত করা	অপারেশনস লিড ও accountant
কার্যদিবস ২	অ্যাক্রুয়াল, প্রিpayment শিডিউল, অবচয়, stock গণনার অ্যাডজাস্টমেন্ট	accountant
কার্যদিবস ৩	চূড়ান্ত reconciliation, ম্যানুয়াল journal রিভিউ, বাজেটের সঙ্গে ভ্যারিয়েন্স রিভিউ	finance ম্যানেজার
কার্যদিবস ৪	পিরিয়ড লক, report প্রকাশ, ম্যানেজমেন্টকে ব্রিফ	finance ম্যানেজার

শুরুর জন্য ছোট একটা ধাপ-তালিকা:

1. গত মাসে হাতে যত journal পোস্ট করেছেন, সবকটির তালিকা করুন আর প্রতিটির উৎস লিখুন।
2. প্রতিটি উৎসের জন্য ভাবুন, কোনো সাব-ledger কি এটা নিজে থেকে পোস্ট করতে পারত।
3. ব্যাংক reconciliation মাসিক থেকে সাপ্তাহিকে আনুন, তারপর সবচেয়ে ঘন ঘন ঘটা পাঁচটি প্যাটার্নের rule লিখুন।
4. নিয়মিত অ্যাক্রুয়াল ও প্রিpayment template করে ফেলুন।
5. প্রতিটি কাজের জন্য মালিক ও শেষ দিন বসিয়ে close calendar লিখুন।
6. নতুন প্রক্রিয়া একবার পুরোনোটার পাশাপাশি চালান, ফল মেলান, তারপর পুরোনোটা বন্ধ করুন।

দ্রুত close কী সম্ভব করে

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

close ভালো হচ্ছে কি না, বোঝার metric

প্রতি মাসে অল্প কয়েকটি সংখ্যা ট্র্যাক করুন, আর টিমের সামনে প্রকাশ করুন।

• close করতে কত দিন। পিরিয়ড শেষ থেকে হিসাব লক হওয়া পর্যন্ত কার্যদিবস। প্রতি মাসে একই নিয়মে মাপুন।
• ম্যানুয়াল journal। হাতে টাইপ করা journalের সংখ্যা ও অঙ্ক। সাব-ledger দায়িত্ব নিলে এটা ধীরে ধীরে কমবে।
• অটো-ম্যাচ রেট। কত শতাংশ ব্যাংক লাইন কোনো মানুষ না ছুঁয়েই মিটেছে।
• reconciliation exception। পিরিয়ড শেষে কয়টি খোলা, আর তাদের গড় বয়স।
• closeের পরের অ্যাডজাস্টমেন্ট। হিসাব লক হওয়ার পর যে এন্ট্রি লাগল। লক্ষ্য শূন্য।

একটি কাল্পনিক উদাহরণ: প্রথম মাসে যে টিম ১২০টি ম্যানুয়াল journal পোস্ট করে আর ৫৫% ব্যাংক লাইন নিজে থেকে মেটায়, ছয় মাস পরে তার লক্ষ্য হতে পারে ৪০টি journal আর ৮৫%। সংখ্যার চেয়ে দিকটাই বড় কথা।

যে ভুলগুলো এড়িয়ে চলুন

• ভাঙা প্রক্রিয়া automate করা। আগে exceptionের কারণ সারান; তাকে পাশ কাটিয়ে automation চালালে সমস্যা শুধু লুকিয়ে যায়।
• সীমা ছাড়া অটো-পোস্টিং। অঙ্কের সীমা ঠিক করুন, তার ওপরে অনুমোদন বাধ্যতামূলক করুন।
• ruleকে পুরোনো হতে দেওয়া। এক বছর আগে যে rule ঠিক ছিল, আজ সেটা হয়তো ভুল সরবরাহকারীর সঙ্গে মেলাচ্ছে।
• লক বাদ দেওয়া। বন্ধ পিরিয়ড যদি যখন-তখন বদলানো যায়, close আসলে শেষ হয়নি।

আবার সন্ধ্যা ৬টা ৪০-এর সেই টিমের কাছে ফিরি। গেটওয়ের জন্য একটি গ্রুপড rule থাকলে ৯,৭১২.৪০-এর পেআউট রাতারাতি তার ২৩টি order-এর সঙ্গে মিলে যায় আর ২৮৭.৬০-এর একটি ফি journal পোস্ট হয়। feed খোলার আগেই rule ১,০০০টির মধ্যে প্রায় ৮৮০টি লাইন মিটিয়ে ফেলে। accountantের সন্ধ্যা কাটে মোটামুটি ১২০টি লাইনে, যেখানে মানুষ লাগে: ৭০টি প্রস্তাব নিশ্চিত করা, আর ৫০টি exception, প্রতিটির একজন করে মালিক। চতুর্থ দিনের মিটিংয়ে আলোচনা হয় গত সপ্তাহের সংখ্যা নিয়ে, গত কোয়ার্টারের নয়।

মূল কথাগুলো

• ধীর closeের কারণ সাধারণত দেরিতে আসা তথ্য, হাতে লেখা journal আর হাতে মেলানো; ধীর মানুষ এর কারণ নয়।
• কাজ মাসের ভেতরে নিয়ে আসুন: ঘটনার সময়ই পোস্ট, সাপ্তাহিক reconciliation, শুধু exception রিভিউ।
• সাব-ledgerকে নিজে থেকে পোস্ট করতে দিন, আর প্রতি সপ্তাহে প্রতিটিকে তার control accountের সঙ্গে মিলিয়ে দেখুন।
• ব্যাংক reconciliation সাজান funnelের মতো: এক্স্যাক্ট rule, গ্রুপড rule, প্রস্তাব, তারপর exception।
• পরামর্শ আর অসঙ্গতির সংকেতে AI ব্যবহার করুন, কিন্তু অনুমোদন থাকুক মানুষের হাতে, আর প্রতিটি সিদ্ধান্তের লগ থাকুক।
• closeে কত দিন, ম্যানুয়াল journal, অটো-ম্যাচ রেট আর exception মাপুন, আর প্রতি মাসে টিমকে দেখান।

আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP system ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো systemের ওপর।