有开发者开通 Azure OpenAI 后，月底账单多出一行 9% 的新加坡 GST，于是想找「免税区域」，并担心之后用 Amazon Bedrock 跑 Claude 也会被同样收税。文章解释云服务税费跟着账单主体和税号走、而不是跟着机房位置走，分析填美国免税州地址的可行性与风险，并给出提交企业税号走反向征收、国内主体境外付汇等几种合规做法和检查清单。
开了 Azure OpenAI，资源按教程建好、调用也正常，结果月底账单里多出一行 GST，税率 9%，等于凭空贵了一截。于是自然会产生两个疑问：一是 Azure 有没有不收这笔税的区域，二是后面打算在 Amazon Bedrock 上跑 Claude，会不会再被收一遍同样的钱。
这类问题的关键，往往不在「机房放在哪个国家」，而在「这笔账记在谁头上」。把这两件事分开看，很多疑惑就通了。
税费跟着账单主体走，不跟着机房走
云厂商判断该收哪种税、收多少，通常看三样东西：
- 账单主体与地址：个人还是企业，注册地址和账单地址在哪个国家/地区；
- 税务身份：有没有提交有效的企业税号，是否适用反向征收（reverse charge）；
- 服务类型与当地税法：同样的云服务，在不同辖区可能被认定为数字服务、电信服务或一般服务，处理方式不同。
数据中心位置（region）影响的是网络延迟和单价，不影响税。所以「换一个便宜的区域」解决不了 GST 的问题，真正要动的是账户层面的税务信息。账单上能单独列出一行 GST，说明系统已经把你的 sold-to 地址判定在了新加坡，税率按当地现行规定代收——具体税率以当地官方最新公告为准。
填美国免税州地址，到底行不行
为什么会有这种说法
美国是州级销售税体系，蒙大拿、俄勒冈、特拉华、新罕布什尔等州不征收州级销售税，阿拉斯加也没有州级销售税（但地方层面可能另有规定）。把账单地址放在这些地方，账单上确实有可能不再出现税行。不少人订阅海外服务时这么操作过，于是形成了「填免税州就免税」的经验。
但有三个现实问题
- 合规性：账单地址应当与真实的主体、付款方式一致。填写不实信息属于违反服务协议的行为，平台有权暂停或关闭账户，余额和已购服务可能一起损失。
- 票据无法入账：如果这笔支出要走公司报销或税前扣除，一张地址对不上的境外发票，在税务上很难站得住。
- 未必长期有效：各州对云计算、数字服务的课税规则并不统一，而且会调整；平台也会做地址与付款方式的一致性核验。
结论很直白：个人自用、金额不大、不打算入账，风险自担；一旦是公司支出、需要正规凭证，不建议走这条路。为省个位数的税，换来账户被风控，不划算。
几种更稳妥的处理方式
1. 提交真实企业税号，走反向征收
很多辖区对企业客户适用反向征收机制：平台不代收增值税，由企业自行申报。Azure 和 AWS 后台都提供了维护税务信息的入口——AWS 有独立的 Tax settings 页面，可以设置税务地址并登记多个国家/地区的税号；Azure 则在账单账户与发票配置中维护类似信息。
前提是：税号真实、主体与账户一致、且你所在辖区确实适用该机制。提交前建议先确认清楚自己是「消费者」还是「企业」，两者适用规则不同。
2. 用国内公司主体签约，走境外付汇流程
如果目的是「拿到能入账的凭证」，正规路径是：
- 合同与付款对象是境外的微软或 AWS 实体，以外汇支付；
- 大额对外支付通常需要办理服务贸易等项目对外支付税务备案（常见口径为单笔等值 5 万美元以上，具体以当地税务机关和银行要求为准）；
- 对境外单位向境内提供的服务，需要代扣代缴增值税及附加，并涉及企业所得税等，增值税常见为 6% 一档，以现行规定为准；
- 最终以境外发票加上完税凭证或代开发票，作为成本费用凭证。
这条路的优点是彻底合规、进项可抵扣；缺点是流程长、要和财务和税务专管员对齐，而且实际综合税负不一定比直接付 9% 更低。是否划算，要把可抵扣部分和人力成本一起算。
3. 用真实存在的主体去签约
如果确实在某个低税辖区有实际经营的主体，用那个主体签约完全正当——这才是「换地区」的正确姿势。反过来，为了省税去注册一个没有实际经营的空壳，属于另一类风险，不建议。
Bedrock 上跑 Claude，税务怎么算
逻辑完全一样：看 AWS 账户的税务地址和税号，不看模型部署在哪个 region。几点补充：
- Bedrock 的模型要先在控制台申请开通访问权限，之后按 token 计费；
- AWS 的税务设置粒度更细，可以按国家登记税号，企业客户走反向征收的路径更明确；
- Anthropic 官方 API、Amazon Bedrock、Google Vertex AI 是三套不同的计费主体和条款，价格与开票方式不能混着算；
- 各平台支持的模型清单和可用区域会变，下单前以官方文档为准。
动手前的检查清单
- 确认当前账单的 sold-to 地址与税务身份是否属实；
- 有企业税号的，先在后台税务设置里补全，再看下一期账单是否适用反向征收；
- 需要入账的，提前和财务确认境外发票 + 完税凭证的处理流程，别等报销时才发现不行；
- 在控制台设置预算和费用告警，避免模型调用量失控；
- 记录每笔跨境支付的手续费与汇率成本，和「省下的税」做对比。
几个容易踩的坑
- 买号、共享账号、找人代充：账号归属不清，一旦触发风控，钱和服务一起没，且完全无法开具合规凭证。
- 只看税率不看总成本：跨境刷卡手续费、汇兑损失、代扣代缴的申报成本，加起来可能超过那 9%。
- 把「试用额度」当常态：免费额度到期后计费口径会变，账单结构也会变。
- 忽略税务政策时效：各地数字服务税、跨境支付备案的要求都在调整，实际操作前请以官方最新说明和主管税务机关口径为准。
小结
这笔 9% 的 GST 不是因为「选了新加坡的机房」，而是因为账单主体被判定在新加坡。想少交税，正确方向是调整税务身份——提交真实企业税号走反向征收，或者用国内主体合规签约、走境外付汇与代开发票流程；而不是把地址随手改成一个免税州。后者短期看账单确实变干净了，但账户风险和票据问题会留在后面。至于 Bedrock 上的 Claude，规则同源，先把 AWS 的税务设置理清楚，再决定用哪个平台跑。