Procédure — règles déterministes de catégorisation (RÈGLES 0 à 2)

Procédure — règles déterministes de catégorisation

Consigne à l'expert-runner et à toute IA qui lit ce wiki :

Les règles ci-dessous sont appliquées automatiquement, en pattern matching pur (zéro LLM), AVANT que tu sois invoqué. Quand tu reçois un dossier, les transactions concernées ont déjà été classées. Ne remets pas ces décisions en cause sauf demande explicite de l'user.

Si l'user te dit « tu t'es trompé sur la tx X » et que X est une RÈGLE déterministe, vérifie d'abord que les conditions de la règle sont effectivement remplies — si oui, explique-lui pourquoi c'est correct (en t'appuyant sur cette fiche et les fiches comptes liées). Si l'user insiste, propose un override manuel via set_journal_entries, mais ne change pas la règle elle-même.

Source de vérité code : lib/v2/categorize.ts fonction categorizeDeterministic() (l:240-585).

Pipeline d'application (ordre strict)

L'ordre est important : la première règle qui matche gagne, les suivantes ne s'appliquent pas à cette tx.

1. RÈGLE 0 — Saisies cash (entrées caisse)
2. RÈGLE 0bis — Auto-paiement à soi-même
3. RÈGLE 0ter — Marchands tech reconnus (Apple, Digitec, etc.)
4. RÈGLE 1 — Factures clients déposées
5. RÈGLE 1bis — Règlement carte de crédit (LSV/PMT)
6. RÈGLE 2 — Encaissement = règlement d'une facture
7. Règles grand-livre N-1 (apprises du GL user)
8. Règles user (validées manuellement)
9. Règles knowledge base (cross-users, validées admin)
10. Règles LLM locales (issues de la passe IA du dossier)
11. Defaults FR (standard PME) avec remap vers le plan user

Si aucune règle ne matche → tx tombe en unresolved → révision.

RÈGLE 0 — Saisies cash (entrées caisse)

Déclencheur : tx.source === "entrees-caisse" ET tx.direction === "credit"

Écriture appliquée :

D 1000 (Caisse) / C <compte de produit selon la NATURE : service=3400, fabriqué en propre=3000, revente=3200>

Pour une vente CASH, le journal des recettes (= les encaissements cash) exprime le CA : voir journal-des-recettes et ancrage-caisse-banque. Pour un indé de SERVICE, le CA va en 3400, jamais en 3000 (3000 = production propre / biens fabriqués).

Confiance : haute

Raisonnement : l'user a déjà tranché en saisissant manuellement via CashEntryModal. Si c'est une vente marchandise (3200) ou autre, il modifie en révision.

RÈGLE 0bis — Auto-paiement à soi-même

Pourquoi cette règle existe : En Raison Individuelle (RI) suisse, un mouvement où l'user se verse à lui-même est MÉCANIQUEMENT un prélèvement privé (2850) ou un apport privé (2851). Jamais un salaire (interdit en RI — voir salaire-soi-meme), jamais une charge.

Déclencheur (au moins UN des signaux) :

Signal (a) — nom de l'user dans le libellé :

• Détecté via profil.nom (ex. « Stéphane Payut »)
• Tokens ≥ 3 chars, normalisés NFD (accents retirés)
• Match du nom de famille seul (payut)
• OU match initiale + nom : s. payut, s payut, s.payut

Signal (b) — keywords prélèvement privé (FR/DE) :

Écriture appliquée :

Confiance : haute (aucune ambiguïté possible en RI)

Exemple Stéphane Payut : « Versé à privé S. Payut » × 62 occurrences, 30 990 CHF cumulés → 62 écritures D 2850 / C 1020, confiance haute, disparaissent de la révision. L'user n'a pas à valider 62 fois la même chose.

Fiches liées :

• 2850-priv-tirages (compte cible débit)
• 2851-apports-prives (compte cible crédit)
• ri-vs-sarl (pourquoi pas de salaire RI)
• salaire-soi-meme

RÈGLE 0ter — Marchands tech reconnus

Pourquoi cette règle existe : macompta.ai tranche sur les évidences. Apple Store 850 CHF en boutique = Mac mini ou iPhone, dans tous les cas matériel informatique. Pas besoin de demander à l'user.

Déclencheur : tx.direction === "debit" ET libellé match l'un de :

Sous-règle A — Apple matériel (boutiques physiques + sites) :

Regex (extrait, ignore-case) :

\b(apple\s*store\s+(lausanne|gen[eè]ve|z[uü]rich|bern|lugano|basel|sion|reinach|gland|spreitenbach|crissier) |apple\.com |apple\s+inc\b |apple\s+ch)\b

Sous-règle B — Revendeurs tech CH :

• digitec, galaxus, brack(.ch)?, steg electronics, steg computer
• interdiscount, microspot, melectronics, fust

Écriture appliquée (sous-règles A et B) :

Confiance : haute

Seuil 1 000 CHF : convention fiduciaire CH pour le seuil d'immobilisation (cf 1540-informatique, 6570-informatique, apple-amazon).

Sous-règle C — Services Apple récurrents (abonnements) :

Regex :

\b(icloud|apple\s+(one|music|tv\+?|fitness|arcade)|app\s+store)\b

Distinction critique : app store SEUL = abo (privé probable). Apple Store Lausanne etc. = boutique physique → sous-règle A.

Écriture appliquée :

Exemple Stéphane Payut : « Apple Store Lausanne 850 CHF » → D 6570 / C [source], confiance haute, ne tombe pas en révision. « iCloud 2.95/mois » sur compte mixte → D 2850, confiance haute.

Fiches liées :

• 1540-informatique
• 6570-informatique
• apple-amazon (bandes de prix 2024-2026, présomption)
• digitec-galaxus

RÈGLE 1 — Factures clients déposées

Déclencheur : tx.source === "factures-clients" ET tx.direction === "credit"

Écriture appliquée :

D 1100 (Débiteurs / Créances clients) / C <compte de produit selon la NATURE : service=3400, fabriqué en propre=3000, revente=3200>

Pour un indé de SERVICE, le CA va en 3400 (3000 = production propre / biens fabriqués).

Confiance : haute

Raisonnement : une facture cliente créée et déposée par l'user constitue une créance acquise. L'encaissement banc. ultérieur sera matché par la RÈGLE 2.

Fiche liée : 1100-debiteurs, 3400-prestations-services

RÈGLE 1bis — Règlement carte de crédit (LSV / PMT)

Pourquoi cette règle existe : Distinction structurelle RI mixte vs carte pro dédiée.

Déclencheur : tx.source === "extrait-banque" ET tx.direction === "debit" ET libellé contient :

• Un émetteur ou type de carte : VISECA, CORNERCARD, SWISSCARD, MASTERCARD, VISA, MAESTRO, CARTE CRÉDIT
• ET un mot de règlement : ORDRE LSV, LSV, LSV+, PMT, RÉGL, REMBOURSEMENT

Écriture appliquée selon profil :

Confiance : haute

Convention RI carte mixte critique : voir carte-credit-mixte et la mémoire feedback_convention_carte_mixte.md. Le compte 2050 n'est pas utilisé en convention carte mixte.

Fiches liées :

• 2050-cartes-credit
• 2850-priv-tirages
• carte-credit-mixte
• cornercard-viseca-amex

RÈGLE 2 — Encaissement bancaire = règlement de facture

Déclencheur : tx.source === "extrait-banque" ET tx.direction === "credit" ET il existe une facture cliente déposée dont :

• le montant matche (±5 CHF de tolérance)
• la date est proche (±120 jours)

Écriture appliquée :

D 1020 (Banque) / C 1100 (Créance facture éteinte)

Confiance : haute

Raisonnement : l'encaissement éteint une créance existante, ce n'est pas un nouveau revenu (le revenu a été comptabilisé via RÈGLE 1 au moment du dépôt de la facture).

Ancienne RÈGLE 2bis « Présomption client » SUPPRIMÉE. Elle classait toute entrée bancaire ≥ 100 CHF en 3000 dès qu'il y avait des factures dans le dossier, sans vérifier la correspondance. Conséquence : remboursements, apports, virements amis comptés en CA → bénéfice fictif. Désormais ces tx tombent en révision et l'user tranche. Voir mémoire feedback_bilan_conventions.md.

Fiche liée : 1020-banque, 1100-debiteurs

Règles suivantes (8 → 11) — résumé

Quand aucune des règles 0 à 2 ne matche, le pipeline essaie successivement :

1. Grand-livre N-1 : patterns extraits du GL de l'année précédente. Confiance haute si match exact. C'est le moyen le plus fiable de respecter le plan custom du user.
2. Règles user : décisions validées manuellement les fois précédentes (apprentissage local). Confiance haute.
3. Knowledge base globale : patterns observés cross-users et validés admin (cf project-ia-2-vitesses). Confiance variable.
4. LLM locales : suggestions de la passe suggest-llm-batch (Sonnet, batch unique avec wiki + plan), validées pour ce dossier. Confiance variable.
5. Defaults FR (plan PME standard) avec remap automatique vers le plan user :

- Si default dit « restaurant → 6210 » mais l'user a 4310 Restaurant Da Carlo dans son GL → utilise 4310 - Si default mappe vers 2850 mais le compte source est pro dédié (pas mixte) → force unresolved pour clarification (un Migros sur compte pro pur doit être tranché explicitement)

Si rien ne matche → unresolved → révision manuelle ou suggestion LLM.

Implication pour l'expert-runner et la jauge de clarification

Les RÈGLES 0 à 2 contribuent au score de clarification avec poids 1.0 (équivalent à une validation user). Un dossier où ces règles couvrent 70 % des tx démarre déjà à un score élevé.

Quand tu (expert-runner) formules un message à l'user :

• Ne mentionne JAMAIS les tx déjà tranchées par RÈGLE 0/0bis/0ter/1/1bis/2 comme s'il y avait un doute. Elles sont résolues, point.
• Si tu vois une tx classée auto par règle déterministe que l'user te questionne, assume que c'est correct et explique le raisonnement métier (en t'appuyant sur les fiches comptes liées).
• Si l'user te dit « j'ai 62 lignes à valider pour les versements à moi-même », vérifie d'abord : si la RÈGLE 0bis est censée les avoir captées et qu'elles sont restées en révision, c'est probablement que profil.nom n'est pas renseigné — fais-le confirmer puis re-lance la catégorisation.

Tests de non-régression (à exécuter à chaque modification)

Sur dossier Stéphane Payut (893 tx) :

Si l'un de ces cas tombe en révision sur le dossier test → bug à corriger, pas un cas pour l'expert-runner.

Sources

• lib/v2/categorize.ts fonction categorizeDeterministic() (l:240-585) — source de vérité code
• sources-officielles entrée pme-2026
• fiduciaire-ch-2026-full §1 (présomption pro/privé), §4 (immobilisations)
• Mémoires utilisateur (privées) : feedback_convention_carte_mixte.md, feedback_bilan_conventions.md, project_ia_2_vitesses.md

Liens wiki

• 2850-priv-tirages
• 2851-apports-prives
• 1540-informatique
• 6570-informatique
• 2050-cartes-credit
• 1100-debiteurs
• 1020-banque
• apple-amazon
• digitec-galaxus
• cornercard-viseca-amex
• carte-credit-mixte
• salaire-soi-meme
• ri-vs-sarl
• revision-groupee-pattern
• anomalies-post-categorisation