অধ্যায় ১ — Accounting কী

Volume 1 · Part 1 — Accounting Fundamentals · Chapter 1

পূর্বশর্ত: কিছু নেই। এখান থেকেই শুরু।

১. Learning Objective

এই অধ্যায় শেষে আপনি পারবেন:

Accounting আর Bookkeeping-এর পার্থক্য বলতে
Financial, Management ও Cost Accounting কার জন্য — আলাদা করতে
কোন ঘটনা খাতায় উঠবে আর কোনটা উঠবে না — সিদ্ধান্ত নিতে
Accounting Period ও Fiscal Year কেন লাগে তা ব্যাখ্যা করতে
পাঁচটি মৌলিক assumption চিনতে ও প্রয়োগ করতে
Entity ও Period কে database-এ কীভাবে রাখতে হয় তা design করতে

সময়: পড়া ৪০ মিনিট + অনুশীলন ৩০ মিনিট।

২. Concept Explanation

Accounting আসলে কী?

এক বাক্যে:

Accounting হলো একটি ব্যবসার আর্থিক ঘটনাগুলোকে নিয়মমাফিক লিপিবদ্ধ, শ্রেণিবদ্ধ ও সংক্ষিপ্ত করে এমন তথ্যে পরিণত করা, যা দেখে সিদ্ধান্ত নেওয়া যায়।

Developer হিসেবে চিনতে সুবিধা হবে এভাবে — accounting একটা তথ্য প্রক্রিয়াকরণ ব্যবস্থা (information system), যার input হলো ব্যবসার ঘটনা আর output হলো report:

   Business Events          Accounting System            Decisions
   ───────────────          ─────────────────            ─────────
   পণ্য বিক্রি হলো                                        লাভ হচ্ছে?
   বেতন দেওয়া হলো    ──▶    record → classify   ──▶      টাকা আছে?
   মেশিন কেনা হলো           → summarize → report        ঋণ শোধ হবে?
   ঋণ নেওয়া হলো                                          বিনিয়োগ করব?

গুরুত্বপূর্ণ কথা: accounting তথ্য তৈরি করে না — সে শুধু যা ঘটেছে তা ধরে রাখে এবং বোধগম্য আকারে সাজায়। ব্যবসা লাভজনক না হলে accounting তাকে লাভজনক বানাতে পারে না; শুধু সত্যটা স্পষ্ট করে দেখাতে পারে।

Bookkeeping বনাম Accounting

এই দুটোকে অনেকে এক করে ফেলেন। পার্থক্যটা আসলে কোথায় কাজ শেষ হয় তা নিয়ে:

Bookkeeping হলো accounting-এর প্রথম ধাপ। আপনি যে software বানাবেন, তার ৮০% আসলে bookkeeping automate করা — বাকি ২০% accounting-এর বিচারমূলক অংশকে সাহায্য করা।

Developer হিসেবে এটা মনে রাখলে scope ঠিক থাকে: আপনার কাজ নিয়মগুলো নির্ভুলভাবে প্রয়োগ করা, accountant-এর সিদ্ধান্ত নিজে নেওয়া নয়।

তিন ধরনের Accounting

একই ঘটনা তিনভাবে দেখা যায়, কারণ পাঠক তিন রকম:

                    একই ব্যবসার ঘটনা
                           │
        ┌──────────────────┼──────────────────┐
        │                  │                  │
   Financial          Management            Cost
   Accounting         Accounting          Accounting
        │                  │                  │
   বাইরের লোকের জন্য    ভিতরের লোকের জন্য    পণ্যের খরচ বের করতে

এই বইয়ের ৮৫% Financial Accounting নিয়ে — কারণ ওটাই সেই অংশ যার নিয়ম কঠোর, যা ভুল হলে audit-এ ধরা পড়ে, এবং যা software-এ নির্ভুলভাবে বানাতে হয়। Management ও Cost Accounting আসবে Volume 2 (Budget, Cost Center) ও Volume 3 (Part 6)-এ।

কোন ঘটনা খাতায় উঠবে?

এটাই এই অধ্যায়ের সবচেয়ে ব্যবহারিক প্রশ্ন — এবং software design-এ সবচেয়ে বেশি ভুল এখানেই হয়।

ব্যবসায় প্রতিদিন অজস্র ঘটনা ঘটে। সবগুলো accounting-এর খাতায় ওঠে না। যেটা ওঠে, তাকে বলে Financial Transaction। শর্ত দুটি:

১. এর একটা টাকার অঙ্ক আছে (measurable in money)
২. এটি ব্যবসার আর্থিক অবস্থা বদলে দেয় (changes assets, liabilities or equity)

দুটোই পূরণ হতে হবে। একটা হলে হবে না।

উদাহরণ দিয়ে দেখুন:

লক্ষ করুন সারি ২ ও ৩, এবং ৪ ও ৫ — একই বিষয়ের দুটি ধাপ, কিন্তু প্রথমটা খাতায় ওঠে না, দ্বিতীয়টা ওঠে। এই সীমারেখাটা ধরতে পারা accounting-এর প্রথম দক্ষতা।

Developer-দের সবচেয়ে সাধারণ ভুল এখানেই: Purchase Order তৈরি হওয়া মাত্র journal entry বানিয়ে ফেলা। PO একটা প্রতিশ্রুতি — কোনো accounting event নয়। Entry হবে তখন, যখন পণ্য আসবে বা bill আসবে। এই একটা ভুল অজস্র ERP-তে ভুল আর্থিক হিসাব তৈরি করেছে।

পাঁচটি মৌলিক Assumption

Accounting কতগুলো অনুমানের উপর দাঁড়িয়ে। এগুলো না জানলে অনেক নিয়ম অযৌক্তিক মনে হবে:

১. Business Entity — ব্যবসা ও মালিক আলাদা

মালিক আর ব্যবসা দুটো আলাদা সত্তা, যদিও আইনত এক হতে পারে। মালিক ব্যবসা থেকে টাকা নিলে সেটা “নিজের টাকা নিজে নেওয়া” নয় — সেটা ব্যবসার হিসাবে একটা লেনদেন (Drawings)।

Software-এ এর প্রতিফলন: প্রতিটি journal entry একটা নির্দিষ্ট entity/company-র অধীনে থাকতে হবে। Multi-company system-এ এটা প্রথম দিন থেকে ভাবা দরকার, পরে যোগ করা প্রায় অসম্ভব।

২. Money Measurement — শুধু টাকায় মাপা যায় এমন জিনিস

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

৩. Going Concern — ব্যবসা চলতে থাকবে

ধরে নেওয়া হয় ব্যবসা অদূর ভবিষ্যতে বন্ধ হচ্ছে না। এই কারণেই একটা মেশিন কেনার খরচ একবারে না ধরে ১০ বছর ধরে ভাগ করা হয় (depreciation)। ব্যবসা কাল বন্ধ হয়ে যাবে ধরে নিলে ওই ভাগ করার কোনো মানে থাকত না।

৪. Accounting Period — সময়কে টুকরো করা

ব্যবসা অবিরাম চলে, কিন্তু ফলাফল জানতে হলে সময়কে টুকরো করতেই হবে। তাই মাস, ত্রৈমাসিক, বছর।

৫. Accrual — নগদ নয়, ঘটনা

আয়/ব্যয় ধরা হয় যখন ঘটে, যখন টাকা হাতবদল হয় তখন নয়। এটাই সবচেয়ে গুরুত্বপূর্ণ এবং developer-দের কাছে সবচেয়ে বিভ্রান্তিকর অনুমান। অধ্যায় ৪-এ বেতনের উদাহরণে এটা দেখবেন, আর অধ্যায় ১৮-এ পুরোটা।

Accounting Period ও Fiscal Year

Accounting Period হলো সেই সময়সীমা যার জন্য হিসাব বন্ধ করে ফলাফল বের করা হয় — সাধারণত মাস।

Fiscal Year (অর্থবছর) হলো ১২ মাসের চক্র। এটা ক্যালেন্ডার বছর হতেই হবে এমন নয়:

বাংলাদেশ (সরকারি)      জুলাই  →  জুন
ভারত                    এপ্রিল →  মার্চ
যুক্তরাষ্ট্র (সাধারণ)      জানুয়ারি → ডিসেম্বর
অনেক বেসরকারি কোম্পানি   জানুয়ারি → ডিসেম্বর

এটাই এই অধ্যায়ের সবচেয়ে দামি developer-শিক্ষা: fiscal year কখনো hardcode করবেন না। “বছর শেষ মানে ৩১ ডিসেম্বর” ধরে নিয়ে লেখা কোড বাংলাদেশের কোনো সরকারি প্রতিষ্ঠানে চলবে না। Fiscal year একটা configuration, ধ্রুবক নয়।

Period-এর আরেকটা দিক আছে যা software-এ অপরিহার্য — period lock। একবার একটা মাস বন্ধ করে report দিয়ে দেওয়ার পরে ওই মাসে নতুন entry ঢোকানো যাবে না। ঢুকলে আগের report আর মিলবে না। বিস্তারিত অধ্যায় ৪২-এ।

৩. Accounting Rule

এই অধ্যায়ে মুখস্থ করার মতো সূত্র নেই, কিন্তু কতগুলো সিদ্ধান্তের নিয়ম আছে:

নিয়ম ১ — Recognition test

একটি ঘটনা খাতায় উঠবে যদি এবং কেবল যদি:
    (ক) টাকায় নির্ভরযোগ্যভাবে মাপা যায়   AND
    (খ) সম্পদ, দায় বা মালিকানা বদলে দেয়

নিয়ম ২ — Entity boundary

প্রতিটি লেনদেন কোনো না কোনো entity-র।
"মালিকের ব্যক্তিগত খরচ" ব্যবসার খরচ নয়।

নিয়ম ৩ — Period assignment

প্রতিটি লেনদেন ঠিক একটি accounting period-এ পড়বে,
নির্ধারিত হয় posting_date দিয়ে — created_at দিয়ে নয়।

তৃতীয় নিয়মটা developer-দের জন্য বিশেষভাবে গুরুত্বপূর্ণ। ৩১ জানুয়ারির লেনদেন কেউ ২ ফেব্রুয়ারিতে system-এ ঢোকাতে পারে — সেটা জানুয়ারি মাসেই পড়বে। created_at দিয়ে period ঠিক করলে হিসাব ভুল হবে।

৪. Real Business Example

একটা ছোট software company-র প্রথম মাস ধরুন। কোনগুলো খাতায় উঠবে?

১ জুলাই    মালিক ৫,০০,০০০ টাকা দিয়ে ব্যবসা শুরু করলেন
৩ জুলাই    অফিস ভাড়ার চুক্তি সই হলো, মাসিক ২০,০০০
৫ জুলাই    দুজন developer নিয়োগপত্র পেলেন
৮ জুলাই    ১,২০,০০০ টাকায় দুটি ল্যাপটপ কেনা হলো (নগদে)
১২ জুলাই   একজন client ৩,০০,০০০ টাকার কাজের আগ্রহ দেখালেন
২০ জুলাই   ওই client-এর সাথে চুক্তি সই, কাজ শুরু
৩১ জুলাই   জুলাই মাসের ভাড়া ২০,০০০ বাকি রইল
৩১ জুলাই   দুজনের বেতন ১,৬০,০০০ হলো, ৫ আগস্টে দেওয়া হবে

বিশ্লেষণ:

আটটি ঘটনার মধ্যে চারটি খাতায় উঠল।

শেষ দুটি বিশেষভাবে লক্ষ করুন — কোনো টাকা হাতবদল হয়নি, তবুও দুটোই খাতায় উঠছে। এটাই accrual। ভাড়ার সুবিধা জুলাইয়ে ভোগ করা হয়েছে, তাই খরচটা জুলাইয়েরই — টাকা আগস্টে দিলেও।

৩ ও ৩১ তারিখের তুলনাটা মনে রাখুন: একই ভাড়া, চুক্তির দিন নয়, ভোগ করার দিন খাতায় ওঠে।

৫. Implementation — Software ও Database

Entity ও Period — ভিত্তির দুটি table

উপরের দুটি assumption (Business Entity, Accounting Period) সরাসরি দুটি table-এ রূপ নেয়। এই দুটো প্রথম দিনেই বানাতে হবে — পরে যোগ করা অত্যন্ত কঠিন।

companies                       -- Business Entity assumption

id                  BIGINT PK
name                VARCHAR
legal_name          VARCHAR
base_currency       CHAR(3)      -- 'BDT'
fiscal_year_start   SMALLINT     -- 1..12, জুলাই হলে 7
is_active           BOOLEAN

accounting_periods              -- Accounting Period assumption

id                  BIGINT PK
company_id          BIGINT FK
fiscal_year         SMALLINT     -- 2025
period_no           SMALLINT     -- 1..12
name                VARCHAR      -- 'July 2025'
start_date          DATE
end_date            DATE
status              VARCHAR      -- 'open' | 'closed' | 'locked'
closed_at           TIMESTAMP
closed_by           BIGINT

fiscal_year_start একটা column — এটাই সেই জিনিস যা আপনার system-কে বাংলাদেশ, ভারত ও যুক্তরাষ্ট্র তিন জায়গাতেই চালাতে দেবে। জুলাই-জুন অর্থবছরে ২০২৫-২৬ সালের period গুলো হবে:

fiscal_year  period_no   start_date    end_date      name
2026         1           2025-07-01    2025-07-31    July 2025
2026         2           2025-08-01    2025-08-31    August 2025
...
2026         12          2026-06-01    2026-06-30    June 2026

লক্ষ করুন — fiscal_year = 2026 অথচ প্রথম period ২০২৫ সালের জুলাই। এই বিভ্রান্তি এড়াতে convention আগেই ঠিক করে নথিভুক্ত করুন (সাধারণত যে ক্যালেন্ডার বছরে অর্থবছর শেষ হয়, সেটাই নাম)।

Period নির্ধারণের যুক্তি

posting_date দেওয়া আছে
        ↓
সেই তারিখ যে period-এর মধ্যে পড়ে, তাকে খুঁজে বের করো
        ↓
    ┌───────────────────────┐
    │  period পাওয়া যায়নি?  │──▶ reject: "period defined নেই"
    └───────────────────────┘
        ↓
    ┌───────────────────────┐
    │  status = closed?     │──▶ reject: "period বন্ধ"
    └───────────────────────┘
        ↓
    post করতে দাও

কোডে যেন এই যুক্তিটা একটাই জায়গায় থাকে। প্রতিটি module নিজে নিজে period যাচাই করলে অবধারিতভাবে কোথাও না কোথাও বাদ পড়বে।

দুটো তারিখ, দুটো আলাদা কাজ

এদের গুলিয়ে ফেলা একটা মারাত্মক bug। জানুয়ারির লেনদেন ফেব্রুয়ারিতে ঢুকলে created_at ফেব্রুয়ারি, কিন্তু posting_date জানুয়ারি — আর হিসাবে সেটা জানুয়ারিতেই যাবে।

Audit-এর সময় দুটোই দরকার হয়: posting_date বলে কোন মাসের হিসাব, created_at বলে কখন লেখা হয়েছিল। বড় ব্যবধান দেখলে নিরীক্ষক প্রশ্ন করেন — এবং সেটা করাই উচিত।

৬. Financial Statement Impact

এই অধ্যায়ের কোনো journal entry নেই, কিন্তু যে report গুলোর দিকে পুরো বই এগোচ্ছে সেগুলোর সাথে পরিচয় করে নিন:

সময়ের এই পার্থক্যটা গুরুত্বপূর্ণ:

Balance Sheet   →  ছবি (snapshot)     →  "৩০ জুন ২০২৬ তারিখে"
P&L             →  ভিডিও (period)     →  "১ জুলাই ২০২৫ থেকে ৩০ জুন ২০২৬"

Report API design করার সময় এটাই ঠিক করে দেয় parameter কী হবে — Balance Sheet নেয় একটি তারিখ, P&L নেয় দুটি তারিখ। এই ভুলটা report engine-এ খুব সাধারণ। বিস্তারিত অধ্যায় ২০–২৩-এ।

৭. Common Developer Mistakes

শেষেরটা সূক্ষ্ম কিন্তু বাস্তব। posting_date যদি TIMESTAMP হয় আর server UTC-তে চলে, তাহলে ঢাকার সময় ৩১ জুলাই রাত ১১টার লেনদেন UTC-তে ৩১ জুলাই বিকেল ৫টা — ঠিক আছে। কিন্তু উল্টো দিকের timezone-এ সেটা ১ আগস্ট হয়ে যাবে, আর লেনদেনটা ভুল মাসে পড়বে। হিসাবের তারিখ একটা তারিখ, একটা মুহূর্ত নয় — DATE রাখুন।

৮. Exercises

সেট ক — খাতায় উঠবে কি?

প্রতিটির জন্য “হ্যাঁ/না” এবং কারণ লিখুন:

১।  কোম্পানি একটি ব্যাংক অ্যাকাউন্ট খুলল (কোনো টাকা জমা ছাড়া)।
২।  ওই অ্যাকাউন্টে ২,০০,০০০ টাকা জমা দেওয়া হলো।
৩।  একজন সরবরাহকারীর সাথে বার্ষিক চুক্তি সই হলো।
৪।  ওই সরবরাহকারী প্রথম চালান পাঠাল, বিল ৫০,০০০।
৫।  কোম্পানির ওয়েবসাইটে ১০,০০০ ভিজিটর এল।
৬।  অফিসের কম্পিউটার পুরনো হয়ে মূল্য কমল।
৭।  একজন কর্মী পদত্যাগ করলেন।
৮।  ওই কর্মীর চূড়ান্ত পাওনা ৪৫,০০০ হিসাব করা হলো।
৯।  মালিক ব্যক্তিগত গাড়ির জ্বালানি ব্যবসার টাকায় কিনলেন।
১০। ব্যাংক থেকে ৫,০০০ টাকা সার্ভিস চার্জ কাটল।

সেট খ — Period নির্ধারণ

কোম্পানির অর্থবছর জুলাই → জুন। নিচের প্রতিটি লেনদেন কোন fiscal_year ও period_no-তে পড়বে?

১১। posting_date = 2025-07-15
১২। posting_date = 2025-12-31
১৩। posting_date = 2026-06-30
১৪। posting_date = 2026-07-01
১৫। posting_date = 2025-08-20, কিন্তু created_at = 2025-09-05

সেট গ — চিন্তার প্রশ্ন

১৬। মালিক ব্যবসার গাড়ি ব্যক্তিগত কাজে ব্যবহার করেন। কোন assumption
    এখানে প্রাসঙ্গিক, এবং হিসাবে কী করা উচিত?

১৭। একটি কোম্পানি আগামী মাসে বন্ধ হয়ে যাচ্ছে। কোন assumption ভেঙে
    পড়ছে, এবং তাতে সম্পদের মূল্যায়নে কী বদলাবে?

১৮। আপনার system-এ একজন ব্যবহারকারী বন্ধ হয়ে যাওয়া জুন মাসে একটি
    entry দিতে চাইছেন — কারণ সত্যিই ওটা জুনের লেনদেন, ভুলে বাদ পড়েছিল।
    আপনি কী করতে দেবেন? তিনটি সম্ভাব্য নকশা লিখুন এবং একটি বেছে নিন।

১৮ নম্বরের কোনো একমাত্র সঠিক উত্তর নেই — বাস্তব system-এ এটা একটা নীতিগত সিদ্ধান্ত। নিজের উত্তর লিখে রাখুন, অধ্যায় ৪২-এ মিলিয়ে দেখবেন।

উত্তর আছে Workbook-এর Answer Key, অধ্যায় ১-এ।

৯. Developer Challenge

একটি নতুন accounting system-এর ভিত্তির schema নকশা করুন — শুধু company ও period, আর কিছু নয়।

যা যা ঠিক করবেন:

১. Multi-company সমর্থন করবেন কীভাবে — প্রতি company আলাদা database, না একই database-এ company_id? দুটোর সুবিধা-অসুবিধা লিখুন। ২. বছর শুরুতে ১২টি period তৈরি হবে — এই কাজটা কে করবে, কখন করবে? ৩. অর্থবছর জুলাই-জুন হলে fiscal_year নামকরণে কোন convention নেবেন, এবং কেন? ৪. একটি period বন্ধ করার আগে কী কী শর্ত যাচাই করবেন? ৫. কোনো একটা লেনদেনের posting_date এমন দিনে পড়েছে যার কোনো period তৈরি হয়নি — কী করবেন? চুপচাপ period বানিয়ে ফেলবেন, নাকি reject করবেন?

৫ নম্বরটা দেখতে ছোট, কিন্তু এর উত্তরই ঠিক করে দেয় আপনার system কতটা নিরাপদ। নিজের সিদ্ধান্ত ও যুক্তি লিখে রাখুন।

১০. Summary Card

Accounting কী

   Business Events  ──▶  record → classify → summarize  ──▶  Reports

Bookkeeping বনাম Accounting

তিন ধরনের Accounting

খাতায় উঠবে কি না — দুটি শর্ত

১.  টাকায় মাপা যায়                          AND
২.  সম্পদ / দায় / মালিকানা বদলায়

দুটোই লাগবে। চুক্তি, order, নিয়োগপত্র — কোনোটাই নয়।

পাঁচটি Assumption

Developer checklist — ভিত্তি তৈরির সময়

□  company_id প্রথম দিন থেকে
□  fiscal_year_start configurable (hardcode নয়)
□  posting_date দিয়ে period, created_at দিয়ে নয়
□  posting_date এর type DATE, TIMESTAMP নয়
□  period এর status: open / closed / locked
□  period যাচাইয়ের যুক্তি একটাই জায়গায়
□  বছর শুরুতে ১২টি period তৈরি
□  PO / চুক্তি থেকে journal নয়

পরবর্তী অধ্যায়

অধ্যায় ২ — Accounting Equation: এই অধ্যায়ে জেনেছি কোন ঘটনা খাতায় ওঠে। পরের অধ্যায়ে জানব — ওঠার পরে তারা কোন নিয়মে বসে। মাত্র একটি সমীকরণ, যা কখনো ভাঙে না, এবং যেখান থেকে পুরো double-entry ব্যবস্থাটা বেরিয়ে আসে।