দুবাইয়ের অফ-প্ল্যান ব্যবস্থায় ক্রেতার দেওয়া টাকা ডেভেলপারের চলতি হিসাবে পৌঁছায় না। সেটি যায় প্রজেক্ট escrow অ্যাকাউন্টে — ওই নির্দিষ্ট প্রজেক্টের সঙ্গে বাঁধা একটি ট্রাস্ট অ্যাকাউন্টে — আর নির্মাণ সার্টিফাইড হওয়ার সঙ্গে সঙ্গে ডেভেলপার সেখান থেকে তোলেন। এই কাঠামো এসেছে কারণ এক সময় ক্রেতাদের এমন ভবনের টাকা দিতে বলা হতো, যেখানে টাকাটা সেই ভবনেই খরচ হবে তার কোনো নিশ্চয়তা ছিল না। ডেভেলপারের জন্য এর মানে — নগদের প্রাপ্যতা নির্ভর করে সার্টিফাইড অগ্রগতির উপর, বিক্রির উপর নয়।
শুরু থেকে শেষ পর্যন্ত শৃঙ্খল
১. প্রজেক্ট নিবন্ধন। প্রজেক্ট নিবন্ধিত হয়, আর স্বীকৃত escrow এজেন্টের কাছে অ্যাকাউন্ট খোলা হয়। ২. ক্রেতার টাকা জমা। প্রতিটি কিস্তি ইউনিটের রেফারেন্সসহ ওই অ্যাকাউন্টে যায়। অন্য কোথাও দেওয়া টাকা কমপ্লায়েন্স আর নিবন্ধন — দুটোরই সমস্যা তৈরি করে; দেখুন Oqood রেজিস্ট্রেশন। ৩. নির্মাণ এগোয়। কাজ হয় আর সাইটে পরিমাপ হয়। ৪. সার্টিফিকেশন। নিযুক্ত প্রকৌশলী বা পরামর্শক সম্পন্ন শতাংশ সার্টিফাই করেন। ৫. রিলিজের আবেদন। ডেভেলপার সার্টিফিকেট আর সহায়ক কাগজসহ আবেদন করেন। ৬. রিলিজ। রাখা-বাধ্যতামূলক অংশ বাদ দিয়ে টাকা ডেভেলপারের কাছে যায়। ৭. সমাপ্তির পর রিটেনশন। চূড়ান্ত ছাড়ের আগে নির্দিষ্ট সময়ের জন্য একটি অংশ থেকে যায়।
নগদ পরিকল্পনায় এর প্রভাব
দুটি ফল, আর escrow নেই এমন বাজার থেকে আসা ডেভেলপাররা দুটিতেই চমকে যান:
শুরুর দিকে ভারী পেমেন্ট প্ল্যান আপনার নগদ শুরুতে দেয় না। 80/20 প্ল্যানে escrow-তে টাকা আগে ঢোকে, কিন্তু আগে ছাড়া হয় না — ছাড় চলে নির্মাণের সঙ্গে। রিলিজের সময়সূচি না দেখে তারল্যের জন্য বানানো প্ল্যান অ্যাকাউন্টের ব্যালান্স বাড়ায়, ব্যাংক ব্যালান্স নয়। এটি মাথায় রেখে বাছাইয়ের উপায় আছে অফ-প্ল্যান পেমেন্ট প্ল্যান লেখায়।
নির্মাণে দেরি দুবার নগদ ঘটনা। প্রজেক্টে সময় বেশি লাগে, আর পরের ধাপের অর্থায়ন করত যে রিলিজ সেটিও আসে না। দুটো একসঙ্গে হিসাব করলেই আসল ঝুঁকিটা দেখা যায়।
একটি রিলিজের পেছনের কাগজ
| কাগজ | কে তৈরি করে | সাধারণ সমস্যা |
|---|---|---|
| প্রকৌশলী বা পরামর্শকের সার্টিফিকেট | নিযুক্ত পরামর্শক | শতাংশ ডেভেলপারের দাবির সঙ্গে মেলে না |
| পরিমাপ ও সহায়ক রেকর্ড | ঠিকাদার ও সাইট টিম | কাজের সময় নয়, আবেদনের পরে জোগাড় করা |
| ওই সময়ের ঠিকাদার চালান | ঠিকাদার | সার্টিফাইড কাজের সঙ্গে মেলানো নেই |
| Escrow-তে জমার রেকর্ড | Escrow এজেন্ট | ক্রেতার জমায় রেফারেন্স নেই, তাই কার টাকা বোঝা যায় না |
| ইউনিট নিবন্ধনের অবস্থা | ডেভেলপার, DLD-র মাধ্যমে | বিক্রি হওয়া ইউনিট নিবন্ধিত নয়, তাই বিক্রয় অবস্থান প্রমাণ করা যায় না |
শেষ সারিতেই ডেভেলপাররা সবচেয়ে বেশি সময় হারান। রিলিজের আবেদন পরোক্ষভাবে একটি বিক্রয় ও আদায় অবস্থানের দাবি করে — আর নিবন্ধিত ইউনিট আর বিক্রিত ইউনিট না মিললে সেই দাবি দাঁড়ায় না।
রেকর্ড থাকুক যেখানে কাজ হয়
যে ডেভেলপার এক দিনে রিলিজের আবেদন জমা দেন আর যিনি তিন সপ্তাহ নেন — পার্থক্যটা দক্ষতায় নয়। পার্থক্যটা হলো সার্টিফিকেট, পরিমাপ, ঠিকাদারের বিল আর ক্রেতার পেমেন্ট ঘটনার সঙ্গে সঙ্গে প্রজেক্টের সঙ্গে যুক্ত হয়েছে, নাকি পরে চারটি বিভাগ থেকে জোগাড় করতে হচ্ছে। ঠিকাদারের পেমেন্ট রক্ষণযোগ্য রাখার শৃঙ্খলাও একই — দেখুন ঠিকাদারের বিল সার্টিফাই করা।
Escrow আর নিজের খাতা মেলানো
মাসে একবার তিনটি সংখ্যা মেলা উচিত: প্রজেক্টে আপনার সিস্টেমে লেখা মোট ক্রেতা-পেমেন্ট, escrow অ্যাকাউন্টে জমা হওয়া মোট, আর অবণ্টিত মোট। পার্থক্যের ব্যাখ্যা সবসময়ই থাকে — ভুল অ্যাকাউন্টে দেওয়া টাকা, পথে থাকা ট্রান্সফার, রেফারেন্স ছাড়া জমা দেওয়া ক্রেতা। সবগুলোই যে মাসে ঘটে সেই মাসে ঠিক করা যায়, আর এক বছর পরে যন্ত্রণাদায়ক।
এরপর কী
সবচেয়ে বড় চলমান প্রজেক্টে গত মাসের ক্রেতা-পেমেন্ট escrow স্টেটমেন্টের সঙ্গে মেলান, আর দেখুন বিক্রি হওয়া প্রতিটি ইউনিট নিবন্ধিত হয়েছে কি না। যা মিলবে না, সেটিই এমন একটি রিলিজ আবেদন যা দরকারের চেয়ে বেশি সময় নেবে — ইউনিট, পেমেন্ট আর escrow রেকর্ড কীভাবে মেলে দেখুন।
