Skip to main content
All three AI detectors run by default in every organization on a plan that includes anomaly detection. There is nothing to turn on, and they have been flagging items whether or not anyone has looked. Run this review well before close so the queue you carry into day one is short enough to trust. For how the detectors decide what to flag, see Anomaly Detection: How Alerts Are Raised and Resolved.

​
Before you begin

Anomaly detection needs history before it produces anything useful. Check all three of these first. If any one is off, your queue comes back empty because of how the detectors are configured, not because your books are clean:
  • Your organization has at least 60 days of posted, non-migrated activity. Transactions loaded by the initial migration sync are excluded from detection, so a ledger that is entirely migration data produces no AI alerts.
  • Your vendors and customers have at least five transactions each inside the trailing 60 days. The amount and field detectors do not run below that.
  • Your role carries the transaction monitor edit permission. Viewing the alert queue and changing a detector are separate permissions, and both are configurable per organization, so check your role if you can read the queue but cannot switch a detector off. See User roles and permissions.
Baselines rebuild nightly at 02:00 UTC, so any scan before the next rebuild is still measuring against the old numbers. Change detector settings early enough that a rebuild runs before you need the queue, and read it after that rebuild rather than before.

​
Review the detectors

These four steps take you from opening the page to a decision on each detector: confirm what is running, give anything you reactivate a full cycle, then judge the queue it produces.
1

Open the Anomaly Detection page

From the sidebar, go to Home > Anomaly Detection. Each detector and each custom rule appears as its own card, showing whether it is active and how many open alerts it holds.
2

Confirm each detector is active

On a new organization all three read active and there is nothing to switch on. If someone turned one off earlier, open the three-dot menu on its card and select Reactivate. The same menu reads Deactivate while a detector is running. The menu appears only for roles that can edit detector settings.Each of the three AI detectors is a single on or off switch for the whole organization. There are no sensitivity presets and no per-company settings. A detector either runs everywhere or nowhere, which matters if you administer several entities with different transaction profiles.
3

Give a reactivated detector one full cycle

AI detection runs hourly on the hour. The scoring pass that reviews ambiguous findings runs at half past, so an alert raised at 02:00 is either promoted or left hidden by 02:30. If you reactivated anything, give it an hour rather than refreshing the page.
4

Read the first queue and decide

Open each detector’s alert list and sample twenty alerts. You are answering one question: would you have wanted to see this transaction? Use the outcomes below to decide what to do next.

​
Which detector to keep

All three detectors run from the start, so your only decision is whether any of them should be turned off. Judge each against how your books are actually kept. When to switch each detector off, and when to keep it: Deactivating a detector that still has open alerts prompts you for an optional reason and a helpful or not helpful rating. Fill both in. The reason is recorded against every alert the detector dismisses on its way out, and it is the only signal that reaches the team about why a detector did not work for your ledger.

​
If the first queue comes back empty

An empty queue is more often a data condition than a broken detector. Work through these in order:
  1. Confirm the detector card reads active rather than inactive.
  2. If you reactivated it, confirm at least one full hour has passed. AI detection runs at the top of the hour, so a detector switched on at 09:05 produces nothing until 10:00.
  3. Check whether your recent activity arrived through the migration sync. Migrated records are excluded permanently, not just on the first pass, so a ledger that is mostly migration data has little left to scan.
  4. Check a vendor you would expect to trigger something. If it has fewer than five transactions in the last 60 days, the amount and field detectors skipped it, and they will keep skipping it until that fifth transaction posts.
An empty queue after those four checks means the detectors ran and found nothing above the high-confidence threshold. Medium-confidence findings stay hidden unless the hourly scoring pass upgrades them, so a quiet queue is a normal result on a clean ledger rather than evidence that nothing is running.

​
If the first queue comes back enormous

A four-figure alert count on the AI Duplicate Detector usually means the near-match layer is pairing recurring transactions that share a vendor and an amount. Look at the memo similarity figure on the alerts. A queue where nearly every row reads 0% memo similarity is pairing on vendor and amount alone. Two responses, in order of preference:
  • Populate memos on the transaction types driving the volume. The exact and fuzzy layers both key on memo text, so blank memos push everything into the weakest layer.
  • Turn the detector off and write a custom rule that captures the specific duplicate risk you care about. See How to Create a Custom Detector.
Do not work down a four-figure queue by hand before close. Fix the input first.
Turning an AI detector off dismisses every open alert it raised. The reason and rating you supply in the dialog are recorded against those dismissals, and the alerts leave the open list along with their callouts on the underlying records. Reactivating the detector does not bring them back, though later scans can raise new alerts on transactions that still qualify.Custom rules behave differently: deactivating a rule asks whether to dismiss its open alerts or keep them.

​
Next steps

Last modified on August 18, 2026