GMV、实收和退款别再混着报，先把销售额口径定清楚

教程定位

这篇教程解决什么问题

电商月会里最容易吵起来的数字，往往不是访客数、转化率或客单价，而是一个看似最基础的问题：这个月销售额到底是多少。

运营同事说本月 GMV 812 万，活动打爆了；财务同事说平台到账实收只有 736 万，还发生了 58 万退款；老板翻到另一页，又看到净销售 678 万。三个数字都像销售额，三个数字都不是完全错，但如果没人提前定义口径，会议就会从“这个月经营表现怎么样”变成“谁的数才算数”。

这篇教程只解决一个具体问题：把交易金额口径定清楚。你会得到一张销售指标口径表、一组可复制计算公式，以及一段可以放进月会材料里的使用说明。它会明确什么时候看 GMV，什么时候看实收，什么时候看退款，什么时候看净销售。

本文不讨论渠道 ROI，不做库存分析，也不替代财务确认收入。GMV、实收、退款和净销售是经营分析口径，用来判断交易规模、现金进入、退款影响和经营净结果。财务确认收入需要根据你们公司的收入确认政策、发票、履约义务、平台结算、税务处理和会计期间来定，不能简单等同于本文的净销售。

一句话先定边界：

GMV 看交易规模，实收看钱是否进来，退款看交易是否被冲回，净销售看扣除退款后的经营结果。月会可以同时展示这四个指标，但必须写清公式、时间口径和数据来源。

AI 在这件事里的价值，是帮你把订单表、支付流水、退款记录和财务规则拆成字段，生成口径表、计算公式、异常检查清单和月会说明。AI 不能替你决定公司最终收入确认，也不能在字段不清时擅自把“下单金额”“支付金额”“到账金额”“确认收入”混成一个销售额。

使用场景

什么情况下最适合用这一套

假设你是电商负责人，或者是运营和财务之间的对接人。月底复盘前，你从店铺后台导出订单表，运营组按“下单商品金额”汇总出 812 万，准备在月会上说活动增长 23%。财务从支付平台和结算单里导出实收流水，看到实际到账前金额是 736 万，再扣掉当月成功退款 58 万，得到净销售 678 万。

这时候出现了三个问题。

第一，运营觉得财务把活动成绩低估了。因为很多订单已经下单，只是有些用户还没有完成支付，或者部分订单用了平台优惠券、店铺券、积分抵扣。运营说：“活动热度确实起来了，GMV 就应该按用户下单金额看。”

第二，财务觉得运营在报喜。因为未支付订单不能算进真实现金流，退款成功的订单也不能继续算本月销售贡献。财务说：“钱没有收进来，或者已经退回去了，不能还当成销售额。”

第三，老板听完两个版本后，不知道该按哪个数字判断经营结果。GMV 高，说明交易规模好像不错；实收低，说明优惠、未支付、平台扣减影响不小；净销售更低，说明退款已经冲掉了一部分成果。如果月会只选一个数字，大家都会觉得不完整。如果月会把三个数字都摆出来，但不解释口径，又会继续混乱。

这篇教程适合三类人：

这篇不解决“为什么退款高”，也不解决“哪个渠道 ROI 更好”。这些是后续分析。本文先把最基础的交易金额口径立住：每个金额列到底代表什么，能不能加总，按什么时间归属，适合放在月会哪个位置。

1. 电商负责人，需要在月会上讲清本月交易规模、实收和退款影响。
2. 运营负责人，需要避免把 GMV、支付金额和净销售混在同一张报表里。
3. 财务对接人，需要把经营分析口径和财务确认收入规则分开说明。

材料准备

开始前先把材料和边界备齐

开始前请准备四类材料。材料不需要一开始就很干净，但字段名和样例必须足够清楚。所有真实订单号、用户手机号、地址、支付账号和内部结算账号都要先脱敏。

第一类是订单表。至少包含订单号、子订单号、下单时间、支付时间、订单状态、商品金额、优惠金额、应付金额、实付金额、支付状态、售后状态、买家 ID。订单表主要回答“用户下了什么单”“订单当前是什么状态”“订单侧显示的金额是多少”。

第二类是支付流水。至少包含支付流水号、订单号、支付成功时间、支付渠道、支付金额、平台补贴金额、店铺优惠金额、手续费、到账金额、支付状态。支付流水主要回答“钱是否支付成功”“实际支付了多少”“是否存在支付失败、重复支付或拆单支付”。

第三类是退款记录。至少包含退款单号、订单号、子订单号、退款申请时间、退款完成时间、退款状态、申请退款金额、实际退款金额、退款原因。退款记录主要回答“哪些钱已经退回去了”“退款应该归到哪个统计周期”。

第四类是财务确认收入规则。这里不是让 AI 直接算财务收入，而是让它知道边界。例如：公司按发货、签收、服务完成或平台结算确认收入；平台手续费是否冲减收入；跨月退款如何处理；发票和收入确认是否同月。把规则提供给 AI 的目的，是让它在输出里提醒“本文净销售不是财务确认收入”，而不是让它擅自替财务入账。

开始前还要先约定 5 个口径问题：

1. GMV 是否只统计已下单，还是只统计已支付订单的下单金额。很多公司把 GMV 定义为“支付成功订单的成交金额”，也有团队在活动实时看板里把“下单金额”作为广义 GMV。两者必须写清。
2. 实收按订单表的实付金额，还是按支付流水的支付成功金额。月会建议以支付流水为准，因为订单表金额可能被拆单、合并单、优惠分摊影响。
3. 退款按申请时间还是完成时间归属。经营月会通常建议用“退款完成时间”，因为只有成功退款才真正冲回交易结果。但售后过程分析可以另看申请时间。
4. 净销售是否等于实收减成功退款。对经营分析来说可以这样定义，但必须标注“不等同财务确认收入”。
5. 跨月订单怎么处理。比如 6 月支付、7 月退款，6 月月会是否展示当月实收，7 月月会是否冲减净销售。这个规则要固定，不能每月临时改。

实操流程

按这套步骤把工作跑起来

【第一步：先列指标，不要先汇总销售额】

不要一上来就让 AI “帮我算销售额”。先让它根据订单表、支付流水和退款记录，整理一张销售指标口径表。表里至少包含指标名称、业务含义、推荐公式、数据来源、时间归属、适用场景、不能用于什么场景。

建议先定义 4 个主指标：

| 指标 | 推荐业务定义 | 主要用途 | 不适合用于 | | --- | --- | --- | --- | | GMV | 统计期内有效交易订单的成交规模，可按下单金额或支付成功订单应付金额定义，但必须写清 | 看活动规模、交易热度、商品成交盘子 | 直接代表到账现金或财务收入 | | 实收 | 统计期内支付成功的交易金额，建议以支付流水成功金额为准 | 看钱是否收进来、支付转化、现金进入 | 代表最终经营净结果 | | 退款 | 统计期内退款成功的实际退款金额，建议以退款完成时间归属 | 看交易冲回、售后影响、净销售扣减 | 代表所有售后申请或潜在风险 | | 净销售 | 实收减成功退款后的经营分析金额 | 看扣除退款后的销售结果，适合月会主结果 | 直接替代财务确认收入 |

这里最容易犯错的是把“销售额”当成一个万能词。建议月会材料里不要单独写“销售额 736 万”，而是写“支付实收 736 万”或“净销售 678 万”。每个标题都带口径，争议会少很多。

【第二步：确定时间归属】

同一笔订单至少有三个时间：下单时间、支付时间、退款完成时间。你必须先决定每个指标按哪个时间统计。

推荐口径如下：

| 指标 | 推荐时间字段 | 说明 | | --- | --- | --- | | GMV | 下单时间或支付时间，按团队定义固定 | 活动实时看下单时间，月度经营建议看支付成功订单的支付时间 | | 实收 | 支付成功时间 | 钱真正进来的时间 | | 退款 | 退款完成时间 | 退款真正完成的时间 | | 净销售 | 实收按支付成功时间，退款按退款完成时间 | 体现本月现金交易进入和本月退款冲回 |

如果你的月会需要解释活动当天热度，可以单独展示“下单 GMV”。如果你的月会要判断月度经营结果，建议主表使用“支付 GMV、实收、退款、净销售”。两者不是谁对谁错，而是使用场景不同。

跨月要特别说明。比如用户 6 月 28 日支付 1000 元，7 月 3 日退款 1000 元。6 月经营月会可以统计 6 月实收 1000 元；7 月经营月会统计 7 月退款 1000 元，并在净销售中扣减。财务是否在 6 月确认收入、是否在 7 月冲回收入，要看财务确认规则，不能由经营净销售直接决定。

【第三步：把计算公式写成可执行规则】

口径表不能只写“GMV 等于订单金额”。你需要把过滤条件、状态条件、去重条件写清楚。

可以先用下面这组经营分析公式：

如果订单表存在父订单和子订单，要特别处理重复金额。常见情况是一个父订单有多个子订单行，每行都显示同一个订单级支付金额。如果直接按行汇总，实收会被放大。

建议增加两个字段：

| 字段 | 含义 | 用法 | | --- | --- | --- | | order_amount_once | 订单级金额只保留一次 | 按订单级统计 GMV 或实收时使用 | | item_amount | 商品行金额 | 按 SKU、类目、商品统计时使用 |

让 AI 写公式时，要让它明确“订单级金额不能在商品行直接加总”。这个提醒比公式本身还重要。

【第四步：区分经营净销售和财务确认收入】

这是本文最重要的边界。经营净销售可以定义为“支付成功金额减成功退款金额”，用于月会观察本月交易结果。但财务确认收入不一定等于净销售。

原因至少有四个：

所以月会可以这样写：

这段话建议直接放在月会材料脚注里，尤其是第一次统一口径时。

【第五步：让 AI 输出口径表和异常清单】

当你把字段样例给 AI 后，不要只要一个汇总数字。让它先输出两张表。

第一张是销售指标口径表，字段包括：指标名称、业务含义、公式、数据来源、时间字段、过滤条件、适用场景、人工确认点。

第二张是异常检查清单，至少包含：

异常清单不是为了难为数据同事，而是为了让月会数字经得起追问。只要你提前把异常和处理规则说清楚，会议上就不会临时陷入“这个数是不是漏算了”的争论。

【第六步：制作月会使用说明】

月会里不要把所有公式念一遍。你需要的是一段可以让管理层快速理解的说明。

建议月会主表按这个顺序展示：

| 指标 | 本月 | 上月 | 环比 | 月会解读 | | --- | ---: | ---: | ---: | --- | | 支付 GMV | 760 万 | 710 万 | +7.0% | 支付成功交易规模扩大 | | 实收 | 736 万 | 692 万 | +6.4% | 实际支付金额增长，但低于支付 GMV，需看优惠和抵扣 | | 成功退款 | 58 万 | 41 万 | +41.5% | 退款冲回变大，需要售后另做原因分析 | | 净销售 | 678 万 | 651 万 | +4.1% | 扣除退款后仍增长，但增速低于实收 |

月会说明可以这样写：

这样汇报的好处是，每个团队都能看到自己关心的东西。运营可以用 GMV 和实收解释活动规模，财务可以用实收和退款解释现金进入与冲回，老板可以用净销售看经营结果。大家不再争“哪个才是唯一销售额”，而是讨论“这四个指标之间为什么出现差异”。

1. 收入确认可能按发货、签收、服务完成或平台结算，而不是按支付成功。
2. 平台手续费、达人佣金、运费、税费、补贴和积分，可能有不同会计处理。
3. 跨月退款、售后赔付和坏账处理，可能需要按财务政策调整期间。
4. 有些订单已经支付但未履约，经营上可算实收，财务上未必能确认收入。

• 订单表中支付状态成功，但支付流水找不到成功记录。
• 支付流水成功，但订单表状态为取消或关闭。
• 同一订单出现多笔成功支付，需要判断是否重复支付或拆单支付。
• 退款记录成功，但退款金额大于实收金额。
• 退款申请成功和退款完成时间跨月，需要明确归属。
• 子订单行重复展示父订单金额，导致 GMV 或实收重复加总。
• 测试单、刷单、内部单是否应排除。

支付 GMV = SUM(支付成功订单的应付金额或成交金额)
实收 = SUM(支付流水中支付状态为成功的支付金额)
成功退款 = SUM(退款记录中退款状态为成功的实际退款金额)
净销售 = 实收 - 成功退款

下单 GMV = SUM(统计期内创建订单的商品原价或下单应付金额)
未支付金额 = SUM(已下单但未支付订单的应付金额)
优惠影响 = 支付 GMV - 实收，需按字段确认是否包含平台补贴、店铺券、积分抵扣
退款率 = 成功退款 / 实收

本页销售类指标为经营分析口径：
- GMV 用于观察交易规模。
- 实收用于观察支付成功金额。
- 退款用于观察已完成退款对经营结果的冲回。
- 净销售 = 实收 - 成功退款，用于经营月会讨论。

以上口径不等同于财务确认收入。财务收入以公司收入确认规则和财务报表为准。

本月销售口径统一为四层：
1. GMV 看交易规模，不代表实际到账。
2. 实收看支付成功金额，不扣除后续退款。
3. 退款看本月退款完成金额，用来衡量交易冲回。
4. 净销售 = 实收 - 成功退款，用作本月经营结果主指标。

本页不使用“销售额”这个模糊词。需要对外或对财务报表使用的数据，另按财务确认收入口径。

输入示例

可以直接参考的输入材料

下面是一组虚构的脱敏样例，用来演示怎么把材料交给 AI。真实使用时，请删除真实用户信息、支付账号、手机号、地址和内部结算账号。

订单表样例：

支付流水样例：

退款记录样例：

业务补充说明：

order_id,sub_order_id,created_at,paid_at,order_status,pay_status,item_name,sku_id,item_amount,order_payable_amount,order_paid_amount,buyer_id,note
O20260601001,SO20260601001-1,2026-06-01 10:02:11,2026-06-01 10:04:20,已支付,支付成功,防晒喷雾,SKU-SPRAY-150,138.00,236.00,236.00,B10001,父订单含两个子订单
O20260601001,SO20260601001-2,2026-06-01 10:02:11,2026-06-01 10:04:20,已支付,支付成功,晒后修护凝胶,SKU-GEL-80,98.00,236.00,236.00,B10001,父订单金额重复展示
O20260602013,SO20260602013-1,2026-06-02 21:12:09,,待付款,未支付,旅行套装,SKU-TRAVEL-SET,129.00,129.00,0.00,B10009,下单未支付
O20260603022,SO20260603022-1,2026-06-03 18:20:33,2026-06-03 18:22:01,已退款,支付成功,精华液,SKU-SERUM-30,169.00,169.00,169.00,B10018,后续发生退款
O20260604031,SO20260604031-1,2026-06-04 09:18:06,2026-06-04 09:20:55,已支付,支付成功,洁面乳,SKU-CLEAN-100,69.00,69.00,69.00,T90001,内部测试单

payment_id,order_id,pay_success_at,pay_channel,payment_status,pay_amount,platform_subsidy,shop_coupon,fee_amount,settlement_amount
P20260601001,O20260601001,2026-06-01 10:04:20,微信支付,成功,236.00,0.00,20.00,1.42,234.58
P20260603022,O20260603022,2026-06-03 18:22:01,支付宝,成功,169.00,0.00,30.00,1.01,167.99
P20260604031,O20260604031,2026-06-04 09:20:55,微信支付,成功,69.00,0.00,0.00,0.41,68.59

refund_id,order_id,sub_order_id,refund_apply_at,refund_completed_at,refund_status,refund_apply_amount,refund_actual_amount,refund_reason
R20260603022,O20260603022,SO20260603022-1,2026-06-05 11:02:00,2026-06-06 14:15:33,退款成功,169.00,169.00,买家不想要
R20260601001,O20260601001,SO20260601001-2,2026-06-30 23:10:00,2026-07-01 09:18:40,退款成功,98.00,98.00,跨月退款

1. 月会使用经营分析口径，不直接作为财务确认收入。
2. 支付 GMV 只统计支付成功订单，按支付成功时间归属。
3. 实收以支付流水 pay_amount 为准，不以订单表重复展示的 order_paid_amount 逐行加总。
4. 退款只统计退款状态为“退款成功”的 actual amount，按退款完成时间归属。
5. 内部测试单 buyer_id 以 T 开头，本月经营报表排除。
6. 净销售 = 实收 - 当月退款成功金额。

提示词

可复制使用的提示词

如果你们已经使用 SQL 或 BI，可以让 AI 继续输出伪 SQL。注意它只能作为思路，真正运行前要由数据同事按你们的表结构改写。

这段伪 SQL 还要根据真实情况调整。比如跨月退款是否要在退款完成月扣减，还是要回溯原支付月冲减，你们必须先定规则。本文推荐月会经营口径按退款完成月扣减，但财务可以另按会计规则处理。

你是电商数据分析助手。请根据我提供的订单表字段、支付流水、退款记录和业务补充说明，帮我统一 GMV、实收、退款、净销售四类销售指标口径。

请严格遵守：
1. 不要把 GMV、实收、净销售、财务确认收入混为一个“销售额”。
2. 输出时必须说明每个指标的业务含义、公式、数据来源、时间归属、过滤条件、适用场景和人工确认点。
3. GMV 用于看交易规模，实收用于看支付成功金额，退款用于看退款完成金额，净销售用于经营月会讨论。
4. 财务确认收入只作为边界提醒，不要替财务做会计确认。
5. 如果订单表存在父订单金额在多子订单行重复展示，请提醒不能逐行加总订单级金额。
6. 退款只按退款成功金额统计；退款申请中、退款关闭、退款失败不能计入成功退款。
7. 如果字段含义不明确，请列入“需人工确认”，不要擅自猜测。

请输出四部分：
A. 销售指标口径表，字段为：指标名称｜业务含义｜推荐公式｜数据来源｜时间字段｜过滤条件｜适用场景｜不能用于｜人工确认点
B. 计算公式，用自然语言和伪 SQL 各写一版
C. 异常检查清单，列出至少 8 类可能导致数字错的情况
D. 月会使用说明，用 150 到 250 字说明本页销售类指标如何解读，并明确“不等同财务确认收入”

下面是材料：
【订单表字段和样例】
在这里粘贴订单表字段与脱敏样例

【支付流水字段和样例】
在这里粘贴支付流水字段与脱敏样例

【退款记录字段和样例】
在这里粘贴退款记录字段与脱敏样例

【业务补充说明】
在这里粘贴你们已确认的口径规则

-- 伪 SQL，仅用于说明口径，不代表可直接在你的数据库运行
WITH valid_payments AS (
  SELECT
    order_id,
    DATE_TRUNC('month', pay_success_at) AS stat_month,
    SUM(pay_amount) AS paid_amount
  FROM payment_flow
  WHERE payment_status = '成功'
    AND buyer_id NOT LIKE 'T%'
  GROUP BY order_id, DATE_TRUNC('month', pay_success_at)
),
successful_refunds AS (
  SELECT
    order_id,
    DATE_TRUNC('month', refund_completed_at) AS stat_month,
    SUM(refund_actual_amount) AS refund_amount
  FROM refund_record
  WHERE refund_status = '退款成功'
  GROUP BY order_id, DATE_TRUNC('month', refund_completed_at)
)
SELECT
  p.stat_month,
  SUM(p.paid_amount) AS received_amount,
  COALESCE(SUM(r.refund_amount), 0) AS successful_refund_amount,
  SUM(p.paid_amount) - COALESCE(SUM(r.refund_amount), 0) AS net_sales
FROM valid_payments p
LEFT JOIN successful_refunds r
  ON p.order_id = r.order_id
 AND p.stat_month = r.stat_month
GROUP BY p.stat_month;

输出样例

AI 应该输出到什么程度

下面是 AI 根据上方输入可能输出的初稿。你可以把它作为月会口径说明的起点，但不能不经检查就放进正式报表。

AI 还可能输出一段月会说明：

这份输出方向是对的，但你还要继续追问几个问题：

如果这些问题没有确认，AI 输出再工整，也只是一个看起来像表格的草稿。

• 支付 GMV 使用“订单应付金额”还是“商品成交金额”，是否和实收存在优惠差异。
• 实收是否需要扣除平台手续费。经营分析通常不扣手续费，毛利或结算分析才看手续费。
• 退款是否包含运费、赔付、平台补偿。不同平台字段可能不同。
• 跨月退款是否按完成月扣减，是否需要在月会中单独列“本月退款中来自历史订单的金额”。
• 内部测试单、刷单、异常单是否有稳定排除规则。

| 指标名称 | 业务含义 | 推荐公式 | 数据来源 | 时间字段 | 过滤条件 | 适用场景 | 不能用于 | 人工确认点 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 支付 GMV | 支付成功订单形成的交易规模 | SUM(支付成功订单的订单应付金额，订单级去重) | 订单表加支付流水 | pay_success_at | 支付状态成功，排除测试单，订单级金额去重 | 看活动交易规模和成交盘子 | 不能代表实际到账和财务收入 | 应付金额是否已扣店铺优惠，父订单金额是否重复展示 |
| 实收 | 支付成功的金额 | SUM(payment_flow.pay_amount) | 支付流水 | pay_success_at | payment_status=成功，排除测试单和重复支付 | 看现金进入和支付成功规模 | 不能直接代表最终净结果 | pay_amount 是否含平台补贴、积分、储值卡 |
| 成功退款 | 已完成退款的实际金额 | SUM(refund_actual_amount) | 退款记录 | refund_completed_at | refund_status=退款成功 | 看交易冲回和售后影响 | 不能代表所有退款申请 | 部分退款、多次退款、跨月退款规则 |
| 净销售 | 扣除成功退款后的经营销售结果 | 实收 - 成功退款 | 支付流水加退款记录 | 支付按支付成功月，退款按完成月 | 同上 | 月会经营结果主指标 | 不能等同财务确认收入 | 是否与财务收入确认另表区分 |

本月销售类指标统一为经营分析口径。GMV 用于观察支付成功交易规模，实收用于观察支付流水中的成功支付金额，退款仅统计本月退款完成且状态为成功的实际退款金额。月会主结果使用净销售，即实收减成功退款，用来判断扣除退款冲回后的经营表现。以上口径用于经营复盘，不等同于财务确认收入；财务收入仍以公司收入确认规则和财务报表为准。

人工验收

人要怎么检查和改到可用

AI 输出后，人工检查至少分 7 步。

第一步，检查指标名称是否带口径。把“销售额”改成“支付 GMV”“实收”“净销售”。如果必须使用“销售额”这个词，也要在标题旁写清“本文销售额指经营净销售”。

第二步，检查金额字段是否选对。订单表里的 `order_paid_amount` 可能是父订单金额，不能在子订单行直接加总。支付流水的 `pay_amount` 通常更适合算实收，但也要确认是否包含储值卡、积分、平台补贴、礼品卡或组合支付。

第三步，检查时间字段是否一致。GMV 如果按下单时间，实收按支付时间，退款按完成时间，月会里必须说明。不要把下单时间筛出的订单和支付时间筛出的流水硬拼在一起。

第四步，检查退款状态。只有退款成功才计入成功退款。退款申请中、审核中、退款关闭、退款失败，都不能冲减净销售。它们可以进入售后风险观察，但不能和成功退款混在一起。

第五步，检查跨月处理。跨月退款很常见。建议月会经营口径固定为“实收按支付成功月，退款按退款完成月，净销售在当月扣减”。如果团队更想看订单生命周期，可以另做“按原订单月回溯退款”的分析页，不能把两套口径混在同一张主表里。

第六步，检查财务边界。凡是出现“确认收入”“会计收入”“报表收入”的地方，都要确认是否由财务提供。如果只是经营分析，就写“净销售”，不要写“确认收入”。这一步能避免后续对账时出现口径责任不清。

第七步，做抽样核验。至少抽 20 笔订单：

| 抽样类型 | 抽样数量 | 检查点 | | --- | ---: | --- | | 普通支付订单 | 5 | 支付流水金额是否等于实收统计金额 | | 多子订单合并支付 | 5 | 父订单金额是否只算一次 | | 成功退款订单 | 5 | 退款金额、完成时间、订单关联是否正确 | | 跨月退款订单 | 3 | 是否按约定月份扣减 | | 测试单或异常单 | 2 | 是否按规则排除并保留原因 |

抽样不通过时，不要在月会数字上手工改几个金额。应该回到口径表和计算规则，把规则改清楚，再重新生成汇总。

失败反例

这些失败反例要提前避开

反例 1：把下单 GMV 当成实收来报喜。

错误写法：

问题在于，这个 812 万可能包含未支付订单、取消订单、用户下单后未付款金额，也可能没有扣掉优惠。它能说明活动热度，但不能说明钱已经收进来。正确写法应该是：

反例 2：把订单表父订单金额逐行加总。

一个父订单 O001 下有 3 个子订单，每一行都显示 `order_paid_amount=300`。如果按行加总，就会得到 900，但用户实际只支付了 300。这种错误在商品明细表里非常常见。

正确做法是：订单级金额按 `order_id` 去重，只保留一次；商品行分析使用已经分摊到 SKU 的 `item_amount`。如果没有商品行分摊金额，就不要用父订单金额直接做 SKU 销售额排行。

反例 3：把退款申请金额直接冲减净销售。

退款申请不等于退款成功。用户可能申请 200 元，客服审核后只退 80 元；也可能申请后关闭；还可能跨月才完成。把申请金额直接扣掉，会让净销售偏低，也会让退款率失真。

正确做法是：经营净销售只扣 `refund_status=退款成功` 的 `refund_actual_amount`，并按你们约定的退款完成时间归属。申请中退款可以放在售后风险页，不进入净销售主公式。

反例 4：把净销售写成财务确认收入。

经营净销售等于实收减成功退款，看起来很接近“收入”，但它不是会计收入。某些订单已经支付但未发货，财务可能尚未确认收入；某些平台手续费、税费、佣金、跨期退款，也可能需要按财务规则处理。

正确写法是：月会主表使用“经营净销售”，并在脚注说明“不等同财务确认收入”。财务确认收入由财务按公司收入确认规则另行提供。

反例 5：月会每页换一个销售额口径。

第一页写销售额 812 万，第二页写销售额 736 万，第三页写销售额 678 万，但没有说明分别是什么。这样的材料会让所有人失去信任。

正确做法是：每页标题带口径。例如“下单 GMV 趋势”“支付实收趋势”“成功退款趋势”“经营净销售趋势”。如果需要综合页，就同时列出四个指标，不能把它们都叫销售额。

本月销售额 812 万，环比增长 23%。

本月下单 GMV 812 万，用于观察活动交易热度；支付实收 736 万，用于观察支付成功金额。两者差额主要来自未支付订单和优惠抵扣，需单独解释。

主题边界

它和相邻主题的区别

本文只讲交易金额口径，重点是 GMV、实收、退款和净销售怎么定义、怎么计算、怎么在月会使用。它和几个相邻主题要分开。

第一，它不是渠道 ROI 分析。渠道 ROI 需要把投放花费、达人佣金、渠道归因、转化路径和毛利放进去。本文只处理交易金额，不判断哪个渠道更赚钱。

第二，它不是库存分析。库存分析要看 SKU 库存、周转天数、缺货、滞销、补货和仓配。本文只在需要时提醒商品行金额不要和订单级金额混算，不讨论库存结构。

第三，它不是退款原因分析。本文会定义成功退款金额如何扣减净销售，但不会分析退款为什么发生。退款原因需要结合售后工单、商品质量、客服沟通、物流和用户反馈另做专题。

第四，它不是财务收入确认教程。本文会反复提醒净销售不等同财务确认收入，但不会替财务决定收入确认时点、税务处理、平台结算和会计分录。经营月会可以用净销售做管理判断，财务报表必须以财务规则为准。

第五，它不是完整经营复盘。销售指标口径统一后，月会还要继续解释：GMV 为什么增长，实收为什么低于 GMV，退款为什么升高，净销售增长是否健康。但这些分析都建立在一个前提上：每个金额指标先不要打架。

如果你只记住一条原则，就记这句：

不要再问“销售额到底是多少”，先问“这页销售额指 GMV、实收、退款后净销售，还是财务确认收入”。口径一清楚，数据才开始有讨论价值。