DualEntry runs anomaly detection across the posted transactions in your ledger. Three AI detectors look for likely duplicates, amounts that are out of line for a vendor or customer, and account or classification choices that break a vendor’s usual pattern. You switch each detector on or off for your organization, add custom rules for the thresholds the detectors do not cover, and dismiss the alerts you have reviewed. Dismissing an alert does feed back into later scans, in two specific ways described in Reviewing and dismissing alerts.
What anomaly detection scans
Each anomaly detection run evaluates posted transactions against three built-in AI detectors. Account balances are not scanned on their own: every alert points at a transaction you can open.
- AI Duplicate Detector - flags likely duplicate transactions that carry the same absolute amount, matched in three layers. The exact layer requires the same date and an identical memo after normalization. The fuzzy and near layers allow three days on either side of the transaction date: fuzzy pairs on memo string similarity, and near pairs transactions whose memos differ when the vendor or customer is the same. String similarity is computed on the memo only, and the vendor or customer is compared by exact ID. Because no layer reaches beyond three days, a bill on a monthly or longer cycle is never paired with its own prior period.
- AI Amount Differences Detector - flags a vendor or customer transaction whose amount sits far above or below that entity’s recent history. The distance is measured as a z-score against stored statistics: the number of standard deviations between the amount and that entity’s mean. The amount must also be at least twice the entity’s mean in either direction, which keeps high-variance vendors from alerting on ordinary swings.
- AI Field Differences Detector - flags a transaction that hits an account or classification the vendor rarely uses, compared against the most frequent value in that vendor’s history.
When anomaly detection runs
Anomaly detection runs on a fixed schedule rather than on demand, and the three kinds of check run at different cadences. AI detection runs hourly at the top of the hour, and also runs on records as they arrive through an import. The scoring pass that reviews medium-confidence AI alerts runs hourly at half past the hour, after detection, so an ambiguous finding is scored within the same hour it was raised. Rule-based checks run on each transaction as it posts, plus a full pass daily at 00:00 UTC.
The baselines behind the amount and field detectors are stored statistics that refresh daily at 02:00 UTC over the trailing 60 days, so a rolling two months of history defines what counts as normal for each vendor, customer, and field. A transaction posted today is measured against statistics that can be up to a day old, which matters in practice only when a vendor’s recent activity has changed sharply. Transactions brought in by your initial migration sync are excluded from detection, so a migration does not produce a backlog of alerts on historical activity.
How anomaly confidence levels work
Every AI alert carries a confidence level, and only high-confidence alerts are visible to you. The detector sets that level from how far a transaction sits from its baseline: a z-score above 3.0 on the amount detector, or a usual-pattern frequency of 95% or more on the field detector, produces a high-confidence alert immediately.
The amount and field detectors also require at least five transactions in an entity’s stored statistics before they run at all. Below five there is no baseline to measure against, so a brand new vendor produces no alerts until it has five transactions inside the trailing 60-day window.
Anything in the ambiguous band becomes a medium-confidence alert, which stays hidden and is queued for a second pass. That pass runs hourly at half past the hour, after detection. An LLM scores each queued alert from 0.0 to 1.0 using the memo, entity, amount, currency, date, and the statistics behind the finding. A score of 0.7 or higher upgrades the alert to high confidence, and it becomes visible in the alert list. A lower score leaves the alert hidden, neither shown to you nor dismissed.
Rule alerts work differently. A custom rule has no confidence score and no scoring pass: if a transaction matches the rule conditions, the alert is raised and visible.
How to tune what anomaly detection flags
You have two controls over what anomaly detection flags: an on or off switch per AI detector, and custom rules that you write yourself. Both live on the Anomaly Detection page under Home, where each detector and rule has a card showing whether it is active and how many open alerts it has. Each of the three AI detectors is a single on or off switch that applies to your whole organization, and all three are on by default. There are no sensitivity presets and no per-company detector settings: a detector either runs for every company in the organization or does not run at all. Deactivating an AI detector that still has open alerts prompts you for an optional reason and an optional helpful or not helpful rating, then dismisses those alerts against the reason you gave. Deactivating a custom rule instead asks whether to dismiss its open alerts or leave them in the list.
Custom rules are where you set your own thresholds. A rule is built from condition groups, and a condition compares one field against a value. Conditions within a group always combine with AND. Groups combine with OR, so a transaction matches when it satisfies every condition in any one group.
The operators are is, is not, greater than, less than, greater than or equal to, less than or equal to, contains, does not contain, starts with, and ends with. Each field accepts only some of them. Amount takes the four comparisons, memo takes the four string operators, and every other field takes is and is not. See How to Create a Custom Detector for the operator restrictions field by field.
The fields a condition can test are memo, amount, posting date, transaction date, creation date, transaction type, customer, vendor, company, record status, account, account type, classification, and item. A rule that tests amount greater than 50000, for example, flags any transaction above that figure. Rules created on the Anomaly Detection page apply to the whole organization; to watch a single entity, add a company condition to the rule. Rule-based checks run on each transaction as it posts, plus a full pass daily at 00:00 UTC.
Where anomaly alerts appear
Anomaly alerts reach you in two places, both inside the product.
- Anomaly Detection page - the alert list, reachable from Home in the sidebar. It carries a card per detector and per rule with open alert counts, and you filter and sort the list from there.
- Record callouts - a callout on the record itself when you open a flagged transaction. These appear on bills, direct expenses, vendor payments, vendor credits, refunds, prepayments, and fixed asset records, among other transaction types. Note that the AI detectors only run on vendor- and customer-related transactions, so records outside that scope (fixed assets, for example) show callouts only for custom rule alerts.
Each alert shows the flagged record, the detector or rule that raised it, the explanation of why it fired, and a link into the source transaction. Because a callout renders on the record, an anomaly on a bill is visible to whoever opens that bill next, whether or not they ever open the alert list.
Anomaly alerts do not currently have an email digest, a home dashboard widget, or an automatic entry on the month-end close checklist. The alert list is where you work through them, and open alerts stay there until someone dismisses them or a later scan resolves them.
Reviewing and dismissing alerts
When you open an alert you either leave it open or dismiss it. Dismissing an alert records who dismissed it, when, and the reason you type, and removes the alert from the open list. The dialog also offers a helpful or not helpful rating. Both the reason and the rating are optional, and the reason is what later scans read, so a dismissal with no reason at all teaches the system nothing. Marking an alert not helpful always stores a reason, even when you leave the text box empty.
Two things follow from a dismissal:
- A dismissed alert stays dismissed. The dismissal is recorded on the alert, which remains in DualEntry as a dismissed record. Later scans skip the finding rather than raising a second alert for it, whichever detector or rule produced it.
- Your five most recent reasons steer the scorer. The five most recently dismissed AI alerts that carry a reason are passed into the hourly scoring prompt as examples of what your organization treats as normal. This affects whether new medium-confidence alerts get upgraded and shown. This is a rolling window of five examples, not a retrained model, and it applies to AI alerts only.
You can dismiss alerts one at a time or in bulk from the list, and you can restore a dismissed alert. Alerts also resolve themselves: 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.
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.
