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.
- 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.
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.1
Open the alert list
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.
2
Work custom rules before AI detectors
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.
3
Sort by alert date, not transaction date
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.
4
Open the record before dismissing
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.
5
Dismiss with a reason
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:
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:- Sample thirty alerts and identify the shared shape. Same vendor? Same amount? Same detector layer?
- 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.
- Bulk dismiss the historical backlog with an accurate reason describing the pattern.
- Watch the next scan. If volume returns, turn the detector off and replace it with a targeted custom rule.
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.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.
- Nothing in the queue points at a transaction you are about to lock behind a closed period.