Acumatica AI Anomaly Detection helps finance teams find unusual numeric values in a configured Generic Inquiry (GI), such as unexpected costs on accounts payable lines, unusual released journal entries, or a change in account turnover. In Acumatica ERP 2026 R2, choose the inquiry and the amount to analyze, define a meaningful time field and comparison group, then review the results against the original documents. Treat the severity as a way to prioritize the review. A significant exception can be a valid transaction, and an ordinary value can still be wrong. Use Acumatica’s approved accounting workflow for any correction, and keep the evidence and decision tied to the original record. Start with one inquiry, a named reviewer, and a repeatable close checklist before adding alerts or expanding to other companies.
The practical challenge is what happens between the flag and the decision. A $48,000 bill may be legitimate for one supplier and surprising for another. A batch posted near period end may be large because it represents an approved annual adjustment. This guide explains how to select a financial inquiry, prove that it compares like records, and turn exceptions into a queue the controller can actually clear. It uses the current Acumatica anomaly detection documentation for product behavior and labels the suggested procedures, thresholds, and examples as implementation choices.
What Acumatica AI Anomaly Detection measures
Anomaly Detection looks for unusual values in a numeric column of a configured Generic Inquiry. A GI is a data view that specifies which ERP records and fields the user sees. Acumatica describes the detector as using unsupervised machine learning through a cloud service. You select a numeric field, a date or date-and-time field for the timeline, and, where useful, fields that divide records into more comparable groups. The documented results classify processed values as Normal, Medium, or Significant. The comparison is shaped by the inquiry and the data available to it. See Acumatica’s explanation of Generic Inquiries and anomaly detection.
A result is a statistical signal about the value and its context. It does not establish whether a purchase was authorized, whether the expense belongs in the right period, or whether a document is genuine. The inquiry may not include evidence such as a signed contract, an approval, or an explanation from the business owner. Conversely, a duplicate payment of an ordinary amount might look statistically normal. Keep controls for duplicate invoices, vendor master changes, payment approvals, and reconciliations in place. Use the detector to decide where to look first within the defined population.
For each inquiry, write a one-sentence statement that a reviewer can read without knowing the model: “This queue shows AP lines whose extended cost differs from the pattern among comparable lines for this vendor.” Document what the queue leaves out, such as invoices outside a selected company or dates before a conversion. The sentence also gives IT a test: if the configured filters, amount, date, or group do not support the sentence, fix the inquiry before asking finance to act on its output.
Which Acumatica version and feature to use
This workflow is based on the 2026 R2 help. The release materials discuss AI Assistant, AI Automation, and AI Anomaly Detection together, but they have distinct jobs. Anomaly Detection surfaces unusual numerical values from a GI; the fact that an inquiry can be used by AI Assistant does not enable its anomaly detection. Acumatica documents different controls in the Generic Inquiry form reference, including Detect Anomalies and Expose to AI Assistant. Enable and govern only the capability needed for the review. A financial exception queue does not require publishing the GI to an external AI client.
Older instructions may refer to the separate GL Anomaly Detection service, Analyze Accounting Transactions (GL510000), and Review Anomaly Predictions (GL406000). The versioned 2024 R2 GL guide describes that earlier workflow. Acumatica’s Anomaly Detection FAQ announced the rename and consolidation starting with 2026 R1. Use the documentation that matches the installed build. This guide uses the GI workflow documented for 2026 R2, including the Detect Anomalies in Generic Inquiries form (ML502000). Do not translate old scores, training instructions, or action names directly into the new queue.
Before copying a setup, have an administrator confirm the build, installed features, license entitlement, company scope, and whether the intended GI exists. Open the actual inquiry and verify its default settings rather than assuming they match a training tenant. For an upgrade, capture the old review population, key filters, reviewer assignments, and open cases first. Then verify how each responsibility and case will carry forward; the screen change is the easy part, while preserving the meaning and ownership of the queue takes work.
Choose a first finance exception worth reviewing
Choose a first use case where the underlying document is available, the expected action is clear, and the reviewer can explain why the alert mattered. AP costs are a good starting point when staff can open the bill, match it to a purchase order or receiving record where relevant, and contact a buyer about a price or quantity discrepancy. Journal entry review is a reasonable alternative when the controller wants to prioritize unexpected postings within a defined group of accounts. Account turnover is useful when the decision is about a change at period level and the reviewer can drill from the aggregate to the entries behind it.
Write down the consequence of finding the exception. For example, “If the amount on the bill line disagrees with authorized pricing, AP investigates before the payment decision using the existing process.” That wording does not assume that all detected documents are unreleased or that the detector can stop a payment. If the source population already consists of released records, the action is to investigate the posted amount and use the appropriate correction process. An alert that arrives after the relevant cutoff may still help with close or process improvement, but it cannot be counted as a preventive check.
Begin with a department, branch, or document population whose owner understands the historical changes. Avoid choosing a use case mainly because the dataset is large or has a dramatic chart. If reviewers cannot see the source or lack authority to resolve the cause, narrow the scope. Establish a baseline of how the team currently finds the problem: which report is used, how often, roughly how much time it takes, and where issues are recorded. That makes the pilot measurable without inventing an improvement claim.
Select a predefined inquiry or design a focused one
Acumatica’s 2026 R2 anomaly detection guide describes predefined inquiries for Journal Entries Analysis (GL3010ML), Costs in AP Documents (AP3010ML), and other operational areas. Journal Entries Analysis can help a controller inspect unusual released journal transactions in the actual ledger. AP cost analysis can help compare relevant line amounts and inspect invoices. Account turnover analysis supports a separate question about activity summarized by period. A transaction outlier and a turnover outlier can point to different causes, even in the same account.
Review the inquiry’s grain before you enable it. Grain means what one row represents: a bill line, a journal transaction, or an account and period. A join to receiving or approval history can produce more than one row per bill line. That can duplicate amounts and change the apparent population. Verify the stable document and line identifiers, then test a few known records against the source forms. The Biz-Tech guide to Generic Inquiry performance and design explains why joins, filters, and grouped results deserve separate checks.
If you need a new inquiry, start with a small definition: identity, relevant date, amount, currency or consistent base amount where appropriate, group keys, and a drill path to the source. Add columns only when they help the model or reviewer. A heavy review view full of attachments or confidential notes may expose more data than needed and make the queue harder to use. For an existing GI used by other teams, evaluate whether a separate finance-specific view gives cleaner scope and accountability. Assign an owner for the definition and record which version of it was used during the pilot.
Define the amount and timeline before setting groups
An amount column needs a business definition. A unit cost can be reasonable when the question is whether the price changed; an extended line cost can be appropriate when the concern is the total line impact. The same purchase can look routine on one measure and unusual on the other. A bulk order at the approved unit price can produce a large line total without an error. A high unit price on a small purchase can matter as a process signal even if the total exposure is small. Record which case the inquiry should reveal, and keep a second measure visible for the reviewer if it helps explain the flag.
Avoid mixing numbers with different meanings. If a local currency amount, base currency amount, and tax-inclusive total are all available, pick one that answers the decision and verify how it reconciles. If currency is relevant to the business question, compare compatible units or define distinct groups deliberately. Check credits, reversals, zero amounts, landed costs, and recurring adjustments before treating them as part of the same population. Excluding them may be sensible for one inquiry and inappropriate for another; document the reason and where excluded cases are reviewed.
Choose the time field with the same care. Invoice date, receipt date, posting date, and financial period are different concepts. For posted journals, the date and period scope should support the controller’s close review. For AP pricing, use the timeline that reflects the vendor’s commercial behavior and make any late entry pattern visible. Test boundary records around month end and fiscal year end. A date mismatch can produce a queue that looks consistent to IT while giving finance a misleading view of when the activity occurred.
Group records that are comparable in business terms
Grouping is a choice about what behavior should be compared. The Acumatica process activity uses an AP cost example with extended cost as the numeric field, date as the timeline, and Vendor ID as a group. This is a documented training configuration, not a rule that every AP team should copy. A supplier that sells both commodity consumables and specialized machinery may need a narrower item or document population. A supplier with only a few lines in the history may not offer enough comparable activity to support a confident business interpretation.
Start with the grouping dimension that most strongly explains how the value behaves. For AP that might be vendor or item family; for journals it might be branch and account, with subaccount where relevant. Compare a broad and narrower design in a pilot only if each has a clear business meaning. Too broad a group may mix unrelated processes. Too narrow a group may leave thin groups and many skipped or difficult-to-interpret rows. The goal is not to find the grouping that produces the smallest number of alerts; it is to create an explainable comparison with acceptable coverage.
Inspect a handful of groups directly. Identify which groups reflect a seasonal buying pattern, a recent acquisition, an account restructuring, or an unusually long gap in activity. Check whether an empty group key has a legitimate meaning or is a data defect. If the inquiry uses Skip Empty Groups, confirm what it omits for your data and route important omitted cases to a separate control. Record sample periods and counts so the review can be repeated when data or grouping changes.
Confirm licensing scope access and cloud processing
Before a live run, verify the Anomaly Detection feature in Enable/Disable Features (CS100000), the account’s entitlement, and which inquiries are enabled. Acumatica’s 2026 R2 Generic Inquiry reference notes that the number of enabled inquiries is license limited and points to the License Monitoring Console (SM604000) for constraints. The ML502000 form reference also documents a daily processing limit measured in UTC. Confirm the tenant’s current limits and applicable terms rather than treating a public training example as a quote or entitlement. Separate the inquiry limit from any AI Assistant consumption question.
The detection process sends selected inquiry data to Acumatica’s cloud service for calculation. Check the installed release’s documentation and commercial terms, review the intended data fields with the responsible owner, and remove unnecessary personal or sensitive values from the population. Have an administrator test what users in the actual reviewer role can open, including source document navigation. A useful finance reviewer can see what the job requires, but a recipient who only needs an exception count should not receive all invoice detail in a notification.
Separate configuration authority from disposition authority where the organization’s controls call for it. The GI administrator can manage the inquiry and processing; the finance lead owns the review policy; an authorized accounting user approves or performs any correction through existing controls. Test access with a permitted reviewer and an account that should not see the data. The Biz-Tech AI Assistant governance guide gives related guidance on source inquiry scope and role tests; these are useful review practices even when the inquiry is never exposed to an assistant.
Configure one inquiry and run it on demand
In a permitted environment, open Generic Inquiry (SM208000) and confirm that the intended GI matches the approved population. The form reference describes selecting Detect Anomalies on the Advanced tab so the Anomaly Detection settings become available. Choose the approved numeric field and timeline, and set grouping where justified. Start with On Demand to review the population and output before deciding on cadence. Keep a record of the inquiry name, filters, field choices, group keys, and environment. There is no benefit in configuring several inquiries before finance confirms that the first one answers its question.
Open Detect Anomalies in Generic Inquiries (ML502000). Acumatica’s AP process walkthrough documents the manual sequence: process the selection to upload data, initiate calculation, and retrieve the results when ready. Use the status and last imported time to confirm that the results actually made it into Acumatica. The process can take time depending on the dataset. Treat a visible screen or an uploaded status as an intermediate result, not as evidence that the queue reflects the latest data.
After the run completes, compare the results to the expected coverage. Look at the status and available counts for uploaded and skipped rows and groups. Investigate anything unexpected: a change in row count, a group that did not process, a failed run, or a long gap between upload and import. If a filter or selected field was wrong, document the problem and correct the inquiry before interpreting outputs. When changing anomaly settings, follow the product guidance about recalculation and historical results; retain the evidence you are authorized to keep before making a change that affects previous calculations.
Read the results and separate review priority from policy
Open the processed inquiry and look for the Anomaly Severity, Expected Value, Comment, and Reviewed fields described in the Acumatica general information and process activity. Compare the observed value with the reported expected value when it is available. A model expectation is not the approved purchase price, a policy limit, or a calculation of loss. Use it to form a question for the reviewer, then use the original business documents to answer it. The product also distinguishes rows that have not been processed; do not include them in the Normal bucket or assume that a blank value indicates safety.
A shared filter for Medium and Significant anomalies gives the team a repeatable queue. Keep enough fields visible to orient a reviewer: record identity, amount, date, company or branch, comparison group, and status. Decide how work is ordered. One reasonable policy is to review significant exceptions with potential payment or close impact first, followed by remaining significant exceptions and a defined subset of medium exceptions. Finance may elevate a medium case if timing or amount matters. The threshold for escalation is a company decision, separate from the model’s severity.
Reviewers should be able to see why an item was prioritized. For example, “close tomorrow, significant, vendor new to the branch” is more actionable than “red row.” Keep a count of unprocessed items and stale runs beside the open alert count. An empty or smaller queue has limited meaning without knowing which rows were covered and when. If the expected comparison is unavailable or clearly unsuitable, record the limitation and route the case using the normal review control rather than guessing the missing value.
Work an AP cost exception from flag to decision
Consider an illustrative AP bill line flagged at $48,000 where the model’s expected value is $12,000 for comparable activity. The observed amount is four times the expectation; the difference is $36,000. This math helps rank the item. It does not establish an overcharge. The source documents may show a quarterly order that contains four times the usual quantity at the same authorized unit price. They could instead show a duplicated line or a unit-of-measure conversion problem. The same statistical result points to different actions depending on evidence.
The reviewer opens the bill and checks the vendor, currency, item, quantity, units of measure, unit price, and extension. Where the business has a purchase order and receipt, compare those records to the bill. Check any approved change order or supplier quote and whether the amount includes an unexpected freight or tax component. Look for duplicate invoice numbers or repeated lines using the established AP checks. Ask the buyer or operational owner about scope if the documentation does not explain the change. Note when supporting records are missing rather than accepting a verbal assurance as final evidence.
If the amount is correct, close the review as an explained exception, with a short note and reference to the approved source. If the invoice or posting needs correction, send it to the authorized owner and use the normal AP or GL procedure appropriate to its state. If facts are incomplete and payment could be affected, escalate through the established payment review. Record the original record, review decision, evidence, and any resulting correction reference. The alert remains a useful trail even when it turns out to be a valid order.
Investigate a journal or turnover exception
For a journal item, begin with the original entry, batch, ledger, branch, accounts, and period. Review the offsetting entries and trace back to the document or approved manual adjustment that created the posting. The 2026 R2 GL transactions guide describes how Acumatica groups journal entries into batches and how documents can generate transactions on release. That relationship matters: a single flagged line is only one part of the accounting event. A large debit might be expected if a matching credit and an approved schedule establish the purpose of the batch.
Turnover is different. An unusual period may reflect many ordinary postings that add up to a large change, or one unusually large journal that dominates the total. As an example, suppose account activity for one branch rises from roughly $80,000 to $230,000 in a period. First reconcile the aggregate to the ledger for the same company, branch, account, currency, and period. Then separate recurring activity, reversals, reclassifications, and one-time adjustments. If $145,000 is an approved annual accrual and the remainder follows normal activity, the reviewer can explain the period change with a documented source. If no approved schedule or support exists, route it for review before treating the account movement as explained.
The current anomaly detection guide warns that some turnover groups shown in the historical period may not have valid results when they lack recent activity. That is a reason to inspect group coverage and context, especially for dormant or reactivated accounts. Keep the transaction-level and period-level results distinguishable. If a period outlier leads to a transaction already logged in another queue, link the related cases rather than treating them as two independent errors.
Record decisions the next reviewer can reproduce
A review record should explain why the team reached a decision and who is responsible for the next step. At a minimum, retain the inquiry and run date, company or branch, source key, severity and expected value if shown, actual amount and units, decision, evidence reference, reviewer, and the next owner or due time if open. If a later correction is approved, record its reference and reconciliation result. The details can live in an approved case log linked to Acumatica; do not assume a product comment field alone meets every organization’s retention or audit requirements.
Use plain status names and a defined meaning for each. “Open” means a reviewer has not reached a disposition. “Explained” means the transaction was unusual but supporting evidence matched its treatment. “Correction required” means the reviewer found a supported discrepancy and has routed it to an authorized owner. “Pending evidence” means the available sources are insufficient. “Outside scope” means the exception came from a population the review policy did not intend to cover. These are suggested team statuses, not claims about native Acumatica fields. An organization may keep fewer statuses if the responsibilities are still clear.
Write a note that a second reviewer could follow. For example: “Extended cost is $48,000 because the approved quarterly order has 400 units at $120. PO and receipt agree; line is valid. Reviewed 6 Nov.” For an unresolved item: “Invoice uses case quantity while receipt is recorded in pieces; buyer to confirm conversion and attach support before payment review.” An uninformative “OK” or “AI false positive” leaves little useful evidence. Mark an item reviewed according to the team’s policy only after the relevant check is complete, and keep any still-open accounting task visible.
Separate operational review from accounting correction
An anomaly queue is a review control. It should not directly reclassify an entry, release a bill, change bank details, or approve a payment. Determine the current state of the source before selecting a correction: a document still under preparation, a released AP document, and a posted GL entry can require different steps. Follow the organization’s existing approval and correction policies and the version-specific product documentation. If an entry can be corrected through reclassification, retain the original and correcting references; the Acumatica reclassification reports and inquiries guide explains how to trace reclassified transactions where that workflow applies.
Keep the people and approvals appropriate to the risk. An analyst can collect evidence and recommend a disposition. An authorized accountant or manager should make or approve the accounting action under existing rules. A suspected fraud or vendor identity concern belongs in the organization’s escalation process with restricted access and no unnecessary external disclosure. Even a high model severity cannot substitute for a source reconciliation or justify attributing intent.
Confirm resolution separately from the original flag. For a correction, verify that the source and ledger now reflect the approved outcome, the period treatment is appropriate, and any relevant downstream report or payment workflow has been reconciled. If the issue was caused by an inquiry join or currency mismatch, document that as a data design defect and retest the inquiry; do not correct the source accounting simply to make the model output look normal. This separation makes the investigation useful for both control improvement and financial reporting.
Design alerts and cadence around real work
Set the cadence according to the operational decision. An AP lead may review after a weekly vendor cost run or ahead of selected payment cycles. A controller may schedule journal analysis around close checkpoints and include a final freshness check before signing off. Acumatica documents on-demand and scheduled anomaly calculation and the ability to use results in dashboards and business events in the 2026 R2 anomaly detection guide. Confirm what cadence options and schedule behavior are available for the installed build and inquiry.
Use alerts to route work rather than simply increasing notification volume. Decide what causes a notification, who receives it, where to open the queue, and how the recipient acknowledges it. An initial business event could notify the finance queue owner of a new high-priority case, with a minimal identifier and link to the approved work surface. Acumatica describes task and notification options in its Generic Inquiries and business events overview. Test alert routing in the approved environment, including the case where the recipient has no permission to open the underlying inquiry.
Account for repeats. A record may still be present after an additional run; one open investigation does not necessarily deserve another message at every refresh. Decide what counts as a new case, when to reopen an existing one, and when to notify a backup. Include a distinct notification path for a calculation error or stale queue. If the data is late, a notification saying “zero exceptions” can mislead finance more than a visible service failure. Use a count widget only with a last successful run and a clear link to the filtered details.
Make the exception review part of the close
Give the close team a specific control step: “Review eligible AP cost and released journal anomalies for the covered period; record unresolved items and escalate based on impact.” Document which entity, branch, and period are covered, the time at which source data is cut off, and who owns the work when the regular reviewer is absent. Set a deadline that leaves room to investigate before the controller’s final review. A queue that runs after the cutoff may inform a subsequent review, but it cannot support a claim that the control ran before close.
At the start of the review, confirm the last imported result and compare its data window to the period under review. Check any late postings or changed scope. Sample a few known records that should be present, especially late transactions or new branches. Use the inquiry to prioritize follow-up while retaining normal reconciliations and ledger reviews. When an exception cannot be resolved by the cutoff, communicate its potential effect, evidence still needed, owner, and decision deadline. Escalation does not require an automatic reopening or adjustment; it gives the controller the information needed to decide through the normal policy.
At the end of the review, capture counts of opened, resolved, and still-open cases alongside run coverage. Describe whether the review included just a cutoff snapshot or any subsequent run. Link the supporting documents and resulting approvals, using the organization’s access and retention practices. In the next period, revisit carryover items. A close review should be reproducible without rerunning the model on changed data, which could return a different set of comparisons.
Measure coverage usefulness and reviewer workload
Use a few measures that answer distinct questions. Run freshness tells you when results last reached the ERP. Processing coverage compares eligible and processed records using the same population definition. Review completion shows which prioritized items got a disposition. The share of reviewed items with a supported correction or actionable process issue tells you whether the queue is helping reviewers find work that matters. These numbers answer different questions, and none alone is the detector’s accuracy.
For an illustrative pilot, assume the approved GI has 1,000 eligible lines, 960 of which are processed, and the team reviews 30 flagged lines. Eight reviewed lines have a documented correction or process issue, 18 are explained, and four need more evidence. That produces 96% processing coverage and an actionable share of 8 of 30 reviewed flags so far. It does not establish recall or what happened in the 40 unprocessed lines. A sample of normal and skipped rows can reveal missed issues or poor coverage, but only a valid labeled evaluation could support broader performance claims. Record the sample and its limitations before comparing periods.
Track reviewer effort and aging in business terms. If the same person investigates two related alerts, count the work once if the outcome is one case. Separate the time to review a flag from the time to get a supplier response or complete a correction. Set pilot thresholds in advance: for example, acceptable run freshness and a maximum number of overdue high-priority cases. If the queue becomes too large, narrow to a clear finance question or refine the comparison group; if it becomes too quiet, look for scope changes and sample records the model did not flag.
Diagnose common reasons a queue gives poor results
If results look stale, start with the last successful import and compare it with the expected schedule and dataset window. Check ML502000 for a stopped or failed processing step and distinguish cloud upload from completed import. A run may cover only the conditions currently defined for the GI. If the result changes dramatically after a GI update, compare the old and new grain, date field, measure, join filters, and group keys. The Generic Inquiry form reference describes how changing anomaly settings can require recalculation and how changing the analyzed field affects earlier results.
If a new group generates too many flags or is skipped, inspect whether it has a coherent history and a valid group key. Check for migration dates, old document types, blanks, and changed currency or unit conventions. If unusual records all share a branch, ask whether a legitimate operational event or data migration changed the comparison. Inspect a known source document before adjusting the model’s input. If the issue is data quality, the remediation belongs in the source process or inquiry design, depending on where the inconsistency originated.
If the queue mostly repeats known, approved activity, the severity may still be behaving consistently. Find whether an expected seasonal or one-time event should be interpreted differently or handled in a separate cohort. Do not hide relevant cases merely because the team knows they are common. Establish an evidence-backed disposition rule and revisit it periodically. Treat changes to filtering, grouping, or schedules as review design changes: record the rationale, compare old and new coverage, and obtain signoff before relying on the changed queue for close.
Roll out one review path before scaling
During the first week, pick a case and agree on the action you expect when finance finds an issue. Confirm the dataset, build, license, access, source forms, and designated reviewer. Define the measure and run an initial sample. Collect known expected transactions and known errors where such examples are available and appropriate to use. If there are no labeled examples, do not invent them as evidence; make synthetic cases in a non-production dataset or document the limits of the pilot.
In the second week, compare one run with the existing review procedure. Record when each case was identified, which source evidence changed the decision, and what the reviewer would do next. Keep the existing control in effect. In the third week, tune only the settings tied to documented misses, excess duplicate work, coverage gaps, or changing business groups. Test permissions and evaluate a lightweight shared filter or dashboard before adding broad notifications. Consider whether the team can support the queue at peak close load.
In the fourth week, review whether the process consistently produces reviewable exceptions. Ask whether reviewers can reproduce dispositions, whether the run is fresh when decisions are made, whether excluded and unprocessed cases have another control, and whether high-priority items have a clear owner. Decide to continue, revise, or stop. Add a second inquiry only once the first one has a repeatable owner, evidence trail, and fallback. For design support, Biz-Tech Services can help review the inquiry population, the role and reporting setup, and the rollout plan. Biz-Tech AI Analyst is a separate tool for approved report and GI design; it is not the anomaly detection engine described here.
Run a dry review before turning on alerts
Use a short dry review to test whether someone who did not build the inquiry can work it independently. Give an authorized reviewer the inquiry name, the stated business question, and the current cutoff. Ask them to open a known approved outlier, a known discrepancy if one can be shared, and a normal or unprocessed line. Have them explain which source fields they compared, which action they would take, and where they would record it. Observe the time spent navigating, waiting for access, or looking for missing evidence. A detector that flags a useful item but leaves its reviewer unable to open the bill or identify the period still has an operational gap.
Check two different failures explicitly. First, simulate a stale result by using a dry-run example where a known eligible document is newer than the last imported data. The reviewer should notice that the run is stale and use the established manual review while the owner investigates. Second, choose a valid case with a surprisingly high value and enough evidence to explain it. The reviewer should be able to close the case without making an accounting change. These exercises validate the response, not the underlying algorithm.
Before adding a notification, confirm who covers the queue during close, which information can be included in a message, and who can make any resulting accounting decision. Keep a sample disposition and a one-paragraph fallback procedure with the inquiry documentation. The fallback should name the report or source view, identify the population, and explain how to log unresolved cases while processing is unavailable. Use those records at the first live review to spot where the workflow differs from the dry run.
What to do next
Begin with one well-understood AP cost or journal question. Make the data definition visible to the reviewer, then run the first calculation on demand. Compare several flagged rows and several unflagged or skipped rows with the original records. Document what the comparison can and cannot tell you. If reviewers can explain the flags and consistently resolve or route the cases, add a schedule with a named owner, an escalation path, and a freshness check. That gives finance a review procedure it can improve over time and keeps accounting decisions in the controls the company already uses.
Frequently Asked Questions
Does Acumatica AI Anomaly Detection prove a financial error
No. It identifies unusual values for the configured inquiry. Review the source document, approvals, timing, and context before deciding whether an error exists. Keep separate controls for risks that do not necessarily change a numeric pattern.
Is Anomaly Detection the same as AI Assistant
No. The 2026 R2 GI form has separate settings for detecting anomalies and exposing an inquiry to AI Assistant. Enable the feature needed for the task and confirm the scope of any additional AI access.
Can it review accounts payable costs
Yes, where the feature is licensed and configured. The 2026 R2 documentation describes Costs in AP Documents (AP3010ML) and a walkthrough using extended cost, date, and vendor grouping. Confirm that these choices fit your own AP population and controls.
Which screen runs anomaly detection
The current GI workflow uses Detect Anomalies in Generic Inquiries (ML502000) after configuration on Generic Inquiry (SM208000). Older GL-specific instructions use different screens. Match the steps to the installed release.
What does the expected value mean
It is a result of the model’s comparison for that configured inquiry. It can help explain the size of a deviation. It is not the amount authorized by the purchase order, the correct accounting amount, or an estimate of confirmed loss.
Why did an inquiry skip some rows
Check the run status and the uploaded and skipped counts in ML502000. Investigate the relevant data fields, filters, group keys, and history. Check which items are eligible or in scope before concluding they were missed by the model.
Can I run the review on a schedule
Acumatica documents scheduled and on-demand processing. Start on demand, confirm that results return and are useful, and then select a cadence aligned to payment or close decisions. The model run and the human review both need an owner.
What happens after a reviewer finds a real discrepancy
Record the facts and route the case to the authorized owner. Use the accounting correction or approval process that applies to the source document and its current state. Verify the resolution and link it to the case.
Can a dashboard replace the close checklist
A dashboard can surface counts and lead reviewers to the queue. The close checklist should also cover freshness, scope, unresolved cases, source reconciliation, and signoff. An empty widget alone does not establish that the review was performed.
Do I need a license and can I use any data
Confirm the applicable entitlement, enabled inquiry count, processing constraints, and data handling terms with your administrator or Acumatica partner. Select only the data needed for the business question and test what reviewers can access.
Sources
- Acumatica Cloud ERP 2026 R2 release overview
- Acumatica 2026 R2 Anomaly Detection general information
- Acumatica 2026 R2 AP anomaly detection process activity
- Acumatica Generic Inquiry form reference SM208000
- Acumatica Detect Anomalies in Generic Inquiries form reference ML502000
- Acumatica Generic Inquiries reporting and analytics overview
- Acumatica Community FAQ on anomaly detection and the 2026 R1 transition
- Acumatica 2024 R2 legacy GL Anomaly Detection guide
- Acumatica 2026 R2 GL transactions guide
- Acumatica 2026 R2 reclassification related reports and inquiries
