GLM 发票申请与企业采购授权怎么走
数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。
很多团队把这两件事混成一件事，结果两头都卡住。GLM 开放平台上，「开发票」是财务动作，走的是财务中心的自助开票入口，核心口径是按已消耗的现金金额开、不按充值金额开；「模型商用授权」是法务动作，走的是商用授权申请表单，只面向完成企业认证的企业用户，而且按商用许可协议自己的定义，它管的是开源模型权重的下载、运算、修改与分发，和你在平台上调 API 产生的账单是两条不相干的线。真正会把人绊倒的是三个顺序问题：先做企业实名再开票、先把历史票开完再做主体变更、先确认哪些金额压根开不出票再去做采购预算。下面按你实际会遇到的先后顺序拆。
先确认账号是什么身份，再谈开票
开票抬头不是你在开票页面临时填的，它跟着账号的实名认证主体走。官方 FAQ 里「如何注册成为企业账号」的答案很直接：在实名认证页面完成企业实名认证，账号就成为企业账号。这一步没做，后面所有企业采购动作都是空的。
服务条款第七章对两类账号的开票能力写得比 FAQ 更细：个人认证账户支持开具个人发票和企业发票，个人在申请开具企业发票时需要提供在职证明、营业执照和工牌作为证明材料；企业认证账户则仅支持按照认证的企业主体开票。
这两句话直接决定了采购路径的选择。如果你是公司里的开发，用自己的手机号注册了个人账号先跑通了 Demo，后面要报销，你会走到「个人账户开企业票」这条路上，需要额外准备三份材料证明你和这家公司的关系。如果一开始就知道要走公司采购，直接用企业实名认证的账号，抬头唯一确定，材料反而最省事。
充值本身也有身份门槛。充值协议第三章写明：当你充值时，你应该具有经实名认证成功后的开放平台账户。也就是说未实名的账号连充值这一步都过不去，更不用说开票。
按消耗开票，不按充值开票
这是 GLM 开放平台最容易引发误会的一条规则，也是采购和财务对账时吵得最多的一条。
官方 FAQ 明确写了当前的开票模式：按照实际消耗金额开票，可开票金额等于用户已消耗的现金金额。紧接着还有一条独立问答直接堵死了另一种预期：目前平台仅支持按照消耗金额开具，不支持按充值金额开具发票。充值协议第八章和服务条款第七章重复了同一件事——智谱将在你的充值金额消耗后，按照实际消耗金额开具相应发票。
这意味着一个很反直觉的结果：你在季度末充了一笔钱，当期一分钱都没调用，那这笔钱当期开不出任何发票。财务如果按「付款即取票」的节奏排账期，这里必然对不上。正确的心理模型是：充值只是把钱放进账户，消耗才产生可开票金额。
可勾选的发票范围也有明确的时间口径。官方给的是两类：T-1 个月及之前的 API 推理「账单」，以及 T-1 日及之前的产品资源包购买「订单」。注意这两类的颗粒度不一样——推理账单是按月归集的，资源包购买是按订单、按日归集的。所以本月刚发生的 API 消耗，得等账单归集到位才能勾选，而昨天买的资源包订单，今天理论上就在可选范围里。搞不清自己当期到底消耗了多少的，先去财务总览和费用账单两个页面把数字拉出来，具体查法在GLM API 计费机制里已经展开过。
哪些钱从一开始就开不出票
这一条建议在做预算表的时候就标注清楚，否则年底会凭空多出一笔对不上的差额。
服务条款第二章把账户里的钱分成了几类，并对其中两类直接写了「不可开具发票」：
- 平台体验金：针对新客户体验场景赠予的限时有效金额，可用于平台大模型 API 调用消耗。条款写明它不可提现、不可转让、不可开具发票，且平台有权随时调整其有效期与使用规则。
- 充值优惠金额：充值优惠活动中在充值金额以外额外赠予的金额，包括红包、折扣、充值返现、优惠券、代金券等形式。同样是不可提现、不可转让、不可开具发票。
充值协议第六章对充值赠送金额的表述完全一致。换句话说，只有你真金白银付进去、并且已经被消耗掉的那部分现金，才构成可开票金额。赠送和优惠部分消耗得再多，也不会转化成发票。
做企业预算的时候，如果把活动赠送额度也算进「可报销成本」，报销口径和实际能拿到的票面金额之间就会出现一个固定缺口。把赠送额度单独列一行、标注不可开票，是最省事的做法。
欠费月份的账单会被单独卡住
官方 FAQ 对欠费状态下的开票给了一个很具体的例子，值得原样理解：若用户账户欠费，部分发票将无法开具。举例来说，用户四月份消耗金额不涉及欠费，五月份消耗涉及欠费，那么用户可以开具四月份账单，无法开具五月份账单，五月份账单需要在欠费金额补缴后才能开具。
这里的关键是按月粒度卡，不是整个账号被锁死。所以真遇到这种情况，别急着提工单说「开不了票」，先去看是哪个月的账单被卡住了，把对应欠费补上，那个月的票就能补开。
顺带一个相关规则：欠费状态下仍然可以使用有效期内的资源包。资源包扣减和现金扣减是两条独立的通道，调用时优先扣除满足模型适用场景的资源包余额，再扣现金账户余额；存在多个相同适用场景的资源包时，优先扣除最快过期的那个。这套扣减顺序会直接影响你某个月的现金消耗额，进而影响那个月能开出多少票——如果发现某个月可开票金额远低于预期，先看是不是被资源包吃掉了，而不是怀疑账单算错。账单突然波动的系统性排查思路可以对照API 账单暴涨的通用排查。
主体变更和历史发票的先后顺序
这是个一旦做反就不可逆的操作，官方专门用提示框标了出来。
原文的意思是：若用户账号进行了企业实名主体变更（企业 A 变为企业 B），也就是统一社会信用代码发生了变更，那么用户在变为企业 B 之后，不能再开具企业 A 时期消耗的发票金额。官方给的建议是可先完成历史开票，再做主体变更操作。
所以正确顺序只有一个：把企业 A 名下所有已消耗、可开票的账单和订单全部开完票，确认到票之后，再去发起主体变更。反过来做，企业 A 那段时间的钱就永远拿不到票了。
如果不想再用当前认证的企业实名信息开票，官方给的入口是企业实名变更页面，通过审核后可以按新企业抬头开票。要注意的是，官方那条提示框就挂在这个问答下面，讲的正是从这个入口做企业 A 变企业 B 的后果。换句话说，「改抬头」和「换主体」在页面上并不是两个互不相干的按钮，别以为只要主体没换就可以随便改、改完历史票照开。先按上面那条顺序把能开的票开完，再动这个页面，是唯一不会出事的做法。
至于跨主体的账号转让，主体变更协议列了生效前提：所申请变更的账号已完成实名认证且你是该实名认证主体、平台审核并同意变更申请、新主体同意接受变更。协议还写明，在新主体确认接受且完成实名认证前你可以撤回流程，一旦新主体确认接受并完成实名认证，撤销或取消请求平台将不予支持。
另外有几种情形平台有权随时终止主体变更程序，包括第三方对该账号发起投诉且尚未处理完毕、账号正处于主管部门调查中、账号正处于诉讼仲裁等法律程序中等。企业并购场景下要走这条路的，把这几条先自查一遍能省掉很多来回。
团队版的集中开票是另一套入口
如果采购的是 GLM Coding Plan 团队版，开票逻辑不走 API 消耗那一套。官方对团队版的描述里，把「集中式账单与发票管理」列为一项能力：企业账单统一归集、集中开票与对账，完成企业认证即可开具企业专票，目的是降低财务核算和分散报销的成本。
团队版订阅协议里写得更明确：你需要提供准确、有效的支付信息及团队开票信息，智谱将严格遵照国家税务规定开具合规的增值税发票。协议同时强调了先付费原则——付费后服务即开通，服务期限自套餐生效之时起算，至订购的套餐资源使用完毕或订阅期限届满为止，以先到者为准，套餐内的 API 调用额度在服务期限内有效、过期作废。
也就是说，团队版是订阅制的「先付费、按期开票」，跟按量计费那套「先消耗、按消耗开票」是两种财务节奏。企业采购前得先想清楚自己的报销流程更适合哪一种。团队版的席位与用量归集细节可以看GLM 编程套餐团队版怎么用。
套餐额度用尽后可以开启按量计费继续使用，同时支持按成员设置消耗上限。官方页面把超额部分标注为按低于 API 刊例价的比例计费，并注明是限时优惠——具体比例和是否仍在优惠期，以官方定价页与套餐页面当时展示的为准，别把它写进长期预算模型。
模型商用授权：完全独立的一条线
先把适用范围钉死，否则很容易白跑一趟表单，或者反过来漏掉真正该走的流程。
模型商用许可协议第一节自己下了定义：「大模型」是开源模型和衍生模型的统称；「开源模型」指使用者向发布者提交《模型商用授权申请》所涉及的模型及其包含的计算机算法、参数；「使用」则包括模型的下载、运算、共享、修改、分发等操作，以及对模型生成内容的共享、修改。这几句话把这条授权线的对象说得很清楚——它针对的是把模型权重拿到手、自行运行或再加工的场景，协议里授予的权利也是模型推理、模型修改、基于模型开发应用或产品服务这一类。
至于在开放平台上调用官方托管的 API 做商业产品要不要另外申请一份商用授权书，官方文档里没有找到相关说明——通篇提到商用授权的只有商用授权 FAQ 和这份商用许可协议两处，落点都在开源模型权重上。平台对 API 用户提的是另一套要求，也就是服务条款第三章那些算法备案、安全评估、模型使用公示的合规义务，跟商用授权不是一回事。所以「付费调 API」和「拿到开源模型权重的商用授权」确实是两条线，但方向别搞反：不是说你调 API 还欠一张授权书，而是这张授权书本来就不是发给 API 调用的。判断自己该不该提交申请，第一步是看自己到底要不要把权重下下来。
商用授权 FAQ 的第一条问答给了明确边界：模型商用授权仅开放给企业用户，个人用户无法获得商用授权。同一条答案还给了另一半信息——若你想将模型用于学术研究或非商用的应用开发，无需申请授权，在 HuggingFace 下载模型使用即可。
注意这条答案的非商用出口给的是「在 HuggingFace 下载模型使用即可」，落点还是下载权重，这也反过来印证了这条流程的适用场景。所以在确认自己确实要自取权重之后，再看两个条件：一是主体是不是企业，二是用途是不是商业。学术研究和非商用开发不需要走这个流程。
申请没下来通常是两个原因，官方也直接列了：一是申请正在审核，平台会在官方约定的工作日内完成审核并通过邮件发送授权书，也可以在平台的授权管理界面下载授权书；二是尚未完成企业认证，需要先完成企业认证，再填写表单进行申请。顺序不能颠倒——没有企业认证就去提交申请，表单交上去也是白交。具体审核时限以官方文档当前版本为准。
商用许可协议里企业法务真正要看的几条
拿到授权书不等于可以随便用。模型商用许可协议里有几条限制，是准备自行部署开源模型权重的企业在上线前必须让法务过一遍的（最后一条的合规义务归属对纯 API 用户同样成立，服务条款里另有对应条款）：
- 来源说明：使用大模型和大模型生成内容时，须注明大模型的来源并附上此大模型许可协议或其链接。这条会影响你产品的关于页、帮助文档甚至 App 内的声明位置。
- 宣传限制：使用者不得以发布者的名义推广宣传此大模型。市场部写文案前得知道这条。
- 许可限制：不得将模型的全部或部分进行复制、转让、出租、出借、出售或提供分许可、转许可，或从事与发布者相竞争的业务。做转售或再分发生意的，这条直接决定业务模式成不成立。
- 衍生模型的义务传递：在开源模型基础上开发的任何衍生作品，包括修改、衍生或集成的版本，仍应遵守本协议并保留原始许可和版权声明。
- 合规义务归属：协议写明使用者应遵守使用地适用的法律法规政策，并履行相应的算法备案、安全评估等要求。服务条款第三章说得更细——你调用平台模型 API 开发的产品和应用，由你负责自行进行互联网信息服务算法备案、具有舆论属性或社会动员能力的互联网信息服务安全评估、上线备案等合规程序，并按照相关规定真实、准确地公示使用模型的情况，不得对未使用该模型的产品服务做虚假或混淆事实的公示标识。
最后一条尤其容易被工程团队忽略：备案责任在你这边，不在模型提供方。国内合规上线的整体要求可以对照国内可达性与合规那篇。
开票和退款的先后关系，决定了采购节奏
有一条规则会反过来约束你什么时候开票：**已开票部分的充值金额不支持退款。**服务条款和费用 FAQ 都写了这一条。
同时平台对退款本身的态度也很明确：暂时不支持任意形式的退款，由于接口对 token 连续消耗的特性，消耗账户通常不支持退款；确有特殊情况的，尚未消费的充值金额（不含体验金、优惠金额等）可以联系客服发起特殊申请，需要配合提供证明材料并经审核。审核通过的按原支付方式原路返还。另外，一旦发起退款申请，充值优惠金额将于退款申请通过之时失效；如果优惠金额已经使用，退款时会从充值金额中全额扣除已使用的优惠部分。
团队版订阅有单独的退款条款：在冷静期内且服务尚未被实际使用（即未产生任何用量）的，可以联系客服申请全额退款；若已产生使用记录，则原则上不予退款。冷静期长度和判定口径以官方订阅协议当前版本为准。
把这几条串起来，采购节奏就清楚了：先小额试跑确认模型和成本模型合适，再放大充值；开票动作放在确认不会退款之后做，因为开完票那部分钱就锁死了。日常成本要盯住不失控，把消费明细的查看习惯固定下来比事后补救有用得多。
最容易栽的三个坑
第一，把充值当成开票依据。付款单和发票金额天然对不上，因为平台按消耗开票。财务排账期时要按消耗节奏排，不是按付款节奏排。
第二，主体变更前没把历史票开完。这个动作不可逆，变更后原主体时期消耗的金额再也开不出票。做并购、分立、重组的团队，把「历史开票清零」写进变更前的检查清单。
第三，分不清自己走的是哪条线。如果方案是把开源模型权重拿下来自行部署再商用，那商用授权是独立表单、独立审核、只对企业用户，而且要先完成企业认证，账单和发票替代不了那张授权书。如果只是调用平台托管的 API，官方文档里没有要求你额外申请这张授权，该盯的是服务条款里的算法备案、安全评估和模型使用公示。两条线的合规材料清单不一样，采购立项时就该先把这个问题问清楚，免得法务和采购各按各的理解准备材料。
至于发票多久到、能不能改抬头这类事务性问题，官方 FAQ 说明发票会在若干个工作日内发送至你提交的邮箱，通过邮箱内的链接下载，超时未收到可以联系在线客服或提交工单——具体时限以官方文档当前版本为准。真正需要提前规划的从来不是这些，而是身份、顺序和授权这三件事。