Nexus 决定某州有没有权要求企业申报；Apportionment 决定多州经营所得中有多少分配给该州。两步使用的事实相关，却不能混为一谈。商品目的地、服务受益地和总账收入必须在同一底稿中对齐。
1. 先分清 Nexus、Allocation 与 Apportionment
Nexus 回答申报连接，Allocation 通常把某些特定类别收入直接归属于一个州，Apportionment 则通过法定因子把多州经营所得分配给各州。企业可能在某州形成 Nexus，却因分摊结果很小而应缴税有限；反之，较高的州内收入比例也不能跳过 Nexus 与 P.L. 86-272 的独立分析。
现代州税已广泛使用销售因子，但各州是否采用单一销售因子、是否加入 property/payroll 因子、是否要求 combined reporting，以及特殊行业公式均不相同。底稿必须标明州、年度、申报主体和规则来源。
2. 商品销售通常从交付目的地开始
对于有形商品，许多州规则从商品交付或运送给购买方的地点判断销售因子 numerator。电商平台、3PL、Drop Shipping、客户自提和跨境运输会使账单地址、发货地、最终交付地与库存所有权不同，订单系统必须保留足够字段。
退货、折扣、运费、Marketplace 代收税和平台费用也要与收入定义统一。州税分摊使用的 receipts 不一定等于银行净回款；正确流程是从 gross sales 出发，按州规则处理允许的调整，再与财务报表收入做桥接。
- 订单号、销售实体和销售渠道
- ship-to、bill-to 与实际交付地点
- 商品、服务、运费、税款和折扣拆分
- 退货、取消、换货及跨期调整
- Marketplace 与自营渠道的 gross-to-net bridge
3. 服务收入要识别客户在哪里获得利益
许多市场来源州会考察服务受益地、交付给客户的地点或客户所在地，并提供层级规则和合理估算方法。合同签署地、开票地址、付款银行或服务人员所在州可能只是证据之一，不能机械替代实际受益地。
B2B 服务应了解客户使用部门、用户或运营地点；SaaS 应保留订阅用户、使用地址或合理可得的客户位置证据；专业服务则需区分成果交付、客户项目和实际受益。无法直接确定时，应记录合理估算方法、数据限制和连续适用原则。
- 合同描述与服务成果
- 客户法人、账单地址和业务地点
- 用户、项目或受益部门位置
- 可得数据不足时的合理估算层级
- 同类交易连续使用的方法和例外审批
4. 建立可复核的 numerator/denominator 底稿
底稿第一层应对平总账与申报范围内的 everywhere receipts；第二层按收入类型拆分商品、服务、许可、利息和其他项目；第三层按各州 sourcing 规则生成 numerator；第四层记录 throwback、throwout、排除项目或特殊规则。每次调整都应能追到订单、合同或计算说明。
不要让每个州从不同导出文件开始。一个受控主数据集可以生成各州视图，并使用异常报告识别无州代码、地址冲突、负数收入和跨期退货。这样既提高申报一致性，也为审计抽样保留证据链。
5. 把业务变化及时带入分摊模型
新产品、订阅模式、经销商、客户合约、履约地点或收购都可能改变收入分类与 sourcing。税务不应只在报税季接收年度汇总，而应参与收入主数据和合同字段设计，并至少季度检查重大变化。
管理层还应比较申报分摊与经营指标。某州销售快速增长而 numerator 不变、账单地址集中在总部州、或服务收入全部落在 unknown，都可能表明数据而非税法出现问题。
