fix(supplier-invoices): guard against duplicate payment when bank tx already booked (#461)

* fix(supplier-invoices): guard against duplicate payment when bank tx already booked Two-pronged fix for a UX trap where a supplier invoice could be marked paid even though the bank payment was already booked on 2440, creating a duplicate verifikation. Prong A — mark-paid duplicate guard: before booking, scan for an unlinked outgoing bank transaction matching this supplier (merchant_name ILIKE) within ±2% / ±60 days. If found, return 409 SI_PAID_LIKELY_DUPLICATE with candidates so the UI can offer "link existing" instead. Override via { force: true }. Prong B — categorize match suggestion: when the user assigns 2440 directly on a negative business transaction and an open supplier invoice from the same supplier covers the same amount, return 409 TX_CATEGORIZE_SUGGEST_SI_MATCH with candidates and route the user to match-supplier-invoice. Override via { confirm_no_match: true }. Frontend dialogs added on the supplier-invoice detail page and the transactions inbox. Partial payments skip the mark-paid guard (deliberate action). Tests cover the 409 path, the override path, and the no-candidates happy path on both routes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(supplier-invoices): apply PR review fixes to duplicate-payment guards - Add `is_business = true` filter to mark-paid candidate query so private bank withdrawals don't surface as false-positive duplicates - Escape LIKE wildcards (`%`, `_`, `\`) in both ILIKE patterns to avoid silent over-matching when a supplier/merchant name contains those chars - Round paymentAmount and remaining_amount to 2 decimals before the partial-payment guard comparison to avoid float-equality fragility - Require credit account to be in the 1xxx (bank/cash) series for the Prong B 2440 intercept so 2440 against clearing/equity accounts isn't misinterpreted as a supplier payment - Extract DUPLICATE_AMOUNT_TOLERANCE_PCT (0.02) and DUPLICATE_DATE_WINDOW_DAYS (60) into a shared helper module with the LIKE-escape utility Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(supplier-invoices): broaden 244x match, audit log overrides, drop JE id from response Second-round PR review fixes: - Widen Prong B regex from /^2440$/ to /^244\d$/ so payments mapped to BAS sub-accounts (e.g. 2441 leverantörsskulder i utländsk valuta) also trigger the suggestion (swedish-invoice-compliance bot) - Log a structured warning when force=true or confirm_no_match=true is honored, with the relevant context (amount, date, accounts) so the override is traceable per BFNAR 2013:2 kap 8 (behandlingshistorik) - Drop journal_entry_id from the SI_PAID_LIKELY_DUPLICATE candidate response payload (data minimization, GDPR Art.5(1)(c)); the UI never rendered it Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(supplier-invoices): third-round PR review — date window on Prong B, length cap, VAT message - Add the missing date window to the Prong B categorize candidate query (swedish-compliance bot): without it, an open invoice from years back can surface as a "match" for an unrelated bank transaction. Uses the shared DUPLICATE_DATE_WINDOW_DAYS against invoice_date. - Cap supplier/merchant names to 200 chars before they enter escapeLikePattern (OWASP V1.2.5 / ISO A.8.28). Bounds DB work on pathological inputs. - Log a structured warning when the mark-paid guard is skipped because the invoice has no resolved supplier name (BFL 5 kap 7 § — motpart should be identifiable; the absence is itself worth surfacing). - Update the SI-match suggestion error and the matching UI copy to call out the actual compliance risk: a duplicate 244x posting double-deducts ingående moms (ML 8 kap 3 §), not just bookkeeping symmetry. - Reword "Bokför på 2440 ändå" to "Bokför på leverantörsskulder ändå" now that the regex covers BAS sub-accounts 244x. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(supplier-invoices): correct Prong B framing — duplicate verifikation, not VAT double-deduction Latest swedish-compliance review correctly walked back the earlier finding that asked for ML 8 kap 3 § VAT framing. Plain 244x categorization via account_override does not include VAT lines (account class 2), so the risk is a duplicate verifikation (BFL 5 kap 5 §), not a double VAT deduction. Update both the structured error message and the dialog body to reflect the actual mechanism. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-13 11:38:19 +02:00
parent 01e99d3220
commit 07a7964e8d
9 changed files with 673 additions and 4 deletions
@@ -271,6 +271,7 @@ export const MarkSupplierInvoicePaidSchema = z.object({
  payment_date: isoDate.optional(),
  exchange_rate_difference: z.number().optional(),
  notes: z.string().optional(),
+  force: z.boolean().optional(),
 })

 export const UpdateSupplierInvoiceSchema = z.object({
@@ -327,6 +328,7 @@ export const CategorizeTransactionSchema = z.object({
  counterparty_template_id: z.string().uuid().optional(),
  user_description: z.string().max(500).optional(),
  inbox_item_id: z.string().uuid().optional(),
+  confirm_no_match: z.boolean().optional(),
 })

 export const BookTransactionSchema = z.object({
@@ -269,6 +269,17 @@ const TRANSACTIONS: Record<string, StructuredErrorEntry> = {
    message_sv: 'Transaktionen kategoriserades av en annan förfrågan. Ladda om och försök igen.',
    message_en: 'Transaction was already categorized by another request.',
  },
+  TX_CATEGORIZE_SUGGEST_SI_MATCH: {
+    httpStatus: 409,
+    message_sv:
+      'Det finns en öppen leverantörsfaktura från samma leverantör med samma belopp. Matcha mot fakturan istället för att bokföra direkt på leverantörsskuldskontot — annars skapas en dubblerad verifikation som måste stornas (BFL 5 kap 5 §).',
+    message_en:
+      'An open supplier invoice from the same supplier matches this amount. Suggest matching to the invoice instead of a plain 244x categorization to avoid producing a duplicate verifikation (BFL 5 kap 5 §).',
+    remediation: {
+      description:
+        'Match the transaction via POST /api/transactions/{id}/match-supplier-invoice, or resend with confirm_no_match: true to keep the plain 244x categorization.',
+    },
+  },
  TX_UNCATEGORIZE_NO_LINKED_ENTRY: {
    httpStatus: 400,
    message_sv: 'Transaktionen har ingen kopplad verifikation att stornera.',
@@ -1129,6 +1140,17 @@ const SUPPLIER_INVOICE_WAVE4: Record<string, StructuredErrorEntry> = {
    message_sv: 'Kunde inte registrera betalningen.',
    message_en: 'Failed to record supplier invoice payment.',
  },
+  SI_PAID_LIKELY_DUPLICATE: {
+    httpStatus: 409,
+    message_sv:
+      'Det finns redan en obokförd banktransaktion som kan vara denna betalning. Länka den istället, eller markera som betald ändå om du är säker.',
+    message_en:
+      'A likely-matching unlinked bank transaction was found for this supplier. Suggest linking it instead of creating a new payment entry.',
+    remediation: {
+      description:
+        'Match the candidate transaction via POST /api/transactions/{id}/match-supplier-invoice, or resend mark-paid with force: true to create the payment entry anyway.',
+    },
+  },
  SI_CREDIT_ALREADY_CREDITED: {
    httpStatus: 409,
    message_sv: 'Leverantörsfakturan har redan krediterats.',
@@ -0,0 +1,30 @@
+/**
+ * Shared constants and helpers for the duplicate-payment / SI-match guards
+ * used by `/api/supplier-invoices/[id]/mark-paid` and
+ * `/api/transactions/[id]/categorize`. Both guards look for a likely-matching
+ * counterparty within a fuzzy amount + date window; keeping the thresholds in
+ * one place makes them tunable as we learn from real false-positive rates.
+ */
+
+/** Acceptable amount drift (±) when matching a bank tx to an invoice amount. */
+export const DUPLICATE_AMOUNT_TOLERANCE_PCT = 0.02
+
+/** Date window (±days) around the payment / invoice date. */
+export const DUPLICATE_DATE_WINDOW_DAYS = 60
+
+/** Cap on supplier / merchant names before they enter an ILIKE pattern, to
+ * bound query work and avoid pathological inputs degrading the index scan. */
+const MAX_LIKE_NEEDLE_LENGTH = 200
+
+/**
+ * Escape LIKE/ILIKE wildcards (`%`, `_`, `\`) and truncate to a safe length
+ * before embedding the value in an ILIKE pattern. SQL-injection is already
+ * handled by Supabase's parameterization; this purely prevents silent
+ * over-matching on names like "50% Off AB" and bounds DB work on long inputs.
+ */
+export function escapeLikePattern(value: string): string {
+  const truncated = value.length > MAX_LIKE_NEEDLE_LENGTH
+    ? value.slice(0, MAX_LIKE_NEEDLE_LENGTH)
+    : value
+  return truncated.replace(/\\/g, '\\\\').replace(/%/g, '\\%').replace(/_/g, '\\_')
+}