Token采购的账不好做，原因不在于金额大小，而在于它在现行制度里没有现成位置。买服务器有固定资产的规矩，买耗材有低值易耗的规矩，买Token却要先回答两个问题：在项目费用表里，它算哪一类费用；在会计账上，它算服务费还是资产。
把Token往资产里放，第一反应通常来自“钱先付了”。点券包一买几百万，钱付出去、额度还在供应商的系统里，看上去像一笔待用的资源。但资产的确认不只看钱付没付，更要看采购方是否控制了一项能带来经济利益的资源。买服务器，你控制了这台机器，可以搬走、可以停用、可以处置；买Token，你控制的是“在供应商平台上调用模型的权利”，离开对方的系统，这个权利无从实现。
更贴切的类比是预付电费。没有人会把预缴的电费记成固定资产，因为它买的是未来会被消耗掉的服务。Token同样如此：它的价值不体现在持有上，而体现在消耗上；不消耗，它就只是一个尚未兑现的额度。
由此，会计上的处理路径也清晰起来：预付时记预付账款，实际消耗时按用途转入相应费用科目，跨年度未消耗的部分在年末作为预付性质列示。预算上的定性则是商品和服务支出，不属于资本性支出。这个定性不是文字游戏，它直接决定三件事：要不要走资产配置审批、支出列在哪一个年度、审计往哪里看。
企业会计与行政事业单位会计在这一点的判断是一致的，差别只在费用归集的方向：企业按用途计入管理费用、研发费用或营业成本，行政事业单位计入商品和服务费用下的相应明细。定性相同，落点不同，但都不会走到固定资产那一栏去。
有一个例外需要留意：如果一份合同把Token与软件平台、硬件设备打包采购，账就要拆开做——平台部分按软件或设备处理，Token部分按服务费处理。合同怎么拆，账就怎么记，这也是后面要强调签约条款的原因。
定性之后是落点。把Token放进项目费用表，先要看现行费用构成怎么分类。在通行的口径中，Token最贴切的参照不是设备或软件的购置费，而是水费和电费——按表计量，用多少付多少，消耗掉即灭失。
这个落点也划清了它与其他科目的界限。它不是软硬件采购，因为买到的既不是可交割的设备，也不是可转让的许可；不是数据资源建设，因为费用不发生在数据采集与治理环节；也不是运行维护，因为它不为既有系统提供保障，而是直接产出业务结果。硬塞进任何一类，评审环节都会被追问。
现行制度里，按量计费的条目本来就有位置：《关于修订2026年政府收支分类科目的通知》（财预〔2026〕14号）支出经济分类的“商品和服务支出”项下，水费与电费单列成科目；广东的《省级政务信息化项目预算编制规范和标准·基础设施服务分册》（粤财数〔2024〕4号）把基础设施服务单列成册，云服务以目录形式逐项列价、按用量结算；共同点是：承认按量计费的服务应当有对应科目，也都以用量乘单价的方式结算——这正是Token可以比照的地方。
落到编制上，有类似规定的，比照办理即可：与水费电费同列“商品和服务支出”，按用量与单价计取，不必走资产配置审批；没有对应规定的，也不必绕道去挤别的科目——在项目费用表中单列“算力服务费”一行，编制说明里写清计量方式与价格依据，评审时一并附上。这也是新标的接入旧制度时通常采用的过渡办法。
编制Token预算最常见的错误，是按“买多少Token”来估。这个口径看似直接，实则站不住：Token与实际业务量之间没有稳定的换算关系。同样一笔钱，用在不同模型、不同任务、不同长度的上下文上，能办成的事相差数倍；再叠加分词器差异与缓存命中率，Token数量本身几乎说明不了任何问题。
可行的做法是反过来推：先确定要办多少事，再折算成Token。例如一年要完成多少件材料初审、多少份合同审查、多少轮咨询应答，按单件任务的Token消耗量乘以单价，再乘上一个成功率修正系数，倒推总额。单件消耗量与单价都要在预算说明里写清依据，不能只写一个总数。
倒推时还要留三笔余量。一是重试与失败的消耗，智能体场景下这部分可能占到两三成；二是上下文膨胀，多轮任务会把历史内容反复带入，输入Token逐轮增长；三是单价变动，算力价格在过去一年是往上走的，跨年度项目应约定调价机制或留出弹性。
举个简化的例子。某单位一年需要完成5万件合同初审，单件任务涉及十余轮调用、累计消耗约60万个Token（输入55万、输出5万，其中约七成输入命中缓存）。按输入每百万Token2元、缓存0.4元、输出8元折算，单件成本约0.88元；再按80%的成功率修正，全年预算约为5.5万元。任务换成简单的材料初审，单件成本会降到两分钱上下；换成更复杂的长上下文任务，又会成倍上升，但倒推的算法完全相同。
还有一个问题：单价从哪里来。Token的价格波动远大于传统软硬件，但并非无据可依——各家大模型厂商与平台都对外公布目录价格，这是最直接的一手依据；评审时被反问一句“这个数是怎么来的”也能从容应对。
编制阶段的价格依据从哪里来，正是「AI询价喵」要解决的问题。这是一款面向全品类设备与服务的智能询价审价平台，以AI大模型与向量数据库为技术底座，沉淀了海量真实成交价与预算限价数据；单次询价最多可匹配100条真实成交数据，输出多维分位价与合理价格区间，支持一键导出标准化询价报告与价格清单，为信息化项目预算编制与价格评审提供可直接引用的依据。
结算是按合同走的，合同没写清，结算必然扯皮。Token合同的计价条款应当按“电费”而不是按“设备”来设计：以用量为计量单位、以对账单为凭证、以单价乘数量为结算公式。按这个思路，有八条建议在合同里写死。
这八条里，最容易被含糊处理的是计量口径与对账单粒度。前者决定“算多少钱”，后者决定“能不能核对”。口径不一致时，双方各按各的表统计，差出两三成都不奇怪；对账单只到月度汇总时，采购方实际上无法验证消耗的真实性，审计这一关也就过不去。
另一条值得坚持的是“先对账、后开票”。把对账确认写成付款的前置条件，能省下后续大量的争议成本。
Token采购的结算方式主要有三种，账务处理各不相同。第一种是先预付、后消耗，即购买点券包或资源额度，这是政府与国企最常见的形态；预付时记预付账款，按月或按季根据实际消耗结转费用。第二种是先消耗、后付费，即按量结算，按月确认费用与应付账款即可。第三种是保底加溢出，需要把保底部分与溢出部分分开核算，因为两者单价通常不同。
无论采用哪一种，月度或季度的对账都是核心动作。供应商出具对账单，采购方核对消耗量与计量口径，双方确认后开票、付款、结转。这个节奏一旦建立，年末就不会出现“账上花了钱、库里查不到量”的局面。
年末处理是最容易出问题的地方。未消耗的额度不能直接列支为本年费用，应按预付性质结转下年；把预付当作已支出，等于虚列支出，是审计的典型问题。如果当地财政对结转额度有限制，编制预算时就应把跨年安排一并写进说明，免得年末被动调账。
审计要回答三个问题：钱花得对不对、量对不对、价对不对。对应到Token采购，需要一条完整的凭据链——合同与预算批复说明口径与价格，对账单证明消耗量，结算单与发票证明支付，成果物证明这些消耗确实办成了事。
链条上最常见的断点有三处。一是只有总账没有明细，消耗量无法验证，也就无从排除刷量；二是对账单口径与合同约定不一致，双方各说各话；三是成果物缺失，Token花出去了，却拿不出对应的工作成果，这在补贴类项目里尤其常见。
针对第三点，一条务实的建议是把“有效任务数”而非“Token消耗总量”作为审计的核心指标。前者对应真实产出，后者只是一个中间量；用产出指标来考核，刷量的空间自然被压缩。这与前一篇提出的“补贴从按消耗量补转向按有效任务补”是同一个道理。
预算、结算、审计看似是财务、采购、审计三个部门的三件事，其实共用同一个前提：存在一个可分割、可计量、可审计的计量单位，以及一条能追溯到这个单位的凭据链。Token恰好提供了这个单位——数量精确、颗粒极小、有调用日志可查、有对账单可核。
真正的障碍不在单位本身，而在配套制度还没有跟上。费用测算标准里还没有它的正式位置，有的文件能给出一个可对照的科目，有的连可对照的条目都没有，只能借用既有科目的计价方法；对账单没有统一格式，各家供应商给出的粒度差别很大；Token类服务的验收标准也尚未成形，“用完为止”怎么写进验收条款仍在摸索。
所以有三件事可以马上做起来。编预算时把算力费用单列一行，写清计量口径、单价来源与跨年安排，没有对应科目就注明借用了哪一条的计价方法；签合同时把八条计费规则写死，并约定调用级别的对账单；结算时坚持先对账、后开票、再结转，年末不把预付当已支出。
