diff --git a/CHANGELOG.md b/CHANGELOG.md
index 404b5b49c..4504a6229 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -36,6 +36,8 @@ Le contenu est rédigé en français à destination des **fiduciaires, PME, ind
 
 - **La configuration d'une installation de production s'inscrit au journal d'audit ([#434](https://github.com/guycorbaz/kesh/issues/434)).** Chaque étape de l'assistant — langue, mode d'utilisation, passage en production, type d'organisation, langue comptable, coordonnées, compte bancaire (ou son omission) et finalisation — laisse une entrée *Étape d'installation franchie*, précédée de ce qu'elle a réellement changé : la société créée ou modifiée, le compte bancaire (sans jamais l'IBAN en clair), les réglages de facturation et les taux de TVA effectivement insérés. Le plan comptable livré s'inscrit en **une seule** entrée, *Plan comptable chargé*, qui liste les comptes créés. Quatre actions nouvelles sont libellées dans les quatre langues. Une étape ne laisse plus la société modifiée à moitié : la modification, la progression de l'étape et leur trace sont désormais **une seule transaction**, et l'étape est revérifiée sous verrou — deux demandes simultanées ne chargent plus le plan comptable deux fois. *Le perdant d'une telle course reçoit désormais « étape déjà franchie » au lieu d'un conflit de version.* *La version de la société (`version`, lue par le verrou optimiste de `PUT /company`) n'avance plus lorsqu'une étape ne change rien ; sur une société provisoire dont les coordonnées changent, elle avance désormais de deux.* Le peuplement de démonstration et la remise à zéro restent à tracer (même issue).
 
+- **Un règlement ne peut plus viser le compte qu'il solde ([#474](https://github.com/guycorbaz/kesh/issues/474)).** Régler une facture client par le compte débiteurs lui-même — en compte interne, ou par un compte bancaire lié à ce compte — écrivait `D 1100 / C 1100` : l'écriture s'équilibrait, le reste dû baissait, la facture pouvait passer « payée », et le grand livre ne bougeait pas. Il en allait de même d'une facture fournisseur réglée par le compte créanciers (`D 2000 / C 2000`), y compris par un lot de paiement, et d'un encaissement par rapprochement quand le compte bancaire était lié au compte débiteurs. Ces règlements sont désormais **refusés sans rien écrire** (`SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT`), avec un message qui dit le remède. Les écrans de règlement ne proposent plus ces comptes, ni les comptes bancaires qui y sont liés. Une facture dont le compte créanciers est le compte de banque du lot n'entre plus dans un lot de paiement (elle apparaît parmi les refus, et le fichier pain.001 ne la porte pas) ; si le compte bancaire a été relié depuis la création du lot, la confirmation est refusée et le message dit les deux issues — relier de nouveau le compte bancaire puis confirmer, ou annuler le lot. Les comptes d'écart du même geste sont gardés de même : le compte de différences d'arrondi d'un règlement ou d'un rapprochement, et les comptes de nature, de reste d'arrondi et de TVA due d'un solde du reste ne peuvent pas être le compte débiteurs de la facture (cas d'un compte débiteurs changé de type, puis désigné dans les réglages) — un administrateur doit alors en désigner un autre dans *Paramètres → Facturation*. Les règlements de cette forme déjà enregistrés restent tels quels.
+
 - **Un compte non imputable est refusé partout où un client le désigne pour recevoir des écritures ([#427](https://github.com/guycorbaz/kesh/issues/427), [#429](https://github.com/guycorbaz/kesh/issues/429)).** Les écrans filtraient ces comptes, mais le serveur ne les contrôlait pas : un appel direct — par clé d'API ou par une intégration — pouvait rapprocher une transaction bancaire sur **9000 Bilan d'ouverture**, et fausser le résultat de l'exercice et le report à nouveau. Sont désormais refusés en `400 ACCOUNT_NOT_POSTABLE`, qui nomme le compte : le **rapprochement** manuel et ventilé, l'acceptation d'une proposition ventilée ou par règle (dans `failed[]`, sans bloquer le reste du lot) ; les **règles d'affectation** — création, changement de compte, et **réactivation** d'une règle dont le compte n'est plus imputable ; le **compte comptable d'un compte bancaire**, à la création, ou quand on le change. Une règle dont le compte est devenu non imputable — par exemple scindé en sous-comptes — **n'est plus proposée** ; la règle suivante qui correspond l'est à sa place. Les **réglages de facturation** refusent un compte non imputable **au moment où on le désigne** (créance, produit, TVA due, TVA récupérable, décompte TVA, créanciers), avec un message qui nomme le champ. ⚠️ **Limites** : un compte déjà désigné ou déjà lié, devenu non imputable après coup, reste accepté — on peut enregistrer les réglages, modifier le compte bancaire ou renommer la règle sans le changer. La validation d'une facture et la saisie (ou la complétion) d'une facture fournisseur refusent désormais un compte de réglage devenu non imputable (entrée ci-dessous) ; **restent** hors de cette garde l'avoir, le compte de produit par défaut et le compte comptable d'un compte bancaire déjà lié. L'écran des règles affichait « [object Object] » au lieu du message d'un refus : il affiche le message. Sur l'écran des comptes bancaires, un compte lié devenu non imputable s'affichait vide dans les formulaires de modification et de lien : il reste affiché.
 
 - **Un compte de réglage devenu non imputable n'est plus utilisé par les écritures automatiques ([#429](https://github.com/guycorbaz/kesh/issues/429)).** La créance et la TVA due, désignées dans *Paramètres → Facturation*, recevaient l'écriture de chaque facture validée même devenues non imputables — après la création de sous-comptes, la case *imputable* décochée ou le rôle « résultat de l'exercice » attribué —, comme les créanciers et la TVA récupérable pour chaque facture fournisseur. La **validation d'une facture** et la **saisie (ou la complétion) d'une facture fournisseur** les contrôlent désormais au moment d'écrire, et refusent avec un message qui nomme le compte, renvoie à *Paramètres → Facturation* et dit qu'un **administrateur** doit y désigner un compte imputable — la page des réglages lui est réservée. La TVA due (ou récupérable) n'est contrôlée que si la pièce en porte. L'**avoir** n'est pas soumis à ce contrôle, délibérément — une facture émise reste annulable : il crédite la créance que la facture a débitée (entrée ci-dessous, [#473](https://github.com/guycorbaz/kesh/issues/473)), et relit encore la TVA due dans les réglages du moment, ce que corrigera [#525](https://github.com/guycorbaz/kesh/issues/525). ⚠️ **Après la mise à jour, vérifiez dans *Paramètres → Facturation* que les comptes désignés sont imputables** : un compte devenu non imputable (sous-comptes créés, case *imputable* décochée…) doit y être remplacé, faute de quoi la validation des factures (ou la saisie des factures fournisseurs) est refusée. *(API : `400 ACCOUNT_NOT_POSTABLE`, `details.rejected[{accountId, accountNumber}]`, sur `POST /invoices/{id}/validate`, `POST /supplier-invoices` et `POST /imported-supplier-invoices/{id}/complete` — après tous les autres refus, exercice compris.)*
diff --git a/README.md b/README.md
index 9115702a4..23aa3e683 100644
--- a/README.md
+++ b/README.md
@@ -34,7 +34,7 @@
 - **Coordonnées de l'émetteur sur la facture** — téléphone, e-mail et site web figurent sous votre adresse sur le PDF, saisis une fois dans les réglages ; chaque champ est facultatif et n'occupe aucune place s'il est vide ✓
 - **Carnet de contacts structuré** — contacts **Personne** (prénom + nom) ou **Entreprise** (raison sociale), **adresse structurée** (QR-facture), et **personnes de contact** rattachées à une entreprise (interlocuteurs, à titre informatif) ✓
 - **Prévention des doublons à la saisie** — pendant que vous tapez le nom d'un nouveau contact, Kesh signale ceux qui lui ressemblent déjà (casse, accents, traits d'union et espaces indifférents), et avertit si l'**IDE** saisi appartient à une fiche existante — y compris **archivée**, cas où l'enregistrement serait refusé sans que la fiche soit visible dans le carnet. Kesh **signale, il ne bloque jamais** : deux clients peuvent légitimement porter des noms très proches ✓
-- **Règlements clients** — enregistrement d'un règlement depuis la fiche (virement, espèces ou tout autre compte), partiel ou total, avec son écriture ; liste des règlements de la facture et **annulation par contre-passation** ✓
+- **Règlements clients** — enregistrement d'un règlement depuis la fiche (virement, espèces ou un autre compte de contrepartie — jamais le compte débiteurs de la facture), partiel ou total, avec son écriture ; liste des règlements de la facture et **annulation par contre-passation** ✓
 - **Avoirs (notes de crédit)** — annulation d'une facture validée par création d'un avoir lié (séquence séparée `AV-…`), contre-passation comptable automatique (TVA comprise), PDF « Avoir » ✓
 - **Envoi de factures par e-mail** — bouton sur la facture validée : QR-facture PDF jointe, objet/message pré-remplis dans la **langue du contact** avec civilité personnalisée (modèles multilingues FR/DE/IT/EN configurables par l'admin), destinataire verrouillé sur la fiche contact, Reply-To = e-mail de la société, traçage « Envoyée le … à … » et renvoi possible ✓
 - **Import bancaire CAMT.053 + CSV multi-encodage** — parser + persistance + UI ✓, profils banque réutilisables ✓, réconciliation automatique avec score ✓, réconciliation manuelle ✓, éclatement de transaction agrégée ✓, règles d'affectation automatique ✓ et **annulation d'un rapprochement** par contre-passation ✓
diff --git a/_bmad-output/implementation-artifacts/15-6b-contrepartie-distincte-de-la-creance.md b/_bmad-output/implementation-artifacts/15-6b-contrepartie-distincte-de-la-creance.md
index 1c08e661d..a6c4d7307 100644
--- a/_bmad-output/implementation-artifacts/15-6b-contrepartie-distincte-de-la-creance.md
+++ b/_bmad-output/implementation-artifacts/15-6b-contrepartie-distincte-de-la-creance.md
@@ -2,7 +2,7 @@
 
 ## Status
 
-ready-for-dev
+done
 
 <!-- Spécifiée le 2026-10-08 en autonomie (bmad-create-story), fille de la 15-6 découpée d'emblée
      (choix C-15-6-1). Choix propres : C-15-6-3, C-15-6-4 (précisé par C-15-6-14), C-15-6-10,
@@ -152,6 +152,11 @@ le défait aussi, et la créance lue dans les réglages n'a **aucun type contrô
    `"SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT"` — **un** code pour les quatre rôles (le défaut est le
    même : une écriture `D X / C X`) ; `details.role` et le message distinguent le remède. Doc-comment :
    le motif (écriture nulle, reste dû qui baisse sans mouvement), #474.
+   ⚠️ **Amendé le 2026-10-09 (revue de code P1, finding L3)** : le sous-ensemble
+   `{ Rounding, WriteOffNature, VatPayable }` est **livré sous le nom `GapAccountRole`**, et non
+   `DesignatedRole` — un `DesignatedRole` de la 15-5d existe déjà dans
+   `company_invoice_settings.rs`, avec un autre ensemble (choix **C-15-6b-2**). Lire
+   `ClaimSubject::Designated(GapAccountRole)` partout où cette fiche écrit `DesignatedRole`.
    **Helper commun** (finding F3 de la P3, DRY ; choix C-15-6-26) — dans
    `crates/kesh-db/src/repositories/invoice_settlements.rs`, à côté du lecteur de la 15-6a, la
    **comparaison** est séparée de la **construction du refus** (signatures indicatives) :
@@ -562,7 +567,7 @@ le défait aussi, et la créance lue dans les réglages n'a **aucun type contrô
 
 ## Tasks / Subtasks
 
-- [ ] **T0 — Rebase** sur `main` après le merge de la 15-6a et des 15-5a à 15-5e ;
+- [x] **T0 — Rebase** sur `main` après le merge de la 15-6a et des 15-5a à 15-5e ;
   **refaire tous les numéros de ligne** de la fiche sur `HEAD` ; vérifier où la 15-5a a placé
   `ACCOUNT_NOT_POSTABLE` dans `settle_invoice` et `pay_in_tx` (AC3, AC4) ; **relever l'ordre des
   lectures** de `settle_invoice` et de `write_off_invoice` sur `HEAD` et vérifier que l'AC3 bis le suit
@@ -573,8 +578,8 @@ le défait aussi, et la créance lue dans les réglages n'a **aucun type contrô
   `failed-proposal-label.ts` (AC7), relever `sitesTotal` (AC8). Les choix **C36, C52, C54, C55**
   que la fiche cite vivent au registre de la branche des 15-5 (dépôt principal) : absents de cette
   branche avant le rebase, ils y arrivent avec lui (finding R6-11 de la P6).
-- [ ] **T1 — Variante, rôle, contexte de lot, code, mapping, i18n** (AC1, AC2).
-- [ ] **T2 — Helper commun puis gardes serveur** : `ensure_not_claim_account`,
+- [x] **T1 — Variante, rôle, contexte de lot, code, mapping, i18n** (AC1, AC2).
+- [x] **T2 — Helper commun puis gardes serveur** : `ensure_not_claim_account`,
   `claim_account_refusal` et `claim_account_refusal_details` dans `invoice_settlements.rs` (AC1), **avant** les sites qui les
   appellent ; gardes (AC3, AC3 bis, AC4, AC5), lecteur sœur fournisseur (AC4). Aucun site ne compare
   ni ne construit le refus ni ne lit le numéro par lui-même. **Critère par le nom seul, sur une liste
@@ -597,16 +602,16 @@ le défait aussi, et la créance lue dans les réglages n'a **aucun type contrô
   `confirm_batch` est un défaut. Et `grep -rnF "SELECT number FROM accounts WHERE id = ? AND company_id = ?" crates/*/src`
   ne rend, pour cette story, que `claim_account_refusal` (chaîne écrite sur une ligne — une requête
   coupée par `\` y échapperait : le helper l'écrit d'un tenant, et le doc-comment le dit).
-- [ ] **T3 — Lots de paiement** (AC6), serveur (création, écriture d'achat malformée, confirmation
+- [x] **T3 — Lots de paiement** (AC6), serveur (création, écriture d'achat malformée, confirmation
   contextualisée) et libellés.
-- [ ] **T4 — Libellé `failed[]` du rapprochement** (AC7) ou signalement.
-- [ ] **T5 — Fonctions d'écran et écrans** (AC8, AC9).
-- [ ] **T6 — Tests** (§ *Tests*) — chaque test de garde **rougit d'abord** sur le code non corrigé,
+- [x] **T4 — Libellé `failed[]` du rapprochement** (AC7) ou signalement.
+- [x] **T5 — Fonctions d'écran et écrans** (AC8, AC9).
+- [x] **T6 — Tests** (§ *Tests*) — chaque test de garde **rougit d'abord** sur le code non corrigé,
   **sauf** les tests de non-régression 3 et 9, verts avant comme après.
-- [ ] **T7 — Documentation** : `docs/api-external.md` (AC10), manuel + PDF (AC11), CHANGELOG (AC12).
-- [ ] **T8 — Inventaire fermé** (§ *Inventaire*) : rejouer les commandes ; tout site neuf est traité
+- [x] **T7 — Documentation** : `docs/api-external.md` (AC10), manuel + PDF (AC11), CHANGELOG (AC12).
+- [x] **T8 — Inventaire fermé** (§ *Inventaire*) : rejouer les commandes ; tout site neuf est traité
   ou écrit en angle mort avec sa raison.
-- [ ] **T9 — Gates** : backend complet (dépôts `kesh-db` touchés : pas de ciblage), frontend complet
+- [x] **T9 — Gates** : backend complet (dépôts `kesh-db` touchés : pas de ciblage), frontend complet
   (`check`, `lint-i18n-ownership`, `test:unit` — dont la borne `sitesTotal` relevée, AC8 —, `build`),
   E2E complet au dernier commit de code (D7).
   Le verdict de lecture sur les E2E existants (§ *Tests*, « E2E existants ») est recopié au Dev Agent
@@ -662,7 +667,8 @@ Finding F5 de la P2 : la P1 a ajouté les lots sans recompter. Recompté le 2026
 la P5, finding R5-5), **au barème de la règle** (« modules métier de premier niveau ») : `kesh-db`
 règlement client (`invoice_settlements_write.rs`, solde du reste compris), `kesh-db` helper commun
 (`invoice_settlements.rs` : trois fonctions publiques et les types `ClaimAccountClash`,
-`ClaimSubject`, `DesignatedRole` — les deux premiers omis jusqu'à la P4, le troisième jusqu'à la P6), `kesh-db` règlement fournisseur
+`ClaimSubject`, `DesignatedRole` — les deux premiers omis jusqu'à la P4, le troisième jusqu'à la P6 ;
+livré sous le nom `GapAccountRole`, C-15-6b-2, amendé le 2026-10-09), `kesh-db` règlement fournisseur
 (`supplier_invoices.rs`), `kesh-db` lots (`payment_batches.rs`), `kesh-api` rapprochement
 (`routes/reconciliation.rs`), `frontend` factures (`features/invoices`), `frontend` factures
 fournisseurs (`routes/supplier-invoices`), `frontend` lots (`features/payment-batches`), `frontend`
@@ -923,6 +929,16 @@ deux cas de l'AC7 (non compté : conditionnel).
   de la story (aucun ne solde un compte), et deux modules de plus.
 - **Le filtre d'écran n'est exercé par aucun E2E** : le seed E2E n'a pas de rôle (§ *Tests*, « E2E
   existants ») ; l'AC8 n'est figé que par Vitest (tests 17-19).
+- **Plan comptable non chargé** (revue de code P1, finding E4) : si `fetchAccounts` échoue, les
+  écrans de règlement retombent sur une liste vide (`invoices/[id]/+page.svelte`,
+  `invoices/due-dates/+page.svelte`), le filtre par rôle n'a rien à écarter et le compte débiteurs
+  redevient proposé ; la garde serveur le refuse avec son message. Même famille que le premier
+  point : l'écran peut proposer ce que le serveur refuse, jamais l'inverse.
+- **Branches d'erreur infra non exercées** (revue de code P1, finding B-5) : le bras
+  `other => DATABASE_ERROR` de `claim_account_failed_proposal` (rapprochement) et le bras
+  `_ => Err(refusal)` de `validate_invoice_for_batch` (erreur SQL de la lecture du numéro) ne sont
+  déclenchés par aucun test — il y faudrait une injection de panne SQL au milieu d'une transaction,
+  que le banc ne sait pas faire. Les tests ne couvrent que le bras du refus métier.
 - **Données antérieures** : des règlements `D 1100 / C 1100` ou `D 2000 / C 2000` déjà écrits par une
   instance v0.12 restent tels quels, sans détection. Acceptable : le produit ne tient pas encore de
   comptabilité réelle (`CLAUDE.md` § *Project Overview*) ; à réexaminer si une instance en a écrit.
@@ -955,12 +971,178 @@ deux cas de l'AC7 (non compté : conditionnel).
 
 ### Agent Model Used
 
+Opus 5.5 (`claude-opus-5-5`), en autonomie (consignes de l'Epic 15), worktree
+`/home/gcorbaz/devel/kesh-15-6b`, branche `story/15-6b-contrepartie-distincte-de-la-creance` depuis
+`39b52628`. Le 2026-10-09.
+
 ### Debug Log References
 
+- Tests neufs joués **avant** les gardes (`target/red-run.log`, non versionné) : **19 rouges / 22**
+  — les 19 tests de garde, chacun pour la bonne raison (écriture `D X / C X` acceptée, ou
+  `ConfigurationRequired` / `RECONCILIATION_OVERPAYMENT` là où l'ordre attend le refus neuf) ; verts :
+  les tests 3 et 9 (non-régression, verts avant comme après) et un test existant attrapé par le
+  filtre. Après les gardes : **22/22**.
+- Mutations jouées et constatées rouges, puis sources restaurées et `touch`ées :
+  1. `confirm_batch` n'intercepte plus le refus (`batch: None` → `batch: Some(_)` dans le motif) →
+     `confirm_batch_refuses_then_passes_once_the_bank_is_relinked` rouge ;
+  2. la nature `rounding` classée `WriteOffNature` → `the_rounding_nature_on_the_receivable_is_refused_as_rounding` rouge ;
+  3. (c-bis) passe `Some(bank_account_id)` → `accept_refuses_a_rounding_account_that_is_the_receivable` rouge ;
+  4. présélection du compte bancaire remise dans l'effet de réinitialisation → test 18 « `accounts`
+     arrivé APRÈS l'ouverture » rouge ;
+  5. filtre du rôle `Receivable` retiré du menu « Compte interne » → test 18 « 1100 absent » rouge.
+- **Artefact de banc relevé** : le `rerender` de `@testing-library/svelte` 5.3.1 remplace l'objet de
+  props entier (`$state.raw`, `svelte-core/src/props.svelte.js`), si bien que toute prop paraît
+  changée et que l'effet de réinitialisation du dialogue se rejoue — ce qu'un parent réel ne fait
+  pas. Le test 18 passe donc par une doublure `SettleInvoiceDialogHost.test.svelte` (patron
+  `ModalSuccessStub.test.svelte`), qui ne change que `accounts`.
+
 ### Completion Notes List
 
+- **T0** : aucun écart de fond (entrée datée au Change Log). Numéros relocalisés.
+- **AC1** : variante, `ClaimSide`, `SettlementAccountRole`, `SettlementBatchContext` dans
+  `kesh-db/src/errors.rs` ; `ClaimAccountClash`, `GapAccountRole` (**et non `DesignatedRole`**,
+  homonyme d'un type de la 15-5d — choix **C-15-6b-2**), `ClaimSubject`, `ensure_not_claim_account`,
+  `claim_account_refusal`, `claim_account_refusal_details` dans `invoice_settlements.rs`, plus
+  `refuse_if_claim_account`, qui enchaîne les deux gestes (choix **C-15-6b-1**).
+- **AC2** : mapping 400, six clés plates (aucun sélecteur), repli `format!`, quatre locales.
+- **AC3 / AC3 bis** : `settle_invoice` (contrepartie → trop-perçu → arrondi) et `write_off_invoice`
+  (nature → reste d'arrondi → TVA due), chaque comparaison aussitôt sa lecture et celle de la
+  créance ; doc-comments.
+- **AC4** : `pay_in_tx` + lecteur sœur `supplier_invoices::purchase_payable_line` (deux appelants).
+- **AC5** : `accept_one_invoice` étape (b bis) et (c-bis), une seule fonction de conversion
+  (`claim_account_failed_proposal`) ; commentaire de classement de la 15-5b amendé.
+- **AC6** : création (`failed[]` avec `bankAccountId`, écriture d'achat malformée en
+  `SUPPLIER_INVOICE_PURCHASE_ENTRY_MALFORMED`, erreur SQL propagée) ; confirmation interceptée et
+  contextualisée (numéro de facture relu) ; `failedItemLabel` à huit codes (les « six » → « huit »
+  aux quatre sites).
+- **AC7** : la 15-5c est mergée — `failedProposalLabel` à deux cas selon `details.role` (27 codes).
+- **AC8** : trois fonctions dans `account-options.ts` ; dialogue client (effet de présélection
+  distinct) et fiche fournisseur filtrés ; messages de liste vide conditionnés ; borne
+  `sitesTotal` **1915 → 1921** (+6, recompté par fichier aux deux bornes) ; et — non prévu par la
+  fiche — `CLES_RELEVEES` de `i18n-un-repli-par-cle.test.ts` **210 → 213** (+3 nommées), garde
+  qui a rougi au premier `test:unit` complet.
+- **AC9** : aucun changement de code ; le rendu de `errorMsg` est figé par le test 18.
+- **AC10** : `docs/api-external.md` — phrase de refus de `POST …/settlements` hors de la table
+  d'annulation ; ligne à la table du solde ; phrase de `POST …/pay` et des deux routes de lot, posée
+  avant la ligne de refus de l'annulation, que j'ai libellée « Refus de l'annulation : » pour lever
+  toute ambiguïté ; refus par proposition au § du rapprochement.
+- **AC11** : manuel utilisateur (cinq sections, `:1754` → balance âgée relocalisée) et manuel
+  d'administration (deux phrases) ; PDF `user-manual` et `admin-manual` régénérés (`make fr`) et
+  contrôlés **aplatis** (une phrase neuve au moins par section, « tout autre compte » et
+  « contrepartie libre » absents). La brochure, régénérée par `make` sans changement de source,
+  a été restaurée depuis git. **Hors fiche** : `README.md` (§ Fonctionnalités) disait « virement,
+  espèces ou tout autre compte » — corrigé (grep de propagation).
+- **AC12** : CHANGELOG `[0.13.0]` / `### Corrigé`.
+- **T8 — inventaire fermé** : les cinq commandes rejouées sur `HEAD` ne rendent **aucun site neuf** ;
+  écrivains : `pay_in_tx`, `settle_invoice`, `write_off_invoice`, `accept_one_invoice` (gardés),
+  `accept_one_split` (déjà gardé), `accept_one_rule`, `post_manual_once`, `post_split_once` (15-6d /
+  déjà gardé), `credit_notes` (#525), `invoices` validation et son arrondi (#537),
+  `supplier_invoices::create` (#537), `opening_complement` (hors classe) ; écrans : ceux des tables
+  de la fiche.
+- **Critère de T2** : `grep -rnF "SettlementCounterpartyIsClaimAccount" crates/*/src` (commentaires
+  exclus) ne rend que les cinq fichiers de la liste ; constructions : `claim_account_refusal`,
+  l'interception de `confirm_batch`, et deux tests ; `SELECT number FROM accounts WHERE id = ? AND company_id = ?`
+  ne rend que `claim_account_refusal`.
+- **Tests ajoutés**, de `39b52628` à `HEAD` (recompté par `grep -c` aux deux bornes) : backend
+  **29** — 21 d'intégration (`invoice_settlement` +6, `invoice_write_off` +5,
+  `supplier_invoices_repository` +2, `payment_batches_repository` +3, `reconciliation_e2e` +3,
+  `invoice_echeancier_e2e` +2) et 8 unitaires (`kesh-db` errors +2, `invoice_settlements` +3,
+  `kesh-api` errors +3) ; frontend **17** déclarations `it` / `it.each` (`account-options` +4,
+  `SettleInvoiceDialog` +6, `supplier-settlement-page` +4, `failed-proposal-label` +3) et le test
+  « mappe les six codes » de `payment-batch-helpers` renommé et étendu à huit. Les 23 tests nommés
+  par la fiche y sont tous ; s'y ajoutent deux cas backend non nommés : nature `rounding` sur la
+  créance (rôle `rounding`) et TVA due = créance (rôle `vat_payable`, sa seule garde).
+- **Verdict de lecture sur les E2E existants** (recopié de la fiche, § *Tests*) : aucune rupture
+  attendue — le filtre par rôle est inerte en E2E (seed sans rôle) ; aucune spec ne règle par le
+  compte soldé. *Confronté au run : voir Gates.*
+
+### Gates (dernier commit de code : `77930445`)
+
+- Backend complet (`scripts/test-fast.sh`, base `kesh_156b` remise à zéro par `DROP`/`CREATE`,
+  migrations, seed) : `cargo fmt --check` vert, `clippy -D warnings` vert, nextest **2958 passés,
+  4 ignorés**.
+- Frontend : `npm run check` 0 erreur (27 avertissements, tous dans des fichiers non touchés),
+  `lint-i18n-ownership` PASS, `test:unit` **1110 / 1110** (112 fichiers), `build` vert.
+- Tests `kesh-i18n` (parité des locales, sélecteurs) : 32 / 32.
+- E2E complet (Playwright, au dernier commit de code ; backend `./target/debug/kesh-api` sur le
+  port 3014, base `kesh_e2e_156b` reconstruite, secrets tirés par `openssl rand`,
+  `KESH_TEST_MODE=true` côté backend et runner, `KESH_COOKIE_SECURE=false`, quatre `KESH_SMTP_*`,
+  répertoires inbox/documents/sauvegarde du worktree ; `/health` : `smtpConfigured: true`) — run de
+  03:32 à 03:42 UTC : **247 passés, 9 échoués, 17 ignorés**. Les 9, fichier par fichier, sont
+  **tous** à la liste de `docs/testing.md` § « Les échecs attendus » : les sept KF-029 (#97)
+  (`mode-expert.spec.ts:26`, `:41` ; `onboarding-path-b.spec.ts:65`, `:92` ; `onboarding.spec.ts:57`,
+  `:77`, `:150`) et les deux KF-045 (#421) d'avant 12:00 UTC (`invoices.spec.ts:415` « historique des
+  rappels affiché », `:439` « axe-core … fiche »). **Aucun échec hors liste, aucune pollution.**
+  Confronté au verdict de lecture : aucune des specs nommées par la fiche n'a rougi
+  (`invoices_echeancier`, `invoices.spec.ts:318-321` sous son numéro actuel, `reminders`,
+  `invoice-write-off`, `invoices-settlement-cancel`, `reconciliation-*`, `payment-batches`,
+  `supplier-invoices`, `bank-account-journal-link`). Backend arrêté par son PID.
+
+### Gates sur l'état rebasé (`origin/main` `012fc430`, 15-12a), au commit de remédiation de la revue P1 `829537fb`
+
+- Rebase sur `012fc430` : conflits résolus en union — registre (les entrées de main d'abord,
+  puis C-15-6b-1 à C-15-6b-3), borne `sitesTotal` (15-12a 1915 → 1916, puis 15-6b +6 → **1922**),
+  CHANGELOG `[0.13.0]` / `### Corrigé` (une rubrique de chaque), PDF `user-manual` et
+  `admin-manual` régénérés (`make fr`, sources `.tex` fusionnées sans conflit) et contrôlés
+  aplatis (phrases de la 15-12a — « Clôture dans l'ordre (depuis la v0.13.0) », « ne se crée pas
+  avant un exercice clôturé » — et de la 15-6b présentes). `CLES_RELEVEES` inchangée par main :
+  **213** (test vert). Aucun conflit de code.
+- Backend complet (`scripts/test-fast.sh`, base `kesh_156b` remise à zéro par `DROP`/`CREATE`,
+  migrations, seed) : `cargo fmt --check` vert, `clippy -D warnings` vert, nextest **2984 passés,
+  4 ignorés** (2951 de la 15-12a + 29 de la 15-6b + 4 de la remédiation P1).
+- Frontend : `npm run check` 0 erreur (27 avertissements, fichiers non touchés),
+  `lint-i18n-ownership` PASS, `test:unit` **1118 / 1118** (112 fichiers), `build` vert.
+- E2E complet (backend `./target/debug/kesh-api` sur le port 3014, base `kesh_e2e_156b`
+  reconstruite, secrets tirés par `openssl rand`, `KESH_TEST_MODE=true` des deux côtés,
+  `KESH_COOKIE_SECURE=false`, quatre `KESH_SMTP_*`, répertoires inbox/documents/sauvegarde du
+  worktree ; `/health` : `smtpConfigured: true`) — run de 04:36 à 04:48 UTC : **247 passés,
+  9 échoués, 17 ignorés**. Les 9, fichier par fichier, sont tous à `docs/testing.md` § « Les
+  échecs attendus » : les sept KF-029 (`mode-expert.spec.ts:26`, `:41` ;
+  `onboarding-path-b.spec.ts:65`, `:92` ; `onboarding.spec.ts:57`, `:77`, `:150`) et les deux
+  KF-045 d'avant 12:00 UTC (`invoices.spec.ts:415`, `:439`). Aucun échec hors liste. Backend
+  arrêté par son PID (identifié par le port 3014 et son répertoire courant).
+
+### Gates sur l'état rebasé une seconde fois (`origin/main` `200f5e79`, 15-7a2)
+
+- La 15-7a2 a été mergée pendant les gates ci-dessus : branche rebasée de nouveau. Conflits
+  documentaires seulement, résolus en union — registre, CHANGELOG `[0.13.0]` / `### Corrigé`
+  (une rubrique de chaque), `sprint-status` (`last_updated` de la 15-6b renuméroté **(36)**, après
+  les (34) et (35) de main) ; PDF `user-manual` et `admin-manual` régénérés (`make fr`) et
+  contrôlés aplatis : phrases de la 15-7a2 (« routes à verbe mutant au moment de la rédaction »,
+  « Deux familles d'opérations n'y figurent pas encore »), de la 15-12a et de la 15-6b (dont la
+  condition du filtre par rôle, L10) présentes. Bornes i18n inchangées par la 15-7a2 (catalogues
+  backend seuls) : `sitesTotal` **1922**, `CLES_RELEVEES` **213**.
+- Backend complet (base `kesh_156b` remise à zéro ; un premier lancement, coupé par une borne de
+  temps de l'orchestration à 537/3006, n'est **pas** compté, la base a été reconstruite avant le
+  second) : fmt et clippy verts, nextest **3006 passés, 4 ignorés**.
+- Frontend : `check` 0 erreur (27 avertissements, fichiers non touchés), `lint-i18n-ownership`
+  PASS, `test:unit` **1118 / 1118**, `build` vert.
+- E2E complet (même montage, base `kesh_e2e_156b` reconstruite, secrets neufs ; run de 05:52 à
+  06:02 UTC) : **247 passés, 9 échoués, 17 ignorés** — les mêmes neuf, tous à la liste (sept
+  KF-029, deux KF-045 d'avant 12:00 UTC). Backend arrêté par son PID.
+
 ### File List
 
+- `crates/kesh-db/src/errors.rs`
+- `crates/kesh-db/src/repositories/invoice_settlements.rs`
+- `crates/kesh-db/src/repositories/invoice_settlements_write.rs`
+- `crates/kesh-db/src/repositories/supplier_invoices.rs`
+- `crates/kesh-db/src/repositories/payment_batches.rs`
+- `crates/kesh-api/src/errors.rs`
+- `crates/kesh-api/src/routes/reconciliation.rs`
+- `crates/kesh-i18n/locales/{fr-CH,de-CH,it-CH,en-CH}/messages.ftl`
+- `crates/kesh-db/tests/{invoice_settlement,invoice_write_off,supplier_invoices_repository,payment_batches_repository}.rs`
+- `crates/kesh-api/tests/{reconciliation_e2e,invoice_echeancier_e2e,supplier_settlement_cancel_e2e}.rs`
+  (le dernier : revue de code P1, finding L5)
+- `frontend/src/lib/features/accounts/account-options.ts` (+ `.test.ts`)
+- `frontend/src/lib/features/invoices/SettleInvoiceDialog.svelte` (+ `.test.ts`, `SettleInvoiceDialogHost.test.svelte`)
+- `frontend/src/routes/(app)/supplier-invoices/[id]/+page.svelte` (+ `supplier-settlement-page.test.ts`)
+- `frontend/src/lib/features/payment-batches/payment-batch-helpers.ts` (+ `.test.ts`)
+- `frontend/src/lib/features/reconciliation/failed-proposal-label.ts` (+ `.test.ts`)
+- `frontend/src/lib/shared/i18n-keys.test.ts`, `frontend/src/lib/shared/i18n-un-repli-par-cle.test.ts`
+- `docs/api-external.md`, `docs/manual/fr/{user-manual,admin-manual}.{tex,pdf}`, `README.md`, `CHANGELOG.md`
+- `_bmad-output/implementation-artifacts/epic-15-choix-autonomes.md` (C-15-6b-1, C-15-6b-2)
+
 ## Change Log
 
 - 2026-10-08 — Spécification initiale (bmad-create-story, en autonomie). Statut `ready-for-dev`.
@@ -1210,3 +1392,99 @@ deux cas de l'AC7 (non compté : conditionnel).
   - Décompte après passe : **13 AC (AC1–AC12 et AC3 bis), 10 tâches (T0–T9), 23 tests** (19 backend
     dont 10 bis, 10 ter et 16 bis, 4 fichiers Vitest ; 22 neufs, 1 existant renommé et étendu) —
     inchangé (le test 18 gagne un cas, sans test neuf). Statut : `ready-for-dev`.
+- 2026-10-09 — **T0 — relecture contre `39b52628`** (`origin/main`, qui porte la 15-6a, les
+  15-5a à 15-5e et la 15-11b ; agent de développement Opus 5.5). **Aucun écart de fond** : aucune
+  règle ni aucun AC ne change. Relevés, numéros relocalisés par le texte :
+  - `settle_invoice` (`invoice_settlements_write.rs:48`) : créance lue par le lecteur de la 15-6a
+    (`:104-107`) **avant** la contrepartie ; contrepartie `:110-172`, dont le refus
+    `ACCOUNT_NOT_POSTABLE` de la 15-5a au **bloc du compte interne** (`:161-170`) ; trop-perçu
+    `:178-186` ; compte d'arrondi du règlement `:189-199`. Ordre **contrepartie → trop-perçu →
+    arrondi** : celui de l'AC3 bis.
+  - `write_off_invoice` (`:359`) : nature `:436-437`, **puis** créance `:438-441`, quote-parts de TVA
+    (aucun refus métier), reste d'arrondi `:476-489` (non relu pour la nature `rounding`, `:476-477`),
+    TVA due `:491-495`. Ordre **nature → reste d'arrondi → TVA due** : celui de l'AC3 bis. Le
+    commentaire « 5 bis » est celui que la 15-5e a réécrit (`:459-475`).
+  - `pay_in_tx` (`supplier_invoices.rs:683`) : dette et TTC `:711-722` (requête à extraire, AC4),
+    contrepartie `:725-797`, refus `ACCOUNT_NOT_POSTABLE` au bloc du compte interne (`:779-788`) ;
+    commentaire « jumeau exact » `:752-766`.
+  - Lots (`payment_batches.rs`) : `create_batch` `:68`, compte bancaire source `:84-103`, appel
+    `validate_invoice_for_batch` `:114` ; `validate_invoice_for_batch` `:226`, `fn fail` `:235-241`,
+    `SELECT` `:251-253` ; `confirm_batch` `:304`, boucle `pay_in_tx` `:359-370` ; `cancel_batch`
+    `:431`.
+  - `accept_one_invoice` (`reconciliation.rs:1226`) : refus du score (7bis) `:1402-1411` ; compte
+    de banque (a) `:1435-1463` ; créance (b) `:1474-1494` ; trop-perçu (c) `:1504-1525` ; arrondi
+    (c-bis) `:1528-1557`. Le commentaire de classement de la 15-5b est au **doc-comment** de la
+    fonction (`:1216-1224`, « aucun compte de cette écriture ne vient du client ») : c'est lui que
+    l'AC5 amende.
+  - Routes du règlement (`invoices::settle`), du solde (`invoices::write_off`), du paiement
+    fournisseur (`supplier_invoices::pay`) et de la confirmation d'un lot (`payment_batches::confirm`)
+    : rejouées par `retry_on_deadlock` (15-5e) — rejeu limité au 1213, un refus métier n'est jamais
+    rejoué.
+  - **15-5c mergée** : `failed-proposal-label.ts` existe (AC7 s'applique, clés `reconciliation-failed-*`) ;
+    son JSDoc et son test parlent de « 26 codes » (25 littéraux + `ACCOUNT_NOT_POSTABLE`) — le code
+    neuf, posé par `DbError::error_code()` comme `ACCOUNT_NOT_POSTABLE`, les porte à **27**.
+  - Borne `sitesTotal` : **1915** sur `HEAD` (`i18n-keys.test.ts:496`) ; **+6** attendus (15-5c
+    mergée).
+  - Écrans : `SettleInvoiceDialog.svelte` — effet de réinitialisation `:82-91`, `selectableAccounts`
+    `:105`, menu des comptes bancaires `:206-208` ; fiche fournisseur — filtres `:81-82`
+    (`journalAccountId !== null`, `active && postable`).
+  - Manuels : `user-manual.tex` § règlement client `:1124-1128` (« tout autre compte » `:1127`),
+    *Solder le reste* `:1143`, « contrepartie libre » `:1402`, pain.001 `:1444`, puce *Accepter*
+    `:1629`, balance âgée `:1861` ; `admin-manual.tex` `:2153`, `:2155`, `:2159`.
+  - Choix C36, C54, C55 présents au registre de la branche ; prochain numéro propre :
+    `C-15-6b-1`.
+- 2026-10-09 — **Développement** (Opus 5.5, en autonomie). T0 (sans écart de fond) ; T1 à T8 selon la
+  fiche ; commits `fc50312c` (serveur), `77930445` (écrans et libellés), `2a3ede61`
+  (documentation). Choix **C-15-6b-1** (`refuse_if_claim_account`) et **C-15-6b-2**
+  (`GapAccountRole`). Écarts à la fiche, tous dits au Dev Agent Record : borne `CLES_RELEVEES`
+  de `i18n-un-repli-par-cle.test.ts` relevée (210 → 213) ; `README.md` corrigé (« tout autre
+  compte ») ; « Refus : » de l'annulation fournisseur libellé « Refus de l'annulation : » dans
+  `api-external.md` ; deux tests backend de plus que la fiche (nature `rounding`, TVA due) ;
+  doublure `SettleInvoiceDialogHost.test.svelte` pour le test 18. Gates : backend 2958/2958,
+  frontend 1110/1110 + build, E2E 247 passés / 9 attendus. Statut : `review`.
+- 2026-10-09 — **Revue de code P1** (Sonnet ×3, lentilles B, E et A ; prompt
+  `15-6b-review-prompt-p1.md`) : **0 CRITICAL, 0 HIGH, 0 MEDIUM, 20 LOW** (B 6, E 4, A 10 ; recoupements
+  L4 = E3, B-2 = E2). Remédiation **sans aucune ligne de code exécutable** (choix **C-15-6b-3**) :
+  - **Fiche** : tâches T0 à T9 cochées (L1) ; ligne du `sprint-status` réécrite (L2) ; AC1 et
+    décompte amendés — `GapAccountRole`, et non `DesignatedRole` (L3, C-15-6b-2) ; angles morts du
+    plan comptable non chargé (E4) et des deux branches d'erreur infra non exercées (B-5).
+  - **Tests ajoutés** (de `67775634` — `1fd9351c` après rebase — au commit de remédiation, recomptés aux deux bornes) : backend **4** —
+    `payment_batches_repository` 13 → 14 (`confirm_batch_rolls_back_the_invoices_settled_before_the_refused_one`,
+    L4 = E3 ; mutation `tx.rollback()` → `tx.commit()` dans la branche d'échec de `confirm_batch`
+    **constatée rouge**, le test 15 à une facture restant vert sous la même mutation),
+    `supplier_settlement_cancel_e2e` 4 → 7 (`POST …/pay`, `POST /payment-batches`,
+    `POST /payment-batches/{id}/confirm` par HTTP, L5) ; frontend **4** — `SettleInvoiceDialog`
+    12 → 15 (1100 non imputable, L6 ; réouverture et choix survivant, L7, par la doublure qui gagne
+    un bouton `host-toggle-open`), `supplier-settlement-page` 16 → 17 (2000 non imputable, L6).
+    Mutations constatées rouges puis sources restaurées et `touch`ées : ids calculés après le
+    filtre `active && postable` (les deux tests L6) ; `bankAccountId = null` retiré de l'effet de
+    réinitialisation (le test de réouverture).
+  - **Commentaires et doc-comments** : `supplier_invoices.rs` (`pay_in_tx`), la mention de la 15-6b
+    sortie du paragraphe qu'elle coupait, et le numéro de ligne périmé remplacé par un nom (L9) ;
+    `validate_invoice_for_batch` — garde de création **consultative**, compte bancaire lu sans
+    verrou (B-3) ; `claim_account_refusal_details` — ce sont les clés qui sont construites une
+    fois, pas l'extraction (B-6).
+  - **i18n** : `it-CH` `error-settlement-counterparty-is-payable-in-batch` à l'infinitif, comme les
+    autres clés neuves (L8).
+  - **Manuel** : la condition du filtre par rôle écrite aux deux sections de règlement (L10).
+  - **E1** : vérifié — la fiche 15-6d couvre `post_manual` et `accept_one_rule` (16 mentions) ;
+    rien à rendre à l'orchestrateur.
+  - **Dette écrite, non corrigée** (code exécutable, C-15-6b-3) : **B-1** — « le seul compte lié »
+    est faux quand plusieurs comptes bancaires sont écartés (quatre locales **et** replis
+    `i18nMsg` des deux écrans) ; **B-2 = E2** — le message HTTP du rôle `counterparty` ne dit pas
+    « reliez le compte bancaire » quand la contrepartie vient d'un virement, et `details` ne porte
+    pas `bankAccountId` hors rapprochement et lot (mapping et repli Rust) ; **B-4** — apostrophe
+    droite de `payment-batches-failed-purchase-entry-malformed` (repli TypeScript ; majorité du
+    catalogue `fr-CH` à l'apostrophe droite) ; **B-6** — deux `match` d'extraction du refus, à
+    remplacer par une méthode sur `DbError`.
+  - Grep du symptôme : « ne le propose pas » (deux sites, les deux traités), « Collega » dans les
+    clés neuves (un site), `DesignatedRole` dans la fiche (amendements aux deux sites de
+    définition ; les mentions historiques du Change Log restent).
+- 2026-10-09 — **Revue de code P1 close** (Sonnet ×3, lentilles B, E et A) : **0 au-dessus de
+  LOW, 20 LOW** ; remédiation sans code exécutable (commit `829537fb` après rebase), quatre LOW
+  écrits en dette (C-15-6b-3). Trend : P1 0 C / 0 H / 0 M → boucle close, la remédiation ne
+  touchant aucune ligne de production (`git diff -U0` sur `crates/*/src` : commentaires seuls ;
+  frontend : fichiers `.test.*` seuls). Rebasée sur `origin/main` `012fc430` (15-12a) ; gates
+  complets sur l'état rebasé : backend 2984/2984, Vitest 1118/1118 + build, E2E 247 passés /
+  9 attendus. Statut : **`done`**. Puis rebasée sur `200f5e79` (15-7a2, mergée pendant les
+  gates) : backend 3006/3006, Vitest 1118/1118 + build, E2E 247 passés / 9 attendus.
diff --git a/_bmad-output/implementation-artifacts/15-6b-review-prompt-p1.md b/_bmad-output/implementation-artifacts/15-6b-review-prompt-p1.md
new file mode 100644
index 000000000..e02dba9e2
--- /dev/null
+++ b/_bmad-output/implementation-artifacts/15-6b-review-prompt-p1.md
@@ -0,0 +1,37 @@
+# Prompt — revue de code P1, Story 15-6b
+
+*Versionné le 2026-10-09. Trois lentilles (Sonnet), contexte frais chacune, en lecture seule (bmad-code-review :
+Blind Hunter, Edge Case Hunter, Acceptance Auditor). Rotation D6 : passes complètes Sonnet ↔ Opus ; Haiku en passe ciblée.*
+
+Worktree `/home/gcorbaz/devel/kesh-15-6b`, branche `story/15-6b-contrepartie-distincte-de-la-creance`. **Le diff à revoir** : `git -C /home/gcorbaz/devel/kesh-15-6b diff 39b52628..1b006a89` (un seul diff aplati ; le code,
+les tests, les manuels, la doc — les fiches `_bmad-output/` sont le contexte, pas l'objet). **Fiche** :
+`_bmad-output/implementation-artifacts/15-6b-contrepartie-distincte-de-la-creance.md` (AC, tâches, Dev Agent Record, Change Log). Issues (par
+`gh api repos/guycorbaz/kesh/issues/N`) : #474. Registre : `epic-15-choix-autonomes.md`. Règles : `CLAUDE.md`. Choix C-15-6-*, C-15-6b-1, C-15-6b-2. Code touché : variante SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT (400), helper refuse_if_claim_account, gardes sur règlement client, solde du reste, règlement fournisseur (purchase_payable_line), création et confirmation des lots, rapprochement ; GapAccountRole ; écrans (account-options.ts, dialogue de règlement, fiche fournisseur, libellés failed[]) ; i18n 4 locales ; manuels et PDF, README, api-external, CHANGELOG. Axes : l'ensemble clos des chemins qui écrivent une contrepartie de règlement — en manque-t-il un (inventaire des sites NON gardés, `grep -rn` sur les écrivains de `invoice_settlements` et de règlements fournisseur) ? ; le refus dans les lots suit-il le patron FailedProposal per-proposal (CLAUDE.md) ? ; ordre du refus parmi les autres refus de ces flux ; lecture sous verrou ou non ; la doublure SettleInvoiceDialogHost.test.svelte ne masque-t-elle pas un défaut du composant ? ; la borne CLES_RELEVEES 210→213 ; manuel et PDF aplati.
+
+## Lentilles
+
+- **B — Blind Hunter** : le diff seul, sans la fiche. Défauts de correction, régressions, erreurs de concurrence
+  (verrous, REPEATABLE READ, ordre d'acquisition), erreurs rendues au client, tests qui passeraient à vide (un test qui
+  ne mord pas sur la mutation qu'il prétend couvrir), code mort, duplication (DRY), doc-comments devenus faux.
+- **E — Edge Case Hunter** : chaque branche et chaque borne du code modifié — entrées vides, nulles, multiples, en
+  doublon, d'une autre société, archivées ; chemins par clé d'API ; lots partiellement en échec ; locales ; et les
+  **chemins NON modifiés qui devraient l'être** (inventorier les sites non résolus de la même famille par `grep`).
+- **A — Acceptance Auditor** : chaque AC de la fiche contre le code ET les tests (un AC sans test qui le prouve est
+  un finding) ; le Dev Agent Record ne déclare-t-il que ce qui a tourné (chiffres recomptés : `grep -c '#\[sqlx::test\]\|#\[test\]\|#\[tokio::test\]'` aux deux bornes) ;
+  le **manuel** (`docs/manual/fr/*.tex` **et PDF aplatis** : `pdftotext -nopgbrk f.pdf - | tr '\n' ' ' | tr -s ' '` vers
+  `target/gate-logs/`, ligatures ff/fi/fl normalisées), `docs/api-external.md`, CHANGELOG, i18n 4 locales.
+
+## Ce que tu rends
+
+Rapport complet dans `target/gate-logs/15-6b-review-p1-<B|E|A>.md` : findings numérotés, sévérité
+(CRITICAL/HIGH/MEDIUM/LOW), `fichier:ligne`, **preuve** (sortie de `grep -nF` pour toute affirmation de présence ou
+d'absence ; code cité relu), correction proposée ; ⛔ **axes exercés ET non exercés**. Dernier message : le chemin, le
+bilan par sévérité, une ligne par MEDIUM+.
+
+## Interdits
+
+⛔ N'écris aucun fichier hors `target/gate-logs/`. Aucune commande qui écrit dans le dépôt ou dans une base, ni
+aucune commande qui compile ou exécute des tests : `scripts/*` (dont `scripts/prepare-release.sh`), `make`,
+`latexmk`, `git commit`/`add`/`checkout`/`stash`/`apply`, `sqlx`, `cargo`, `npm`, `npx`,
+`gh issue create`/`comment`/`edit`, SQL d'écriture. Autorisés : lecture, `grep`, `sed -n`, `git log`/`show`/`diff`,
+`gh api` en lecture, `pdftotext` vers `target/gate-logs/`.
diff --git a/_bmad-output/implementation-artifacts/epic-15-choix-autonomes.md b/_bmad-output/implementation-artifacts/epic-15-choix-autonomes.md
index 54abfdeb5..4e153804a 100644
--- a/_bmad-output/implementation-artifacts/epic-15-choix-autonomes.md
+++ b/_bmad-output/implementation-artifacts/epic-15-choix-autonomes.md
@@ -5028,3 +5028,58 @@ l'import (#458–#461).
 - **Retenu** : rebase sur `de285ea8`. Deux conflits seulement : `admin-manual.pdf` (binaire — pris de `main` pendant le rebase puis **régénéré** sur le `.tex` fusionné sans conflit par git, contrôlé aplati : « 104 des 112 routes », « 104 + 6 + 2 = 112 », la réserve OLICo réécrite et les apports de la 15-11b sur `.env` sont tous présents) et ce registre (union, les entrées C-15-11b avant les C-15-7a2). `CHANGELOG.md` et `sprint-status.yaml` fusionnés sans conflit ; `last_updated` (27) pris après le (26) de `main`. Aucun conflit de code : `routes/onboarding.rs` passe déjà par `config::env_nonempty` (15-11b) et le test (L) est vert. **Partition du registre recomptée depuis `LIB_ROUTES`** (et non relue) : 112 routes = 104 `Traced` + 6 `Exempt` + 2 `NoMatter` ; colonne `Rejeu` sur les 115 entrées : 22 rejouées + 4 exemptées + 89 sans écriture — inchangée par le rebase (`main` n'a pas touché `audit_route_registry.rs`), le manuel reste juste. Gates complets rejoués sur l'état rebasé (backend, frontend, E2E).
 - **Écartées** : merge de `main` dans la branche (historique moins lisible) ; garder l'un des deux PDF (il aurait omis l'apport de l'autre).
 - **Réversible** : oui (rebase ; branche poussée, sans PR).
+
+
+## C-15-6b-1 — 15-6b : une garde d'un tenant, `refuse_if_claim_account`, au-dessus des deux fonctions de la fiche
+
+- **Contexte** : l'AC1 sépare la comparaison pure (`ensure_not_claim_account`) de la construction
+  du refus (`claim_account_refusal`, numéro lu à l'échec) et veut que chaque site appelle l'une
+  puis, sur `Err` seulement, l'autre. Neuf sites (règlement : contrepartie et arrondi ; solde :
+  nature, reste d'arrondi, TVA due ; règlement fournisseur ; création d'un lot ; rapprochement :
+  banque et arrondi) auraient chacun écrit le même `match` de quatre lignes.
+- **Retenu** : une troisième fonction publique, `invoice_settlements::refuse_if_claim_account`,
+  qui fait exactement les deux gestes dans cet ordre et rend `Result<(), DbError>`. Les sites
+  l'appellent ; le rapprochement et la création de lot convertissent son `Err` (refus → item
+  `failed[]`, toute autre erreur → `DATABASE_ERROR` / propagation). Les deux fonctions de la fiche
+  restent publiques — la 15-6d emprunte la comparaison pure.
+- **Écarté** : le `match` recopié site par site (DRY, et un site qui oublierait la lecture à
+  l'échec seulement).
+- **Réversibilité** : totale (une fonction d'enrobage).
+
+## C-15-6b-2 — 15-6b : `GapAccountRole` au lieu du `DesignatedRole` de la fiche
+
+- **Contexte** : la fiche (AC1, signature indicative) nomme `DesignatedRole` le sous-ensemble
+  `{ Rounding, WriteOffNature, VatPayable }`. Un `DesignatedRole` existe déjà dans
+  `company_invoice_settings.rs` (Story 15-5d) : les quatre **champs** que la validation et la
+  saisie fournisseur écrivent (`Receivable`, `VatPayable`, `Payable`, `VatRecoverable`) — un autre
+  ensemble, au sens voisin. Deux types homonymes dans `kesh_db::repositories`, dont un
+  `VatPayable` de chaque côté, inviteraient à l'import du mauvais.
+- **Retenu** : `invoice_settlements::GapAccountRole` (« compte d'écart », le vocabulaire de la
+  fiche : « comptes d'écart du même geste »), dans le même fichier et au même usage que la fiche
+  décrit (`ClaimSubject::Designated(GapAccountRole)`). Le doc-comment dit pourquoi.
+- **Écarté** : garder l'homonyme (confusion à l'import) ; renommer celui de la 15-5d (hors
+  périmètre, 26 occurrences).
+- **Réversibilité** : totale (renommage).
+
+## C-15-6b-3 — 15-6b : les LOW de la revue P1 qui exigent du code exécutable sont écrits en dette, pas corrigés
+
+- **Contexte** : la revue de code P1 (Sonnet ×3) rend 0 au-dessus de LOW et 20 LOW. La consigne de
+  clôture borne la remédiation aux lignes non exécutables (tests, doc-comments, commentaires,
+  `.ftl`, fiche, manuel). Quatre LOW ne se corrigent qu'en touchant du code de production :
+  B-1 (« le seul compte lié » faux quand plusieurs comptes bancaires sont écartés — le texte vit
+  aussi dans les replis `i18nMsg` de `SettleInvoiceDialog.svelte` et de la fiche fournisseur, et
+  dans deux tests qui le comparent au repli) ; B-2 = E2 (remède du message HTTP quand la
+  contrepartie vient d'un compte bancaire : il faudrait porter `bankAccountId` jusqu'au mapping, ou
+  retoucher le repli Rust `format!` avec la clé) ; B-4 (apostrophe droite de
+  `payment-batches-failed-purchase-entry-malformed`, dont le repli est dans
+  `payment-batch-helpers.ts`) ; B-6 (DRY : deux `match` d'extraction des champs du refus).
+- **Retenu** : les quatre écrits comme dette au Change Log de la fiche, sans modifier le seul
+  catalogue — corriger le `.ftl` sans le repli ferait diverger le texte affiché selon que la clé
+  est chargée ou non, défaut pire que celui qu'on corrige. B-4 est de plus discutable sur le fond :
+  le catalogue `fr-CH` écrit l'apostrophe droite sur 316 lignes et la typographique sur 70 ; la
+  clé neuve suit la majorité. Le doc-comment de `claim_account_refusal_details` dit désormais que
+  seules les clés sont construites une fois, pas l'extraction (B-6).
+- **Écarté** : corriger les replis malgré la consigne (elle est explicite) ; corriger le `.ftl`
+  seul (divergence repli/catalogue).
+- **Réversibilité** : totale ; la dette se solde dans une story de rattrapage i18n ou dans la
+  15-6c, qui retouche les écrans de liaison bancaire.
diff --git a/_bmad-output/implementation-artifacts/sprint-status.yaml b/_bmad-output/implementation-artifacts/sprint-status.yaml
index 51a60c9cf..0d2566f76 100644
--- a/_bmad-output/implementation-artifacts/sprint-status.yaml
+++ b/_bmad-output/implementation-artifacts/sprint-status.yaml
@@ -1,3 +1,4 @@
+# last_updated: 2026-10-09 (36) (15-6b done — revue de code P1 close, 0 au-dessus de LOW ; rebasée sur 200f5e79 (15-7a2) ; gates sur l'état rebasé 3006/3006, Vitest 1118/1118, E2E 247 / 7 KF-029 + 2 KF-045 ; choix C-15-6b-3)
 # last_updated: 2026-10-09 (35) (15-7a2 intégrée sur 012fc430 (15-6a, 15-12a) — CHANGELOG, fiscal_years.rs et doc du registre par union ; partition 104/6/2 inchangée ; gates sur l'état rebasé : backend 2973/2973, Vitest 1095/1095, E2E 247 / 7 KF-029 + 2 KF-045)
 # last_updated: 2026-10-09 (34) (renuméroté au rebase sur 012fc430, (27) sur de285ea8) (15-7a2 done — rebasée sur de285ea8 (15-11b) ; revue de code close : P1 Sonnet ×3 2 MEDIUM / 10 LOW → P2 ciblée Haiku 0 ; gates sur l'état rebasé : backend 2934/2934, Vitest 1091/1091, E2E 247 / 7 KF-029 + 2 KF-045 avant 12:00 UTC ; choix C-15-7a2-5)
 # last_updated: 2026-10-09 (33) (15-12a intégrée sur 39b52628 (15-6a) — conflit de code rejeu_interblocage_e2e.rs : deux ajouts gardés ; gates sur l'état rebasé : backend 2951/2951, Vitest 1095/1095, E2E 245 / 7 KF-029 + 2 KF-045)
@@ -348,8 +349,8 @@ development_status:
   15-5e1-socle-rejeu: done  # 2026-10-08 REVUE DE CODE CLOSE (P1 Sonnet ×3 : 3 MEDIUM, 9 LOW, remédiés en 1dc41152 → P2 ciblée Haiku : 0, vérifiée par l'orchestrateur). DEV FAITE (gate backend 2793/2793, 4 ignorés ; frontend 979/979 ; E2E 240 passés / 7 KF-029 attendus ; R3-7 mesurée VRAIE sur 10.11.16 — issue à ouvrir ; dix mutations rouges ; choix C-15-5e1-1..3). — VALIDATION CLOSE (P7 ciblée Haiku : 0, vérifiée par l'orchestrateur). closes #463 #491, refs #536 #429. DÉPEND de 15-5a ET 15-5b (mergées, f289414e) ; passe AVANT 15-5e2 et 15-5d. Story-zéro (C61) : inventaire fermé des routes qui écrivent au journal (21 + 4 exemptées) gravé dans une seconde colonne d'audit_route_registry.rs (statut transitoire ARejouer, partition 8/13/4/90 = 115 ; volet (c) par analyse syn du corps du handler — C63, C70) ; enveloppes nommées kesh_db::retry::retry_on_deadlock et kesh_api::retry::retry_app_on_deadlock / is_app_deadlock, nom d'opération en champ du warn! de retry_with (C62) ; règlement client (#491), annulation de règlement (#463), validation (#536) et saisie fournisseur (C66) rejoués, tests « route victime » sur une vraie 1213 (tests 2-5) + test du prédicat et de l'enveloppe AppError (test 1), registre (test 6) ; doc-comments canoniques de validate_invoice et de supplier_invoices::create_in_tx, avance des réglages de la saisie fournisseur (R3-7 hypothèse forte, mesurée en T0 — C70) ; enregistrement des réglages de facturation rejoué (test 7, SansEcritureAuJournal au registre — C70), « 5 bis », module retry.rs (ce que la 15-5d attend — C65, C66) ; CHANGELOG Corrigé + Modifié (C64, C69). Dérogation de découpage : 11 modules, signal D5 déclaré (C67, révisé par C70). 7 AC, 6 tâches, 7 tests. Validation : P4 Opus ×2 (3 MEDIUM, 19 LOW) remédiée ; P5 Sonnet ×2 (1 MEDIUM — recyclage du volet (c), signal D5, changement de méthode —, 11 LOW) remédiée ; P6 Opus ×2 (1 MEDIUM — F6-1, le test 7 pouvait passer sans rejeu hors MariaDB 10.11, recyclage de la remédiation P5, signal D5 —, 10 LOW distincts) remédiée : témoin du rejeu (warn! de kesh_db::retry capté) aux tests 2-5 et 7, cycle du test 7 formé en T0 (C74) ; EN VALIDATION : passe ciblée P7 (Haiku) à lancer sur la remédiation P6.
   15-5e2-rejeu-des-autres-flux: done  # 2026-10-08 DÉVELOPPÉE (commit 6125d50b, sur ec675288 qui porte la 15-8b) : 12 routes rejouées (9 DbError, 3 AppError « une tentative »), 6 sites retry_with migrés, post_accept seul en retry_with ; registre 22/0/4/89, volet (c bis) ; test 8 (post_manual victime) vert, cycle formé en T0 sur 10.11.16 ; commentaires d'ordre, Pattern 5, api-external § 10, CHANGELOG, manuels #484 ; gates au commit de code — backend 2837/2837 (4 ignorés), frontend 1086/1086, E2E 246 / 7 KF-029 + 1 pollution (sidebar :75 vert seul) ; choix C-15-5e2-1..6. Revue de code à lancer (lentille adversariale sur les trois extractions). Avant : — closes #536 #484, refs #463 #491. DÉPEND de 15-5e1 ; ordre libre avec 15-5d, sûr aussi pour la documentation (C65, C68). Rollout (C61) : les 17 autres routes Rejouee (13 à rejouer — 10 DbError, 3 AppError —, 3 sites retry_with migrés vers les enveloppes, post_accept inchangée ; la saisie fournisseur est passée à la 15-5e1, C66), revue fichier par fichier + lentille adversariale sur les trois extractions ; registre sans ARejouer (21/4/90), retry_with restreint à post_accept ; mentions retry_with d'opening_complement.rs (C69) ; commentaires d'ordre restants (journal_entries étapes 0 et 0-bis, accept_one_rule, accept_one_split, post_manual, post_split, fiscal_years.rs:489-502), inventaire au symptôme insensible à la casse (205 lignes / 42 fichiers sur f289414e) ; Pattern 5 (lignes par renvoi aux doc-comments canoniques, ordre du lot, Required et When to Use réécrits) ; api-external § 10 ; CHANGELOG (texte final complet) ; manuels #484 (SERIALIZABLE, innodb_deadlock_detect), make admin user, brochure non commitée (C64). 6 AC, 6 tâches. Validation : P4 Opus ×2 (5 MEDIUM dont 4 distincts et d'origine, signal D5 déclaré, pas de découpage ; 15 LOW) remédiée ; P5 Sonnet ×2 (0 au-dessus de LOW, 9 LOW) remédiée — VALIDATION CLOSE (trend P1 1 HIGH/6 MED → P2 6 MED → P3 2 MED → découpage → P4 5 MED → P5 0) ; développement après le merge de la 15-5e1.
   15-6-creance-juste-avoir-reglement: split  # 2026-10-08 SPÉCIFIÉE et DÉCOUPÉE d'emblée (règle de splitting, plus de cinq modules — choix C-15-6-1) en 15-6a + 15-6b + 15-6c ; 15-6d ajoutée à la validation P1 (C-15-6-9). Fiche d'index. #473, #474, #523, #524 (P1)
-  15-6a-avoir-credite-la-creance-de-la-vente: done  # 2026-10-09 REVUE DE CODE P1 CLOSE (Sonnet ×3 : 0 > LOW, 14 LOW ; remédiation 3a7bddcc sans code de production, B-3 en dette — C-15-6a-4) ; rebasée sur ec745d0c, gates sur l'état rebasé : backend 2906/2906, Vitest 1091/1091, E2E 245 / 7 KF-029 + 2 invoices.spec.ts (heure UTC, hors branche). Avant : 2026-10-09 DÉVELOPPÉE (commits 55143ec0 code et tests, ef1e7b47 docs) — 16 tests neufs, 2 modifiés (9, 13), 11 rouges d'abord, 4 mutations rouges ; gates au commit de code : backend 2895/2895, Vitest 1091/1091, E2E 247 / 7 KF-029 ; choix C-15-6a-2, C-15-6a-3. Revue de code à lancer. Avant : DÉVELOPPEMENT REPRIS après le merge de la 15-5d (5e4bec50), T0 confirmé au code mergé (C-15-6a-2). Avant : 2026-10-08 T0 FAIT (alignement sur le livré, C-15-6a-1) — EN ATTENTE du merge de la 15-5d (dépendance ferme : helper lock_designated_accounts_in_tx et test de C35 sur sa branche seule) ; aucun écart de règle métier. Avant : 2026-10-08 — closes #473, closes #523. Créance ET arrondi lus sur l'écriture de vente (lecteurs partagés ; compte archivé → INACTIVE_OR_INVALID_ACCOUNTS, test :846 modifié délibérément) ; P2 : comptes de la vente verrouillés, archivé → ACCOUNT_ARCHIVED nommé (C-15-6-16) ; TVA due en angle mort tracé #525 (C-15-6-8) ; P3 : verrou LOCK IN SHARE MODE avant l'exercice (C-15-6-24), variante CreditNoteAccountsArchived, code ACCOUNT_ARCHIVED, libellé « Impossible d'émettre l'avoir » (C-15-6-25), signal D5 déclaré. P4 : verrou partagé étendu à tous les comptes écrits (TVA due, produits), rejeu retry_with de POST /credit-notes, cycle avoir ↔ rapprochement tracé #536, ligne absente → Invariant (C-15-6-29). P5 : APRÈS 15-5a à 15-5e ; rejeu de la route porté par la 15-5e (C54), verrou gardé pour la course de lecture seule, aucun réordonnancement, cycles nommés ; helper de verrou de liste partagé avec 15-5d ; TVA à source unique (C-15-6-32). Validations P1 à P5 appliquées ; P6 complète à lancer.
-  15-6b-contrepartie-distincte-de-la-creance: ready-for-dev  # 2026-10-08 — refs #474. DÉPEND de 15-6a ; de préférence après 15-5c (#492, C-15-6-12). Refus SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT : règlement client/fournisseur, deux modes, rapprochement (failed[]), lots de paiement à la création et à la confirmation (C-15-6-10) ; lecteur sœur fournisseur (C-15-6-11) ; P2 : comptes d'écart comparés à la créance (C-15-6-18), lot bloqué contextualisé (C-15-6-19), signal D5 déclaré sans découpage (C-15-6-20) ; P3 : details.role et clé distincte pour le compte désigné, helper commun emprunté par 15-6d (C-15-6-26), signal D5 déclaré ; P4 : rôle rounding du compte d'arrondi quel que soit le geste, validation et avoir en angles morts (#537, #525), message de liste vide conditionné, « un administrateur doit » (C-15-6-30), signal D5 déclaré (recyclage de F1, pas de découpage). P5 : APRÈS 15-5a à 15-5e ; trois clés plates, chaque comparaison suit sa lecture, critère de T2 par nom sur liste fermée, sitesTotal relevé, user-manual :1754 (C-15-6-33) ; signal D5 levé, non déclenché. Validations P1 à P5 appliquées ; P6 complète à lancer.
+  15-6a-avoir-credite-la-creance-de-la-vente: done  # 2026-10-09 REVUE DE CODE P1 CLOSE (Sonnet ×3 : 0 > LOW, 14 LOW ; remédiation 3a7bddcc sans code de production, B-3 en dette — C-15-6a-4) ; rebasée sur ec745d0c, gates sur l'état rebasé : backend 2906/2906, Vitest 1091/1091, E2E 245 / 7 KF-029 + 2 invoices.spec.ts (heure UTC, hors branche). Avant : 2026-10-09 DÉVELOPPÉE (commits 55143ec0 code et tests, ef1e7b47 docs) — 16 tests neufs, 2 modifiés (9, 13), 11 rouges d'abord, 4 mutations rouges ; gates au commit de code : backend 2895/2895, Vitest 1091/1091, E2E 247 / 7 KF-029 ; choix C-15-6a-2, C-15-6a-3. Revue de code à lancer. Avant : DÉVELOPPEMENT REPRIS après le merge de la 15-5d (5e4bec50), T0 confirmé au code mergé (C-15-6a-2). Avant : 2026-10-08 T0 FAIT (alignement sur le livré, C-15-6a-1) — EN ATTENTE du merge de la 15-5d (dépendance ferme : helper lock_designated_accounts_in_tx et test de C35 sur sa branche seule) ; aucun écart de règle métier. Avant : 2026-10-08 — closes #473, closes #523. Créance ET arrondi lus sur l'écriture de vente (lecteurs partagés ; compte archivé → INACTIVE_OR_INVALID_ACCOUNTS, test :846 modifié délibérément) ; P2 : comptes de la vente verrouillés, archivé → ACCOUNT_ARCHIVED nommé (C-15-6-16) ; TVA due en angle mort tracé #525 (C-15-6-8) ; P3 : verrou LOCK IN SHARE MODE avant l'exercice (C-15-6-24), variante CreditNoteAccountsArchived, code ACCOUNT_ARCHIVED, libellé « Impossible d'émettre l'avoir » (C-15-6-25), signal D5 déclaré. P4 : verrou partagé étendu à tous les comptes écrits (TVA due, produits), rejeu retry_with de POST /credit-notes, cycle avoir ↔ rapprochement tracé #536, ligne absente → Invariant (C-15-6-29). P5 : APRÈS 15-5a à 15-5e ; rejeu de la route porté par la 15-5e (C54), verrou gardé pour la course de lecture seule, aucun réordonnancement, cycles nommés ; helper de verrou de liste partagé avec 15-5d ; TVA à source unique (C-15-6-32). Validations P1 à P6 appliquées — VALIDATION CLOSE (C-15-6-34).
+  15-6b-contrepartie-distincte-de-la-creance: done  # 2026-10-09 DONE : revue de code P1 close (Sonnet ×3 : 0 au-dessus de LOW, 20 LOW ; remédiation sans code exécutable, B-1/B-2/B-4/B-6 en dette, C-15-6b-3) ; rebasée sur 200f5e79 (15-7a2) ; gates sur l'état rebasé : backend 3006/3006, Vitest 1118/1118, E2E 247 / 7 KF-029 + 2 KF-045. — DÉVELOPPÉE (fc50312c, 77930445, docs 2a3ede61) : gate backend 2958/2958, frontend 1110/1110, E2E 247 passés / 9 attendus (KF-029, KF-045 avant midi) ; choix C-15-6b-1, C-15-6b-2. — 2026-10-08 — refs #474. DÉPEND de 15-6a ; de préférence après 15-5c (#492, C-15-6-12). Refus SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT : règlement client/fournisseur, deux modes, rapprochement (failed[]), lots de paiement à la création et à la confirmation (C-15-6-10) ; lecteur sœur fournisseur (C-15-6-11) ; P2 : comptes d'écart comparés à la créance (C-15-6-18), lot bloqué contextualisé (C-15-6-19), signal D5 déclaré sans découpage (C-15-6-20) ; P3 : details.role et clé distincte pour le compte désigné, helper commun emprunté par 15-6d (C-15-6-26), signal D5 déclaré ; P4 : rôle rounding du compte d'arrondi quel que soit le geste, validation et avoir en angles morts (#537, #525), message de liste vide conditionné, « un administrateur doit » (C-15-6-30), signal D5 déclaré (recyclage de F1, pas de découpage). P5 : APRÈS 15-5a à 15-5e ; trois clés plates, chaque comparaison suit sa lecture, critère de T2 par nom sur liste fermée, sitesTotal relevé, user-manual :1754 (C-15-6-33) ; signal D5 levé, non déclenché. Validations P1 à P6 appliquées — VALIDATION CLOSE (C-15-6-34).
   15-6c-configuration-sans-ecriture-nulle: ready-for-dev  # 2026-10-08 — closes #474. APRÈS le merge de 15-5b et de 15-6b. Compte bancaire ≠ débiteurs/créanciers, et réciproquement ; exemption « inchangé » ; contrôles dans la transaction, deux gestes sérialisés (C-15-6-13) ; écrans filtrés sur les réglages (C-15-6-14) ; P2 : LOCK IN SHARE MODE, 409 avant le refus des réglages (C-15-6-21), tests étendus de 15-5b, APRÈS 15-5d aussi (C-15-6-22), signal D5 déclaré sans découpage ; P3 : test 12 bis du FOR UPDATE de before, attentes prouvées, pas de verrou pour une dé-liaison (C-15-6-27). Validations P1, P2 et P3 appliquées ; P4 ciblée (Haiku) : 0, vérifié — VALIDATION CLOSE.
   15-6d-contrepartie-distincte-de-la-banque: ready-for-dev  # 2026-10-08 — closes #524. Créée à la validation P1 de 15-6b (C-15-6-9). Rebase APRÈS 15-5b ; de préférence après 15-5c (manuel du rapprochement). post_manual et accept_one_rule refusent la contrepartie égale au compte de la banque, même refus et même place que le flux ventilé ; règle sur ce compte plus proposée (C-15-6-23) ; P2 : compte de banque actif sur le chemin par règle, gardes ventilées figées, APRÈS 15-6b (comparaison empruntée, C-15-6-28) ; P3 : 10 LOW appliqués (C-15-6-31). Validations P1, P2 et P3 appliquées — VALIDATION CLOSE.
   15-7-trace-onboarding: split  # 2026-10-08 DÉCOUPÉE en 15-7a (production) + 15-7b (démo et remise à zéro) après la validation P1 (1 HIGH, 8 MEDIUM, 10 LOW distincts ; règle de splitting franchie, findings R7/F-5) — choix C-15-7-8. Corps vidé ; Change Log de P1 conservé. SPÉCIFIÉE le 2026-10-08 (choix C-15-7-1 à 7).
diff --git a/crates/kesh-api/src/errors.rs b/crates/kesh-api/src/errors.rs
index 46af25475..1dba344cc 100644
--- a/crates/kesh-api/src/errors.rs
+++ b/crates/kesh-api/src/errors.rs
@@ -3041,6 +3041,22 @@ impl IntoResponse for AppError {
                     });
                     (StatusCode::CONFLICT, Json(body)).into_response()
                 }
+                // Story 15-6b (#474) — un règlement viserait le compte qu'il
+                // solde. 400 (la donnée proposée est invalide), un code pour les
+                // quatre rôles ; le message suit le rôle (le remède diffère).
+                DbError::SettlementCounterpartyIsClaimAccount {
+                    account_id,
+                    account_number,
+                    claim,
+                    role,
+                    batch,
+                } => settlement_counterparty_response(
+                    account_id,
+                    account_number.as_deref(),
+                    claim,
+                    role,
+                    batch.as_ref(),
+                ),
                 // Story 25-3-a-1 (#414) — l'annulation d'un règlement refusée.
                 //
                 // ⚠️ Seuls les rangs que le GESTE refuse lui-même arrivent ici
@@ -3648,6 +3664,109 @@ fn supplier_invoice_cancel_blocked_text(
     }
 }
 
+/// Clé i18n et repli français du refus « contrepartie = compte soldé »
+/// (Story 15-6b, AC2) — **un rôle, une clé**, toutes **plates** : un sélecteur
+/// Fluent neuf rougirait `no_new_select_expression_reaches_the_frontend_dictionary`
+/// (kesh-i18n), et le dictionnaire du frontend le résoudrait sans argument.
+///
+/// ⚠️ `t_args` rend le repli **tel quel**, sans les arguments : il est donc
+/// construit par `format!`, numéro et facture déjà en place.
+fn settlement_counterparty_message(
+    account: &str,
+    claim: kesh_db::errors::ClaimSide,
+    role: kesh_db::errors::SettlementAccountRole,
+    batch: Option<&kesh_db::errors::SettlementBatchContext>,
+) -> String {
+    use kesh_db::errors::{ClaimSide, SettlementAccountRole};
+    let mut args = FluentArgs::new();
+    args.set("account", account.to_string());
+    let (key, fallback) = match (role, claim) {
+        (SettlementAccountRole::Counterparty, ClaimSide::Payable) => match batch {
+            Some(ctx) => {
+                let invoice = ctx
+                    .supplier_invoice_number
+                    .clone()
+                    .unwrap_or_else(|| format!("#{}", ctx.supplier_invoice_id));
+                args.set("invoice", invoice.clone());
+                (
+                    "error-settlement-counterparty-is-payable-in-batch",
+                    format!(
+                        "Le compte bancaire de ce lot est lié au compte {account}, le compte créanciers de la facture {invoice} : le lot ne peut pas être confirmé. Reliez le compte bancaire à son propre compte de banque puis confirmez de nouveau, ou annulez le lot et réglez la facture depuis sa fiche."
+                    ),
+                )
+            }
+            None => (
+                "error-settlement-counterparty-is-payable",
+                format!(
+                    "Le compte {account} est le compte créanciers de cette facture : un règlement doit éteindre la dette par un autre compte (banque, caisse, compensation…)."
+                ),
+            ),
+        },
+        (SettlementAccountRole::Counterparty, ClaimSide::Receivable) => (
+            "error-settlement-counterparty-is-receivable",
+            format!(
+                "Le compte {account} est le compte débiteurs de cette facture : un règlement doit faire sortir la créance vers un autre compte (banque, caisse, compensation…)."
+            ),
+        ),
+        (SettlementAccountRole::Rounding, _) => (
+            "error-settlement-rounding-account-is-receivable",
+            format!(
+                "Le compte {account}, désigné dans les réglages comme compte de différences d'arrondi, est le compte débiteurs de cette facture : un administrateur doit désigner un autre compte dans Paramètres → Facturation."
+            ),
+        ),
+        (SettlementAccountRole::WriteOffNature, _) => (
+            "error-settlement-write-off-account-is-receivable",
+            format!(
+                "Le compte {account}, désigné dans les réglages comme compte de cette nature de solde, est le compte débiteurs de cette facture : un administrateur doit désigner un autre compte dans Paramètres → Facturation."
+            ),
+        ),
+        (SettlementAccountRole::VatPayable, _) => (
+            "error-settlement-vat-payable-account-is-receivable",
+            format!(
+                "Le compte {account}, désigné dans les réglages comme compte de TVA due, est le compte débiteurs de cette facture : un administrateur doit désigner un autre compte dans Paramètres → Facturation."
+            ),
+        ),
+    };
+    t_args(key, &fallback, &args)
+}
+
+/// Réponse **400** `SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT` (Story 15-6b,
+/// AC2). `details` vient de `claim_account_refusal_details` — la forme que
+/// partagent le rapprochement et la création d'un lot ; les clés **de lot**
+/// (`paymentBatchId`, `supplierInvoiceId`) ne sont ajoutées qu'ici, seul
+/// consommateur qui en ait.
+fn settlement_counterparty_response(
+    account_id: i64,
+    account_number: Option<&str>,
+    claim: kesh_db::errors::ClaimSide,
+    role: kesh_db::errors::SettlementAccountRole,
+    batch: Option<&kesh_db::errors::SettlementBatchContext>,
+) -> Response {
+    let account = account_number
+        .map(str::to_string)
+        .unwrap_or_else(|| format!("#{account_id}"));
+    let message = settlement_counterparty_message(&account, claim, role, batch);
+    let mut details = kesh_db::repositories::invoice_settlements::claim_account_refusal_details(
+        account_id,
+        account_number,
+        claim,
+        role,
+        None,
+    );
+    if let Some(ctx) = batch {
+        details["paymentBatchId"] = serde_json::json!(ctx.payment_batch_id);
+        details["supplierInvoiceId"] = serde_json::json!(ctx.supplier_invoice_id);
+    }
+    let body = serde_json::json!({
+        "error": {
+            "code": "SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT",
+            "message": message,
+            "details": details,
+        }
+    });
+    (StatusCode::BAD_REQUEST, Json(body)).into_response()
+}
+
 /// Le 400 `ACCOUNT_ARCHIVED` d'une contre-passation dont un compte a été
 /// archivé — [`DbError::ReversalAccountsArchived`] et sa jumelle de l'avoir
 /// [`DbError::CreditNoteAccountsArchived`] (Story 15-6a) : même code, même
@@ -4026,6 +4145,127 @@ mod tests {
         );
     }
 
+    fn claim_refusal(
+        role: kesh_db::errors::SettlementAccountRole,
+        claim: kesh_db::errors::ClaimSide,
+        batch: Option<kesh_db::errors::SettlementBatchContext>,
+    ) -> DbError {
+        DbError::SettlementCounterpartyIsClaimAccount {
+            account_id: 17,
+            account_number: Some("1100".into()),
+            claim,
+            role,
+            batch,
+        }
+    }
+
+    /// Story 15-6b (#474, AC2) — 400, un code, `details` de la forme commune,
+    /// et un repli français **formaté** : sans i18n initialisée, `t_args` rend
+    /// le repli tel quel, qui ne doit pas laisser fuir le gabarit `{ $account }`.
+    #[tokio::test]
+    async fn settlement_counterparty_is_claim_account_is_400_with_details() {
+        use kesh_db::errors::{ClaimSide, SettlementAccountRole};
+        let resp = AppError::from(claim_refusal(
+            SettlementAccountRole::Counterparty,
+            ClaimSide::Receivable,
+            None,
+        ))
+        .into_response();
+        let (status, body) = response_body(resp).await;
+        assert_eq!(status, StatusCode::BAD_REQUEST);
+        assert_eq!(
+            body["error"]["code"],
+            "SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT"
+        );
+        assert_eq!(
+            body["error"]["details"],
+            serde_json::json!({
+                "accountId": 17,
+                "accountNumber": "1100",
+                "claim": "receivable",
+                "role": "counterparty",
+            })
+        );
+        let msg = body["error"]["message"].as_str().unwrap();
+        assert!(msg.contains("1100") && msg.contains("débiteurs"), "{msg}");
+        assert!(!msg.contains('$'), "gabarit non résolu : {msg}");
+    }
+
+    /// Story 15-6b (AC2) — la clé suit le RÔLE : un compte désigné renvoie à
+    /// Paramètres → Facturation, jamais à « banque, caisse ».
+    #[tokio::test]
+    async fn settlement_counterparty_message_follows_the_role() {
+        use kesh_db::errors::{ClaimSide, SettlementAccountRole};
+        for (role, marker) in [
+            (SettlementAccountRole::Rounding, "différences d'arrondi"),
+            (SettlementAccountRole::WriteOffNature, "nature de solde"),
+            (SettlementAccountRole::VatPayable, "TVA due"),
+        ] {
+            let resp =
+                AppError::from(claim_refusal(role, ClaimSide::Receivable, None)).into_response();
+            let (_, body) = response_body(resp).await;
+            assert_eq!(body["error"]["details"]["role"], role.as_str());
+            let msg = body["error"]["message"].as_str().unwrap();
+            assert!(msg.contains(marker), "{role:?} : {msg}");
+            assert!(msg.contains("Paramètres → Facturation"), "{role:?} : {msg}");
+            assert!(!msg.contains("banque, caisse"), "{role:?} : {msg}");
+        }
+        let resp = AppError::from(claim_refusal(
+            SettlementAccountRole::Counterparty,
+            ClaimSide::Payable,
+            None,
+        ))
+        .into_response();
+        let (_, body) = response_body(resp).await;
+        assert_eq!(body["error"]["details"]["claim"], "payable");
+        let msg = body["error"]["message"].as_str().unwrap();
+        assert!(msg.contains("créanciers"), "{msg}");
+    }
+
+    /// Story 15-6b (AC2, AC6) — à la confirmation d'un lot, le message dit les
+    /// deux issues et `details` gagne les clés de lot, et elles seules.
+    #[tokio::test]
+    async fn settlement_counterparty_in_batch_carries_batch_keys() {
+        use kesh_db::errors::{ClaimSide, SettlementAccountRole, SettlementBatchContext};
+        let resp = AppError::from(claim_refusal(
+            SettlementAccountRole::Counterparty,
+            ClaimSide::Payable,
+            Some(SettlementBatchContext {
+                payment_batch_id: 5,
+                supplier_invoice_id: 42,
+                supplier_invoice_number: Some("FF-7".into()),
+            }),
+        ))
+        .into_response();
+        let (status, body) = response_body(resp).await;
+        assert_eq!(status, StatusCode::BAD_REQUEST);
+        assert_eq!(body["error"]["details"]["paymentBatchId"], 5);
+        assert_eq!(body["error"]["details"]["supplierInvoiceId"], 42);
+        assert!(body["error"]["details"].get("bankAccountId").is_none());
+        let msg = body["error"]["message"].as_str().unwrap();
+        assert!(
+            msg.contains("FF-7") && msg.contains("1100") && msg.contains("annulez le lot"),
+            "{msg}"
+        );
+
+        // Sans numéro de facture : repli `#<id>`.
+        let resp = AppError::from(claim_refusal(
+            SettlementAccountRole::Counterparty,
+            ClaimSide::Payable,
+            Some(SettlementBatchContext {
+                payment_batch_id: 5,
+                supplier_invoice_id: 42,
+                supplier_invoice_number: None,
+            }),
+        ))
+        .into_response();
+        let (_, body) = response_body(resp).await;
+        assert!(
+            body["error"]["message"].as_str().unwrap().contains("#42"),
+            "{body}"
+        );
+    }
+
     /// Story 16-3b — le conflit de numéro de client porte **son propre code**,
     /// et pas celui de l'IDE.
     ///
diff --git a/crates/kesh-api/src/routes/reconciliation.rs b/crates/kesh-api/src/routes/reconciliation.rs
index c27aa1b49..cf37a8e28 100644
--- a/crates/kesh-api/src/routes/reconciliation.rs
+++ b/crates/kesh-api/src/routes/reconciliation.rs
@@ -23,8 +23,8 @@ use chrono::{Duration, NaiveDate};
 use kesh_db::entities::audit_log::NewAuditLogEntry;
 use kesh_db::entities::bank_transaction::{BankTransaction, BankTransactionStatus};
 use kesh_db::entities::invoice::Invoice;
-use kesh_db::errors::DbError;
-use kesh_db::repositories::invoice_settlements::PaymentAgainstDue;
+use kesh_db::errors::{ClaimSide, DbError};
+use kesh_db::repositories::invoice_settlements::{ClaimSubject, GapAccountRole, PaymentAgainstDue};
 use kesh_db::repositories::reconciliation::UnpaidInvoiceCandidate;
 use kesh_db::repositories::{
     accounts as accounts_repo, audit_log, bank_accounts, company_invoice_settings,
@@ -1204,6 +1204,43 @@ async fn accept_one(
     }
 }
 
+/// Convertit le refus « compte = créance » (Story 15-6b, #474) en
+/// `FailedProposal` — **une seule** fonction pour l'étape (b bis) et (c-bis),
+/// `details` par le helper commun `claim_account_refusal_details`.
+/// `bank_account_id` n'est fourni que pour le rôle `counterparty`. Toute autre
+/// erreur — celle de la lecture du numéro — est un `DATABASE_ERROR`, comme aux
+/// étapes voisines (pattern batch : jamais d'`AppError` global).
+fn claim_account_failed_proposal(
+    bank_transaction_id: i64,
+    err: DbError,
+    bank_account_id: Option<i64>,
+) -> FailedProposal {
+    match &err {
+        DbError::SettlementCounterpartyIsClaimAccount {
+            account_id,
+            account_number,
+            claim,
+            role,
+            ..
+        } => FailedProposal {
+            bank_transaction_id,
+            error_code: err.error_code().to_string(),
+            details: Some(invoice_settlements::claim_account_refusal_details(
+                *account_id,
+                account_number.as_deref(),
+                *claim,
+                *role,
+                bank_account_id,
+            )),
+        },
+        other => FailedProposal {
+            bank_transaction_id,
+            error_code: "DATABASE_ERROR".to_string(),
+            details: Some(serde_json::json!({ "message": other.to_string() })),
+        },
+    }
+}
+
 /// Helper interne — traite UNE proposal `type='invoice'` dans son savepoint.
 ///
 /// **C2 Pass 1 code review (TOCTOU fix)** : la BankTransaction est
@@ -1222,6 +1259,17 @@ async fn accept_one(
 /// `company_invoice_settings::rounding_account_for_write`. Les deux autres
 /// flux d'acceptation (`split`, `rule`) et les rapprochements manuel et ventilé
 /// gardent, eux, le compte de contrepartie venu du client.
+///
+/// ⚠️ **Mais ne pas venir du client ne veut pas dire ne pas pouvoir être la
+/// créance** (Story 15-6b, #474, amendement du classement ci-dessus) : le compte
+/// de banque vient de la **configuration** du compte bancaire, et rien n'y
+/// interdit le 1100 ; le compte d'arrondi vient des réglages, et la créance
+/// retypée en charge passe son contrôle de type. L'un et l'autre écriraient
+/// `D 1100 / C 1100`. Ils sont donc **comparés à la créance** — le compte de
+/// banque aussitôt la créance lue (étape b bis, avant le trop-perçu), le compte
+/// d'arrondi aussitôt lu (c-bis) — et le refus est une proposition de
+/// `failed[]` (`SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT`), jamais une erreur
+/// globale.
 #[allow(clippy::too_many_arguments)]
 async fn accept_one_invoice(
     tx: &mut sqlx::Transaction<'_, sqlx::MySql>,
@@ -1493,6 +1541,19 @@ async fn accept_one_invoice(
         }
     };
 
+    // (b bis) ⛔ Story 15-6b (#474) — le compte de banque n'est pas la créance.
+    //         Après tous les refus antérieurs (score, compte bancaire sans
+    //         journal, écriture de vente malformée), avant le trop-perçu.
+    invoice_settlements::refuse_if_claim_account(
+        tx,
+        company_id,
+        bank_ledger_account_id,
+        receivable_account_id,
+        ClaimSubject::Counterparty(ClaimSide::Receivable),
+    )
+    .await
+    .map_err(|e| claim_account_failed_proposal(bank_transaction_id, e, Some(bank_account_id)))?;
+
     // (c) ⛔ Le trop-perçu est REFUSÉ, il ne s'écrit pas. Sans ce garde, le
     //     compte de créance passerait CRÉDITEUR — un solde contre nature que le
     //     grand livre signalerait, mais après coup.
@@ -1533,7 +1594,20 @@ async fn accept_one_invoice(
         )
         .await
         {
-            Ok(id) => Some(id),
+            // Story 15-6b (AC3 bis) — le compte d'arrondi n'est pas la créance :
+            // `details` sans `bankAccountId`, qui n'a pas de sens ici.
+            Ok(id) => {
+                invoice_settlements::refuse_if_claim_account(
+                    tx,
+                    company_id,
+                    id,
+                    receivable_account_id,
+                    ClaimSubject::Designated(GapAccountRole::Rounding),
+                )
+                .await
+                .map_err(|e| claim_account_failed_proposal(bank_transaction_id, e, None))?;
+                Some(id)
+            }
             Err(DbError::RoundingAccountNotConfigured { .. }) => {
                 return Err(FailedProposal {
                     bank_transaction_id,
diff --git a/crates/kesh-api/tests/invoice_echeancier_e2e.rs b/crates/kesh-api/tests/invoice_echeancier_e2e.rs
index 50413dead..c440dac7e 100644
--- a/crates/kesh-api/tests/invoice_echeancier_e2e.rs
+++ b/crates/kesh-api/tests/invoice_echeancier_e2e.rs
@@ -1837,3 +1837,111 @@ async fn write_off_route_refusals(pool: MySqlPool) {
         "{body}"
     );
 }
+
+// --- Story 15-6b (#474) — la contrepartie n'est pas la créance, à la frontière HTTP
+
+/// Story 15-6b, test 16 — `POST …/settlements` par compte interne = la créance :
+/// **400**, code, `details.claim = "receivable"`, message **fr** (la langue des
+/// messages est globale au processus, `init_error_i18n`).
+#[sqlx::test(migrations = "../kesh-db/test-schema")]
+async fn settle_on_the_receivable_account_is_a_400_with_details(pool: MySqlPool) {
+    let (admin_id, company_id) = seed_base(&pool).await;
+    let contact_id = seed_contact(&pool, company_id, admin_id).await;
+    let (id, _v) = create_validated_invoice(
+        &pool,
+        company_id,
+        contact_id,
+        admin_id,
+        NaiveDate::from_ymd_opt(2026, 4, 1).unwrap(),
+        NaiveDate::from_ymd_opt(2026, 4, 30).unwrap(),
+        dec!(100.00),
+    )
+    .await;
+    let creance = receivable_id(&pool, company_id).await;
+    let app = spawn_app(pool.clone()).await;
+    let token = login(&app).await;
+
+    let resp = post_settle(&app, &token, id, creance, "108.10").await;
+    assert_eq!(resp.status(), 400);
+    let body: serde_json::Value = resp.json().await.unwrap();
+    assert_eq!(
+        body["error"]["code"],
+        "SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT"
+    );
+    assert_eq!(
+        body["error"]["details"],
+        json!({
+            "accountId": creance,
+            "accountNumber": "1100",
+            "claim": "receivable",
+            "role": "counterparty",
+        })
+    );
+    let msg = body["error"]["message"].as_str().unwrap();
+    assert!(
+        msg.contains("1100") && msg.contains("compte débiteurs de cette facture"),
+        "message fr attendu : {msg}"
+    );
+    assert!(!msg.contains('$') && !msg.contains('\u{2068}'), "{msg}");
+    assert!(!paid(&pool, id).await);
+}
+
+/// Story 15-6b, test 16 bis — `POST …/write-off` dont le compte de la nature
+/// `discount` est la créance retypée : **400**, `details.role =
+/// "write_off_nature"`, message qui renvoie à Paramètres → Facturation — et non
+/// à « banque, caisse » (clé plate `error-settlement-write-off-account-is-receivable`).
+#[sqlx::test(migrations = "../kesh-db/test-schema")]
+async fn write_off_on_a_nature_account_that_is_the_receivable_is_a_400(pool: MySqlPool) {
+    let (admin_id, company_id) = seed_base(&pool).await;
+    let contact_id = seed_contact(&pool, company_id, admin_id).await;
+    let (id, _v) = create_validated_invoice(
+        &pool,
+        company_id,
+        contact_id,
+        admin_id,
+        NaiveDate::from_ymd_opt(2026, 4, 1).unwrap(),
+        NaiveDate::from_ymd_opt(2026, 4, 30).unwrap(),
+        dec!(100.00),
+    )
+    .await;
+    let creance = receivable_id(&pool, company_id).await;
+    sqlx::query("UPDATE accounts SET account_type = 'Expense', role = NULL WHERE id = ?")
+        .bind(creance)
+        .execute(&pool)
+        .await
+        .unwrap();
+    sqlx::query(
+        "UPDATE company_invoice_settings SET default_discount_account_id = ? WHERE company_id = ?",
+    )
+    .bind(creance)
+    .bind(company_id)
+    .execute(&pool)
+    .await
+    .unwrap();
+    let app = spawn_app(pool.clone()).await;
+    let token = login(&app).await;
+    let version = invoice_version(&app, &token, id).await;
+
+    let resp = post_write_off(
+        &app,
+        &token,
+        id,
+        json!({ "nature": "discount", "settledOn": "2026-04-20", "version": version }),
+    )
+    .await;
+    assert_eq!(resp.status(), 400);
+    let body: serde_json::Value = resp.json().await.unwrap();
+    assert_eq!(
+        body["error"]["code"],
+        "SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT"
+    );
+    assert_eq!(body["error"]["details"]["role"], "write_off_nature");
+    assert_eq!(body["error"]["details"]["claim"], "receivable");
+    let msg = body["error"]["message"].as_str().unwrap();
+    assert!(
+        msg.contains("nature de solde") && msg.contains("Paramètres → Facturation"),
+        "{msg}"
+    );
+    assert!(!msg.contains("banque, caisse"), "{msg}");
+    assert!(!paid(&pool, id).await);
+}
diff --git a/crates/kesh-api/tests/reconciliation_e2e.rs b/crates/kesh-api/tests/reconciliation_e2e.rs
index 6033747bb..3bb24338a 100644
--- a/crates/kesh-api/tests/reconciliation_e2e.rs
+++ b/crates/kesh-api/tests/reconciliation_e2e.rs
@@ -5267,3 +5267,219 @@ async fn accept_split_missing_and_non_postable_reports_not_found_first(pool: MyS
     assert_eq!(failed.len(), 1, "{body}");
     assert_eq!(failed[0]["errorCode"], "ACCOUNT_NOT_FOUND");
 }
+
+// ============================================================
+// Story 15-6b (#474) — le compte de banque n'est pas la créance
+// ============================================================
+
+/// Une transaction de `amount`, référencée `reference`, sur le compte bancaire
+/// du contexte. Rend son id.
+async fn one_tx(
+    pool: &MySqlPool,
+    ctx: &CompanyCtx,
+    hash_seed: &str,
+    amount: Decimal,
+    reference: &str,
+) -> i64 {
+    let day = NaiveDate::from_ymd_opt(2026, 5, 15).unwrap();
+    seed_bank_transactions(
+        pool,
+        ctx.company_id,
+        ctx.bank_account_id,
+        ctx.user_id,
+        &unique_hash(hash_seed),
+        day,
+        day,
+        vec![make_new_tx(
+            ctx.company_id,
+            ctx.bank_account_id,
+            day,
+            Some(day),
+            amount,
+            "CHF",
+            reference,
+            None,
+        )],
+    )
+    .await[0]
+}
+
+async fn tx_status(pool: &MySqlPool, tx_id: i64) -> String {
+    sqlx::query_scalar("SELECT status FROM bank_transactions WHERE id = ?")
+        .bind(tx_id)
+        .fetch_one(pool)
+        .await
+        .unwrap()
+}
+
+/// Story 15-6b, test 7 — **un lot de deux propositions, deux créances** : A sur
+/// 1100, B sur 1101 ; le compte bancaire du lot est lié au 1100. HTTP 200, B
+/// acceptée, A dans `failed[]` avec ses cinq clés ; la transaction de A reste
+/// en attente.
+#[sqlx::test(migrations = "../kesh-db/test-schema")]
+async fn accept_refuses_per_proposal_a_bank_ledger_that_is_the_receivable(pool: MySqlPool) {
+    let ctx = setup_company(&pool, "ContrepA", "CH4431999123000889012", Role::Comptable).await;
+    let inv_date = NaiveDate::from_ymd_opt(2026, 5, 1).unwrap();
+    let (inv_a, _) = seed_validated_invoice(
+        &pool,
+        ctx.company_id,
+        ctx.contact_id,
+        "INV-CP-A",
+        inv_date,
+        dec!(100.00),
+    )
+    .await;
+    let (inv_b, je_b) = seed_validated_invoice(
+        &pool,
+        ctx.company_id,
+        ctx.contact_id,
+        "INV-CP-B",
+        inv_date,
+        dec!(200.00),
+    )
+    .await;
+    // B porte sa créance sur un 1101 (débiteurs changé dans les réglages entre
+    // les deux ventes) : la ligne de débit de son écriture de vente.
+    let r1101: i64 = sqlx::query_scalar(
+        "INSERT INTO accounts (company_id, number, name, account_type, active, postable) \
+         VALUES (?, '1101', 'Débiteurs bis', 'Asset', 1, 1) RETURNING id",
+    )
+    .bind(ctx.company_id)
+    .fetch_one(&pool)
+    .await
+    .unwrap();
+    sqlx::query("UPDATE journal_entry_lines SET account_id = ? WHERE entry_id = ? AND debit > 0")
+        .bind(r1101)
+        .bind(je_b)
+        .execute(&pool)
+        .await
+        .unwrap();
+    // Le compte bancaire du lot, lié au 1100 (sans passer par la 15-6c).
+    sqlx::query("UPDATE bank_accounts SET journal_account_id = ? WHERE id = ?")
+        .bind(ctx.receivable_account_id)
+        .bind(ctx.bank_account_id)
+        .execute(&pool)
+        .await
+        .unwrap();
+    let tx_a = one_tx(&pool, &ctx, "cp-a", dec!(100.00), "INV-CP-A").await;
+    let tx_b = one_tx(&pool, &ctx, "cp-b", dec!(200.00), "INV-CP-B").await;
+    let app = spawn_app(pool.clone()).await;
+
+    let resp = app
+        .client
+        .post(app.url("/api/v1/reconciliation/accept"))
+        .bearer_auth(&ctx.jwt)
+        .json(&serde_json::json!({
+            "bankAccountId": ctx.bank_account_id,
+            "proposals": [
+                { "type": "invoice", "bankTransactionId": tx_a, "invoiceId": inv_a },
+                { "type": "invoice", "bankTransactionId": tx_b, "invoiceId": inv_b },
+            ],
+        }))
+        .send()
+        .await
+        .unwrap();
+    assert_eq!(resp.status(), 200, "succès partiel = succès HTTP");
+    let body: Value = resp.json().await.unwrap();
+    assert_eq!(body["accepted"].as_array().map(Vec::len), Some(1), "{body}");
+    let failed = body["failed"].as_array().unwrap();
+    assert_eq!(failed.len(), 1, "{body}");
+    assert_eq!(failed[0]["bankTransactionId"], tx_a);
+    assert_eq!(
+        failed[0]["errorCode"],
+        "SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT"
+    );
+    assert_eq!(
+        failed[0]["details"],
+        serde_json::json!({
+            "bankAccountId": ctx.bank_account_id,
+            "accountId": ctx.receivable_account_id,
+            "accountNumber": "1100",
+            "claim": "receivable",
+            "role": "counterparty",
+        })
+    );
+    assert_eq!(settlements_and_paid_at(&pool, inv_a).await, (0, None));
+    assert_eq!(tx_status(&pool, tx_a).await, "pending");
+    let (settled_b, _) = settlements_and_paid_at(&pool, inv_b).await;
+    assert_eq!(settled_b, 1, "B est réglée");
+}
+
+/// Story 15-6b, test 8 — **ordre** : sur A, une transaction supérieure au reste
+/// (référencée, donc de score positif — l'étape 7bis passe) rend le refus de
+/// contrepartie, pas `RECONCILIATION_OVERPAYMENT`.
+#[sqlx::test(migrations = "../kesh-db/test-schema")]
+async fn the_counterparty_refusal_comes_before_the_reconciliation_overpayment(pool: MySqlPool) {
+    let ctx = setup_company(&pool, "ContrepB", "CH4431999123000889012", Role::Comptable).await;
+    let (inv_a, _) = seed_validated_invoice(
+        &pool,
+        ctx.company_id,
+        ctx.contact_id,
+        "INV-CP-C",
+        NaiveDate::from_ymd_opt(2026, 5, 1).unwrap(),
+        dec!(100.00),
+    )
+    .await;
+    sqlx::query("UPDATE bank_accounts SET journal_account_id = ? WHERE id = ?")
+        .bind(ctx.receivable_account_id)
+        .bind(ctx.bank_account_id)
+        .execute(&pool)
+        .await
+        .unwrap();
+    let tx_a = one_tx(&pool, &ctx, "cp-c", dec!(150.00), "INV-CP-C").await;
+    let app = spawn_app(pool.clone()).await;
+
+    let body = post_accept_one(&app, &ctx, tx_a, inv_a).await;
+    let failed = body["failed"].as_array().unwrap();
+    assert_eq!(failed.len(), 1, "{body}");
+    assert_eq!(
+        failed[0]["errorCode"], "SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT",
+        "la contrepartie précède le trop-perçu"
+    );
+    assert_eq!(settlements_and_paid_at(&pool, inv_a).await, (0, None));
+}
+
+/// Story 15-6b, test 12 — **arrondi (c-bis) = créance** (AC3 bis) : la créance
+/// retypée en charge et désignée compte d'arrondi. `failed[]`, HTTP 200,
+/// `details.role = "rounding"`, et PAS de `bankAccountId`.
+#[sqlx::test(migrations = "../kesh-db/test-schema")]
+async fn accept_refuses_a_rounding_account_that_is_the_receivable(pool: MySqlPool) {
+    let ctx = setup_company(&pool, "ContrepR", "CH4431999123000889012", Role::Comptable).await;
+    designate_rounding_account(&pool, ctx.company_id).await;
+    let (inv_id, tx_id) =
+        half_centime_invoice_and_tx(&pool, &ctx, "INV-CP-R", dec!(10.01), "INV-CP-R").await;
+    sqlx::query("UPDATE accounts SET account_type = 'Expense', role = NULL WHERE id = ?")
+        .bind(ctx.receivable_account_id)
+        .execute(&pool)
+        .await
+        .unwrap();
+    sqlx::query(
+        "UPDATE company_invoice_settings SET default_rounding_account_id = ? WHERE company_id = ?",
+    )
+    .bind(ctx.receivable_account_id)
+    .bind(ctx.company_id)
+    .execute(&pool)
+    .await
+    .unwrap();
+    let app = spawn_app(pool.clone()).await;
+
+    let body = post_accept_one(&app, &ctx, tx_id, inv_id).await;
+    let failed = body["failed"].as_array().unwrap();
+    assert_eq!(failed.len(), 1, "{body}");
+    assert_eq!(
+        failed[0]["errorCode"],
+        "SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT"
+    );
+    assert_eq!(
+        failed[0]["details"],
+        serde_json::json!({
+            "accountId": ctx.receivable_account_id,
+            "accountNumber": "1100",
+            "claim": "receivable",
+            "role": "rounding",
+        })
+    );
+    assert!(failed[0]["details"].get("bankAccountId").is_none());
+    assert_eq!(settlements_and_paid_at(&pool, inv_id).await, (0, None));
+    assert_eq!(tx_status(&pool, tx_id).await, "pending");
+}
diff --git a/crates/kesh-api/tests/supplier_settlement_cancel_e2e.rs b/crates/kesh-api/tests/supplier_settlement_cancel_e2e.rs
index c61fa4227..5cd950969 100644
--- a/crates/kesh-api/tests/supplier_settlement_cancel_e2e.rs
+++ b/crates/kesh-api/tests/supplier_settlement_cancel_e2e.rs
@@ -1,5 +1,7 @@
 //! Annuler le règlement d'une facture fournisseur par l'API — Story 25-3-a-2 (#414) —
-//! et annuler la facture elle-même, même payée — Story 25-3-c (#454).
+//! et annuler la facture elle-même, même payée — Story 25-3-c (#454) ; puis le
+//! refus « contrepartie = compte créanciers » du paiement et des lots, par HTTP
+//! — Story 15-6b (#474), revue de code P1.
 //!
 //! ⚠️ Premier fichier de tests HTTP des factures fournisseurs : le montage de
 //! l'application est repris de `invoice_echeancier_e2e.rs` (chaque binaire de
@@ -451,3 +453,226 @@ async fn cancel_invoice_roles_and_refusals(pool: MySqlPool) {
         "got {body:?}"
     );
 }
+
+// ---------------------------------------------------------------------------
+// Story 15-6b (#474) — revue de code P1, finding L5 = E3 : le refus
+// « contrepartie = compte créanciers » à travers HTTP, sur les trois routes
+// que `docs/api-external.md` documente et que seuls le dépôt et le mapping
+// `AppError` exerçaient jusque-là.
+// ---------------------------------------------------------------------------
+
+/// Un compte bancaire source (IBAN valide), relié au compte du grand livre
+/// `ledger` ; rend son id.
+async fn bank_linked_to(pool: &MySqlPool, seeded: &SeededCompany, ledger: i64) -> i64 {
+    let bank = kesh_db::repositories::bank_accounts::create(
+        pool,
+        kesh_db::entities::NewBankAccount {
+            company_id: seeded.company_id,
+            bank_name: "Banque Source".into(),
+            iban: "CH9300762011623852957".into(),
+            qr_iban: None,
+            is_primary: true,
+        },
+    )
+    .await
+    .unwrap();
+    relink(pool, bank.id, ledger).await;
+    bank.id
+}
+
+async fn relink(pool: &MySqlPool, bank_id: i64, ledger: i64) {
+    sqlx::query("UPDATE bank_accounts SET journal_account_id = ? WHERE id = ?")
+        .bind(ledger)
+        .bind(bank_id)
+        .execute(pool)
+        .await
+        .unwrap();
+}
+
+/// Le compte de banque 1020, absent du seed.
+async fn ledger_1020(pool: &MySqlPool, seeded: &SeededCompany) -> i64 {
+    sqlx::query_scalar(
+        "INSERT INTO accounts (company_id, number, name, account_type, active, postable) \
+         VALUES (?, '1020', 'Banque', 'Asset', 1, 1) RETURNING id",
+    )
+    .bind(seeded.company_id)
+    .fetch_one(pool)
+    .await
+    .unwrap()
+}
+
+/// Une facture ouverte payable par virement (IBAN du créancier posé).
+async fn open_invoice_with_iban(pool: &MySqlPool, seeded: &SeededCompany) -> i64 {
+    let id = open_invoice(pool, seeded).await;
+    sqlx::query("UPDATE supplier_invoices SET creditor_iban = ? WHERE id = ?")
+        .bind("CH5604835012345678009")
+        .bind(id)
+        .execute(pool)
+        .await
+        .unwrap();
+    id
+}
+
+async fn status_of(pool: &MySqlPool, id: i64) -> String {
+    sqlx::query_scalar("SELECT status FROM supplier_invoices WHERE id = ?")
+        .bind(id)
+        .fetch_one(pool)
+        .await
+        .unwrap()
+}
+
+/// `POST /supplier-invoices/{id}/pay` par le compte interne 2000 — le compte
+/// créanciers de la facture : **400**, code et `details` du refus, message qui
+/// nomme le compte ; la facture reste ouverte.
+#[sqlx::test(migrations = "../kesh-db/test-schema")]
+async fn pay_through_the_payable_account_itself_is_a_400(pool: MySqlPool) {
+    let seeded = seed_accounting_company(&pool).await.unwrap();
+    let id = open_invoice(&pool, &seeded).await;
+    let app = spawn_app(pool.clone()).await;
+    let token = login(&app, "admin", TEST_ADMIN_PASSWORD).await;
+    let payable = seeded.accounts["2000"];
+
+    let resp = post(
+        &app,
+        &token,
+        &format!("/api/v1/supplier-invoices/{id}/pay"),
+        json!({
+            "settlementType": "internal_account",
+            "accountId": payable,
+            "paymentDate": "2026-06-20"
+        }),
+    )
+    .await;
+    assert_eq!(resp.status(), 400);
+    let body: Value = resp.json().await.unwrap();
+    assert_eq!(
+        body["error"]["code"],
+        "SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT"
+    );
+    assert_eq!(
+        body["error"]["details"],
+        json!({
+            "accountId": payable,
+            "accountNumber": "2000",
+            "claim": "payable",
+            "role": "counterparty",
+        })
+    );
+    let msg = body["error"]["message"].as_str().unwrap();
+    assert!(
+        msg.contains("2000") && msg.contains("compte créanciers de cette facture"),
+        "message fr attendu : {msg}"
+    );
+    assert!(!msg.contains('$') && !msg.contains('\u{2068}'), "{msg}");
+    assert_eq!(status_of(&pool, id).await, "open");
+}
+
+/// `POST /payment-batches` avec un compte bancaire relié au 2000 : **200**,
+/// aucun lot, la facture dans `failed[]` avec le code et les `details` du
+/// refus (dont `bankAccountId`) — patron FailedProposal, jamais un 4xx global.
+#[sqlx::test(migrations = "../kesh-db/test-schema")]
+async fn create_batch_with_a_bank_linked_to_the_payable_reports_the_invoice_in_failed(
+    pool: MySqlPool,
+) {
+    let seeded = seed_accounting_company(&pool).await.unwrap();
+    let id = open_invoice_with_iban(&pool, &seeded).await;
+    let payable = seeded.accounts["2000"];
+    let bank_id = bank_linked_to(&pool, &seeded, payable).await;
+    let app = spawn_app(pool.clone()).await;
+    let token = login(&app, "admin", TEST_ADMIN_PASSWORD).await;
+
+    let resp = post(
+        &app,
+        &token,
+        "/api/v1/payment-batches",
+        json!({
+            "bankAccountId": bank_id,
+            "requestedExecutionDate": "2026-07-01",
+            "supplierInvoiceIds": [id]
+        }),
+    )
+    .await;
+    assert_eq!(resp.status(), 200);
+    let body: Value = resp.json().await.unwrap();
+    assert!(body["batch"].is_null(), "aucun lot : {body}");
+    assert_eq!(body["failed"].as_array().unwrap().len(), 1);
+    assert_eq!(body["failed"][0]["supplierInvoiceId"], id);
+    assert_eq!(
+        body["failed"][0]["errorCode"],
+        "SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT"
+    );
+    assert_eq!(
+        body["failed"][0]["details"],
+        json!({
+            "bankAccountId": bank_id,
+            "accountId": payable,
+            "accountNumber": "2000",
+            "claim": "payable",
+            "role": "counterparty",
+        })
+    );
+}
+
+/// `POST /payment-batches/{id}/confirm` après un relien du compte bancaire au
+/// 2000 : **400**, `details` portant `paymentBatchId` et `supplierInvoiceId`,
+/// message qui nomme la facture ; le lot reste `generated`, la facture
+/// `open`.
+#[sqlx::test(migrations = "../kesh-db/test-schema")]
+async fn confirm_batch_after_a_relink_to_the_payable_is_a_contextual_400(pool: MySqlPool) {
+    let seeded = seed_accounting_company(&pool).await.unwrap();
+    let id = open_invoice_with_iban(&pool, &seeded).await;
+    let l1020 = ledger_1020(&pool, &seeded).await;
+    let bank_id = bank_linked_to(&pool, &seeded, l1020).await;
+    let app = spawn_app(pool.clone()).await;
+    let token = login(&app, "admin", TEST_ADMIN_PASSWORD).await;
+
+    let resp = post(
+        &app,
+        &token,
+        "/api/v1/payment-batches",
+        json!({
+            "bankAccountId": bank_id,
+            "requestedExecutionDate": "2026-07-01",
+            "supplierInvoiceIds": [id]
+        }),
+    )
+    .await;
+    assert_eq!(resp.status(), 200);
+    let body: Value = resp.json().await.unwrap();
+    let batch_id = body["batch"]["id"].as_i64().expect("lot créé");
+
+    let payable = seeded.accounts["2000"];
+    relink(&pool, bank_id, payable).await;
+    let resp = post(
+        &app,
+        &token,
+        &format!("/api/v1/payment-batches/{batch_id}/confirm"),
+        json!({ "paymentDate": "2026-07-02" }),
+    )
+    .await;
+    assert_eq!(resp.status(), 400);
+    let body: Value = resp.json().await.unwrap();
+    assert_eq!(
+        body["error"]["code"],
+        "SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT"
+    );
+    let details = &body["error"]["details"];
+    assert_eq!(details["paymentBatchId"], batch_id);
+    assert_eq!(details["supplierInvoiceId"], id);
+    assert_eq!(details["accountId"], payable);
+    assert_eq!(details["claim"], "payable");
+    assert_eq!(details["role"], "counterparty");
+    let msg = body["error"]["message"].as_str().unwrap();
+    assert!(
+        msg.contains("FF-1") && msg.contains("2000") && msg.contains("lot"),
+        "message de lot attendu : {msg}"
+    );
+    assert!(!msg.contains('$') && !msg.contains('\u{2068}'), "{msg}");
+    let status: String = sqlx::query_scalar("SELECT status FROM payment_batches WHERE id = ?")
+        .bind(batch_id)
+        .fetch_one(&pool)
+        .await
+        .unwrap();
+    assert_eq!(status, "generated");
+    assert_eq!(status_of(&pool, id).await, "open");
+}
diff --git a/crates/kesh-db/src/errors.rs b/crates/kesh-db/src/errors.rs
index 3b96850eb..71f6a85a7 100644
--- a/crates/kesh-db/src/errors.rs
+++ b/crates/kesh-db/src/errors.rs
@@ -919,6 +919,47 @@ pub enum DbError {
     #[error("Comptes archivés sur l'avoir à émettre ({})", .0.len())]
     CreditNoteAccountsArchived(Vec<ArchivedAccount>),
 
+    /// Un règlement viserait **le compte même qu'il doit solder** (Story 15-6b,
+    /// #474) : la contrepartie — ou un compte d'écart du même geste — est le
+    /// compte débiteurs de la facture client, ou le compte créanciers de la
+    /// facture fournisseur.
+    ///
+    /// ⛔ **Le motif** : l'écriture serait `D X / C X`. Elle s'équilibre (rien
+    /// n'interdit un même compte au débit et au crédit), le règlement
+    /// s'enregistre, le reste dû baisse, la facture peut passer « payée » — et le
+    /// grand livre **ne bouge pas**. Le refus vient avant toute écriture.
+    ///
+    /// `role` dit **d'où vient** le compte en cause, donc le remède
+    /// ([`SettlementAccountRole`]). ⚠️ **Le rôle suit la colonne de réglage lue,
+    /// pas la route** : le compte d'arrondi du règlement, celui du rapprochement,
+    /// le reste d'arrondi d'un solde et le compte de la nature `rounding` lisent
+    /// tous `default_rounding_account_id` — ils sortent tous sous
+    /// `role: Rounding`. `claim: Payable` ne se combine qu'avec `Counterparty` :
+    /// le règlement fournisseur n'écrit aucun compte d'écart, et le constructeur
+    /// unique (`invoice_settlements::claim_account_refusal`) rend la combinaison
+    /// irreprésentable.
+    ///
+    /// `batch` ne vaut `Some` qu'à la **confirmation d'un lot** de paiement
+    /// (`payment_batches::confirm_batch`), qui intercepte le refus de
+    /// `pay_in_tx` pour dire lequel de ses règlements est en cause.
+    ///
+    /// Mappé vers HTTP **400** `SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT` — un
+    /// seul code pour les quatre rôles, le défaut étant le même ; `details.role`
+    /// et le message distinguent le remède.
+    #[error("La contrepartie du règlement est le compte qu'il solde (compte {account_id})")]
+    SettlementCounterpartyIsClaimAccount {
+        /// Le compte en cause — qui **est** le compte soldé.
+        account_id: i64,
+        /// Son numéro, lu à l'échec ; `None` s'il n'a pas pu être résolu.
+        account_number: Option<String>,
+        /// Le côté soldé : créance client ou dette fournisseur.
+        claim: ClaimSide,
+        /// D'où vient le compte en cause, donc quel est le remède.
+        role: SettlementAccountRole,
+        /// Le lot et la facture, à la seule confirmation d'un lot.
+        batch: Option<SettlementBatchContext>,
+    },
+
     /// L'écriture a été contre-passée : on ne la modifie ni ne la supprime
     /// plus (Story 24-4a ; la modification, Story 15-8a).
     ///
@@ -1042,6 +1083,72 @@ pub enum RoundingContext {
     Issuance,
 }
 
+/// Le côté que solde un règlement (Story 15-6b, #474) : la **créance** d'une
+/// facture client, ou la **dette** d'une facture fournisseur.
+#[derive(Debug, Clone, Copy, PartialEq, Eq)]
+pub enum ClaimSide {
+    /// Le compte débiteurs, lu sur l'écriture de vente.
+    Receivable,
+    /// Le compte créanciers, lu sur l'écriture d'achat.
+    Payable,
+}
+
+impl ClaimSide {
+    /// Discriminant machine exposé dans `details.claim`.
+    pub fn as_str(self) -> &'static str {
+        match self {
+            Self::Receivable => "receivable",
+            Self::Payable => "payable",
+        }
+    }
+}
+
+/// D'où vient le compte qui coïncide avec le compte soldé — donc quel est le
+/// remède (Story 15-6b, #474 ; choix C-15-6-26, C-15-6-30).
+///
+/// ⚠️ **Le rôle suit la colonne de réglage lue, pas la route** : un même compte
+/// désigné sort sous le même rôle partout.
+#[derive(Debug, Clone, Copy, PartialEq, Eq)]
+pub enum SettlementAccountRole {
+    /// La contrepartie que l'utilisateur **choisit** (compte interne, compte
+    /// bancaire du virement) ou que porte le **compte bancaire** du geste (lot,
+    /// rapprochement). Remède : un autre compte, ou relier le compte bancaire à
+    /// son propre compte de banque.
+    Counterparty,
+    /// Le compte de différences d'arrondi des réglages
+    /// (`default_rounding_account_id`), **quel que soit le geste** : règlement,
+    /// rapprochement, reste d'arrondi d'un solde, nature `rounding`.
+    Rounding,
+    /// Le compte d'une nature de solde des réglages — `discount`, `bank_fees`,
+    /// `bad_debt` seulement (la nature `rounding` est [`Self::Rounding`]).
+    WriteOffNature,
+    /// Le compte de TVA due des réglages (solde du reste).
+    VatPayable,
+}
+
+impl SettlementAccountRole {
+    /// Discriminant machine exposé dans `details.role`.
+    pub fn as_str(self) -> &'static str {
+        match self {
+            Self::Counterparty => "counterparty",
+            Self::Rounding => "rounding",
+            Self::WriteOffNature => "write_off_nature",
+            Self::VatPayable => "vat_payable",
+        }
+    }
+}
+
+/// Le lot de paiement et la facture en cause, quand le refus naît à la
+/// **confirmation d'un lot** (Story 15-6b, AC6) : le remède n'y est pas celui
+/// du règlement unitaire — l'utilisateur n'y choisit aucun compte.
+#[derive(Debug, Clone, PartialEq, Eq)]
+pub struct SettlementBatchContext {
+    pub payment_batch_id: i64,
+    pub supplier_invoice_id: i64,
+    /// Numéro de la facture fournisseur, relu par `confirm_batch`.
+    pub supplier_invoice_number: Option<String>,
+}
+
 impl DbError {
     /// Raccourci de construction de [`DbError::AccountsNotPostable`] : trie,
     /// dédoublonne et vérifie la non-vacuité par [`NonPostableAccounts::new`].
@@ -1081,6 +1188,9 @@ impl DbError {
             Self::EntryNotReversable { .. } => "ENTRY_NOT_REVERSABLE",
             Self::ReversalAccountsArchived(_) => "ACCOUNT_ARCHIVED",
             Self::CreditNoteAccountsArchived(_) => "ACCOUNT_ARCHIVED",
+            Self::SettlementCounterpartyIsClaimAccount { .. } => {
+                "SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT"
+            }
             Self::InvoiceNotUnvalidatable { blocker, .. } => blocker.code(),
             Self::SettlementNotCancellable { blocker } => blocker.code(),
             Self::ReconciliationNotCancellable { blocker } => blocker.code(),
@@ -1217,4 +1327,38 @@ mod tests {
         let err = DbError::accounts_not_postable([acc(1, "1000")]);
         assert_eq!(err.error_code(), "ACCOUNT_NOT_POSTABLE");
     }
+
+    /// Story 15-6b (#474) — un code pour les quatre rôles.
+    #[test]
+    fn settlement_counterparty_is_claim_account_error_code() {
+        for role in [
+            SettlementAccountRole::Counterparty,
+            SettlementAccountRole::Rounding,
+            SettlementAccountRole::WriteOffNature,
+            SettlementAccountRole::VatPayable,
+        ] {
+            let err = DbError::SettlementCounterpartyIsClaimAccount {
+                account_id: 1,
+                account_number: Some("1100".into()),
+                claim: ClaimSide::Receivable,
+                role,
+                batch: None,
+            };
+            assert_eq!(err.error_code(), "SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT");
+        }
+    }
+
+    /// Story 15-6b — les discriminants machine de `details.claim` et `details.role`.
+    #[test]
+    fn claim_side_and_role_discriminants() {
+        assert_eq!(ClaimSide::Receivable.as_str(), "receivable");
+        assert_eq!(ClaimSide::Payable.as_str(), "payable");
+        assert_eq!(SettlementAccountRole::Counterparty.as_str(), "counterparty");
+        assert_eq!(SettlementAccountRole::Rounding.as_str(), "rounding");
+        assert_eq!(
+            SettlementAccountRole::WriteOffNature.as_str(),
+            "write_off_nature"
+        );
+        assert_eq!(SettlementAccountRole::VatPayable.as_str(), "vat_payable");
+    }
 }
diff --git a/crates/kesh-db/src/repositories/invoice_settlements.rs b/crates/kesh-db/src/repositories/invoice_settlements.rs
index 2c7b52e4a..05a2c9997 100644
--- a/crates/kesh-db/src/repositories/invoice_settlements.rs
+++ b/crates/kesh-db/src/repositories/invoice_settlements.rs
@@ -20,7 +20,7 @@ const COLUMNS: &str = "id, company_id, invoice_id, journal_entry_id, amount, set
      write_off_nature, write_off_vat, created_at";
 
 use crate::entities::{InvoiceSettlement, NewInvoiceSettlement, NewJournalEntryLine};
-use crate::errors::{DbError, map_db_error};
+use crate::errors::{ClaimSide, DbError, SettlementAccountRole, map_db_error};
 use crate::repositories::invoices::line_ttc_sql;
 
 /// Forme **scalaire par facture** du total réglé — sous-requête corrélée.
@@ -617,6 +617,179 @@ pub async fn sale_rounding_account(
     }
 }
 
+// ---------------------------------------------------------------------------
+// Story 15-6b (#474) — un règlement ne vise pas le compte qu'il solde
+// ---------------------------------------------------------------------------
+
+/// Constat **pur** qu'un compte coïncide avec le compte soldé — rendu par
+/// [`ensure_not_claim_account`], consommé par [`claim_account_refusal`].
+#[derive(Debug, Clone, Copy, PartialEq, Eq)]
+pub struct ClaimAccountClash {
+    /// Le compte en cause (égal au compte soldé).
+    pub account_id: i64,
+}
+
+/// Le **compte d'écart** désigné dans les réglages qu'un geste écrit en face de
+/// la créance (Story 15-6b, AC3 bis). Sous-ensemble de
+/// [`SettlementAccountRole`] : un compte désigné est toujours comparé à une
+/// **créance** client.
+///
+/// ⚠️ Nommé `GapAccountRole`, et non `DesignatedRole` comme l'écrivait la fiche
+/// (signature indicative ; choix C-15-6b-2) : un `DesignatedRole` existe déjà
+/// dans `company_invoice_settings` (Story 15-5d), qui désigne les quatre champs
+/// que la validation et la saisie fournisseur écrivent — un autre ensemble.
+#[derive(Debug, Clone, Copy, PartialEq, Eq)]
+pub enum GapAccountRole {
+    /// `default_rounding_account_id`, quel que soit le geste.
+    Rounding,
+    /// Le compte d'une nature `discount`, `bank_fees` ou `bad_debt`.
+    WriteOffNature,
+    /// `default_vat_payable_account_id` (solde du reste).
+    VatPayable,
+}
+
+/// Le **sujet** d'une comparaison au compte soldé (Story 15-6b, AC1 ; finding
+/// F5 de la P5) : la combinaison « dette fournisseur + compte désigné » est
+/// **irreprésentable** — le règlement fournisseur n'écrit aucun compte d'écart.
+#[derive(Debug, Clone, Copy, PartialEq, Eq)]
+pub enum ClaimSubject {
+    /// La contrepartie choisie, ou celle que porte le compte bancaire du geste.
+    Counterparty(ClaimSide),
+    /// Un compte désigné dans les réglages — comparé à la créance client.
+    Designated(GapAccountRole),
+}
+
+impl ClaimSubject {
+    /// Le côté soldé : celui de la contrepartie, ou la créance pour un compte
+    /// désigné.
+    pub fn claim(self) -> ClaimSide {
+        match self {
+            Self::Counterparty(side) => side,
+            Self::Designated(_) => ClaimSide::Receivable,
+        }
+    }
+
+    /// Le rôle exposé (`details.role`), qui porte le remède.
+    pub fn role(self) -> SettlementAccountRole {
+        match self {
+            Self::Counterparty(_) => SettlementAccountRole::Counterparty,
+            Self::Designated(GapAccountRole::Rounding) => SettlementAccountRole::Rounding,
+            Self::Designated(GapAccountRole::WriteOffNature) => {
+                SettlementAccountRole::WriteOffNature
+            }
+            Self::Designated(GapAccountRole::VatPayable) => SettlementAccountRole::VatPayable,
+        }
+    }
+}
+
+/// Compare un compte que le geste écrit **en face** du compte soldé à ce compte
+/// soldé (Story 15-6b, #474). **Pure** : ni I/O ni transaction — c'est la seule
+/// partie que la 15-6d emprunte (sa garde compare la contrepartie au compte de
+/// banque).
+///
+/// ⛔ Une écriture `D X / C X` s'équilibre : rien, au grand livre, ne la refuse.
+/// Seule cette comparaison d'**identifiants** la ferme — le contrôle de type
+/// d'un compte désigné ne suffit pas, le type d'un compte qui porte des
+/// écritures se changeant avec confirmation.
+pub fn ensure_not_claim_account(
+    account_id: i64,
+    claim_account_id: i64,
+) -> Result<(), ClaimAccountClash> {
+    if account_id == claim_account_id {
+        Err(ClaimAccountClash { account_id })
+    } else {
+        Ok(())
+    }
+}
+
+/// Construit le refus [`DbError::SettlementCounterpartyIsClaimAccount`] —
+/// **seule** construction de la variante hors de l'interception de
+/// `payment_batches::confirm_batch` (qui la reconstruit avec son lot).
+///
+/// Appelée **à l'échec seulement** : elle lit le numéro du compte dans la
+/// transaction de l'appelant (la requête est écrite d'un tenant, sur une ligne,
+/// pour rester trouvable par `grep`). Une erreur SQL de cette lecture est rendue
+/// telle quelle — c'est alors elle, et non le refus, que l'appelant propage.
+/// `batch` vaut toujours `None` ici.
+pub async fn claim_account_refusal(
+    conn: &mut sqlx::MySqlConnection,
+    company_id: i64,
+    clash: ClaimAccountClash,
+    subject: ClaimSubject,
+) -> DbError {
+    let number: Result<Option<String>, DbError> =
+        sqlx::query_scalar("SELECT number FROM accounts WHERE id = ? AND company_id = ?")
+            .bind(clash.account_id)
+            .bind(company_id)
+            .fetch_optional(&mut *conn)
+            .await
+            .map_err(map_db_error);
+    match number {
+        Ok(account_number) => DbError::SettlementCounterpartyIsClaimAccount {
+            account_id: clash.account_id,
+            account_number,
+            claim: subject.claim(),
+            role: subject.role(),
+            batch: None,
+        },
+        Err(e) => e,
+    }
+}
+
+/// Garde complète d'un site : [`ensure_not_claim_account`], puis, sur
+/// coïncidence **seulement**, [`claim_account_refusal`] (Story 15-6b ; choix
+/// C-15-6b-1). Rend `Err` avec le refus — ou avec l'erreur SQL de la lecture du
+/// numéro.
+pub async fn refuse_if_claim_account(
+    conn: &mut sqlx::MySqlConnection,
+    company_id: i64,
+    account_id: i64,
+    claim_account_id: i64,
+    subject: ClaimSubject,
+) -> Result<(), DbError> {
+    match ensure_not_claim_account(account_id, claim_account_id) {
+        Ok(()) => Ok(()),
+        Err(clash) => Err(claim_account_refusal(conn, company_id, clash, subject).await),
+    }
+}
+
+/// Les `details` du refus, construits **une fois** pour ses trois
+/// consommateurs — le mapping HTTP, le `FailedProposal` du rapprochement et le
+/// `PaymentBatchFailedItem` de la création d'un lot — pour que leurs clés ne
+/// divergent pas.
+///
+/// `bankAccountId` n'est posé que s'il est fourni (rôle `counterparty` d'un
+/// geste qui porte un compte bancaire). Les clés **de lot**
+/// (`paymentBatchId`, `supplierInvoiceId`) sont hors de ce helper : le mapping
+/// HTTP, seul consommateur qui en ait, les ajoute.
+///
+/// ⚠️ **Ce qui est construit une fois, ce sont les CLÉS, pas l'extraction** :
+/// les consommateurs du rapprochement
+/// (`routes/reconciliation.rs::claim_account_failed_proposal`) et de la
+/// création d'un lot (`payment_batches.rs::validate_invoice_for_batch`)
+/// déstructurent chacun la variante `SettlementCounterpartyIsClaimAccount`
+/// par leur propre `match` avant d'appeler ce helper. Une méthode sur
+/// `DbError` qui rende directement les `details` supprimerait ces deux `match`
+/// — dette écrite au Change Log de la 15-6b (revue de code P1, finding B-6).
+pub fn claim_account_refusal_details(
+    account_id: i64,
+    account_number: Option<&str>,
+    claim: ClaimSide,
+    role: SettlementAccountRole,
+    bank_account_id: Option<i64>,
+) -> serde_json::Value {
+    let mut details = serde_json::json!({
+        "accountId": account_id,
+        "accountNumber": account_number,
+        "claim": claim.as_str(),
+        "role": role.as_str(),
+    });
+    if let Some(bank_account_id) = bank_account_id {
+        details["bankAccountId"] = serde_json::json!(bank_account_id);
+    }
+    details
+}
+
 // ---------------------------------------------------------------------------
 // Story 25-5-a (#386) — lecture exhaustive pour l'export de souveraineté
 // ---------------------------------------------------------------------------
@@ -754,4 +927,90 @@ mod tests {
             assert!(parse_write_off_vat(&bad).is_err(), "accepté : {bad}");
         }
     }
+
+    /// Story 15-6b (#474) — la comparaison est une égalité d'identifiants, et
+    /// rien d'autre.
+    #[test]
+    fn la_comparaison_au_compte_solde_est_une_egalite_d_identifiants() {
+        assert_eq!(ensure_not_claim_account(7, 8), Ok(()));
+        assert_eq!(
+            ensure_not_claim_account(8, 8),
+            Err(ClaimAccountClash { account_id: 8 })
+        );
+    }
+
+    /// Story 15-6b — le sujet rend le côté et le rôle ; un compte désigné est
+    /// toujours comparé à la créance.
+    #[test]
+    fn le_sujet_rend_le_cote_et_le_role() {
+        let cases = [
+            (
+                ClaimSubject::Counterparty(ClaimSide::Receivable),
+                ClaimSide::Receivable,
+                SettlementAccountRole::Counterparty,
+            ),
+            (
+                ClaimSubject::Counterparty(ClaimSide::Payable),
+                ClaimSide::Payable,
+                SettlementAccountRole::Counterparty,
+            ),
+            (
+                ClaimSubject::Designated(GapAccountRole::Rounding),
+                ClaimSide::Receivable,
+                SettlementAccountRole::Rounding,
+            ),
+            (
+                ClaimSubject::Designated(GapAccountRole::WriteOffNature),
+                ClaimSide::Receivable,
+                SettlementAccountRole::WriteOffNature,
+            ),
+            (
+                ClaimSubject::Designated(GapAccountRole::VatPayable),
+                ClaimSide::Receivable,
+                SettlementAccountRole::VatPayable,
+            ),
+        ];
+        for (subject, claim, role) in cases {
+            assert_eq!(subject.claim(), claim, "{subject:?}");
+            assert_eq!(subject.role(), role, "{subject:?}");
+        }
+    }
+
+    /// Story 15-6b — forme des `details`, avec et sans compte bancaire.
+    #[test]
+    fn les_details_du_refus_ont_une_seule_forme() {
+        assert_eq!(
+            claim_account_refusal_details(
+                3,
+                Some("1100"),
+                ClaimSide::Receivable,
+                SettlementAccountRole::Counterparty,
+                Some(9),
+            ),
+            serde_json::json!({
+                "accountId": 3,
+                "accountNumber": "1100",
+                "claim": "receivable",
+                "role": "counterparty",
+                "bankAccountId": 9,
+            })
+        );
+        let sans_banque = claim_account_refusal_details(
+            3,
+            None,
+            ClaimSide::Receivable,
+            SettlementAccountRole::Rounding,
+            None,
+        );
+        assert_eq!(
+            sans_banque,
+            serde_json::json!({
+                "accountId": 3,
+                "accountNumber": null,
+                "claim": "receivable",
+                "role": "rounding",
+            })
+        );
+        assert!(sans_banque.get("bankAccountId").is_none());
+    }
 }
diff --git a/crates/kesh-db/src/repositories/invoice_settlements_write.rs b/crates/kesh-db/src/repositories/invoice_settlements_write.rs
index bf41b04a8..bddee26bc 100644
--- a/crates/kesh-db/src/repositories/invoice_settlements_write.rs
+++ b/crates/kesh-db/src/repositories/invoice_settlements_write.rs
@@ -21,8 +21,10 @@ use crate::entities::{
     Journal, NewInvoiceSettlement, NewJournalEntry, SettlementChoice, SettlementKind,
     SettlementWriteOffNature,
 };
-use crate::errors::{DbError, NonPostableAccount, SettlementCancelBlocker, map_db_error};
-use crate::repositories::invoice_settlements::PaymentAgainstDue;
+use crate::errors::{
+    ClaimSide, DbError, NonPostableAccount, SettlementCancelBlocker, map_db_error,
+};
+use crate::repositories::invoice_settlements::{ClaimSubject, GapAccountRole, PaymentAgainstDue};
 use crate::repositories::journal_entries::ReversalAuthority;
 use crate::repositories::settlement_cancellation::{
     SettlementCancelHit, settlement_entry_cancel_blocker,
@@ -45,6 +47,22 @@ pub struct SettlementOutcome {
 /// ⛔ **Le trop-perçu est refusé, jamais écrit** : sinon le compte de créance
 /// passerait créditeur, une anomalie que le grand livre signalerait — mais après
 /// coup.
+///
+/// ⛔ **Un règlement ne vise pas le compte qu'il solde** (Story 15-6b, #474) : ni
+/// la contrepartie (compte interne choisi, ou compte du grand livre du compte
+/// bancaire) ni le compte d'arrondi ne peuvent être la créance lue sur la vente
+/// — l'écriture serait `D 1100 / C 1100`, équilibrée, et le reste dû baisserait
+/// sans que rien ne bouge au grand livre.
+///
+/// **Ordre des refus**, celui des lectures : statut et date ; créance (lue sur
+/// la vente) ; **contrepartie** — compte bancaire inconnu (404), sans compte lié
+/// (`CONFIGURATION_REQUIRED`), compte interne archivé ou inconnu
+/// (`INACTIVE_OR_INVALID_ACCOUNTS`), non imputable (`ACCOUNT_NOT_POSTABLE`),
+/// **puis** contrepartie = créance (`SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT`,
+/// `role: counterparty`) ; **trop-perçu** ; **compte d'arrondi** —
+/// `ROUNDING_ACCOUNT_NOT_CONFIGURED`, puis compte d'arrondi = créance
+/// (`role: rounding`). Trop-perçu et écart d'arrondi sont exclusifs. Aucun de
+/// ces refus n'écrit rien.
 pub async fn settle_invoice(
     pool: &MySqlPool,
     user_id: i64,
@@ -171,6 +189,19 @@ pub async fn settle_invoice(
         }
     };
 
+    // (3 bis) ⛔ Story 15-6b (#474) — la contrepartie n'est pas la créance.
+    //         Comparée aussitôt résolue, donc après ses propres refus et avant
+    //         le trop-perçu : un montant excessif sur 1100 rend ce refus-ci, le
+    //         défaut de fond. Aucune relecture, sauf le numéro à l'échec.
+    invoice_settlements::refuse_if_claim_account(
+        &mut tx,
+        company_id,
+        counterparty_account_id,
+        receivable_account_id,
+        ClaimSubject::Counterparty(ClaimSide::Receivable),
+    )
+    .await?;
+
     // (4) ⛔ Le trop-perçu est refusé AVANT toute écriture — à DOUBLE BORNE
     //     (Story 25-4-c3-b, AC 3) : un paiement égal au reste arrondi au centime
     //     solde la facture, l'écart passant en écriture ; au-delà du brut, tout le
@@ -185,18 +216,27 @@ pub async fn settle_invoice(
             }
             PaymentAgainstDue::Ordinary => (amount, None),
             // (4bis) Le compte d'arrondi n'est exigé QUE s'il y a un écart, et il
-            //        est revérifié ici, au moment d'écrire (AC 4).
-            PaymentAgainstDue::SettlesWithRounding { raw_due } => (
-                raw_due,
-                Some(
-                    company_invoice_settings::rounding_account_for_write(
-                        &mut tx,
-                        company_id,
-                        crate::errors::RoundingContext::Payment,
-                    )
-                    .await?,
-                ),
-            ),
+            //        est revérifié ici, au moment d'écrire (AC 4) — puis comparé
+            //        à la créance (Story 15-6b, AC3 bis) : son type, contrôlé, ne
+            //        suffit pas, celui d'un compte qui porte des écritures se
+            //        change avec confirmation.
+            PaymentAgainstDue::SettlesWithRounding { raw_due } => {
+                let rounding = company_invoice_settings::rounding_account_for_write(
+                    &mut tx,
+                    company_id,
+                    crate::errors::RoundingContext::Payment,
+                )
+                .await?;
+                invoice_settlements::refuse_if_claim_account(
+                    &mut tx,
+                    company_id,
+                    rounding,
+                    receivable_account_id,
+                    ClaimSubject::Designated(GapAccountRole::Rounding),
+                )
+                .await?;
+                (raw_due, Some(rounding))
+            }
         };
 
     // (5) Exercice OUVERT couvrant la date de règlement.
@@ -355,6 +395,18 @@ pub struct WriteOffOutcome {
 /// - ⛔ **Tant qu'un solde existe, la facture est payée** : il éteint tout le
 ///   reste, et aucun autre règlement ne s'annule avant lui
 ///   (`SettlementCancelBlocker::WriteOffExists`).
+/// - ⛔ **Aucun compte d'écart n'est la créance** (Story 15-6b, #474, AC3 bis) :
+///   le compte de la nature, celui du reste d'arrondi et celui de TVA due sont
+///   comparés par **identifiant** à la créance lue sur la vente — le contrôle de
+///   type des comptes désignés ne suffit pas (un compte qui porte des écritures
+///   change de type avec confirmation), et la TVA due n'en a aucun au moment
+///   d'écrire. Chaque comparaison suit la lecture de son compte et celle de la
+///   créance ; l'ordre des refus est donc celui des lectures : **nature**
+///   (`role: write_off_nature`, ou `rounding` pour la nature `rounding`), **reste
+///   d'arrondi** (`role: rounding` — même colonne de réglage), **TVA due**
+///   (`role: vat_payable`). Le premier égal est nommé ; une nature égale à la
+///   créance précède les refus de configuration du reste d'arrondi et de la TVA
+///   due.
 #[allow(clippy::too_many_arguments)]
 pub async fn write_off_invoice(
     pool: &MySqlPool,
@@ -439,6 +491,23 @@ pub async fn write_off_invoice(
         invoice_settlements::sale_receivable_account(&mut tx, company_id, sale_entry_id)
             .await?
             .ok_or_else(|| DbError::Invariant("écriture de vente sans ligne de débit".into()))?;
+    // (4 bis) Story 15-6b — le compte de la nature n'est pas la créance, comparé
+    //         aussitôt la créance lue (la nature a été lue avant elle ; aucun
+    //         refus métier ne les sépare, et aucune lecture ne s'avance). La
+    //         nature `rounding` lit la colonne du compte d'arrondi : son rôle est
+    //         `rounding`.
+    invoice_settlements::refuse_if_claim_account(
+        &mut tx,
+        company_id,
+        nature_account_id,
+        receivable_account_id,
+        ClaimSubject::Designated(if nature == SettlementWriteOffNature::Rounding {
+            GapAccountRole::Rounding
+        } else {
+            GapAccountRole::WriteOffNature
+        }),
+    )
+    .await?;
 
     // (5) La TVA corrigée, au prorata des taux (escompte, perte).
     let shares = if nature.corrects_vat() {
@@ -476,14 +545,22 @@ pub async fn write_off_invoice(
     let rounding_account_id = if nature == SettlementWriteOffNature::Rounding {
         Some(nature_account_id)
     } else if amount != invoice_settlements::amount_due_to_centime(amount) {
-        Some(
-            company_invoice_settings::write_off_account_for_write(
-                &mut tx,
-                company_id,
-                SettlementWriteOffNature::Rounding,
-            )
-            .await?,
+        let rounding = company_invoice_settings::write_off_account_for_write(
+            &mut tx,
+            company_id,
+            SettlementWriteOffNature::Rounding,
         )
+        .await?;
+        // Story 15-6b — le compte du reste d'arrondi n'est pas la créance.
+        invoice_settlements::refuse_if_claim_account(
+            &mut tx,
+            company_id,
+            rounding,
+            receivable_account_id,
+            ClaimSubject::Designated(GapAccountRole::Rounding),
+        )
+        .await?;
+        Some(rounding)
     } else {
         None
     };
@@ -491,7 +568,20 @@ pub async fn write_off_invoice(
     let vat_account_id = if shares.is_empty() {
         None
     } else {
-        Some(company_invoice_settings::vat_payable_account_for_write(&mut tx, company_id).await?)
+        let vat =
+            company_invoice_settings::vat_payable_account_for_write(&mut tx, company_id).await?;
+        // Story 15-6b — la TVA due n'est pas la créance. Aucun contrôle de type ne
+        // garde ce compte au moment d'écrire : cette comparaison est sa seule
+        // garde contre `D 1100 / C 1100`.
+        invoice_settlements::refuse_if_claim_account(
+            &mut tx,
+            company_id,
+            vat,
+            receivable_account_id,
+            ClaimSubject::Designated(GapAccountRole::VatPayable),
+        )
+        .await?;
+        Some(vat)
     };
 
     // (6) Exercice ouvert, puis l'écriture au journal OD.
diff --git a/crates/kesh-db/src/repositories/payment_batches.rs b/crates/kesh-db/src/repositories/payment_batches.rs
index f6cdda946..cc1d66c74 100644
--- a/crates/kesh-db/src/repositories/payment_batches.rs
+++ b/crates/kesh-db/src/repositories/payment_batches.rs
@@ -16,7 +16,8 @@ use sqlx::MySqlPool;
 use crate::entities::{
     NewAuditLogEntry, NewPaymentBatch, PaymentBatch, PaymentBatchItem, SettlementChoice,
 };
-use crate::errors::{DbError, map_db_error};
+use crate::errors::{ClaimSide, DbError, SettlementBatchContext, map_db_error};
+use crate::repositories::invoice_settlements::{self, ClaimSubject};
 use crate::repositories::{audit_log, supplier_invoices};
 
 /// Échec per-facture lors de la génération d'un lot (pattern `FailedProposal`).
@@ -96,11 +97,11 @@ pub async fn create_batch(
                 "le compte bancaire source est archivé".into(),
             ));
         }
-        if journal_account_id.is_none() {
+        let Some(bank_ledger_account_id) = journal_account_id else {
             return Err(DbError::ConfigurationRequired(
                 "bank_account.journal_account_id".into(),
             ));
-        }
+        };
 
         // (1) Valider chaque facture (FailedProposal per-facture).
         let mut accepted: Vec<Accepted> = Vec::new();
@@ -111,7 +112,15 @@ pub async fn create_batch(
             if !seen.insert(sid) {
                 continue; // doublon dans la requête : ignoré silencieusement.
             }
-            match validate_invoice_for_batch(&mut tx, company_id, sid).await? {
+            match validate_invoice_for_batch(
+                &mut tx,
+                company_id,
+                sid,
+                bank_account_id,
+                bank_ledger_account_id,
+            )
+            .await?
+            {
                 Ok(acc) => accepted.push(acc),
                 Err(f) => failed.push(f),
             }
@@ -227,10 +236,34 @@ pub async fn create_batch(
 /// (`FOR UPDATE`, sérialise vs pay/cancel/autre lot). Retourne `Ok(Accepted)`
 /// ou `Err(PaymentBatchFailedItem)` (échec métier per-facture), ou un `DbError`
 /// (échec infra → propage).
+///
+/// ⛔ **Story 15-6b (#474) — la défense principale contre un lot inconfirmable** :
+/// après ses refus existants, la dette lue sur l'écriture d'achat
+/// (`supplier_invoices::purchase_payable_line`) est comparée au compte du grand
+/// livre du compte bancaire source. Égalité → la facture va dans `failed[]`
+/// (`SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT`) : sa confirmation écrirait
+/// `D 2000 / C 2000`, et le fichier pain.001, peut-être déjà déposé à la
+/// banque, ne pourrait plus être confirmé. Une écriture d'achat sans ligne de
+/// crédit est une donnée de CETTE facture (`SUPPLIER_INVOICE_PURCHASE_ENTRY_MALFORMED`),
+/// pas une erreur globale. Une erreur SQL de la lecture du numéro, elle, est
+/// propagée comme les autres `DbError`.
+///
+/// ⚠️ **« Principale » ne veut pas dire « définitive »** : le compte du grand
+/// livre du compte bancaire est lu par `create_batch` **sans verrou** (la
+/// lecture de `bank_accounts`, au début de la création, n'est pas un
+/// `FOR UPDATE`, alors que `pay_in_tx` lit le même champ `FOR UPDATE`). Un
+/// relien concurrent du compte bancaire entre la création et la confirmation
+/// peut donc laisser entrer une facture que la confirmation refusera : c'est le
+/// cas que la garde de seconde ligne de `confirm_batch` (refus intercepté et
+/// contextualisé) est faite pour tenir. La garde de création est
+/// **consultative** — elle évite le cas courant, elle ne le rend pas
+/// impossible (revue de code P1, finding B-3).
 async fn validate_invoice_for_batch(
     tx: &mut sqlx::Transaction<'_, sqlx::MySql>,
     company_id: i64,
     sid: i64,
+    bank_account_id: i64,
+    bank_ledger_account_id: i64,
 ) -> Result<Result<Accepted, PaymentBatchFailedItem>, DbError> {
     fn fail(sid: i64, code: &str) -> Result<Accepted, PaymentBatchFailedItem> {
         Err(PaymentBatchFailedItem {
@@ -240,16 +273,19 @@ async fn validate_invoice_for_batch(
         })
     }
 
-    // (status, creditor_iban, creditor_qr_iban, payment_reference, total_amount)
+    // (status, creditor_iban, creditor_qr_iban, payment_reference, total_amount,
+    //  purchase_journal_entry_id)
     type InvoiceCoordsRow = (
         String,
         Option<String>,
         Option<String>,
         Option<String>,
         Decimal,
+        i64,
     );
     let row: Option<InvoiceCoordsRow> = sqlx::query_as(
-        "SELECT status, creditor_iban, creditor_qr_iban, payment_reference, total_amount \
+        "SELECT status, creditor_iban, creditor_qr_iban, payment_reference, total_amount, \
+                purchase_journal_entry_id \
              FROM supplier_invoices WHERE id = ? AND company_id = ? FOR UPDATE",
     )
     .bind(sid)
@@ -258,7 +294,7 @@ async fn validate_invoice_for_batch(
     .await
     .map_err(map_db_error)?;
 
-    let Some((status, iban, qr_iban, _reference, total_amount)) = row else {
+    let Some((status, iban, qr_iban, _reference, total_amount, purchase_entry_id)) = row else {
         return Ok(fail(sid, "SUPPLIER_INVOICE_NOT_FOUND"));
     };
     if status != "open" {
@@ -293,6 +329,54 @@ async fn validate_invoice_for_batch(
         return Ok(fail(sid, "INVALID_IBAN"));
     }
 
+    // Story 15-6b — la dette, lue sur l'écriture d'achat, n'est pas le compte de
+    // banque du lot.
+    let Some((payable_account_id, _ttc)) =
+        supplier_invoices::purchase_payable_line(tx, company_id, purchase_entry_id).await?
+    else {
+        return Ok(Err(PaymentBatchFailedItem {
+            supplier_invoice_id: sid,
+            error_code: "SUPPLIER_INVOICE_PURCHASE_ENTRY_MALFORMED".to_string(),
+            details: Some(serde_json::json!({
+                "reason": "no_credit_line_on_purchase_entry",
+                "purchaseEntryId": purchase_entry_id,
+            })),
+        }));
+    };
+    if let Err(refusal) = invoice_settlements::refuse_if_claim_account(
+        tx,
+        company_id,
+        bank_ledger_account_id,
+        payable_account_id,
+        ClaimSubject::Counterparty(ClaimSide::Payable),
+    )
+    .await
+    {
+        return match &refusal {
+            // Le refus métier devient un item de `failed[]`, `details` par le
+            // helper commun (mêmes clés que le rapprochement et le mapping HTTP).
+            DbError::SettlementCounterpartyIsClaimAccount {
+                account_id,
+                account_number,
+                claim,
+                role,
+                ..
+            } => Ok(Err(PaymentBatchFailedItem {
+                supplier_invoice_id: sid,
+                error_code: refusal.error_code().to_string(),
+                details: Some(invoice_settlements::claim_account_refusal_details(
+                    *account_id,
+                    account_number.as_deref(),
+                    *claim,
+                    *role,
+                    Some(bank_account_id),
+                )),
+            })),
+            // Erreur SQL de la lecture du numéro : échec infra de toute la création.
+            _ => Err(refusal),
+        };
+    }
+
     Ok(Ok(Accepted {
         supplier_invoice_id: sid,
         amount: total_amount,
@@ -301,6 +385,18 @@ async fn validate_invoice_for_batch(
 
 /// Confirme un lot `generated` : poste les règlements de toutes les factures
 /// dans UNE transaction atomique. Pré-check du compte source archivé.
+///
+/// ⛔ **Story 15-6b (#474) — deux contrôles, et pourquoi le second subsiste.** La
+/// création du lot refuse déjà une facture dont le compte créanciers est le
+/// compte de banque du lot. Mais le compte bancaire a pu être **relié** entre la
+/// création et la confirmation : la garde de `pay_in_tx` refuse alors le
+/// règlement, et la confirmation entière échoue (transaction atomique, le lot
+/// reste `generated`, rien d'écrit). Le refus est **intercepté** pour porter le
+/// lot et la facture (`SettlementBatchContext`, numéro de facture relu ici) :
+/// le remède n'est pas celui du règlement unitaire. **Deux issues** : relier le
+/// compte bancaire à son propre compte de banque puis confirmer de nouveau, ou
+/// annuler le lot (`cancel_batch` — les factures redeviennent réglables à
+/// l'unité) et régler la facture depuis sa fiche.
 pub async fn confirm_batch(
     pool: &MySqlPool,
     company_id: i64,
@@ -357,7 +453,7 @@ pub async fn confirm_batch(
         .map_err(map_db_error)?;
 
         for item in &items {
-            supplier_invoices::pay_in_tx(
+            let paid = supplier_invoices::pay_in_tx(
                 &mut tx,
                 company_id,
                 item.supplier_invoice_id,
@@ -367,7 +463,43 @@ pub async fn confirm_batch(
                 payment_date,
                 user_id,
             )
-            .await?;
+            .await;
+            match paid {
+                Ok(_) => {}
+                // Story 15-6b — le refus « contrepartie = dette », reconstruit avec
+                // son lot. La transaction reste utilisable : c'est un refus métier,
+                // aucune erreur SQL ne l'a précédé.
+                Err(DbError::SettlementCounterpartyIsClaimAccount {
+                    account_id,
+                    account_number,
+                    claim,
+                    role,
+                    batch: None,
+                }) => {
+                    let supplier_invoice_number: Option<String> = sqlx::query_scalar(
+                        "SELECT supplier_invoice_number FROM supplier_invoices \
+                         WHERE id = ? AND company_id = ?",
+                    )
+                    .bind(item.supplier_invoice_id)
+                    .bind(company_id)
+                    .fetch_optional(&mut *tx)
+                    .await
+                    .map_err(map_db_error)?
+                    .flatten();
+                    return Err(DbError::SettlementCounterpartyIsClaimAccount {
+                        account_id,
+                        account_number,
+                        claim,
+                        role,
+                        batch: Some(SettlementBatchContext {
+                            payment_batch_id: batch_id,
+                            supplier_invoice_id: item.supplier_invoice_id,
+                            supplier_invoice_number,
+                        }),
+                    });
+                }
+                Err(e) => return Err(e),
+            }
         }
 
         // (4) Lot → confirmed.
diff --git a/crates/kesh-db/src/repositories/supplier_invoices.rs b/crates/kesh-db/src/repositories/supplier_invoices.rs
index 4f1791919..007693f98 100644
--- a/crates/kesh-db/src/repositories/supplier_invoices.rs
+++ b/crates/kesh-db/src/repositories/supplier_invoices.rs
@@ -23,9 +23,10 @@ use crate::entities::{
     NewAuditLogEntry, NewJournalEntryLine, NewSupplierInvoice, SettlementChoice, SupplierInvoice,
     SupplierInvoiceLine,
 };
-use crate::errors::{DbError, NonPostableAccount, map_db_error};
+use crate::errors::{ClaimSide, DbError, NonPostableAccount, map_db_error};
 use crate::repositories::audit_log;
 use crate::repositories::company_invoice_settings::{DesignatedRole, GeneratedLines};
+use crate::repositories::invoice_settlements::{self, ClaimSubject};
 
 /// SELECT scopé multi-tenant (anti-IDOR — toujours `AND company_id = ?`).
 const FIND_SCOPED_SQL: &str = "SELECT id, company_id, contact_id, supplier_invoice_number, status, \
@@ -645,6 +646,35 @@ async fn in_generated_batch(
     .map_err(map_db_error)
 }
 
+/// La ligne de **crédit** de l'écriture d'achat — `(compte créanciers, TTC)` —
+/// ou `None` si l'écriture n'en a pas (Story 15-6b, #474 ; choix C-15-6-11).
+///
+/// Lecteur sœur de `invoice_settlements::sale_receivable_account` : la dette se
+/// lit **sur l'écriture d'achat**, jamais sur les réglages, pour que le compte
+/// se solde exactement quoi qu'il soit arrivé à la configuration. Il diffère du
+/// lecteur de la vente (ligne de crédit, et le montant). Deux appelants :
+/// `pay_in_tx` (dont `None` est un `Invariant`) et la création d'un lot de
+/// paiement (dont `None` est un refus de **cette** facture,
+/// `SUPPLIER_INVOICE_PURCHASE_ENTRY_MALFORMED`). Portée par `je.company_id`.
+/// Aucun verrou : les lignes d'une écriture d'achat sont gelées.
+pub async fn purchase_payable_line(
+    conn: &mut sqlx::MySqlConnection,
+    company_id: i64,
+    purchase_entry_id: i64,
+) -> Result<Option<(i64, Decimal)>, DbError> {
+    sqlx::query_as(
+        "SELECT jel.account_id, jel.credit FROM journal_entry_lines jel \
+         JOIN journal_entries je ON je.id = jel.entry_id \
+         WHERE jel.entry_id = ? AND je.company_id = ? AND jel.credit > 0 \
+         ORDER BY jel.id LIMIT 1",
+    )
+    .bind(purchase_entry_id)
+    .bind(company_id)
+    .fetch_optional(&mut *conn)
+    .await
+    .map_err(map_db_error)
+}
+
 /// Règle une facture fournisseur `open` (choix binaire). Poste l'écriture de
 /// règlement et passe en `paid`. Refuse si la facture est dans un lot `generated`.
 pub async fn pay(
@@ -708,18 +738,13 @@ pub async fn pay_in_tx(
 
     // (2) Compte débité (créanciers) ET montant = ligne de crédit de l'écriture
     //     d'achat → solde 2000 garanti à 0 quelle que soit l'évolution des settings.
-    let (payable_account_id, ttc): (i64, Decimal) = sqlx::query_as(
-        "SELECT jel.account_id, jel.credit FROM journal_entry_lines jel \
-         JOIN journal_entries je ON je.id = jel.entry_id \
-         WHERE jel.entry_id = ? AND je.company_id = ? AND jel.credit > 0 \
-         ORDER BY jel.id LIMIT 1",
-    )
-    .bind(inv.purchase_journal_entry_id)
-    .bind(company_id)
-    .fetch_optional(&mut **tx)
-    .await
-    .map_err(map_db_error)?
-    .ok_or_else(|| DbError::Invariant("écriture d'achat sans ligne de crédit créanciers".into()))?;
+    //     Lecteur partagé avec la création d'un lot (Story 15-6b).
+    let (payable_account_id, ttc) =
+        purchase_payable_line(tx, company_id, inv.purchase_journal_entry_id)
+            .await?
+            .ok_or_else(|| {
+                DbError::Invariant("écriture d'achat sans ligne de crédit créanciers".into())
+            })?;
 
     // (3) Contrepartie selon le choix binaire (company-scoped).
     let (counterparty_account_id, settlement_type, bank_account_id, internal_account_id, journal) =
@@ -754,7 +779,8 @@ pub async fn pay_in_tx(
                 // postabilité de la 14-3b, donc ce SELECT est le seul contrôle.
                 //
                 // Ici l'écran filtre déjà `active && postable`
-                // (`supplier-invoices/[id]/+page.svelte:66`), si bien que le
+                // (`supplier-invoices/[id]/+page.svelte`, chargement des comptes
+                // internes), si bien que le
                 // trou n'était atteignable que par appel direct à l'API — à la
                 // différence de son jumeau côté client, où l'écran offrait le
                 // compte. Le fermer quand même : une garde serveur ne se déduit
@@ -764,6 +790,9 @@ pub async fn pay_in_tx(
                 // de revue de code de la Story 24-5, #375) — la lentille avait
                 // nommé ce fichier pour SA validation de compte de charge, pas
                 // pour ce site-ci.
+                //
+                // Jumeau aussi pour la garde qui suit l'étape (3) : la
+                // contrepartie n'est pas le compte créanciers (Story 15-6b).
                 let account: Option<(bool, bool, String)> = sqlx::query_as(
                     "SELECT active, postable, number FROM accounts WHERE id = ? AND company_id = ? \
                      FOR UPDATE",
@@ -796,6 +825,20 @@ pub async fn pay_in_tx(
             }
         };
 
+    // (3 bis) ⛔ Story 15-6b (#474) — la contrepartie n'est pas la dette :
+    //         `D 2000 / C 2000` s'équilibre, et la facture passerait « payée »
+    //         sans paiement. Comparée aussitôt résolue, après ses propres refus.
+    //         À la confirmation d'un lot, `confirm_batch` intercepte ce refus pour
+    //         le contextualiser.
+    invoice_settlements::refuse_if_claim_account(
+        tx,
+        company_id,
+        counterparty_account_id,
+        payable_account_id,
+        ClaimSubject::Counterparty(ClaimSide::Payable),
+    )
+    .await?;
+
     // (4) Exercice ouvert couvrant la date de règlement.
     let fy = fiscal_years::find_open_covering_date(tx, company_id, payment_date)
         .await?
diff --git a/crates/kesh-db/tests/invoice_settlement.rs b/crates/kesh-db/tests/invoice_settlement.rs
index ea4182d6c..cb3f1e85f 100644
--- a/crates/kesh-db/tests/invoice_settlement.rs
+++ b/crates/kesh-db/tests/invoice_settlement.rs
@@ -1265,3 +1265,326 @@ async fn une_cloture_concurrente_attend_l_annulation(pool: MySqlPool) {
         "rien n'a été annulé"
     );
 }
+
+// ---------------------------------------------------------------------------
+// Story 15-6b (#474) — un règlement ne vise pas le compte qu'il solde
+// ---------------------------------------------------------------------------
+mod contrepartie_distincte_de_la_creance {
+    use super::*;
+    use kesh_db::errors::{ClaimSide, SettlementAccountRole};
+
+    /// Un compte bancaire lié au compte du grand livre `ledger_id`.
+    async fn bank_account_linked_to(
+        pool: &MySqlPool,
+        seeded: &SeededCompany,
+        ledger_id: i64,
+    ) -> i64 {
+        sqlx::query_scalar(
+            "INSERT INTO bank_accounts (company_id, bank_name, iban, is_primary, journal_account_id) \
+             VALUES (?, 'UBS', 'CH4431999123000889012', TRUE, ?) RETURNING id",
+        )
+        .bind(seeded.company_id)
+        .bind(ledger_id)
+        .fetch_one(pool)
+        .await
+        .expect("compte bancaire")
+    }
+
+    /// Le compte de banque 1020, absent du seed (`test_fixtures.rs`).
+    async fn bank_ledger_1020(pool: &MySqlPool, seeded: &SeededCompany) -> i64 {
+        sqlx::query_scalar(
+            "INSERT INTO accounts (company_id, number, name, account_type, active, postable) \
+             VALUES (?, '1020', 'Banque', 'Asset', 1, 1) RETURNING id",
+        )
+        .bind(seeded.company_id)
+        .fetch_one(pool)
+        .await
+        .expect("compte banque")
+    }
+
+    async fn settle(
+        pool: &MySqlPool,
+        seeded: &SeededCompany,
+        inv_id: i64,
+        choice: SettlementChoice,
+        amount: Decimal,
+    ) -> Result<invoice_settlements_write::SettlementOutcome, DbError> {
+        invoice_settlements_write::settle_invoice(
+            pool,
+            seeded.admin_user_id,
+            seeded.company_id,
+            inv_id,
+            choice,
+            amount,
+            ymd(2026, 3, 5),
+        )
+        .await
+    }
+
+    async fn scalar(pool: &MySqlPool, sql: &str, id: i64) -> i64 {
+        sqlx::query_scalar(sql)
+            .bind(id)
+            .fetch_one(pool)
+            .await
+            .expect("lecture")
+    }
+
+    /// Rien n'est écrit : ni écriture, ni ligne de règlement, ni `paid_at`, ni
+    /// `version`, ni audit.
+    async fn assert_nothing_written(
+        pool: &MySqlPool,
+        inv_id: i64,
+        (entries_before, version_before): (i64, i32),
+    ) {
+        let (paid_at, version): (Option<chrono::NaiveDateTime>, i32) =
+            sqlx::query_as("SELECT paid_at, version FROM invoices WHERE id = ?")
+                .bind(inv_id)
+                .fetch_one(pool)
+                .await
+                .unwrap();
+        assert!(paid_at.is_none(), "paid_at inchangé");
+        assert_eq!(version, version_before, "version inchangée");
+        assert_eq!(
+            scalar(
+                pool,
+                "SELECT COUNT(*) FROM invoice_settlements WHERE invoice_id = ?",
+                inv_id
+            )
+            .await,
+            0,
+            "aucune ligne de règlement"
+        );
+        let entries: i64 = sqlx::query_scalar("SELECT COUNT(*) FROM journal_entries")
+            .fetch_one(pool)
+            .await
+            .unwrap();
+        assert_eq!(entries, entries_before, "aucune écriture neuve");
+        assert_eq!(
+            scalar(
+                pool,
+                "SELECT COUNT(*) FROM audit_log WHERE entity_type = 'invoice' \
+                 AND action IN ('invoice.paid', 'invoice.partially_settled') AND entity_id = ?",
+                inv_id
+            )
+            .await,
+            0,
+            "aucun audit"
+        );
+    }
+
+    /// L'état avant le geste : nombre d'écritures, `version` de la facture.
+    async fn before(pool: &MySqlPool, inv_id: i64) -> (i64, i32) {
+        let entries: i64 = sqlx::query_scalar("SELECT COUNT(*) FROM journal_entries")
+            .fetch_one(pool)
+            .await
+            .unwrap();
+        let version: i32 = sqlx::query_scalar("SELECT version FROM invoices WHERE id = ?")
+            .bind(inv_id)
+            .fetch_one(pool)
+            .await
+            .unwrap();
+        (entries, version)
+    }
+
+    fn assert_counterparty_refusal(err: &DbError, receivable: i64) {
+        match err {
+            DbError::SettlementCounterpartyIsClaimAccount {
+                account_id,
+                account_number,
+                claim: ClaimSide::Receivable,
+                role: SettlementAccountRole::Counterparty,
+                batch: None,
+            } => {
+                assert_eq!(*account_id, receivable);
+                assert_eq!(account_number.as_deref(), Some("1100"));
+            }
+            other => panic!("refus de contrepartie attendu, obtenu {other:?}"),
+        }
+    }
+
+    /// Test 1 — **compte interne = créance** : `D 1100 / C 1100` refusé.
+    #[sqlx::test(migrations = "./test-schema")]
+    async fn an_internal_account_that_is_the_receivable_is_refused(pool: MySqlPool) {
+        let seeded = seed_accounting_company(&pool).await.expect("seed");
+        let creance = seeded.accounts["1100"];
+        let inv_id = validated_invoice(&pool, &seeded, dec!(100.00), ymd(2026, 3, 1)).await;
+        let n = before(&pool, inv_id).await;
+
+        let err = settle(
+            &pool,
+            &seeded,
+            inv_id,
+            SettlementChoice::InternalAccount {
+                account_id: creance,
+            },
+            dec!(100.00),
+        )
+        .await
+        .expect_err("la créance comme contrepartie doit être refusée");
+        assert_counterparty_refusal(&err, creance);
+        assert_nothing_written(&pool, inv_id, n).await;
+    }
+
+    /// Test 2 — **virement sur un compte bancaire lié au 1100** : même refus.
+    #[sqlx::test(migrations = "./test-schema")]
+    async fn a_bank_account_linked_to_the_receivable_is_refused(pool: MySqlPool) {
+        let seeded = seed_accounting_company(&pool).await.expect("seed");
+        let creance = seeded.accounts["1100"];
+        let inv_id = validated_invoice(&pool, &seeded, dec!(100.00), ymd(2026, 3, 1)).await;
+        let bank_account_id = bank_account_linked_to(&pool, &seeded, creance).await;
+        let n = before(&pool, inv_id).await;
+
+        let err = settle(
+            &pool,
+            &seeded,
+            inv_id,
+            SettlementChoice::BankTransfer { bank_account_id },
+            dec!(100.00),
+        )
+        .await
+        .expect_err("un compte bancaire lié à la créance doit être refusé");
+        assert_counterparty_refusal(&err, creance);
+        assert_nothing_written(&pool, inv_id, n).await;
+    }
+
+    /// Test 3 — non-régression : un règlement ordinaire, par banque 1020 puis
+    /// par la caisse, reste accepté.
+    #[sqlx::test(migrations = "./test-schema")]
+    async fn an_ordinary_settlement_is_still_accepted(pool: MySqlPool) {
+        let seeded = seed_accounting_company(&pool).await.expect("seed");
+        let inv_id = validated_invoice(&pool, &seeded, dec!(100.00), ymd(2026, 3, 1)).await;
+        let ledger = bank_ledger_1020(&pool, &seeded).await;
+        let bank_account_id = bank_account_linked_to(&pool, &seeded, ledger).await;
+
+        let out = settle(
+            &pool,
+            &seeded,
+            inv_id,
+            SettlementChoice::BankTransfer { bank_account_id },
+            dec!(30.00),
+        )
+        .await
+        .expect("virement");
+        assert_eq!(out.amount_due_after, dec!(70.00));
+        let out = settle(
+            &pool,
+            &seeded,
+            inv_id,
+            SettlementChoice::InternalAccount {
+                account_id: seeded.accounts["1000"],
+            },
+            dec!(70.00),
+        )
+        .await
+        .expect("espèces");
+        assert!(out.fully_settled);
+        assert_eq!(solde(&pool, seeded.accounts["1100"]).await, Decimal::ZERO);
+    }
+
+    /// Test 4 — **montant excessif sur 1100** : le refus est celui de la
+    /// contrepartie, pas le trop-perçu (la contrepartie précède).
+    #[sqlx::test(migrations = "./test-schema")]
+    async fn the_counterparty_refusal_comes_before_the_overpayment(pool: MySqlPool) {
+        let seeded = seed_accounting_company(&pool).await.expect("seed");
+        let creance = seeded.accounts["1100"];
+        let inv_id = validated_invoice(&pool, &seeded, dec!(100.00), ymd(2026, 3, 1)).await;
+        let n = before(&pool, inv_id).await;
+
+        let err = settle(
+            &pool,
+            &seeded,
+            inv_id,
+            SettlementChoice::InternalAccount {
+                account_id: creance,
+            },
+            dec!(500.00),
+        )
+        .await
+        .expect_err("refus attendu");
+        assert_counterparty_refusal(&err, creance);
+        assert_nothing_written(&pool, inv_id, n).await;
+    }
+
+    /// Test 9 — **ordre** : la créance archivée comme compte interne rend
+    /// l'ancien refus (`INACTIVE_OR_INVALID_ACCOUNTS`), qui prime.
+    #[sqlx::test(migrations = "./test-schema")]
+    async fn an_archived_receivable_as_internal_account_keeps_the_older_refusal(pool: MySqlPool) {
+        let seeded = seed_accounting_company(&pool).await.expect("seed");
+        let creance = seeded.accounts["1100"];
+        let inv_id = validated_invoice(&pool, &seeded, dec!(100.00), ymd(2026, 3, 1)).await;
+        sqlx::query("UPDATE accounts SET active = FALSE WHERE id = ?")
+            .bind(creance)
+            .execute(&pool)
+            .await
+            .unwrap();
+
+        let err = settle(
+            &pool,
+            &seeded,
+            inv_id,
+            SettlementChoice::InternalAccount {
+                account_id: creance,
+            },
+            dec!(100.00),
+        )
+        .await
+        .expect_err("refus attendu");
+        assert!(
+            matches!(err, DbError::InactiveOrInvalidAccounts),
+            "l'ancien refus prime : {err:?}"
+        );
+    }
+
+    /// Test 11 — **arrondi du règlement = créance** (AC3 bis) : la créance
+    /// retypée en charge et désignée compte d'arrondi ; un paiement au centime
+    /// d'un reste brut hors centime, par la caisse, écrirait l'écart sur 1100.
+    /// Refus `role: Rounding` — le compte interne, valide, a été contrôlé avant.
+    #[sqlx::test(migrations = "./test-schema")]
+    async fn a_payment_rounding_account_that_is_the_receivable_is_refused(pool: MySqlPool) {
+        let seeded = seed_accounting_company(&pool).await.expect("seed");
+        let creance = seeded.accounts["1100"];
+        kesh_db::test_fixtures::designate_rounding_account(&pool, seeded.company_id)
+            .await
+            .expect("compte d'arrondi");
+        let inv_id = validated_invoice(&pool, &seeded, dec!(10.0050), ymd(2026, 3, 1)).await;
+        sqlx::query("UPDATE accounts SET account_type = 'Expense', role = NULL WHERE id = ?")
+            .bind(creance)
+            .execute(&pool)
+            .await
+            .unwrap();
+        sqlx::query(
+            "UPDATE company_invoice_settings SET default_rounding_account_id = ? WHERE company_id = ?",
+        )
+        .bind(creance)
+        .bind(seeded.company_id)
+        .execute(&pool)
+        .await
+        .unwrap();
+        let n = before(&pool, inv_id).await;
+
+        let err = settle(
+            &pool,
+            &seeded,
+            inv_id,
+            SettlementChoice::InternalAccount {
+                account_id: seeded.accounts["1000"],
+            },
+            dec!(10.01),
+        )
+        .await
+        .expect_err("refus attendu");
+        assert!(
+            matches!(
+                err,
+                DbError::SettlementCounterpartyIsClaimAccount {
+                    claim: ClaimSide::Receivable,
+                    role: SettlementAccountRole::Rounding,
+                    batch: None,
+                    ..
+                }
+            ),
+            "{err:?}"
+        );
+        assert_nothing_written(&pool, inv_id, n).await;
+    }
+}
diff --git a/crates/kesh-db/tests/invoice_write_off.rs b/crates/kesh-db/tests/invoice_write_off.rs
index d63803f96..6d830e412 100644
--- a/crates/kesh-db/tests/invoice_write_off.rs
+++ b/crates/kesh-db/tests/invoice_write_off.rs
@@ -14,7 +14,7 @@ use kesh_db::entities::{
     NewCreditNote, NewInvoice, NewInvoiceLine, NewJournalEntry, NewJournalEntryLine,
     SettlementChoice, SettlementWriteOffNature as Nature,
 };
-use kesh_db::errors::{DbError, SettlementCancelBlocker};
+use kesh_db::errors::{ClaimSide, DbError, SettlementAccountRole, SettlementCancelBlocker};
 use kesh_db::repositories::{
     credit_notes, invoice_settlements, invoice_settlements_write, invoices, reconciliation,
     reconciliation_cancel,
@@ -1186,3 +1186,254 @@ fn write_off_lines_put_a_sub_half_centime_remainder_on_the_rounding_account() {
         vec![(9, dec!(0.0040), dec!(0)), (2, dec!(0), dec!(0.0040))]
     );
 }
+
+// ---------------------------------------------------------------------------
+// Story 15-6b (#474, AC3 bis) — un compte d'écart désigné n'est pas la créance
+// ---------------------------------------------------------------------------
+
+/// Le chemin `confirm_retype` sans la route : la créance 1100 devient un compte
+/// de `account_type` (rôle retiré), et porte toujours la créance des ventes
+/// déjà validées. C'est ce qui rend le contrôle de TYPE d'un compte désigné
+/// insuffisant.
+async fn retype_receivable(pool: &MySqlPool, seeded: &SeededCompany, account_type: &str) {
+    sqlx::query("UPDATE accounts SET account_type = ?, role = NULL WHERE id = ?")
+        .bind(account_type)
+        .bind(seeded.accounts["1100"])
+        .execute(pool)
+        .await
+        .expect("changement de type");
+}
+
+/// Désigne `account_id` dans la colonne `column` des réglages de facturation.
+async fn designate(
+    pool: &MySqlPool,
+    seeded: &SeededCompany,
+    column: &str,
+    account_id: Option<i64>,
+) {
+    sqlx::query(&format!(
+        "UPDATE company_invoice_settings SET {column} = ? WHERE company_id = ?"
+    ))
+    .bind(account_id)
+    .bind(seeded.company_id)
+    .execute(pool)
+    .await
+    .expect("désignation");
+}
+
+/// Rien n'a été écrit : facture non payée, version inchangée, aucune ligne de
+/// règlement, aucune écriture neuve, aucun audit de solde.
+async fn assert_nothing_written(
+    pool: &MySqlPool,
+    inv: i64,
+    version_before: i32,
+    entries_before: i64,
+) {
+    let (paid_at, version): (Option<chrono::NaiveDateTime>, i32) =
+        sqlx::query_as("SELECT paid_at, version FROM invoices WHERE id = ?")
+            .bind(inv)
+            .fetch_one(pool)
+            .await
+            .unwrap();
+    assert!(paid_at.is_none(), "la facture ne doit pas être payée");
+    assert_eq!(version, version_before, "version inchangée");
+    let settlements: i64 =
+        sqlx::query_scalar("SELECT COUNT(*) FROM invoice_settlements WHERE invoice_id = ?")
+            .bind(inv)
+            .fetch_one(pool)
+            .await
+            .unwrap();
+    assert_eq!(settlements, 0, "aucune ligne de règlement");
+    let entries: i64 = sqlx::query_scalar("SELECT COUNT(*) FROM journal_entries")
+        .fetch_one(pool)
+        .await
+        .unwrap();
+    assert_eq!(entries, entries_before, "aucune écriture neuve");
+    let audits: i64 = sqlx::query_scalar(
+        "SELECT COUNT(*) FROM audit_log WHERE action = 'invoice.written_off' AND entity_id = ?",
+    )
+    .bind(inv)
+    .fetch_one(pool)
+    .await
+    .unwrap();
+    assert_eq!(audits, 0, "aucun audit");
+}
+
+async fn entry_count(pool: &MySqlPool) -> i64 {
+    sqlx::query_scalar("SELECT COUNT(*) FROM journal_entries")
+        .fetch_one(pool)
+        .await
+        .unwrap()
+}
+
+/// Story 15-6b, test 10 — **nature = créance** : la créance 1100 retypée en
+/// charge et désignée compte d'escompte ; solder en escompte écrirait
+/// `D 1100 / C 1100`. Refus `role: WriteOffNature`, rien d'écrit.
+#[sqlx::test(migrations = "./test-schema")]
+async fn a_write_off_nature_account_that_is_the_receivable_is_refused(pool: MySqlPool) {
+    let seeded = company(&pool).await;
+    let inv = validated_invoice(&pool, &seeded, &[(dec!(100.00), dec!(0))]).await;
+    retype_receivable(&pool, &seeded, "Expense").await;
+    designate(
+        &pool,
+        &seeded,
+        "default_discount_account_id",
+        Some(seeded.accounts["1100"]),
+    )
+    .await;
+    let (v, n) = (version(&pool, inv).await, entry_count(&pool).await);
+
+    let err = write_off(&pool, &seeded, inv, Nature::Discount)
+        .await
+        .unwrap_err();
+    match err {
+        DbError::SettlementCounterpartyIsClaimAccount {
+            account_id,
+            ref account_number,
+            claim: ClaimSide::Receivable,
+            role: SettlementAccountRole::WriteOffNature,
+            batch: None,
+        } => {
+            assert_eq!(account_id, seeded.accounts["1100"]);
+            assert_eq!(account_number.as_deref(), Some("1100"));
+        }
+        other => panic!("refus attendu, obtenu {other:?}"),
+    }
+    assert_nothing_written(&pool, inv, v, n).await;
+}
+
+/// Story 15-6b, test 10 bis — **reste d'arrondi = créance** : la nature est un
+/// compte de charge distinct, mais le reste à quatre décimales envoie sa
+/// fraction de centime au compte d'arrondi, qui est la créance retypée. Le rôle
+/// suit la COLONNE lue (`rounding`), pas la nature du geste.
+#[sqlx::test(migrations = "./test-schema")]
+async fn a_rounding_remainder_account_that_is_the_receivable_is_refused_as_rounding(
+    pool: MySqlPool,
+) {
+    let seeded = company(&pool).await;
+    let inv = validated_invoice(&pool, &seeded, &[(dec!(3.3350), dec!(0))]).await;
+    retype_receivable(&pool, &seeded, "Expense").await;
+    designate(
+        &pool,
+        &seeded,
+        "default_rounding_account_id",
+        Some(seeded.accounts["1100"]),
+    )
+    .await;
+    let (v, n) = (version(&pool, inv).await, entry_count(&pool).await);
+
+    let err = write_off(&pool, &seeded, inv, Nature::Discount)
+        .await
+        .unwrap_err();
+    assert!(
+        matches!(
+            err,
+            DbError::SettlementCounterpartyIsClaimAccount {
+                claim: ClaimSide::Receivable,
+                role: SettlementAccountRole::Rounding,
+                ..
+            }
+        ),
+        "{err:?}"
+    );
+    assert_nothing_written(&pool, inv, v, n).await;
+}
+
+/// Story 15-6b — la nature `rounding` EST le compte d'arrondi : une seule
+/// comparaison, sous `role: Rounding`.
+#[sqlx::test(migrations = "./test-schema")]
+async fn the_rounding_nature_on_the_receivable_is_refused_as_rounding(pool: MySqlPool) {
+    let seeded = company(&pool).await;
+    let inv = validated_invoice(&pool, &seeded, &[(dec!(0.0300), dec!(0))]).await;
+    retype_receivable(&pool, &seeded, "Expense").await;
+    designate(
+        &pool,
+        &seeded,
+        "default_rounding_account_id",
+        Some(seeded.accounts["1100"]),
+    )
+    .await;
+    let (v, n) = (version(&pool, inv).await, entry_count(&pool).await);
+
+    let err = write_off(&pool, &seeded, inv, Nature::Rounding)
+        .await
+        .unwrap_err();
+    assert!(
+        matches!(
+            err,
+            DbError::SettlementCounterpartyIsClaimAccount {
+                role: SettlementAccountRole::Rounding,
+                ..
+            }
+        ),
+        "{err:?}"
+    );
+    assert_nothing_written(&pool, inv, v, n).await;
+}
+
+/// Story 15-6b, test 10 ter — **ordre des refus du solde** : la nature égale à
+/// la créance est refusée aussitôt la créance lue, AVANT la lecture de la TVA
+/// due — donc avant son `CONFIGURATION_REQUIRED`.
+#[sqlx::test(migrations = "./test-schema")]
+async fn a_nature_on_the_receivable_is_refused_before_a_missing_vat_payable(pool: MySqlPool) {
+    let seeded = company(&pool).await;
+    let inv = validated_invoice(&pool, &seeded, &[(dec!(100.00), dec!(8.1))]).await;
+    retype_receivable(&pool, &seeded, "Expense").await;
+    designate(
+        &pool,
+        &seeded,
+        "default_discount_account_id",
+        Some(seeded.accounts["1100"]),
+    )
+    .await;
+    designate(&pool, &seeded, "default_vat_payable_account_id", None).await;
+    let (v, n) = (version(&pool, inv).await, entry_count(&pool).await);
+
+    let err = write_off(&pool, &seeded, inv, Nature::Discount)
+        .await
+        .unwrap_err();
+    assert!(
+        matches!(
+            err,
+            DbError::SettlementCounterpartyIsClaimAccount {
+                role: SettlementAccountRole::WriteOffNature,
+                ..
+            }
+        ),
+        "la nature précède la TVA due : {err:?}"
+    );
+    assert_nothing_written(&pool, inv, v, n).await;
+}
+
+/// Story 15-6b — **TVA due = créance** : aucun contrôle de type ne garde ce
+/// compte au moment d'écrire ; la comparaison est sa seule garde.
+#[sqlx::test(migrations = "./test-schema")]
+async fn a_vat_payable_account_that_is_the_receivable_is_refused(pool: MySqlPool) {
+    let seeded = company(&pool).await;
+    let inv = validated_invoice(&pool, &seeded, &[(dec!(100.00), dec!(8.1))]).await;
+    retype_receivable(&pool, &seeded, "Liability").await;
+    designate(
+        &pool,
+        &seeded,
+        "default_vat_payable_account_id",
+        Some(seeded.accounts["1100"]),
+    )
+    .await;
+    let (v, n) = (version(&pool, inv).await, entry_count(&pool).await);
+
+    let err = write_off(&pool, &seeded, inv, Nature::Discount)
+        .await
+        .unwrap_err();
+    assert!(
+        matches!(
+            err,
+            DbError::SettlementCounterpartyIsClaimAccount {
+                claim: ClaimSide::Receivable,
+                role: SettlementAccountRole::VatPayable,
+                ..
+            }
+        ),
+        "{err:?}"
+    );
+    assert_nothing_written(&pool, inv, v, n).await;
+}
diff --git a/crates/kesh-db/tests/payment_batches_repository.rs b/crates/kesh-db/tests/payment_batches_repository.rs
index 5830df405..8ff18a87a 100644
--- a/crates/kesh-db/tests/payment_batches_repository.rs
+++ b/crates/kesh-db/tests/payment_batches_repository.rs
@@ -538,3 +538,343 @@ async fn last_confirmed_batch_is_historical_and_most_recent(pool: MySqlPool) {
     assert_eq!(last.map(|(id, _)| id), Some(second), "le plus récent");
     assert_ne!(first, second);
 }
+
+// ---------------------------------------------------------------------------
+// Story 15-6b (#474, AC6) — refus à la création, garde à la confirmation
+// ---------------------------------------------------------------------------
+
+/// Relie le compte bancaire source du contexte au compte du grand livre `ledger`.
+async fn link_bank(pool: &MySqlPool, ctx: &Ctx, ledger: i64) {
+    sqlx::query("UPDATE bank_accounts SET journal_account_id = ? WHERE id = ?")
+        .bind(ledger)
+        .bind(ctx.bank_id)
+        .execute(pool)
+        .await
+        .unwrap();
+}
+
+/// Le compte de banque 1020, absent du seed.
+async fn ledger_1020(pool: &MySqlPool, ctx: &Ctx) -> i64 {
+    sqlx::query_scalar(
+        "INSERT INTO accounts (company_id, number, name, account_type, active, postable) \
+         VALUES (?, '1020', 'Banque', 'Asset', 1, 1) RETURNING id",
+    )
+    .bind(ctx.seeded.company_id)
+    .fetch_one(pool)
+    .await
+    .unwrap()
+}
+
+/// Story 15-6b, test 13 — **création** : A (dette sur 2000) refusée par
+/// facture, B (dette sur 2001) retenue ; avec A seule, aucun lot.
+#[sqlx::test(migrations = "./test-schema")]
+async fn create_batch_refuses_an_invoice_whose_payable_is_the_bank_ledger(pool: MySqlPool) {
+    let ctx = setup(&pool).await;
+    let a = make_invoice(&pool, &ctx, Some(IBAN_A), None, Some("A"), dec!(100.00)).await;
+    let p2001: i64 = sqlx::query_scalar(
+        "INSERT INTO accounts (company_id, number, name, account_type) \
+         VALUES (?, '2001', 'Créanciers bis', 'Liability') RETURNING id",
+    )
+    .bind(ctx.seeded.company_id)
+    .fetch_one(&pool)
+    .await
+    .unwrap();
+    sqlx::query(
+        "UPDATE company_invoice_settings SET default_payable_account_id = ? WHERE company_id = ?",
+    )
+    .bind(p2001)
+    .bind(ctx.seeded.company_id)
+    .execute(&pool)
+    .await
+    .unwrap();
+    let b = make_invoice(&pool, &ctx, Some(IBAN_A), None, Some("B"), dec!(200.00)).await;
+    let payable = ctx.seeded.accounts["2000"];
+    link_bank(&pool, &ctx, payable).await;
+
+    let outcome =
+        payment_batches::create_batch(&pool, new_batch(&ctx, vec![a, b]), ctx.seeded.admin_user_id)
+            .await
+            .unwrap();
+    let batch = outcome.batch.expect("B forme un lot");
+    assert_eq!(batch.items.len(), 1);
+    assert_eq!(batch.items[0].supplier_invoice_id, b);
+    assert_eq!(outcome.failed.len(), 1);
+    let failed = &outcome.failed[0];
+    assert_eq!(failed.supplier_invoice_id, a);
+    assert_eq!(
+        failed.error_code,
+        "SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT"
+    );
+    assert_eq!(
+        failed.details,
+        Some(serde_json::json!({
+            "bankAccountId": ctx.bank_id,
+            "accountId": payable,
+            "accountNumber": "2000",
+            "claim": "payable",
+            "role": "counterparty",
+        }))
+    );
+
+    // A seule : aucun lot n'est créé — donc aucun fichier pain.001.
+    let outcome =
+        payment_batches::create_batch(&pool, new_batch(&ctx, vec![a]), ctx.seeded.admin_user_id)
+            .await
+            .unwrap();
+    assert!(outcome.batch.is_none(), "aucun lot");
+    assert_eq!(
+        outcome.failed[0].error_code,
+        "SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT"
+    );
+    let batches: i64 = sqlx::query_scalar("SELECT COUNT(*) FROM payment_batches")
+        .fetch_one(&pool)
+        .await
+        .unwrap();
+    assert_eq!(batches, 1, "seul le lot de B existe");
+}
+
+/// Story 15-6b, test 14 — **écriture d'achat sans ligne de crédit** : la
+/// facture va dans `failed[]` (donnée de CETTE facture), les autres restent.
+#[sqlx::test(migrations = "./test-schema")]
+async fn create_batch_reports_a_purchase_entry_without_credit_line_per_invoice(pool: MySqlPool) {
+    let ctx = setup(&pool).await;
+    let ok = make_invoice(&pool, &ctx, Some(IBAN_A), None, Some("OK"), dec!(100.00)).await;
+    let bad = make_invoice(&pool, &ctx, Some(IBAN_A), None, Some("KO"), dec!(50.00)).await;
+    let empty_entry: i64 = sqlx::query_scalar(
+        "INSERT INTO journal_entries (company_id, fiscal_year_id, entry_number, entry_date, journal, description) \
+         VALUES (?, ?, 999999, '2026-06-15', 'Achats', 'Écriture vide') RETURNING id",
+    )
+    .bind(ctx.seeded.company_id)
+    .bind(ctx.seeded.fiscal_year_id)
+    .fetch_one(&pool)
+    .await
+    .unwrap();
+    sqlx::query("UPDATE supplier_invoices SET purchase_journal_entry_id = ? WHERE id = ?")
+        .bind(empty_entry)
+        .bind(bad)
+        .execute(&pool)
+        .await
+        .unwrap();
+
+    let outcome = payment_batches::create_batch(
+        &pool,
+        new_batch(&ctx, vec![ok, bad]),
+        ctx.seeded.admin_user_id,
+    )
+    .await
+    .unwrap();
+    let batch = outcome.batch.expect("lot créé avec la facture saine");
+    assert_eq!(batch.items.len(), 1);
+    assert_eq!(batch.items[0].supplier_invoice_id, ok);
+    assert_eq!(outcome.failed.len(), 1);
+    assert_eq!(outcome.failed[0].supplier_invoice_id, bad);
+    assert_eq!(
+        outcome.failed[0].error_code,
+        "SUPPLIER_INVOICE_PURCHASE_ENTRY_MALFORMED"
+    );
+    assert_eq!(
+        outcome.failed[0].details,
+        Some(serde_json::json!({
+            "reason": "no_credit_line_on_purchase_entry",
+            "purchaseEntryId": empty_entry,
+        }))
+    );
+}
+
+/// Story 15-6b, test 15 — **confirmation, puis remède** : le compte bancaire,
+/// relié au 2000 après la création, bloque la confirmation (400 contextualisé,
+/// lot toujours `generated`, rien d'écrit) ; relié de nouveau au 1020, elle
+/// passe.
+#[sqlx::test(migrations = "./test-schema")]
+async fn confirm_batch_refuses_then_passes_once_the_bank_is_relinked(pool: MySqlPool) {
+    let ctx = setup(&pool).await;
+    let l1020 = ledger_1020(&pool, &ctx).await;
+    link_bank(&pool, &ctx, l1020).await;
+    let inv = make_invoice(&pool, &ctx, Some(IBAN_A), None, Some("R"), dec!(100.00)).await;
+    let batch_id =
+        payment_batches::create_batch(&pool, new_batch(&ctx, vec![inv]), ctx.seeded.admin_user_id)
+            .await
+            .unwrap()
+            .batch
+            .expect("lot créé")
+            .batch
+            .id;
+    let payable = ctx.seeded.accounts["2000"];
+    link_bank(&pool, &ctx, payable).await;
+    let entries_before: i64 = sqlx::query_scalar("SELECT COUNT(*) FROM journal_entries")
+        .fetch_one(&pool)
+        .await
+        .unwrap();
+
+    let err = payment_batches::confirm_batch(
+        &pool,
+        ctx.seeded.company_id,
+        batch_id,
+        d(2026, 7, 2),
+        ctx.seeded.admin_user_id,
+    )
+    .await
+    .expect_err("la confirmation doit être refusée");
+    match err {
+        DbError::SettlementCounterpartyIsClaimAccount {
+            account_id,
+            ref account_number,
+            claim: kesh_db::errors::ClaimSide::Payable,
+            role: kesh_db::errors::SettlementAccountRole::Counterparty,
+            batch: Some(ref ctx_batch),
+        } => {
+            assert_eq!(account_id, payable);
+            assert_eq!(account_number.as_deref(), Some("2000"));
+            assert_eq!(ctx_batch.payment_batch_id, batch_id);
+            assert_eq!(ctx_batch.supplier_invoice_id, inv);
+            assert_eq!(ctx_batch.supplier_invoice_number.as_deref(), Some("FF-001"));
+        }
+        other => panic!("refus contextualisé attendu, obtenu {other:?}"),
+    }
+    let (status,): (String,) = sqlx::query_as("SELECT status FROM payment_batches WHERE id = ?")
+        .bind(batch_id)
+        .fetch_one(&pool)
+        .await
+        .unwrap();
+    assert_eq!(status, "generated");
+    let inv_status: String =
+        sqlx::query_scalar("SELECT status FROM supplier_invoices WHERE id = ?")
+            .bind(inv)
+            .fetch_one(&pool)
+            .await
+            .unwrap();
+    assert_eq!(inv_status, "open");
+    let entries_after: i64 = sqlx::query_scalar("SELECT COUNT(*) FROM journal_entries")
+        .fetch_one(&pool)
+        .await
+        .unwrap();
+    assert_eq!(entries_after, entries_before, "aucun règlement écrit");
+
+    // Le remède : relier de nouveau le compte bancaire à son compte de banque.
+    link_bank(&pool, &ctx, l1020).await;
+    let confirmed = payment_batches::confirm_batch(
+        &pool,
+        ctx.seeded.company_id,
+        batch_id,
+        d(2026, 7, 2),
+        ctx.seeded.admin_user_id,
+    )
+    .await
+    .expect("la confirmation passe après le remède");
+    assert_eq!(confirmed.batch.status, "confirmed");
+    assert_eq!(
+        account_balance(&pool, ctx.seeded.company_id, payable).await,
+        Decimal::ZERO
+    );
+}
+
+/// Story 15-6b, revue de code P1 (findings L4 = E3) — **atomicité de la
+/// confirmation** : un lot de deux factures, A (dette sur 2001) puis B (dette
+/// sur 2000). Le compte bancaire, relié au 2000 après la création, laisse
+/// passer A et refuse B. Le règlement de A, déjà écrit dans la transaction,
+/// doit être défait avec elle : A reste `open`, aucune écriture neuve, le lot
+/// reste `generated`. Le test à une seule facture (test 15) ne pouvait pas le
+/// montrer — le refus y tombait avant toute écriture.
+///
+/// Mutation constatée rouge : `tx.rollback()` remplacé par `tx.commit()` dans
+/// la branche d'échec de `confirm_batch` (l'effet d'un « commit par facture »).
+#[sqlx::test(migrations = "./test-schema")]
+async fn confirm_batch_rolls_back_the_invoices_settled_before_the_refused_one(pool: MySqlPool) {
+    let ctx = setup(&pool).await;
+    let l1020 = ledger_1020(&pool, &ctx).await;
+    link_bank(&pool, &ctx, l1020).await;
+    let p2001: i64 = sqlx::query_scalar(
+        "INSERT INTO accounts (company_id, number, name, account_type) \
+         VALUES (?, '2001', 'Créanciers bis', 'Liability') RETURNING id",
+    )
+    .bind(ctx.seeded.company_id)
+    .fetch_one(&pool)
+    .await
+    .unwrap();
+    let set_payable = |account: i64| {
+        sqlx::query(
+            "UPDATE company_invoice_settings SET default_payable_account_id = ? \
+             WHERE company_id = ?",
+        )
+        .bind(account)
+        .bind(ctx.seeded.company_id)
+        .execute(&pool)
+    };
+    set_payable(p2001).await.unwrap();
+    let a = make_invoice(&pool, &ctx, Some(IBAN_A), None, Some("A"), dec!(100.00)).await;
+    let payable = ctx.seeded.accounts["2000"];
+    set_payable(payable).await.unwrap();
+    let b = make_invoice(&pool, &ctx, Some(IBAN_A), None, Some("B"), dec!(200.00)).await;
+
+    let batch_id =
+        payment_batches::create_batch(&pool, new_batch(&ctx, vec![a, b]), ctx.seeded.admin_user_id)
+            .await
+            .unwrap()
+            .batch
+            .expect("lot créé avec A et B")
+            .batch
+            .id;
+    // Montage : A est réglée AVANT B — sans quoi le refus tomberait avant
+    // toute écriture et le test passerait à vide.
+    let order: Vec<i64> = sqlx::query_scalar(
+        "SELECT supplier_invoice_id FROM payment_batch_items \
+         WHERE payment_batch_id = ? ORDER BY position",
+    )
+    .bind(batch_id)
+    .fetch_all(&pool)
+    .await
+    .unwrap();
+    assert_eq!(order, vec![a, b], "A doit précéder B dans le lot");
+
+    link_bank(&pool, &ctx, payable).await;
+    let entries_before: i64 = sqlx::query_scalar("SELECT COUNT(*) FROM journal_entries")
+        .fetch_one(&pool)
+        .await
+        .unwrap();
+
+    let err = payment_batches::confirm_batch(
+        &pool,
+        ctx.seeded.company_id,
+        batch_id,
+        d(2026, 7, 2),
+        ctx.seeded.admin_user_id,
+    )
+    .await
+    .expect_err("la confirmation doit être refusée sur B");
+    match err {
+        DbError::SettlementCounterpartyIsClaimAccount {
+            batch: Some(ref ctx_batch),
+            ..
+        } => assert_eq!(ctx_batch.supplier_invoice_id, b, "le refus nomme B"),
+        other => panic!("refus contextualisé attendu, obtenu {other:?}"),
+    }
+
+    for (id, label) in [(a, "A"), (b, "B")] {
+        let status: String =
+            sqlx::query_scalar("SELECT status FROM supplier_invoices WHERE id = ?")
+                .bind(id)
+                .fetch_one(&pool)
+                .await
+                .unwrap();
+        assert_eq!(status, "open", "{label} reste ouverte");
+    }
+    let entries_after: i64 = sqlx::query_scalar("SELECT COUNT(*) FROM journal_entries")
+        .fetch_one(&pool)
+        .await
+        .unwrap();
+    assert_eq!(
+        entries_after, entries_before,
+        "le règlement de A est défait avec la transaction"
+    );
+    assert_eq!(
+        account_balance(&pool, ctx.seeded.company_id, p2001).await,
+        dec!(-100.00),
+        "la dette de A reste entière"
+    );
+    let status: String = sqlx::query_scalar("SELECT status FROM payment_batches WHERE id = ?")
+        .bind(batch_id)
+        .fetch_one(&pool)
+        .await
+        .unwrap();
+    assert_eq!(status, "generated");
+}
diff --git a/crates/kesh-db/tests/supplier_invoices_repository.rs b/crates/kesh-db/tests/supplier_invoices_repository.rs
index cb235d83b..ba8dcdd86 100644
--- a/crates/kesh-db/tests/supplier_invoices_repository.rs
+++ b/crates/kesh-db/tests/supplier_invoices_repository.rs
@@ -2361,3 +2361,140 @@ mod garde_usage_comptes_reglage {
             .expect("la saisie réussit une fois l'exercice rendu");
     }
 }
+
+// ---------------------------------------------------------------------------
+// Story 15-6b (#474, AC4) — un règlement ne vise pas le compte qu'il solde
+// ---------------------------------------------------------------------------
+
+/// Le règlement fournisseur refusé ne laisse rien : facture `open`, version
+/// inchangée, aucune écriture neuve.
+async fn assert_supplier_nothing_written(
+    pool: &MySqlPool,
+    invoice_id: i64,
+    (entries_before, version_before): (i64, i32),
+) {
+    let (status, version, settlement): (String, i32, Option<i64>) = sqlx::query_as(
+        "SELECT status, version, settlement_journal_entry_id FROM supplier_invoices WHERE id = ?",
+    )
+    .bind(invoice_id)
+    .fetch_one(pool)
+    .await
+    .unwrap();
+    assert_eq!(status, "open");
+    assert_eq!(version, version_before);
+    assert!(settlement.is_none());
+    let entries: i64 = sqlx::query_scalar("SELECT COUNT(*) FROM journal_entries")
+        .fetch_one(pool)
+        .await
+        .unwrap();
+    assert_eq!(entries, entries_before, "aucune écriture neuve");
+}
+
+async fn supplier_before(pool: &MySqlPool, invoice_id: i64) -> (i64, i32) {
+    let entries: i64 = sqlx::query_scalar("SELECT COUNT(*) FROM journal_entries")
+        .fetch_one(pool)
+        .await
+        .unwrap();
+    let version: i32 = sqlx::query_scalar("SELECT version FROM supplier_invoices WHERE id = ?")
+        .bind(invoice_id)
+        .fetch_one(pool)
+        .await
+        .unwrap();
+    (entries, version)
+}
+
+fn assert_payable_refusal(err: &DbError, payable: i64) {
+    match err {
+        DbError::SettlementCounterpartyIsClaimAccount {
+            account_id,
+            account_number,
+            claim: kesh_db::errors::ClaimSide::Payable,
+            role: kesh_db::errors::SettlementAccountRole::Counterparty,
+            batch: None,
+        } => {
+            assert_eq!(*account_id, payable);
+            assert_eq!(account_number.as_deref(), Some("2000"));
+        }
+        other => panic!("refus de contrepartie attendu, obtenu {other:?}"),
+    }
+}
+
+/// Story 15-6b, test 5 — **compte interne = 2000** : `D 2000 / C 2000` refusé.
+#[sqlx::test(migrations = "./test-schema")]
+async fn pay_with_the_payable_account_as_internal_account_is_refused(pool: MySqlPool) {
+    let ctx = setup(&pool).await;
+    let payable = ctx.seeded.accounts["2000"];
+    let created = supplier_invoices::create(
+        &pool,
+        one_line(&ctx, dec!(500.00), dec!(0)),
+        ctx.seeded.admin_user_id,
+    )
+    .await
+    .unwrap();
+    let before = supplier_before(&pool, created.invoice.id).await;
+
+    let err = supplier_invoices::pay(
+        &pool,
+        ctx.seeded.company_id,
+        created.invoice.id,
+        SettlementChoice::InternalAccount {
+            account_id: payable,
+        },
+        d(2026, 6, 20),
+        ctx.seeded.admin_user_id,
+    )
+    .await
+    .expect_err("la dette comme contrepartie doit être refusée");
+    assert_payable_refusal(&err, payable);
+    assert_supplier_nothing_written(&pool, created.invoice.id, before).await;
+}
+
+/// Story 15-6b, test 6 — **virement sur un compte bancaire lié au 2000** : même
+/// refus. (La fixture `pay_bank_transfer_uses_journal_account` lie au 1100 :
+/// elle reste valide, le compte soldé est 2000.)
+#[sqlx::test(migrations = "./test-schema")]
+async fn pay_by_a_bank_account_linked_to_the_payable_account_is_refused(pool: MySqlPool) {
+    let ctx = setup(&pool).await;
+    let payable = ctx.seeded.accounts["2000"];
+    let bank = bank_accounts::create(
+        &pool,
+        NewBankAccount {
+            company_id: ctx.seeded.company_id,
+            bank_name: "Banque Test".into(),
+            iban: "CH9300762011623852957".into(),
+            qr_iban: None,
+            is_primary: true,
+        },
+    )
+    .await
+    .unwrap();
+    sqlx::query("UPDATE bank_accounts SET journal_account_id = ? WHERE id = ?")
+        .bind(payable)
+        .bind(bank.id)
+        .execute(&pool)
+        .await
+        .unwrap();
+    let created = supplier_invoices::create(
+        &pool,
+        one_line(&ctx, dec!(500.00), dec!(0)),
+        ctx.seeded.admin_user_id,
+    )
+    .await
+    .unwrap();
+    let before = supplier_before(&pool, created.invoice.id).await;
+
+    let err = supplier_invoices::pay(
+        &pool,
+        ctx.seeded.company_id,
+        created.invoice.id,
+        SettlementChoice::BankTransfer {
+            bank_account_id: bank.id,
+        },
+        d(2026, 6, 20),
+        ctx.seeded.admin_user_id,
+    )
+    .await
+    .expect_err("un compte bancaire lié à la dette doit être refusé");
+    assert_payable_refusal(&err, payable);
+    assert_supplier_nothing_written(&pool, created.invoice.id, before).await;
+}
diff --git a/crates/kesh-i18n/locales/de-CH/messages.ftl b/crates/kesh-i18n/locales/de-CH/messages.ftl
index 0081e6464..d5a5016ab 100644
--- a/crates/kesh-i18n/locales/de-CH/messages.ftl
+++ b/crates/kesh-i18n/locales/de-CH/messages.ftl
@@ -25,6 +25,12 @@ error-check-constraint = Ungültiger Wert
 error-illegal-state = Unzulässiger Statusübergang
 error-invoice-unvalidate-blocked-settled = Diese Rechnung weist eine — auch nur teilweise — Zahlung auf: stornieren Sie diese zuerst.
 error-credit-note-blocked-settled = Diese Rechnung weist eine — auch nur teilweise — Zahlung auf: Stornieren Sie diese zuerst, um eine Gutschrift ausstellen zu können.
+error-settlement-counterparty-is-receivable = Das Konto { $account } ist das Debitorenkonto dieser Rechnung: Eine Zahlung muss die Forderung auf ein anderes Konto ausbuchen (Bank, Kasse, Verrechnung…).
+error-settlement-counterparty-is-payable = Das Konto { $account } ist das Kreditorenkonto dieser Rechnung: Eine Zahlung muss die Schuld über ein anderes Konto tilgen (Bank, Kasse, Verrechnung…).
+error-settlement-counterparty-is-payable-in-batch = Das Bankkonto dieses Stapels ist mit dem Konto { $account } verknüpft, dem Kreditorenkonto der Rechnung { $invoice }: Der Stapel kann nicht bestätigt werden. Verknüpfen Sie das Bankkonto mit seinem eigenen Bankkonto in der Buchhaltung und bestätigen Sie erneut, oder stornieren Sie den Stapel und begleichen Sie die Rechnung über ihre Detailansicht.
+error-settlement-rounding-account-is-receivable = Das Konto { $account }, in den Einstellungen als Konto für Rundungsdifferenzen festgelegt, ist das Debitorenkonto dieser Rechnung: Eine Administratorin oder ein Administrator muss unter Einstellungen → Fakturierung ein anderes Konto festlegen.
+error-settlement-write-off-account-is-receivable = Das Konto { $account }, in den Einstellungen als Konto dieser Ausbuchungsart festgelegt, ist das Debitorenkonto dieser Rechnung: Eine Administratorin oder ein Administrator muss unter Einstellungen → Fakturierung ein anderes Konto festlegen.
+error-settlement-vat-payable-account-is-receivable = Das Konto { $account }, in den Einstellungen als Konto für geschuldete MWST festgelegt, ist das Debitorenkonto dieser Rechnung: Eine Administratorin oder ein Administrator muss unter Einstellungen → Fakturierung ein anderes Konto festlegen.
 error-invoice-unvalidate-blocked-credited = Diese Rechnung wurde durch eine Gutschrift korrigiert, die bereits die Korrektur darstellt.
 error-invoice-unvalidate-blocked-reminders = Diese Rechnung hat eine Mahnhistorie: deren Löschung würde den Nachweis des Inkassos vernichten.
 error-invoice-unvalidate-blocked-emailed = Diese Rechnung wurde dem Kunden zugestellt: korrigieren Sie sie mit einer Gutschrift.
@@ -715,6 +721,7 @@ invoice-settle-type-label = Zahlungsart
 invoice-settle-type-bank = Banküberweisung
 invoice-settle-type-internal = Bar oder anderes Konto
 invoice-settle-bank-label = Bankkonto
+invoices-settle-no-eligible-bank-account = Kein verwendbares Bankkonto: Das einzige verknüpfte Konto ist das Debitorenkonto dieser Rechnung. Verknüpfen Sie ein Bankkonto mit seinem eigenen Bankkonto in der Buchhaltung, oder begleichen Sie über ein internes Konto.
 invoice-settle-account-label = Konto
 invoice-settle-account-placeholder = — Konto wählen
 invoice-settle-amount-label = Betrag
@@ -1081,6 +1088,8 @@ reconciliation-failed-project-archived = Das Analyseprojekt ist archiviert.
 reconciliation-failed-project-not-found = Analyseprojekt nicht gefunden.
 reconciliation-failed-currency-mismatch = Nur Transaktionen in CHF können mit einer Rechnung oder einer Regel abgeglichen werden.
 reconciliation-failed-overpayment = Der Betrag der Transaktion übersteigt den offenen Betrag der Rechnung.
+reconciliation-failed-counterparty-is-claim-account = Das Bankkonto ist mit dem Debitorenkonto der Rechnung verknüpft: Verknüpfen Sie es mit seinem eigenen Bankkonto in der Buchhaltung.
+reconciliation-failed-rounding-account-is-claim-account = Das festgelegte Konto für Rundungsdifferenzen ist das Debitorenkonto der Rechnung: Eine Administratorin oder ein Administrator muss unter Einstellungen → Fakturierung ein anderes festlegen.
 reconciliation-failed-payment-before-invoice = Die Zahlung liegt mehr als einen Tag vor dem Rechnungsdatum: Sie kann die Rechnung nicht begleichen, auch wenn diese vorgeschlagen wurde.
 reconciliation-failed-rule-mismatch = Das Gegenkonto der Regel hat sich geändert: Laden Sie die Seite neu.
 reconciliation-failed-rule-no-longer-matches = Die Regel passt nicht mehr auf diese Transaktion: Sie wurde inzwischen geändert.
@@ -1970,6 +1979,7 @@ supplier-invoices-new = Rechnung erfassen
 supplier-invoices-paid-info = Rechnung bezahlt.
 supplier-invoices-pay-account-ph = Gegenkonto
 supplier-invoices-pay-bank-ph = Belastungskonto
+supplier-invoices-pay-no-eligible-bank-account = Kein verwendbares Bankkonto: Das einzige verknüpfte Konto ist das Kreditorenkonto dieser Rechnung. Verknüpfen Sie ein Bankkonto mit seinem eigenen Bankkonto in der Buchhaltung, oder begleichen Sie über ein internes Konto.
 supplier-invoices-pay-date = Zahlungsdatum
 supplier-invoices-pay-err-account = Wählen Sie ein Konto.
 supplier-invoices-pay-err-bank = Wählen Sie ein Bankkonto.
@@ -2024,6 +2034,8 @@ nav-users = Benutzer
 payment-batches-failed-already-in-generated-batch = Bereits in einem erstellten Stapel
 payment-batches-failed-invalid-iban = IBAN ungültig
 payment-batches-failed-invalid-qr-iban = QR-IBAN ungültig
+payment-batches-failed-counterparty-is-claim-account = Das Bankkonto des Stapels ist mit dem Kreditorenkonto dieser Rechnung verknüpft
+payment-batches-failed-purchase-entry-malformed = Einkaufsbuchung ohne Habenzeile: Rechnung prüfen
 payment-batches-failed-no-payment-coordinates = Keine Zahlungsverbindung (IBAN/QR-IBAN)
 payment-batches-failed-supplier-invoice-not-found = Rechnung nicht gefunden
 payment-batches-failed-supplier-invoice-not-open = Rechnung nicht offen
diff --git a/crates/kesh-i18n/locales/en-CH/messages.ftl b/crates/kesh-i18n/locales/en-CH/messages.ftl
index 2a1ab19b3..9143479fa 100644
--- a/crates/kesh-i18n/locales/en-CH/messages.ftl
+++ b/crates/kesh-i18n/locales/en-CH/messages.ftl
@@ -25,6 +25,12 @@ error-check-constraint = Invalid value
 error-illegal-state = Illegal state transition
 error-invoice-unvalidate-blocked-settled = This invoice carries a payment, even a partial one: cancel it first.
 error-credit-note-blocked-settled = This invoice carries a payment, even a partial one: cancel it first to be able to issue a credit note.
+error-settlement-counterparty-is-receivable = Account { $account } is this invoice's receivables account: a payment must move the receivable to another account (bank, cash, offset…).
+error-settlement-counterparty-is-payable = Account { $account } is this invoice's payables account: a payment must settle the debt through another account (bank, cash, offset…).
+error-settlement-counterparty-is-payable-in-batch = This batch's bank account is linked to account { $account }, the payables account of invoice { $invoice }: the batch cannot be confirmed. Link the bank account to its own bank ledger account and confirm again, or cancel the batch and pay the invoice from its page.
+error-settlement-rounding-account-is-receivable = Account { $account }, designated in the settings as the rounding differences account, is this invoice's receivables account: an administrator must designate another account in Settings → Invoicing.
+error-settlement-write-off-account-is-receivable = Account { $account }, designated in the settings as the account for this write-off nature, is this invoice's receivables account: an administrator must designate another account in Settings → Invoicing.
+error-settlement-vat-payable-account-is-receivable = Account { $account }, designated in the settings as the VAT payable account, is this invoice's receivables account: an administrator must designate another account in Settings → Invoicing.
 error-invoice-unvalidate-blocked-credited = This invoice is credited by a credit note, which is already the correction.
 error-invoice-unvalidate-blocked-reminders = This invoice has a reminder history: removing it would erase the proof of collection.
 error-invoice-unvalidate-blocked-emailed = This invoice was sent to the client: correct it with a credit note.
@@ -715,6 +721,7 @@ invoice-settle-type-label = Settlement method
 invoice-settle-type-bank = Bank transfer
 invoice-settle-type-internal = Cash or other account
 invoice-settle-bank-label = Bank account
+invoices-settle-no-eligible-bank-account = No usable bank account: the only linked account is this invoice's receivables account. Link a bank account to its own bank ledger account, or settle through an internal account.
 invoice-settle-account-label = Account
 invoice-settle-account-placeholder = — Choose an account
 invoice-settle-amount-label = Amount
@@ -1081,6 +1088,8 @@ reconciliation-failed-project-archived = The analytical project is archived.
 reconciliation-failed-project-not-found = Analytical project not found.
 reconciliation-failed-currency-mismatch = Only CHF transactions can be reconciled with an invoice or a rule.
 reconciliation-failed-overpayment = The transaction amount exceeds the amount due on the invoice.
+reconciliation-failed-counterparty-is-claim-account = The bank account is linked to the invoice's receivables account: link it to its own bank ledger account.
+reconciliation-failed-rounding-account-is-claim-account = The designated rounding account is the invoice's receivables account: an administrator must designate another one in Settings → Invoicing.
 reconciliation-failed-payment-before-invoice = The payment is dated more than one day before the invoice: it cannot settle it, even though the invoice was proposed.
 reconciliation-failed-rule-mismatch = The rule's counterpart account has changed: reload the page.
 reconciliation-failed-rule-no-longer-matches = The rule no longer matches this transaction: it has been changed in the meantime.
@@ -1976,6 +1985,7 @@ supplier-invoices-new = Record an invoice
 supplier-invoices-paid-info = Invoice paid.
 supplier-invoices-pay-account-ph = Counterparty account
 supplier-invoices-pay-bank-ph = Source bank account
+supplier-invoices-pay-no-eligible-bank-account = No usable bank account: the only linked account is this invoice's payables account. Link a bank account to its own bank ledger account, or pay through an internal account.
 supplier-invoices-pay-date = Payment date
 supplier-invoices-pay-err-account = Select an account.
 supplier-invoices-pay-err-bank = Select a bank account.
@@ -2030,6 +2040,8 @@ nav-users = Users
 payment-batches-failed-already-in-generated-batch = Already in a created batch
 payment-batches-failed-invalid-iban = IBAN invalid
 payment-batches-failed-invalid-qr-iban = QR-IBAN invalid
+payment-batches-failed-counterparty-is-claim-account = The batch's bank account is linked to this invoice's payables account
+payment-batches-failed-purchase-entry-malformed = Purchase entry without a credit line: check the invoice
 payment-batches-failed-no-payment-coordinates = No payment details (IBAN/QR-IBAN)
 payment-batches-failed-supplier-invoice-not-found = Invoice not found
 payment-batches-failed-supplier-invoice-not-open = Invoice not open
diff --git a/crates/kesh-i18n/locales/fr-CH/messages.ftl b/crates/kesh-i18n/locales/fr-CH/messages.ftl
index 39b2d23e9..53f472500 100644
--- a/crates/kesh-i18n/locales/fr-CH/messages.ftl
+++ b/crates/kesh-i18n/locales/fr-CH/messages.ftl
@@ -25,6 +25,12 @@ error-check-constraint = Valeur invalide
 error-illegal-state = Transition d'état interdite
 error-invoice-unvalidate-blocked-settled = Cette facture porte un règlement, même partiel : annulez-le d'abord.
 error-credit-note-blocked-settled = Cette facture porte un règlement, même partiel : annulez-le d'abord pour pouvoir émettre un avoir.
+error-settlement-counterparty-is-receivable = Le compte { $account } est le compte débiteurs de cette facture : un règlement doit faire sortir la créance vers un autre compte (banque, caisse, compensation…).
+error-settlement-counterparty-is-payable = Le compte { $account } est le compte créanciers de cette facture : un règlement doit éteindre la dette par un autre compte (banque, caisse, compensation…).
+error-settlement-counterparty-is-payable-in-batch = Le compte bancaire de ce lot est lié au compte { $account }, le compte créanciers de la facture { $invoice } : le lot ne peut pas être confirmé. Reliez le compte bancaire à son propre compte de banque puis confirmez de nouveau, ou annulez le lot et réglez la facture depuis sa fiche.
+error-settlement-rounding-account-is-receivable = Le compte { $account }, désigné dans les réglages comme compte de différences d'arrondi, est le compte débiteurs de cette facture : un administrateur doit désigner un autre compte dans Paramètres → Facturation.
+error-settlement-write-off-account-is-receivable = Le compte { $account }, désigné dans les réglages comme compte de cette nature de solde, est le compte débiteurs de cette facture : un administrateur doit désigner un autre compte dans Paramètres → Facturation.
+error-settlement-vat-payable-account-is-receivable = Le compte { $account }, désigné dans les réglages comme compte de TVA due, est le compte débiteurs de cette facture : un administrateur doit désigner un autre compte dans Paramètres → Facturation.
 error-invoice-unvalidate-blocked-credited = Cette facture est créditée par un avoir, qui en est déjà la correction.
 error-invoice-unvalidate-blocked-reminders = Cette facture a un historique de rappels : le dévalider effacerait la preuve du recouvrement.
 error-invoice-unvalidate-blocked-emailed = Cette facture a été envoyée au client : corrigez-la par un avoir.
@@ -763,6 +769,7 @@ invoice-settle-type-label = Mode de règlement
 invoice-settle-type-bank = Virement bancaire
 invoice-settle-type-internal = Espèces ou autre compte
 invoice-settle-bank-label = Compte bancaire
+invoices-settle-no-eligible-bank-account = Aucun compte bancaire utilisable : le seul compte lié est le compte débiteurs de cette facture. Reliez un compte bancaire à son propre compte de banque, ou réglez par un compte interne.
 invoice-settle-account-label = Compte
 invoice-settle-account-placeholder = — Choisir un compte
 invoice-settle-amount-label = Montant
@@ -1144,6 +1151,8 @@ reconciliation-failed-project-archived = Le projet analytique est archivé.
 reconciliation-failed-project-not-found = Projet analytique introuvable.
 reconciliation-failed-currency-mismatch = Seules les transactions en CHF peuvent être rapprochées d’une facture ou d’une règle.
 reconciliation-failed-overpayment = Le montant de la transaction dépasse le reste dû de la facture.
+reconciliation-failed-counterparty-is-claim-account = Le compte bancaire est lié au compte débiteurs de la facture : reliez-le à son propre compte de banque.
+reconciliation-failed-rounding-account-is-claim-account = Le compte d’arrondi désigné est le compte débiteurs de la facture : un administrateur doit en désigner un autre dans Paramètres → Facturation.
 reconciliation-failed-payment-before-invoice = Le paiement est daté de plus d’un jour avant la facture : il ne peut pas la régler, même si elle a été proposée.
 reconciliation-failed-rule-mismatch = Le compte de contrepartie de la règle a changé : rechargez la page.
 reconciliation-failed-rule-no-longer-matches = La règle ne correspond plus à cette transaction : elle a été modifiée entre-temps.
@@ -1997,6 +2006,7 @@ supplier-invoices-new = Enregistrer une facture
 supplier-invoices-paid-info = Facture réglée.
 supplier-invoices-pay-account-ph = Compte de contrepartie
 supplier-invoices-pay-bank-ph = Compte bancaire source
+supplier-invoices-pay-no-eligible-bank-account = Aucun compte bancaire utilisable : le seul compte lié est le compte créanciers de cette facture. Reliez un compte bancaire à son propre compte de banque, ou réglez par un compte interne.
 supplier-invoices-pay-date = Date de règlement
 supplier-invoices-pay-err-account = Sélectionnez un compte.
 supplier-invoices-pay-err-bank = Sélectionnez un compte bancaire.
@@ -2065,6 +2075,8 @@ nav-users = Utilisateurs
 payment-batches-failed-already-in-generated-batch = Déjà dans un lot créé
 payment-batches-failed-invalid-iban = IBAN invalide
 payment-batches-failed-invalid-qr-iban = QR-IBAN invalide
+payment-batches-failed-counterparty-is-claim-account = Le compte bancaire du lot est lié au compte créanciers de cette facture
+payment-batches-failed-purchase-entry-malformed = Écriture d'achat sans ligne de crédit : facture à vérifier
 payment-batches-failed-no-payment-coordinates = Pas de coordonnées de paiement (IBAN/QR-IBAN)
 payment-batches-failed-supplier-invoice-not-found = Facture introuvable
 payment-batches-failed-supplier-invoice-not-open = Facture non ouverte
diff --git a/crates/kesh-i18n/locales/it-CH/messages.ftl b/crates/kesh-i18n/locales/it-CH/messages.ftl
index 4c1e400b0..0260cb5c5 100644
--- a/crates/kesh-i18n/locales/it-CH/messages.ftl
+++ b/crates/kesh-i18n/locales/it-CH/messages.ftl
@@ -25,6 +25,12 @@ error-check-constraint = Valore non valido
 error-illegal-state = Transizione di stato non consentita
 error-invoice-unvalidate-blocked-settled = Questa fattura presenta un pagamento, anche parziale: annullatelo prima.
 error-credit-note-blocked-settled = Questa fattura presenta un pagamento, anche parziale: annullalo prima per poter emettere una nota di credito.
+error-settlement-counterparty-is-receivable = Il conto { $account } è il conto debitori di questa fattura: un pagamento deve trasferire il credito su un altro conto (banca, cassa, compensazione…).
+error-settlement-counterparty-is-payable = Il conto { $account } è il conto creditori di questa fattura: un pagamento deve estinguere il debito tramite un altro conto (banca, cassa, compensazione…).
+error-settlement-counterparty-is-payable-in-batch = Il conto bancario di questo lotto è collegato al conto { $account }, il conto creditori della fattura { $invoice }: il lotto non può essere confermato. Collegare il conto bancario al proprio conto di banca e confermare di nuovo, oppure annullare il lotto e pagare la fattura dalla sua scheda.
+error-settlement-rounding-account-is-receivable = Il conto { $account }, designato nelle impostazioni come conto delle differenze di arrotondamento, è il conto debitori di questa fattura: un amministratore deve designare un altro conto in Impostazioni → Fatturazione.
+error-settlement-write-off-account-is-receivable = Il conto { $account }, designato nelle impostazioni come conto di questa natura di saldo, è il conto debitori di questa fattura: un amministratore deve designare un altro conto in Impostazioni → Fatturazione.
+error-settlement-vat-payable-account-is-receivable = Il conto { $account }, designato nelle impostazioni come conto dell'IVA dovuta, è il conto debitori di questa fattura: un amministratore deve designare un altro conto in Impostazioni → Fatturazione.
 error-invoice-unvalidate-blocked-credited = Questa fattura è stornata da una nota di credito, che ne è già la correzione.
 error-invoice-unvalidate-blocked-reminders = Questa fattura ha uno storico di solleciti: eliminarlo cancellerebbe la prova del recupero.
 error-invoice-unvalidate-blocked-emailed = Questa fattura è stata inviata al cliente: correggetela con una nota di credito.
@@ -715,6 +721,7 @@ invoice-settle-type-label = Modalità di pagamento
 invoice-settle-type-bank = Bonifico bancario
 invoice-settle-type-internal = Contanti o altro conto
 invoice-settle-bank-label = Conto bancario
+invoices-settle-no-eligible-bank-account = Nessun conto bancario utilizzabile: l'unico conto collegato è il conto debitori di questa fattura. Collegare un conto bancario al proprio conto di banca, oppure pagare tramite un conto interno.
 invoice-settle-account-label = Conto
 invoice-settle-account-placeholder = — Scegliere un conto
 invoice-settle-amount-label = Importo
@@ -1081,6 +1088,8 @@ reconciliation-failed-project-archived = Il progetto analitico è archiviato.
 reconciliation-failed-project-not-found = Progetto analitico introvabile.
 reconciliation-failed-currency-mismatch = Solo le transazioni in CHF possono essere riconciliate con una fattura o una regola.
 reconciliation-failed-overpayment = L'importo della transazione supera il saldo dovuto della fattura.
+reconciliation-failed-counterparty-is-claim-account = Il conto bancario è collegato al conto debitori della fattura: collegarlo al proprio conto di banca.
+reconciliation-failed-rounding-account-is-claim-account = Il conto delle differenze di arrotondamento designato è il conto debitori della fattura: un amministratore deve designarne un altro in Impostazioni → Fatturazione.
 reconciliation-failed-payment-before-invoice = Il pagamento è anteriore di più di un giorno alla data della fattura: non può saldarla, anche se è stata proposta.
 reconciliation-failed-rule-mismatch = Il conto di contropartita della regola è cambiato: ricaricare la pagina.
 reconciliation-failed-rule-no-longer-matches = La regola non corrisponde più a questa transazione: è stata modificata nel frattempo.
@@ -1971,6 +1980,7 @@ supplier-invoices-new = Registra una fattura
 supplier-invoices-paid-info = Fattura pagata.
 supplier-invoices-pay-account-ph = Conto di contropartita
 supplier-invoices-pay-bank-ph = Conto bancario di origine
+supplier-invoices-pay-no-eligible-bank-account = Nessun conto bancario utilizzabile: l'unico conto collegato è il conto creditori di questa fattura. Collegare un conto bancario al proprio conto di banca, oppure pagare tramite un conto interno.
 supplier-invoices-pay-date = Data di pagamento
 supplier-invoices-pay-err-account = Seleziona un conto.
 supplier-invoices-pay-err-bank = Seleziona un conto bancario.
@@ -2025,6 +2035,8 @@ nav-users = Utenti
 payment-batches-failed-already-in-generated-batch = Già in un lotto creato
 payment-batches-failed-invalid-iban = IBAN non valido
 payment-batches-failed-invalid-qr-iban = QR-IBAN non valido
+payment-batches-failed-counterparty-is-claim-account = Il conto bancario del lotto è collegato al conto creditori di questa fattura
+payment-batches-failed-purchase-entry-malformed = Registrazione d'acquisto senza riga in avere: fattura da verificare
 payment-batches-failed-no-payment-coordinates = Nessuna coordinata di pagamento (IBAN/QR-IBAN)
 payment-batches-failed-supplier-invoice-not-found = Fattura non trovata
 payment-batches-failed-supplier-invoice-not-open = Fattura non aperta
diff --git a/docs/api-external.md b/docs/api-external.md
index 63cf83bf5..61ed17385 100644
--- a/docs/api-external.md
+++ b/docs/api-external.md
@@ -331,6 +331,8 @@ Corps : `{ "version": n }` — le verrou optimiste. Réponse : la facture, même
 | Date du jour dans une période verrouillée | `PERIOD_LOCKED` | `400` |
 | Facture ou règlement introuvable (ou d'une autre société) | `NOT_FOUND` | `404` |
 
+**Refus de `POST /api/v1/invoices/{id}/settlements` (enregistrer un règlement)** — distinct de l'annulation ci-dessus : un règlement dont un compte est **le compte débiteurs de la facture** (celui que son écriture de vente a débité) est refusé en `400 SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT`, sans rien écrire — l'écriture serait `D 1100 / C 1100`, et le reste dû baisserait sans que rien ne bouge au grand livre. `details` : `{ accountId, accountNumber, claim: "receivable", role }`, où `role` vaut `counterparty` (le compte interne choisi, ou le compte comptable lié au compte bancaire du virement — refusé après les refus propres de ce compte, avant le trop-perçu) ou `rounding` (le compte de différences d'arrondi des réglages, quand le paiement solde au centime — à remplacer dans *Paramètres → Facturation*). *(Depuis la v0.13.0.)*
+
 ### Solder le reste d'une facture
 
 **`POST /api/v1/invoices/{id}/write-off`** — écriture (`read-write`), ouverte aux clés comme `POST /invoices/{id}/settlements`. Corps : `{ nature, settledOn, version }`, `nature` parmi `discount` (escompte accordé), `bank_fees` (frais bancaires retenus par la banque du client), `bad_debt` (perte sur débiteur), `rounding` (reste d'arrondi, moins de 5 centimes). **Sans montant** : le serveur solde **tout** le reste dû, au reste exact, si bien que la facture est payée. La `version` de la facture est exigée — un écran périmé, ou un reste qui a changé depuis la lecture, est refusé en `409 OPTIMISTIC_LOCK_CONFLICT`. L'écriture, au journal OD, débite le compte de la nature (réglé dans *Paramètres → Facturation*), crédite la créance ; pour `discount` et `bad_debt`, elle débite aussi la **TVA due au prorata des taux** de la facture. Le solde apparaît dans la liste des règlements (`settlementType = write_off`) et s'annule comme eux. Réponse : `{ invoice, journalEntryId, amount }`.
@@ -343,6 +345,7 @@ Corps : `{ "version": n }` — le verrou optimiste. Réponse : la facture, même
 | Facture déjà payée, rien à solder, reste d'arrondi de 5 centimes ou plus, date antérieure à la facture | `INVALID_INPUT` | `400` |
 | Aucun compte utilisable désigné pour la nature | `WRITE_OFF_ACCOUNT_NOT_CONFIGURED` | `400` |
 | Compte de TVA due absent ou inutilisable — archivé, non imputable (escompte, perte) | `CONFIGURATION_REQUIRED` | `400` |
+| Un compte désigné pour la nature, le reste d'arrondi ou la TVA due est le compte débiteurs de la facture (compte débiteurs changé de type depuis, puis désigné) — l'écriture serait `D 1100 / C 1100` *(depuis la v0.13.0)* | `SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT` | `400`, `details.role` (`write_off_nature`, `rounding`, `vat_payable`) ; refusés dans cet ordre, le premier nommé |
 | Aucun exercice ouvert ne couvre la date | `FISCAL_YEAR_INVALID` | `400` |
 | Date dans une période verrouillée | `PERIOD_LOCKED` | `400` |
 
@@ -364,7 +367,9 @@ Corps : `{ "version": n }` — le verrou optimiste. Réponse : la facture, même
 
 `GET /supplier-invoices/{id}`, la réponse de `pay` et celle de l'annulation portent `settlementCancellable`, `settlementCancelBlockedBy` (code du motif), `settlementCancelBlockedLabel` (numéro du compte archivé) et `lastConfirmedBatch` (`{ id, confirmedAt }` du lot confirmé **le plus récent** qui contient la facture — un fait **historique**, qui ne dit pas d'où vient le règlement courant). Ailleurs, ces champs valent `null` : *non calculés*. Après `pay` ou l'annulation, la facture est **relue** avec ses champs, dans une même lecture : la réponse décrit l'état courant — celui d'une écriture concurrente éventuelle —, jamais un état qui se contredit.
 
-Refus : `SUPPLIER_INVOICE_NOT_PAID` (`409`, la facture n'est pas payée), `FISCAL_YEAR_CLOSED` (`409`), `ACCOUNT_ARCHIVED` (`400`, `details.rejected[]`), `FISCAL_YEAR_INVALID` (`400`), `PERIOD_LOCKED` (`400`), `NOT_FOUND` (`404`).
+**Refus de `POST /api/v1/supplier-invoices/{id}/pay` (régler une facture fournisseur)** — distinct de l'annulation : une contrepartie qui est **le compte créanciers de la facture** (celui que son écriture d'achat a crédité) — compte interne, ou compte comptable lié au compte bancaire du virement — est refusée en `400 SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT`, sans rien écrire (`D 2000 / C 2000` passerait la facture « payée » sans paiement) ; `details` : `{ accountId, accountNumber, claim: "payable", role: "counterparty" }`. Les lots de paiement font le même contrôle : `POST /api/v1/payment-batches` place la facture dans `failed[]` (`200`) avec ce code et `details.bankAccountId` en plus — ou avec `SUPPLIER_INVOICE_PURCHASE_ENTRY_MALFORMED` (`details.reason = "no_credit_line_on_purchase_entry"`, `details.purchaseEntryId`) si son écriture d'achat n'a pas de ligne de crédit ; `POST /api/v1/payment-batches/{id}/confirm` refuse la confirmation entière en `400` du même code, `details.paymentBatchId` et `details.supplierInvoiceId` en plus, si le compte bancaire a été relié au compte créanciers depuis la création du lot (le lot reste `generated` : relier le compte bancaire à son propre compte de banque puis confirmer, ou annuler le lot). *(Depuis la v0.13.0.)*
+
+Refus de l'annulation : `SUPPLIER_INVOICE_NOT_PAID` (`409`, la facture n'est pas payée), `FISCAL_YEAR_CLOSED` (`409`), `ACCOUNT_ARCHIVED` (`400`, `details.rejected[]`), `FISCAL_YEAR_INVALID` (`400`), `PERIOD_LOCKED` (`400`), `NOT_FOUND` (`404`).
 
 ### Annuler une facture fournisseur
 
@@ -380,7 +385,7 @@ Refus, dans l'ordre de précédence : `SUPPLIER_INVOICE_CANCELLED` (`409`, déj
 
 **`POST /api/v1/reconciliation/accept`** — écriture (`read-write`), rôle Comptable, ouverte aux clés comme les autres routes de réconciliation ; la clé est nommée au journal d'audit (`reconciliation.accepted`). Corps : `{ bankAccountId, proposals: [...] }`, chaque proposition portant `type` (`invoice`, `split` ou `rule`) et `bankTransactionId` — plus `invoiceId` pour une facture. Les propositions viennent de `GET /api/v1/reconciliation/proposals`, où `invoiceAmount` est le **reste dû** de la facture (le TTC tant que rien n'est réglé) et `invoiceTotalTtc` son total d'origine, présent seulement quand les deux diffèrent.
 
-La réponse est un **succès partiel** en `200` : `{ accepted: [...], failed: [{ bankTransactionId, errorCode, details }] }` — une proposition refusée n'empêche pas les autres. Pour une facture, le score est recalculé par le serveur, et un montant supérieur au reste dû est refusé (`RECONCILIATION_OVERPAYMENT`, jamais écrit). Si la facture change **pendant** l'acceptation — un règlement, un avoir, une dévalidation enregistrés au même moment —, la proposition est refusée en `RECONCILIATION_INVOICE_NOT_ELIGIBLE` (`details.reason` = `race_during_update`) sans rien écrire : relire les propositions et recommencer. Un interblocage transitoire avec une autre opération est **rejoué** par le serveur, sans être montré ; s'il persiste après trois tentatives, la requête finit en `500 INTERNAL_ERROR` et peut être renvoyée telle quelle — rien n'a été écrit. Refus de la requête entière : `400` (corps invalide), `404` (compte bancaire inconnu), `409 RECONCILIATION_ACCOUNT_LOCKED` (une autre acceptation tient le compte).
+La réponse est un **succès partiel** en `200` : `{ accepted: [...], failed: [{ bankTransactionId, errorCode, details }] }` — une proposition refusée n'empêche pas les autres. Pour une facture, le score est recalculé par le serveur, et un montant supérieur au reste dû est refusé (`RECONCILIATION_OVERPAYMENT`, jamais écrit). Un compte de l'écriture qui serait **le compte débiteurs de la facture** est refusé, lui aussi par proposition, en `SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT` — `details.role` vaut `counterparty` (le compte bancaire est lié au compte débiteurs ; `details.bankAccountId` est posé, et ce refus précède le trop-perçu) ou `rounding` (le compte de différences d'arrondi des réglages est le compte débiteurs ; sans `bankAccountId`) *(depuis la v0.13.0)*. Si la facture change **pendant** l'acceptation — un règlement, un avoir, une dévalidation enregistrés au même moment —, la proposition est refusée en `RECONCILIATION_INVOICE_NOT_ELIGIBLE` (`details.reason` = `race_during_update`) sans rien écrire : relire les propositions et recommencer. Un interblocage transitoire avec une autre opération est **rejoué** par le serveur, sans être montré ; s'il persiste après trois tentatives, la requête finit en `500 INTERNAL_ERROR` et peut être renvoyée telle quelle — rien n'a été écrit. Refus de la requête entière : `400` (corps invalide), `404` (compte bancaire inconnu), `409 RECONCILIATION_ACCOUNT_LOCKED` (une autre acceptation tient le compte).
 
 Pour une proposition `split` ou `rule`, un compte de contrepartie **non imputable** (compte de regroupement, de résultat ou de clôture) est refusé dans `failed[]` en `ACCOUNT_NOT_POSTABLE`, avec `details.rejected[{accountId, accountNumber}]` — la forme du `400` du § 10. Un compte inconnu, d'une autre company ou archivé reste `ACCOUNT_NOT_FOUND` et **prime**. Une règle dont le compte est devenu non imputable n'est plus proposée par `GET /api/v1/reconciliation/proposals` *(depuis la v0.13.0)*.
 
diff --git a/docs/manual/fr/admin-manual.pdf b/docs/manual/fr/admin-manual.pdf
index 43c31b922..4939d25d5 100644
Binary files a/docs/manual/fr/admin-manual.pdf and b/docs/manual/fr/admin-manual.pdf differ
diff --git a/docs/manual/fr/admin-manual.tex b/docs/manual/fr/admin-manual.tex
index 91e361eff..b7a907637 100644
--- a/docs/manual/fr/admin-manual.tex
+++ b/docs/manual/fr/admin-manual.tex
@@ -2155,11 +2155,11 @@ \subsection{Loi sur la TVA (LTVA)}
 
 \paragraph{Compte de différences d'arrondi.} Comme le veut l'usage suisse, le \textbf{total d'une facture émise est arrondi à 5~centimes} (123.44 devient 123.45, 234.52 devient 234.50), avec une ligne « Arrondi » sur la facture ; ce réglage est \textbf{actif par défaut} et se désactive dans la même section, case \emph{« Arrondir le total des factures émises à 5~centimes »} --- les factures déjà émises gardent leur total. L'écart, sans TVA, est écrit \textbf{à la validation} et reste attaché à la facture ; un avoir le reprend et l'annule. Changer de compte d'arrondi ne déplace pas les factures déjà émises~: leur avoir contre-passe l'arrondi sur le compte qu'elles ont mouvementé. Gardez donc l'ancien compte actif tant qu'un avoir peut les viser (sinon~: le réactiver, émettre l'avoir, le ré-archiver). Par ailleurs, une facture émise sans arrondi dont le total porte plus de deux décimales --- quantité ou prix unitaire fractionnaire --- laisse, une fois payée au centime, un écart d'un demi-centime au plus ; et le \emph{solde du reste} d'une telle facture y passe sa fraction de centime, quelle que soit la nature choisie --- d'où l'exigence de ce compte pour solder un reste à fraction de centime. Ces écarts vont au \textbf{compte de différences d'arrondi}, désigné depuis \emph{Paramètres} → \emph{Facturation}, section \emph{Différences d'arrondi}. Ce doit être un compte de \textbf{charge ou de produit}, actif et \textbf{imputable} (pas un compte de regroupement). Les plans livrés (PME, indépendant, association) le proposent : \texttt{6940} \emph{Différences d'arrondi}, une charge, \textbf{désignée d'office} à la création d'une société. Pour une société créée auparavant, ou si vous préférez un autre compte : créez-le au besoin dans le plan comptable, puis choisissez-le dans les paramètres. \textbf{Sans ce compte, une facture dont le total n'est pas déjà un multiple de 5~centimes ne peut pas être validée} : la validation est refusée, avec un message qui renvoie aux paramètres. Pour une société créée avant cette version, désignez-le donc avant d'émettre.
 
-\paragraph{Comptes du solde du reste.} La même page, section \emph{Solde du reste}, désigne les comptes qui recevront ce qui reste dû quand une facture est soldée sans être entièrement payée, selon la \textbf{nature} de l'écart : l'\textbf{escompte accordé} au client, les \textbf{frais bancaires} retenus par sa banque, la \textbf{perte sur un débiteur}. Chacun doit être un compte de \textbf{charge ou de produit}, actif et \textbf{imputable}. Les plans livrés les proposent, \textbf{désignés d'office} à la création d'une société : \texttt{3800} pour l'escompte (\emph{Déductions sur ventes} pour une PME, \emph{Déductions sur prestations} pour un indépendant), \texttt{6900} \emph{Charges financières} pour les frais bancaires, et \texttt{3805} \emph{Pertes sur créances}, ajouté aux trois plans, pour les pertes. Le plan des \textbf{associations} ne propose \textbf{aucun compte d'escompte} --- son \texttt{3800} est \emph{Autres produits} --- : une association qui accorde des escomptes choisit elle-même le compte. Pour une société créée avant cette version, les trois réglages sont vides : créez au besoin les comptes dans le plan comptable, puis choisissez-les ici.
+\paragraph{Comptes du solde du reste.} La même page, section \emph{Solde du reste}, désigne les comptes qui recevront ce qui reste dû quand une facture est soldée sans être entièrement payée, selon la \textbf{nature} de l'écart : l'\textbf{escompte accordé} au client, les \textbf{frais bancaires} retenus par sa banque, la \textbf{perte sur un débiteur}. Chacun doit être un compte de \textbf{charge ou de produit}, actif et \textbf{imputable}. Les plans livrés les proposent, \textbf{désignés d'office} à la création d'une société : \texttt{3800} pour l'escompte (\emph{Déductions sur ventes} pour une PME, \emph{Déductions sur prestations} pour un indépendant), \texttt{6900} \emph{Charges financières} pour les frais bancaires, et \texttt{3805} \emph{Pertes sur créances}, ajouté aux trois plans, pour les pertes. Le plan des \textbf{associations} ne propose \textbf{aucun compte d'escompte} --- son \texttt{3800} est \emph{Autres produits} --- : une association qui accorde des escomptes choisit elle-même le compte. Pour une société créée avant cette version, les trois réglages sont vides : créez au besoin les comptes dans le plan comptable, puis choisissez-les ici. Un solde du reste est \textbf{refusé}, sans rien écrire, si le compte de la nature, le compte de différences d'arrondi ou le compte de TVA due est le \textbf{compte débiteurs de la facture} --- le cas d'un compte débiteurs changé de type depuis, puis désigné ici : désignez alors un autre compte.
 
 \paragraph{Montant minimum d'une facture.} La même page, section \emph{Montant minimum}, fixe un seuil sous lequel une facture ne peut pas être validée (comparé au total arrondi). Vide par défaut : aucun seuil. Les avoirs n'y sont pas soumis.
 
-Quand un paiement --- règlement manuel ou rapprochement bancaire --- \textbf{égale le reste dû arrondi au centime} alors que le reste exact en diffère (10.01 pour 10.0050), il \textbf{solde} la facture : le règlement est enregistré pour le reste exact, et l'écart passe en \textbf{troisième ligne} d'écriture sur le compte de différences d'arrondi --- au crédit si le paiement dépasse le reste exact, au débit sinon. La créance se ferme ainsi à zéro. Si aucun compte utilisable n'est désigné --- réglage vide, ou compte archivé, rendu non imputable ou changé de type depuis ---, un tel paiement est \textbf{refusé sans rien écrire}, avec un message qui renvoie à \emph{Paramètres} → \emph{Facturation}. Un paiement sans écart n'exige aucun réglage. Un règlement manuel se saisit au centime : un montant à plus de deux décimales est refusé.
+Quand un paiement --- règlement manuel ou rapprochement bancaire --- \textbf{égale le reste dû arrondi au centime} alors que le reste exact en diffère (10.01 pour 10.0050), il \textbf{solde} la facture : le règlement est enregistré pour le reste exact, et l'écart passe en \textbf{troisième ligne} d'écriture sur le compte de différences d'arrondi --- au crédit si le paiement dépasse le reste exact, au débit sinon. La créance se ferme ainsi à zéro. Si aucun compte utilisable n'est désigné --- réglage vide, ou compte archivé, rendu non imputable ou changé de type depuis, ou devenu le compte débiteurs de la facture ---, un tel paiement est \textbf{refusé sans rien écrire}, avec un message qui renvoie à \emph{Paramètres} → \emph{Facturation}. Un paiement sans écart n'exige aucun réglage. Un règlement manuel se saisit au centime : un montant à plus de deux décimales est refusé.
 
 Le format de décompte officiel AFC (e-décompte ESTV) et la conformité LTVA Art.~70 (factures électroniques signées) restent hors périmètre à ce stade.
 
diff --git a/docs/manual/fr/user-manual.pdf b/docs/manual/fr/user-manual.pdf
index 462eea97a..b8b8d01d9 100644
Binary files a/docs/manual/fr/user-manual.pdf and b/docs/manual/fr/user-manual.pdf differ
diff --git a/docs/manual/fr/user-manual.tex b/docs/manual/fr/user-manual.tex
index a699d674b..7a2fec1a0 100644
--- a/docs/manual/fr/user-manual.tex
+++ b/docs/manual/fr/user-manual.tex
@@ -1128,8 +1128,18 @@ \subsection{Échéancier des factures}
 \subsection{Enregistrer et annuler un règlement}\label{sec:reglement-client}
 
 \textbf{Enregistrer.} Sur la fiche d'une facture validée, \emph{Enregistrer un règlement}~: le
-mode (virement sur un compte bancaire, ou espèces et tout autre compte), le montant et la date.
-Kesh passe l'écriture \emph{Débit contrepartie / Crédit débiteurs} et calcule ce qui reste dû.
+mode (virement sur un compte bancaire, ou espèces et un autre compte de contrepartie), le montant
+et la date. Kesh passe l'écriture \emph{Débit contrepartie / Crédit débiteurs} et calcule ce qui
+reste dû. La contrepartie \textbf{ne peut pas être le compte débiteurs de la facture}~: l'écriture
+serait nulle, et le reste dû baisserait sans que rien ne bouge au grand livre. Kesh le refuse dans
+tous les cas~--- de même qu'un compte bancaire lié au compte débiteurs~--- et ne le propose pas dans
+les listes, \textbf{à condition} qu'il porte, au plan comptable, le \textbf{rôle} de compte de
+créances clients~: un compte qui l'a perdu reste proposé, et c'est l'enregistrement qui est
+refusé. Si le compte en cause
+est celui que vous \textbf{choisissez} (compte interne, compte bancaire), choisissez-en un autre
+ou reliez le compte bancaire à son propre compte de banque~; si c'est un compte \textbf{désigné
+dans les réglages} --- le compte de différences d'arrondi ---, un administrateur doit en désigner
+un autre dans \emph{Paramètres} → \emph{Facturation}.
 Un règlement \textbf{partiel} est permis~: la facture reste validée, avec son reste dû, et
 redevient «~payée~» quand le solde atteint zéro. Un montant supérieur au reste dû est
 \textbf{refusé}, de même qu'un montant à plus de deux décimales.
@@ -1157,7 +1167,11 @@ \subsection{Enregistrer et annuler un règlement}\label{sec:reglement-client}
 ainsi que se solde un reste trop petit pour être payé, inférieur au demi-centime. Si le reste porte
 une fraction de centime, elle va au compte de différences d'arrondi. La facture est alors
 «~payée~»~; la liste des règlements montre le solde («~Solde --- escompte accordé~»), et la fiche le
-distingue de ce qui a été encaissé (\emph{Déjà réglé} / \emph{Soldé}). Un solde s'\textbf{annule}
+distingue de ce qui a été encaissé (\emph{Déjà réglé} / \emph{Soldé}). Un solde est
+\textbf{refusé}, sans rien écrire, si le compte de la nature, le compte de différences d'arrondi
+ou le compte de TVA due est le \textbf{compte débiteurs de la facture} (un compte débiteurs
+changé de type depuis, puis désigné)~: un administrateur doit en désigner un autre dans
+\emph{Paramètres} → \emph{Facturation}. Un solde s'\textbf{annule}
 comme un règlement --- bouton \emph{Annuler le solde}, contre-passation datée du jour, TVA
 comprise.
 
@@ -1403,9 +1417,16 @@ \subsection{Régler une facture fournisseur}
     \item \textbf{Virement bancaire} : vous choisissez le \emph{compte bancaire
     source}. Kesh solde la dette fournisseur par le crédit de ce compte bancaire.
     \item \textbf{Compte interne} (caisse, carte, compte de passage) : vous
-    choisissez un \emph{compte de contrepartie} libre.
+    choisissez un \emph{compte de contrepartie}.
 \end{itemize}
 
+La contrepartie \textbf{ne peut pas être le compte créanciers de la facture}~: l'écriture serait
+nulle, et la facture passerait «~payée~» sans paiement. Kesh le refuse dans tous les cas~--- de
+même qu'un compte bancaire lié au compte créanciers~--- et ne le propose pas dans les listes,
+\textbf{à condition} qu'il porte, au plan comptable, le \textbf{rôle} de compte de dettes
+fournisseurs~: un compte qui l'a perdu reste proposé, et c'est l'enregistrement qui est refusé.
+Choisissez un autre compte, ou reliez le compte bancaire à son propre compte de banque.
+
 \textbf{Annuler le règlement.} Un règlement enregistré par erreur ne se supprime pas~: sur la
 fiche d'une facture payée, \emph{Annuler le règlement} (comptable ou administrateur) passe une
 écriture inverse \textbf{datée du jour} et ramène la facture à \emph{ouverte}, à payer --- c'est
@@ -1460,6 +1481,14 @@ \subsection{Paiements par fichier pain.001}
     être \textbf{annulé} tant qu'il n'est pas confirmé).
 \end{enumerate}
 
+Une facture dont le compte créanciers est le compte lié au compte bancaire du lot
+\textbf{n'entre pas dans le lot}~: elle apparaît parmi les refus, avec son motif, et le fichier
+ne la porte pas. Si le compte bancaire a été relié à ce compte \emph{après} la création du lot,
+la \textbf{confirmation est refusée}, sans rien écrire~; deux issues~: relier de nouveau le compte
+bancaire à son propre compte de banque puis confirmer, ou annuler le lot et régler la facture
+depuis sa fiche. Le fichier \texttt{pain.001} a pu être exécuté par la banque~: c'est alors la
+première qu'il faut choisir.
+
 \begin{keshwarning}[title=\faExclamationTriangle\ Annuler le règlement d'une facture payée par lot]
 Le règlement d'une facture payée par un lot \textbf{confirmé} peut être annulé --- le cas
 d'usage est le \textbf{rejet} du virement par la banque. Le lot, lui, n'est pas modifié~: il
@@ -1630,7 +1659,7 @@ \subsubsection{Accepter ou rejeter les propositions}
 Cochez les transactions à traiter, puis cliquez sur l'un des deux boutons placés au-dessus de la liste~:
 
 \begin{itemize}
-    \item \emph{Accepter (N)} --- N est le nombre de lignes cochées --- accepte, pour chaque ligne, \textbf{la candidate affichée}. Pour une facture, l'écriture de règlement est créée (Débit banque / Crédit débiteurs). Si la transaction solde une facture dont le reste porte plus de deux décimales, l'écart d'arrondi passe en troisième ligne, comme pour un règlement manuel (\S\ref{sec:reglement-client}) ; sans compte de différences d'arrondi, la ligne apparaît dans les \emph{Échecs partiels} avec le message «~aucun compte de différences d'arrondi utilisable n'est désigné~» --- désignez-en un dans \emph{Paramètres} → \emph{Facturation}. Pour une règle, l'écriture est passée entre la banque et le compte de contrepartie de la règle.
+    \item \emph{Accepter (N)} --- N est le nombre de lignes cochées --- accepte, pour chaque ligne, \textbf{la candidate affichée}. Pour une facture, l'écriture de règlement est créée (Débit banque / Crédit débiteurs). Si la transaction solde une facture dont le reste porte plus de deux décimales, l'écart d'arrondi passe en troisième ligne, comme pour un règlement manuel (\S\ref{sec:reglement-client}) ; sans compte de différences d'arrondi, la ligne apparaît dans les \emph{Échecs partiels} avec le message «~aucun compte de différences d'arrondi utilisable n'est désigné~» --- désignez-en un dans \emph{Paramètres} → \emph{Facturation}. La proposition échoue aussi, avec son libellé, si le compte bancaire est lié au \textbf{compte débiteurs} de la facture (reliez-le à son propre compte de banque) ou si le compte de différences d'arrondi désigné \textbf{est} le compte débiteurs (un administrateur doit en désigner un autre dans \emph{Paramètres} → \emph{Facturation})~: l'écriture serait nulle. Pour une règle, l'écriture est passée entre la banque et le compte de contrepartie de la règle.
     \item \emph{Rejeter} écarte la proposition~: la transaction est marquée comme revue et \textbf{quitte la liste} de la réconciliation. Elle reste visible dans le \textbf{détail de son import} (\emph{Import bancaire}, puis l'import), avec le statut «~pending~», mais \textbf{sans aucune action}~: aucun geste de l'interface ne permet ensuite de la passer en comptabilité. Ne rejetez donc une transaction que si vous ne comptez pas la comptabiliser par ce chemin.
 \end{itemize}
 
@@ -1862,7 +1891,7 @@ \subsection{Balance âgée des créances}\label{sec:balance-agee}
 \keshscreenshot{balance-agee.png}{Balance âgée : reste dû par client et par tranche de retard, avec total général.}  % TODO capture: onglet Rapports/Balance âgée
 
 \begin{itemize}
-    \item \textbf{Colonnes} : \emph{Non échu} \textbar{} \emph{1-30} \textbar{} \emph{31-60} \textbar{} \emph{61-90} \textbar{} \emph{90+} jours de retard. Avec la colonne « Non échu », le \textbf{total général réconcilie} avec le solde du compte clients (débiteurs) du bilan \emph{tant que ce compte n'est mouvementé que par les factures, leurs règlements et leurs avoirs} (y compris leurs annulations). Toute autre écriture qui le touche l'en écarte : solde de départ, écriture saisie au journal, virement bancaire affecté à ce compte sans passer par une facture, paiement d'une facture fournisseur compensé sur ce compte, ou règlement dont la contrepartie est ce compte lui-même. De même un changement du compte clients dans les réglages de facturation, ou des données antérieures à la version 0.12.1, restaurées ou mises à jour.
+    \item \textbf{Colonnes} : \emph{Non échu} \textbar{} \emph{1-30} \textbar{} \emph{31-60} \textbar{} \emph{61-90} \textbar{} \emph{90+} jours de retard. Avec la colonne « Non échu », le \textbf{total général réconcilie} avec le solde du compte clients (débiteurs) du bilan \emph{tant que ce compte n'est mouvementé que par les factures, leurs règlements et leurs avoirs} (y compris leurs annulations). Toute autre écriture qui le touche l'en écarte : solde de départ, écriture saisie au journal, virement bancaire affecté à ce compte sans passer par une facture, paiement d'une facture fournisseur compensé sur ce compte, ou règlement enregistré avant la version 0.13.0 dont la contrepartie était ce compte lui-même. De même un changement du compte clients dans les réglages de facturation, ou des données antérieures à la version 0.12.1, restaurées ou mises à jour.
     \item \textbf{Détail} : une ligne par client, un total par tranche, et un total général. Chaque client renvoie d'un clic vers \textbf{ses factures}.
     \item \textbf{Export CSV} : réservé aux rôles \emph{Comptable} et \emph{Administrateur} (le rapport lui-même est consultable par tous les rôles).
 \end{itemize}
diff --git a/frontend/src/lib/features/accounts/account-options.test.ts b/frontend/src/lib/features/accounts/account-options.test.ts
index 674d43445..393dbcacd 100644
--- a/frontend/src/lib/features/accounts/account-options.test.ts
+++ b/frontend/src/lib/features/accounts/account-options.test.ts
@@ -6,7 +6,12 @@
 
 import { describe, it, expect } from 'vitest';
 import type { AccountResponse } from './accounts.types';
-import { withCurrentAccount } from './account-options';
+import {
+	accountIdsWithRole,
+	bankAccountsNotLinkedTo,
+	withCurrentAccount,
+	withoutAccountIds,
+} from './account-options';
 
 function acc(
 	partial: Partial<AccountResponse> & { id: number; number: string; name: string },
@@ -97,3 +102,52 @@ describe('withCurrentAccount — un compte ARCHIVÉ configuré avant son archiva
 		expect(options[0].id).toBe(ARCHIVE.id);
 	});
 });
+
+// Story 15-6b (#474, AC8, test 17) — les écrans de règlement ne proposent plus le compte soldé.
+describe('fonctions d’écran de la Story 15-6b', () => {
+	const DEBITEURS = acc({ id: 1100, number: '1100', name: 'Débiteurs', role: 'Receivable' });
+	const CREANCIERS = acc({
+		id: 2000,
+		number: '2000',
+		name: 'Créanciers',
+		accountType: 'Liability',
+		role: 'Payable',
+	});
+	const SANS_ROLE = acc({ id: 1000, number: '1000', name: 'Caisse' });
+	const PLAN = [SANS_ROLE, DEBITEURS, CREANCIERS];
+
+	function bank(id: number, journalAccountId: number | null) {
+		return { id, journalAccountId };
+	}
+
+	it('accountIdsWithRole rend les seuls comptes du rôle donné', () => {
+		expect([...accountIdsWithRole(PLAN, 'Receivable')]).toEqual([1100]);
+		expect([...accountIdsWithRole(PLAN, 'Payable')]).toEqual([2000]);
+		expect(accountIdsWithRole(PLAN, 'VatPayable').size).toBe(0);
+	});
+
+	it('withoutAccountIds écarte le rôle donné et garde les autres, sans rôle compris', () => {
+		const kept = withoutAccountIds(PLAN, accountIdsWithRole(PLAN, 'Receivable'));
+		expect(kept.map((a) => a.id)).toEqual([1000, 2000]);
+	});
+
+	it('bankAccountsNotLinkedTo écarte les comptes bancaires liés, garde les autres et les non liés', () => {
+		const ids = accountIdsWithRole(PLAN, 'Receivable');
+		const kept = bankAccountsNotLinkedTo([bank(1, 1100), bank(2, 1020), bank(3, null)], ids);
+		expect(kept.map((b) => b.id)).toEqual([2, 3]);
+	});
+
+	it('un compte bancaire lié à un débiteurs NON IMPUTABLE est écarté (ids calculés avant le filtre)', () => {
+		const nonImputable = acc({ ...DEBITEURS, postable: false });
+		const plan = [SANS_ROLE, nonImputable];
+		// Le geste correct : les ids sur la liste reçue, puis le filtre `active && postable`.
+		const ids = accountIdsWithRole(plan, 'Receivable');
+		expect(bankAccountsNotLinkedTo([bank(1, 1100)], ids)).toEqual([]);
+		// La mutation à éviter : calculer les ids APRÈS le filtre laisse passer le compte bancaire.
+		const idsApresFiltre = accountIdsWithRole(
+			plan.filter((a) => a.active && a.postable),
+			'Receivable',
+		);
+		expect(bankAccountsNotLinkedTo([bank(1, 1100)], idsApresFiltre)).toHaveLength(1);
+	});
+});
diff --git a/frontend/src/lib/features/accounts/account-options.ts b/frontend/src/lib/features/accounts/account-options.ts
index bd68a6c55..a0f1a508b 100644
--- a/frontend/src/lib/features/accounts/account-options.ts
+++ b/frontend/src/lib/features/accounts/account-options.ts
@@ -41,7 +41,7 @@
  * dont les options sont l'unique source de vérité de ce qui est affichable.
  */
 
-import type { AccountResponse } from './accounts.types';
+import type { AccountResponse, AccountRole } from './accounts.types';
 
 /**
  * Rend `filtered`, en y ajoutant le compte d'identifiant `currentId` s'il
@@ -72,3 +72,49 @@ export function withCurrentAccount(
 
 	return [current, ...filtered];
 }
+
+// ---------------------------------------------------------------------------
+// Story 15-6b (#474) — les écrans de règlement ne proposent plus le compte soldé
+// ---------------------------------------------------------------------------
+
+/**
+ * Identifiants des comptes portant le rôle `role` (Story 15-6b, AC8 ; signature
+ * partagée avec la 15-6c, choix C-15-6-14).
+ *
+ * **Pourquoi le rôle** : un écran de règlement n'a pas l'écriture de vente sous
+ * la main ; le rôle `Receivable` / `Payable` est un singleton par société, dont
+ * les réglages de facturation sont dérivés. ⚠️ **La garde serveur, exacte, reste
+ * l'autorité** : elle compare la contrepartie au compte que porte l'écriture de
+ * vente ou d'achat. Si le réglage a été déplacé hors du compte de rôle, l'écran
+ * peut proposer un compte que le serveur refusera, avec un message clair —
+ * jamais l'inverse.
+ *
+ * ⛔ **Calculer les ids sur la liste que l'écran REÇOIT, avant le filtre
+ * `active && postable`** : sans quoi un compte bancaire lié à un compte
+ * débiteurs devenu **non imputable** ne serait pas écarté.
+ *
+ * ⚠️ **Les comptes archivés n'y sont pas, et c'est voulu** (choix C-15-6-17) :
+ * les écrans chargent le plan sans eux. Un compte bancaire lié à un compte
+ * archivé reste donc proposé — mais aucune écriture ne peut viser un compte
+ * archivé (garde `active` du serveur) : le serveur suffit.
+ */
+export function accountIdsWithRole(accounts: AccountResponse[], role: AccountRole): Set<number> {
+	return new Set(accounts.filter((a) => a.role === role).map((a) => a.id));
+}
+
+/** Les comptes dont l'identifiant n'est pas dans `ids` (Story 15-6b, AC8). */
+export function withoutAccountIds(accounts: AccountResponse[], ids: Set<number>): AccountResponse[] {
+	return accounts.filter((a) => !ids.has(a.id));
+}
+
+/**
+ * Les comptes bancaires dont le compte du grand livre (`journalAccountId`)
+ * n'est pas dans `ids` (Story 15-6b, AC8). Un compte bancaire sans compte lié
+ * est gardé : ce filtre ne juge que le lien au compte soldé.
+ */
+export function bankAccountsNotLinkedTo<T extends { journalAccountId: number | null }>(
+	bankAccounts: T[],
+	ids: Set<number>,
+): T[] {
+	return bankAccounts.filter((b) => b.journalAccountId === null || !ids.has(b.journalAccountId));
+}
diff --git a/frontend/src/lib/features/invoices/SettleInvoiceDialog.svelte b/frontend/src/lib/features/invoices/SettleInvoiceDialog.svelte
index 5831f966d..bdb8d6146 100644
--- a/frontend/src/lib/features/invoices/SettleInvoiceDialog.svelte
+++ b/frontend/src/lib/features/invoices/SettleInvoiceDialog.svelte
@@ -21,6 +21,11 @@
 	import type { AccountResponse } from '$lib/features/accounts/accounts.types';
 	import type { BankAccountSummary } from '$lib/features/bank-accounts/bank-accounts.api';
 	import { dueToCentime } from './invoice-helpers';
+	import {
+		accountIdsWithRole,
+		bankAccountsNotLinkedTo,
+		withoutAccountIds,
+	} from '$lib/features/accounts/account-options';
 
 	export type SettlementPayload = {
 		settlementType: 'bank_transfer' | 'internal_account';
@@ -86,11 +91,40 @@
 			// (« 68.1000 ») ; le champ montre des centimes.
 			amount = amountDue !== null ? dueToCentime(amountDue).toFixed(2) : '';
 			settlementType = 'bank_transfer';
-			bankAccountId = bankAccounts.find((b) => b.isPrimary)?.id ?? bankAccounts[0]?.id ?? null;
+			// La présélection du compte bancaire vit dans l'effet suivant (Story
+			// 15-6b) : elle dépend de `accounts`, que cet effet ne doit pas lire —
+			// une liste arrivée après l'ouverture effacerait la saisie en cours.
+			bankAccountId = null;
 			accountId = null;
 		}
 	});
 
+	// Story 15-6b (#474, AC8) — le compte débiteurs n'est jamais une contrepartie :
+	// `D 1100 / C 1100` s'équilibre, le reste dû baisserait sans que rien ne bouge
+	// au grand livre. Les ids se calculent sur la liste REÇUE, avant le filtre
+	// `active && postable` (un compte bancaire lié à un 1100 devenu non imputable
+	// doit être écarté aussi). La garde serveur reste l'autorité.
+	let receivableIds = $derived(accountIdsWithRole(accounts, 'Receivable'));
+	let eligibleBankAccounts = $derived(bankAccountsNotLinkedTo(bankAccounts, receivableIds));
+	// Liste vide PARCE QUE le filtre a écarté un compte : le dire. Une société
+	// sans aucun compte bancaire n'a rien d'écarté, et le message, qui accuse le
+	// compte débiteurs, y serait faux.
+	let noEligibleBankAccount = $derived(
+		eligibleBankAccounts.length === 0 && bankAccounts.length > eligibleBankAccounts.length,
+	);
+
+	// Présélection du compte bancaire, DANS la liste filtrée : le primaire, sinon
+	// le premier. Elle ne remplace la valeur courante que si celle-ci est absente
+	// de la liste (`null` compris) — un choix de l'utilisateur survit à l'arrivée
+	// tardive de `accounts`, et ni la date, ni le montant, ni le mode ne bougent.
+	$effect(() => {
+		if (!open) return;
+		const current = bankAccountId;
+		if (current !== null && eligibleBankAccounts.some((b) => b.id === current)) return;
+		bankAccountId =
+			eligibleBankAccounts.find((b) => b.isPrimary)?.id ?? eligibleBankAccounts[0]?.id ?? null;
+	});
+
 	// ⚠️ Seuls les comptes ACTIFS **et IMPUTABLES** : le backend refuse l'un et
 	// l'autre, et proposer ce qu'il refusera est une erreur qu'on fait commettre.
 	//
@@ -102,7 +136,14 @@
 	// défaut même que la story ferme. Le patron est celui de l'écran de règlement
 	// fournisseur (`supplier-invoices/[id]/+page.svelte:66`), qui filtrait déjà
 	// les deux.
-	let selectableAccounts = $derived(accounts.filter((a) => a.active && a.postable));
+	//
+	// Story 15-6b : ni le compte débiteurs (rôle `Receivable`) — cf. plus haut.
+	let selectableAccounts = $derived(
+		withoutAccountIds(
+			accounts.filter((a) => a.active && a.postable),
+			receivableIds,
+		),
+	);
 
 	let clientError = $derived.by(() => {
 		if (!settledOn) {
@@ -205,10 +246,18 @@
 					bind:value={bankAccountId}
 					data-testid="settle-bank"
 				>
-					{#each bankAccounts as b (b.id)}
+					{#each eligibleBankAccounts as b (b.id)}
 						<option value={b.id}>{b.bankName} — {b.iban}</option>
 					{/each}
 				</select>
+				{#if noEligibleBankAccount}
+					<p class="mt-1 text-xs text-destructive" data-testid="settle-no-eligible-bank">
+						{i18nMsg(
+							'invoices-settle-no-eligible-bank-account',
+							'Aucun compte bancaire utilisable : le seul compte lié est le compte débiteurs de cette facture. Reliez un compte bancaire à son propre compte de banque, ou réglez par un compte interne.',
+						)}
+					</p>
+				{/if}
 			</div>
 		{:else}
 			<div class="mt-2">
diff --git a/frontend/src/lib/features/invoices/SettleInvoiceDialog.test.ts b/frontend/src/lib/features/invoices/SettleInvoiceDialog.test.ts
index 45aeb609d..b98b3afd2 100644
--- a/frontend/src/lib/features/invoices/SettleInvoiceDialog.test.ts
+++ b/frontend/src/lib/features/invoices/SettleInvoiceDialog.test.ts
@@ -11,7 +11,9 @@ vi.mock('$lib/shared/utils/i18n.svelte', () => ({
 }));
 
 import SettleInvoiceDialog from './SettleInvoiceDialog.svelte';
+import SettleInvoiceDialogHost from './SettleInvoiceDialogHost.test.svelte';
 import type { BankAccountSummary } from '$lib/features/bank-accounts/bank-accounts.api';
+import type { AccountResponse } from '$lib/features/accounts/accounts.types';
 
 const banque = {
 	id: 1,
@@ -91,3 +93,153 @@ describe('SettleInvoiceDialog — le reste dû au centime', () => {
 		expect(queryByText(SCALE)).toBeNull();
 	});
 });
+
+// Story 15-6b (#474, AC8, AC9 ; test 18) — le compte débiteurs n'est pas une contrepartie.
+describe('SettleInvoiceDialog — la contrepartie n’est pas le compte débiteurs', () => {
+	const DEBITEURS = {
+		id: 1100,
+		number: '1100',
+		name: 'Débiteurs',
+		accountType: 'Asset',
+		active: true,
+		postable: true,
+		role: 'Receivable',
+	} as unknown as AccountResponse;
+	const CAISSE = {
+		id: 1000,
+		number: '1000',
+		name: 'Caisse',
+		accountType: 'Asset',
+		active: true,
+		postable: true,
+		role: null,
+	} as unknown as AccountResponse;
+	function compte(id: number, journalAccountId: number | null, isPrimary = false) {
+		return {
+			...banque,
+			id,
+			bankName: `Banque ${id}`,
+			isPrimary,
+			journalAccountId,
+		} as BankAccountSummary;
+	}
+	const EMPTY =
+		'Aucun compte bancaire utilisable : le seul compte lié est le compte débiteurs de cette facture. Reliez un compte bancaire à son propre compte de banque, ou réglez par un compte interne.';
+
+	function monter(accounts: AccountResponse[], bankAccounts: BankAccountSummary[], errorMsg = '') {
+		return render(SettleInvoiceDialog, {
+			open: true,
+			onOpenChange: vi.fn(),
+			invoiceDate: '2026-01-01',
+			amountDue: '100.00',
+			accounts,
+			bankAccounts,
+			errorMsg,
+			onConfirm: vi.fn(),
+		});
+	}
+	const options = (testId: string) =>
+		Array.from(
+			(document.querySelector(`[data-testid="${testId}"]`) as HTMLSelectElement).options,
+		).map((o) => o.value);
+
+	it('1100 (rôle Receivable) est absent du menu « Compte interne » (mutation : filtre retiré)', async () => {
+		const { getByTestId } = monter([CAISSE, DEBITEURS], []);
+		await fireEvent.change(getByTestId('settle-type'), { target: { value: 'internal_account' } });
+		await waitFor(() => expect(options('settle-account')).toContain('1000'));
+		expect(options('settle-account')).not.toContain('1100');
+	});
+
+	it('un compte bancaire lié au 1100 est absent, et la présélection tombe sur un autre', async () => {
+		monter([CAISSE, DEBITEURS], [compte(1, 1100, true), compte(2, 1020)]);
+		await waitFor(() => expect(options('settle-bank')).toEqual(['2']));
+		expect((document.getElementById('settle-bank') as HTMLSelectElement).value).toBe('2');
+	});
+
+	it('`accounts` arrivé APRÈS l’ouverture ne réinitialise pas la saisie (mutation : présélection dans l’effet de réinitialisation)', async () => {
+		// Hôte qui passe les props une à une (cf. son en-tête : `rerender` les changerait toutes).
+		const { getByTestId } = render(SettleInvoiceDialogHost, {
+			lateAccounts: [CAISSE, DEBITEURS],
+			bankAccounts: [compte(1, 1100, true), compte(2, 1020)],
+		});
+		const input = document.getElementById('settle-amount') as HTMLInputElement;
+		await waitFor(() => expect(input.value).toBe('100.00'));
+		await waitFor(() =>
+			expect((document.getElementById('settle-bank') as HTMLSelectElement).value).toBe('1'),
+		);
+		await fireEvent.input(input, { target: { value: '40.00' } });
+		await fireEvent.click(getByTestId('host-load-accounts'));
+		await waitFor(() => expect(options('settle-bank')).toEqual(['2']));
+		expect((document.getElementById('settle-bank') as HTMLSelectElement).value).toBe('2');
+		expect((document.getElementById('settle-amount') as HTMLInputElement).value).toBe('40.00');
+	});
+
+	// Revue de code P1 (finding L6) — les ids se calculent AVANT le filtre
+	// `active && postable` : un 1100 devenu non imputable écarte toujours la
+	// banque qui y est liée.
+	it('1100 non imputable : la banque qui y est liée reste absente (mutation : ids calculés après le filtre `active && postable`)', async () => {
+		monter(
+			[CAISSE, { ...DEBITEURS, postable: false } as AccountResponse],
+			[compte(1, 1100, true), compte(2, 1020)],
+		);
+		await waitFor(() => expect(options('settle-bank')).toEqual(['2']));
+	});
+
+	// Revue de code P1 (finding L7) — la réouverture : la réinitialisation remet
+	// le compte bancaire à `null`, puis l'effet distinct présélectionne DANS la
+	// liste filtrée ; le montant revient au reste dû.
+	it('réouverture : saisie réinitialisée, présélection refaite dans la liste filtrée', async () => {
+		const { getByTestId } = render(SettleInvoiceDialogHost, {
+			lateAccounts: [CAISSE, DEBITEURS],
+			bankAccounts: [compte(1, 1100, true), compte(2, 1020), compte(3, 1030)],
+		});
+		await fireEvent.click(getByTestId('host-load-accounts'));
+		const bank = () => document.getElementById('settle-bank') as HTMLSelectElement;
+		const amount = () => document.getElementById('settle-amount') as HTMLInputElement;
+		await waitFor(() => expect(options('settle-bank')).toEqual(['2', '3']));
+		await waitFor(() => expect(bank().value).toBe('2'));
+		await fireEvent.change(bank(), { target: { value: '3' } });
+		await fireEvent.input(amount(), { target: { value: '40.00' } });
+		expect(bank().value).toBe('3');
+
+		await fireEvent.click(getByTestId('host-toggle-open')); // fermer
+		await fireEvent.click(getByTestId('host-toggle-open')); // rouvrir
+		await waitFor(() => expect(amount().value).toBe('100.00'));
+		await waitFor(() => expect(bank().value).toBe('2'));
+	});
+
+	// Revue de code P1 (finding L7) — un choix de l'utilisateur, encore éligible,
+	// survit à l'arrivée tardive de `accounts`.
+	it('un choix de l’utilisateur encore éligible survit à l’arrivée tardive de `accounts`', async () => {
+		const { getByTestId } = render(SettleInvoiceDialogHost, {
+			lateAccounts: [CAISSE, DEBITEURS],
+			bankAccounts: [compte(1, 1100, true), compte(2, 1020), compte(3, 1030)],
+		});
+		const bank = () => document.getElementById('settle-bank') as HTMLSelectElement;
+		await waitFor(() => expect(bank().value).toBe('1'));
+		await fireEvent.change(bank(), { target: { value: '3' } });
+		await fireEvent.click(getByTestId('host-load-accounts'));
+		await waitFor(() => expect(options('settle-bank')).toEqual(['2', '3']));
+		expect(bank().value).toBe('3');
+	});
+
+	it('le seul compte bancaire lié au 1100 → le message de liste vide', async () => {
+		const { findByText } = monter([CAISSE, DEBITEURS], [compte(1, 1100, true)]);
+		expect(await findByText(EMPTY)).toBeTruthy();
+	});
+
+	it('aucun compte bancaire → PAS de message de liste vide (rien n’a été écarté)', async () => {
+		const { queryByTestId } = monter([CAISSE, DEBITEURS], []);
+		await waitFor(() => expect(document.getElementById('settle-bank')).not.toBeNull());
+		expect(queryByTestId('settle-no-eligible-bank')).toBeNull();
+	});
+
+	it('la prop `errorMsg` s’affiche (AC9 — rendu seulement)', async () => {
+		const refus = 'Le compte 1100 est le compte débiteurs de cette facture';
+		const { findByText, getByTestId } = monter([CAISSE], [compte(2, 1020, true)], refus);
+		await waitFor(() =>
+			expect((getByTestId('settle-bank') as HTMLSelectElement).value).toBe('2'),
+		);
+		expect(await findByText(refus)).toBeTruthy();
+	});
+});
diff --git a/frontend/src/lib/features/invoices/SettleInvoiceDialogHost.test.svelte b/frontend/src/lib/features/invoices/SettleInvoiceDialogHost.test.svelte
new file mode 100644
index 000000000..f61e78a31
--- /dev/null
+++ b/frontend/src/lib/features/invoices/SettleInvoiceDialogHost.test.svelte
@@ -0,0 +1,39 @@
+<!--
+  Doublure de test (Story 15-6b, test 18) — hôte de `SettleInvoiceDialog` qui lui passe ses props
+  UNE À UNE, comme un vrai parent, et ne change que `accounts` (bouton `host-load-accounts`)
+  ou `open` (bouton `host-toggle-open` — réouverture, revue de code P1, finding L7).
+
+  ⚠️ Pourquoi pas `rerender` : celui de @testing-library/svelte remplace l'objet de props entier
+  (`$state.raw`), si bien que CHAQUE prop paraît changée et que l'effet de réinitialisation du
+  dialogue se rejoue — ce qu'un parent réel ne provoque pas. Le test serait rouge sur un
+  composant juste. Le suffixe `.test.` tient ce fichier hors des relevés i18n et hors du build.
+-->
+<script lang="ts">
+	import SettleInvoiceDialog from './SettleInvoiceDialog.svelte';
+	import type { AccountResponse } from '$lib/features/accounts/accounts.types';
+	import type { BankAccountSummary } from '$lib/features/bank-accounts/bank-accounts.api';
+
+	type Props = {
+		lateAccounts: AccountResponse[];
+		bankAccounts: BankAccountSummary[];
+	};
+	let { lateAccounts, bankAccounts }: Props = $props();
+	let accounts = $state<AccountResponse[]>([]);
+	let open = $state(true);
+</script>
+
+<button type="button" data-testid="host-load-accounts" onclick={() => (accounts = lateAccounts)}>
+	charger
+</button>
+<button type="button" data-testid="host-toggle-open" onclick={() => (open = !open)}>
+	basculer
+</button>
+<SettleInvoiceDialog
+	{open}
+	onOpenChange={() => {}}
+	invoiceDate="2026-01-01"
+	amountDue="100.00"
+	{accounts}
+	{bankAccounts}
+	onConfirm={() => {}}
+/>
diff --git a/frontend/src/lib/features/payment-batches/payment-batch-helpers.test.ts b/frontend/src/lib/features/payment-batches/payment-batch-helpers.test.ts
index d986af7fa..e12c95585 100644
--- a/frontend/src/lib/features/payment-batches/payment-batch-helpers.test.ts
+++ b/frontend/src/lib/features/payment-batches/payment-batch-helpers.test.ts
@@ -56,9 +56,10 @@ describe('paymentBatchStatusLabel', () => {
 describe('failedItemLabel', () => {
 	// ⚠️ L'ancienne rédaction assertait `toContain('coordonnées')` et `toContain('lot')` — plus
 	// insidieux qu'un `toBe` : un `toContain` survit à une traduction PARTIELLE, donc il serait
-	// resté vert sur un correctif à moitié fait. Les six codes sont désormais assertés en
-	// entier, et le chemin réel est éprouvé par le cas suivant.
-	it('mappe les six codes sur leur repli français', () => {
+	// resté vert sur un correctif à moitié fait. Les huit codes sont désormais assertés en
+	// entier (les deux derniers par la Story 15-6b), et le chemin réel est éprouvé par le cas
+	// suivant.
+	it('mappe les huit codes sur leur repli français', () => {
 		expect(failedItemLabel('SUPPLIER_INVOICE_NOT_FOUND')).toBe('Facture introuvable');
 		expect(failedItemLabel('SUPPLIER_INVOICE_NOT_OPEN')).toBe('Facture non ouverte');
 		expect(failedItemLabel('NO_PAYMENT_COORDINATES')).toBe(
@@ -67,6 +68,12 @@ describe('failedItemLabel', () => {
 		expect(failedItemLabel('ALREADY_IN_GENERATED_BATCH')).toBe('Déjà dans un lot créé');
 		expect(failedItemLabel('INVALID_IBAN')).toBe('IBAN invalide');
 		expect(failedItemLabel('INVALID_QR_IBAN')).toBe('QR-IBAN invalide');
+		expect(failedItemLabel('SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT')).toBe(
+			'Le compte bancaire du lot est lié au compte créanciers de cette facture'
+		);
+		expect(failedItemLabel('SUPPLIER_INVOICE_PURCHASE_ENTRY_MALFORMED')).toBe(
+			"Écriture d'achat sans ligne de crédit : facture à vérifier"
+		);
 	});
 
 	it('un code inconnu retombe sur sa valeur brute', () => {
diff --git a/frontend/src/lib/features/payment-batches/payment-batch-helpers.ts b/frontend/src/lib/features/payment-batches/payment-batch-helpers.ts
index d13e27c55..55d98c9b9 100644
--- a/frontend/src/lib/features/payment-batches/payment-batch-helpers.ts
+++ b/frontend/src/lib/features/payment-batches/payment-batch-helpers.ts
@@ -56,7 +56,7 @@ export function paymentBatchStatusLabel(status: PaymentBatchStatus): string {
  * § *Pattern batch — FailedProposal per-proposal* de `CLAUDE.md`. Seul leur affichage est
  * traduit ; un code inconnu retombe sur sa valeur brute, ce qui vaut mieux qu'une case vide.
  *
- * ⚠️ **Les six libellés sont RELEVÉS, pas inventés** : `SUPPLIER_INVOICE_NOT_FOUND` sur
+ * ⚠️ **Huit codes. Les six premiers libellés sont RELEVÉS, pas inventés** : `SUPPLIER_INVOICE_NOT_FOUND` sur
  * `reminders-error-invoice-not-found`, les deux IBAN sur
  * `imported-supplier-invoices-error-invalid-iban` — **sans** « du créancier », qui ne
  * s'applique pas ici —, et *ouverte* est en partie A du glossaire. `NO_PAYMENT_COORDINATES`
@@ -70,7 +70,15 @@ export function paymentBatchStatusLabel(status: PaymentBatchStatus): string {
  * désormais le mot exact de la colonne Statut. Laisser cette ligne de côté aurait rendu le
  * correctif incohérent avec lui-même.
  *
- * ⚠️ **Les six clés sont écrites en toutes lettres, jamais construites par gabarit.** Une
+ * ⚠️ **Les deux derniers libellés sont ÉCRITS par la Story 15-6b (#474), non relevés du
+ * glossaire** : `SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT` — le compte bancaire du lot est lié au
+ * compte créanciers de la facture, dont le règlement écrirait `D 2000 / C 2000` (la facture n'entre
+ * pas dans le lot, aucun fichier pain.001 ne la porte) — et `SUPPLIER_INVOICE_PURCHASE_ENTRY_MALFORMED`
+ * — l'écriture d'achat n'a pas de ligne de crédit, la facture est à vérifier. Le libellé ne nomme
+ * pas le compte : le `failed[]` du lot n'affiche que `#id — libellé`, et le compte en cause est
+ * celui du compte bancaire choisi à l'écran.
+ *
+ * ⚠️ **Les huit clés sont écrites en toutes lettres, jamais construites par gabarit.** Une
  * clé statique est vue par `i18n-keys.test.ts` dès qu'elle manque d'un catalogue ; une clé
  * dynamique demande un motif déclaré, et une carte peut grandir sans qu'aucune garde ne
  * rougisse — c'est exactement ce qui a été mesuré en passe 4 de la story 23-3.
@@ -92,6 +100,16 @@ export function failedItemLabel(code: string): string {
 			return i18nMsg('payment-batches-failed-invalid-iban', 'IBAN invalide');
 		case 'INVALID_QR_IBAN':
 			return i18nMsg('payment-batches-failed-invalid-qr-iban', 'QR-IBAN invalide');
+		case 'SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT':
+			return i18nMsg(
+				'payment-batches-failed-counterparty-is-claim-account',
+				'Le compte bancaire du lot est lié au compte créanciers de cette facture'
+			);
+		case 'SUPPLIER_INVOICE_PURCHASE_ENTRY_MALFORMED':
+			return i18nMsg(
+				'payment-batches-failed-purchase-entry-malformed',
+				"Écriture d'achat sans ligne de crédit : facture à vérifier"
+			);
 		default:
 			return code;
 	}
diff --git a/frontend/src/lib/features/reconciliation/failed-proposal-label.test.ts b/frontend/src/lib/features/reconciliation/failed-proposal-label.test.ts
index 6dfce32be..e3913bedb 100644
--- a/frontend/src/lib/features/reconciliation/failed-proposal-label.test.ts
+++ b/frontend/src/lib/features/reconciliation/failed-proposal-label.test.ts
@@ -3,7 +3,8 @@
 // ⚠️ La liste des codes est ÉCRITE EN DUR, et non lue depuis le module : un test qui
 // itérerait sur la table de production serait vert par construction (fiche, § « Tests — ce qui
 // rendrait un test vert sans rien prouver »). Relevé : les 25 littéraux de
-// `crates/kesh-api/src/routes/reconciliation.rs` + `ACCOUNT_NOT_POSTABLE` (DbError::error_code).
+// `crates/kesh-api/src/routes/reconciliation.rs` + les deux codes de `DbError::error_code()` :
+// `ACCOUNT_NOT_POSTABLE` et `SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT` (Story 15-6b).
 
 import { describe, it, expect, vi, beforeEach } from 'vitest';
 
@@ -50,6 +51,7 @@ const EXPECTED_KEYS: Record<string, string> = {
 	RECONCILIATION_SPLIT_IMBALANCE: 'reconciliation-split-error-imbalance',
 	RECONCILIATION_TRANSACTION_NOT_PENDING: 'reconciliation-failed-transaction-not-pending',
 	ROUNDING_ACCOUNT_NOT_CONFIGURED: 'error-rounding-account-not-configured',
+	SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT: 'reconciliation-failed-counterparty-is-claim-account',
 	VALIDATION_ERROR: 'error-validation',
 };
 
@@ -58,8 +60,8 @@ describe('failedProposalLabel', () => {
 		calls.length = 0;
 	});
 
-	it('couvre les 26 codes relevés', () => {
-		expect(Object.keys(EXPECTED_KEYS)).toHaveLength(26);
+	it('couvre les 27 codes relevés', () => {
+		expect(Object.keys(EXPECTED_KEYS)).toHaveLength(27);
 	});
 
 	for (const [code, key] of Object.entries(EXPECTED_KEYS)) {
@@ -124,6 +126,38 @@ describe('failedProposalLabel', () => {
 		expect(label).toContain('plus d’un jour avant la facture');
 	});
 
+	// Story 15-6b (#474, AC7) — deux remèdes selon `details.role`.
+	it('SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT, role counterparty : relier le compte bancaire', () => {
+		const label = failedProposalLabel('SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT', {
+			bankAccountId: 3,
+			accountId: 7,
+			accountNumber: '1100',
+			claim: 'receivable',
+			role: 'counterparty',
+		});
+		expect(calls).toEqual(['reconciliation-failed-counterparty-is-claim-account']);
+		expect(label).toContain('propre compte de banque');
+	});
+
+	it('SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT, role rounding : renvoi aux réglages (mutation : rôle ignoré)', () => {
+		const label = failedProposalLabel('SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT', {
+			accountId: 7,
+			accountNumber: '1100',
+			claim: 'receivable',
+			role: 'rounding',
+		});
+		expect(calls).toEqual(['reconciliation-failed-rounding-account-is-claim-account']);
+		expect(label).toContain('Paramètres → Facturation');
+	});
+
+	it.each([
+		['role non chaîne', { role: 1 }],
+		['details absent', null],
+	])('SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT (%s) → libellé du compte bancaire', (_cas, details) => {
+		failedProposalLabel('SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT', details);
+		expect(calls).toEqual(['reconciliation-failed-counterparty-is-claim-account']);
+	});
+
 	it.each([
 		['invoice_already_paid', { reason: 'invoice_already_paid' }],
 		['payment_date_outside_window', { reason: 'payment_date_outside_window', window_days: 30 }],
diff --git a/frontend/src/lib/features/reconciliation/failed-proposal-label.ts b/frontend/src/lib/features/reconciliation/failed-proposal-label.ts
index 4c4ccfb08..478a1abcf 100644
--- a/frontend/src/lib/features/reconciliation/failed-proposal-label.ts
+++ b/frontend/src/lib/features/reconciliation/failed-proposal-label.ts
@@ -6,11 +6,12 @@
  * FailedProposal per-proposal* du `CLAUDE.md` ; seul leur affichage est traduit. Patron :
  * `failedItemLabel` (`payment-batches/payment-batch-helpers.ts`).
  *
- * **Les 26 codes** sont ceux que `crates/kesh-api/src/routes/reconciliation.rs` peut poser dans
+ * **Les 27 codes** sont ceux que `crates/kesh-api/src/routes/reconciliation.rs` peut poser dans
  * `failed[]` : les 25 littéraux relevés par
  * `grep -ohE 'error_code: "[A-Z_]+"' crates/kesh-api/src/routes/reconciliation.rs | sort -u`,
- * plus `ACCOUNT_NOT_POSTABLE`, posé par `DbError::error_code()` (seule forme non littérale du
- * fichier). Un code apparu depuis retombe sur le repli, qui **montre le code brut** : mieux vaut
+ * plus les deux codes posés par `DbError::error_code()` (seules formes non littérales du
+ * fichier) : `ACCOUNT_NOT_POSTABLE` et, depuis la Story 15-6b (#474),
+ * `SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT`. Un code apparu depuis retombe sur le repli, qui **montre le code brut** : mieux vaut
  * un code qu'une case vide.
  *
  * ⚠️ **Clés réutilisées** (choix C37, étendu par C-15-5c-1) : quand un message existant convient
@@ -21,8 +22,10 @@
  * ⚠️ **Les clés sont écrites en toutes lettres, jamais construites par gabarit** : une clé
  * statique est vue par `i18n-keys.test.ts` dès qu'elle manque d'un catalogue.
  *
- * ⚠️ **Deux codes seulement lisent leur `details`** : `ACCOUNT_NOT_POSTABLE` (AC2), pour
- * nommer les comptes, et `RECONCILIATION_INVOICE_NOT_ELIGIBLE`, pour la seule raison
+ * ⚠️ **Trois codes seulement lisent leur `details`** : `SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT`
+ * (Story 15-6b), pour son `role` — le compte de banque lié au compte débiteurs et le compte
+ * d'arrondi désigné qui l'est n'appellent pas le même remède ; `ACCOUNT_NOT_POSTABLE` (AC2), pour
+ * nommer les comptes ; et `RECONCILIATION_INVOICE_NOT_ELIGIBLE`, pour la seule raison
  * `payment_date_before_invoice_date` (revue de code P1, E1 — choix C-15-5c-3). Cette raison
  * est la seule qu'un utilisateur rencontre sans avoir rien fait de travers : la proposition
  * retient les factures datées de 30 jours avant à 30 jours après la transaction, alors que
@@ -74,10 +77,20 @@ export function failureReason(details: unknown): string | null {
 	return typeof reason === 'string' ? reason : null;
 }
 
+/**
+ * Rôle d'un `details` de la forme `{ role: "<rôle>" }` (Story 15-6b), ou `null` pour toute autre
+ * forme. Même prudence que `failureReason`.
+ */
+export function failureRole(details: unknown): string | null {
+	if (typeof details !== 'object' || details === null) return null;
+	const role = (details as { role?: unknown }).role;
+	return typeof role === 'string' ? role : null;
+}
+
 /**
  * Libellé traduit d'un `errorCode` de `failed[]`. `details` n'est lu que pour
- * `ACCOUNT_NOT_POSTABLE` et `RECONCILIATION_INVOICE_NOT_ELIGIBLE` ; un code inconnu rend
- * un repli qui cite le code.
+ * `SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT`, `ACCOUNT_NOT_POSTABLE` et
+ * `RECONCILIATION_INVOICE_NOT_ELIGIBLE` ; un code inconnu rend un repli qui cite le code.
  */
 export function failedProposalLabel(code: string, details?: unknown): string {
 	switch (code) {
@@ -198,6 +211,20 @@ export function failedProposalLabel(code: string, details?: unknown): string {
 				'error-rounding-account-not-configured',
 				"Ce paiement solde la facture au centime, mais aucun compte de différences d'arrondi utilisable n'est désigné : choisissez-en un dans Paramètres → Facturation."
 			);
+		case 'SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT':
+			// Story 15-6b (#474) : l'écriture serait `D 1100 / C 1100`. Deux remèdes selon le
+			// compte en cause — le seul `rounding` renvoie aux réglages ; tout autre rôle est le
+			// compte de banque (`counterparty`), seul autre rôle que pose l'acceptation.
+			if (failureRole(details) === 'rounding') {
+				return i18nMsg(
+					'reconciliation-failed-rounding-account-is-claim-account',
+					'Le compte d’arrondi désigné est le compte débiteurs de la facture : un administrateur doit en désigner un autre dans Paramètres → Facturation.'
+				);
+			}
+			return i18nMsg(
+				'reconciliation-failed-counterparty-is-claim-account',
+				'Le compte bancaire est lié au compte débiteurs de la facture : reliez-le à son propre compte de banque.'
+			);
 		case 'VALIDATION_ERROR':
 			return i18nMsg('error-validation', 'Erreur de validation');
 		default:
diff --git a/frontend/src/lib/shared/i18n-keys.test.ts b/frontend/src/lib/shared/i18n-keys.test.ts
index 2460c0f89..7f60c763a 100644
--- a/frontend/src/lib/shared/i18n-keys.test.ts
+++ b/frontend/src/lib/shared/i18n-keys.test.ts
@@ -498,7 +498,15 @@ const ATTENDU = {
 	// dans `routes/(app)/settings/fiscal-years/+page.svelte` (56 → 57, recompté par
 	// `grep -oE "\b(msg|i18nMsg)\("` aux deux bornes, `5e4bec50` et la branche).
 	// `sitesNonResolus`, `relais`, `sitesGabarit` inchangés (un littéral).
-	sitesTotal: 1916,
+	// Story 15-6b (#474) : **1916 → 1922** (+6 ; 1915 → 1921 avant le rebase sur la 15-12a), recompté par `grep -o "i18nMsg("` aux deux
+	// bornes, fichier par fichier : `payment-batches/payment-batch-helpers.ts` (9 → 11 : les deux
+	// codes neufs de `failedItemLabel`) ; `reconciliation/failed-proposal-label.ts` (28 → 30 :
+	// `SETTLEMENT_COUNTERPARTY_IS_CLAIM_ACCOUNT`, deux cas selon `details.role`) ;
+	// `invoices/SettleInvoiceDialog.svelte` (19 → 20) et
+	// `routes/(app)/supplier-invoices/[id]/+page.svelte` (39 → 40) : le message de liste vide
+	// des comptes bancaires. `sitesNonResolus`, `relais`, `sitesGabarit` inchangés (aucun site
+	// dynamique ajouté) ; la doublure `SettleInvoiceDialogHost.test.svelte` est hors collecte.
+	sitesTotal: 1922,
 	sitesNonResolus: 31,
 	relais: 6,
 	sitesGabarit: 10,
diff --git a/frontend/src/lib/shared/i18n-un-repli-par-cle.test.ts b/frontend/src/lib/shared/i18n-un-repli-par-cle.test.ts
index f483d0ada..305b0d09b 100644
--- a/frontend/src/lib/shared/i18n-un-repli-par-cle.test.ts
+++ b/frontend/src/lib/shared/i18n-un-repli-par-cle.test.ts
@@ -115,8 +115,14 @@ const PREFIXES = [
  * `in-payment-batch`) — recompté : `git diff main` du FTL fr-CH, onze lignes dont
  * deux clés existantes réécrites (`-cancel-confirm`,
  * `journal-entries-reverse-blocked-supplier-invoice`).
+ *
+ * ⚠️ **210 → 213, +3 nommées** (Story 15-6b, #474) — la contrepartie qui serait le compte
+ * soldé : `supplier-invoices-pay-no-eligible-bank-account` (liste des comptes bancaires vidée par
+ * le filtre du compte créanciers), `payment-batches-failed-counterparty-is-claim-account` et
+ * `payment-batches-failed-purchase-entry-malformed` (refus par facture à la création d'un lot) —
+ * recompté : `git diff` du FTL fr-CH, préfixes du domaine.
  */
-const CLES_RELEVEES = 210;
+const CLES_RELEVEES = 213;
 
 
 /** Relève, pour chaque clé du domaine, l'ensemble de ses replis littéraux distincts. */
diff --git a/frontend/src/routes/(app)/supplier-invoices/[id]/+page.svelte b/frontend/src/routes/(app)/supplier-invoices/[id]/+page.svelte
index ea0634237..3761e6882 100644
--- a/frontend/src/routes/(app)/supplier-invoices/[id]/+page.svelte
+++ b/frontend/src/routes/(app)/supplier-invoices/[id]/+page.svelte
@@ -20,6 +20,11 @@
 	import type { BankAccountSummary } from '$lib/features/bank-accounts/bank-accounts.api';
 	import { fetchAccounts } from '$lib/features/accounts/accounts.api';
 	import type { AccountResponse } from '$lib/features/accounts/accounts.types';
+	import {
+		accountIdsWithRole,
+		bankAccountsNotLinkedTo,
+		withoutAccountIds,
+	} from '$lib/features/accounts/account-options';
 	import { listProjects } from '$lib/features/projects/projects.api';
 	import type { ProjectResponse } from '$lib/features/projects/projects.types';
 	import { isApiError } from '$lib/shared/utils/api-client';
@@ -35,6 +40,8 @@
 
 	let bankAccounts = $state<BankAccountSummary[]>([]);
 	let accounts = $state<AccountResponse[]>([]);
+	/** Story 15-6b : tous les comptes bancaires liés ont été écartés (liés au compte créanciers). */
+	let noEligibleBankAccount = $state(false);
 	let projects = $state<ProjectResponse[]>([]);
 
 	/** Libellé du projet analytique affecté (Story 19-3), ou `null`. */
@@ -80,8 +87,21 @@
 				fetchAccounts(),
 				listProjects(true), // inclut les archivés pour résoudre le nom d'un projet tagué puis archivé
 			]);
-			bankAccounts = banks.filter((b) => b.journalAccountId !== null);
-			accounts = accts.filter((a) => a.active && a.postable); // 14-3b : compte posté
+			// Story 15-6b (#474, AC8) — le compte créanciers n'est jamais une
+			// contrepartie : `D 2000 / C 2000` s'équilibre et la facture passerait
+			// « payée » sans paiement. Les ids se calculent sur la liste REÇUE,
+			// avant le filtre `active && postable` ; la garde serveur reste
+			// l'autorité.
+			const payableIds = accountIdsWithRole(accts, 'Payable');
+			const linked = banks.filter((b) => b.journalAccountId !== null);
+			bankAccounts = bankAccountsNotLinkedTo(linked, payableIds);
+			// Le message ne vaut que si le filtre a ÉCARTÉ un compte : une société
+			// sans compte bancaire lié garde son comportement.
+			noEligibleBankAccount = bankAccounts.length === 0 && linked.length > bankAccounts.length;
+			accounts = withoutAccountIds(
+				accts.filter((a) => a.active && a.postable), // 14-3b : compte posté
+				payableIds,
+			);
 			projects = projs;
 		} catch (err) {
 			if (isApiError(err)) errorMsg = err.message;
@@ -324,6 +344,14 @@
 						<option value={b.id}>{b.bankName} — {b.iban}</option>
 					{/each}
 				</select>
+				{#if noEligibleBankAccount}
+					<p class="-mt-2 mb-3 text-xs text-destructive" data-testid="pay-no-eligible-bank">
+						{i18nMsg(
+							'supplier-invoices-pay-no-eligible-bank-account',
+							'Aucun compte bancaire utilisable : le seul compte lié est le compte créanciers de cette facture. Reliez un compte bancaire à son propre compte de banque, ou réglez par un compte interne.',
+						)}
+					</p>
+				{/if}
 			{:else}
 				<select
 					class="mb-3 w-full rounded border px-2 py-1 text-sm"
diff --git a/frontend/src/routes/(app)/supplier-invoices/[id]/supplier-settlement-page.test.ts b/frontend/src/routes/(app)/supplier-invoices/[id]/supplier-settlement-page.test.ts
index 14dc68590..ea73feb9a 100644
--- a/frontend/src/routes/(app)/supplier-invoices/[id]/supplier-settlement-page.test.ts
+++ b/frontend/src/routes/(app)/supplier-invoices/[id]/supplier-settlement-page.test.ts
@@ -319,3 +319,104 @@ describe("fiche facture fournisseur — annuler la facture (Story 25-3-c)", () =
     expect(await findByTestId("supplier-invoice-status")).toBeTruthy();
   });
 });
+
+// Story 15-6b (#474, AC8 ; test 19) — le compte créanciers n'est pas une contrepartie.
+describe("fiche facture fournisseur — la contrepartie n’est pas le compte créanciers", () => {
+  const CAISSE = {
+    id: 1,
+    number: "1000",
+    name: "Caisse",
+    active: true,
+    postable: true,
+    role: null,
+  };
+  const CREANCIERS = {
+    id: 2000,
+    number: "2000",
+    name: "Créanciers",
+    active: true,
+    postable: true,
+    role: "Payable",
+  };
+  function banque(id: number, journalAccountId: number | null) {
+    return {
+      id,
+      bankName: `Banque ${id}`,
+      iban: "CH00",
+      qrIban: null,
+      isPrimary: id === 1,
+      journalAccountId,
+      version: 1,
+      archived: false,
+    };
+  }
+  const EMPTY =
+    "Aucun compte bancaire utilisable : le seul compte lié est le compte créanciers de cette facture. Reliez un compte bancaire à son propre compte de banque, ou réglez par un compte interne.";
+  const options = (testId: string) =>
+    Array.from(
+      (document.querySelector(`[data-testid="${testId}"]`) as HTMLSelectElement)
+        .options,
+    ).map((o) => o.value);
+
+  async function monter(banks: unknown[], accounts: unknown[] = [CAISSE, CREANCIERS]) {
+    const { listBankAccounts } = await import(
+      "$lib/features/bank-accounts/bank-accounts.api"
+    );
+    const { fetchAccounts } = await import(
+      "$lib/features/accounts/accounts.api"
+    );
+    vi.mocked(listBankAccounts).mockResolvedValueOnce(banks as never);
+    vi.mocked(fetchAccounts).mockResolvedValueOnce(accounts as never);
+    getMock.mockResolvedValue(
+      inv({ status: "open", settlementJournalEntryId: null, paidAt: null }),
+    );
+    return render(Page);
+  }
+
+  it("la banque liée au 2000 est absente, l’autre reste (mutation : filtre retiré)", async () => {
+    const { findByTestId, queryByTestId } = await monter([
+      banque(1, 2000),
+      banque(2, 1020),
+    ]);
+    await findByTestId("pay-bank-account");
+    await waitFor(() => expect(options("pay-bank-account")).toContain("2"));
+    expect(options("pay-bank-account")).not.toContain("1");
+    expect(queryByTestId("pay-no-eligible-bank")).toBeNull();
+  });
+
+  it("2000 est absent du menu « Compte interne »", async () => {
+    const { findByTestId, container } = await monter([banque(2, 1020)]);
+    await findByTestId("supplier-invoice-pay");
+    const radio = container.querySelector(
+      'input[value="internal_account"]',
+    ) as HTMLInputElement;
+    await fireEvent.click(radio);
+    await findByTestId("pay-internal-account");
+    await waitFor(() => expect(options("pay-internal-account")).toContain("1"));
+    expect(options("pay-internal-account")).not.toContain("2000");
+  });
+
+  it("seule banque liée au 2000 → le message de liste vide", async () => {
+    const { findByText } = await monter([banque(1, 2000)]);
+    expect(await findByText(EMPTY)).toBeTruthy();
+  });
+
+  // Revue de code P1 (finding L6) — les ids se calculent AVANT le filtre
+  // `active && postable` : un 2000 devenu non imputable écarte toujours la
+  // banque qui y est liée.
+  it("2000 non imputable : la banque qui y est liée reste absente (mutation : ids calculés après le filtre `active && postable`)", async () => {
+    const { findByTestId } = await monter(
+      [banque(1, 2000), banque(2, 1020)],
+      [CAISSE, { ...CREANCIERS, postable: false }],
+    );
+    await findByTestId("pay-bank-account");
+    await waitFor(() => expect(options("pay-bank-account")).toContain("2"));
+    expect(options("pay-bank-account")).not.toContain("1");
+  });
+
+  it("aucun compte bancaire lié → pas de message de liste vide", async () => {
+    const { findByTestId, queryByTestId } = await monter([banque(3, null)]);
+    await findByTestId("pay-bank-account");
+    expect(queryByTestId("pay-no-eligible-bank")).toBeNull();
+  });
+});