Back to Details

company-cfo

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/company-cfo — Monthly company CFO workflow

/company-cfo — 公司月度CFO工作流程

The standing analysis leadership uses to make distribution / cuts / hiring / runway decisions. Primary cadence is monthly (run on the 1st for the closed prior month). Weekly and scenario modes cover the in-between.
Anonymized team-scope sibling to 
personal-cfo
(households). Same discipline (transaction-sum EOM, categorization traps, scenario modeling) applied to company books.
这是领导层用于制定分配、裁员、招聘和资金runway决策的常规分析流程。主要周期为月度（每月1日针对上月已结算数据运行）。每周和场景模式用于填补月度周期之间的空白。
这是面向团队范围的匿名版工具，对应处理家庭财务的
personal-cfo
。将相同的原则（交易求和法计算月末余额、分类陷阱、场景建模）应用于公司账簿。

Step 0 — Load company config + prior run

步骤0 — 加载公司配置与上一次运行记录

Before starting work, read these in order:
  1. ${COMPANY_CFO_ROOT:-$HOME/code/company-cfo}/CLAUDE.md
     — your company's specific methodology, data source map, categorization rules, distribution mechanics. This is the source of truth for HOW your company computes things. Don't invent your own methodology.
  2. The most recent report in 
    ${COMPANY_CFO_ROOT}/reports/monthly/
    — last month's snapshot. Tells you what leadership decided + what was open.
  3. The most recent 
    *-followup.md
     in that folder (if one exists) — supplementary decisions, scenario analysis.
  4. Any relevant memory notes in 
    ~/.claude/memory/
    — running context: known anomalies, leadership constraints, current churn state.
  5. git log --oneline -10
     in 
    ${COMPANY_CFO_ROOT}
    — what's shipped since the last run.
If the 
COMPANY_CFO_ROOT
dir doesn't exist yet: first-run walkthrough asks the user to 
mkdir
it, seed a 
CLAUDE.md
from 
references/company-config-template.md
, and set the env var.
开始工作前，请按以下顺序读取内容：
  1. ${COMPANY_CFO_ROOT:-$HOME/code/company-cfo}/CLAUDE.md
     — 贵公司的特定方法、数据源映射、分类规则和分配机制。这是公司计算方式的唯一权威来源，请勿自行创建方法。
  2. ${COMPANY_CFO_ROOT}/reports/monthly/
    中的最新报告     — 上月的快照，告知领导层的决策内容以及未解决事项。
  3. 该文件夹中最新的
    *-followup.md
    文件（如果存在）     — 补充决策、场景分析内容。
  4. ~/.claude/memory/
    中的相关记忆笔记     — 运行上下文：已知异常、领导层限制、当前客户流失状态。
  5. ${COMPANY_CFO_ROOT}
    中的
    git log --oneline -10
     — 上一次运行以来的更新内容。
如果
COMPANY_CFO_ROOT
目录尚未存在：首次运行引导会要求用户
mkdir
创建该目录，从
references/company-config-template.md
生成初始
CLAUDE.md
，并设置环境变量。

Step 1 — Parse mode

步骤1 — 解析模式

InvocationModeCadence
/company-cfo monthly
(default)		monthlyOnce per month on the 1st for the closed prior month
/company-cfo weekly
weeklyThin cash pulse — current cash + next 2 weeks of expected flows
/company-cfo scenario <question>
scenarioAd-hoc modeling in the projector
/company-cfo pickup
pickupResume where the prior run left off (checks git log + last report + open items)
Below sections walk through monthly in detail. Weekly + scenario are summarized at the end.
调用指令模式周期
/company-cfo monthly
（默认）		月度每月1日针对上月已结算数据运行一次
/company-cfo weekly
每周精简现金动态——当前现金余额+未来2周的预期资金流动
/company-cfo scenario <question>
场景在预测器中进行临时建模
/company-cfo pickup
续办从上一次运行中断处恢复（检查git日志、最新报告和未完成事项）
以下部分详细介绍月度模式。每周和场景模式将在末尾总结。

Monthly workflow

月度工作流程

Ask the user: Which month are we reporting on? (Default: prior calendar month.)
Then walk through these phases. Pause and confirm before moving to the next.
询问用户：我们要报告哪个月份的数据？（默认：上一自然月。）
然后按以下阶段逐步进行。进入下一阶段前请暂停并确认。

Phase 1 — Pull raw data

阶段1 — 拉取原始数据

For the target month, pull raw data from each source. Standard source categories (each company's actual tools live in their 
CLAUDE.md
):
Source categoryWhat it givesCommon tools
Bank / cash accountsCash truth, internal vs external transfers, distribution recipientsMercury CLI, Plaid, direct bank export
Payment processorRevenue, subscriptions, churn, payout timingStripe API, Paddle, LemonSqueezy
Payroll / contractorsW-2 payroll, contractor payPlane, Deel, Gusto, Rippling
Expense managementReimbursements, corporate cardsRamp, Brex, Divvy
Alternative revenueNon-primary billing sourcesDirect invoice tools, alternative payment platforms
Save all pulls to 
${COMPANY_CFO_ROOT}/data/YYYY-MM/<source>-*.json[l]
(gitignored — raw data doesn't get committed).
Also pull the current cash balance from the bank source for the "today" starting-cash figure.
If a source isn't wired yet: use 
/toolify <source>
to wire it up before running the CFO workflow. First-time integration is a one-time cost.
针对目标月份，从每个数据源拉取原始数据。标准数据源类别（各公司的实际工具记录在其
CLAUDE.md
中）：
数据源类别提供内容常用工具
银行/现金账户现金真实余额、内部与外部转账、分配接收方Mercury CLI、Plaid、直接银行导出
支付处理器收入、订阅、客户流失、付款时间Stripe API、Paddle、LemonSqueezy
薪资/承包商W-2薪资、承包商报酬Plane、Deel、Gusto、Rippling
费用管理报销、公司卡消费Ramp、Brex、Divvy
其他收入非主要账单来源直接发票工具、替代支付平台
将所有拉取的数据保存至
${COMPANY_CFO_ROOT}/data/YYYY-MM/<source>-*.json[l]
（已加入git忽略——原始数据不会提交）。
同时从银行数据源拉取当前现金余额，作为“今日”起始现金数值。
如果某个数据源尚未连接： 在运行CFO工作流前使用
/toolify <source>
进行连接。首次集成是一次性工作。

Phase 2 — Categorize and reconcile

阶段2 — 分类与对账

Bucket all cash-account outflows into the categories your company uses. See 
references/categorization.md
for a starter category set and the discipline of maintaining categorization.
Universal traps to check (see 
references/traps.md
for full list):
  • Cash-vs-credit double-count — if the bank shows a "credit card autopay" outflow AND the credit card account shows individual charges, don't count both. Filter to cash accounts only OR treat the CC as a debt account.
  • Internal transfers — Checking ↔ Savings transfers net to zero. Exclude them (usually via a 
    kind=internalTransfer
    filter or account-pair match).
  • Currency mismatches — contractor payment tools often return 
    destination_amount
    in the worker's payout currency. Always use 
    source_amount
    (or equivalent) for USD/base-currency cost analysis.
  • Distribution counting — if leadership has N partners who should get a monthly distribution, verify N distributions exist. If N-1, flag the missing partner — often one is deferring their draw to balance cash.
Cross-checks before writing the report:
  • Total payroll debits in bank ≈ payroll-tool API total + fees (within a small residual for held deductions)
  • Payment processor payouts arriving in the month ≈ bank inflows from that processor (within timing lag)
  • Expense-management outflows in bank ≈ approved expenses in expense-mgmt tool (with cash-basis lag)
将所有现金账户的流出款项归类到公司使用的类别中。入门类别集和分类维护原则请参考
references/categorization.md
。
需检查的常见陷阱（完整列表请参考
references/traps.md
）：
  • 现金与信用卡重复统计 — 如果银行记录显示“信用卡自动还款”流出，同时信用卡账户显示单独的消费记录，请勿重复统计。仅筛选现金账户记录，或将信用卡视为负债账户处理。
  • 内部转账 — 支票账户与储蓄账户之间的转账净额为零。请排除此类记录（通常通过
    kind=internalTransfer
    筛选或账户配对匹配）。
  • 货币不匹配 — 承包商支付工具通常返回工人收款货币的
    destination_amount
    。美元/基准货币成本分析请始终使用
    source_amount
    （或等效字段）。
  • 分配统计 — 如果领导层有N位合伙人应获得月度分配，请确认存在N笔分配记录。如果只有N-1笔，请标记缺失的合伙人——通常是其中一位延迟提款以平衡现金。
撰写报告前的交叉检查：
  • 银行中的薪资总支出 ≈ 薪资工具API总额 + 手续费（扣除预扣款项后的微小误差范围内）
  • 当月支付处理器到账金额 ≈ 银行中来自该处理器的流入金额（考虑时间滞后）
  • 银行中的费用管理流出 ≈ 费用管理工具中的已审批费用（考虑收付实现制滞后）

Phase 3 — Compute EOM cash (the transaction-sum method)

阶段3 — 计算月末现金余额（交易求和法）

Use transaction sums, not the walkback-from-current-balance method. Walkback has bitten CFO workflows repeatedly — a bank API balance snapshot at pull time can be off by tens of thousands, and that error propagates into every historical EOM value.
Correct method (see 
references/eom-cash-methodology.md
for the full recipe):
python
undefined
请使用交易求和法，而非从当前余额回溯的方法。 回溯法曾多次导致CFO工作流程出错——拉取数据时的银行API余额快照可能偏差数万美元，且该误差会传播到所有历史月末余额中。
正确方法（完整流程请参考
references/eom-cash-methodology.md
）：
python
undefined

1. Pull ALL transactions for each cash account (Checking + Savings + any other cash-holding):

1. 拉取每个现金账户（支票账户+储蓄账户+其他现金持有账户）的所有交易记录：

<bank-tool> transactions list --account-id <id> --format jsonl --max-items 100000

<bank-tool> transactions list --account-id <id> --format jsonl --max-items 100000

2. Sum the amount field across all transactions in each account.

2. 汇总每个账户中所有交易的amount字段。

3. The sum should equal that account's CURRENT available_balance exactly.

3. 汇总金额应与该账户当前的available_balance完全一致。

(Sanity check — if not, missing data or a pre-history baseline deposit exists.)

（ sanity检查——如果不一致，说明存在数据缺失或历史基线存款。）

4. For any past date T: balance_at_T = sum of all transactions posted on or before T

4. 对于任意过去日期T：balance_at_T = 所有在T日或之前入账的交易总和

(plus any pre-history baseline, which should be ~$0 if the sanity check passes).

（加上任何历史基线，如果sanity检查通过，该基线应约为$0。）


Cross-check EOM: last month's EOM + this month's net cash change should equal this month's EOM, to the dollar.

If transaction sums don't reconcile with current balance, **do not proceed** with walkback as fallback. Investigate the gap first — missing pulls (timeout, paging), an unknown account, or a legitimate pre-history baseline.

月末余额交叉检查：上月月末余额 + 本月现金净变化应等于本月月末余额，精确到美元。

如果交易总和与当前余额无法对账，**请勿使用回溯法作为替代方案**。首先调查差异原因——数据拉取缺失（超时、分页问题）、未知账户或合法的历史基线。

Phase 4 — Update the scenario projector

阶段4 — 更新场景预测器

Most CFO workflows benefit from a scenario projector — an interactive forecast that projects EOM cash forward N months under adjustable assumptions (revenue growth, expense scenarios, hiring plans, distribution changes).
Common structure (see 
references/scenario-projector.md
for the reference implementation):
  • HISTORICAL (trailing 3 closed months) — provides context before TODAY
  • TODAY — actual current cash balance (calendar-positioned within current month)
  • Mo 1 — current calendar month EOM (partial — remaining-month activity)
  • Mo 2-7 — next 6 full calendar month EOMs (scenario settings apply from here)
Each month: 
starting + revenue − expenses = profit → ending
Intramonth cycle low (for weekly cash pulse relevance): most CFO systems care about the low point of the month (when you might hit a cash floor), not just the high (EOM). Formula depends on payout cadence — see 
references/scenario-projector.md
.
Update the projector each monthly run:
  1. Append the just-closed month to HISTORICAL with all category fields; drop the oldest.
  2. Update 
    startingCash
    to today's actual bank balance.
  3. Update expense baselines for any category that materially shifted.
  4. Update 
    baselineMrr
    (net of processing fees).
  5. Verify presets still make sense (scenarios may need updating if comp structure or hiring plans changed).
大多数CFO工作流程都受益于场景预测器——这是一个交互式预测工具，可根据可调整的假设（收入增长、费用场景、招聘计划、分配变化）预测未来N个月的月末现金余额。
常见结构（参考实现请参考
references/scenario-projector.md
）：
  • 历史数据（过去3个已结算月份）——提供今日之前的上下文
  • 今日——实际当前现金余额（定位在当前月的日历位置）
  • 第1个月——当前自然月月末余额（部分数据——剩余月份活动）
  • 第2-7个月——接下来6个完整自然月的月末余额（从这里开始应用场景设置）
每月公式：
起始余额 + 收入 − 支出 = 利润 → 期末余额
月内周期低点（与每周现金动态相关）：大多数CFO系统更关注月度低点（可能触及现金底线），而非高点（月末余额）。计算公式取决于付款周期——请参考
references/scenario-projector.md
。
每次月度运行时更新预测器：
  1. 将刚结算的月份添加到历史数据中，包含所有类别字段；移除最早的月份。
  2. 将
    startingCash
    更新为今日实际银行余额。
  3. 更新任何大幅变动类别的费用基线。
  4. 更新
    baselineMrr
    （扣除手续费后的净额）。
  5. 验证预设是否仍然合理（如果薪酬结构或招聘计划变更，场景可能需要更新）。

Phase 5 — Write the snapshot report

阶段5 — 撰写快照报告

Create 
${COMPANY_CFO_ROOT}/reports/monthly/YYYY-MM.md
following the template in 
references/report-template.md
. Sections (adapt as needed):
  1. TL;DR — headline + status table (net cash, ending balance, current MRR, trailing-N-month, recommendation)
  2. Cash In — by source (payment processor, alt revenue, one-times)
  3. Cash Out — by category (matches the projector's category structure)
  4. Payroll breakdown — verified contractor + W-2 split
  5. Distributions — who got paid, who didn't (flag anomalies)
  6. Revenue metrics — active subs, MRR delta, recent cancels with $ and customer
  7. Forward projection — 1-3 scenarios from the projector (link the projector state)
  8. Recommended actions — concrete for leadership to decide on
  9. Open items — questions to resolve next month
Write the why-paragraph in plain English: what happened and why. Reference the previous month if there's continuity ("Vendor X churn from last month finished hitting June payouts").
按照
references/report-template.md
中的模板创建
${COMPANY_CFO_ROOT}/reports/monthly/YYYY-MM.md
。章节内容（可按需调整）：
  1. 摘要——标题+状态表（净现金、期末余额、当前MRR、过去N个月数据、建议）
  2. 现金流入——按来源分类（支付处理器、其他收入、一次性收入）
  3. 现金流出——按类别分类（与预测器的类别结构一致）
  4. 薪资明细——已验证的承包商与W-2员工拆分
  5. 分配情况——收款方、未收款方（标记异常）
  6. 收入指标——活跃订阅数、MRR变化、近期取消订阅的金额和客户
  7. 前瞻性预测——来自预测器的1-3种场景（链接预测器状态）
  8. 建议行动——供领导层决策的具体措施
  9. 未解决事项——下月需解决的问题
用通俗易懂的语言撰写原因段落：发生了什么以及原因。如果与上月有连续性，请参考上月内容（例如“上月Vendor X的客户流失在6月付款中完全体现”）。

Phase 6 — Update memory

阶段6 — 更新记忆

Update 
~/.claude/memory/company_cfo_<company-slug>.md
(or wherever your memory system lives) if any of:
  • Distribution/comp structure changed
  • Active sub count or MRR shifted materially
  • New revenue stream (new billing platform)
  • New partner / contractor decision
  • New cash floor or distribution constraint
Don't bloat the note. Replace stale facts; don't append indefinitely.
如果出现以下情况，请更新
~/.claude/memory/company_cfo_<company-slug>.md
（或您的记忆系统所在位置）：
  • 分配/薪酬结构变更
  • 活跃订阅数或MRR大幅变动
  • 新收入来源（新账单平台）
  • 新合伙人/承包商决策
  • 新现金底线或分配限制
请勿让笔记过于冗长。替换过时信息；不要无限追加。

Phase 7 — Review and ship

阶段7 — 审核与发布

Follow your company's git workflow:
Before the first-ever run, verify 
.gitignore
at the repo root excludes raw exports — Phase 1 dumps sensitive bank / payroll / payment-processor data to 
data/
and that MUST NOT be committed. If missing, seed it:
bash
cd ${COMPANY_CFO_ROOT}
遵循公司的git工作流程：
首次运行前，请验证仓库根目录的
.gitignore
是否排除原始导出文件——阶段1会将敏感的银行/薪资/支付处理器数据转储到
data/
目录，绝对不能提交。如果缺失，请添加：
bash
cd ${COMPANY_CFO_ROOT}

Verify .gitignore excludes raw data + secrets

验证.gitignore是否排除原始数据和密钥

if ! grep -q '^data/' .gitignore 2>/dev/null; then cat >> .gitignore <<'GITIGNORE'
if ! grep -q '^data/' .gitignore 2>/dev/null; then cat >> .gitignore <<'GITIGNORE'

Raw financial data — never commit

原始财务数据——绝不提交

data/ *.jsonl *.env *.env.local .mcp.json GITIGNORE git add .gitignore git commit -m "Seed .gitignore for raw financial data" fi

Then ship the report + projector changes ONLY (never `git add -A` in this repo — targeted adds only, so a stray `data/` file can't slip in):

```bash
cd ${COMPANY_CFO_ROOT}
git checkout -b feature/YYYY-MM-snapshot
git add reports/monthly/YYYY-MM.md scenarios/index.html CLAUDE.md   # targeted
git status --short                                                    # verify no data/ or .env files staged
git commit -m "YYYY-MM monthly snapshot"
git push -u origin feature/YYYY-MM-snapshot
gh pr create --base main --title "YYYY-MM monthly snapshot"
Never 
git add -A
in 
${COMPANY_CFO_ROOT}
. A silent 
data/
file leak would push bank transaction history + partner distribution ACHs to a git remote. Targeted adds only.
Before merging: run a code review (if applicable) or manually review the diff. Then merge + delete branch.
data/ *.jsonl *.env *.env.local .mcp.json GITIGNORE git add .gitignore git commit -m "Seed .gitignore for raw financial data" fi

然后仅发布报告和预测器变更（切勿在此仓库中使用`git add -A`——仅针对性添加，避免意外提交`data/`文件）：

```bash
cd ${COMPANY_CFO_ROOT}
git checkout -b feature/YYYY-MM-snapshot
git add reports/monthly/YYYY-MM.md scenarios/index.html CLAUDE.md   # 针对性添加
git status --short                                                    # 验证未暂存data/或.env文件
git commit -m "YYYY-MM monthly snapshot"
git push -u origin feature/YYYY-MM-snapshot
gh pr create --base main --title "YYYY-MM monthly snapshot"
切勿在
${COMPANY_CFO_ROOT}
中使用
git add -A
。 意外提交
data/
文件会将银行交易历史和合伙人分配ACH信息推送到git远程仓库。仅进行针对性添加。
合并前：进行代码审查（如适用）或手动审查差异。然后合并并删除分支。

Weekly cash pulse mode

每周现金动态模式

Thin — designed to fit into a 15-minute weekly sync.
  1. Pull current cash balance (bank API 
    accounts list
    )
  2. Pull last 7 days of transactions + next 7 days of scheduled outflows (payroll, known bills)
  3. Compute: current cash, next-payroll date + amount, next-Stripe-payout date + amount
  4. Flag if cash < next 2 weeks of outflows (below cash floor)
  5. One-line status: 
    Cash $X | Next payroll $Y on <date> | Next inflow $Z on <date> | Floor status: OK|WATCH|BREACH
Save to 
${COMPANY_CFO_ROOT}/reports/weekly/YYYY-WW.md
.
Pair with 
/loopify
to schedule the weekly run (typically Monday 9am).
精简模式——适用于15分钟的每周同步会议。
  1. 拉取当前现金余额（银行API的
    accounts list
    ）
  2. 拉取过去7天的交易记录+未来7天的计划流出（薪资、已知账单）
  3. 计算：当前现金余额、下一次薪资日期+金额、下一次Stripe付款日期+金额
  4. 如果现金余额<未来2周流出（低于现金底线），标记预警
  5. 单行状态：
    现金 $X | 下一次薪资 $Y 于 <date> | 下一次流入 $Z 于 <date> | 底线状态：正常|关注|突破
保存至
${COMPANY_CFO_ROOT}/reports/weekly/YYYY-WW.md
。
可与
/loopify
组合使用，安排每周运行（通常为周一上午9点）。

Scenario mode

场景模式

Ad-hoc — for "what if we hire a $150K/yr engineer in September" or "what if churn ticks up 2%".
Open the scenario projector, adjust the relevant knobs, screenshot or export the resulting cash projection. Save the analysis to 
${COMPANY_CFO_ROOT}/reports/scenarios/YYYY-MM-DD-<question-slug>.md
.
If the scenario decision is material (new hire, distribution change, big expense), also run 
/decide
to formalize.
临时模式——用于“如果我们在9月雇佣一名年薪15万美元的工程师会怎样”或“如果客户流失率上升2%会怎样”这类问题。
打开场景预测器，调整相关参数，截图或导出生成的现金预测。将分析保存至
${COMPANY_CFO_ROOT}/reports/scenarios/YYYY-MM-DD-<question-slug>.md
。
如果场景决策影响重大（新招聘、分配变更、大额支出），还需运行
/decide
进行正式化处理。

Pickup mode

续办模式

Resume from the prior run. Surface:
  1. Most recent monthly report (
    ls -t ${COMPANY_CFO_ROOT}/reports/monthly/*.md | head -1
    )
  2. Most recent weekly pulse
  3. Latest 
    git log
    on 
    ${COMPANY_CFO_ROOT}
    (what's shipped since last snapshot)
  4. Memory note for current narrative
  5. Open items from the last report's §9
Don't assume continuity from training data. Always check the reports + memory + git log first.
从上一次运行中断处恢复。展示以下内容：
  1. 最新月度报告（
    ls -t ${COMPANY_CFO_ROOT}/reports/monthly/*.md | head -1
    ）
  2. 最新每周现金动态
  3. ${COMPANY_CFO_ROOT}
    的最新
    git log
    （上一次快照以来的更新内容）
  4. 当前叙事的记忆笔记
  5. 上一次报告第9节中的未解决事项
不要假设训练数据具有连续性。 请始终先检查报告、记忆和git日志。

Composes with

可组合工具

  • personal-cfo
     — sibling. Personal-cfo handles household finances (house math, monthly cash flow, big purchases). Same discipline (transaction-sum method, scenario modeling) applied to different scope.
  • company-brain
     — the CFO reports get stored + wiki-indexed there. 
    outputs/
    in the company brain accumulates monthly reports; wiki pages compile trends across months.
  • toolify
     — wire company-specific data sources (Mercury API, Stripe, Plane, Ramp, or equivalents). First-run integration setup.
  • loopify
     — schedule the monthly run (1st of month) + weekly cash pulse (Monday 9am).
  • decide
     — for material decisions surfaced by the report (distribution changes, hiring, cash floor breach response). Formalize with the 37signals framework.
  • deep-research
     — for benchmark questions ("what's a typical SaaS marketing budget as % of ARR?") that inform scenario inputs.
  • personal-cfo
     — 姊妹工具。personal-cfo处理家庭财务（家庭收支、月度现金流、大额采购）。将相同原则（交易求和法、场景建模）应用于不同范围。
  • company-brain
     — CFO报告将存储并在维基中索引。company-brain的
    outputs/
    目录累积月度报告；维基页面汇总跨月趋势。
  • toolify
     — 连接公司特定数据源（Mercury API、Stripe、Plane、Ramp或等效工具）。首次运行集成设置。
  • loopify
     — 安排月度运行（每月1日）+每周现金动态（周一上午9点）。
  • decide
     — 处理报告中提出的重大决策（分配变更、招聘、现金底线突破应对）。使用37signals框架进行正式化。
  • deep-research
     — 处理基准问题（“典型SaaS营销预算占ARR的百分比是多少？”），为场景输入提供信息。

Notes on quality

质量注意事项

  • Never invent methodology. Every company computes cash differently — trust the company's 
    CLAUDE.md
    in 
    ${COMPANY_CFO_ROOT}
    . If it's not documented, ask; don't guess.
  • Transaction-sum method is non-negotiable. Walkback from a balance snapshot has burned CFO workflows repeatedly. Use raw transaction sums, verify against current balance.
  • Categorization discipline matters more than accuracy. Same categories every month = trend-readable. Changing categories mid-year = trends become noise.
  • Baseline expenses to actuals, not to "safe" estimates. A software line modeled at $8K when actuals run $12K creates optimistic projections that break the model.
  • Revenue is net of processing fees, not gross. ~3% Stripe/similar processor fees materially change monthly cash inflow.
  • The intramonth cycle low matters more than EOM. With monthly payout cadences, cash dips deep mid-month. Cash floor applies to the LOW, not the EOM HIGH.
  • Weekly payouts smooth the cycle dramatically — if your payment processor supports it, switching from monthly to weekly payouts is one of the highest-leverage cash-management moves available. See 
    references/eom-cash-methodology.md
    .
  • When numbers don't reconcile, stop. Don't ship a report with unexplained gaps. Investigate first — a $42K reconciliation gap once propagated silently for weeks before being caught.
  • 切勿自行创建方法。 每家公司的现金计算方式不同——请信任
    ${COMPANY_CFO_ROOT}
    中的公司
    CLAUDE.md
    。如果未记录，请询问；不要猜测。
  • 交易求和法是必须遵守的。 从余额快照回溯的方法曾多次导致CFO工作流程出错。请使用原始交易求和，并与当前余额验证。
  • 分类原则比准确性更重要。 每月使用相同的类别=趋势可读。年中更改类别=趋势变为噪音。
  • 费用基线基于实际数据，而非“安全”估计。 如果软件费用建模为8000美元，而实际为12000美元，会产生乐观的预测，导致模型失效。
  • 收入为扣除手续费后的净额，而非总额。 Stripe等处理器约3%的手续费会显著改变月度现金流入。
  • 月内周期低点比月末余额更重要。 对于月度付款周期，月中现金会大幅下降。现金底线适用于低点，而非月末高点。
  • 每周付款可大幅平滑周期——如果支付处理器支持，从月度付款切换为每周付款是可用的最高杠杆现金管理措施之一。请参考
    references/eom-cash-methodology.md
    。
  • 当数据无法对账时，请停止。 不要发布存在无法解释差异的报告。首先调查——曾有42000美元的对账差异在数周后才被发现，期间已悄然传播。

When NOT to use this skill

不适用场景

  • Ad-hoc single-number lookups ("what's our current cash?") — just query the bank source directly, don't run the full workflow.
  • Tax / accounting questions — out of scope; refer to your CPA.
  • Personal finance — use 
    personal-cfo
    instead.
  • Investor pitch financials — different discipline (multi-year projections, unit economics deep dives). This skill covers operational CFO cadence, not fundraising narrative.
  • 临时单个数值查询（“我们当前的现金余额是多少？”）——直接查询银行数据源即可，无需运行完整工作流。
  • 税务/会计问题——超出范围；请咨询CPA。
  • 个人财务——请使用
    personal-cfo
    。
  • 投资者推介财务数据——不同原则（多年预测、单位经济深度分析）。本技能涵盖运营CFO周期，而非融资叙事。