税报里最容易让人怀疑人生的情况之一，就是“同一张发票，为什么这个税的税基变大了”。企业版 generic tax report 的测试把这个问题拆得很细：有些税会影响后续税的 base，而不同分组报表只是把同一事实按不同维度展开。
参考入口：
enterprise/account_reports/tests/test_tax_report_default_part.pyenterprise/account_reports/models/account_generic_tax_report.py
一、include_base_amount 会把前一个税并进后一个税基
test_tax_affect_base 里，tax_20_affect_base 设置 include_base_amount=True 后，后续 10% 税的税基不再是原始 2000，而变成 2400。这不是报表 bug，而是税定义本身在说：前税额要进入后税基。
二、同一事实在不同 grouped report 里会换视角，不会换真相
测试同时跑了：
- generic tax report
- grouped by account then tax
- grouped by tax then account
三张报表看起来布局不同，但合计一致。差异只是你先按科目拆、还是先按税种拆。把不同视图当成不同结果，往往才是误判来源。
三、audit drilldown 依赖 caret option 把税线回到 AML 集合
测试里通过 caret_option_audit_tax() 验证：点税行下钻后，系统会把对应 tax line 和带该 tax 的 base line 一起找出来。也就是说，审计不是只看税分录，而是要看组成该税口径的整组 move lines。
四、实施误区通常发生在“税配置”和“报表解释”混为一谈
很多财务会先问“为什么报表算错”，但真正该先问的是：
- 这个税是否
include_base_amount=True？ - 当前看到的是按 tax 分组还是按 account 分组？
- 下钻拿到的 AML 是否和预期税组一致？
五、实战建议
- 做税报培训时，把税定义与报表视图一起讲，不要拆开。
- 出现税基放大时先查 tax config，不要先改报表。
- 审计时用 drilldown 验证底层 AML 组成，别只看汇总数。
六、结论
Tax Report 最难的地方不是“算税”，而是理解税定义如何改变税基、报表如何换维度展示、审计如何把汇总重新落回分录。把这三层分清，很多争议会立刻消失。
DISCUSSION
评论区