GST চালান ডেটা মডেলের মৌলিক দিক: ন্যূনতম ফিল্ডগুলো, HSN হ্যান্ডলিং, এবং কনপ্লায়েন্ট ইনভয়েস তৈরির জন্য প্রয়োজনীয় অ্যাডমিন স্ক্রিন ও রিকনসিলিয়েশন সহজ করার টিপস।

অধিকাংশ GST চালান সমস্যা "জটিল কর" বিষয় নয়। এগুলো সাধারণত অনুপস্থিত বা অসমঞ্জস্ত ডেটার কারণে হয়। অডিট ব্যর্থ হয় যখন চালানটি পরিষ্কারভাবে দেখা যায় না যে কী বিক্রি হয়েছে, কার কাছে, কোথায় সরবরাহ হয়েছে, এবং কর কীভাবে হিসাব করা হয়েছে।
একটি সাধারণ কারণ HSN অনুপস্থিত থাকা, পুরোনো থাকা বা ভুল স্তরে প্রয়োগ করা। টিমগুলো প্রোডাক্টে HSN সংরক্ষণ করতে পারে, কিন্তু যখন ইনভয়েস লাইনটা ভিন্ন SKU নাম বা ভ্যারিয়েন্ট থেকে তৈরি হয়, তখন HSN কখনো ফাইনাল ডকুমেন্টে পৌঁছায় না। আরেকটা ঘন সমস্যা হল কর বিভাজন ভুল হওয়া: "place of supply" কে শিপিং ঠিকানার থেকে অনুমান করে IGST চার্জ করে নেয়া যখন আসলে CGST+SGST হওয়া উচিত (বা উল্টোটাও হতে পারে) — কারণ সিদ্ধান্ত নেয়ার জন্য ব্যবহৃত state code সংরক্ষিত থাকে না।
ফাইন্যান্স টিমরা এইটা তৎক্ষণাৎ অনুভব করে। রিকনসিলিয়েশন প্রতিদিনের ক্লিনআপ কাজ হয়ে যায়: ইনভয়েস মোট অর্ডারের সাথে মেলে না, অর্ডার পেমেন্ট গেটওয়ে সেটেলমেন্টের সাথে মেলে না, এবং রিফান্ডগুলো ম্যানুয়াল নোটের একটি চেইন হয়ে ওঠে। এমনকি লাইন আইটেমগুলিতে ছোট রাউন্ডিং পার্থক্যও ইনভয়েস PDF, GST রিপোর্ট এবং লেজারের মধ্যে মিল খামতি তৈরি করতে পারে।
নিচে সেই প্যাটার্নগুলো দিলাম যেগুলো সবচেয়ে বেশি মismatch করে:
GST চালান ডেটা মডেলের লক্ষ্য সরল: অর্ডার, প্রোডাক্ট, পার্টি, ট্যাক্স, ইনভয়েস এবং ক্রেডিট নোটের একটি ন্যূনতম সেট সংরক্ষণ করুন যাতে প্রতিটি সংখ্যা পরে পুনরুত্পাদন ও ব্যাখ্যা করা যায়। ছোট রাখুন, কিন্তু এমন ফিল্ড বাদ দেবেন না যা আইনিকভাবে কর ধরার ধরন, হার এবং রিপোর্টিং নির্ধারণ করে।
যদি আপনি চান GST চালান তৈরি করা সহজ হোক এবং পরে রিকনসিলিয়েশন সহজ হয়, তাহলে একটি ছোট সেট অবজেক্ট দিয়ে শুরু করুন এবং প্রতিটি অবজেক্টকে একটি একক কাজ করতে দিন। একটি পরিষ্কার GST চালান ডেটা মডেল অনেক টেবিল থাকার চেয়ে সময়ের সাথে तथ्यগুলো স্থিতিশীল রাখার ওপর বেশি নির্ভর করে।
দিন একের জন্য বেশিরভাগ টিমকে যে মূল রেকর্ডগুলো দরকার তা হলো:
Invoice অবশ্যই Order থেকে আলাদা হওয়া উচিত। অর্ডার বদলে যেতে পারে (ঠিকানা আপডেট, আইটেম বাতিল ইত্যাদি)। ইনভয়েসগুলো পরিবর্তনশীল হওয়া উচিত নয়। তাদের স্থিতিশীল নম্বরিং, তারিখ এবং মোট দরকার যা পরে "ড্রিফট" হবে না কারণ কেউ পরে অর্ডার আপডেট করেছে।
ট্যাক্স সঠিক রাখার মূল হলো Line Items। প্রতিটি অর্ডার লাইন আইটেম (এবং পরে প্রতিটি ইনভয়েস লাইন আইটেম) নির্দিষ্ট পরিমাণ, ইউনিট প্রাইজ, ডিসকাউন্ট এবং ঐ নির্দিষ্ট আইটেমের জন্য ট্যাক্স ব্রেকডাউন ধারণ করা উচিত। এখানেই HSN/SAC এবং GST রেট বাস্তবে প্রয়োগ হয়।
একটি ছোট কিন্তু গুরুত্বপূর্ণ ধারণা: snapshots সংরক্ষণ করুন। যখন আপনি ইনভয়েস তৈরি করেন, তখন প্রোডাক্টের বিবরণ, HSN/SAC, ট্যাক্স রেট এবং প্রাইসিং ইনভয়েস লাইনগুলিতে কপি করে নিন। কারেন্ট প্রোডাক্ট মাস্টারের উপর নির্ভর করবেন না, কারণ রেট ও নাম বদলে যেতে পারে।
বিকল্পভাবে, সাধারণত শুরুতেই যোগ করা উচিত: Returns, Refunds, এবং Credit Notes আলাদা রেকর্ড হিসেবে রাখা। উদাহরণ: একজন কাস্টমার দুটি আইটেমের অর্ডারের মধ্যে থেকে একটি ফিরিয়ে দিলে আপনি চাইবেন একটি ক্রেডিট নোট যা মূল ইনভয়েস লাইনের রেফারেন্স দেয়, আর পেমেন্ট রিফান্ড রেকর্ড গেটওয়ে ট্রান্জেকশনের রেফারেন্স দেয়। এগুলোকে স্পষ্ট অবজেক্ট হিসেবে রাখা মাস এক শেষে GST রেজিস্টারে ম্যানুয়াল ফিক্স এড়িয়ে দেয়।
যদি আপনি এটা Koder.ai-তে বানান, প্রত্যেক অবজেক্টকে প্রথমে একটি সরল স্ক্রিন হিসেবে বিবেচনা করুন (create, view, edit), তারপর ইনভয়েস জেনারেশন যোগ করুন কেবল যখন snapshots এবং লাইন-লেভেল ফিল্ডগুলো স্থাপন করা হয়েছে।
HSN (পণ্যগুলোর জন্য) এবং SAC (সেবার জন্য) "শুধু ইনভয়েস-অনলি" ডিটেইল নয়। এগুলো প্রোডাক্ট বা সার্ভিস ডিফ�nিশন থেকে শুরু হয়, এবং ইনভয়েস ওঠানোর সময় প্রতিটি লাইনে কপি করা হয়। এটি মিক্সড কার্টগুলোকে সঠিক রাখে এবং অডিট সহজ করে কারণ প্রতিটি লাইন নিজে থেকেই দাঁড়ায়।
একটি ব্যবহারিক ন্যূনতম ডেটা মডেল হলো:
Product-এ HSN/SAC রাখা অ্যাডমিন টিমকে এক জায়গায় তা মেইনটেইন করতে সাহায্য করে। InvoiceLine-এ কপি করা অতীত ইনভয়েসগুলোকে স্থিতিশীল করে। প্রোডাক্ট পরে বদলে গেলেও ইনভয়েস দেখায় কোন তথ্য সেই বিক্রয়ের সময় সত্য ছিল। এটি এমন একটি GST চালান ডেটা মডেলের হৃৎপিণ্ড যা রিকনসিলিয়েশনে ভাঙে না।
HSN সংরক্ষণের জন্য সরলতা রাখুন: code প্রয়োজনীয়, description ঐচ্ছিক, এবং effective_from date ঐচ্ছিক যদি আপনি পরিবর্তনের ইতিহাস ট্র্যাক করতে চান। বেশিরভাগ টিম প্রতিটি লাইন আইটেমে description চাইবে না, তবে ব্যতিক্রমগুলো ফাইন্যান্স চেক করার সময় সাহায্য করে।
মিক্সড কার্ট স্বাভাবিক: একটি ইনভয়েসে একাধিক লাইন আইটেম হতে পারে এবং তাই একাধিক HSN/SAC কোড থাকতে পারে। এক ইনভয়েসে এক কোড জোর করে দেবেন না। মোটগুলো ইনভয়েস লেভেলে রোল-আপ হয়, ক্লাসিফিকেশন লাইন লেভেলে থাকে।
চেঞ্জ ম্যানেজমেন্টেই লোকেরা সমস্যায় পড়ে। একটি ছোট রুল সেট ব্যবহার করুন:
অ্যাডমিন স্ক্রিন দিক থেকে, প্রোডাক্ট ট্যাক্স ফিল্ড এডিট করার জন্য আপনাকে মাত্র একটি জায়গা লাগবে, প্লাস ইনভয়েস লাইনের read-only ভিউ যাতে যখন ইনভয়েস তৈরি হয়েছে তখন কি ধারণ করা হয়েছিল তা দেখানো যায়। দ্রুত স্ক্রিন বানালে Koder.ai-এর মতো টুলগুলি এই মডেল থেকে মৌলিক CRUD পেজ এবং ডেটা টেবিল জেনারেট করতে পারে খুব কম প্রচেষ্টায়।
GST চালান ডেটা মডেল সবচেয়ে বেশি ব্যর্থ হয় পার্টি বিবরণে। যদি বায়ার বা সেলার পরিচয় সামান্য হলেও ভুল থাকে, আপনার ইনভয়েস কাগজে বৈধ হতে পারে কিন্তু রিটার্ন ও রিকনসিলিয়েশনে যন্ত্রণাদায়ক হবে।
শুরুতেই "seller", "buyer" এবং "ship-to" কে আলাদা পার্টি হিসেবে ধরুন, এমনকি তারা একই ব্যক্তি হলেও। এটি পরে যখন কাস্টমার ভিন্ন শিপিং ঠিকানা যোগ করে বা আপনি একাধিক GST রেজিস্ট্রেশন থেকে বিক্রি করেন তখন হ্যাকগুলো আটকায়।
বোরিং ও এক্সপ্লিসিট ফিল্ড রাখুন। এগুলো সাধারণত ইনভয়েস ও রিপোর্টে দরকার হয়:
State উভয়ে মানব-পঠিত নাম ও state code হিসেবে সংরক্ষণ করুন, কারণ রিপোর্টিং ও place-of-supply নিয়মগুলো প্রায়ই কোডের উপর নির্ভর করে।
অর্ডারে প্রোফাইল ছাড়াও billing ও shipping ঠিকানা কপি করে রাখুন। প্রোফাইল বদলে যায়; ইনভয়েস বদলে যাওয়া উচিত নয়।
Place of supply ইনভয়েসে একটি নির্দিষ্ট state code হিসেবে সংরক্ষিত থাকা উচিত (invoice তৈরির সময়ে order থেকে কপি করা)। পরে এটি "রিক্যালকুলেট" করবেন না। যদি আপনার রুল "ship-to state" হয়, তাহলে সেই ফলটি এবং সিদ্ধান্ত নেয়ার জন্য ব্যবহৃত state সংরক্ষণ করুন। এতে অডিট ও বিতর্ক সহজ হয়।
B2B-এর জন্য সাধারণত বায়ার GSTIN বাধ্যতামূলক এবং entry করার সময় দৈর্ঘ্য ও ফরম্যাট ভ্যালিডেট করা উচিত। B2C-তে GSTIN ফাঁকা থাকতে পারে, কিন্তু আপনি তখনও পূর্ণ ঠিকানা ও স্টেট দরকার যাতে CGST/SGST না হলে IGST প্রযোজ্য কি না ঠিক করা যায়।
একটি সরল রুল যেটা বেশিরভাগ সিস্টেমে কাজ করে: যদি বায়ার GSTIN থাকে, সেটি B2B হিসেবে বিবেচনা করুন; না থাকলে B2C হিসেবে ধরা হবে। যদি আপনি ব্যতিক্রম চান, explicit customer_type ফিল্ড সংরক্ষণ করুন।
যদি আপনার ব্রাঞ্চ বা বিজনেস ইউনিট থাকে যাদের আলাদা GST রেজিস্ট্রেশন আছে, তাহলে "Seller Entity" কে আলাদা রেকর্ড হিসেবে মডেল করুন যাতে প্রতিটি এন্টিটির নিজস্ব GSTIN ও ঠিকানা থাকে। প্রতিটি অর্ডারটি একমাত্র seller entity রেফার করবে, এবং প্রতিটি ইনভয়েস ঐ ডিটেইল কপি করবে যাতে ইতিহাসগত ইনভয়েসগুলো সঠিক থাকে যদিও পরে seller ঠিকানা বদলে যায়।
Koder.ai-এর মতো টুলগুলি দ্রুত এই রেকর্ডগুলোর অ্যাডমিন ফর্ম জেনারেট করতে পারে, তবে মূল কাঠামো হলো: আলাদা seller entity, অর্ডার-সময় স্ন্যাপশট, এবং explicit place-of-supply state code।
সবচেয়ে সাধারণ বিভাজন সোজা: যদি supplier এবং place of supply একই রাজ্য হয়, ট্যাক্স CGST + SGST; অন্য রাজ্য হলে IGST। আপনার সিস্টেম পরে "টোটাল থেকে পুনর্গণনা" করা উচিৎ নয় কারণ ক্ষুদ্র পার্থক্য (রাউন্ডিং, ডিসকাউন্ট, শিপিং)ই মিসম্যাচের কারণ।
ন্যূনতমভাবে ট্যাক্স নম্বরগুলো ইনভয়েস লাইন লেভেলে সংরক্ষণ করুন, শুধুমাত্র ইনভয়েস হেডারে নয়। এভাবে আপনি ইনভয়েসের প্রতিটি রুপিয়া ব্যাখ্যা করতে পারবেন এবং সেটা প্রোডাক্ট, HSN এবং রেভিনিউ-র সাথে মিলাতে পারবেন।
প্রতি ইনভয়েস লাইনের জন্য ব্যবহারিক ন্যূনতম ক্ষেত্রগুলো দেখতে এভাবে:
ডিসকাউন্টগুলোই এমন জায়গা যেখানে সিস্টেমগুলো জটিল হয়ে পড়ে। একটি রুল ঠিক করুন এবং সেটিকে স্পষ্টভাবে সংরক্ষণ করুন। যদি ডিসকাউন্ট ট্যাক্সের আগে মূল দাম কমায় (সাধারণত আইটেম ডিসকাউন্ট ও কুপন ক্ষেত্রে), তাহলে মূল গ্রস এমাউন্ট, ডিসকাউন্ট এমাউন্ট, এবং ফলাফল taxable value সংরক্ষণ করুন। যদি অর্ডার-লেভেল কুপন থাকে, সেটিকে লাইনগুলোর উপর বরাদ্দ করুন (সাধারণত প্রতিটি লাইনের প্রি-ডিসকাউন্ট ট্যাক্সেবল ভ্যালু অনুযায়ী تناপাতিকভাবে) এবং প্রতিটি লাইনের আলোকিত ডিসকাউন্ট সংরক্ষণ করুন যাতে ট্যাক্স ম্যাথ ব্যাখ্যাযোগ্য থাকে।
রাউন্ডিং সঙ্গতিপূর্ণ হওয়া উচিত এবং রেকর্ড করা উচিত। আপনি লাইন লেভেলে রাউন্ড করবেন নাকি কেবল ইনভয়েস লেভেলে, সেটি অবশ্যই নির্ধারিত করুন এবং আপনি যে রাউন্ডিং ফলাফল প্রিন্ট করেছেন তা সংরক্ষণ করুন। অনেক টিম লাইন অনুযায়ী ট্যাক্স গণনা করে, দুই দশমিকের কাছে রাউন্ড করে, তারপর একটি চূড়ান্ত invoice_rounding_adjustment ফিল্ড প্রয়োগ করে নির্দিষ্ট পে-অ্যাবল অ্যামাউন্টে যেতে।
শিপিং ও হ্যান্ডলিংকে লুকানো অতিরিক্ত হিসেবে বিবেচনা করবেন না। এগুলোকে একটি আলাদা ইনভয়েস লাইন হিসেবে বিবেচনা করুন যার নিজস্ব HSN/service কোড এবং ট্যাক্স রেট রুল। উদাহরণ: দুইটি প্রোডাক্ট এবং একটি শিপিং ফি আছে এমন অর্ডার তিনটি লাইনে রূপান্তরিত হবে, প্রতিটিতেই ট্যাক্সেবল ভ্যালু ও ট্যাক্স কম্পোনেন্ট এমাউন্ট রাখা থাকবে, ফলে ফাইন্যান্স রিকনসিলিয়েশন অনেক সহজ হয়।
একবার ট্যাক্স গণনা হলে, ইনভয়েসের এমন "ডকুমেন্ট" ফিল্ডগুলো দরকার যা এটিকে বৈধ, অডিটঅযোগ্য, এবং পরে রিকনসিল করতে সহজ করে। GST চালান ডেটা মডেলে ইনভয়েস হেডারকে একটি আইনি রেকর্ড হিসেবে দেখুন: এটি স্থির থাকা উচিত যদিও প্রোডাক্ট বা কাস্টমার ডেটা পরে বদলে যায়।
হেডারের বেসিক্স দিয়ে শুরু করুন: invoice number, issue date (ইনভয়েসে যা লেখা থাকবে), invoice type (tax invoice, export, B2B, B2C ইত্যাদি), এবং currency। যদিও বেশিরভাগ ইনভয়েস INR-এ হোক, currency সংরক্ষণ করলে এক্সপোর্ট বা মাল্টি-কারেন্সি মার্কেটপ্লেসের জন্য সমস্যা কমে।
নম্বরিংতে টিমগুলো পুড়ে যায়। একটি সিরিজ বা প্রিফিক্স রাখুন (উদাহরণ: "FY25-INV-"), আর ফাইন্যান্সিয়াল ইয়ার সংরক্ষণ করুন এবং ডাটাবেস স্তরে uniqueness বজায় রাখুন। অ্যাডমিনে প্রতিটি সিরিজের জন্য "next number" কন্ট্রোলও রাখুন যাতে দুটি অ্যাডমিন একসাথে একই নাম্বার ইস্যু করতে না পারে।
টোটালগুলো স্পষ্টভাবে সংরক্ষণ করুন, কেবল ডিরাইভ করা নয়। subtotal (taxable value), total tax, grand total, এবং আলাদা round-off amount সংরক্ষণ করুন। যদি আপনি লাইন আইটেম থেকে পরে পুনর্গণনা করেন, একটি ছোট রুল পরিবর্তন পুরোনো ইনভয়েসগুলোকে ফাইল করা রিটার্নের সাথে মেলানো বন্ধ করতে পারে।
স্ট্যাটাসগুলো বাস্তব জীবনচক্র প্রতিফলিত করবে এবং প্রয়োজন হলে রেকর্ড লক করবে:
অবশেষে, জেনারেট করা আর্টিফ্যাক্ট মেটাডেটা সংরক্ষণ করুন: PDF টেমপ্লেট ভার্সন, জেনারেশন টাইমস্ট্যাম্প, এবং একটি ফাইল আইডেন্টিফায়ার। একটি হ্যাশ ঐচ্ছিক, কিন্তু যদি আপনি প্রমাণ করতে চান যে PDF পরিবর্তন করা হয়নি তাহলে উপকারী।
উদাহরণ: যদি একটি সাপোর্ট এজেন্ট টেমপ্লেট আপডেটের পরে PDF পুনরায় জেনারেট করে, ইনভয়েস মোট ও নম্বর একই থাকা উচিত, কিন্তু সংরক্ষিত টেমপ্লেট ভার্সন ব্যাখ্যা করবে কেন PDF লেআউট ভিন্ন দেখা যাচ্ছে।
ফাইল ক্রিৎ GST ইনভয়েস চাইলে ইনভয়েস স্ক্রিন থেকেই শুরু করবেন না। ইনপুটগুলো যেখান থেকে আসে সেই অ্যাডমিন পেজগুলো থেকে শুরু করুন। একটি ভাল GST চালান ডেটা মডেল ছোট থাকে যখন এই ইনপুটগুলো নিয়ন্ত্রিত ও সঙ্গতিপূর্ণ থাকে।
প্রোডাক্ট মাস্টার হলো যেখানে ভবিষ্যতের বেশিরভাগ মismatch শুরু হয়, তাই এটাকে কড়াকড়ি রাখুন। প্রতিটি SKU-তে একটাই ডিফল্ট HSN (বা সার্ভিসের জন্য SAC), প্লাস ডিফল্ট GST হার এবং কেবল নির্দিষ্ট তারিখগুলোর জন্য প্রযোজ্য কোনো ব্যতিক্রম থাকা উচিত।
একটি বাস্তবিক প্রোডাক্ট স্ক্রিন সাধারণত এসব দরকার:
একটি "ক্যালকুলেটর" UI এড়ান। বরং এমন ইনপুট সংরক্ষণ করুন যা আপনার সিস্টেম ধারাবাহিকভাবে প্রয়োগ করতে পারে: রেট টেবিল, আপনি যে place of supply রুল অনুসরণ করেন, এবং আপনি কীভাবে ইনট্রা-স্টেট বনাম ইন্টার-স্টেট নির্ধারণ করেন (সাধারণত supplier state ও ship-to state তুলনা করে)।
ট্যাক্স স্ক্রিনকে ফোকাস রাখুন: ক্যাটেগরি/HSN গ্রুপ অনুযায়ী ট্যাক্স রেট, effective dates, এবং যখন বায়ার বৈধ GSTIN দেয় তখন কি ঘটবে সেই নিয়ম।
কাস্টমার স্ক্রিনে GSTIN এবং তার validation স্ট্যাটাস, প্লাস ডিফল্ট বিলিং ও শিপিং ঠিকানা থাকা উচিত। ব্যবহারকারীদের ফ্রি-ফর্ম স্টেট টাইপ করতে দেবেন না; একটি নিয়ন্ত্রিত তালিকা ব্যবহার করুন যাতে "KA" এবং "Karnataka" দুইটি আলাদা মান না হয়।
আপনার কোম্পানি প্রোফাইল স্ক্রিন একইভাবে গুরুত্বপূর্ণ: আইনগত নাম, GSTIN, নিবন্ধিত ঠিকানা, এবং ইনভয়েস সিরিজ সেটিংস (প্রিফিক্স, পরবর্তী নম্বর, এবং অর্থবছরের সীমানা)। পারমিশন দিয়ে এটাকে লক করুন কারণ পরিবর্তনগুলি ভবিষ্যত প্রতিটি ডকুমেন্টকে প্রভাবিত করে।
কঠিন সিস্টেম দরকার নেই, কিন্তু ট্রেইল দরকার। দেখুন কে HSN/SAC, GST রেট, invoice series সেটিং পরিবর্তন করেছে, পুরোনো মান, নতুন মান, টাইমস্ট্যাম্প এবং কারণসহ লগ রাখুন।
যদি আপনি এই স্ক্রিনগুলো Koder.ai-তে তৈরি করছেন, অডিট লগিং এবং effective dates-কে প্রথম শ্রেণির ফিল্ড হিসেবে বিবেচনা করুন। এগুলো শুরুতেই যোগ করা খরচ কম কিন্তু পরে ফাইন্যান্স রিভিউয়ে অনেক সময় বাঁচায়।
একটি কনপ্লায়েন্ট ইনভয়েস ফরম্যাটিং নয় বরং সঠিক সময়ে সঠিক তথ্য স্থির করে ফেলার ব্যাপার। যদি আপনি আপনার GST চালান ডেটা মডেলকে এই ফ্লোর চারপাশে ডিজাইন করেন, ফাইন্যান্সের কাজ মিলিয়ে দেখা নয় বরং সহজ ম্যাচিং হবে।
ট্যাক্স গণনার আগে অর্ডারের স্ন্যাপশট লক করুন: আইটেম, পরিমাণ, ইউনিট প্রাইস, ডিসকাউন্ট, শিপিং/হ্যান্ডলিং চার্জ, কাস্টমার GSTIN (যদি থাকে), বিলিং ও শিপিং ঠিকানা, এবং place of supply সংকেত। এই স্ন্যাপশট পরিবর্তন করা উচিত না এমনকি প্রোডাক্ট প্রাইস বা HSN ম্যাপিং পরে বদলে গেলেও।
স্ন্যাপশট থেকে ট্যাক্স গণনা করে ইনভয়েস লাইন জেনারেট করুন। প্রতিটি ইনভয়েস লাইন ঐ মুহূর্তে HSN/SAC, ট্যাক্স রেট(গুলি), taxable value, এবং ব্যবহৃত ট্যাক্স এমাউন্ট কপি করবে, লাইভ পরে লুকআপ করার পরিবর্তে।
ইনভয়েস নম্বর ও ইস্যু তারিখ নির্ধারণ করুন, তারপর ইনভয়েসকে issued হিসেবে মার্ক করুন। এই পয়েন্ট থেকে ইনভয়েস রেকর্ডে প্রাইসিং, ট্যাক্স রেট, HSN কোড, এবং ঠিকানায় সম্পাদনা ব্লক করুন। যদি কিছু অনুমোদন দিতে হয়, সেটি সীমাবদ্ধ করুন কেবল নন-ফাইন্যান্সিয়াল নোট ও আভ্যন্তরীণ ট্যাগ পর্যন্ত।
জারি ইনভয়েস থেকে PDF/প্রিন্ট ভিউ জেনারেট করুন, তারপর রিপোর্ট করার জন্য চূড়ান্ত মোটগুলো সংরক্ষণ করুন: taxable total, CGST/SGST/IGST মোট, রাউন্ডিং, ও গ্র্যান্ড টোটাল। অতিরিক্ত নিরাপত্তা চাইলে ডকুমেন্ট ভার্সন বা চেকসাম সংরক্ষণ করুন যাতে আপনি প্রিন্টআউট এবং সংরক্ষিত সংখ্যাগুলোর মিল প্রমাণ করতে পারেন।
ইস্যুর পরে পরিবর্তনগুলো নিয়ম অনুযায়ী হওয়া উচিত, সরাসরি এডিট পড়ার পরিবর্তে:
আপনি যদি এই ফ্লোকে আপনার অ্যাডমিন স্ক্রিনে বিল্ড করেন (Koder.ai-এর Planning Mode মানচিত্রটি আগেভাগে স্টেপগুলো স্কেচ করতে সহায়ক), আপনার টিম দ্রুত ইনভয়েস জেনারেট করতে পারবে বিনা রিকনসিলিয়েশন ভাঙবার।
রিকনসিলিয়েশন জটিল হয়ে যায় যখন পেমেন্টগুলোকে অর্ডারের উপর একটি "paid/unpaid" ফ্ল্যাগ হিসেবে দেখা হয়। পেমেন্ট ও রিফান্ড আলাদা রেকর্ড রাখুন যা অর্ডার ও ইনভয়েসকে পয়েন্ট করে, যাতে ফাইন্যান্স ব্যাংক সেটেলমেন্ট মিলাতে পারে ইতিহাস না মুছেই।
একটি কনপ্লায়েন্ট ইনভয়েস ইস্যুর পরে স্থিতিশীল থাকা উচিত। যদি গ্রাহক কিস্তিতে পে করে, বা পরে রিফান্ড করা হয়, সেই মুভমেন্ট পেমেন্ট বা রিফান্ড এন্ট্রি হিসেবে রেকর্ড করুন, ইনভয়েস মোট পরিবর্তন করে না।
রিকনসিলিয়েশন সহজ করতে সাধারণত দরকারি ফিল্ড:
যদি গ্রাহক একটি আইটেম ফিরিয়ে দেয়, ইনভয়েস "কমিয়ে" দেবেন না। মূল ইনভয়েসটি লিঙ্ক করে ক্রেডিট নোট ইস্যু করুন। ইনভয়েস রেজিস্টার পরিষ্কার থাকবে এবং রিফান্ড ক্রেডিট নোটের সাথে টিকে থাকবে।
ফাইন্যান্সকে এমন একটি সিংগেল স্ক্রিন দিন যা উত্তর দেয়: কী ইস্যু হয়েছে, কী পে হয়েছে, কী খোলা আছে, এবং কী উল্টানো হয়েছে। এতে ageing (0-7, 8-30, 31-60, 60+ দিন) এবং সংশ্লিষ্ট পেমেন্ট ও রিফান্ড এন্ট্রিগুলোর ড্রিল-ডাউন রাখুন।
মাসিকভাবে বেশিরভাগ টিম যে এক্সপোর্টগুলো প্রয়োজন:
উদাহরণ: একটি অর্ডার Rs 10,000, আজ Rs 6,000 পে করা হয় এবং পরের সপ্তাহে Rs 4,000। ইনভয়েস থাকবে Rs 10,000। আপনার ফাইন্যান্স ভিউ দেখাবে ব্যালান্স Rs 4,000 যতক্ষণ না দ্বিতীয় সেটেলমেন্ট আসে, তারপর তা পুরো পেমেন্ট হিসেবে চিহ্নিত হবে পরিবর্তন না করে।
অধিকাংশ GST চালান সমস্যা "ট্যাক্স লজিক" সমস্যা নয়। এগুলো রেকর্ড-কিপিং সমস্যা: PDF-এ থাকা সংখ্যা ফাইন্যান্স এক্সপোর্টের সাথে মেলে না, অথবা ইনভয়েস পরে বোঝানো যায় না।
প্রথম ফাঁদ হলো ভিউ করার সময়ই GST গণনা করা। যদি আপনি CGST/SGST/IGST প্রতিবার ইনভয়েস খোলার সময় গণনা করেন, একটি দিন পরে রেট পরিবর্তন, রাউন্ডিং পরিবর্তন বা বাগ ফিক্সের কারণে ফলাফল ভিন্ন হবে। ইনভয়েস ইস্যুর সময় ব্যবহার করা ট্যাক্স ব্রেকডাউনটি সংরক্ষণ করুন, যদিও আপনি ইনপুটগুলোও সংরক্ষণ করেন।
একটি দ্বিতীয় ফাঁদ হলো ইস্যুকৃত ইনভয়েস এডিট করা। একবার ইনভয়েস চূড়ান্ত হলে পরিবর্তনগুলো ক্রেডিট নোট বা রিপ্লেসমেন্ট ফ্লোয়ের মাধ্যমে হওয়া উচিত, সরাসরি এডিট করে নয়। নচেৎ আপনি দেখবেন "কেন কাস্টমারের PDF বইয়ের সাথে আলাদা?"—এরকম তর্ক।
নিচে এমন মismatch প্যাটার্নগুলো দিলাম যা সবচেয়ে বেশি দেখা যায়:
একটি দ্রুত উদাহরণ: আপনি Karnataka-র একজন কাস্টমারে বিক্রি করেন, কিন্তু শিপিং ঠিকানা Maharashtra-তে। যদি আপনার সিস্টেম ভুল করে billing state কে place of supply হিসেবে নেয়, আপনি CGST+SGST চার্জ করতে পারেন IGST এর বদলে। যদি আপনি পরে লাইভে ট্যাক্স পুনর্গণনা করেন, ঐ ভুলটা নিরবে পরে "স্বয়ংক্রিয়ভাবে ঠিক" হয়ে যেতে পারে, ফলে ফাইন্যান্সের সামনে সংখ্যাগুলো ইনভয়েসের সাথে মেলে না।
যখন আপনি অ্যাডমিন স্ক্রিন বানাবেন (কাস্টম বা Koder.ai-এর মাধ্যমে), ছোট গার্ডরেইল যোগ করুন: ইস্যুকৃত ইনভয়েস লক করুন, place-of-supply ইনপুট পাশে প্রদর্শন করুন যাতে ব্যবহারকারী ট্যাক্স টাইপ দেখেন, এবং ইস্যু সময়ে ব্যবহৃত HSN, রেট ও রাউন্ডিং-র immutable স্ন্যাপশট রাখুন।
কাস্টমারকে ইনভয়েস পাঠানোর বা এটিকে "issued" চিহ্ন করার আগে দ্রুত কিছু চেক চালান। ছোট ভুলগুলোই পরবর্তীতে বড় রিকনসিলিয়েশন মাথাব্যথা তৈরি করে। যদি আপনি একটি GST চালান ডেটা মডেল বানাচ্ছেন, এই চেকগুলো ভ্যালিডেশন রুল ও অ্যাডমিন UI-তে বেক করা মূল্যবান।
একটি সরল উদাহরণ: গ্রাহক পেমেন্ট করার পরে তাদের শিপিং ঠিকানা আপডেট করে এবং স্টেট বদলে যায়। আপনি যদি একই ইনভয়েস নম্বর পুনরায় ইস্যু করে নতুন ট্যাক্স প্রয়োগ করেন, আপনার রেজিস্টার ও পেমেন্ট রেকর্ড মিল বন্ধ করে দেবে। নিরাপদ উপায় হল মূল ইনভয়েস অপরিবর্তিত রাখা এবং সামঞ্জস্য ডকুমেন্ট তৈরি করা।
পরবর্তী ধাপ: প্রথমে স্ক্রিন ও ভ্যালিডেশনগুলো ইমপ্লিমেন্ট করুন, তারপর পুনরাবৃত্তি করুন। Koder.ai-তে Planning Mode ব্যবহার করে records ও অ্যাডমিন স্ক্রিন (প্রোডাক্টের HSN/SAC ম্যাপিং, কাস্টমার/GSTIN ডিটেইল, ট্যাক্স রুল, ইনভয়েস) স্কেচ করুন। অ্যাপ জেনারেট করুন, কয়েকটি বাস্তব অর্ডার এন্ড-টু-এন্ড টেস্ট করুন, তারপর স্ন্যাপশট ও রোলব্যাক ব্যবহার করে সেফ ভাবে ওয়ার্কফ্লো পরিমার্জান করুন। যখন ডিপার কাস্টমাইজেশন দরকার পড়বে, সোর্স কোড এক্সপোর্ট করে আপনার স্বাভাবিক প্রক্রিয়ায় সেটি বিকাশ করুন।