信用卡支付会通过收单机构的对账单进入您的账目，该对账单本身已标明订单。USDC 转账到达时只附带地址、金额和交易哈希，别无其他信息。加密货币支付对账之所以可行，是因为发票上承载了业务编号，而转账本身做不到这一点。
本指南面向接受稳定币并以欧元结算的商户、支付服务提供商（PSP）和电子货币机构（EMI）的财务与运营团队。文中列出每条发票记录所需的字段，说明如何处理部分付款和付错币种的情况，介绍 Webhook 与 API 如何将数据送入账簿，并说明哪些欧盟规则决定您需要保存多久。
关键时刻
简要概括
- ERC-20 转账仅包含发送方、接收方和金额。订单编号必须记录在发票上，而不是支付信息中。
- 以欧元为发票定价，并记录该欧元金额。加密货币金额是一个推导出的数字，您需保留以备审计追踪。
- 大部分工作集中在异常情况上：部分付款、过期发票、付错币种。应每日审核，而非等到月底。
- 以 Webhook 作为触发器，以按 ID 重新读取的发票为准，并每晚拉取发票列表作为安全网，同时作为 CSV 导出的数据来源。
为什么加密货币支付对账比信用卡更难？#
加密货币支付对账更难，因为区块链转账没有可填写订单号的字段。在以太坊上，ERC-20 代币标准（EIP-20）将转账事件定义为 `Transfer(address _from, address _to, uint256 _value)`：谁发送、谁接收、金额多少。它没有备注、没有发票号，也没有客户名称。
银行和信用卡支付的设计恰好相反。SEPA 转账有一个由付款人填写的附言字段，而收单机构的结算报告会将每笔信用卡交易与您的商户编号对应起来。您的会计系统正是依据该编号进行匹配。
稳定币还会带来另外三个障碍：
- 金额很少是整数。一张以 USDC 计价的 250 欧元发票会变成 279.2846 USDC 这样的数字，因此金额相近的两张发票看起来可能很相似。
- 支付不会立即最终确认。以太坊大约每 12 秒产出一个区块，但根据 ethereum.org（页面更新于 2026 年 10 月），“以太坊区块大约需要 15 分钟才能最终确认。”转账即使已可见，仍可能不算数。
- 付款人会出错。他们可能少付、重复付款、用错币种，或在发票过期后才付款。
因此，关联必须在付款人付款之前就已建立：每个订单对应一张发票，发票承载您的订单 ID 及其专属收款地址，这样每笔入账转账都会落在一条已知其用途的记录上。
每条加密货币发票记录需要哪些字段？#
每张发票都需要一组固定字段，将四件事关联起来：您的订单、欧元价格、链上转账和最终状态。缺少任何一项，就会有人不得不手动匹配。下表使用 ItisPay 发票 API 的字段名称；其他服务商对相同概念可能使用不同的名称。
| 字段 | 内容 | 会计为何需要 |
|---|---|---|
| invoice_id | 服务商分配的唯一 ID | 每次查询和每条账簿记录的主键 |
| order_id | 您的订单或合同编号，每个订单唯一 | 与您的 ERP、店铺或 CRM 的关联；这是信用卡免费提供的编号 |
| order_name | 订单的简短描述 | 无需打开店铺，即可由人工核查异常情况 |
| fiat_amount, fiat_currency | 欧元价格 | 您入账的收入金额 |
| currency, crypto_amount | 开票的币种及应付金额 | 显示付款人被要求支付的金额 |
| actual_crypto_amount_paid | 实际到账金额 | 检测少付和多付 |
| currency_paid | 实际使用的币种（若与开票币种不同） | 标记付错币种的付款以供审核 |
| network, address | 区块链网络和收款地址 | 证明款项发往何处；任何追踪或退款都需要 |
| transactions (tx_hash, amount, status) | 每笔入账转账一行 | 一张发票可收到多笔转账；每个哈希即您的链上证据 |
| status | new, pending, completed, expired, cancelled, paid_partial | 决定您是入账、发货、催收还是关闭 |
| created_at, updated_at, expires_at | 时间戳 | 月末截止及订单付款时间的证明 |
其中两个字段承担了大部分工作。`order_id` 是区块链转账无法承载的编号，因此应从您自己的系统中设定，并保证每个订单唯一，而非每位客户唯一。`transactions` 列表很重要，因为发票并不总是一次付清：每笔转账都有自己的一行，包含哈希和状态，这样您就能看出哪些转账构成了已付金额。
将加密货币金额以全部小数位存放在单独的列中。您的总账以欧分为单位运作；加密货币列是证据，而非账面价值。
哪个欧元金额应计入账簿？#
按发票上的欧元价格入账。当发票以欧元开具时，服务商按当前汇率将其折算为加密货币金额，付款方支付该金额。若付款以欧元结算至您的账户，则发票上的欧元数字即为您的收入，而加密货币金额只是款项到账方式的技术细节。
这也是主要原因：团队若通过自动接收加密货币支付并兑换为欧元，通常几乎不需要加密货币会计处理：资产负债表上不存在需要在月末估值的币种。
若您持有稳定币，情况则不同。国际财务报告准则解释委员会于2019年6月决定：持有的加密货币若在日常经营中为出售而持有，则归入IAS 2（存货）；否则归入IAS 38（无形资产）。其对加密货币的定义不包括在持有人与另一方之间产生合同的资产。USDC情况不同：Circle声明其可“按1:1兑换为美元”，并且自2024年7月起，Circle在欧盟依据法国监管机构ACPR颁发的电子货币牌照，以电子货币代币形式发行USDC和EURC。如何对持有的稳定币进行分类，应由您的审计师判断。收款时结算为欧元即可避开这一问题。
如何处理部分付款和错误币种？#
凡未处于`completed`状态的发票，均应视为例外事项，并指定负责人和处理期限。加密货币支付对账的大部分工作都集中于此；全额付清的发票会自动匹配。
以下为ItisPay各状态对财务的含义：
| 状态 | 发生了什么 | 财务处理 | 发货或放行？ |
|---|---|---|---|
| new | 发票待付，尚未收到款项 | 无需入账 | 否 |
| pending | 已看到转账，尚未最终确认 | 等待状态变更 | 否 |
| completed | 已全额付清 | 按欧元价格确认收入，释放订单 | 是 |
| paid_partial | 已到账部分金额 | 要求补足余款、退款，或经协商后关闭 | 视情况 |
| expired | 超时仍未全额付款 | 关闭订单；检查是否有迟到的转账 | 否 |
| cancelled | 您已作废该发票 | 不做记账；若客户仍愿付款，则重新开具 | 否 |
部分付款#
部分付款通常意味着付款方的钱包或交易所从金额中扣除了手续费，或付款方输入有误。ItisPay会分别记录每笔转账，因此第二笔转账即可补足发票金额。发票还设有`allowed_error_percent`参数：这是按发票设置的一个小额容差，使略微不足的付款仍视为已付。应将其作为一项政策统一设定，例如设定为您在银行转账中同样会予以核销的水平，并且不要逐案更改。
若余款始终未到账，应在固定天数内作出决定：接受差额并予以核销、退还已收款项，或取消订单。请将决定记录在发票档案中，以便审计师了解为何一笔已付订单对应的资金较少。
错误币种或迟到付款#
若付款方发送的稳定币与发票所要求的币种不同，`currency_paid`字段会显示该信息。请勿自动入账：应核对金额和欧元价值，再决定接受或退款。向已过期发票的转账情况类似。资金已在链上，但您的订单已关闭，因此须由专人决定是重新开启订单还是退还款项。若您方作废了某订单，请通过API取消该发票（即更新状态），以便在任何迟到付款到达前，您的记录显示其已关闭。
webhook和API应如何为加密货币支付对账提供数据？#
采用三层机制：webhook告知您有状态发生变化，重新读取发票可确认当前的真实状态，每晚拉取全部发票则可捕获前两层遗漏的任何情况。
- 每张发票可设置`callback_url`，服务商会将状态更新发送至该地址。应将该消息视为触发信号，而非凭证。
- 每次收到webhook时，调用`GET /invoices/{invoice_id}`，并依据该响应中的状态和金额采取行动。由于API调用需要您的API密钥，此举可防范伪造或重放发送至您端点的请求。
- 确保处理程序具有幂等性：同一状态可能被接收两次。以`invoice_id`加状态作为账本记录的键，使重复接收不会产生任何变化。
- 每晚按`updated_at`排序列出发票，最新的在前，并逐页回溯至上次运行时；同时复查所有仍为`new`、`pending`或`paid_partial`状态的发票。将其与您的账本比对。凡在服务商记录中已付款、而在您的账本中仍为未结的，均属于例外事项。
用于测试时，ItisPay提供一个可模拟发票状态变更的端点，以及一个可按`invoice_id`或`order_id`重新发送最新webhook的端点。若您的服务器曾宕机，可使用重发功能。若团队通过统一的支付编排层路由多种支付方式，则会对每条通道应用同样的模式。
如何为会计工作构建 CSV 导出文件？#
从发票列表 API 构建导出文件，每张发票一行，每笔转账再加一行。在 ItisPay 中，`GET /invoices` 可按状态、币种和创建日期筛选，按日期或金额排序，每页最多返回 100 张发票，并附带页数。一个小脚本可以遍历某一天或某个月的所有页面，并根据上方字段表写入各列。
两个文件比一个更好用：
- `invoices.csv`：invoice_id、order_id、fiat_amount、fiat_currency、currency、crypto_amount、actual_crypto_amount_paid、status、created_at、updated_at。会计人员导入此文件，并与销售数据进行核对。
- `transfers.csv`：invoice_id、tx_hash、amount、currency、transfer status、time。这是供审计人员查阅的凭证文件。
将发票文件导入会计工具的方式与导入银行卡结算报表相同：每个订单一行，以欧元计价，并以订单 ID 作为匹配键。
哪些欧盟规则会影响加密支付记录？#
有三项欧盟规则构成了背景。它们都不会使商户成为加密资产服务提供商（CASP），但决定了哪些数据存在以及保存多久。
- 《资金转账条例》(EU) 2023/1113。自 2024 年 12 月 30 日起，付款方的加密资产服务提供商必须确保每笔转账都附有付款方和收款方的信息，例如姓名和分类账地址（第 14 条）。这些数据随转账一同传递，而非包含在转账之中。对于与自托管钱包之间金额超过 1000 欧元的转账，相关一方的服务提供商必须评估该钱包是否属于其自身客户（第 14 条和第 16 条）。这是持牌服务提供商的职责，也是一笔支付可能处于审核状态的原因之一。
- 记录保存。根据现行《反洗钱（AML）指令》(EU) 2015/849 第 40 条，义务实体须在业务关系结束或交易发生后保存交易记录五年。新的《反洗钱（AML）条例》(EU) 2024/1624 保留了五年期限（第 77 条），并自 2027 年 7 月 10 日起适用。
- DAC8，指令 (EU) 2023/2226。自 2026 年 1 月 1 日起，加密资产服务提供商须向税务机关报告其用户的加密交易。您自己的记录应与您的服务提供商所报告的内容一致。
如果您通过持牌合作伙伴开展业务，该合作伙伴将依据 MiCA 及上述规则承担 CASP 义务，详见我们关于 MiCA CASP 牌照的指南。您仍需保留自己的订单记录以及您这一侧的交易轨迹。
加密对账中哪些环节仍需人工介入？#
自动化可处理全额付清的情况。其余情况需要指定负责人和一份简短的书面政策。
此方法不适用的情况
- 退款是新的转出交易，而非冲正。它们需要向地址或 IBAN 付款，并需要单独的记录。
- 从交易所账户付款的付款方，无法总是通过发送地址识别。应仅按发票匹配，切勿按付款方匹配。
- 付给已过期发票的款项、重复付款以及币种错误的付款，都需要人工决策。
- 网络手续费和舍入会造成细小差异。请一次性确定容差标准并始终遵守。
五步完成的每日加密支付对账流程#
一个简短的每日流程，可让月末结账变成例行手续：
- 从 API 拉取自上次运行以来创建或更新的发票，并更新发票和转账文件。
- 检查每个 `completed` 发票在您的店铺或 ERP 中是否都有对应的已付款订单，反之亦然。
- 处理异常清单：`paid_partial`、付给已过期发票的款项、币种错误的付款。每项都须以书面决定结案。
- 将银行账户中的欧元结算款项与该期间已完成发票的总额进行核对。结算至 IBAN 时，虚拟 IBAN 有助于按业务线区分资金流。
- 将两份文件至少保存五年。
如果您希望接受稳定币并收取欧元，而无需自行搭建这套系统，ItisPay 可提供 API、开票和对账数据：发票和订单 ID、每笔转账的哈希值、状态以及 Webhook。牌照、KYC 和结算至您的 IBAN 均通过我们获欧盟许可的 CASP + 支付机构合作伙伴办理，大多数团队从 KYB 到首笔交易不足一周。
本文仅供参考，不构成法律或监管建议。
