Qonto Counterparty Watch

Know who owes you, who's slipping, and who's legally sinking — before it costs you the invoice. 100 % read-only: the skill observes and alerts; it never writes anything anywhere.

Prerequisites

1. get_organization → accounts, bank_account_id/IBAN (required by list_transactions), legal country. Nothing hardcoded: the skill adapts to whatever organization it finds.
2. Country-aware: legal-health enrichment relies on French public registries (SIRENE, BODACC). For other Qonto countries (DE, ES, IT, AT, NL, BE, PT…), say so plainly and degrade to the Qonto-pure core — exposure ranking + payment-delay scoring work everywhere; never pretend to check a registry that wasn't checked.
3. Optional enrichment — detect, don't assume: use the declared Datagouv tools (search_datasets, query_resource_data) only when available. Do not probe MCP availability through filesystem or native tools. Present → offer legal-health checks and explain that they send SIRENs or exact legal names from Qonto to Datagouv; activate only after the user explicitly confirms. Absent or declined → announce it once ("legal-health checks unavailable, delivering Qonto-only scoring") and continue. The core must never depend on it.

Workflow

1. Build the counterparty inventory

• Clients: list_clients (paginate per_page: "50") → legal name, tax_identification_number when present. Extract the SIREN: a French VAT number is FR + 2 keys + 9-digit SIREN; keep the 9 digits. get_client for details on demand.
• Suppliers: list_supplier_invoices (supplier names, amounts, statuses) + list_transactions per account (12–24 months, 3-month windows, per_page: "50") → recurring debits grouped by normalized counterparty.
• Name normalization (bank labels are messy): uppercase, strip SEPA/transfer prefixes and references, drop legal suffixes (SARL, SAS, SASU, SA, EURL, SCI, GmbH…), collapse whitespace. Merge Qonto client records with transaction counterparties on the normalized key; keep the raw label for display.

2. Compute exposure per counterparty

• Clients: sum of list_client_invoices with unpaid/overdue status — amount, count, oldest due date, ageing buckets (0–30 / 31–60 / 61–90 / 90+ days past due).
• Suppliers: supplier invoices still to pay + annualized recurring spend from transaction history → dependency weight (what breaks if this supplier fails).