> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dualentry.com/llms.txt
> Use this file to discover all available pages before exploring further.
# How to Clear the Anomaly Queue During Close
> Work the alert list down to zero before you lock the period, dismiss with reasons that improve later scans, and handle a queue too large to review by hand.
Anomaly alerts do not appear natively on the [month-end close checklist](../core-financials/close-management/month-end-close-checklist) and there is no email digest. Add the review as a checklist task in DualEntry, or keep it on your own close calendar, scheduled far enough ahead of lock that you can act on what it surfaces.
## Before you begin
Decide up front what "clear" means for your close. Zero open alerts is achievable on a tuned ledger and unrealistic on a noisy one. A target of zero open alerts on custom rules, with AI detector alerts triaged but not necessarily emptied, is the more common working standard.
Two things make the review go faster:
* **Do it before the period locks, not after.** Most alerts resolve by correcting the underlying transaction, and a locked period turns a two-minute fix into an unlock request. See [How to Lock and Unlock Accounting Periods](../core-financials/general-ledger/period-locking).
* **Know what feeds back.** Only the reasons you type on dismissed AI alerts influence later scans, and only the five most recent of them. Reasons on rule alerts are recorded for audit but change nothing about future scoring.
Reading the queue requires the transaction monitor view permission, and dismissing or restoring alerts requires the edit permission. The two are granted separately and are configurable per organization, so check your role if you can see the queue but cannot clear it.
## Work the queue
Work the alerts in the order below. It front-loads the decisions that are cheap to make and leaves the queue empty of anything you have not consciously judged.
Go to **Home > Anomaly Detection** and open a detector card. The alert list opens on the **Active** tab, with **Dismissed** alongside it.
Each row carries the explanation of why the alert fired, the transaction type and number, both dates, the company, the vendor or customer, currency, amount, and memo. The transaction number links into the record.
Rule alerts are unfiltered, so each one represents a condition you personally wrote and decided was worth interrupting yourself over. They are also finite and usually few. Clear them first.
AI detector alerts are already filtered to high confidence, which means a large AI queue is a tuning problem rather than a review problem. Treat it as one.
The two differ, sometimes by months. An alert dated 2026-06-30 on a transaction dated 2026-03-31 means a later scan caught something that earlier passes did not, usually because the baseline moved. Sorting by alert date surfaces what is new since your last review, which is the only part you have not already seen.
The alert row gives you enough to guess and not enough to conclude. Open the transaction. The same anomaly appears as a callout on the record itself, so whoever touches that bill next sees it too, whether or not they ever open the alert list.
Select **Dismiss**. Type a reason. The dialog also offers a helpful or not helpful rating.
Both fields are optional and the reason is the one that matters. Your five most recently dismissed AI alerts that carry a reason are fed into the hourly scoring pass as examples of what your organization treats as normal. A dismissal with an empty reason teaches the system nothing and occupies none of those five slots.
## Writing a dismissal reason that does something
The scorer reads your last five reasons as examples. Write them as if explaining the pattern to a new staff accountant, not as if closing a ticket.
Weak reasons and the versions worth writing instead:
| Instead of | Write |
| --------------- | ---------------------------------------------------------------------------- |
| Not a duplicate | Recurring monthly retainer, same amount every month by contract |
| Reviewed | Verified against signed change order, increase is expected through Q4 |
| OK | This vendor bills quarterly in one lump, so a 4x month is the normal cadence |
| Fine | Coded to 6410 deliberately, the standing account was retired in June |
Because it is a rolling window of five, the reasons you write this month are what steer next month's scoring. Five vague dismissals in a row flush your useful examples out entirely.
Name the pattern rather than the transaction. "IN-4471 is fine" describes one record and generalizes to nothing, while "this vendor bills quarterly in one lump" describes a shape the scorer can recognize on the next transaction that looks like it. Write for the reader who has never seen the record, because the scorer never has.
## Handling a queue too large to review
A queue in the thousands cannot be reviewed transaction by transaction and should not be bulk-dismissed blind. Bulk dismissal is available from the list, but a bulk dismissal with a single generic reason both hides the problem and poisons the five examples the scorer sees.
Do this instead:
1. Sample thirty alerts and identify the shared shape. Same vendor? Same amount? Same detector layer?
2. Fix the cause. Blank memos push duplicate detection into its weakest matching layer, so populating memos on the offending transaction type is often the entire fix.
3. Bulk dismiss the historical backlog with an accurate reason describing the pattern.
4. Watch the next scan. If volume returns, turn the detector off and replace it with a targeted [custom rule](./create-a-custom-detector).
Do this before close rather than during it. Step 4 takes a scan cycle to confirm, and a queue in the thousands is not something to work through under lock-day pressure.
## What clears itself
You do not need to dismiss everything by hand. When a transaction no longer meets the criteria, or the duplicates behind an alert are deleted or voided, the next scan dismisses the alert and records that it was dismissed automatically. Fixing the underlying record is usually faster than dismissing the alert about it.
A dismissal is also permanent by default. It is recorded on the alert, which stays in DualEntry as a dismissed record, and later scans skip the finding because that alert already exists, whichever detector or rule produced it.
This cuts both ways at close. A duplicate you resolve by voiding one of the two entries clears its own alert on the next scan, with no action from you. A duplicate you dismiss without touching the records stays dismissed even if the underlying problem is real, and nothing will surface it a second time. Dismiss when you have decided the transaction is correct, not when you intend to come back to it.
Restoring a dismissed alert clears its dismissal reason. The alert returns to the open list and no longer counts as one of the five examples the scorer sees. If you restore an alert you had dismissed with a good reason, that reason is gone and you will need to write it again on the next dismissal.
## Before you lock the period
The queue is not a gate on locking a period, so nothing stops you from closing over an open alert. Confirm three things yourself before you do:
* No open alerts on custom rules for the closing period. Rule alerts are unfiltered, so an open one is a condition you decided was worth reviewing and then did not review.
* Any alert you dismissed on a materially significant transaction carries a reason a reviewer could follow. Dismissals record who dismissed, when, and why, and that record is what an auditor reads. See [Audit trail and compliance](../platform-configuration/audit-trail-and-compliance).
* Nothing in the queue points at a transaction you are about to lock behind a closed period.
Anomaly alerts are not part of the close checklist and no status anywhere turns green when the queue is empty, so the record that you did this review is the dismissal history itself. That is the argument for writing reasons even on alerts you clear in seconds.
## Next steps
* [How to Set Up Anomaly Detection](./set-up-anomaly-detection)
* [How to Create a Custom Detector](./create-a-custom-detector)
* [Anomaly Detection: How Alerts Are Raised and Resolved](./anomaly-detection)