কো-ওনারদের মধ্যে নির্মাণ খরচ ন্যায্যভাবে ভাগ করার সঠিক উপায় কী?

যখন একাধিক ব্যক্তি যৌথভাবে একটি সম্পত্তির মালিক হন, তখন তাদের মুখোমুখি হওয়া প্রথম আর্থিক প্রশ্নগুলোর মধ্যে একটি হলো:

"নির্মাণে প্রতিটি কো-ওনারের কতটুকু কন্ট্রিবিউট করা উচিত?"

এর সহজ উত্তর হতে পারে মোট খরচ সমানভাবে ভাগ করা।

যদি একটি প্রকল্পের জন্য $100,000 প্রয়োজন হয় এবং সেখানে 10 জন কো-ওনার থাকে, তাহলে কেন সবাইকে $10,000 করে চাওয়া হবে না?

কারণ কো-ওনারশিপ খুব কমই এত সহজ হয়।

একজন ব্যক্তি হয়তো সম্পত্তির 25% এর মালিক, অন্যজন 10% এর। কিছু প্রকল্পের ইউনিট বা ফ্লোর ভিন্ন আকারের হতে পারে। কিছু সদস্য হয়তো তাদের বর্তমান বাধ্যবাধকতার চেয়ে বেশি কন্ট্রিবিউট করেছেন, আবার অন্যদের বকেয়া থাকতে পারে।

একটি ন্যায্য কন্ট্রিবিউশন সিস্টেমকে এই পার্থক্যগুলো বিবেচনায় নিতে হবে।

সমান কন্ট্রিবিউশন মানে সবসময় ন্যায্য কন্ট্রিবিউশন নয়

চারজন কো-ওনারের একটি প্রকল্পের কথা ভাবুন:

কো-ওনার	মালিকানার অংশ
Owner A	40%
Owner B	30%
Owner C	20%
Owner D	10%
মোট	100%

ধরুন, প্রকল্পের জন্য $100,000 সংগ্রহ করতে হবে।

যদি খরচ সমানভাবে ভাগ করা হয়, তাহলে প্রত্যেকে $25,000 করে কন্ট্রিবিউট করবে।

এটা সহজ মনে হয়।

কিন্তু এটি মালিকানার কাঠামোকে প্রতিফলিত করে না।

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

কো-ওনার	মালিকানা	কন্ট্রিবিউশন
Owner A	40%	$40,000
Owner B	30%	$30,000
Owner C	20%	$20,000
Owner D	10%	$10,000
মোট	100%	$100,000

এই উদাহরণে, আনুপাতিক কন্ট্রিবিউশন অন্তর্নিহিত মালিকানার সাথে আরও বেশি সঙ্গতিপূর্ণ।

গুরুত্বপূর্ণ বিষয় হলো, ন্যায্যতা প্রতিটিবার অর্থের প্রয়োজন হলে অনানুষ্ঠানিক চুক্তির পরিবর্তে একটি স্পষ্টভাবে সংজ্ঞায়িত নিয়মের উপর ভিত্তি করে হওয়া উচিত।

একটি পরিষ্কার মালিকানা কাঠামো দিয়ে শুরু করুন

কন্ট্রিবিউশন হিসাব করার আগে, প্রকল্পকে কে কীসের মালিক তা নির্ধারণ করতে হবে।

CoBuild Manager মালিকানাকে প্রকল্পের একটি আনুষ্ঠানিক অংশ হিসাবে বিবেচনা করে।

একটি সম্পত্তি এক বা একাধিক সদস্যের সাথে যুক্ত হতে পারে, যেখানে প্রতিটি মালিকানার রেকর্ডে একটি মালিকানার শতাংশ থাকে।

সেই মালিকানার তথ্য আর্থিক হিসাবের ভিত্তি হয়ে ওঠে।

উদাহরণস্বরূপ:

Property → Ownership → Member → Ownership %

একবার এই সম্পর্কটি স্পষ্টভাবে রেকর্ড করা হলে, প্রকল্পের আর্থিক বাধ্যবাধকতা হিসাব করার জন্য একটি ধারাবাহিক ভিত্তি থাকে।

একটি আনুষ্ঠানিক মালিকানা কাঠামো ছাড়া, প্রতিটি তহবিল অনুরোধ একটি আলাদা ম্যানুয়াল অনুশীলনে পরিণত হতে পারে।

একটি Ownership Multiplier কী?

মালিকানার শতাংশ সবসময় পুরো গল্প বলে না।

কিছু কো-বিল্ড প্রকল্পে ইউনিট বা অন্যান্য প্রকল্প-নির্দিষ্ট কারণগুলির মধ্যে পার্থক্য বিবেচনা করার জন্য একটি অতিরিক্ত ownership multiplier ব্যবহার করা হয়।

উদাহরণস্বরূপ, দুইজন সদস্যের একই মৌলিক মালিকানার শতাংশ থাকতে পারে কিন্তু তাদের ইউনিটগুলির ভিন্ন বৈশিষ্ট্যের কারণে ভিন্ন কন্ট্রিবিউশন প্রয়োজন হতে পারে।

মাল্টিপ্লায়ারটি কন্ট্রিবিউশন হিসাবে প্রয়োগ করা যেতে পারে এমন একটি অতিরিক্ত ফ্যাক্টর সরবরাহ করে।

সুনির্দিষ্ট নিয়মগুলি প্রতিটি প্রকল্পের দ্বারা সংজ্ঞায়িত করা উচিত।

গুরুত্বপূর্ণ নীতিটি হলো:

হিসাবটি এমন একটি স্বচ্ছ নিয়মের উপর ভিত্তি করে হওয়া উচিত যা প্রকল্পের সবাই বোঝে।

একটি সিস্টেমে শুধুমাত্র চূড়ান্ত সংখ্যা না দেখিয়ে ইনপুটগুলি রেকর্ড করা উচিত।

এভাবে, একজন সদস্য কেবল কত টাকা তাদের বকেয়া আছে তা নয়, কেন তাদের বকেয়া আছে তাও বুঝতে পারবেন।

একটি সহজ কন্ট্রিবিউশন হিসাব

একটি মৌলিক আনুপাতিক কন্ট্রিবিউশন এভাবে প্রকাশ করা যেতে পারে:

সদস্যের কন্ট্রিবিউশন = মোট তহবিলের প্রয়োজন × মালিকানার শতাংশ

ধরুন প্রকল্পের জন্য $250,000 প্রয়োজন।

20% মালিকানার অংশীদার একজন সদস্যের মূল কন্ট্রিবিউশন হবে:

$250,000 × 20% = $50,000

যদি প্রকল্প একটি মাল্টিপ্লায়ারও ব্যবহার করে, তাহলে প্রকল্পের সংজ্ঞায়িত হিসাব পদ্ধতি সেই মাল্টিপ্লায়ারকেও অন্তর্ভুক্ত করতে পারে।

গুরুত্বপূর্ণ অংশ হলো ধারাবাহিকতা।

একই নিয়ম প্রতিটি সদস্যের ক্ষেত্রে তাদের রেকর্ড করা মালিকানা এবং প্রকল্পের কনফিগারেশন অনুযায়ী প্রয়োগ করা উচিত।

কিন্তু পূর্ববর্তী পেমেন্টগুলো চিত্র পরিবর্তন করে

হিসাবকৃত কন্ট্রিবিউশন আজকের দিনে একজন সদস্যের পরিশোধ করার পরিমাণ নাও হতে পারে।

কল্পনা করুন:

বর্তমান কন্ট্রিবিউশন বাধ্যবাধকতা: $50,000 ইতিমধ্যে পরিশোধিত: $30,000

বাকি পরিমাণ হলো:

$50,000 − $30,000 = $20,000

এটি সহজ মনে হয়।

কিন্তু অন্য একজন সদস্যের কথা ভাবুন যিনি তাদের বর্তমান বাধ্যবাধকতার চেয়ে বেশি পরিশোধ করেছেন।

উদাহরণস্বরূপ:

বর্তমান বাধ্যবাধকতা: $50,000 ইতিমধ্যে পরিশোধিত: $60,000

সেই সদস্যকে কেবল "$60,000 পরিশোধ করা হয়েছে" হিসাবে বিবেচনা করা উচিত নয়।

অতিরিক্ত $10,000 একটি ক্রেডিট নির্দেশ করে।

ক্রেডিট ব্যালেন্স কেন গুরুত্বপূর্ণ?

নির্মাণ প্রকল্পে অগ্রিম পেমেন্ট সাধারণ ব্যাপার।

একজন কো-ওনার অতিরিক্ত পরিশোধ করতে পারেন কারণ তাদের কাছে তহবিল উপলব্ধ আছে, তারা আগেভাগে কন্ট্রিবিউট করতে চান, অথবা ভবিষ্যতের বাধ্যবাধকতা থেকে এগিয়ে থাকতে চান।

ধরুন একজন সদস্যের আছে:

বাধ্যবাধকতা: $50,000 পেমেন্ট: $60,000 ক্রেডিট ব্যালেন্স: $10,000

পরবর্তী তহবিল অনুরোধ তৈরি করার সময়, সেই ক্রেডিটটি বিবেচনায় নেওয়া উচিত।

অন্যথায়, সদস্যকে একই অর্থের জন্য কার্যকরভাবে দুবার চার্জ করা হতে পারে।

সুতরাং, একটি ভালো আর্থিক ব্যবস্থার উচিত পার্থক্য করা:

• মোট বাধ্যবাধকতা
• পরিশোধিত পরিমাণ
• বকেয়া পরিমাণ
• ক্রেডিট ব্যালেন্স

এটি প্রতিটি কো-ওনারের আর্থিক অবস্থানের একটি অনেক বেশি সঠিক চিত্র তৈরি করে।

একজন কো-ওনারের আর্থিক অবস্থান একটি সংখ্যার চেয়ে বেশি

একজন সদস্যের অবস্থা কেবল এইরকম হওয়া উচিত নয়:

"Paid" অথবা "Unpaid."

একটি কার্যকর আর্থিক দৃশ্যে বেশ কয়েকটি প্রশ্নের উত্তর দেওয়া উচিত।

তাদের কত কন্ট্রিবিউট করার কথা ছিল?

এটি ডিপোজিট শিডিউল এবং প্রকল্পের মালিকানা হিসাব থেকে আসে।

তারা আসলে কত পরিশোধ করেছেন?

এটি রেকর্ড করা ডিপোজিট এবং পেমেন্ট থেকে আসে।

কত বকেয়া আছে?

এটি তাদের বর্তমান বাধ্যবাধকতার অপরিশোধিত অংশ।

তাদের কি কোনো ক্রেডিট আছে?

যদি তারা অতিরিক্ত পরিশোধ করে থাকেন, তাহলে অতিরিক্ত অর্থটি এগিয়ে নিয়ে যাওয়া উচিত।

একসাথে, এগুলো একটি আরও সম্পূর্ণ চিত্র তৈরি করে:

বাধ্যবাধকতা → পরিশোধিত → বকেয়া / ক্রেডিট

ম্যানুয়াল হিসাব কেন ঝুঁকিপূর্ণ হয়ে ওঠে?

30 জন কো-ওনারের একটি প্রকল্পের কথা ভাবুন।

প্রকল্পের অতিরিক্ত তহবিলের প্রয়োজন।

কেউ একজন একটি স্প্রেডশীট খুলে হিসাব করা শুরু করে:

• মালিকানার শতাংশ
• মাল্টিপ্লায়ার
• পূর্ববর্তী পেমেন্ট
• বকেয়া ব্যালেন্স
• ক্রেডিট ব্যালেন্স

তারপর তারা গ্রুপে পরিমাণগুলি পাঠায়।

একজন সদস্য উত্তর দেন:

"আমি গত মাসে অতিরিক্ত পরিশোধ করেছি।"

অন্যজন বলেন:

"আমার মালিকানার শতাংশ ভিন্ন।"

অন্য কেউ বলেন:

"আমার মনে হয় আমার পূর্ববর্তী পেমেন্ট অন্তর্ভুক্ত করা হয়নি।"

এখন অর্থ ব্যবস্থাপককে প্রতিটি কেস ম্যানুয়ালি তদন্ত করতে হবে।

এটি খারাপ ব্যবস্থাপনার কারণে নাও হতে পারে।

এটি একটি স্প্রেডশীটের মধ্যে একটি গতিশীল আর্থিক ব্যবস্থা বজায় রাখার একটি স্বাভাবিক পরিণতি।

সদস্য এবং লেনদেনের সংখ্যা যত বেশি হয়, ম্যানুয়াল রিকনসিলিয়েশন তত কঠিন হয়ে ওঠে।

ডিপোজিট শিডিউল কন্ট্রিবিউশনকে কাঠামোবদ্ধ করে তোলে

অনানুষ্ঠানিক বার্তার মাধ্যমে বারবার সদস্যদের কাছে অর্থ চাওয়ার পরিবর্তে, একটি প্রকল্প একটি কাঠামোবদ্ধ deposit schedule তৈরি করতে পারে।

উদাহরণস্বরূপ:

নির্মাণ পর্যায়: কাঠামোগত কাজ

তহবিলের প্রয়োজন: $200,000 সংগ্রহের সময়কাল: জুন 1 – জুন 30

সিস্টেমটি প্রকল্পের মালিকানা নিয়ম অনুযায়ী প্রতিটি সদস্যের জন্য বরাদ্দ হিসাব করতে পারে।

প্রতিটি সদস্যের তখন একটি নির্দিষ্ট বরাদ্দ থাকতে পারে:

সদস্য	বরাদ্দ	পরিশোধিত	বকেয়া
Owner A	$80,000	$80,000	$0
Owner B	$60,000	$40,000	$20,000
Owner C	$40,000	$40,000	$0
Owner D	$20,000	$10,000	$10,000

এখন প্রকল্প অবিলম্বে দেখতে পাবে:

• মোট অনুরোধকৃত পরিমাণ
• মোট সংগৃহীত
• মোট বকেয়া
• প্রতিটি সদস্যের পেমেন্ট স্ট্যাটাস

এটি হোয়াটসঅ্যাপ বার্তার একটি সিরিজের চেয়ে অনেক বেশি কার্যকর।

কন্ট্রিবিউশন নির্মাণের সাথে সংযুক্ত হওয়া উচিত

একটি তহবিল অনুরোধের আদর্শভাবে একটি কারণ থাকা উচিত।

নির্মাণ প্রকল্পগুলির অর্থের প্রয়োজন হয় কারণ কিছু কাজ করতে হবে।

উদাহরণস্বরূপ:

Foundation → Funding Requirement

Structural Work → Funding Requirement

Finishing → Funding Requirement

Electrical Work → Funding Requirement

এটি আর্থিক ব্যবস্থাপনা এবং নির্মাণ অগ্রগতির মধ্যে একটি অর্থপূর্ণ সংযোগ তৈরি করে।

যখন একজন কো-ওনারকে $20,000 কন্ট্রিবিউট করতে বলা হয়, তখন তাদের বুঝতে সক্ষম হওয়া উচিত যে সেই তহবিল কী সমর্থন করছে।

প্রকল্পটি তখন ডিপোজিট শিডিউলকে প্রাসঙ্গিক নির্মাণ মাইলস্টোনের সাথে সংযুক্ত করতে পারে।

একটি কন্ট্রিবিউশন সিস্টেমকে কী ন্যায্য করে তোলে?

একটি ন্যায্য সিস্টেমের বেশ কয়েকটি বৈশিষ্ট্য থাকা উচিত।

1. নিয়মটি আগে থেকে সংজ্ঞায়িত

সদস্যদের জানা উচিত তাদের কন্ট্রিবিউশন কিভাবে হিসাব করা হয়।

2. মালিকানা স্পষ্টভাবে রেকর্ড করা হয়েছে

প্রত্যেকের মালিকানার শতাংশ অনুমোদিত সদস্যদের কাছে দৃশ্যমান হওয়া উচিত।

3. হিসাবটি ধারাবাহিক

সমতুল্য মালিকানার শর্তযুক্ত সদস্যদের ক্ষেত্রে একই নিয়ম প্রয়োগ করা উচিত।

4. পূর্ববর্তী পেমেন্টগুলো অন্তর্ভুক্ত

একজন সদস্যকে তাদের ইতিমধ্যে পরিশোধ করা অর্থ বিবেচনা না করে আবার কন্ট্রিবিউট করতে বলা উচিত নয়।

5. ক্রেডিট সংরক্ষিত

অতিরিক্ত পেমেন্ট তহবিল চক্রের মধ্যে হারিয়ে যাওয়া উচিত নয়।

6. সদস্যরা তাদের নিজস্ব অবস্থান দেখতে পারেন

প্রতিটি কো-ওনার তাদের বাধ্যবাধকতা, পেমেন্ট এবং বকেয়া ব্যালেন্স বুঝতে সক্ষম হওয়া উচিত।

7. ইতিহাস ট্রেসযোগ্য

গুরুত্বপূর্ণ আর্থিক রেকর্ডের পরিবর্তনগুলির একটি স্থায়ী ইতিহাস থাকা উচিত।

এই নীতিগুলি একটি কন্ট্রিবিউশন প্রক্রিয়াকে একটি অনানুষ্ঠানিক হিসাব থেকে একটি স্বচ্ছ আর্থিক সিস্টেমে রূপান্তরিত করে।

মালিকানা পরিবর্তিত হলে কী হয়?

যৌথ মালিকানাধীন সম্পত্তিও হাত বদল হতে পারে।

একজন সদস্য তাদের মালিকানার অংশ অন্য সদস্যের কাছে বিক্রি বা হস্তান্তর করতে পারেন।

এটি আরেকটি আর্থিক চ্যালেঞ্জ তৈরি করে।

প্রকল্পের জানা দরকার:

• কে পূর্বে সম্পত্তির মালিক ছিলেন?
• এখন কে এর মালিক?
• কত শতাংশ পরিবর্তিত হয়েছে?
• কখন হস্তান্তর হয়েছিল?
• ভবিষ্যতের বাধ্যবাধকতা কিভাবে পরিচালনা করা উচিত?

সুতরাং, মালিকানা স্থানান্তরের ইতিহাস গুরুত্বপূর্ণ হয়ে ওঠে।

সিস্টেমের উচিত পুরানো মালিককে কেবল ওভাররাইট না করে ঐতিহাসিক সম্পর্কটি সংরক্ষণ করা।

এটি দীর্ঘমেয়াদী নির্মাণ প্রকল্পগুলির জন্য বিশেষভাবে গুরুত্বপূর্ণ যেখানে সমাপ্তির আগে মালিকানা বেশ কয়েকবার পরিবর্তিত হতে পারে।

স্বচ্ছতা সূত্রের চেয়ে বেশি গুরুত্বপূর্ণ

প্রতিটি কো-বিল্ড প্রকল্পের ক্ষেত্রে প্রযোজ্য কোনো একক কন্ট্রিবিউশন সূত্র নেই।

বিভিন্ন গ্রুপের বিভিন্ন মালিকানা কাঠামো, মাল্টিপ্লায়ার, চুক্তিভিত্তিক ব্যবস্থা বা শাসন বিধি থাকতে পারে।

গুরুত্বপূর্ণ নীতিটি কোনো নির্দিষ্ট গাণিতিক সূত্র নয়।

এটি হলো স্বচ্ছতা।

প্রতিটি কো-ওনার বুঝতে সক্ষম হওয়া উচিত:

"এটি আমার মালিকানার অংশ।"

"এটি প্রকল্পের তহবিলের প্রয়োজন।"

"এভাবে আমার কন্ট্রিবিউশন হিসাব করা হয়েছে।"

"আমি ইতিমধ্যে এত টাকা পরিশোধ করেছি।"

"আমার এখনও এত টাকা বকেয়া আছে।"

"আমার এত ক্রেডিট উপলব্ধ আছে।"

যখন এই উত্তরগুলি পরিষ্কার হয়, তখন আর্থিক আলোচনা অনেক সহজ হয়ে যায়।

CoBuild Manager কিভাবে শেয়ার-ভিত্তিক কন্ট্রিবিউশন পরিচালনা করে

CoBuild Manager এই ধারণার উপর ভিত্তি করে ডিজাইন করা হয়েছে যে কো-ওনারের আর্থিক বাধ্যবাধকতাগুলি আনুষ্ঠানিক মালিকানার রেকর্ডের সাথে সংযুক্ত হওয়া উচিত।

প্ল্যাটফর্মটি বজায় রাখে:

• সদস্য
• সম্পত্তি
• সম্পত্তির মালিকানা
• মালিকানার শতাংশ
• মালিকানার মাল্টিপ্লায়ার
• ডিপোজিট শিডিউল
• প্রতি-সদস্যের বরাদ্দ
• পেমেন্ট
• বকেয়া ব্যালেন্স
• ক্রেডিট ব্যালেন্স
• মালিকানা স্থানান্তরের ইতিহাস

যখন একটি ডিপোজিট শিডিউল তৈরি করা হয়, তখন সিস্টেমটি প্রকল্পের মালিকানা কনফিগারেশন অনুযায়ী প্রতিটি সদস্যের বরাদ্দ হিসাব করতে পারে।

ফলস্বরূপ শিডিউলটি প্রতিটি সদস্যের কত বকেয়া, তারা কত পরিশোধ করেছেন এবং কত বকেয়া রয়েছে তার একটি কাঠামোবদ্ধ চিত্র সরবরাহ করে।

এটি পুনরাবৃত্ত তহবিল অনুরোধগুলি পরিচালনা করার সাথে জড়িত অনেক পুনরাবৃত্তিমূলক ম্যানুয়াল হিসাব দূর করে।

উপসংহার

নির্মাণ খরচ ন্যায্যভাবে ভাগ করা কেবল কো-ওনারের সংখ্যা দিয়ে একটি সংখ্যা ভাগ করার বিষয় নয়।

একটি যৌথ মালিকানাধীন সম্পত্তিতে বিভিন্ন মালিকানার শতাংশ, মাল্টিপ্লায়ার, পূর্ববর্তী পেমেন্ট, ক্রেডিট ব্যালেন্স এবং মালিকানা স্থানান্তর থাকতে পারে।

সুতরাং, একটি নির্ভরযোগ্য কন্ট্রিবিউশন সিস্টেমকে সংযুক্ত করতে হবে:

মালিকানা → তহবিলের প্রয়োজন → ব্যক্তিগত বরাদ্দ → পেমেন্ট → ব্যালেন্স

সুনির্দিষ্ট নিয়মগুলি এক প্রকল্প থেকে অন্য প্রকল্পে ভিন্ন হতে পারে।

তবে নীতিটি একই থাকা উচিত:

প্রতিটি কো-ওনারকে তাদের আর্থিক বাধ্যবাধকতা কিভাবে হিসাব করা হয়েছিল তা সুনির্দিষ্টভাবে বুঝতে সক্ষম হওয়া উচিত।

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