Report Missing an Expected Row: How to Find and Fix It

TL;DR — If a report is missing one row, the most common cause is a filter, date range, or join (combining tables) that excludes it. Start by checking the report filters and time zone, then confirm the row exists in the source data, and finally compare the report query against the raw record to see where it gets filtered out. Reading time: ~6 min

The scenario

It is Tuesday afternoon, you are reviewing a client-facing report, and one customer order you know was created this morning is nowhere in the list. You refresh the page, widen the date range, and even ask a teammate to check from their account, but the row still does not appear. The dashboard looks otherwise normal, totals are close to what you expect, and there is no obvious error banner. You need to figure out whether the row was never saved, is being filtered out, or is present in the database but missing from the report logic.

Symptoms

• A report grid or CSV export is missing one specific record you expected to see.
• Totals look slightly low, but not completely broken.
• The application may show the record on its detail page, but not in the report.
• Common user observations:
  • "I can open the order, but it does not appear in the sales report."
  • "It shows up yesterday in the app, but not in today's report."
  • "The export has 99 rows, but I expected 100."
• If you can inspect SQL logs or query text, you may see patterns like:

WHERE created_at >= '2026-10-01 00:00:00'

INNER JOIN customers c ON c.id = orders.customer_id

WHERE status = 'paid'

• If soft delete (hidden instead of fully removed) is involved, you may find a field like:

deleted_at IS NOT NULL

Likely causes

Step-by-step diagnosis

1. Reset report filters first
   In your app's report screen, use the filter panel and click Reset, Clear all, or remove each active filter chip. If your provider dashboard has saved views, switch from a saved view to the default report view.

   • This is your problem if: the missing row appears immediately after clearing filters.
   • Jump to: ### Filter or date range excludes the row

2. Widen the date range and check time zone effects
   In the report UI, change the date filter from presets like Today or This week to a custom range covering at least one day before and one day after the expected date. If the app has a profile or workspace setting for time zone, note it.

   • This is your problem if: the row appears only when the date range is widened, or appears on the previous/next day.
   • Jump to: ### Time zone mismatch shifts the row outside the selected day

3. Open the missing record directly and compare status/fields
   Use the app search to open the specific record by ID, email, order number, or name. Compare its fields to the report filters: status, owner, team, region, payment state, and created date.

   • This is your problem if: the record exists, but one field does not match the report's criteria.
   • Jump to: ### Record status or field values do not match report criteria

4. Check whether your account can see the row in reports
   Ask a workspace owner or admin to open the same report with the same filters, or switch to an admin role if your app supports role switching.

   • This is your problem if: an admin can see the row, but your account cannot.
   • Jump to: ### Row-level permissions or account scoping hide the record

5. Check whether the row is archived or soft-deleted
   In the record detail page, look for labels like Archived, Deleted, Inactive, or Hidden. If you have database access, run:

SELECT id, archived_at, deleted_at, status
FROM orders
WHERE id = 12345;

• This is your problem if: archived_at or deleted_at has a value, or the UI marks the record archived.
• Jump to: ### Source row was soft-deleted or archived

1. Compare the raw row to the report query
   If your agency has given you SQL access, test the missing record directly. Start with the base table, then add the same filters and joins used by the report.

SELECT * FROM orders WHERE id = 12345;

SELECT o.id, o.created_at, o.status, c.id AS customer_id
FROM orders o
INNER JOIN customers c ON c.id = o.customer_id
WHERE o.id = 12345;

• This is your problem if: the base query returns the row, but the joined or filtered query does not.
• Jump to: ### Report query uses an INNER JOIN and drops unmatched rows

1. Check for reporting delay
   If the row was created very recently, wait 5-10 minutes and refresh the report or rerun the export. Some systems build reports from a read replica (a copy of the database used for reporting) or a cache (temporary stored results).
   • This is your problem if: the row appears later without any other change.
   • Jump to: ### Reporting data is delayed by replica or cache lag

Fixes

Filter or date range excludes the row

Clear the report filters and rebuild them one by one. In the report UI, remove filters such as status, owner, region, or saved search conditions. Then set a custom date range instead of a preset.

If the report is SQL-based, compare these two patterns:

-- Too narrow
WHERE created_at >= '2026-10-01 00:00:00' AND created_at < '2026-10-02 00:00:00'

-- Wider check for diagnosis
WHERE created_at >= '2026-09-30 00:00:00' AND created_at < '2026-10-03 00:00:00'

Verify it worked: rerun the report and confirm the expected record ID appears.

Time zone mismatch shifts the row outside the selected day

If your app has a workspace or user time zone setting, align it with how your team interprets "today." In your provider's dashboard or app settings, look for Settings → Localization, Workspace settings → Time zone, or Profile → Time zone.

If you control the SQL, convert timestamps before grouping or filtering by date:

-- Example for PostgreSQL
SELECT id, created_at AT TIME ZONE 'UTC' AT TIME ZONE 'America/New_York' AS local_created_at
FROM orders
WHERE (created_at AT TIME ZONE 'UTC' AT TIME ZONE 'America/New_York')::date = DATE '2026-10-01';

Verify it worked: the row appears on the correct day without widening the range.

Record status or field values do not match report criteria

Update the record so it matches the report's intended rules, or update the report to include the real statuses you use.

Example SQL fix if a row should be marked paid:

UPDATE orders
SET status = 'paid'
WHERE id = 12345;

Or update the report filter/query:

WHERE status IN ('paid', 'settled')

⚠️ Changing record status can affect billing, downstream automations, and customer-visible totals. If this is a financial or compliance-sensitive record, confirm with the business owner before editing it.

Verify it worked: open the record detail page, confirm the field value, then rerun the report.

Report query uses an INNER JOIN and drops unmatched rows

If the row exists in the main table but not after the join, change INNER JOIN to LEFT JOIN (keep all rows from the main table even if the related table has no match) when that fits the report's purpose.

Example:

-- Before
SELECT o.id, c.name
FROM orders o
INNER JOIN customers c ON c.id = o.customer_id;

-- After
SELECT o.id, c.name
FROM orders o
LEFT JOIN customers c ON c.id = o.customer_id;

If the related data should exist but does not, repair the missing foreign key (link to another row):

UPDATE orders
SET customer_id = 678
WHERE id = 12345;

⚠️ Editing foreign keys can attach records to the wrong customer or project if you guess. Confirm the target ID before running the update.

Verify it worked: rerun the joined query for the missing ID and confirm it now returns one row.

Row-level permissions or account scoping hide the record

If admins can see the row but standard users cannot, update the report scope or the user's role/team membership in your app's admin area. In your provider's dashboard, look for paths like Settings → Users, Workspace → Members, or Roles & permissions.

If permissions are SQL-based, inspect the scope field:

SELECT id, team_id, owner_id
FROM orders
WHERE id = 12345;

Then compare it to the viewing user's allowed team or owner scope.

Verify it worked: the affected user can open the same report and see the row without using an admin account.

Source row was soft-deleted or archived

Restore the record from the app UI if available, usually from Archived, Trash, or the record action menu. If you have SQL access and your application uses soft delete fields:

UPDATE orders
SET deleted_at = NULL,
    archived_at = NULL
WHERE id = 12345;

⚠️ Restoring deleted or archived records can re-trigger automations, notifications, or totals. Check whether your app syncs this table to billing, CRM, or email systems.

Verify it worked: the record detail page no longer shows Archived/Deleted, and the report includes the row.

Reporting data is delayed by replica or cache lag

Wait for the reporting refresh window, then rerun the report. If your agency controls the cache layer, clear the report cache in the app admin area or redeploy the report service if that is your normal process.

If your team uses materialized views (precomputed report tables), refresh them:

REFRESH MATERIALIZED VIEW report_orders_daily;

Verify it worked: the row appears after refresh, and newly created records show up within the expected delay window.

Prevention

• Add a "raw record vs report" check to CI for important reports. Example SQL test:

-- Fails if any paid order from the last day is missing from the report source
SELECT o.id
FROM orders o
LEFT JOIN report_orders_daily r ON r.order_id = o.id
WHERE o.status = 'paid'
  AND o.created_at >= NOW() - INTERVAL '1 day'
  AND r.order_id IS NULL;

• Pin report time zone logic in code instead of relying on server defaults:

-- PostgreSQL session setting for report jobs
SET TIME ZONE 'UTC';

• Add an alert for replica lag if reports read from a replica. For PostgreSQL, monitor:

SELECT now() - pg_last_xact_replay_timestamp() AS replication_delay;

• Prefer LEFT JOIN in reports where missing related data should not hide the main record. Then explicitly flag incomplete rows:

CASE WHEN c.id IS NULL THEN 'missing customer' ELSE 'ok' END AS data_quality_flag

• Add a saved "diagnostic" report view with no filters except a wide date range, so support can quickly rule out UI filters.
• Log the final SQL or filter JSON used to generate each export, so you can compare a missing-row complaint to the exact report definition that ran:

{"report":"orders_daily","filters":{"status":["paid"],"date_from":"2026-10-01","date_to":"2026-10-01","timezone":"America/New_York"}}

This article was written by an AI system and published pending human review. Verify anything you intend to act on.