费用生命周期

管理人或顾问录入的费用从录入到付款的路径，以及查询结果中出现的状态和来源。相关调用见本节后续页面。

管理人录入费用的流程

图例：实线蓝框是管理人的调用或费用等待管理人处理的步骤；灰色虚线框是 QI Tech 的步骤；绿框是已支付的费用；红框是被驳回的费用。

1. 供应商和合同，仅适用于需要合同的类型。
2. 录入。 以 pending_submission 状态录入费用，附带计算说明，如已有发票也可一并附上。费用在进入投资组合之前可以取消，即处于 pending_contract_analysis、pending_submission、pre_approved、in_manual_analysis 或 pending_manager_approval 状态时。
3. 提交。 提交费用审核，或在录入时传 submit: true。费用将进入以下两种路径之一：
   • 无计提： 状态变为 pre_approved，等待发票。如果合同仍在审核中，费用会先在 pending_contract_analysis 状态等待，合同生效后变为 pre_approved。
   • 有计提： 进入 QI Tech 审核（in_manual_analysis）。审核通过后以 in_provision 状态进入投资组合，并按日计提。如果合同仍在审核中，费用在审核通过后于 pending_contract_analysis 状态等待，合同生效后进入投资组合。
4. 发票。 当费用处于 pre_approved 或 in_provision 时，提交发票。在此之前，可以重新安排付款日期。
5. 合并和付款。 QI Tech 审核通过发票后，费用变为 consolidated。费用在审核指定的日期支付（paid），最终变为 completed。被拒绝的发票将由新的合并分析取代。

以下两种情况的流程有所不同：

• 顾问的费用。 顾问录入的费用和发票，在 QI Tech 审核之后还需经过管理人决定。
• QI Tech 计算的费用（例如管理费、投资管理费和业绩报酬）。这类费用在产生时即已进入投资组合。如果发票由管理人开具，也通过合并分析提交。

跟踪。 费用没有 webhook。请通过查询按 status 筛选跟踪。使用集成密钥通过 API 执行的操作会出现在 status_events 中，author_type: qitech。

费用状态

由管理人或顾问录入的费用首先经过提交和审核阶段。之后进入基金的投资组合，在其中计提、合并和支付。由 QI Tech 计算的费用在产生时即已进入投资组合。

图例：实线蓝框表示费用等待管理人或顾问处理；灰色虚线框表示费用由 QI Tech 处理；绿框为最终状态；红框为驳回。图中没有 canceled：通过 API，费用在进入投资组合之前都可以取消。取消合同也会取消该合同下已进入投资组合且尚未支付的费用；合同被驳回时，该合同下所有尚未进入投资组合的费用都会被驳回（contract_reproved）。

状态	阶段	说明
pending_submission	提交	已录入，等待提交审核。
pending_contract_analysis	提交	已提交，等待关联合同审核通过。
pre_approved	提交	预审通过：等待发票以完成合并。
in_manual_analysis	提交	QI Tech 审核中。
pending_manager_approval	提交	由顾问录入并经 QI Tech 审核通过，等待管理人决定。
reproved	提交	已拒绝。reproval_reason 说明原因；请录入新的费用。
created	投资组合	已登记，尚未进入投资组合。对于管理人或顾问录入的费用，只作为 status_events 的第一个事件出现。
in_provision	投资组合	在 start_deferral_date 和 end_deferral_date 之间按日计提。
on_demand_recognition	投资组合	按需确认，不按日计提。
consolidated	投资组合	金额已合并，可以付款。
paid	投资组合	已支付；计提持续至 end_deferral_date。
completed	投资组合	已支付且已全部确认。
canceled	任意	已取消。

费用拒绝原因（reproval_reason）：invalid_documents、missing_documents、incorrect_information、ineligible_contract、contract_reproved、manager_reproval。费用因 incorrect_value、incorrect_payment_data 或 rebate_inconsistency 与发票一同被拒绝时，费用的 reproval_reason 为 null；原因见 consolidation_analysis.reproval_reason。

费用来源

origin.origin_type 说明费用是如何产生的：

origin_type	来源
expense_contract	由管理人或顾问在费用合同下录入。origin_key 为合同的 key。
expense	由管理人或顾问在无合同情况下录入（公证处、诉讼费用、CVM 和 ANBIMA 费用）。
reimbursement	向管理人或顾问报销其已支付的费用。
rebate_fee	投资管理费返还，作为分销费录入。
quota_fee、performance_fee、payment_fee、recurring_expense、expense_control、manual	由 QI Tech 计算或登记。

合并分析

合并是用发票确定费用的最终金额。在此之前，金额为录入的金额（有计提时为每日计提的金额）；发票确认最终金额，金额可以不同，但需附说明。合并后（consolidated），费用的金额和付款信息即为最终版本，进入付款环节。

管理人或顾问录入的每笔费用都有一个合并分析：在合并和付款之前，核对发票、金额和付款信息。它在费用查询结果的 consolidation_analysis 中返回。相关调用见合并分析。

状态	说明
created	审核的初始记录；只作为 consolidation_status_events 的第一个事件出现。
pending_submission	等待提交发票。
in_manual_analysis	QI Tech 审核中。
pending_manager_approval	由顾问提交并经 QI Tech 审核通过，等待管理人决定。
approved	已通过。费用进入 consolidated。
reproved	已拒绝。请开启新的分析，新的分析使用下一个编号（analysis_number）。
consolidated	由 QI Tech 自动合并。
canceled	随费用一同终止。

分析拒绝原因（reproval_reason）：invalid_documents、missing_documents、incorrect_value、incorrect_payment_data、incorrect_information、manager_reproval、rebate_inconsistency。

错误

认证、权限和主机相关的错误：参见 API 错误。费用相关的错误以 EXP 为前缀，列在各调用的页面中。