Audit a dashboard for the specific mistakes that make numbers look right until someone checks

Run a QA audit on the dashboard described below the way an experienced analyst would before it ships to a wide audience — looking specifically for the errors that look fine at a glance and only surface when someone checks the math.

DASHBOARD DESCRIPTION
A revenue-by-region dashboard joining an orders table to a shipments table, with charts for total revenue, average order value, and on-time delivery rate

METRIC DEFINITIONS AS BUILT
Total revenue = SUM(orders.amount) after joining to shipments on order_id; on-time rate = COUNT(delivered_on_time)/COUNT(all shipment rows)

KNOWN DATA SOURCES FEEDING IT
Orders table logged in UTC from the checkout system; shipments table logged in local warehouse time from a separate logistics vendor system

AUDIENCE AND STAKES
Regional VPs use this weekly to evaluate performance bonuses tied to on-time delivery rate

Check each of the following categories and report a finding or an explicit "checked, no issue found" for each — do not skip a category just because nothing obvious jumped out.

1. DOUBLE-COUNTING — could any metric be summing across a join that fans out rows, inflating a total (e.g., joining orders to a one-to-many items table and then summing an order-level field, multiplying it by item count)?
2. FILTER LEAKAGE — does every chart on the dashboard apply the same date range and segment filters consistently, or could one chart be silently using a different implicit window than the one displayed in the filter control, producing numbers that don't actually correspond to what the filter appears to say?
3. DENOMINATOR MISMATCH — for any rate or percentage metric, does the numerator and denominator come from genuinely the same population and time window, or could a rate be computed from a numerator filtered one way and a denominator filtered another, producing a percentage that isn't actually measuring what it claims to?
4. TIMEZONE/BOUNDARY DRIFT — for any metric bucketed by day or month, is the timezone used for bucketing stated and consistent across all data sources feeding it, given that Orders table logged in UTC from the checkout system; shipments table logged in local warehouse time from a separate logistics vendor system may log timestamps in different timezones?
5. SURVIVORSHIP OR SAMPLE BIAS — does any metric implicitly exclude a group in a way that biases the result (e.g., an "average session length" that only includes completed sessions, silently excluding the abandoned ones that would pull the average down)?

WHAT NOT TO DO
Do not report only the issues found and silently skip the categories where nothing was wrong — an audit needs to show its work on every category checked, not just the ones with findings. Do not treat a suspected issue as confirmed without stating what would need to be checked in the actual data to confirm it.

OUTPUT FORMAT
For each of the 5 categories: verdict (issue found / no issue found / can't determine from what's given) and, for any issue found, exactly what to check in the real data to confirm it and what the fix would look like.
Followed by: overall risk level given Regional VPs use this weekly to evaluate performance bonuses tied to on-time delivery rate, and whether this dashboard should ship as-is, ship with a caveat noted, or be held pending fixes.