Chargeback و Internal Cost Allocation

1. شکست واقعی: صورتحساب درست است، نسبت‌دادن هزینه غلط است

سه Venture از Observability، ظرفیت پلتفرم و Support مشترک استفاده می‌کنند. جمع صورتحساب ۹۸۰ واحد است و از نظر حسابی مشکلی ندارد؛ مشکل این است که «چه کسی باعث این هزینه شده؟» و «چه مقدار باید فقط نمایش داده شود یا واقعاً Chargeback شود؟». اگر صرفاً هزینه مشترک را سه قسمت کنیم، عددها کامل‌اند ولی شواهد ناقص‌اند. هدف این درس ساخت Internal Cost Allocation & Chargeback Policy Ledger v1 است؛ Ledger باید نشان دهد هر مقدار از کجا آمده، با کدام Driver توزیع شده و چه مقدار هنوز Unallocated است.

2. مرز مالکیت درس

ARC-005 فقط Allocation داخلی، Showback/Chargeback و Reconciliation را مالک است. Quota/Reservation متعلق به ARC-004 و Tenant Isolation متعلق به ARC-006 است. در این درس Billing Production، Journal Entry، Cost Center واقعی یا Invoice مشتری تغییر نمی‌کند. FinOps فقط مرز FACT را می‌دهد؛ Policy داخلی MAKNOW و سازمان شما باید جدا ثبت شود.

3. مدل ذهنی: Cost Identity قبل از Allocation

اول هر Cost Item را با cost_item_id، billing_period و cost_category هویت‌دار کنید. بعد تعیین کنید DIRECT است یا SHARED. تا وقتی این طبقه‌بندی روشن نیست، انتخاب روش تقسیم زودهنگام است. فرمول Reconciliation ساده است: Source Cost = Allocated Amount + Unallocated Amount. اگر این برابری برقرار نباشد، Ledger قابل اتکا نیست.

4. Direct Cost و Shared Cost یکی نیستند

Direct Cost وقتی معتبر است که Target با Metadata قابل ردگیری باشد؛ مثلاً Resource Tag، Account/Project mapping یا رکورد مالکیت. Shared Cost به یک Pool و Driver نیاز دارد. قرار نیست هر هزینه‌ای که Tag ندارد فوراً Shared اعلام شود؛ ممکن است فقط Ownership Evidence ناقص باشد و باید Unallocated بماند.

5. Showback با Chargeback فرق دارد

Showback یعنی هزینه به تیم‌ها/محصولات نشان داده شود تا Ownership و تصمیم‌گیری بهتر شود. Chargeback یک قدم رسمی‌تر است و هزینه را به فرآیندهای مالی/بودجه‌ای سازمان وارد می‌کند. FinOps هم این تفاوت را به رسمیت می‌شناسد و Chargeback را برای همه سازمان‌ها الزامی نمی‌داند. پس showback_chargeback_mode یک فیلد تصمیم است، نه برچسب تزئینی.

6. فیلدهای Ledger و Stateهای مجاز

Ledger باید همه فیلدهای حیاتی را جدا نگه دارد: Item، Period، Direct/Shared، Target، Metadata، Driver، Quantity، Method، Basis، Pool Total، Allocated، Unallocated، Mode، Policy Version، Exception، Reconciliation State و Provenance. State موفق RECONCILED است؛ شواهد ناقص یا ناسازگار باید با HOLD / UNKNOWN / PARTIAL / DISPUTED / STALE / BLOCKED دیده شوند.

7. Driver را از Outcome انتخاب کنید، نه از راحتی

برای Shared Cost یک Driver باید رابطه قابل دفاعی با Cost Causation یا Policy مصوب داشته باشد. Traffic ممکن است برای Observability مناسب باشد ولی برای Onboarding Support نه. Fixed، Proportional و Proxy Metric هر سه ممکن‌اند؛ اما انتخابشان باید در allocation_basis و policy_version ثبت شود.

8. Equal Split پیش‌فرض خنثی نیست

تقسیم مساوی فقط یک روش است. اگر سه Venture رفتار بسیار متفاوت دارند، Equal Split می‌تواند به Venture کم‌مصرف هزینه اضافه و به مصرف‌کننده سنگین یارانه پنهان بدهد. اگر Policy می‌گوید Usage-Proportional ولی محاسبه Equal Split است، State باید DISPUTED باشد—even اگر جمع Allocated دقیقاً با Source Cost برابر شود.

9. Unallocated Cost را پنهان نکنید

مقدار Unallocated نشانه شکست Ledger نیست؛ ممکن است صادقانه‌ترین خروجی باشد. اگر یک Direct Resource بزرگ Tag معتبر ندارد، آن هزینه نباید برای «کامل شدن درصدها» به Venture دلخواه منتقل شود. Forced allocation بدون Evidence باعث DISPUTED می‌شود. هدف Reconciliation صفرکردن Residue به هر قیمت نیست؛ هدف توضیح‌پذیری کامل است.

10. Policy Version و Reconciliation

هر تغییر در Target Population، Driver، Apportionment Method یا Policy Version می‌تواند عددها را عوض کند. Amountهای نسخه قبلی زیر Policy جدید خودکار معتبر نمی‌مانند. اگر Policy تغییر کرده ولی Recompute انجام نشده، State PARTIAL است تا محاسبه و Reconciliation دوباره انجام شود.

11. مثال Baseline: ۹۸۰ واحد هزینه

سه Direct Cost برابر A=250، B=150، C=100 داریم. Shared Observability برابر 300 با Traffic 50/30/20 توزیع می‌شود: 150/90/60. Shared Support برابر 180 با Support-Hours 20/50/30 توزیع می‌شود: 36/90/54. خروجی نهایی A=436، B=330، C=214 است؛ جمع 980، Unallocated=0 و با Policy v1 حالت RECONCILED می‌شود. نکته: موفقیت به خاطر «جمع شدن عددها» نیست؛ Driver و Provenance هم معتبرند.

12. چهار Shortcut که باید رد شوند

1. حذف Tag از یک Direct Item بزرگ و نسبت‌دادن حدسی آن؛ ۲) استفاده از Equal Split در حالی که Policy Driver دیگری می‌خواهد؛ ۳) Force کردن Unallocated به صفر؛ ۴) تغییر Policy Version بدون Recompute. این‌ها به‌ترتیب می‌توانند PARTIAL، DISPUTED، DISPUTED و PARTIAL بسازند. Evidence قدیمی STALE است و ممنوعیت صریح مالی/مالک BLOCKED.

13. Lab آفلاین

Lab شامل ۸ Fixture مصنوعی است و هیچ API یا Credential نمی‌خواهد. با python run_checks.py اجرا کنید. برای هر Case فقط State را حفظ نکنید؛ allocated_total، unallocated_total، target_allocations، Conservation و امکان Chargeback را هم بررسی کنید. اگر محاسبه عوض شد ولی توضیح Driver عوض نشد، پاسخ ناقص است.

14. Assessment و معیار قبولی

باید بتوانید: مرز Showback/Chargeback را توضیح دهید؛ Baseline Ledger را کامل کنید؛ Mutation حذف Tag را Diagnose کنید؛ و Transfer را از نو محاسبه کنید. پاسخ خوب حتماً Source Cost را Reconcile می‌کند، Driver را نام می‌برد، Residue را پنهان نمی‌کند و State قوی‌تر از Evidence انتخاب نمی‌کند.

15. Transfer: Venture جدید با Traffic کم و Support سنگین

Venture D وسط ماه اضافه می‌شود. Direct Costها A=250، B=150، C=100، D=40 است. Shared Platform=200 با Traffic 50/30/15/5 توزیع می‌شود؛ Shared Support=400 با Support-Hours 15/20/25/40. Allocation جدید A=410، B=290، C=230، D=210 است. Equal Split برای 600 Shared Cost به هر Venture 150 می‌داد و totals را A=400، B=300، C=250، D=190 می‌کرد. تفاوت ثابت می‌کند Driver Policy باید با Context جدید Recompute شود. منابع FinOps تا 2026-09-15 دوباره بررسی شده‌اند؛ اگر semantics مادی تغییر کند، نسخه جدید Lesson لازم است.