查Ideogram积分重置日期，先把“本期订阅额度”和“额外购买余额”拆开。按2026年10月9日官方说明，未用完的订阅Priority积分在周期结束时失效；Top-up在订阅积分耗尽后使用，未用部分可结转。个人续费日可以在Manage Billing查看，不能统一按每月1日计算。官方套餐与积分FAQ
实际核对时，需要回答三个问题：哪一项余额在变化、对应哪个周期、期间发生过哪些操作。只记录一个总余额，很难区分额度到期、正常扣减和新周期发放。
把付款日期与额度日期分成两栏
当前个人Plus和Pro套餐均列出月度Priority额度，并提供Top-up购买及slow queue。年付页面仍以每月额度展示，因此不能把一年付款理解成“全年积分一次发放且一直保留”。团队席位和企业合同应另建记录，不直接套用个人账户的额度。官方套餐说明
建议按以下顺序核对：
- 登录实际使用的账号，确认是个人空间还是团队空间，记录当前计划名称与购买渠道。
- 打开Manage Billing，抄下续费日期、付款频率和最近一期收据编号。
- 回到余额界面，分别记录订阅与Top-up余额，以及界面显示的下一次额度更新信息。
- 如果年付账户只显示明年的续费日，没有明确的月度额度更新时间，向支持确认“下一次月度Priority发放时间及适用时区”，不要从年付收据自行推算。
记录日期时保留界面的原始文字；未标时区就注明“界面未显示”，不要擅自改成北京时间零点。可以沿用订阅台账与续费核对的记录方法，将自动续费检查日与积分检查日分别设置提醒。
用一个假设账本检查周期交接
以下数字只演示核对方法，不代表任何真实套餐或图片消耗。假设个人网页账户的订阅余额为60、Top-up为25；期间只有一笔已确认扣费10的操作，没有API调用、计划变更或其他交易。
| 核对时点 | 订阅Priority | Top-up | 应保存的证据 |
|---|---|---|---|
| 操作前 | 60 | 25 | 两项余额、观察时间 |
| 操作后 | 50 | 25 | 本次扣费记录 |
| 周期结束前 | 50 | 25 | 最后一次余额快照 |
| 新周期额度到账后 | 本期新发额度 | 25 | 新额度记录、周期日期 |
这个例子用于检查两个变化：旧周期剩余的50不加到新额度上；未动用的25仍单列。不要把新周期总额减去旧周期总额，就直接称为“被扣掉的积分”。先拆解为旧额度退出、新额度进入、期间实际使用三项，再查是否存在无法解释的差额。
同样订阅图像工具时，可以参考Midjourney Fast时间的到期核对理解为何月度额度与额外购买需要分列；具体有效期和使用条件仍分别按各家规则记录。
使用API时，增加一条消费来源核对
不要假定网页与API的额度完全隔离。当前官方API v2设置文档说明：订阅用户通过API key发起请求时，如果月度订阅额度足以覆盖整次请求，会先使用这部分额度；否则使用API balance。API控制台的Billing可查看余额及历史，Usage用于核对调用消耗。官方API设置文档
因此，网页操作很少但订阅余额下降时，应同时核对脚本和自动化调用。台账可增加“入口：网页/API”“请求时间”“使用的余额类别”三列；对不上时再把对应记录交给支持确认。
不要把这条规则扩写成“一次请求自动拆分扣两个余额”，也不要把网页Top-up结转说明直接当作API充值的有效期承诺。两者名称相近，仍应保存各自购买入口和账单。若启用了API自动充值，也单独记录其状态，避免把新增余额误认成订阅发放。
积分用完，先查任务能否进入slow queue
Slow queue并不覆盖所有操作：官方明确Editing with AI、Image Reference等功能需要Priority，无法在慢队列使用；慢队列等待时间也随容量及使用情况变化。官方积分FAQ
排查时先记下具体功能与提示，而不是只写“不能生成”：普通生成在排队，应核对队列状态；编辑功能提示需要Priority，应检查对应额度。不要为了测试余额是否恢复，连续提交重复任务。
周期前后可复用的核对清单
- 账号、空间、计划和付款渠道是否一致？
- 月付或年付是否已记录，续费日与额度更新日是否分开？
- 订阅、网页Top-up、API balance是否各有一项记录？
- 前后两次观察之间是否有网页操作、API调用或计划变更？
- 异常差额是否附有时间、余额截图和交易记录？
若仍无法解释变化，向官方支持询问具体余额类别、对应周期和交易，不只询问“为什么积分少了”。保留自己的核对记录即可，无需提供密码或API密钥。下一次周期到来时，用同样字段对照，才能看清余额变化的原因。