P&L per Client و Contribution Margin

این درس دربارهٔ «یک عدد سود برای هر مشتری» نیست. هدف این است که بتوانی دقیقاً بگویی هر نتیجه از چه لایه‌ای می‌آید، چه هزینه‌هایی داخل آن هستند و با کدام نسخهٔ تخصیص ساخته شده است.

1) مسئله‌ای که این درس حل می‌کند

درآمد مشتری معمولاً راحت دیده می‌شود؛ اما سودآوری واقعی وقتی خراب می‌شود که credit/refund، مصرف مستقیم، کارمزد پرداخت، زمان پشتیبانی و سهم هزینه‌های مشترک در یک سبد نامشخص ریخته شوند. در این وضعیت دو نفر می‌توانند از یک مشتری دو «سود» متفاوت گزارش کنند و هر دو ظاهراً عدد درست داشته باشند.

2) مرز درس و خروجی

خروجی این درس Client P&L & Contribution Bridge v1 است. این artifact برای تصمیم مدیریتی داخلی است، نه صورت مالی قانونی، اظهارنامه مالیاتی یا invoice. خروجی باید از recognized_revenue تا fully_loaded_profit یک زنجیرهٔ قابل‌ردیابی بسازد و cost_scope و allocation_version را کنار عدد نگه دارد.

3) Fact: Gross Profit با Overhead یکی نیست

راهنمای فعلی QuickBooks برای Invoice Profitability، revenue، direct cost/COGS و gross profit را نشان می‌دهد و تصریح می‌کند overhead و operating expenses در همان گزارش نیستند. پس اگر یک گزارش فقط direct cost را کم می‌کند، نباید آن را خودکار «fully-loaded client P&L» نامید.

4) Fact: Unit Economics می‌تواند تا سطح Customer/Cost-to-Serve برود

FinOps Unit Economics متریک‌هایی مثل cost per customer/tenant و cost to serve را به رسمیت می‌شناسد و آن‌ها را به بحث‌های margin، sustainability و pricing وصل می‌کند. اما خود FinOps نمی‌گوید MAKNOW دقیقاً کدام هزینه را contribution و کدام را shared allocation بداند؛ این مرز باید محلی و مستند باشد.

5) مدل ذهنی درست: Revenue → Contribution → Fully Loaded

سه لایه را جدا نگه دار: net_revenue، سپس contribution economics، سپس fully-loaded view. Contribution می‌پرسد «این مشتری بعد از هزینه‌های مستقیم/متغیر چه چیزی برای پوشش shared cost باقی می‌گذارد؟» Fully-loaded می‌پرسد «بعد از تخصیص سهم shared cost چه نتیجه‌ای می‌ماند؟» این دو سؤال یکی نیستند.

6) Period و Revenue Boundary را قفل کن

client_id و period باید قبل از هر محاسبه ثابت باشند. recognized_revenue با credits_refunds همان period به net_revenue تبدیل می‌شود. اگر credit بعد از بسته‌شدن دوره ثبت شود، عدد جدید ممکن است قابل محاسبه باشد اما بدون restatement/version نباید final تلقی شود.

7) Contribution Cost را صریح بساز

در این قرارداد، contribution cost از direct_usage_cost + payment_cost + customer_support_cost + other_variable_cost ساخته می‌شود. اگر پشتیبانی مشخصاً برای همان مشتری انجام شده، انتقال آن به shared overhead فقط برای بهتر شدن margin یک misclassification است، نه optimization.

8) Contribution Profit و Margin را از نو محاسبه کن

contribution_profit = net_revenue − contribution_cost. اگر net_revenue > 0 باشد، contribution_margin_pct = contribution_profit / net_revenue × 100. این خروجی هنوز fully-loaded profit نیست. نمایش درصد بدون scope، period و evidence یک عدد بی‌پشتوانه است.

9) Shared Allocation را لایهٔ جدا نگه دار

allocated_shared_cost باید جدا از contribution cost بماند و allocation_version داشته باشد. سپس fully_loaded_cost = contribution_cost + allocated_shared_cost و fully_loaded_profit = net_revenue − fully_loaded_cost. اگر روش تخصیص عوض شود، مقایسهٔ قبل/بعد بدون restatement یا segmentation قابل اتکا نیست.

10) Contribution-positive می‌تواند Fully-loaded-negative باشد

اگر contribution profit مثبت ولی fully-loaded profit منفی باشد، این درس آن را MARGINAL می‌نامد. این state می‌گوید مشتری به پوشش shared costs کمک می‌کند اما با allocation فعلی fully-loaded سودده نیست. حذف این لایه باعث می‌شود «سودده» و «زیان‌ده» بیش‌ازحد ساده شوند.

11) Variance Driver را کنار نتیجه منتشر کن

تغییر سود باید explanation داشته باشد: CREDIT, SUPPORT_AUTOMATION, USAGE_SPIKE, PAYMENT_FEE, ALLOCATION_V2 یا ترکیبی از آن‌ها. variance_driver برای داستان‌سازی نیست؛ برای این است که reviewer بداند کدام evidence نسبت به دورهٔ قبلی تغییر کرده است.

12) Core Evidence Contract

هر Bridge باید ۲۰ بُعد زیر را حمل کند و ۱۵ بُعد بحرانی بدون evidence معتبر نمی‌توانند خالی بمانند.

13) Typed State جلوی «سود جعلی» را می‌گیرد

PROFITABLE یعنی contribution مثبت و fully-loaded غیرمنفی. MARGINAL یعنی contribution مثبت اما fully-loaded منفی. LOSS یعنی contribution غیرمثبت. HOLD برای evidence ناقص/نیاز به restatement و DISPUTED برای scope یا comparison ناسازگار است. هیچ score کلی حق ندارد HOLD یا DISPUTED را پنهان کند.

14) مقایسه باید Scope و Allocation Version مشترک داشته باشد

دو مشتری یا دو دوره فقط وقتی مستقیم قابل مقایسه‌اند که تعریف هزینه‌ها و allocation version هم‌تراز باشد. اگر cost_scope متفاوت است یا allocation method عوض شده، اول restate/segment کن؛ بعد نتیجه بگیر. این قاعده از مقایسهٔ زیبا اما بی‌معنا جلوگیری می‌کند.

15) Lab، Transfer و Freshness

در Lab هشت fixture داری: baseline، misclassification پشتیبانی، refund بعد از close، allocation-version drift، scope mismatch، evidence مفقود، مشتری contribution-positive/fully-loaded-negative و transfer نهایی. در transfer، Client A credit می‌گیرد، support بعد از automation کم می‌شود و allocation به v2 می‌رود؛ باید هر دو profitability layer را از evidence جدید بسازی. منابع QuickBooks و FinOps در 2026-09-15 بازبینی شدند و هر تغییر معنادار قبل از review_due نیازمند requalification است.