Measure reconciliation queue ageing consistently

Choose one clock for each ageing measure

Use consistent dates so the team can identify genuinely stalled work instead of debating what the backlog numbers mean.

When an exception needs a supplier invoice schedule, ParseMill can extract the invoice PDFs into Excel and keep source references available for checking. That gives the reviewer a concrete starting point. Bank reconciliation, accounting judgments and posting stay in your accounting system.

For operational queue ageing, detection-to-reporting-date is a useful proposed measure, while transaction age and time with the current owner answer different questions. Choose the measures that serve your review and name them clearly. Do not blend them into one unlabeled days-open column.

Write the definition beside the report

Record the start event, calendar-day or business-day basis, reporting date and timezone where timestamps matter, treatment of closed cases, and handling of reopens. Preserve the original detection date when ownership changes. If you report active time excluding pauses, retain the pause intervals and show that it is a different measure.

Microsoft: Sorting data describes sorting by multiple fields. Microsoft: Refreshing filters describes refreshing filtered views. Those features help inspect ageing, but the proposed definition controls what the numbers mean. A correctly sorted report can still be wrong if its date fields represent different events or its filter excludes carried-forward cases.

Compare three clocks on one fictional case

Assume a reporting date of 25 October and calendar-day differences. The dates below are synthetic and demonstrate why the labels matter.

All three numbers are valid for their stated purposes. Calling the case five days old hides ten days of prior queue time. Calling it twenty-four days overdue may also be wrong unless an actual deadline supports that label. Age and overdue status should therefore remain separate calculations.

Handle reopens and pauses explicitly

For reopened cases, keep the original detection date and a reopen date. Report total case age and current reopen-cycle age separately if both are useful. A pause can explain waiting time without resetting history. Decide whether it changes the metric before publishing comparisons, and apply the rule consistently.

• Preserve transaction, detection and assignment dates separately.
• State calendar-day or business-day calculation rules.
• Use a fixed reporting cutoff for comparisons.
• Retain original age through transfers.
• Label reopened-cycle and pause-adjusted measures distinctly.

If a detection date is missing, mark the case's queue age unknown until the record is reconstructed. Do not substitute transaction date silently. A report with visible missing-date counts is more honest and more useful than a precise-looking number built from inconsistent assumptions.

Validate the calculation with boundary cases

Test a case detected on the reporting date, a carried-forward case, a reassigned case and a reopened case. Check the expected ages manually before relying on formulas or dashboards. Then compare the included case population with the open register so the report is not missing older items.

Use the related workflow guide for the wider exception process and the workflow audit checklist to review backlog measurement. A useful report makes its clock and population explicit, allowing the team to distinguish long-standing issues from time spent with the current owner.