先把问题拆成三层：客户在 Customer Portal 里做了什么，subscription 上的 paid seats 现在是多少，invoice 或 credit 什么时候生成。Polar 的 seat-based pricing 不是「谁被分配席位就收谁的钱」这么简单；一个 billing manager 可以买 5 个 seats，只分配 3 个，账单仍按 5 个 paid seats 走。
最容易出错的现场是团队客户发来一句「我删了两个人，为什么账单还是 5 seats」。这时不要先改价格，也不要手工退款。先去 Polar Dashboard 找这个 customer 的 subscription，看 seat count、seat status、最近一次 plan 或 seats update，以及组织的 proration 默认值。
是 seat assignment 变了，还是 paid quantity 变了？
Polar 文档把 seat-based product 拆成购买者和使用者两层：Customer 是付费实体，Member 是团队里的人，CustomerSeat 才是某个产品席位和成员之间的关系。这个模型对 B2B SaaS 很合理，但也会让账单排查多一层。
| 你看到的变化 | Polar 里的事实 | 对账单的影响 |
|---|---|---|
| 成员从 claimed 变 revoked | 某个用户权益被移除，seat 被空出来 | 不会自动降低 subscription quantity |
| 5 seats 里只分配了 3 个 | 还有 2 个未分配 seats | 仍按 5 个 paid seats 收费 |
| billing manager 增加到 8 seats | subscription paid seats 变成 8 | 可能立即收费，也可能下期体现 |
| billing manager 降到 3 seats | paid seats 减少 | 可能产生 prorated credit |
| 切到另一个团队计划 | product 变更 | 受 plan change 和 proration 共同影响 |
所以第一句回复客户可以很短：删除成员不等于减少付费席位。要停掉空余席位，需要减少 subscription 的 seat count。
Customer Portal 里客户到底能改什么？
Polar Customer Portal 是给客户自助处理订阅、历史订单、invoice、receipt、权益、取消订阅和付款方式的托管页面。它不会因为你不放入口就消失；Polar 文档写明 portal 总是可用，客户也会从交易邮件里拿到入口。
但客户能不能自己改 seat 和 plan，要看 Settings -> Customer portal：
| Portal 设置 | 打开后客户能做什么 | 关闭后的处理方式 |
|---|---|---|
| Enable subscription seat management | 改 seat 数，分配或撤销 teammates | 你用 Dashboard 或 Customer Seats API 做 |
| Enable subscription plan changes | 自助升级、降级或换 plan | 你用 Dashboard 或 Update Subscription endpoint 做 |
| Show metered usage | 看当前 usage consumption | 只影响 portal UI，不等于 usage 停止记录 |
| Allow email address changes | 客户改 customer email | 需要监听 customer.updated 同步到自家系统 |
如果客户说「我在 portal 改了数量」，你要问的是：他是撤销了成员，还是确实把 paid seats 从 5 改成 3。前者影响权益，后者影响账单。
invoice 为什么没有按客户预期立刻变化？
Polar 的 subscription 变更有三种 proration 行为。它们决定客户改 seat 或改 plan 后，账单是马上出现、下次体现，还是下个周期才生效。
| proration 行为 | subscription 何时变化 | invoice / credit 怎么出现 | 适合场景 |
|---|---|---|---|
invoice | 立即变化 | 立即开差额 invoice；升级收费，降级给 credit | 升级后马上收差价 |
prorate | 立即变化 | 差额进入下一张正常 invoice | 想减少客户被突然扣款的感觉 |
next_period | 下个周期变化 | 当前周期不出差额，更新排进 pending_update | 降级、保留当前周期权益 |
账单看起来「不一致」，很多时候只是这三种结果混在一起：Customer Portal 已经接受了客户动作，但 invoice 还没到生成时间；或者 paid seats 已经变了，但 credit 会在下次 invoice 才出现。
排查时看四个字段：subscription 当前 seats、pending_update、最近一次 invoice 的 line items、组织默认 proration behavior。只截图客户 portal 页面不够。
seat、quantity、invoice 对不上时看哪张表？
把客户邮件、后台订阅页和账单页放在一起，按下面这张表走。它比直接争论「应该收几个人」更快。
| 现象 | 先看的 Polar 对象 | 可能原因 | 下一步 |
|---|---|---|---|
| 客户删了成员但 invoice 仍是原金额 | CustomerSeat + subscription | revoke seat，不是 reduce paid seats | 让 billing manager 降低 seat count |
| 客户从 10 降到 6，invoice 还没 credit | subscription + proration | prorate 或 next_period | 看 pending_update 和下一张 invoice |
| 客户加 seat 后马上被扣费 | subscription update + invoice | proration behavior 是 invoice | 给客户解释剩余周期差额 |
| 已分配 seat 少于付费数 | CustomerSeat list | 购买了空余 seat | 提醒客户分配或减少 paid seats |
| invoice 税额比页面单价高 | invoice line items + billing address | 税费、地区和税行为影响 | 下载 invoice，看 tax breakdown |
| 客户换 plan 后 seat 不能改 | subscription product | 新旧 product 类型不兼容 | 确认都是 seat-based 或都不是 |
这里有一个硬事实：Polar 文档写明 flat subscription 不能直接切到 seat-based product，反过来也一样。遇到 plan change 失败，不要只盯金额，先看产品类型。
billing manager、member 与权益的财务误区
seat-based pricing 的购买者通常是 billing manager，但权益不一定给购买者。Polar 文档说明，seat-based product 的 benefits 只授予 claim seat 的 team members；billing manager 如果也要用产品，需要给自己分配一个 seat，而且这个 seat 计入购买总数。
这会引出两个对账误判：
| 财务看到的说法 | 技术侧真实含义 | 怎么写给客户 |
|---|---|---|
| 我只剩 3 个用户 | 可能还有 5 个 paid seats | 「现在 3 个成员在用，但订阅仍购买 5 个 seats」 |
| Owner 没有权益 | billing manager 没给自己分配 seat | 「付款角色和使用角色分开，需要给 Owner 分配 seat」 |
| 邀请过期了所以不该收费 | claim link 过期不等于 seat count 下降 | 「可重发邀请，也可减少 paid seats」 |
| revoked 之后还收费 | revoked 只回收某个成员权益 | 「要停止收费，需要 reduce seat count」 |
如果你自家 SaaS 还有一套 team 表，最好把 Polar 的 member id、seat status 和本地 user id 存起来。只存 customer_id 会把付款实体和最终用户混成一个人。
改后台设置前先停手
如果金额只差几美元，最糟糕的动作是同时改 subscription、手工 refund、改 product price、再让客户重新 checkout。这样下一张 invoice 会更难解释。
我会按这个顺序处理：
- 在 Sales -> Subscriptions 找到 subscription，记录当前 seats、product、currency 和 billing period。
- 打开 Customer Portal settings，看 seat management 和 plan changes 是否允许客户自助。
- 查看最近一次 subscription update 的时间，判断是客户 portal 动作、merchant dashboard 动作，还是 API 调用。
- 打开 invoice，看 line items、tax、credit、discount 和 payment status。
- 如果是
next_period，把 pending_update 生效日期写给客户；如果是prorate，说明差额会到下一张 invoice。 - 只有在 invoice 明显错误、subscription 记录缺失或 API 返回与后台不一致时，才带证据找 Polar support。
以上基于 2026-05-29 能看到的 Polar 官方文档；我没有进入你的组织后台，也没有验证不同国家税率、所有付款失败场景和自定义 API 集成。金额较大、企业采购或税务口径有争议时，先把 invoice、contract、订单号和客户账单地址交给会计或律师看。
Polar 账单能力有哪些限制？
Polar 已经覆盖 Customer Portal、seat-based pricing、subscription 管理、proration、invoice 和 failed payment recovery，但它不是你的财务系统，也不会替你解释每个客户合同。
这些限制要记清楚：
- Seat-based pricing 仍标注为 beta，需要在 Settings -> General -> Features 开启。
- claim link 有有效期，过期后重发邀请，不代表账单自动变少。
- 每个 subscription 最多 1,000 seats。
- Dashboard 没有 seat 批量导入，批量场景要用 API。
- 客户能改的 portal 动作受设置控制；revoking、trial、discount、renewal date 等动作仍是 merchant-only。
- invoice 上税费和客户看到的价格受 billing address、tax behavior 和 proration 影响。
对独立开发者来说，Polar 的优势是把 billing 的常见动作做轻；它不适合把复杂企业合同、线下 PO、定制折扣审批和多实体税务全塞进一个自助 portal。