你共用一个上游 Provider 账号，背后却服务着许多下游客户：转售额度的买家、网关后的租户、或按组织分账的 workspace。月末上游发票准时到账，总额对得上、折扣也清楚。但当你要按客户说明用量、分摊成本，或只是回答「这个月谁烧了多少 token」时，同一张发票几乎帮不上忙。
问题通常不在「有没有付钱」，而在计量粒度：上游账单回答「这个账号一共用了多少」；客户侧需要「每个 customer 用了多少、成本怎么归」。二者不是同一张表。
为什么 Provider 发票对不上客户账单
三类错位很常见，而且经常叠在一起。
池化。AI 产品与 token reseller 多半把多客户流量汇进少数上游 key。Provider 看到的是池子里的模型、token 与价目行；池内是谁触发的调用，默认不在发票维度里。对上游对账越顺利，越容易误以为下游也能直接拆开。
缺 customer 维度。上游按账号、项目或订阅计价；你的商业单位是 customer、tenant、workspace。日志里即便有客户标识，发票也不会自动带上。没有按客户切分的用量事实，分账只能估比例或靠人工对表——争议单一来就撑不住。
价格与折扣停在上游。发票上的单价、批量折扣与 credit，是你与 Provider 的合同结果。客户侧你可能加价、打包或差异化费率。即使用量能拆开，上游应付也不等于下游应收。混为一谈，月底一定对不齐。
另有一层容易混淆：请求超时或收据缺失，会让「事件是否发生」本身变模糊——那是 Architecture 文讨论的收据问题。本稿只聚焦另一点：即便收据齐全，汇总账单仍不是客户级用量账本。
缺的一层：usage event → 可归因的客户用量行
要对齐客户侧，中间需要一层明确的计量事实，而不是再多一张上游 PDF：
usage event → attributed / priced customer usage lineEvent：可观测的一次用量（token、模型、时间戳，以及 customer / tenant 标识）。
Attribute：归到正确的客户（及你需要的产品、环境等维度）。
Price（按你的规则）：用你的价目或成本映射标价，而不是抄上游发票行。
Line：可查询、可汇总、可导出的客户级用量行——是分账与对接账单系统的输入，不是发票本身。
有了这一层，上游发票继续证明你对 Provider 的应付；客户侧则基于自己的用量行说话。两边可以对照（例如按模型汇总是否大致吻合），但职责分开：一边是采购池，一边是归因事实。
这层解决什么，不解决什么
解决的是计量与归因粒度，不是出账。
| 它帮你做的 | 它不替你做的 |
|---|---|
| 按 customer 看见 tokens 与成本 | 完整订阅、出票、催收、税务 |
| 把网关/多租户流量写成可归因用量行 | 替代 Stripe / Lago / OpenMeter 等账单套件 |
| 为分账、用量说明、导出提供事实底稿 | 承诺「零超支」 |
| 让上游合计与客户明细可对照、不混为一谈 | 把 HTTP 202 / custody 当成已结算 |
一句话：计量层停在归因后的 usage line（可再导出）；出票与支付仍属于你的账单栈。若在看 Compare：OpenMeter 或 Compare：Lago，先对齐问题——要的是计量层还是账单套件。二者可以衔接（导出），不是同一叙事下的简单替代。
和 FluxMeter 的关系
FluxMeter 定位：Open-source usage metering for AI gateways and multi-tenant products — customer-level tokens and cost, without a full billing suite.
路径可概括为 from flux to ledger：接入网关或 SDK 的用量流，经 custody 与流处理进入可查询账本，再通过 Usage API 读出已归因、可按你的规则标价的客户用量行。导出可选——可送进自有账单逻辑，或 Stripe / Lago / Orb / Metronome；FluxMeter 不宣称取代它们。
工程语义也需克制：ingest 返回 202 表示 custody（用量已被可靠接收），不是 settlement。Meter every token. Attribute every cost. 停在用量行，把出账留给账单层。
接下来
若正被「上游发票对得上、客户账对不上」卡住，先确认是否已有 customer 维度的 usage line，而不是先换一张更大的汇总报表。
边界与对照：Compare
本地摸栈：make demo（见 Docs）
产品与路径：Architecture
把计量粒度补齐，分账与出账才能各站在正确的一层上。