Skip to main content

总览

核心原则​

  • 规则优先，AI 辅助
  • 先跑通，再优化
  • 所有结果可解释、可审计

场景与价值

场景一：发票大额 / 高税率风控​

围绕「单张发票金额是否异常、税率是否超政策上限」等问题，提供规则可配置的发票风控能力。

业务痛点

  • 线下抽查靠人工经验，覆盖率低
  • 规则散落在制度文档中，难以落地与统一维护
  • 问题发票难以追踪来源与处置结果

产品价值

  • 将制度规则结构化，落地到可配置规则引擎
  • 支持在线试跑与解释，方便与业务、风控、内审对齐
  • 通过 Webhook 与工作流，将「命中高风险」自动衔接到下游系统

场景二：费用报销异常行为识别（规划中）​

结合员工历史报销行为、部门基线、时间窗口等，对费用报销异常行为进行识别与量化评分。

方向示例

  • 员工历史行为统计（频次、金额）
  • 部门均值 / 中位数对比
  • 滑动窗口（30/90 天）趋势分析

（该模块可以作为发票风控之后的第二阶段演进能力。）

核心能力拆分

1. 发票解析与建模​

发票数据通过「发票解析服务」进入平台，最终沉淀为统一的发票实体模型。

1.1 发票解析服务​

接口形态示例：

  • POST /invoice/upload
  • GET /invoice/{id}

核心任务包括：

  • 发票文件上传（PDF / 图片）
  • OCR 与发票类型识别
  • 发票字段解析与去重（发票代码 + 号码）
  • 预留发票验真接口

1.2 发票实体 fin_invoice​

在 LoamBase 元数据中使用 DataModel 定义发票实体 fin_invoice，字段示例：

  • 基础信息：invoice_code、invoice_no、invoice_date、buyer_tax_id、seller_tax_id
  • 金额类：amount、tax_amount、tax_rate、currency
  • 风险类：risk_tags（JSON/数组，用于存放风险标签）

通过统一的实体模型，规则引擎与下游系统都可以基于相同的数据结构协同工作。

2. 费用合规规则引擎​

费用合规规则引擎复用 LoamBase 元数据服务中的通用规则引擎能力。

2.1 规则管理能力​

已具备的规则管理能力包括：

  • 规则 CRUD：POST/PUT/GET/DELETE /api/v1/rules
  • 规则启停：enabled 字段控制
  • 规则试跑（Dry-run）：POST /api/v1/rules/evaluate

规则以 JSON 形式持久化在 rule_definitions 表中，支持：

  • comparison：单字段比较（eq / ne / gt / lt 等）
  • logical：and / or 组合
  • not：取反
  • value 支持字面量、字段引用、表达式（SpEL）

2.2 发票大额 / 高税率规则示例​

以「单张发票金额超过策略阈值」或「税率超过政策上限」为例，可以定义规则：

  • invoice.amount > policy.single_invoice_max_amount
  • 或 invoice.tax_rate > policy.max_tax_rate

规则执行返回：

  • result：整体是否命中
  • matchedPaths：命中的字段路径，便于做可解释性展示

业务可以基于这些信息打上风险标签，进入后续流程。

3. 实体 Webhook 与下游集成​

通过实体 Webhook，将 fin_invoice 的变更实时推送给下游风控或审批系统。

3.1 实体 Webhook 配置​

在元数据中为 fin_invoice 配置 Webhook，关键参数包括：

  • entityName: fin_invoice
  • events: INSERT,UPDATE
  • webhookUrl: 下游风控系统地址
  • secret: 用于签名校验的密钥

执行流程：

  1. 数据服务对 fin_invoice 执行 insert/update
  2. 写入租户库中的 mutation_webhook_outbox 表
  3. 调度器 WebhookOutboxDispatcher 读取 outbox，构造 HTTP 请求并推送至下游

3.2 下游验签与处理​

下游服务需要：

  • 校验时间戳与签名（防重放、防篡改）
  • 解析 payload 中的发票数据与 risk_tags
  • 将高风险发票写入自身风控库或触发告警 / 审批流程

4. 接入 Linker 工作流（可选）​

在上述链路基础上，可以将规则评估与后续动作放入 Linker 工作流中，实现更加可视化、可配置的编排。

4.1 工作流职责​

典型工作流职责：

  • 接收发票事件（包括发票详情与策略上下文）
  • 调用元数据规则引擎 /metadata/rules/evaluate
  • 根据结果分支执行：
    • 高风险：写入风险记录 / 推送告警 / 触发人工审批
    • 低风险：记录审计日志后结束

4.2 输入与节点设计示例​

工作流输入 payload 包括：

  • invoice：发票详情
  • policy：策略阈值
  • source：来源实体、操作类型、请求 ID、租户 ID 等

节点示例：

  • Start：接收上述 payload
  • HTTP：调用规则评估接口
  • Condition：判断是否高风险
  • HTTP：写入内部风控系统或外部告警系统
  • Approval（可选）：发起人工审批

5. AI 归类与风险解释（辅助能力）​

在规则引擎之外，可以引入 LLM 辅助做「归类与解释」，但不负责打分与最终决策。

5.1 费用类型 AI 归类​

  • 输入：商品/服务名称等文本字段
  • 输出：费用类型建议
  • 支持人工修正，修正结果可以反向写入规则或映射表

5.2 风险解释生成​

  • 输入：命中规则列表、异常指标（金额、频次、税率等）
  • 输出：面向财务人员的自然语言解释，如：

该报销在金额和频次上均明显高于历史水平，存在合规风险，建议人工复核。

LLM 仅负责生成解释内容，不参与风险评分，以保证结果可解释、可复盘。

端到端链路总览

发票风控产品在 LoamBase 上的典型端到端链路如下：

  1. 元数据服务：定义发票实体 fin_invoice
  2. 规则引擎：创建并启用大额/高税率等规则
  3. 实体 Webhook：为 fin_invoice 配置变更推送
  4. 发票解析服务：解析并写入发票数据
  5. 数据服务：通过 Mutation 写入 fin_invoice，并写入 outbox
  6. Webhook 调度器：根据配置推送到下游风控系统或 Linker 工作流
  7. 下游系统：验签、解析、入库或触发审批/告警
  8. （可选）AI：生成风险解释与摘要，辅助人工决策

通过上述链路，企业可以在不推翻现有财务系统的前提下，逐步把制度规则与 AI 能力沉淀到统一的平台之上，实现「规则可配置、过程可追踪、结果可解释」的财务合规能力。

发票技术资源​

doc/product/financial 目录下已经为「财务合规（发票风控）」准备了一整套可落地的技术资源。为方便在文档侧按模块浏览，这里只保留索引，详细内容拆分到多个子页面：