Docs
Reading a finding
What every field on a finding means: exposure class, potential exposure, confidence and its reasons, what happened, calculation, formula, evidence, timeline.
The header: title, exposure class, money
Every finding opens with a title that names the entity and the disagreement: an order name, a SKU, a refund id or a fee id, and what does not agree with what. Below it are three money fields, and it matters which one is filled. potentialExposure is the amount the detector can calculate from the ledger but cannot prove is gone. verifiedLoss is filled only when the cash movement itself is the evidence, as with a fee that posted twice. recoveredValue is reserved for money confirmed back after a fix; none of today's detectors fills it, so expect it empty.
The exposure class tells you which of those to believe. potential_exposure means the number is arithmetic on real records, not a proven loss. likely_loss means a high-confidence operational failure, for example a SKU whose costs and fees exceed its price on every unit. verified_loss means cash-proven. unknown means the inputs to price the problem are missing, typically because no cost record exists for the SKU, and the finding shows no number rather than a guessed one. The workspace totals never add a verified loss into potential exposure, so the two headline figures do not double count.
Severity and confidence
Severity (info, low, medium, high, critical) comes from the absolute amount and the confidence together. Amounts of at least 1,000 in the reporting currency with confidence of 0.8 or more are critical; at least 400 with confidence 0.7 or more are high; at least 100 are medium; a zero amount is info unless the operational failure itself is judged medium. A high-impact operational failure, such as a shipment marked shipped with no tracking, can be high with no money attached at all.
Confidence is shown as a label (high, medium, low, unknown) and a percentage, with the thresholds 85, 60 and 30 percent. Open Why? to see confidenceReasons: short statements of what the detector relied on, such as which source is treated as the authority, whether the SKU mapping was exact, whether the observation falls inside the audit window, and whether an FX conversion was involved. If one of those reasons is wrong for your business, for example the warehouse count is not actually your authority, the finding is still arithmetically correct but you should weight it accordingly.
What happened, why, calculation, formula
What happened is the factual statement: which records were compared, their values, and the difference. It contains only numbers taken from your imported rows. Why we think this happened is the detector's hypothesis about the mechanism, written as the typical causes for that pattern (a dropped webhook, a partial capture, a return coded as unsellable). It is a prompt for where to look, not a conclusion.
Calculation shows the arithmetic with the actual values substituted, for example the unit difference multiplied by the contribution margin, or the refund amount plus stranded cost of goods. Formula, printed in monospace under it, is the same rule with field names instead of values, such as potential_exposure = abs(observed_available − expected_available) × contribution_margin_per_unit. If you want to reproduce a number in a spreadsheet, the formula is the specification and the calculation is the worked example.
Evidence and timeline
Evidence is the list of records the finding rests on. Each item has a kind: event (a row from your orders, payments, refunds, shipments or fees file), snapshot (an inventory count at a point in time), calculation (a value AXIOTRA derived, with the derivation in the detail) or formula (a per-unit economics breakdown). Each item names its source (shopify, amazon, stripe, warehouse, csv or axiotra), the external id you imported, the timestamp, and the value used. Any figure in the header can be traced to one of these items.
Timeline orders the relevant events by time, with source and detail on each point. The point drawn in red is the broken step: the moment the record diverged from what the other source expected, such as the storefront count that does not match the reconstructed available quantity, or the payment capture that never arrived. Reading the timeline top to bottom is the fastest way to see whether the disagreement started at import, at a webhook, or at a manual edit.
Recommended action, autopilot eligibility, locked findings
Recommended action is the next step an operator would take, and it always stops short of moving money: search the processor for the reference, locate the unit, open a fee dispute, hold fulfillment. Under it, autopilot eligibility says either eligible for recommend / retry or human approval required. Only small, reversible corrections qualify, such as an inventory difference of three units or fewer or a retried warehouse read; nothing that refunds, reprices or files a dispute is ever eligible, regardless of the autopilot mode you set.
Findings are sorted by potential exposure, largest first. On the free audit the first three are fully readable and the rest show their title with Unlock full analysis; an active paid plan unlocks every finding. Status starts at detected; the action buttons on the finding move it to investigating, confirmed, actioned, false_positive or verified as you work it, and you can attach notes. Marking a finding false positive removes it from the open count without deleting the evidence.