矿池余额先对应内部账户
核对矿池到冷钱包的付款，第一步是确定正在看的数字属于哪一层。Braiins的说明把Financial Account定义为保存已确认挖矿奖励的财务账户，把Funds解释为这些账户中的可用余额。这些名称描述矿池内部记账，不能仅因页面出现余额，就认定同额比特币已经写入某个收款地址的交易输出。
该平台还允许把奖励分配给不同财务账户，并为账户配置付款规则。因此，记录应保留具体账户及分配关系；若只比较矿工总奖励与一个地址的收款，可能是在比较不同范围。这里引用的是平台规则说明，没有读取任何用户的矿池后台，也没有替平台确认债务或应付金额。
付款条件和链上确认分开记录
在Braiins的模型中，付款规则决定何时以及如何付款，可以涉及时间间隔或金额阈值。系统按说明评估规则，满足条件后触发付款。阈值达成、付款记录生成、交易获得确认是不同的事件，不能把一个时间戳复制成三项完成时间，也不应把页面给出的通常耗时改成必然到账期限。
本文只讨论比特币链上付款。该平台也列有闪电网络方式，不能把下面的交易输出核对方法直接套在闪电发票上。对于链上记录，宜分别保存付款方式、目标地址、平台记录金额和交易标识；没有给出交易标识时，就保留缺项，不能自行拿一笔金额相近的交易补上。
交易标识还要配具体输出编号
Bitcoin Core 28.0的getrawtransaction文档区分整笔交易与vout输出数组。每个输出有编号n及以BTC计量的value，输出脚本另有自己的字段；address只在存在明确地址时出现。由此，个人付款应对照具体输出的收款条件和金额，不能直接把数组全部金额相加后记入自己的收款栏。
设一份完全虚构的核对卡：交易甲的输出零给目标地址0.012 BTC，输出一给另一个地址0.018 BTC。全体输出合计0.030 BTC，而这张卡能对应的目标收款只有0.012 BTC。这是示意算术，没有真实交易哈希；也不能仅凭另一个输出存在，就替它判断属于其他矿工还是平台找零。
查不到交易也要记录查询范围
同一份Core文档说明，默认查询范围受内存池限制；是否启用交易索引、是否提供区块哈希以及区块是否可用，都会影响查找条件。因此，一次接口未返回记录，不能单独证明矿池没有付款。confirmations等字段也是可选返回项，应保留原始缺失状态，不能默认填成零或某个确认数。
完整的对账结论要把内部付款记录、正确网络上的交易、输出编号及接收条件连起来，并标注观察时间。地址匹配只帮助解释链上收款，不能证明某人仍控制其密钥。资料不足时，应写明缺少哪一段证据；本文没有登录钱包、生成收款地址或执行转账，也不根据这份示意账推算挖矿回报。