数据分析在审计中的应用与思考

原创演示。代码使用虚构的 demo_transactions 表，只用于展示数据整理思路。

拿到一张交易明细后，最容易先做的动作是排序、筛选、画图。我会在这之前多花一点时间：这张表覆盖什么期间，金额字段的含义是什么，数据是否经过筛选，是否能够与已知汇总数核对。

一、先理解数据来源

数据来源说明最好和数据本身一起保存。取得日期、导出人员、系统名称、查询条件、字段定义与记录数，都可能帮助解释之后遇到的差异。如果明细分批导出，还需要确认期间之间是否重复或遗漏。

核对不是为了制造一条形式上的勾稽关系。明细合计与总账不一致时，先了解是否含税、是否包含冲销、是否使用不同日期字段。只有口径一致，比较结果才有意义。

二、用简单规则找到线索

下面的查询寻找同一供应商、同一天、相同金额的多笔交易。它只能提示需要了解的情况，不能证明重复付款。

SELECT vendor_id, payment_date, amount, COUNT(*) AS transaction_count
FROM demo_transactions
GROUP BY vendor_id, payment_date, amount
HAVING COUNT(*) > 1;

实际使用时还要考虑分期付款、同批采购、冲销记录等业务原因。规则的价值，在于把一张很大的表缩小为可以逐项追问的事项。

三、从异常走向证据

分析线索	后续问题	可以查看的资料
同日同额交易	是否来自不同订单？	订单、付款申请
年末集中入账	是否与业务完成时间一致？	业务记录、合同
金额突然变化	是价格、数量还是口径变化？	明细、解释与支持文件

不要在“筛出异常”这一步停下。把每一条线索的调查结果写回台账，区分已解释、需补资料与尚未解决。规则误报的原因也值得记录，下一次可以据此改进。

四、保留可复现的过程

原始文件、转换步骤、查询代码、结果表和核对记录应能够相互对应。修改规则后保存版本说明，避免最终报告中的数字无法回到当时的分析过程。

数据分析可以拓展观察范围，但结果仍需要结合业务事实和其他证据理解。先把数据口径弄清楚，再让工具帮助自己提出更好的问题。