১৪ জানু, ২০২৬·8 মিনিট পড়তে

সাবস্ক্রিপশন বনাম ব্যবহারভিত্তিক বিলিং: প্রথম দিন থেকে কী সংরক্ষণ করবেন

Q: Why does my pricing model affect what data I need to store?

Start by deciding what you need to prove later: *why* a customer was charged that amount. Subscriptions need plan, period, and entitlement history; usage needs an immutable record of what happened, when, and under which pricing rules.

ডেটা-মডেলিং দৃষ্টিকোণ থেকে সাবস্ক্রিপশন বনাম ব্যবহারভিত্তিক বিলিং: মিটার, লিমিট, ইনভয়েস, প্রোরেশন এবং প্রথম দিন থেকেই কোন রেকর্ড রাখা উচিত তা ব্যাখ্যা করা।

কেন মূল্য নির্ধারণ মডেলগুলোর জন্য ডাটা প্ল্যান দরকার

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

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

পরবর্তীতে ব্যবহার যোগ করলে পরিকল্পনা না করলে সাধারণত তিনটি জায়গায় সমস্যা হয়:

বিশ্বস্ত ব্যবহার ইতিহাস নেই, ফলে গ্রাহক চার্জ বিতর্ক করে।
আপনার অ্যানালিটিক্স অনুমানমুলক হয়ে যায় কারণ টিমগুলো "ব্যবহার" ভিন্নভাবে নির্ধারণ করে।
ফাইন্যান্স চালান অডিট করতে পারে না কারণ কাঁচা ইনপুট নেই বা ওভাররাইট করা হয়েছে।

লক্ষ্যটি বিরক্তিকর কিন্তু অপরিহার্য: প্রতিবার একইভাবে একই চালান হিসাব করা। এর মানে আপনি সংরক্ষিত তথ্য (প্ল্যান শর্তাবলী, মিটার নিয়ম, ব্যবহার ইভেন্ট এবং কোন মূল্য সংস্করণ প্রযোজ্য ছিল) থেকে হিসাবটি পুনরায় চালাতে পারবেন।

"মডেলিং ভিউ" বলতে বোঝায় বিলিংকে এমন বিল্ডিং ব্লক হিসেবে বর্ণনা করা যাতে তারা একসাথে মিলে, এমনকি আপনি ইঞ্জিনিয়ার না হলেও বোঝা যায়। একটি টিম চ্যাট প্রোডাক্ট কল্পনা করুন:

সাবস্ক্রিপশন: প্রতিটি ওয়ার্কস্পেস প্রতি মাসে $99
ব্যবহার: 50,000 বার্তা পার হওয়ার পর প্রতিটি বার্তা $0.01

পরে এটি সমর্থন করার জন্য আপনার ডেটা উত্তর দিতে হবে: কোন ওয়ার্কস্পেস, কোন মাস, কতটা বার্তা, কী অন্তর্ভুক্ত ছিল, এবং কোন মূল্য নিয়ম সক্রিয় ছিল।

সাবস্ক্রিপশন বনাম ব্যবহার: বাস্তবে কীভাবে তারা আলাদা

সাবস্ক্রিপশন অ্যাক্সেসের জন্য চার্জ করে। ব্যবহারভিত্তিক বিলিং ভোগের জন্য চার্জ করে। আপগ্রেড, ডাওনগ্রেড, প্রোরেশন এবং বাস্তব জটিলতা আসলে তাদের আচরণ ভিন্ন করে তোলে।

সাবস্ক্রিপশনের ক্ষেত্রে মূল প্রশ্ন হয়: "এই সময় গ্রাহক কি প্রোডাক্ট ব্যবহার করার যোগ্য ছিলেন?" আপনি সাধারণত প্ল্যান, সিট কাউন্ট, বিলিং পিরিয়ড এবং চালান পেয়েছেন কি না তা ট্র্যাক করেন। ব্যবহার এখনও গুরুত্বপূর্ণ, কিন্তু প্রায়ই এটি লিমিট হিসেবে (সফট বা হার্ড) দেখায় লাইন আইটেম হিসেবে নয়।

ব্যবহারভিত্তিক বিলিংয়ের ক্ষেত্রে মূল প্রশ্ন হয়: "ঠিক কী ঘটল, এবং কখন?" আপনাকে নির্ভরযোগ্য মিটারিং, স্পষ্ট নিয়ম কখন ব্যবহার গণনা করা হয়, এবং প্রতিটি চার্জ পরে ব্যাখ্যা করার উপায় দরকার। এমনকি যদি UI এক সংখ্যা দেখায় (যেমন "1,243 API calls"), তবুও পিছনে এক সেট ইভেন্ট থাকে যা সঙ্গতিপূর্ণ এবং অডিটযোগ্য হতে হবে।

অনেক B2B SaaS টিম হাইব্রিড মূল্য নির্ধারণে আসে: একটি বেস ফি যা একটি বান্ডেল কভার করে, এবং অতিরিক্ত ব্যবহারের জন্য চার্জ।

সাধারণ হাইব্রিড প্যাটার্ন

অধিকাংশ হাইব্রিড মডেল কয়েকটি পরিচিত আকারে পড়ে:

বেস প্ল্যাটফর্ম ফি প্লাস প্রতি সিট ফি
বেস ফি প্লাস অন্তর্ভুক্ত ইউনিট (বার্তা, টাস্ক, API কল) এবং একটি অভারেজ রেট
টিয়ার্ড প্ল্যান প্লাস একটি ব্যবহার অ্যাড-অন (শুধু সক্রিয় থাকলে চার্জ হয়)
মিনিমাম কমিট সহ ব্যবহার ক্রেডিট ড্রাউন

গ্রাহক যখন বাজেট অনুমোদন দরকার বা স্থির মাসিক ব্যয়ের দরকার হয় তখন পূর্বনির্ধারণ সহজ হয়। পে-অ্যাস-ইউ-গো ভাল কাজ করে যখন মূল্য কার্যকলাপের সাথে স্কেল করে (উদাহরণ: "প্রতি চালান প্রক্রিয়াকৃত") অথবা যখন গ্রাহক আপনাকে ট্রায়াল করছেন এবং কম ঝুঁকি চান।

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

এমন মিটার নির্ধারণ করুন যা নির্ভরযোগ্যভাবে পরিমাপ করা যায়

মিটার হলো সেই সুনির্দিষ্ট জিনিসটির নাম যার জন্য আপনি চার্জ করেন, এটাকে স্পষ্টভাবে লিখে রাখুন যাতে দুইজন গেনা করলে একই ফল পায়। এটির তিনটি অংশ আছে: ইভেন্ট (কি ঘটল), ইউনিট (কি গোনা হচ্ছে), এবং টাইমিং (কখন এটি গোনা হয়)।

অধিকাংশ বিতর্ক এখান থেকেই শুরু হয়। একপাশ মনে করে তারা আউটকমের জন্য পে করছে, অন্যপাশ পরিমাপযোগ্য কার্যকলাপের জন্য চার্জ করছে।

মিটারকে অস্পষ্টতাহীন করুন

এমন মিটার বাছুন যা বাস্তব প্রোডাক্ট ক্রিয়াকলাপের সাথে মেলে এবং স্বয়ংক্রিয়ভাবে রেকর্ড করা যায়। সাধারণ উদাহরণ:

সিট (অ্যাক্টিভ ইউজার যারা লগইন করতে পারে)
API কল (সফল রিকুয়েস্ট, বা সব রিকুয়েস্ট)
স্টোরেজ (নির্দিষ্ট এক্ষণে GB, বা একটি সময়ের গড়)
বার্তা (পাঠানো, পৌঁছানো, বা খোলা)
কম্পিউট মিনিট (কোন কাজ কতক্ষণ চালিত হয়)

তারপর নির্ধারণ করুন কী গন্য হবে এবং কী হবে না। যদি আপনি প্রতি API কল চার্জ করেন, সিদ্ধান্ত নিন কি রিট্রাই কনট করবে, 4xx এবং 5xx রেসপন্সগুলি গননা হবে কি, এবং আপনার নিজস্ব ইন্টিগ্রেশনের অভ্যন্তরীণ কলগুলি গননা হবে কি না।

টাইমিং ইউনিটের মতোই গুরুত্বপূর্ণ। সিট সাধারণত পয়েন্ট-ইন-টাইম স্ন্যাপশট হিসেবে প্রতি বিলিং পিরিয়ডে ভালো কাজ করে। API কল সাধারণত একটি উইন্ডোতে যোগ হয়। স্টোরেজ জটিল: গ্রাহকরা সাধারণত "আপনি কত স্টোর করেছেন" এর উপর পে করতে চান, যা সাধারণত সময়ের গড় বোঝায়, পিক নয়।

স্কোপও নির্ধারণ করুন: অ্যাকাউন্ট-ভিত্তিক, বা ওয়ার্কস্পেস/প্রজেক্ট-ভিত্তিক। সহজ নিয়ম: যদি টিমগুলো আলাদাভাবে বিল করা যায়, মিটারগুলো হওয়া উচিত ওয়ার্কস্পেস-ভিত্তিক।

লিমিট, টিয়ার, এবং entitlements

Entitlements হল নিয়মগুলো যা নির্ধারণ করে গ্রাহক তাদের কেনা অনুযায়ী কী করতে পারবে। তারা উত্তর দেয়: কতজন ব্যবহারকারী যোগ করতে পারবে? কোন ফিচার সক্রিয়? প্রতি মাসে কোন ভলিউম অনুমোদিত? Entitlements অ্যাক্সেস এবং বিলিংয়ের মাঝে অবস্থান করে: তারা প্রোডাক্ট কি অনুমতি দেয় তা নির্ধারণ করে, যখন মিটারিং কী ঘটেছে তা রেকর্ড করে।

Entitlements কে মিটারিং লজিক থেকে আলাদা রাখুন। Entitlements পড়তে সহজ এবং স্থিতিশীল হওয়া উচিত (প্ল্যান, অ্যাড-অন, কন্ট্রাক্ট শর্ত)। মিটারিং পণ্য পরিবর্তিত হওয়ার সাথে বিবর্তিত হবে (নতুন ইভেন্ট, নতুন মিটার), এবং আপনি চান না প্রতিটি মিটার পরিবর্তন অ্যাক্সেস ভাঙিয়ে দেয়।

হার্ড লিমিট, সফট লিমিট, এবং ওভারেজ বিলিং UI-তে একইরকম দেখতে পারে, কিন্তু আচরণ ভিন্ন:

হার্ড লিমিট কেপ থেকে পরে অ্যাকশন ব্লক করে।
সফট লিমিট সতর্ক করে কিন্তু অনুমোদন দেয়।
ওভারেজ বিলিং অ্যাকশন অনুমোদন করে এবং অতিরিক্ত চার্জ করে।
গ্রেস পিরিয়ড সাময়িকভাবে হার্ড লিমিটকে সফট লিমিটের মতো আচরণ করে।
ট্রায়াল এবং ফ্রি টিয়ার entitlements দেয়, কিন্তু মূল্য আলাদা (কয়েক সময় শূন্য) কোন তারিখ বা থ্রেশহোল্ড পর্যন্ত।

এর মানে আগে থেকেই সিদ্ধান্ত নিন লিমিট লঙ্ঘনের সময় কী হবে। উদাহরণ: "স্টার্টার" টিয়ারে 5 সিট এবং মাসে 10,000 API কল অন্তর্ভুক্ত। যদি তারা 6ষ্ঠ ব্যবহারকারী আমন্ত্রণ করে, আপনি কি ব্লক করবেন, অতিরিক্ত সিটের জন্য চার্জ শুরু করবেন, না 7 দিন গ্রেস দেবেন? প্রতিটি পছন্দের জন্য এমন একটি নিয়ম দরকার যা চালান এবং সাপোর্ট লগে দেখানো যায়।

Entitlements কে টাইম-বাউন্ড রেকর্ড হিসেবে সংরক্ষণ করুন: গ্রাহক, প্ল্যান বা অ্যাড-অন, শুরু এবং শেষ টাইমস্ট্যাম্প, লিমিট মান, এবং প্রয়োগ মোড (হার্ড, সফট, ওভারেজ)। এটি অ্যাক্সেস সিদ্ধান্ত এবং বিলিং সিদ্ধান্তকে সঙ্গত রাখে।

আপনি অডিট করতে পারবেন এমন ইনভয়েস এবং বিলিং পিরিয়ড

Move fast without tech debt

Use visual tools to ship billing screens fast and keep clean code generation.

Build in Hours

একটি চালান শুধুই PDF নয়। এটি একটি অডিট ট্রেইল যা উত্তর দেয়: কার কাছে বিল করা হয়েছে, কোন কারণে, কোন তারিখের জন্য, কোন নিয়মের অধীনে। যদি আপনি মূল্য পরিবর্তন করেন, তাহলে আপনাকে পুরোনো ইনভয়েস একইভাবে পুনরায় তৈরি করতে সক্ষম হতে হবে।

কয়েকটি মূল রেকর্ড দিয়ে শুরু করুন: Customer, Subscription (বা Contract), Billing Period, এবং Invoice with Line Items। প্রতিটি লাইন আইটেমকে তার উৎসে পয়েন্ট করুন: একটি প্ল্যান ফি, একটি ব্যবহার সারমর্ম, বা একটি এককালীন চার্জ। সেই লিংকই বিলিং ব্যাখ্যাযোগ্য করে যখন কেউ চার্জ বিতর্ক করে।

বিলিং পিরিয়ডের জন্য একটি অ্যাঙ্কর এবং টাইমজোন দরকার। "মাসিক" যথেষ্ট নয়। সাইকেল অ্যাঙ্কর তারিখ সংরক্ষণ করুন (উদাহরণ: 15 তারিখ 00:00) এবং ব্যবহৃত টাইমজোন। এটি ধারাবাহিক রাখুন না হলে ডেলাইট সেভিং সময়ের চারপাশে একদিনের ত্রুটি হবে।

অডিটযোগ্য ইনভয়েস সাধারণত প্রয়োজন করে:

প্রতিটি ইনভয়েস এবং লাইন আইটেমে period_start এবং period_end
যে মূল্য সংস্করণ (plan/price IDs) ওই ইনভয়েসে ব্যবহার হয়েছে
অপরিবর্তনীয় টোটাল: subtotal, tax, discounts, amount_due, currency
যে কোন ব্যবহারভিত্তিক লাইন আইটেমের সঠিক ব্যবহার উইন্ডো
প্রয়োজনে বাহ্যিক পেমেন্ট রেফারেন্স (প্রসেসর চার্জ আইডি)

রাজস্ব স্বীকৃতি চার্জিং-এর সমান নয় কিন্তু সম্পর্কিত। প্রিপেইড সাবস্ক্রিপশন ফি সাধারণত সার্ভিস পিরিয়ড জুড়ে স্বীকৃত হয়, যখন ব্যবহার সাধারণত ডেলিভারি মুহূর্তে স্বীকৃত হয়। এমনকি যদি আপনি এটি উচ্চ-স্তরের রাখেন, পরে সহায়তার জন্য পর্যাপ্ত তারিখ সংরক্ষণ করুন।

ক্রেডিট নোট, রিফান্ড এবং অ্যাডজাস্টমেন্টকে প্রথম-শ্রেণীর রেকর্ড হিসেবে বিবেচনা করুন, কখনো পুরোনো ইনভয়েস সম্পাদনা হিসেবে নয়। যদি একটি গ্রাহক মিড-সাইকেলে আপগ্রেড করে, একটি অ্যাডজাস্টমেন্ট লাইন বা ক্রেডিট নোট তৈরি করুন যা মূল ইনভয়েসকে রেফার করে এবং ব্যবহৃত প্রোরেশন নিয়মটি উল্লেখ করে।

আইডেম্পটেনসি কী ইনভয়েস জেনারেশন এবং পেমেন্ট প্রচেষ্টার জন্য গুরুত্বপূর্ণ। যদি একটি জব দুইবার চলে, আপনি চান একটি ইনভয়েস, একটি চার্জ, এবং পরিষ্কার লগ।

প্রোরেশন এবং মিড-সাইকেল পরিবর্তন

Handle proration with clarity

Model upgrades and downgrades as explicit credits and debits tied to change events.

Add Proration

মিড-সাইকেল পরিবর্তনেই বিলিং বিতর্ক শুরু হয়। যদি কেউ 20 তারিখে আপগ্রেড করে, 7 দিনের জন্য পজ করে, তারপর বাতিল করে, আপনাকে এই কর্মগুলোকে এমন সংখ্যায় রূপান্তর করার নিয়ম দরকার যা চালানে মানানসই হয়।

নির্ধারণ করুন আপনি কী পরিবর্তন অনুমোদন করবেন এবং কখন তারা কার্যকর হবে। বহু টিম আপগ্রেডগুলি ম sofort প্রযোজ্য করে যাতে গ্রাহক অবিলম্বে মূল্য পায়, কিন্তু ডাওনগ্রেড রিনিউয়ালে প্রয়োগ করে যাতে জটিল রিফান্ড এড়ানো যায়।

এমন একটি প্রোরেশন নীতি বেছে নিন যা আপনি ব্যাখ্যা করতে পারবেন

প্রোরেশন দৈনিক, ঘণ্টাভিত্তিক, বা না-ও হতে পারে। যত বেশি সূক্ষ্ম আপনি হন, তত বেশি টাইমস্ট্যাম্প, রাউন্ডিং নিয়ম, এবং এজ-কেস সংরক্ষণ করতে হবে এবং টেস্ট করতে হবে।

নীতিগুলো আগে লক করুন:

আপগ্রেড তাত্ক্ষণিক প্রোরেট করুন, ডাওনগ্রেড রিনিউয়ালে পিছিয়ে দিন
দৈনিক প্রোরেশন ব্যবহার করুন (ঘণ্টার চেয়ে সাধারণত সহজ এবং যথেষ্ট ন্যায়সঙ্গত)
রাউন্ডিং নিয়ম নির্ধারণ করুন (উদাহরণ: নিকটতম সেন্টে রাউন্ড আপ)
পজ কিভাবে কাজ করে তা সিদ্ধান্ত নিন (সময় ক্রেডিট করুন, না হলে পিরিয়ড বাড়ান)
বাতিলের জন্য স্পষ্ট রিফান্ড নীতি নির্ধারণ করুন (পূর্ণ, আংশিক, না কোনো)

প্রোরেশনকে ইনভয়েস লাইন আইটেম হিসেবে মডেল করুন

গোপন গণিত এড়িয়ে চলুন। প্রোরেশনকে ইনভয়েসে স্পষ্ট অ্যাডজাস্টমেন্ট হিসেবে উপস্থাপন করুন, যেমন নতুন প্ল্যানের বাকি সময়ের জন্য ডেবিট এবং পুরানো প্ল্যানের অব্যবহৃত সময়ের জন্য ক্রেডিট। প্রতিটি লাইন আইটেমটি যেই পরিবর্তন ইভেন্ট করেছে সেটির (change_id) রেফারেন্স থাকা উচিত এবং প্রোরেশন উইন্ডো (start_at, end_at), পরিমাণ/সময় ভিত্তি, এবং ট্যাক্স ক্যাটেগরি অন্তর্ভুক্ত করা উচিত।

ব্যবহার মিটারগুলো একটি আরেকটি সিদ্ধান্ত যোগ করে: যখন প্ল্যান পরিবর্তিত হয়, মিটারগুলো রিসেট হবে কি, আরও জমা হবে কি, না ভাগ করা হবে? একটি সরল, অডিটযোগ্য পদ্ধতি হলো মেয়াদভিত্তিক পরিকল্পনা দ্বারা ব্যবহার ভাগ করা। উদাহরণ: গ্রাহক মাঝামাঝি মাসে 10 সিট থেকে 25 সিটে আপগ্রেড করে। আপনি ব্যবহার ইভেন্টগুলো যেমন আছে ছেড়ে দেন, কিন্তু রেটিং তাদের সেই সময় সক্রিয় entitlement পিরিয়ড দ্বারা গ্রুপ করে।

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

প্রথম দিন থেকেই যে ডেটা আপনাকে সংরক্ষণ করতে হবে

যদি আপনি গ্রাহক অভিযোগ হওয়ার পর বিলিং ডেটা ডিজাইন করার জন্য অপেক্ষা করেন, আপনি অনুমান করার পথে যাবেন। আপনি সাবস্ক্রিপশন, ব্যবহার, বা হাইব্রিড কোন মডেলই বাছুন না কেন, নিরাপদ শুরু হল এমন কিছু রেকর্ড রাখা যা পরে সবসময় অডিট করা যাবে।

স্পষ্ট গ্রাহক হায়ারার্কি দিয়ে শুরু করুন। B2B SaaS-এ, পেয়ার সাধারণত একটি কোম্পানি একাউন্ট, কিন্তু ব্যবহার প্রায়ই ওয়ার্কস্পেস বা প্রজেক্টের ভিতরে ঘটে, এবং অ্যাকশানগুলো ব্যক্তিগত ইউজার থেকে আসে। তিনটি স্তরই (অ্যাকাউন্ট, ওয়ার্কস্পেস, ইউজার) সংরক্ষণ করুন এবং কি করেছে তা রেকর্ড করুন। বিলিং বিতর্ক প্রায়ই হয়ে ওঠে "এটি কোন টিম করেছে?"।

একটি ন্যূনতম বিলিং ডাটাবেস ডিজাইন যা বাস্তব ইনভয়েস এবং পরিষ্কার তদন্ত সমর্থন করে:

অ্যাকাউন্ট এবং অর্গ কাঠামো: account, workspace (বা project), users, roles, billing contact, এবং ট্যাক্স ফিল্ড প্রয়োজনে
সাবস্ক্রিপশন: প্ল্যান, স্ট্যাটাস, শুরু/শেষ তারিখ, রিনিউয়াল সেটিংস, বাতিলের কারণ, এবং শুরুতে প্রয়োগ করা মূল্য সংস্করণ
প্রাইস ক্যাটালগ: products, plan components (base fee, seats, meters), tiers, currency, এবং কার্যকর তারিখ
ব্যবহার মিটারিং ডেটা: টাইমস্ট্যাম্প, ওয়ার্কস্পেস, ইউজার (যদি পাওয়া যায়), মিটার নাম, পরিমাণ, এবং একটি ইউনিক idempotency কী সহ অপরিবর্তনীয় অ্যাপেন্ড-ওনলি ইভেন্ট লোগ
ইনভয়েস আর্টিফ্যাক্টস: বিলিং পিরিয়ড বাউন্ডারি, লাইন আইটেম, টোটাল, ট্যাক্স/ডিসকাউন্ট অ্যাডজাস্টমেন্ট, এবং ব্যবহৃত ইনপুটগুলির স্ন্যাপশট

শুধু aggregated কাউন্টারগুলোর উপর নির্ভর করবেন না। গতি জন্য কাউন্টার রাখুন, কিন্তু ইভেন্ট লোগকে ট্রুথ সোর্স হিসেবে রাখুন। একটি সহজ নিয়ম: ইভেন্টগুলো অপরিবর্তনীয়, সংশোধনী নতুন ইভেন্ট (উদাহরণ: নেতিবাচক পরিমাণ), এবং প্রতিটি ইভেন্ট একটি নির্দিষ্ট মিটার ডেফিনিশনের সাথে টাইট করা।

উদাহরণ: একটি গ্রাহক বলে তাদের "API calls" গত মাসে দ্বিগুণ হয়েছিল। আপনি যদি ওয়ার্কস্পেস ও দিনে কাঁচা ইভেন্ট টেনে দেখাতে পারেন, আপনি জানাতে পারবেন কোথা থেকেই স্পাইক এসেছে বা কোনো ইন্টিগ্রেশন লুপ আছে কি না।

ধাপে ধাপে: ব্যবহার ইভেন্ট থেকে ইনভয়েস পর্যন্ত

Launch a simple billing portal

Show customers plan details, usage to date, and past invoices in one place.

Build Portal

কঠিন অংশটি গণিত নয়। এটা হলো ফলাফলটি মাস পরে ব্যাখ্যাযোগ্য করা, এমনকি প্ল্যান, দাম এবং গ্রাহক বদলে গেলে ও।

1) সময় ভ্রমণ করতে পারে এমন একটি প্রাইস ক্যাটালগ দিয়ে শুরু করুন

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

উদাহরণ: "API Calls" 1 এপ্রিল থেকে প্রতি কল $0.002। মার্চ ইনভয়েসগুলিকে পুরোনো রেট ব্যবহার করে আবার চালাতে হবে।

2) পিরিয়ডের সময় গ্রাহক কী অধিকারী ছিল তার স্ন্যাপশট নিন

প্রতি বিলিং পিরিয়ডের শুরুতে (বা যখন কোনো পরিবর্তন ঘটে) একটি entitlement স্ন্যাপশট সংরক্ষণ করুন: প্ল্যান, অন্তর্ভুক্ত ইউনিট, লিমিট, টিয়ার নিয়ম, ডিসকাউন্ট, এবং ট্যাক্স সেটিংস। এটা ভাবুন "এই পিরিয়ডের জন্য আমরা কী প্রতিশ্রুতি দিয়েছি"।

3) ব্যবহার ইভেন্ট গ্রহণ করুন এবং আগে যাচাই করুন

ব্যবহার ইভেন্টগুলো অপরিবর্তনীয় হওয়া উচিত: টাইমস্ট্যাম্প, গ্রাহক, মিটার, পরিমাণ, এবং ডুপ্লিকেট বাঁচাতে একটি ইউনিক আইডি। দরজায় মৌলিক বৈধতা করুন (মিটার অনুপস্থিত, নেতিবাচক পরিমাণ, অসম্ভব টাইমস্ট্যাম্প) এবং কাঁচা ইভেন্ট রেকর্ড করুন এমনকি যদি আপনি ক্লিন করা সংস্করণও রাখেন।

তারপর গণনা দুই ধাপে করুন:

ইভেন্টগুলোকে গ্রাহক, মিটার, এবং বিলিং পিরিয়ড অনুযায়ী টোটালে একত্রিত করুন (এবং aggregation সংস্করণ রাখুন)
ক্যাটালগ এবং entitlement স্ন্যাপশট ব্যবহার করে টোটালগুলোকে চার্জে রেট করুন (অন্তর্ভুক্ত ইউনিট, ওভারেজ মূল্য, টিয়ার)

যেই ইনপুটগুলো ব্যবহার হয়েছে (ক্যাটালগ সংস্করণ, স্ন্যাপশট আইডি, aggregation আইডি) সেগুলোর রেফারেন্সসহ ইনভয়েস লাইন আইটেম তৈরি করুন।

পরিশেষে, ইনভয়েস লক করুন। হিসাবের ইনপুট এবং আউটপুট সংরক্ষণ করুন, এটিকে ফাইনাল চিহ্নিত করুন, এবং দেরিতে আগমণকারী ইভেন্ট এলে এটি পরিবর্তন করা থেকে বিরত রাখুন। দেরিতে আসা ইভেন্টগুলো পরের ইনভয়েসে (বা আলাদা অ্যাডজাস্টমেন্টে) যেতে পারে স্পষ্ট অডিট নোটসহ।

গ্রাহক এবং অভ্যন্তরীণ রিপোর্টিংয়ের প্রয়োজন

গ্রাহকরা পার্থক্য করে না আপনি সাবস্ক্রিপশন বেছে নেয়েছেন নাকি ব্যবহারভিত্তিক বিলিং; তারা চায় আপনার সংখ্যা তাদের নিজের সাথে মেলে, এবং তারা চাই যে তারা পরের চার্জটি পূর্বানুমান করতে পারে।

গ্রাহক-মুখী রিপোর্টিং একটি সহজ বিলিং হোম হিসেবে ভালো কাজ করে যা কয়েকটি প্রশ্নের উত্তর দেয় সাপোর্ট টিকেট ছাড়া:

আমি কোন প্ল্যানে আছি, এবং এতে কি অন্তর্ভুক্ত?
এই পিরিয়ডে আমি কতটি ব্যবহার করেছি, এবং ব্যবহার কিভাবে গণনা করা হয়?
আমার লিমিট কি, এবং লিমিট লঙ্ঘন হলে কী হয়?
বিলিং পিরিয়ড কখন শেষ হয়, এবং আমার অনুমিত পরবর্তী বিল কত হবে?
আমি কোথায় অতীত ইনভয়েস এবং পেমেন্ট দেখতে পারি?

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

বিল প্রিভিউকে ইনভয়েস থেকে আলাদা রাখুন। প্রিভিউ রিক্যালকুলেট করা যেতে পারে যখন দেরিতে ব্যবহার আসে বা আপনি মিটার ডেফিনিশন পরিমার্জনা করেন। ইনভয়েসগুলো পরিবর্তন করা ঠিক নয়।

আপনার অভ্যন্তরীণ রিপোর্টিং এমনভাবে রাখুন যাতে অস্বাভাবিকতা (হঠাৎ ব্যবহারের ঝাঁকুনি, নেতিবাচক ব্যবহার, ডুপ্লিকেট ইভেন্ট) চিহ্নিত করা সহজ হয়, কাঁচা ব্যবহার এবং নিয়ম থেকে একটি ইনভয়েস লাইন আইটেম পুনরায় তৈরি করা যায়, এবং পিরিয়ডের প্ল্যান পরিবর্তন ও ইনভয়েস প্রোরেশন নিয়ম দেখা যায়।

অডিট ট্রেইল অনেক বেশি গুরুত্বপূর্ণ তার চেয়েও যা টিমগুলো আশা করে। যদি গ্রাহক বলে, "আমরা 12 তারিখে আপগ্রেড করেছিলাম," আপনার কাছে টাইমস্ট্যাম্প, কার্যকারী (ইউজার, অ্যাডমিন, অটোমেশন), এবং প্ল্যান, সিট, লিমিট, এবং মিটার রেটের সঠিক আগে/পরে মান থাকা দরকার।

রিটেনশনের জন্য, কাঁচা ব্যবহার ইভেন্ট এবং ফাইনালাইজড ইনভয়েস আর্টিফ্যাক্ট দীর্ঘমেয়াদে রাখুন। একটি বাস্তবিক নিয়ম: যদি এটি চার্জ পরিমাণ পরিবর্তন করতে পারে বা বিতর্কে রক্ষা করতে পারে, সেটি অপরিবর্তনীয়ভাবে সংরক্ষণ করুন।

সাধারণ ফাঁক যা বিলিং বিতর্ক সৃষ্টি করে

Prototype your pricing model

Test subscription, usage, or hybrid pricing by versioning your price catalog early.

Prototype Now

বেশিরভাগ বিলিং বিতর্ক দামকে ঘিরে নয়। তারা ঘটে যখন আপনি কোনো ইনভয়েসের একটি সংখ্যাকে ব্যাখ্যা করতে পারেন না, বা একই ইনপুট পরে ভিন্ন মোট ফল দেয়।

একটি সাধারণ ভুল শুধু মাসিক টোটাল রাখা। কাঁচা ইভেন্ট না রাখলে, আপনি সহজ প্রশ্নের উত্তর দিতে পারবেন না যেমন "কোন দিন আমাদের সীমা অতিক্রম করিয়েছে?" ইভেন্ট রাখুন, তারপর এটিকে অ্যাগ্রিগেট করুন।

আর একটি সমস্যা হল মিটার অর্থ বদলে দেওয়া কিন্তু সেটি ট্র্যাক না করা। "অ্যাক্টিভ ইউজার" শুরুতে হতে পারে "কমপক্ষে একবার লগইন করা" এবং পরে হতে পারে "একটি রেকর্ড তৈরি করেছে"। যদি আপনি মিটার ডেফিনিশন ভের্সন না করেন, গ্রাহকরা পুরোনো ইনভয়েসকে নতুনগুলোর সাথে তুলনা করবে এবং আপনি প্রমাণ করতে পারবেন না কোন নিয়ম প্রয়োগ হয়েছে।

বিতর্ক প্রায়ই একই কয়েকটি প্যাটার্ন থেকে আসে:

entitlements শুধু UI-তে প্রয়োগ করা (ব্যাকএন্ড এখনও অতিরিক্ত ব্যবহার অনুমোদন করে বা বৈধ ব্যবহার ব্লক করে)
সবকিছুর জন্য একটাই টাইমস্ট্যাম্প ব্যবহার (ইভেন্ট টাইম, ইনজেস্ট টাইম, বিলিং পিরিয়ড সময়)
টাইমজোন উপেক্ষা করা (স্থানীয় সময় 00:30-এ ব্যবহার ভুল দিন/মাসে যায়)
বিলিং অ্যাঙ্কর ভুলে যাওয়া (কিছু গ্রাহক 1 তারিখে বিল পায়, অনেকে সাইনআপ দিনের উপর)
প্ল্যান, মূল্য, এবং লিমিট পরিবর্তনের অডিট ট্রেইল নেই

উদাহরণ: টোকিওর একজন গ্রাহক মাঝামাঝি সাইকেলে 31 তারিখে আপগ্রেড করে। যদি আপনি শুধুমাত্র UTC টাইমস্ট্যাম্প সংরক্ষণ করেন এবং কোনো বিলিং অ্যাঙ্কর না রাখেন, তাহলে আপগ্রেডটি আপনার সিস্টেমে 30 তারিখ বলে দেখাতে পারে, প্রোরেশন এবং ব্যবহার ভুল পিরিয়ডে পড়ে যাবে।

বিশ্বাস হারানোর দ্রুততম উপায় হল কোনো পুরোনো ইনভয়েস গণনা পুনরুত্পাদন করার উপায় না থাকা। ইনপুটগুলো (ইভেন্ট, সংস্করণ, অ্যাঙ্কর, এবং প্রয়োগকৃত দাম) সংরক্ষণ করুন যাতে আপনি একই লজিক পরে চালিয়ে একই ফল পান, এমনকি আপনার প্রোডাক্ট বদলে গেলেও।

চালান চালানোর আগে দ্রুত চেকলিস্ট

Design billing data in AppMaster

Model plans, meters, and invoices in a PostgreSQL schema you can audit later.

Start Building

লঞ্চের আগে একটি ড্রিল করুন: একটি র‍্যান্ডম গ্রাহক নিন এবং কেবল সংরক্ষিত ডেটা ব্যবহার করে তাদের শেষ ইনভয়েস পুনরায় তৈরি করুন। যদি আপনাকে দরকার হয় "যা তখন কোড করেছিল" তবেই, আপনার কাছে অডিট ট্রেইল নেই।

প্রতিটি মিটার অস্পষ্টতাহীন কিনা নিশ্চিত করুন। একটি মিটারের স্পষ্ট ইউনিট প্রয়োজন (requests, seats, GB, minutes), একটি ট্রাস্টেড উৎস (কোন সেবা এটি এমিট করে), এবং একটি টাইম উইন্ডো (প্রতি দিন, প্রতি বিলিং পিরিয়ড, প্রতি ক্যালেন্ডার মাস)। যদি আপনি একটি বাক্যে মিটারটি ব্যাখ্যা করতে না পারেন, গ্রাহক বিশ্বাস করবে না।

বেশিরভাগ বিলিং সমস্যাকে ধরার দ্রুত চেকগুলো:

আপনি ইনপুটগুলো থেকে একটি ইনভয়েস রিপ্লে করতে পারবেন: প্ল্যান সংস্করণ, দাম, ব্যবহার টোটাল, ট্যাক্স, ডিসকাউন্ট, এবং প্রোরেশন প্যারামিটার
ব্যবহার ইভেন্টগুলো অ্যাপেন্ড-ওনলি, অপরিবর্তনীয়, এবং ডিডুপ্লিকেটেড (idempotency কী বা ইভেন্ট আইডি)
প্ল্যান এবং মূল্য পরিবর্তনগুলো কার্যকর তারিখসহ ভার্সন করা (পুরোনো দাম ওভাররাইট করবেন না)
প্রোরেশন নিয়ম সাধারণ ভাষায় লেখা আছে এবং টেস্ট কভর্ড
সাপোর্ট দ্রুত উত্তর দিতে পারে "আমি কেন চার্জ পেলাম" একই সংরক্ষিত তথ্য ব্যবহার করে

উদাহরণ: একটি গ্রাহক 18 তারিখে 10 থেকে 25 সিটে আপগ্রেড করে এবং 23 তারিখে একটি ব্যবহার থ্রেশহোল্ড পার করে। আপনার সিস্টেমটি দেখাতে সক্ষম হওয়া উচিত (1) কোন প্ল্যান সংস্করণ কোন তারিখে সক্রিয় ছিল, (2) সিট-চেঞ্জ ইভেন্টের টাইমস্ট্যাম্প, (3) ব্যবহৃত প্রোরেশন সূত্র, এবং (4) চূড়ান্ত টোটালে যেসব ব্যবহার ইভেন্ট যোগ হয়েছে সেগুলো।

পরবর্তী পদক্ষেপ: এমনভাবে বাস্তবায়ন করুন যাতে আপনি নিজেই জটিলতায় আটকে না যান

ছোটভাবে শুরু করুন, কিন্তু অস্পষ্টভাবে নয়। সবচেয়ে নিরাপদ পথ হল সেই ক্ষুদ্রতম ডেটা মডেল যা আপনাকে পরে এক প্রশ্নের উত্তর দিতে পারে: "আমরা কেন এই পরিমাণটি চার্জ করেছি?"

প্রোটোটাইপ আপনার বিলিং স্কিমা এবং অ্যাডমিন স্ক্রিনগুলো দ্রুত, আপনার প্রথম প্রাইসিং পরিবর্তনের আগে। যদি আপনি সেলসের প্রথম অনুরোধ পর্যন্ত অপেক্ষা করুন নতুন টিয়ার বা মিড-সাইকেল আপগ্রেডের জন্য, আপনি অনেক জায়গায় লজিক প্যাচ করতে থাকবেন।

একটি ব্যবহারিক ভাগ হলো: Stripe-কে চার্জিং, রসিদ, এবং পেমেন্ট রিট্রাই পরিচালনা করতে দিন, কিন্তু রেটিং (কীভাবে ব্যবহার লাইন আইটেমে পরিণত হয়) আপনার নিজস্ব সিস্টেমে রাখুন। এর মানে আপনি কাঁচা ব্যবহার ইভেন্ট, মূল্য সংস্করণ, এবং ইনভয়েস প্রিভিউ তৈরিতে ব্যবহৃত গণনার ফলাফল সংরক্ষণ করবেন।

একটি সহজ লঞ্চ প্ল্যান যা নমনীয় থাকবে:

1-2টি মিটার বেছে নিন যা আপনি নির্ভরযোগ্যভাবে পরিমাপ করতে পারেন (উদাহরণ: সক্রিয় সিট প্রতি দিন এবং API কল)
প্রথম দিন থেকেই মূল্য নিয়ম ভার্সন করুন যাতে পুরোনো ইনভয়েসগুলি এখনও পুরোনো নিয়মের সঙ্গে মেলে
একটি অভ্যন্তরীণ বিলিং অ্যাডমিন প্যানেল তৈরি করুন যা ব্যবহার, ওভাররাইড, ক্রেডিট, এবং বিতর্ক দেখতে দেয়
একটি মৌলিক গ্রাহক পোর্টাল ভিউ যোগ করুন: বর্তমান প্ল্যান, বর্তমান পিরিয়ড ব্যবহার, প্রত্যাশিত বিল
প্রতিটি ইনভয়েসকে একটি অডিটযোগ্য স্ন্যাপশট হিসেবে গ্রহণ করুন, পুনরায় গণনা করা অনুমান হিসেবে নয়

আপনি খুব দ্রুত যেতে চান এবং বেশি কাস্টম ব্যাক-অফিস কোড না লিখতে চান, তাহলে আপনি AppMaster-এ এই এনটিটি গুলো মডেল করে অ্যাডমিন এবং পোর্টাল স্ক্রিনগুলো ভিজ্যুয়াল টুলস দিয়ে নির্মাণ করতে পারেন, PostgreSQL-কে ইভেন্ট এবং ইনভয়েসের সিস্টেম অফ রেকর্ড হিসেবে রেখে।

কংক্রিট উদাহরণ: আপনি একটি সিট মিটার নিয়ে লঞ্চ করেছেন। তিন মাস পর আপনি GB স্টোরেজ যোগ করেন। যদি মিটার, entitlements, এবং মূল্য নিয়ম ভার্সন করা থাকে, আপনি নতুন মিটার পরিচয় করিয়ে দিতে পারবেন পুরোনো ইনভয়েস না ভেঙে, এবং সাপোর্ট কয়েক মিনিটে কোনো লাইন আইটেম ব্যাখ্যা করতে পারবে।

প্রশ্নোত্তর

Start by deciding what you need to prove later: why a customer was charged that amount. Subscriptions need plan, period, and entitlement history; usage needs an immutable record of what happened, when, and under which pricing rules.

If you can’t replay the invoice from stored inputs, you can’t reliably answer disputes or audits. The safest setup is to store time-bounded plan terms, versioned prices, raw usage events, and the exact calculation outputs used when the invoice was finalized.

A good meter is something two people can count the same way. Define the event, the unit, and the timing window, and write down what counts and what doesn’t (like retries, failed requests, or internal calls) so you don’t change the meaning midstream.

Hard limits block actions, soft limits warn but allow, and overage billing allows and charges. Pick one behavior per entitlement and store it as a rule with start and end timestamps so support, product, and billing all make the same decision.

They solve different problems: entitlements control what the customer is allowed to do, while metering records what actually happened. Keeping them separate prevents a meter change from accidentally breaking access, and it makes invoices easier to explain.

Store an append-only usage event log as the source of truth, and optionally keep aggregates for speed. Events should include timestamp, customer scope (like workspace), meter name, quantity, and a unique idempotency key so duplicates don’t double-charge.

Never overwrite old prices or plan rules; add new versions with effective dates. Then store which pricing version applied to each invoice (and often each entitlement period), so old invoices can be rebuilt exactly even after packaging changes.

Monthly billing needs a cycle anchor and a timezone, not just “monthly.” Store period_start and period_end consistently and be explicit about which timestamps you use for event time versus ingestion time to avoid off-by-one errors around time zones and DST.

Use a policy you can explain in one sentence, and model the math as explicit invoice line items (credits and debits) tied to the change event and proration window. Daily proration is a common default because it’s simpler to test and defend than hourly.

Finalize invoices as immutable snapshots and treat late usage as a new adjustment or as part of the next period, with a clear note. Previews can be recalculated freely, but finalized invoices should not change when new events arrive.