well_list_possible_double_debits

io.github.WellApp-ai/well-mcp · Verify this server

Find the pairs of outgoing bank movements that may be one charge taken twice, and say how many movements were scanned to find them. Use it for "was I charged twice?", "double debit", "prélevé deux fois" or "doublon de prélèvement" about a supplier. It reads the bank movements itself: do not scan `well_query_records` rows by eye to look for pairs. A PAIR is two outgoing debits of this workspace to the same creditor company, in the same currency, for the same amount, executed 7 days apart or fewer (counted by calendar day). Both debits must sit inside the window. Outgoing is read from the legs: the debtor leg is on an account of the workspace (any account that is not a counterparty's, so an account of unknown ownership counts), and the stored flow is empty or a supplier payment. A transfer to an account the workspace owns is not a payment to a supplier: it is not scanned and never paired. It does NOT answer which subscriptions a workspace pays or what each costs month by month (`well_measure_subscriptions`: cadence and price per supplier), a total or a spend per supplier (`well_sum_transactions`), or a list of payments to a named supplier (`well_query_records`). A same-amount pair inside 7 days belongs HERE whatever the supplier's cadence: a subscription charged twice in a week is a pair, and `recurring_hint` carries the overlap. `from` is inclusive and `to` is EXCLUSIVE, both optional. Omit both for the last 6 months, which is what "recently" means here. **A window is at most 13 months**: a longer one is refused with an error, never trimmed, so ask again with a shorter one. Only this workspace's own movements are read. **An open pair is an upper bound, never a verdict.** Two same-amount payments to one supplier within a week are a double debit or a legitimate pair (a split payment, two instalments, a weekly plan), and nothing here can tell which. Say "possible double debit" and "to check", and say what would settle it: the supplier's invoices for the two dates and the bank statement line. Never state that an open pair IS a double charge, and never offer a claim for one. **Every pair carries its class**, read from stored fields and never from a label: - `open_pair`: no stored verdict and no separate invoice behind each debit. This is the only class to raise as a possible double debit, "to check". `needs_review_reason` says why it is still open: `recurring_undecided` when `recurring_hint` is true, `no_invoice_evidence` otherwise. - `distinct_invoices`: each debit has its own confirmed invoice or its own document, and none is shared. Two invoices for two debits are not a double debit. Count it, do not raise it. - `imported_twice`: one debit stored twice by the bank import, not two charges. Count it, do not raise it. - `confirmed_distinct`: a person already confirmed these are two real payments, so it is never a possible double debit to check again. Count it. `distinct_invoice_links` says what the two payments rest on: `true` is two purchases, each with its own invoice or document, and nothing to raise; `false` means the two debits do not each have one, so a caller that looks for money to recover may raise the pair as a double charge confirmed as two separate payments, to take up with the supplier. The field does not say which of the two debits lacks its invoice. - `set_aside`: a movement of the pair was already dismissed as a duplicate. Count it, do not raise it again. A pair is tested against these in that stored-state order: `imported_twice`, then `confirmed_distinct`, then `set_aside`, then `distinct_invoices`, and `open_pair` is what none of them claims. `recurring_hint: true` means the same creditor, currency and amount also appears in at least 2 OTHER months of the window, so the pair may be a subscription charged twice or a plan with two instalments. The read excludes nothing for recurrence: a recurring pair is still returned as an `open_pair`, and you word the hint. `distinct_invoice_links` is true when each debit of the pair has a confirmed invoice edge or an attached document of its own and no invoice or document is shared by both. A provisional edge is not evidence of a payment. **Every pair is returned, so a group of n same-amount debits inside the window is n(n-1)/2 pairs**, not one entry per group. `dates` and `movement_ids` are in the same order, earlier day first. `amount.value` is the magnitude, whatever sign the bank feed stores. **Always state what was scanned, and never say "no double debit" without it.** `scanned_count` is every outgoing debit of the workspace in the window: the movements read. `eligible_count` is the part of it that could be paired, with a creditor company and an amount above zero that reads as a number. The rest is explained and adds up: `scanned_count = eligible_count + excluded_malformed + excluded_no_creditor_company`. `excluded_malformed` are debits whose amount could not be read as a number or is zero (a zero is never a double debit), and `excluded_no_creditor_company` are debits to a payee with no company on record (a person, a bare name), which no pair can be built on. Say so when either is above 0, and when `scanned_count` is 0 say nothing was read in the window. Debits an import stored twice are in `scanned_count`; this count is not the row count `well_query_records` reports, which leaves them out. `counts_by_class` counts EVERY pair found, exact. `pairs` is cut at 100 with the open pairs kept first: `truncated: true` means more pairs exist than the list shows, so state the open count from `counts_by_class` and say the list is partial. A window with no open pair is a statement about `counts_by_class.open_pair`, never about the length of a cut list. **`success: false` means the window is UNKNOWN, not clean.** The read failed, so `pairs`, the counts and `truncated` are absent rather than zero. Say the check could not be done; never report "no double debit" from a failed read. When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass `workspace_id` on the call.