Set a narrow review boundary
Use this suggested workflow practice after the custom system, relevant records and report purpose have already been scoped. The deliverable is one completed reconciliation acceptance sheet for one named report view. It records whether the displayed total can be traced to the agreed source population under an agreed filter and as-of time. It is not a promise that every future report, every later data change, or every business decision will be accurate.
Bring the dated scope or release reference, the report name, the named source location, and the people who can explain the report and accept the result. State the review question in observable language: “Does this report show the agreed count of included records at the stated point in time?” Avoid a broad question such as “Are the reports correct?” That wording hides which report, which records and which rule are being reviewed.
This page does not choose a dashboard, compare software categories, define accounting treatment, test exports, restore backups, alter permissions, or approve a whole release. If the review shows that a new field, filter, workflow rule or report is needed, record it as a separate scope decision. Do not quietly add it to the acceptance sheet.
- Name one report view
- Attach scope reference
- Identify source location
- Name acceptance owner
Describe the report view exactly
Write the report title as displayed, its release or environment reference, the person running it, and the date and time it was run. Capture every setting that changes the population: date range, status, owner, location, category, search term, timezone if shown, and whether empty values are included. “Current records” is not enough because a later reader cannot reproduce it.
Set one as-of time. This is the point at which the source and report are treated as the same review population. If the source keeps changing, pause routine changes where practical, take a saved view or export only for the review, or record that the result is provisional. Do not compare a source read at one time with a report refreshed much later and call the difference unexplained.
Name the source used to check the report: for example, an agreed record list, a controlled extract, or another in-scope system view. A source reference should be stable enough for a reviewer to find the item again. Row number alone may change; use a record identifier together with the source location where possible.
- Record run time
- List every filter
- State as-of time
- Name source view
Agree the counting rules first
Before looking at the total, define the counting unit. A report may count distinct parent records, detail rows, users, tasks, or another agreed unit. One parent record with three detail rows can legitimately appear three times in a line-based report but once in a distinct-record report. Neither number is inherently wrong; acceptance depends on the rule written before comparison.
List positive inclusion rules and explicit exclusions. Examples of exclusions may include cancelled records, test entries, drafts, records outside the date rule, or records without a required condition, but only when those rules are already agreed or explicitly decided for this review. State whether a cancelled record remains visible but contributes zero, is absent entirely, or belongs in a separate figure.
Keep report logic separate from a business explanation. A reviewer may need to know why a record is excluded, yet the acceptance sheet should say precisely how that decision affects the counted population. If a value is unknown, label it unknown and assign an owner to resolve it; do not turn a blank into an assumed zero or inclusion.
- Define counting unit
- List inclusion rules
- List exclusion rules
- Mark unknown values
Build the reconciliation sheet
Create one compact sheet with these fields: report identity; run time; as-of time; source identity; filters; counting unit; inclusion and exclusion rules; expected total; displayed total; variance; sample references; reviewer; acceptance owner; decision; and open exception. The expected total is calculated from the agreed source under the written rules. The displayed total is what the report shows. Variance is the difference between them, expressed in the same unit.
Use samples to make the total inspectable, not to replace the total check. Include at least one included reference, one excluded reference where an exclusion applies, and one parent record with multiple detail rows if the report can show line rows. For each sample, record its source reference, whether it should be included, the reason, and what the report displays.
A useful acceptance criterion is observable: the named report, run with listed settings at the stated time, displays the expected total; sampled references follow the stated rules; and any remaining variance has a recorded disposition. This follows the general idea that acceptance criteria describe checkable outcomes. It does not make the worksheet a legal, audit, or accounting standard.
- Calculate expected total
- Capture displayed total
- Show variance result
- Link sample records
Work through a fictional count
Fictional example: the agreed report is “Open Work Detail” as of 14:00 in a test environment. Its filter is work dated in the agreed week and status not cancelled. The source list contains parent records W-101, W-102 and W-103. W-101 has two qualifying detail rows. W-102 has one qualifying detail row. W-103 has two detail rows but is cancelled, so both rows are excluded under the stated rule.
The worksheet says the counting unit is qualifying detail rows, not distinct work records. Expected total: three rows: two from W-101 and one from W-102. Displayed total: three rows. Variance: zero. Sample checks show W-101 twice, W-102 once, and W-103 absent. The acceptance owner can accept this report view because the written rule, source count and display agree.
If the report instead displayed two, first check whether it deduplicates parent records. If that is its designed rule, the original counting unit is wrong for this report and the team must either revise the acceptance question or use another report. If it should count detail rows, record a variance and do not accept merely because the records look familiar.
- Label example fictional
- Check parent records
- Check detail rows
- Check cancelled records
Decide exceptions and handover
Use three clear decisions. Accept when the expected and displayed totals reconcile and samples follow the stated rule. Accept with a recorded limitation only when the acceptance owner explicitly agrees a bounded, understood limitation that does not hide an unresolved mismatch. Hold acceptance when the filter, source, counting unit, sample evidence or variance is unclear. A hold is a decision, not a failure to document.
For each variance, record the amount, affected references, first observed time, likely category, evidence reviewed, next action, owner and review point. Categories might include a different filter, a timing gap, duplicate source data, missing data, distinct-versus-line counting, or an unresolved cause. Do not claim a cause without evidence. Preserve the original result; do not overwrite it after a later correction.
At handover, attach the signed or otherwise recorded sheet to the release evidence. State exactly what was accepted: one report, one filter set, one as-of time and one counting rule. State what was not reviewed, such as other reports, future data, source correction processes, financial interpretation or live configuration. Outcomes are not promised; the sheet makes this limited review reproducible.
- Record exception owner
- Choose acceptance decision
- Attach review evidence
- State review limits
中文指南
先限定审阅范围
这份建议工作方法适用于自定义系统、相关记录和报表用途已经确定之后。交付物是一份针对一个指定报表视图的完整对账验收表，说明在约定筛选条件和截至时间下，报表显示总数是否可追溯至约定来源记录。它不是对所有未来报表、之后资料变动或业务决定的承诺。
准备已注明日期的范围或发布参考、报表名称、来源位置，以及能够解释报表并作出验收决定的人。把问题写成可观察的句子，例如：“在指定时间点，这份报表是否显示符合规则的记录数量？”不要只问“报表是否正确”，因为这没有说明审阅哪份报表、哪些记录和哪条规则。
本页不用于选择看板、比较软件类别、规定会计处理、测试导出、还原备份、修改权限，或批准整个发布。如果审阅发现需要新字段、新筛选条件、新流程规则或新报表，应另行记录为范围决定，不要悄悄放进验收表。
- 写明单一报表
- 附上范围参考
- 确定来源位置
- 指定验收负责人
准确描述报表视图
记录画面显示的报表名称、发布或环境参考、执行人及运行日期时间。写下每一个会改变记录范围的设定：日期范围、状态、负责人、地点、类别、搜索词、显示的时区，以及是否包含空值。“当前记录”并不足够，因为后来的人无法重现这次检查。
确定一个截至时间，也就是来源和报表被视为同一审阅总体的时点。如果来源持续变化，可在实际可行时暂停日常修改、只为审阅保存视图或导出，或注明结果为暂定。不要把一个时间读取的来源与很久后刷新的报表相比，再把差异称为无法解释。
写明用来检查报表的来源，例如约定记录清单、受控导出或范围内的另一系统视图。来源参考应足以让审阅者再次找到项目。行号可能改变；尽可能同时使用稳定记录编号和来源位置。
- 记录运行时间
- 列明所有筛选
- 注明截至时间
- 命名来源视图
先约定计数规则
查看总数之前，先定义计数单位。报表可能计算不重复的主记录、明细行、用户、任务，或其他约定单位。一条主记录有三条明细时，在逐行报表中出现三次、在去重记录报表中出现一次都可能合理。重点不是哪一个数字天然正确，而是比较前写明的规则。
列出纳入规则及明确排除规则。可排除的例子包括已取消记录、测试资料、草稿、不在日期规则内的记录，或不符合某项必要条件的记录，但仅限于已经约定或本次明确决定的规则。说明已取消记录是仍会显示但不计数、完全不出现，还是应归入另一项数字。
将报表逻辑与业务解释分开。审阅者可能需要知道记录为何被排除，但验收表必须准确说明该决定怎样影响计数总体。若某值未知，应标为未知并指定负责人处理；不要把空白当作零、纳入或排除。
- 定义计数单位
- 列出纳入规则
- 列出排除规则
- 标示未知数据
建立对账验收表
建立一份简洁表格，包含：报表识别资料、运行时间、截至时间、来源识别资料、筛选条件、计数单位、纳入和排除规则、预期总数、显示总数、差异、抽样参考、审阅人、验收负责人、决定和未结异常。预期总数是按书面规则从约定来源计算；显示总数是报表所示；差异以相同单位表示两者之差。
抽样是让总数可以检查，不是取代总数检查。至少包括一条纳入参考、一条适用排除规则的排除参考，以及一条有多条明细行的主记录（如报表可能显示明细行）。每个样本记录来源编号、是否应纳入、理由及报表显示结果。
一项有用的验收条件必须可观察：指定报表在列明设定和指定时间下显示预期总数；抽样参考遵循书面规则；任何残余差异都有记录的处理决定。这借用验收条件应描述可检查结果的一般原则，但本工作表不是法律、审计或会计标准。
- 计算预期总数
- 记录显示总数
- 展示差异结果
- 连接样本记录
演练虚构计数案例
虚构例子：约定报表为测试环境中的“未结工作明细”，截至时间为14:00。筛选条件是约定周内的工作，且状态不是已取消。来源清单有主记录 W-101、W-102 和 W-103。W-101 有两条符合条件的明细行；W-102 有一条；W-103 有两条明细行，但状态已取消，所以两条都按书面规则排除。
验收表写明计数单位是符合条件的明细行，而不是不重复工作记录。预期总数为三行：W-101 两行加 W-102 一行。显示总数为三行，差异为零。样本检查显示 W-101 两次、W-102 一次、W-103 不出现。因为书面规则、来源计数和显示一致，验收负责人可接受这个报表视图。
若报表反而显示两行，先检查它是否按主记录去重。若这是它的设计规则，则原本的计数单位不适合此报表；团队应修改验收问题或使用另一报表。若它本应计明细行，应记录差异；不能因为记录看起来熟悉就接受。
- 标明虚构案例
- 检查主记录数
- 检查明细行数
- 检查取消记录
处理异常并完成交接
使用三个清楚决定。预期与显示总数对得上且样本遵循规则时，接受。只有验收负责人明确同意某项范围有限、可理解且不会掩盖未解决不符的限制时，才可带限制接受。若筛选条件、来源、计数单位、样本证据或差异不清楚，则暂缓验收。暂缓也是一种记录完整的决定。
每项差异记录数量、受影响参考、首次发现时间、可能类别、已查看证据、下一步、负责人和复核时间点。类别可包括筛选不同、时间间隙、来源重复资料、缺失资料、主记录与明细行计数不同，或原因未明。没有证据不要宣称原因。保留原始结果，不要在后来更正后覆盖它。
交接时，把已签署或以其他方式确认的验收表附在发布证据中。明确写出接受的范围：一份报表、一组筛选条件、一个截至时间和一条计数规则。同时写明未审阅事项，例如其他报表、未来资料、来源更正流程、财务解释或线上配置。结果并非承诺；这份表让有限审阅可以重现。
- 记录异常负责人
- 选择验收决定
- 附上审阅证据
- 说明审阅限制
Sources and next step
Discuss your workflow scope with BossFlow · Compare system categories at SME Systems · All articles