星耀图 · 财务工作台
电商服务 / 广告代理(快手磁力金牛、腾讯视频号、抖音千川)。隶属广州鹏云。名义 9 人,实际构成为:在职领薪 4 人 + 无薪股东 4 人 + 已离职 1 人。本工作台整合 8–9 月财务报表、内部流水、客户对账单与工资表,用于经营决策与风险管控。
一、资方结算台(资金双向轧账)资金视角 · 全盘轧账
把我们打给资方的钱和资方打回给我们的钱放在同一张表里轧。§2 是利润视角(贴补收入是否到账,量级约 2 万);本节是资金视角(两边银行流水是否轧平,量级约 38 万)——利润算对了不代表钱平了,两个视角必须同时看。两张表数据互相独立、各录各的,不重复。
| 日期 | 对手方 | 摘要 | 我方对私已付(本金) | 我方对公已收 | 应收回款(置换) | 差额(谁欠谁) | 收款方(对公到账户) |
|---|
逻辑只有一条(一行 = 一笔业务):①「我方对私已付」填你打出去的本金;②系统自动置换应收回款 = 已付 ÷(1−现金点)(贴补按总回款计:打 10,000 回 10,582);③「我方对公已收」填实际到账的钱;④差额 = 已收 − 应收:正数 = 我欠资方(多收了,应补回),负数 = 资方欠我(没回够,应催收),0 = 轧平。
例:对私打 19,138.76 → 置换应收 19,138.76 ÷0.945 = 20,252.66;资方实际回 50,000 → 50,000 − 20,252.66 = 29,747.34,我欠资方。回款多就自动是"我欠资方",回款少就自动是"资方欠我"——一个差额管两个方向,不需要你判断。合计行是全部行的净额,顶部「当前净状态」给最终结论。改顶部现金点,全表实时重算。「对手方」填这笔业务的对方(资方/客户/打款人),「收款方」填对公回款进哪个账户,默认星耀图公户。
二、资方贴补到账台账利润视角 · 只追贴补
和 §1 不是重复的:§1 管含本金的全盘资金是否轧平(约 38 万,一行的"已付/已收"是本金+贴补合在一起的银行流水);本节把贴补这块利润单独拆出来逐笔追"应收 vs 已收"(约 2 万),是查清 10,004.96 元差额的工具。每笔业务结束当天录入一次。
| 日期 | 客户 | 面值 | 客户付款(对私) | 贴补% | 应收贴补 | 已收贴补 | 未收 |
|---|
贴补基数按2026-11-02 你确认的口径:贴补 = 总回款 × 点数,即 应收贴补 = 客户对私付款 ÷(1−点数) × 点数(不是面值,也不是"付款 × 点数")。对私 10,000 → 应收回款 10,582 → 贴补 582;未收 = 应收 − 已收。"已收"列未填即按 0 计,请先补填已收,未收列才会显示真实差额。
现金点:已按你的决定全盘统一 5.5%(含历史"票点5"那部分),示例数据每行都填了 5.5。个别老单若确实按 5% 结清,改那一行即可,合计会实时重算。异常提醒:若某笔已收长期挂账(如超过约定周期 30 天),应转为催款动作而非继续等待。另见 §1 资方结算台——本节追的是贴补本金(约 2 万),§1 追的是含本金的全额资金盘(约 38 万)与双向轧账。
怎么对照 10,004.96:贴补是纯利,少收 1 元净利就少 1 元。全盘应收贴补合计 见下表合计(旧口径示例值 19,912.01,按 ÷0.945 新口径重算约 21,071.23)。填完"已收"后,若"未收差额"≈ 10,004.96,说明差额已全部定位为贴补未到账;若明显小于它,说明还有别的漏损(对公付款、客户回款、其他成本),要继续追。
三、每日对公 / 对私流水表(逐笔明细)
收款行填"收入方"(资金来源,谁付给我们),付款行填"支出方"(资金去向,我们付给谁),一行只填其一。"账户类型"按资金实际走向选"对公"或"对私"。
| 日期 | 账户类型 | 摘要 | 收入方 | 支出方 | 收入 | 支出 | 余额 |
|---|
余额为逐行滚动:本行余额 = 上行余额 + 收入 − 支出;改"期初余额"可整体平移。载入的示例为内部账非充值类收支(源表未区分公私账户,默认标为对公,请按实际改)。建议"对手方"列注明对应协议或业务背景——对私逐笔记录的用途若被质疑,这列是说明资金性质最省事的依据。
四、现金点 / 账户点 换算器
资方给的 5.5 是现金点,给客户的 6 是账户点,两者单位不同、不能直接相加减。本模块把两者统一到同一单位再算净利,避免谈政策时算错。
精确公式:净利 = 客户现金 × [ (1+现金点) − (1+账户点) ÷ (1+端口点) ]。线性加减(端口点 + 现金点 − 账户点)只是一阶近似,忽略乘积项,点数越大偏差越大——百度组合(30/27/5.5)下精确值 3.1378%、线性值 2.50%,已偏离 0.64 个百分点;若客户账户点谈到 20 个点,偏差会突破 1 个点。谈政策时务必先问清对方报的是账户点还是现金点。
| 术语 | 别名(含易混叫法) | 方向 | 含义 |
|---|---|---|---|
| 现金点 | 票点、补贴点、返点 | 收入 | 资方在客户对私付款基础上额外补回的比例,是收入项。2026-10-30 起全盘统一按 5.5% 记账,历史"票点5"不再单独分档 |
| 账户点 | 充值点位 | 让利 | 给客户的充值加成,如付 10000 充 10600 即 6 个点 |
| 端口点 | 对公政策、返点 | 收入 | 上游端口给我们的折扣,决定付上游多少钱 |
术语纪律(2026-10-30 立):对账单里的「票点」经你确认就是资方补贴的现金点(历史上挂过 5%,现已全盘统一按 5.5% 记账),不是发票票点、不是成本。但"票点"这个叫法字面就是"开票点数",一旦换人或隔一段时间复查,极可能被当成 5% 的成本项冲减利润——金额量级足以让全盘由盈转亏。建议台账与内部沟通一律改用"现金点/补贴点","票点"仅保留在对账单原始备注对应处。
五、盈亏测算器(可复用)
业务模型:客户按对私政策付款 → 公司打给资方 → 资方按对公贴补点数转回对公 → 公司向端口对公充值。修改下方参数即可实时测算,谈政策、谈客户时可直接用。
六、盈亏平衡倒推器
已知月成本 14,579 元,倒推需要做到多大规模才能不亏。当前月均面值约 128,854 元。改下面任一参数即可实时测算。下方三行情景表随上方「月成本 / 当前月均面值」实时重算(v1.14 起),不再是写死数字。
| 情景 | 每万元面值净利 | 净利率 | 打平所需月面值 | 是当前规模的 |
|---|
读法:三行的差距不是精度问题,是路线问题。走百度路径,打平门槛是抖音的 1/2.4、是维持现状的 1/6.4。但前提是百度能拿到同等规模——目前百度只做了 2 万面值,抖音做了 19.2 万,结构是反的。另外注意:落袋实际(29.9 倍)与抖音理论(11.2 倍)差 2.7 倍,这个缺口本身就是 10,004.96 元差额的直接后果——先查清差额,再谈规模目标。
七、家底盘点
净资产已为负,公司处在资不抵债状态;亏损主要来自管理费用,而非业务毛利。带「实时」的 4 张卡由「十三、月度财务报表」云端数据生成;带「快照」的是 2026-10 对账单分析结论或固定口径假设,不随录入变化(v1.14 起明确区分)。
八、月度财报对比(实时)
本区由「十三、月度财务报表」云端数据自动生成,取最近两个月份对比(v1.14 起不再是 8/9 月写死快照)。只列出月报表中实际存在的科目。两个月累计营业收入若完全一致,说明当月单月没有任何收入入账,而客户对账单显示业务确有发生——这个差额需解释。
| 科目 | 上月末 | 本月末 | 变动 |
|---|
| 利润表(累计) | 上月 | 本月 | 单月发生 |
|---|
9 月对账单实际发生的客户充值:欢乐精选 9/7、红不让 9/10、欢乐童年 9/22,合计面值 31,950 元、客户付款约 30,000 元 —— 报表收入为 0,业务与账务已脱节。
九、客户利润明细
口径:净利 = 客户对私付款 ×(1+资方贴补)− 公司对公付款。本表由下方「十、客户充值利润表」按客户 + 端口实时汇总生成,随云端数据自动更新(v1.13 起,不再是对账单静态快照)。同客户多笔合并为一行:期间取各行日期、政策多档并列、面值与净利累计。
| 客户 / 端口 | 期间 | 面值 | 客户政策 | 对公政策 | 净利 |
|---|
历史口径锚点(2026-10 对账快照,仅供追溯):百度净利 241–433 元/万元面值,抖音仅约 101 元/万元 —— 百度利润率是抖音的 2.4–4.3 倍,但当前业务量结构正相反(抖音 19.2 万面值 vs 百度 2 万面值)。
十、客户充值利润表(平台 + 品类两层)
按你确认的分类维度:平台(抖音千川 / 快手磁力金牛 / 腾讯视频号 / 百度)+ 品类(充值 / 微信豆 / 开户)。填面值与两端政策即可自动算出净利,并按平台、品类分别汇总。注意:微信豆属于腾讯视频号体系下的品类,不与平台并列。
| 日期 | 客户 | 平台 | 品类 | 面值 | 客户政策 | 对公政策 | 贴补% | 客户付款 | 对公付款 | 贴补额 | 净利 |
|---|
| 按平台汇总 | 笔数 | 面值 | 净利 | 净利率 |
|---|
| 按品类汇总 | 笔数 | 面值 | 净利 | 净利率 |
|---|
计算口径(2026-11-02 三次修正,以你给的实算例为准):客户付款 = 面值 ÷ 客户政策;贴补额 = 客户付款 ÷(1−贴补%) × 贴补%(资方贴的是客户对私打款置换出的总回款:打 10,000 → 实收 10,582.01,贴补 582.01);对公付款 = 面值 ÷ 对公政策,对公政策填 0 或留空 = 资方无折扣、按面值全价结算(此前填 0 会被算成"对公付 0",成本凭空消失,净利虚高到数万元);净利 = 客户付款 + 贴补额 − 对公付款。验算例(10/23 未来美丽前行):面值 10,450、客户政策 1.045、对公拿 0(全价)、贴 5.5% → 客户付 10,000 + 贴补 582.01 − 对公付 10,450 = 净利 132.01,与你手算一致。豆豆14月行(面值 45,000、同口径)→ 客户付 43,062.20 + 贴补 2,506.27 − 45,000 = 净利 568.47。净利显示保留两位小数(四舍五入)。注:贴补基数 2026-11-02 内先被误改为"对公付款"、当日晚已按你的实算例改回"客户付款",两版净利差 ≈ 对公付款−客户付款的 5.5% 量级,以本页现显示为准。
本表算出的是逐单理论净利,不等于落袋金额——落袋数据见第一节。§9 客户利润明细为旧口径静态快照,以本表动态重算为准。
十一、客户集中度预警(实时)
代理公司出事最常见的原因不是没客户,是客户太集中。本区由「十、客户充值利润表」云端数据按客户实时聚合生成(v1.14 起),新增录入立即反映到占比、CR1 / CR3 与风险等级。按面值口径计算。
十二、生存测算
现金基数取「十三、月度财务报表」最新月货币资金、下方情景表与上方卡片同源实时生成(v1.14 起);工资/社保/杂费为已确认的固定口径假设。已确认:在职领薪 4 人(李德 + 赵子琛 / 冷琛慧 / 陆瑞月),袁志伟已离职,另 4 位股东不领薪。工资按满勤口径计算;房租由鹏云承担、按月 0 元计。点击下方按钮可查看压力测试情景。
| 情景 | 月工资 | 社保 | 杂费 | 月业务利润 | 月净流出 | 可支撑 |
|---|
口径说明:工资按工资表满勤底薪(李德 2,500、销售 2,900/人);社保为流水实际发生额 1,909.11 元(仅李德一人);杂费为流水非充值项剔除社保后 ÷ 2.7 个月,含设备租赁 204、电话卡月租、转账手续费、素材兼职、差旅;房租 = 0(鹏云承担,年内不撤);4 位股东不领薪、袁志伟已离职,故工资按 4 人计。社保敞口按你要求本年搁置,未计入上表。
十三、月度财务报表记录与分析
记录每月法定报表数据,自动算单月发生额与环比。核心用途是追踪报表数 vs 内部账数的差额——9 月报表收入为 0 而业务在跑,这个差额不收敛,风险会持续累积。
| 月份 | 营业收入 | 营业成本 | 管理费用 | 财务费用 | 净利润 | 货币资金 | 资产总计 | 负债合计 | 所有者权益 | 内部账业务收入 | 差异 |
|---|
| 分析项 | 8 月累计 | 9 月累计 | 9 月单月发生 |
|---|
"单月发生" = 9 月累计 − 8 月累计。9 月营业收入单月为 0,而客户对账单显示 9/7、9/10、9/22 共 3 笔、客户付款约 30,000 元——这是当前最需要解释的差异,已在"差异"列标红。仅两期数据不构成趋势,做同比或环比结论前至少攒够 6 期。
十四、风险清单
按严重程度分级。前两项属于合规与真实性问题,优先级高于盈利能力问题。本节为 2026-10 对账单分析结论(静态文档),引用的历史数字不随录入数据变化;实时数据见各动态表。
资方兑换业务需确保三流一致
对私款打给资方、资方对公转回并贴补 5.5 个点。若合同流、资金流、发票流不一致,可能被认定为无真实交易的资金往来。须有书面协议、贴补收入依法入账纳税。
两套账:9 月约 3 万元业务流水未入账
9 月报表营业收入为 0,但客户对账单显示 9 月有充值发生。业务在跑、账上不确认,累积形成税务申报缺口。
利润 100% 依赖资方贴补
抖音业务贴补前为每万元亏 418 元,贴补后才转为赚 101 元。资方一旦停止或降低贴补,业务立即转亏,做得越多亏越多。
现金流仅够 1.08 个月,且依赖股东无薪工作
账面现金 15,277.84 元,已确认口径下月净流出 14,092 元。这个数字成立的前提是"4 位股东不领薪"——一旦他们开始领薪,月净流出升至 28,592 元,支撑时间腰斩至 0.53 个月。9 月已净流出 1,916.53 元,靠股东新增垫款 2,200 元维持。
隐性成本:4 位股东无薪劳动约 11,600 元/月未入账
按销售底薪 2,900 元/人估算,3 个月累计约 34,800 元,已超过报表累计亏损 29,952 元。这意味着公司当前的低成本不是经营效率,而是股东在贴人;报表亏损因此被系统性低估,据此做出的"能否扩张"判断会偏乐观。
理论利润与落袋金额差 10,004.96 元
含贴补理论利润 11,321.03 元,内部现金流水实际只落袋 1,316.07 元。贴补总额 19,912.01 元几乎未体现在现金流水里,这是首要待查项。
工资疑似私户发放
工资表两期实发 19,515.28 元(含已离职的袁志伟),而流水仅记录工资支出 1,800 元,差额 17,715 元去向不明,涉及个税与社保合规。当前在职领薪 4 人,另 4 位股东确认不领薪。
社保敞口(本年搁置,风险继续累积)
在职 3 名销售未参保,按广州 2026 年最低基数企业端约 1,337 元/人/月计,月敞口约 4,011 元;已离职的袁志伟在岗期间欠缴部分仍属历史敞口。依《社会保险法》第 58 条,用工 30 日内须登记;第 86 条按日加收万分之五滞纳金。已确认全员签有劳动合同,故双倍工资风险排除。
股东注资记成收入
7/27 张延峰股东注资 6,000 元记在流水"收入金额"栏,虚增利润且错判资金性质,应改为"其他应付款—股东借款"。
技术入股未评估、实收资本为 0
注册资本 10 万元认缴未实缴;法定代表人以技术入股若未评估作价并办理权属转移,法律上视为未履行出资义务。
十五、行动清单
按优先级排序,P0 为本周内应完成事项。本节为 2026-10 分析结论(静态文档),不随录入数据变化。
把人力往百度倾斜——百度利润率是抖音 2.4 倍以上,当前业务量结构相反。
重谈宣天下对公政策——1.015(1.5 个点)过低,是利润被压缩的主因。
锁定资方条款——取得书面协议,明确贴补基数、结算周期、持续性,并至少储备第二家资方。
处理 9 月 3 万元流水——确认未入账原因,补入账或统一口径,停止两套账。
核对资方贴补是否全额到账——含贴补理论 11,321.03,现金只落袋 1,316.07,差额 10,004.96 元需逐笔追
提规模或调结构,不要再压人数——月落袋利润仅 487 元,与月成本 1.46 万元相差约 29 倍。当前已是在职 4 人的最低配置,再减人会直接伤业务;出路是把面值规模做到 10 倍以上,或把人力往百度倾斜(利润率是抖音 2.4 倍以上)。
把"4 位股东无薪"书面化——明确是暂缓领薪还是永久放弃,以及未来补薪、股权调整的条件
更正 7/27 股东注资 6,000 元的记账——该笔记在"收入金额"栏,虚增利润、错判性质
补现金流量表、其他应付款 50,835 元明细
十六、待补资料
这些缺口不补齐,工作台中的测算无法转为账载事实。本节为待办清单(静态文档),不随录入数据变化。
遗留动作:台账统一改称"现金点 / 补贴点",不再使用"票点"——字面易被误读为发票票点(成本),属交接风险
十七、口径与决定(存档)
本节是决策日志(静态文档),按定义不随业务数据变化。所有影响数字的口径、外部确认的重大判断,统一记在这里,避免后来人重新理解一遍。修改沿革与推导过程见《星耀图工作台开发记录》。
| 日期 | 事项 | 口径 / 结论 | 状态 |
|---|---|---|---|
| 2026-10-30 | "票点"的定义 | 即资方补贴的现金点,属收入项、不是成本项(对账单「悠序/左岸香水」10/1–10/2 行备注写法)。已于本日全盘统一按 5.5% 记账;建议台账改称"现金点 / 补贴点",不再使用"票点"字面写法 | 已定案 |
| 2026-10-30 | 百度对公政策 | 原始客户表"对公政策"列为空,现按口头口径 1.27 测算,百度 674.44 元净利建立在假设之上;已按原始两笔(10/8 @1.27、10/25 @1.30)分行入账 | 待核实 |
| 2026-10-30 | 理论利润 vs 落袋 | 含贴补理论净利 11,321.03 元,内部现金实际落袋 1,316.07 元,待查差额 10,004.96 元;应收贴补 19,912.01 元几乎未在现金流水体现 | 追款中(用「二、资方贴补到账台账」逐笔追) |
| 2026-10-30 | 悠序 10,867.95 元 | = 累计充值 192,000 − 累计客户现金 181,132.05,实为累计给客户的返点(6 个账户点的累计兑现额),不是债权、不构成额外风险 | 已澄清 |
| 2026-10-30 | 账户点 vs 现金点 | 6 个账户点 ≈ 5.66% 现金让利;两者单位不同不可直接相加减,谈政策时必须用「四、换算器」统一单位,精确公式见该节 | 已定案 |
| 2026-10-30 | 数据可否保存 | 此前没有保存机制,刷新即丢失。现改为:自动存本机浏览器 + 每表「导出 Excel」+ 全站「备份 / 恢复 JSON」。云办公多设备场景请定期备份 | 已修复 |
| 2026-10-30 | 外部表格如何入账 | 每表「⬆ 导入表格」支持 xlsx / CSV,弹列映射面板;Excel 日期自动还原(含自定义格式)、金额千分位自动清理、列名自动匹配 + 类型校验。老版 .xls 不支持,需另存为 xlsx / CSV;多表文件取第一个工作表 | 已定案 |
本节只记已定案或待核实的口径。若某项被推翻,请同步修改本页对应板块与《工作台开发记录》,不要只在聊天里说明——工作台是唯一事实源。