{"id":"39a9e4d5-3a74-4006-9fef-9d9c30ded737","entityType":"agent","slug":"clawhub-trendex-organisation-documents","name":"Organisation Documents","canonicalUrl":"https://www.xpersona.co/agent/clawhub-trendex-organisation-documents","canonicalPath":"/agent/clawhub-trendex-organisation-documents","generatedAt":"2026-10-10T07:39:28.947Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-10T02:27:21.438Z","emptyReason":null},"description":"Skill central de l'assistant comptable. Réceptionne, classe et nomme automatiquement les documents comptables (factures, relevés bancaires) par client / anné... Skill: Organisation Documents Owner: trendex Summary: Skill central de l'assistant comptable. Réceptionne, classe et nomme automatiquement les documents comptables (factures, relevés bancaires) par client / anné... Tags: latest:0.2.0 Version history: v0.2.0 | 2026-05-13T12:07:50.633Z | user Migration vers pipeline déterministe script-driven : scripts/main.py + extract.py, onboarding 2-étapes pour expéditeurs ambigus,","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.8K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s171rnymrzgb46f7qxnxd5034586ma2f:organisation-documents","sourceUrl":"https://clawhub.ai/trendex/organisation-documents","homepage":"https://clawhub.ai/trendex/skills/organisation-documents","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/trendex/organisation-documents","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/trendex/skills/organisation-documents","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":65,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Skill central de l'assistant comptable. Réceptionne, classe et nomme automatiquement les documents comptables (factures, relevés bancaires) par client / anné..."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T02:27:21.438Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T02:27:21.438Z","emptyReason":null},"stars":null,"forks":null,"downloads":1773,"packageName":null,"latestVersion":"0.2.0","tractionLabel":"1.8K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T02:27:21.438Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T02:27:21.438Z","lastCrawledAt":"2026-10-10T02:27:21.438Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T02:27:21.438Z","lastVerifiedAt":null,"highlights":[{"version":"0.2.0","createdAt":"2026-05-13T12:07:50.633Z","changelog":"Migration vers pipeline déterministe script-driven : scripts/main.py + extract.py, onboarding 2-étapes pour expéditeurs ambigus, dédup SHA-256, bootstrap clients.json depuis relevés bancaires","fileCount":15,"zipByteSize":41853},{"version":"0.1.0","createdAt":"2026-05-12T13:08:26.796Z","changelog":"Initial release: core document classification skill for French accounting firms.","fileCount":7,"zipByteSize":21220}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s171rnymrzgb46f7qxnxd5034586ma2f:organisation-documents","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-trendex-organisation-documents/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-trendex-organisation-documents/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-trendex-organisation-documents/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-trendex-organisation-documents/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-trendex-organisation-documents/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-trendex-organisation-documents/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T07:39:28.944Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-trendex-organisation-documents/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-trendex-organisation-documents/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-trendex-organisation-documents/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-trendex-organisation-documents/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-10T02:27:21.438Z","emptyReason":null},"readme":"Skill: Organisation Documents\n\nOwner: trendex\n\nSummary: Skill central de l'assistant comptable. Réceptionne, classe et nomme automatiquement les documents comptables (factures, relevés bancaires) par client / anné...\n\nTags: latest:0.2.0\n\nVersion history:\n\nv0.2.0 | 2026-05-13T12:07:50.633Z | user\n\nMigration vers pipeline déterministe script-driven : scripts/main.py + extract.py, onboarding 2-étapes pour expéditeurs ambigus, dédup SHA-256, bootstrap clients.json depuis relevés bancaires\n\nv0.1.0 | 2026-05-12T13:08:26.796Z | user\n\nInitial release: core document classification skill for French accounting firms.\n\nArchive index:\n\nArchive v0.2.0: 15 files, 41853 bytes\n\nFiles: data/company.example.json (2453b), data/facturation/mentions-obligatoires.json (7463b), README.md (5640b), references/contrat-io.md (5249b), references/reforme-facturation-2026.md (5771b), references/roadmap.md (3785b), references/structure-cible.md (14917b), references/validation-fr.md (7515b), scripts/extract.py (12883b), scripts/fetch_company.py (6349b), scripts/main.py (12926b), scripts/validate-facture.js (12432b), skill-card.md (2656b), SKILL.md (12521b), _meta.json (141b)\n\nFile v0.2.0:SKILL.md\n\n---\nname: organisation-documents\ndescription: Skill central de l'assistant comptable. Réceptionne, classe et nomme automatiquement les documents comptables (factures, relevés bancaires) par client / année / mois / nature, et déduit clients.json depuis les relevés bancaires. À INVOQUER SYSTÉMATIQUEMENT et SANS DEMANDER L'AUTORISATION dès que (a) un e-mail arrive avec une PJ PDF/image, (b) un e-mail contient un mot-clé comptable (facture, invoice, reçu, paiement, TVA, total, acompte, avoir, relevé), (c) le comptable demande de traiter / classer / organiser un document, (d) un fichier est déposé dans l'inbox, (e) le comptable répond à une question d'identification de client. L'extraction et le classement sont faits par scripts/main.py + scripts/extract.py — aucun champ n'est jamais deviné à l'œil.\nlicense: Interne — usage privé OpenClaw\n---\n\n# Skill `organisation-documents`\n\n> Moteur d'entrée du domaine comptable. Réception → identification du client → classement → indexation → rapport.\n> **Le travail réel est fait par `scripts/main.py`** (qui appelle `scripts/extract.py`). Ce skill = quand le lancer + comment dialoguer avec le comptable.\n\n---\n\n## ⚠️ Règle absolue — EXÉCUTION DU SCRIPT (non négociable)\n\n**Pour chaque invocation, la SEULE action de classement correcte est d'exécuter la commande :**\n\n```bash\npython3 scripts/main.py \n```\n\npuis de lire `/_report.json` et de le relayer au comptable.\n\n### ❌ INTERDIT\n\n- **Lire les PDFs un par un et classer à la main.** L'agent extrait les champs à l'œil de façon inconsistante (cas réels déjà observés : `invoice_id` = `\"N\"`, `\"des\"`, `\"um-rix\"` au lieu de `F1-2026-0001` ; `total_ttc` = `0.00` au lieu du vrai montant). Ces erreurs cassent ensuite tout le rapprochement de `rapprochement-bancaire`.\n- **Dupliquer la logique du script en Python ad-hoc** dans une cellule / un sous-process inline. Le script EST la logique, il est déterministe, déjà testé. Le réimplémenter à chaque invocation est garanti de diverger.\n- **Créer ou déplacer des fichiers dans `/` à la main** (move, copy, write). C'est le script qui le fait.\n- **Inventer un `invoice_id`** quand le PDF n'en contient pas de lisible. Si `extract.py` ne le trouve pas, le script écrit `SANS-NUM` ; n'essaie PAS de fabriquer mieux à partir du nom de l'émetteur ou de la description.\n\n### ✅ OBLIGATOIRE\n\n1. Exécuter la commande shell ci-dessus (et UNIQUEMENT ça pour la partie classement).\n2. Lire le `_report.json` produit.\n3. Relayer au comptable un résumé court + les questions d'onboarding si la section `questions` n'est pas vide.\n\n### Si le script échoue\n\nSignale l'erreur exacte (stderr) au comptable. **NE PAS** \"rattraper\" en classant manuellement — c'est précisément ce qui produit les filenames cassés. Si le binaire `pdftotext` manque (`poppler-utils` non installé), demande-le et stoppe.\n\n> Pourquoi cette règle est aussi stricte : on a déjà eu plusieurs runs où l'agent a improvisé le classement et produit des `invoice_id` bidons (`N`, `des`, `um-rix`). À chaque fois, `rapprochement-bancaire` flagge ensuite des `facture_manquante` qui n'en sont pas, le comptable perd du temps à investiguer. Le script ne fait pas ces erreurs.\n\n---\n\n## Quand utiliser ce skill\n\nRéflexe par défaut face à tout document entrant :\n\n1. E-mail avec PJ → traitement immédiat.\n2. Dépôt manuel dans l'inbox → idem.\n3. Import en masse (ZIP, dossier) → idem.\n4. Réponse du comptable à une question d'identification → reprise (étape 2 de l'onboarding).\n5. Reclassement / correction → relancer le script.\n\nNe **pas** utiliser pour : FEC (→ `fec-parser`), relances (→ `relances`), rapprochement bancaire (→ `rapprochement-bancaire`).\n\n---\n\n## Exécution\n\n```bash\npython3 scripts/main.py []\n# racine_clients par défaut : ~/.openclaw/workspace/clients\n```\n\nLe script :\n\n1. **Dédoublonne** par SHA-256 (ignore les fichiers déjà classés via `_index.json`).\n2. **Extrait** chaque PDF avec `scripts/extract.py` (`pdftotext -layout` + règles déterministes). Aucun montant, numéro ou nom n'est inventé.\n3. **Phase 1 — relevés bancaires d'abord** : le titulaire affiché en en-tête du relevé EST le client du cabinet (identité certaine) → crée/complète l'entrée `clients.json` (`statut: auto-from-bank-statement`), classe le relevé dans `///bank-statements/`.\n4. **Phase 2 — factures** : pour chaque facture, compare émetteur et destinataire à `clients.json` (exact puis fuzzy ≥ 0.82).\n - un seul côté matche → c'est le client ; émetteur ≈ client → `invoices/out/`, destinataire ≈ client → `invoices/in/`.\n - aucun côté ne matche → `_a-identifier/` + une **question** dans le rapport (cf. onboarding ci-dessous).\n - les deux matchent → `_a-identifier/` + question (cas rare).\n - extraction incomplète (date ou montant TTC introuvable) → `_incomplet/` + ligne dans le rapport.\n5. **Phase 3 — autres** : ni facture ni relevé reconnaissable → `_non-attribue/`.\n6. Écrit `clients/clients.json`, `clients/_index.json`, `clients/_report.json`, et imprime un résumé.\n\n**Après l'exécution**, lire `clients/_report.json` et :\n\n- relayer au comptable un résumé court (nb de factures classées, nb de relevés, clients créés) ;\n- si `_report.json → questions` n'est pas vide → poser ces questions au comptable (cf. format) ;\n- si `_report.json → incomplete` n'est pas vide → signaler ces pièces ;\n- pour chaque facture classée (hors `_a-identifier`/`_incomplet`), considérer le post-traitement `rapprochement-bancaire` déclenché (le batch repassera de toute façon).\n\n---\n\n## Identification du client — règle absolue\n\nTrois signaux **fiables**, dans l'ordre (gérés par le script) :\n\n1. **Relevé bancaire** : titulaire du compte → certitude.\n2. **Mapping confirmé** : e-mail expéditeur ∈ `contacts[].email`, domaine ∈ `domains`, ou SIREN du document ∈ `siren` d'un client.\n3. **Raison sociale fuzzy** ≥ 0.82 contre `clients.json` — seulement si **un seul** des deux côtés matche.\n\nSi aucun signal fiable → **on ne devine pas**. Le document part en `_a-identifier/` et le comptable tranche une fois.\n\n### Onboarding d'un expéditeur ambigu (le cas « Corse Plomberie »)\n\nUne facture contient toujours deux entreprises (émetteur, destinataire). Quand aucune n'est connue — et qu'aucun relevé ne couvre l'une d'elles — le script ne choisit pas : il met la pièce dans `_a-identifier/` et ajoute une question.\n\n**Étape 1 (automatique)** — la question apparaît dans `_report.json → questions` :\n\n> « Document : facture `TUYO-2024-087` (348,50 € TTC). Émetteur « TUYO SARL », destinataire « Corse Plomberie ». Lequel est votre client ? »\n\nL'agent la relaie au comptable. **Aucune écriture dans `clients.json`** à ce stade.\n\n**Étape 2 (à la réponse du comptable)** — quand le comptable répond « c'est **X** » :\n\n1. Ajouter/compléter l'entrée `clients.json` de X :\n ```json\n { \"slug\": \"\", \"raisonSociale\": \"X\", \"statut\": \"confirmed\",\n \"confiance\": 1.0, \"aValider\": false,\n \"siren\": [\"\"], \"contacts\": [{\"email\": \"\"}],\n \"domains\": [\"\"], \"sources\": [\"accountant-confirmation\"] }\n ```\n2. Relancer `python3 scripts/main.py clients/_a-identifier ` : avec X désormais dans `clients.json`, les pièces de `_a-identifier/` liées sont classées (sens in/out déterminé) et sortent du dossier.\n3. Relayer le résultat.\n\nÀ partir de là, tout document futur du même expéditeur (même e-mail) est attribué automatiquement.\n\n### Si le comptable répond « aucune des deux »\n\nDéplacer la pièce de `_a-identifier/` vers `_non-attribue/`. Pas de suivi comptable.\n\n---\n\n## `clients.json` — structure\n\n```json\n[\n {\n \"slug\": \"corse-plomberie\",\n \"raisonSociale\": \"Corse Plomberie\",\n \"statut\": \"auto-from-bank-statement | confirmed\",\n \"confiance\": 0.9,\n \"aValider\": false,\n \"siren\": [\"812345678\"],\n \"contacts\": [{ \"email\": \"jeanmichel@gmail.com\" }],\n \"domains\": [\"corseplomberie.fr\"],\n \"sources\": [\"bank-statement\"]\n }\n]\n```\n\nFichier **construit et maintenu par ce skill seul** (via `scripts/main.py` + ajouts manuels lors de l'onboarding). Aucun autre skill ne l'écrit. Le comptable ne l'édite pas à la main : il répond aux questions.\n\n---\n\n## Arborescence cible\n\n```\nclients/\n├── clients.json ← liste des clients (déduite des relevés + confirmations)\n├── _index.json ← sha256 → chemin classé (dédup)\n├── _report.json ← rapport de la dernière exécution\n├── _a-identifier/ ← factures dont le client n'est pas confirmé (onboarding en cours)\n├── _incomplet/ ← pièces dont l'extraction a échoué (date / montant manquant)\n├── _non-attribue/ ← ni facture ni relevé exploitable\n├── _cabinet/ ← documents internes du cabinet\n└── /\n └── //\n ├── bank-statements/\n │ └── _.pdf\n └── invoices/\n ├── in/\n │ └── ___.pdf\n └── out/\n └── ___.pdf\n```\n\nConvention de nom (produite par le script, jamais à la main) :\n- `N°Facture` : numéro réel extrait du PDF (ex `F1-2026-0003`), alphanumérique+tirets ; `SANS-NUM` si absent.\n- `Contrepartie` : 14 premiers caractères significatifs du nom de l'autre partie, sans accents/espaces.\n- `MontantTTC` : point décimal, sans séparateur de milliers, sans symbole (ex `3336.78`).\n- `AAAA-MM-JJ` : date d'émission du document.\n\n---\n\n## Détection facture vs relevé (rappel — implémenté dans `extract.py`)\n\n- **Relevé bancaire** si : `RELEVÉ DE COMPTE`/`EXTRAIT DE COMPTE`/`ACCOUNT STATEMENT`, ou nom de banque + `RELEVÉ`, ou `Solde d'ouverture`/`Solde de clôture`. **Exception** : si le document contient aussi (`FACTURE`/`INVOICE`) ET (`SIRET`/`TVA`) → c'est une facture.\n- **Facture** si ≥ 2 signaux parmi : `FACTURE`/`INVOICE`/`BON DE FACTURATION` · bloc `SIRET`/`TVA`/`SIREN` · bloc destinataire (`FACTURÉ À`/`DESTINATAIRE`/`BILL TO`) · `TOTAL HT`/`TOTAL TTC`/`NET À PAYER`.\n- Sinon → `_non-attribue/`.\n\n---\n\n## Communication avec le comptable\n\n- **Silence par défaut** : une ligne au début, une ligne à la fin. Pas de narration par étape.\n- **Questions d'onboarding** : regroupées en fin de message, une par expéditeur ambigu, format « Document … — Émetteur « … », destinataire « … » — lequel est votre client ? ».\n- **Vocabulaire interdit** : `pdftotext`, `regex`, `SHA-256`, `pipeline`, `extract.py`, chemins absolus système.\n- **Vocabulaire métier** : facture, pièce, dossier client, mois en cours, classement, doublon, mention obligatoire, contrepartie.\n\n---\n\n## Garde-fous\n\n- Aucune donnée ne quitte le container LXD.\n- Conservation 10 ans minimum. Jamais de suppression — `_a-identifier/`, `_incomplet/`, `_non-attribue/` conservent les pièces.\n- Sources externes en lecture seule.\n- Le système ne **devine jamais** un montant, un numéro ou l'identité d'un client : signal fiable, sinon question. `_incomplet/` plutôt qu'une valeur inventée.\n\n---\n\n## Post-traitement\n\nPour chaque facture / relevé classé dans un vrai dossier client (pas `_a-identifier/` ni `_incomplet/`), le moteur d'état `rapprochement-bancaire` reprendra. Émettre :\n\n```json\n{ \"trigger\": \"rapprochement-bancaire\", \"client\": \"\" }\n```\n\n(Le batch repasse de toute façon sur tous les clients ; ce trigger ne fait qu'accélérer.)\n\nRelances : ne jamais appeler directement. Produire au plus :\n\n```json\n{ \"trigger_suggestion\": \"relances\", \"reason\": \"invoice status may require update\" }\n```\n\n---\n\n## Philosophie\n\n```\norganisation-documents = moteur d'entrée — classe les pièces, identifie les clients (relevé ou question), maintient clients.json\nrapprochement-bancaire = moteur d'état — rapproche, reconstruit l'état comptable\nrelances = moteur de décision différée\n```\n\nLe travail mécanique est dans les scripts. Ce skill décide *quand* les lancer et *comment* en parler au comptable.\n\nFile v0.2.0:README.md\n\n# organisation-documents\n\n> Claude skill for **French accounting firms** (`cabinets comptables`). Receives accounting documents (invoices, bank statements), identifies the client of the firm by reading bank statements, and classifies each PDF into a per-client / year / month folder tree. Deterministic script-driven — never guesses.\n\n## What it does\n\nFor each invocation, the skill runs **one command** :\n\n```bash\npython3 scripts/main.py \n```\n\nThat script:\n\n1. **Deduplicates** files by SHA-256 (already-classified docs are skipped, listed in `_index.json`).\n2. **Extracts** each PDF with `scripts/extract.py` (`pdftotext -layout` + deterministic regexes — no LLM-eyeballing).\n3. **Phase 1 — bank statements first.** The account holder shown on the statement header **is** the client of the firm (unambiguous). For each statement, create/complete the `clients.json` entry and file the statement into `///bank-statements/`.\n4. **Phase 2 — invoices.** Compare emitter and recipient (extracted from the PDF) against `clients.json`. One side matches a known client → that's the firm's client ; emitter ≈ client → `invoices/out/`, recipient ≈ client → `invoices/in/`.\n5. **Phase 3 — others** : files that are neither invoices nor bank statements → `_non-attribue/`.\n6. Writes `clients/clients.json`, `clients/_index.json`, `clients/_report.json`, and prints a short summary.\n\nThe agent's job is then only to **read `_report.json` and relay it to the accountant in plain French** — including any onboarding question when the client of a new invoice is ambiguous.\n\n## Onboarding for ambiguous senders (the \"Corse Plomberie\" case)\n\nAn invoice always carries two companies. When neither is yet in `clients.json` and no bank statement covers them, the script does not guess :\n\n1. **Step 1** — the document lands in `clients/_a-identifier/` and a question is added to `_report.json → questions` :\n > « Document : facture `TUYO-2024-087` (348,50 € TTC). Émetteur « TUYO SARL », destinataire « Corse Plomberie ». Lequel est votre client ? »\n2. **Step 2** — when the accountant answers « it's Corse Plomberie », the agent adds the mapping to `clients.json` (`contacts[].email = `) and re-runs the script on `_a-identifier/`. The piece gets filed correctly, in the right direction (in/out). **The question is never asked again** for that sender.\n\n## Output tree\n\n```\nclients/\n├── clients.json ← clients of the firm (auto-derived from bank statements + accountant confirmations)\n├── _index.json ← sha256 → classified path (dedup)\n├── _report.json ← last-run report (questions, incomplete, classified, ignored)\n├── _a-identifier/ ← pieces awaiting accountant disambiguation\n├── _incomplet/ ← extraction-incomplete pieces (date or TTC missing)\n├── _non-attribue/ ← non-accounting documents\n└── /\n └── //\n ├── bank-statements/_.pdf\n └── invoices/\n ├── in/___.pdf\n └── out/___.pdf\n```\n\nInvoice numbers in filenames are extracted from PDF content (e.g. `N° F1-2026-0003`) — not guessed. If absent in the PDF, the script writes `SANS-NUM` and flags the piece for review. **No invented values, ever.**\n\n## Why script-driven\n\nEarlier versions let the agent classify documents by reading PDFs and inventing field values. Result : invoice numbers like `\"N\"`, `\"des\"`, `\"um-rix\"`, total amounts of `0.00`, and downstream reconciliation collapse. The current SKILL.md forbids LLM-eyeballed classification and mandates `scripts/main.py`. The extraction logic lives entirely in `scripts/extract.py` (`pdftotext -layout` + named-group regexes for `N°`, `TOTAL TTC`, `SIRET`, transaction lines, etc.).\n\n## Prerequisite\n\nThe script calls `pdftotext` (package `poppler-utils`). Install it once on the runtime :\n\n```bash\napt install poppler-utils # Debian/Ubuntu\nbrew install poppler # macOS\n```\n\n## Companion skill\n\n- [`rapprochement-bancaire`](https://github.com/developers-trendex/rapprochement-bancaire) — reconciles bank transactions with the invoices classified here. Consumes the same `clients//...` tree.\n\n## Files\n\n| File | Purpose |\n| --------------------------------- | ---------------------------------------------------------------------- |\n| `SKILL.md` | Skill definition (French) — the \"when and how to relay\" layer |\n| `scripts/main.py` | Entrypoint — classification, `clients.json` bootstrap, report |\n| `scripts/extract.py` | Deterministic extractor (only place that touches `pdftotext`) |\n| `references/structure-cible.md` | Reference — path/naming conventions, enums |\n| `references/contrat-io.md` | Reference — JSON I/O contract |\n| `references/validation-fr.md` | Reference — French legal validation rules |\n| `references/roadmap.md` | Roadmap |\n| `data/` | Sample data for tests |\n\n## License\n\nInternal — OpenClaw private use.\n\nFile v0.2.0:_meta.json\n\n{\n \"ownerId\": \"kn7ethsmh4zep86d7ew9wsns2x86jwhr\",\n \"slug\": \"organisation-documents\",\n \"version\": \"0.2.0\",\n \"publishedAt\": 1778674070633\n}\n\nFile v0.2.0:references/contrat-io.md\n\n# Référence — Contrat d'invocation & sources\n\n> Référence chargée à la demande par `organisation-documents`. Schémas JSON, sources acceptées, enum d'alertes, schéma de l'index.\n\n---\n\n## Sources acceptées\n\n| Source | Détection | Pré-traitement |\n| ------------------ | --------------------------------------------------------- | --------------------------------------------- |\n| Pièce jointe Gmail | Skill `gog` → push d'événement | Extraction de la PJ + métadonnées de l'e-mail |\n| Adresse AgentMail | Skill `agentmail` → webhook | Idem |\n| Lien Drive | URL `https://drive.google.com/file/d/...` dans un message | Téléchargement via `gog` |\n| Dépôt FS local | Surveillance `~/.openclaw/workspace/inbox/` | Lecture directe |\n| Upload manuel UI | API REST de l'agent | Idem |\n\n### Formats de fichiers\n\nPDF (texte ou scanné), JPG, PNG, HEIC, TIFF, e-mail `.eml` complet, Factur-X (PDF/A-3 + XML embarqué), UBL XML, CSV/OFX (relevés bancaires).\n\n### Métadonnées de l'e-mail (si applicable)\n\nAdresse expéditeur, sujet, date d'envoi, corps HTML. Utilisées pour deviner le client si non détectable depuis la pièce.\n\n---\n\n## Contrat JSON\n\n### Input\n\n```jsonc\n{\n \"email\": {\n // optionnel : absent si dépôt FS / upload manuel\n \"from\": \"compta@orange-pro.fr\",\n \"subject\": \"Facture F-2026-04-1287\",\n \"date\": \"2026-04-15T09:12:00Z\",\n \"body\": \"Bonjour, veuillez trouver ci-joint…\",\n \"messageId\": \"\",\n },\n \"attachments\": [\n {\n \"filename\": \"facture_orange_avril.pdf\",\n \"mimeType\": \"application/pdf\",\n \"path\": \"/var/lib/openclaw/inbox/staging/abc.pdf\",\n \"sizeBytes\": 184320,\n },\n ],\n \"source\": \"gmail|agentmail|drive|fs|upload\",\n \"mode\": \"draft|auto\", // override explicite ; sinon dérivé du calendrier post-onboarding\n \"clientHint\": \"acme-sa\", // optionnel : déjà connu par l'appelant (ex : reclassement)\n}\n```\n\n### Output\n\n```jsonc\n{\n \"status\": \"processed\",\n \"documents\": [\n {\n \"filename\": \"facture_orange_avril.pdf\",\n \"decision\": \"auto_classify|needs_review|ignore\",\n \"reason\": \"client identifié + extraction 0.92 + conforme\",\n \"client\": \"acme-sa\",\n \"categorie\": \"achat\", // enum : achat | vente | bank-statement | note-de-frais | contrat | autre\n \"cheminCible\": \"clients/acme-sa/2026/04/invoices/in/2026-04-15_OrangePro_348.50.pdf\",\n \"metadata\": {\n \"emetteur\": \"Orange Pro\",\n \"destinataire\": \"ACME SA\", // optionnel : peuplé pour categorie = vente\n \"numeroFacture\": \"F-2026-04-1287\",\n \"dateEmission\": \"2026-04-15\",\n \"montantTTC\": 348.5,\n },\n \"confidence\": 0.92, // 0–1, agrégat OCR + matching client\n \"alerts\": [],\n },\n ],\n \"alerts\": [], // alertes batch-level\n}\n```\n\n---\n\n## Enum `alerts[]`\n\nValeurs possibles (par document ou batch-level) :\n\n- `email_non_pertinent` — pas de PJ ET pas de mots-clés comptables → ignoré dès le pré-filtre\n- `client_inconnu` — aucune correspondance dans `clients.json`\n- `extraction_incomplete` — un ou plusieurs champs obligatoires manquants\n- `low_confidence_extraction` — `confidence < 0.7`\n- `siren_client_manquant` — facture B2B post-2026-09-01 sans SIREN destinataire\n- `tva_incoherente` — `HT × taux ≠ TVA` au-delà de la tolérance\n- `duplicate_fichier` — hash identique déjà indexé\n- `duplicate_metier` — même `numeroFacture` + `emetteur` + `montantTTC`\n- `duplicate_probable` — même `emetteur` + `montantTTC` + écart date < 7j\n- `mention_obligatoire_manquante` — au moins une mention légale FR absente\n- `iban_invalide` — IBAN présent mais mod 97 KO\n- `montant_aberrant` — TTC ≠ HT + TVA hors tolérance\n- `date_future` — date d'émission postérieure à aujourd'hui\n- `multi_clients_possibles` — plusieurs candidats clients à confiance proche\n\n---\n\n## Schéma d'une entrée d'index\n\nIndex par client (`~/.openclaw/workspace/clients//index.json`) et global (`~/.openclaw/workspace/index-global.json`).\n\n```jsonc\n{\n \"id\": \"uuid\",\n \"hashFichier\": \"sha256:...\",\n \"clientId\": \"acme-sa\",\n \"categorie\": \"achat\", // enum : achat | vente | bank-statement | note-de-frais | contrat | autre\n \"emetteur\": \"Orange Pro\",\n \"sirenEmetteur\": \"380129866\",\n \"destinataire\": \"ACME SA\", // optionnel : peuplé pour categorie = vente | note-de-frais\n \"numeroFacture\": \"F-2026-04-1287\",\n \"dateEmission\": \"2026-04-15\",\n \"montantHT\": 290.42,\n \"tva\": [{ \"taux\": 20, \"montant\": 58.08 }],\n \"montantTTC\": 348.5,\n \"cheminDrive\": \"clients/acme-sa/2026/04/invoices/in/2026-04-15_OrangePro_348.50.pdf\",\n \"cheminLocal\": \"/var/lib/openclaw/.../clients/acme-sa/2026/04/invoices/in/...\",\n \"statutConformite\": \"conforme\",\n \"manquements\": [],\n \"modeTraitement\": \"auto-validé\",\n \"validePar\": null,\n \"dateClassement\": \"2026-04-28T14:23:11Z\",\n \"sourceReception\": \"gmail|agentmail|drive|fs|upload\",\n \"messageIdSource\": \"...\",\n}\n```\n\nFile v0.2.0:references/reforme-facturation-2026.md\n\n# Réforme de la Facturation Électronique 2026\n\n## Textes de référence\n\n- Loi n° 2022-1726 du 30 décembre 2022 (loi de finances 2023)\n- Loi n° 2023-1322 du 29 décembre 2023 (report de calendrier)\n- Ordonnance n° 2021-1190 du 15 septembre 2021\n- Décret n° 2022-1299 du 7 octobre 2022\n- Article 289 bis du Code général des impôts\n\n## Calendrier\n\n### Phase 1 : 1er septembre 2026\n\n| Obligation | Qui |\n|-----------|-----|\n| **Réception** de factures électroniques | **Toutes** les entreprises assujetties TVA |\n| **Émission** de factures électroniques | Grandes entreprises (GE) et ETI |\n| **E-reporting** | GE et ETI |\n\n### Phase 2 : 1er septembre 2027\n\n| Obligation | Qui |\n|-----------|-----|\n| **Émission** de factures électroniques | PME et micro-entreprises |\n| **E-reporting** | PME et micro-entreprises |\n\n### Déterminer la taille de l'entreprise\n\nCritères cumulatifs (2 sur 3 dépassés pendant 2 exercices consécutifs) :\n\n| Catégorie | Effectif | CA (HT) | Total bilan |\n|-----------|----------|---------|-------------|\n| Micro-entreprise | < 10 | < 900 000 EUR | < 450 000 EUR |\n| PME | < 250 | < 50 M EUR | < 43 M EUR |\n| ETI | < 5 000 | < 1 500 M EUR | < 2 000 M EUR |\n| Grande entreprise | >= 5 000 | >= 1 500 M EUR | >= 2 000 M EUR |\n\n**En pratique** : la grande majorité des utilisateurs de Paperasse sont des TPE/PME/micro. Échéance émission = **1er septembre 2027**. Échéance réception = **1er septembre 2026**.\n\n## Qui est concerné\n\n**Toutes les entreprises assujetties à la TVA établies en France**, y compris :\n- Les entreprises en **franchise en base de TVA** (art. 293 B du CGI) : elles sont assujetties, elles ne collectent simplement pas\n- Les auto-entrepreneurs\n- Les entreprises individuelles\n- Les sociétés (SASU, SAS, SARL, EURL, SA, SCI, etc.)\n\n### Opérations concernées\n\n- Livraisons de biens entre assujettis en France\n- Prestations de services entre assujettis en France\n- Acomptes liés à ces opérations\n\n### Opérations exclues\n\n- Prestations de santé (art. 261, 4° du CGI)\n- Enseignement (art. 261, 4° du CGI)\n- Opérations immobilières exonérées\n- Opérations bancaires et d'assurance (art. 261 C du CGI)\n- Activités associatives exonérées\n\n### Territoires concernés\n\n| Territoire | TVA applicable | E-facturation |\n|-----------|---------------|---------------|\n| France métropolitaine | Oui | Oui |\n| Guadeloupe, Martinique, Réunion | Oui (taux spécifiques) | Oui |\n| Guyane, Mayotte | Non | Non |\n| Saint-Pierre-et-Miquelon, Saint-Barthélemy, Saint-Martin | Non | Non |\n| Nouvelle-Calédonie, Polynésie française | Non | Non |\n\n## Architecture du système\n\n### Les trois acteurs\n\n```\nEntreprise A ──→ PA émettrice ──→ PA réceptrice ──→ Entreprise B\n │ │\n └──────┬───────────┘\n ▼\n PPF (annuaire +\n concentrateur)\n │\n ▼\n DGFiP\n```\n\n### Portail Public de Facturation (PPF)\n\nLe PPF devait initialement servir de plateforme d'émission/réception gratuite pour tous. **Ce rôle a été abandonné en octobre 2024.** Le PPF ne sert plus qu'à :\n\n1. **Annuaire central** : identifie la PA de chaque entreprise pour le routage\n2. **Concentrateur fiscal** : collecte les données de facturation, transaction et paiement transmises par les PA, et les relaie à la DGFiP\n\n**Les entreprises ne peuvent pas utiliser le PPF pour émettre ou recevoir des factures.**\n\n### Plateformes Agréées (PA, anciennement PDP)\n\nLes PA sont des opérateurs privés immatriculés par la DGFiP. Elles assurent :\n- L'émission et la réception des factures électroniques\n- L'extraction et la transmission des données à l'administration (via le PPF)\n- La conformité des formats (Factur-X, UBL, CII)\n- Le suivi des statuts de traitement des factures\n\n**Toute entreprise doit choisir une PA** pour émettre et recevoir des factures électroniques. Voir [plateformes-agreees.md](plateformes-agreees.md) pour le comparatif.\n\n### PEPPOL\n\nRéseau européen d'interopérabilité entre PA. La DGFiP est l'Autorité PEPPOL France. 74 prestataires français connectés (déc. 2025). PEPPOL n'est pas obligatoire pour les PA (elles peuvent s'interconnecter par conventions bilatérales), mais il facilite l'interopérabilité, notamment pour les échanges intra-UE.\n\n## Nouvelles mentions obligatoires (à partir de sept. 2026)\n\nEn plus des mentions existantes (voir [mentions-obligatoires.md](mentions-obligatoires.md)), les factures devront comporter :\n\n| Mention | Détail |\n|---------|--------|\n| **SIREN du client** | Obligatoire pour les transactions B2B domestiques |\n| **Catégorie d'opération** | Livraison de biens / prestation de services / mixte |\n| **Adresse de livraison** | Si différente de l'adresse de facturation |\n| **Option pour les débits** | Si TVA exigible à la facturation (et non à l'encaissement) |\n\n## Conservation\n\nLes factures électroniques doivent être conservées **6 ans** à compter de la date d'établissement, **en format informatique** (pas de simple impression papier). Un cachet électronique qualifié est recommandé pour authentifier l'origine et garantir l'intégrité.\n\n## Sanctions\n\nLe non-respect des obligations de facturation électronique expose à :\n- **Amende de 15 EUR par facture** non émise au format électronique (plafond 15 000 EUR par année civile)\n- **Amende de 250 EUR par transmission** manquante en e-reporting (plafond 15 000 EUR par année civile)\n- Sanctions fiscales classiques en cas de défaut de facturation (50% du montant de la transaction, art. 1737 du CGI)\n\nFile v0.2.0:references/roadmap.md\n\n# Référence — Tools, critères de succès, roadmap, questions ouvertes\n\n> Référence chargée à la demande. Pas nécessaire à l'exécution courante du skill.\n\n---\n\n## Tools (sous-skills appelés)\n\n| Tool | Skill source | Rôle |\n| ---------------------------- | ------------------- | ---------------------------------------- |\n| `nano_pdf.extract` | `nano-pdf` | OCR + extraction structurée des champs |\n| `gog.drive.upload` | `gog` | Dépôt du fichier au chemin cible |\n| `gog.drive.search` | `gog` | Vérification existence fichier |\n| `gog.gmail.fetch_attachment` | `gog` | Récupération PJ depuis un message Gmail |\n| `agentmail.fetch_message` | `agentmail` | Idem côté AgentMail |\n| `factures_doublons.check` | `factures-doublons` | Test de doublons logiques |\n| `taskflow.schedule` | `taskflow` | Replanification si extraction incertaine |\n| `1password.read` | `1password` | Récupération des creds Drive si besoin |\n\n---\n\n## Critères de succès (à mesurer)\n\n- **Taux de classement automatique** ≥ 85 % après 30 jours (hors documents non conformes / non attribuables).\n- **Taux de doublon manqué** = 0 % (doublons certains détectés à 100 %).\n- **Taux de mauvais classement** ≤ 2 % (correction manuelle par le comptable).\n- **Délai de classement** < 60 s entre réception e-mail et fichier classé.\n\n→ Métriques exposées par le skill via une commande `organisation-documents.stats` consommable par le dashboard mensuel.\n\n---\n\n## Roadmap d'implémentation\n\n### v0.1 (MVP)\n\n- Réception Gmail + AgentMail.\n- Extraction `nano-pdf` (pas encore de Factur-X / UBL).\n- Identification client par e-mail expéditeur uniquement.\n- Classement `achat` / `vente` / `autre` dans la structure cible complète (`invoices/in`, `invoices/out`, `autres`).\n- Création des dossiers `bank-statements/`, `notes-de-frais/`, `contrats/` vides au moment où ils deviennent pertinents (pas pré-créés).\n- Lecture de `relances.md` / `followup.md` s'ils existent (pour rattacher paiements aux factures), pas d'écriture (hors scope).\n- Mode draft pur.\n\n### v0.2\n\n- Validation des mentions obligatoires + référentiel embarqué.\n- Détection client par SIREN et fuzzy raison sociale.\n- Bascule auto post-14 jours.\n- CSV consolidé.\n\n### v0.3\n\n- Support Factur-X (XML embarqué) + UBL.\n- Mapping catégorie → compte PCG.\n- Détection séquentialité numéros de facture (anti-fraude).\n- Détection automatique `bank-statement` et `contrat` (mots-clés + structure), au-delà de la simple cascade émetteur ∈ clients.\n\n### v0.4\n\n- Notes de frais (OCR de tickets photo, classement par collaborateur).\n- Relevés bancaires (CSV / OFX) → préparation rapprochement (`rapprochement-bancaire`).\n- Reclassement bulk (correction comptable propage à toutes les pièces similaires).\n\n---\n\n## Questions ouvertes\n\n1. **Reverse OCR sur les images natives** (ticket photo) : `nano-pdf` couvre-t-il, ou faut-il un fallback Tesseract local ?\n2. **Multi-cabinet sur un même container** : confirmé hors scope (cf. `context.md` Q3) — on suppose 1 user = 1 cabinet.\n3. **Migration existant** : si le comptable a déjà un Drive structuré différemment, on importe en l'état ou on re-classe ? → laisser le choix au comptable à l'onboarding.\n4. **Stockage local vs Drive** : doublure complète sur disque LXD pour requêtes rapides, ou tout dans Drive et cache opportuniste ? Impact perf vs coût stockage.\n5. **Format de l'index** : JSON suffit pour < 5 000 pièces / cabinet. Au-delà, basculer SQLite. Quel volume cible ?\n\nFile v0.2.0:references/structure-cible.md\n\n# Référence — Structure cible & conventions de nommage\n\n> Référence chargée à la demande par `organisation-documents`. Spec exhaustive du classement.\n> Source de vérité pour les autres skills qui écrivent dans le même arbre (`relances`, `facturation`, `rapprochement-bancaire`).\n\n---\n\n## Arborescence complète\n\n```\n~/.openclaw/workspace/\n├── clients/\n│ ├── / # un dossier = un client réel (existant ou auto-créé)\n│ │ ├── contrats/ # niveau client — contrats pluriannuels\n│ │ │ └── __.\n│ │ ├── /\n│ │ │ └── /\n│ │ │ ├── bank-statements/ # toujours un dossier (multi-comptes possibles)\n│ │ │ │ └── _.\n│ │ │ ├── invoices/\n│ │ │ │ ├── in/ # factures reçues (achats)\n│ │ │ │ │ └── _<Émetteur>_.\n│ │ │ │ └── out/ # factures émises (ventes)\n│ │ │ │ └── __.\n│ │ │ ├── notes-de-frais/\n│ │ │ │ └── __<Émetteur>_.\n│ │ │ ├── autres/\n│ │ │ │ └── _.\n│ │ │ ├── relances.md # maintenu par skill `relances`\n│ │ │ └── followup.md # maintenu par skill `facturation`\n│ │ ├── _archive-suppression/ # RGPD soft-delete (grâce 30 j)\n│ │ ├── index.json # index par client\n│ │ └── audit.log # déplacements / renommages\n│ └── index-global.json\n├── .pending-attribution/ # parking technique HORS clients/\n│ ├── _.\n│ └── pending-attribution.json\n└── clients.json\n```\n\n### Pas de slug réservé dans `clients/`\n\nTout dossier sous `clients/` correspond à un client réel — existant ou auto-créé en `draft-auto-created`. Aucune entité technique (`_cabinet`, `_non-attribue`, etc.) ne pollue cet arbre.\n\n### `.pending-attribution/`\n\nParking technique pour les documents que la cascade d'identification n'a pas su attribuer (expéditeur générique sans signal exploitable). Vit à la racine du workspace, **hors** `clients/`.\n\n| Élément | Rôle |\n| -------------------------------- | --------------------------------------------------------------------------------- |\n| `_.` | Le fichier physique, renommé pour la traçabilité (pas le filename d'origine) |\n| `pending-attribution.json` | Métadonnées extraites partielles + question à poser à l'utilisateur |\n\nUne fois la réponse utilisateur reçue (« rattacher à `acme-sa` » ou « créer client `nouveau-client` »), le fichier est **déplacé** vers son chemin cible définitif dans `clients//…` et l'entrée correspondante de `pending-attribution.json` est purgée.\n\n---\n\n## Mapping `categorie` → dossier\n\n| `categorie` | Dossier cible | Vocab comptable | Niveau |\n| ---------------- | ---------------------------------------- | ------------------ | -------- |\n| `achat` | `//invoices/in/` | Achats | mois |\n| `vente` | `//invoices/out/` | Ventes | mois |\n| `bank-statement` | `//bank-statements/` | Relevés bancaires | mois |\n| `note-de-frais` | `//notes-de-frais/` | Notes de frais | mois |\n| `contrat` | `contrats/` (racine `/`) | Contrats | client |\n| `autre` | `//autres/` | Autres | mois |\n\nL'enum machine est en kebab-case singulier (`achat`, pas `Achats`). Le vocab capitalisé pluriel est réservé aux **messages affichés au comptable** ; il n'apparaît jamais dans un chemin ni un payload.\n\n---\n\n## Conventions de nommage\n\n### Slug client\n\n- lowercase\n- accents retirés (`é` → `e`, `ç` → `c`, etc.)\n- espaces → `-`\n- caractères non alphanumériques → `-`\n- pas de `-` consécutifs, pas de `-` en début/fin\n- dérivé du **domaine** de l'expéditeur, pas de l'email (`trendex.tech` → `trendex-tech`)\n\n### Composants de nom de fichier\n\n| Token | Règle |\n| ---------------- | ------------------------------------------------------------------------------------------------------ |\n| `AAAA-MM-JJ` | `dateEmission` du document (ISO 8601), pas date de réception |\n| `AAAA-MM` | `dateEmission` tronquée au mois — utilisé pour les relevés bancaires (couvre généralement un mois) |\n| `Émetteur` | Raison sociale source, 10 premiers caractères significatifs, sans accents ni espaces (`Orange Pro` → `OrangePro`) |\n| `Destinataire` | Idem, pour les factures émises (`out/`) — c'est le client final du client du cabinet |\n| `Collaborateur` | Prénom ou prénom+initiale, sans accents (`Thomas`, `ThomasM`) |\n| `MontantTTC` | Sans séparateur de milliers, point décimal, sans symbole (`348.50`, pas `348,50 €`) |\n| `BanqueOuCompte` | Nom court de banque + suffixe compte optionnel (`BNP-courant`, `Qonto-pro`) |\n| `Type` (contrat) | `MSA`, `NDA`, `Bail`, `CDI`, `Avenant`, etc. — vocabulaire court figé |\n| `Contrepartie` | Slug ou raison sociale courte de l'autre partie au contrat |\n| `Description` | Slug court décrivant le document quand aucune catégorie ne s'applique (`Statuts`, `KBis`, `Procuration`) |\n\n### Séparateur\n\n`_` entre composants. `-` à l'intérieur d'un composant. Jamais d'espace.\n\n### Extension\n\nPréservée du document source en lowercase (`.pdf`, `.jpg`, `.png`, `.eml`, `.csv`, `.ofx`, `.xml`).\n\n---\n\n## Cas spéciaux\n\n### Multi-comptes bancaires\n\nUn client peut avoir plusieurs comptes (courant, livret pro, devises). `bank-statements/` est toujours un dossier, jamais un fichier unique :\n\n```\nclients/acme-sa/2026/04/bank-statements/\n├── 2026-04_BNP-courant.pdf\n├── 2026-04_BNP-livret-pro.pdf\n└── 2026-04_Qonto-usd.pdf\n```\n\n### Multi-pages relevé / cas hebdomadaires\n\nSi un relevé couvre plusieurs périodes ou est fragmenté, suffixer avec la plage :\n\n```\nclients/acme-sa/2026/04/bank-statements/2026-04-01_2026-04-15_BNP-courant.pdf\n```\n\n### Contrats pluriannuels\n\nLes contrats vivent à `/contrats/`, indexés sur la date de signature, pas la date de réception. Un avenant garde le même `` préfixé `Avenant-` :\n\n```\nclients/acme-sa/contrats/2024-01-15_MSA_TrendexTech.pdf\nclients/acme-sa/contrats/2026-03-01_Avenant-MSA_TrendexTech.pdf\n```\n\n### Notes de frais — toujours rattachées à un client\n\nUne note de frais appartient toujours à un client (celui dont l'employé doit être remboursé). L'émetteur du document est le commerçant (SNCF, restaurant…) ; le **bénéficiaire** — identifié dans le composant `` du nom — est l'employé d'un client.\n\n```\nclients////notes-de-frais/__<Émetteur>_.\n```\n\nLes frais perso de l'utilisateur lui-même **ne sont pas dans le scope** de ce skill. Si un document de ce type est détecté (typiquement : ticket envoyé depuis l'adresse perso de l'utilisateur, sans contexte client) → traité comme `non attribuable` → `.pending-attribution/`.\n\n### Documents non datables\n\nSi `dateEmission` est introuvable ET non déductible (carte de visite, capture d'écran, etc.) → date de réception en fallback, et alerte `extraction_incomplete`. Décision auto-rétrogradée à `needs_review`.\n\n### Reclassement (correction d'un mauvais classement)\n\nQuand le comptable corrige une attribution (mauvais client, mauvaise catégorie), le skill :\n\n1. Déplace le fichier vers le nouveau chemin (sans renommage si le nouveau nom est identique).\n2. Met à jour `index.json` des deux clients concernés (ancien + nouveau).\n3. Logue l'opération dans `audit.log` du nouveau client avec `motif: reclassement-manuel`.\n4. Ne touche jamais à `_archive-suppression/` (la suppression est un autre flux).\n\n---\n\n## `relances.md` — schéma\n\n> Maintenu par le skill `relances`. Lu par `organisation-documents` en cas de classement d'une réponse à relance.\n\nUn fichier par mois et par client : `clients////relances.md`.\n\n**Contenu** — un fichier = deux tableaux markdown :\n\n```markdown\n# Relances — — /\n\n> Maintenu par le skill `relances`. Toute modification manuelle est tolérée mais peut être écrasée à la prochaine exécution.\n\n## À envoyer\n\n| Date prévue | Facture | Destinataire | Montant TTC | Échéance dépassée | Canal | Type | Statut |\n| ----------- | ------------- | ------------ | ----------- | ----------------- | ----- | ------ | --------- |\n| 2026-05-15 | F-2026-04-012 | TrendexTech | 2 400,00 € | 15 j | email | R1 | planifiée |\n| 2026-05-30 | F-2026-04-012 | TrendexTech | 2 400,00 € | 30 j | email | R2 | planifiée |\n\n## Effectuées\n\n| Date envoi | Facture | Destinataire | Montant TTC | Canal | Type | Réponse client | Suite |\n| ---------- | ------------- | ------------ | ----------- | ------- | ---- | -------------- | ----------------- |\n| 2026-04-15 | F-2026-03-008 | ACME Corp | 1 248,00 € | email | R1 | promesse 15/05 | R2 planifié 30/05 |\n| 2026-04-30 | F-2026-03-005 | Foo SAS | 850,00 € | courrier | R3 | aucune | escalade huissier |\n```\n\n**Colonnes obligatoires** — toute autre colonne est facultative.\n\n**Règles d'écriture** :\n\n- Le skill `relances` est seul autorisé à modifier ces fichiers. `organisation-documents` les lit uniquement.\n- L'ordre des lignes dans `À envoyer` : chronologique croissant (la prochaine en haut).\n- L'ordre des lignes dans `Effectuées` : chronologique décroissant (la plus récente en haut).\n- Quand une relance planifiée est envoyée, le skill `relances` la migre de `À envoyer` vers `Effectuées` dans le fichier du mois courant (pas du mois de la facture).\n\n---\n\n## `followup.md` — schéma\n\n> Maintenu par le skill `facturation`. Lu par `organisation-documents` en cas de classement d'une facture entrante (paiement) ou sortante (émise).\n\nUn fichier par mois et par client : `clients////followup.md`.\n\n```markdown\n# Followup factures — — /\n\n> Maintenu par le skill `facturation`. Vue mois en cours.\n\n## À émettre\n\n| Date prévue | Destinataire | Description | Montant TTC prévu | Statut |\n| ----------- | ------------ | ------------------ | ----------------- | -------------- |\n| 2026-04-01 | TrendexTech | Forfait avril | 2 400,00 € | à préparer |\n| 2026-04-15 | ACME Corp | Prestation projet X | 5 800,00 € | brouillon prêt |\n\n## Émises ce mois\n\n| Date émission | N° facture | Destinataire | Montant TTC | Échéance | Statut paiement | Prochaine relance |\n| ------------- | ------------- | ------------ | ----------- | ---------- | --------------- | ----------------- |\n| 2026-04-01 | F-2026-04-012 | TrendexTech | 2 400,00 € | 2026-04-30 | non payée | R1 le 2026-05-15 |\n| 2026-04-15 | F-2026-04-013 | ACME Corp | 5 800,00 € | 2026-05-15 | partielle (50%) | suivi 2026-05-15 |\n| 2026-04-22 | F-2026-04-014 | Foo SAS | 720,00 € | 2026-05-22 | payée 2026-04-28 | — |\n```\n\n**Statut paiement** — enum : `non payée` | `partielle` | `payée` | `litige` | `irrécouvrable`.\n\n**Mise à jour automatique** — quand `organisation-documents` classe un relevé bancaire dans `bank-statements/`, il devrait théoriquement déclencher un rapprochement (`rapprochement-bancaire` skill) qui mettra à jour `followup.md` avec les paiements détectés. Hors scope de ce skill, mais le contrat de chemin est figé ici pour permettre l'intégration.\n\n---\n\n## Pourquoi cette structure\n\n| Décision | Alternative rejetée | Raison |\n| ------------------------------------------- | -------------------------------------------- | --------------------------------------------------------------------------------------- |\n| `//` (deux niveaux) | `/` (un niveau) | Conservation 10 ans = 120 dossiers à plat ingérables sur Drive/Finder |\n| `invoices/in` + `invoices/out` séparés | `invoices/` unique | TVA et PCG différents — un compta ne mélange jamais |\n| `contrats/` à la racine client | `contrats/` au mois | Contrats pluriannuels — les enterrer dans un mois rend la lecture impossible |\n| `bank-statements/` toujours un dossier | Fichier `bank-statement.pdf` direct | Multi-comptes très courant, dossier dès le départ évite la migration |\n| `relances.md` + `followup.md` au mois | Fichier rolling à la racine client | Le comptable raisonne par mois (clôtures) — état mensuel plus utile que log global |\n| Slug dérivé du domaine | Slug dérivé de l'email | 1 client = N employés = N emails — mais 1 dossier client |\n| Aucun slug réservé dans `clients/` | `_cabinet` + `_non-attribue` pseudo-clients | Un slug = un client réel. Le reste vit dans `.pending-attribution/` hors `clients/`. |\n| Auto-création par défaut | Toujours demander à l'utilisateur | Trop interruptif au quotidien. Confirmation opt-in via `clientCreation: \"confirm\"`. |\n| Enum `categorie` kebab-case singulier | Capitalisé pluriel | Aligné sur les noms de dossiers (`invoices/in` etc.) — pas de mismatch machine/affiché |\n\nFile v0.2.0:references/validation-fr.md\n\n# Référence — Extraction & validation comptable française\n\n> Référence chargée à la demande par `organisation-documents`. Détail des champs, des règles FR, des seuils, des doublons et des données embarquées.\n\n---\n\n## Champs cibles d'extraction\n\n| Champ | Format attendu | Obligatoire |\n| ------------------------ | ---------------------------------------------------- | -------------------------- |\n| `emetteur` | Raison sociale + SIREN si présent | ✅ |\n| `numeroFacture` | Chaîne libre (peut contenir préfixe / suffixe) | ✅ |\n| `dateEmission` | ISO 8601 (`YYYY-MM-DD`) | ✅ |\n| `dateEcheance` | ISO 8601 | ⚠️ recommandé |\n| `montantHT` | Décimal, devise | ✅ |\n| `tauxTVA` | Liste (multi-taux possible) | ✅ |\n| `montantTVA` | Décimal | ✅ |\n| `montantTTC` | Décimal | ✅ |\n| `iban` | Format normalisé (mod 97) | ⚠️ |\n| `bicSwift` | Format normalisé | ⚠️ |\n| `mentionAutoliquidation` | bool | ⚠️ si TVA = 0 |\n| `categorieOperation` | `biens` / `services` / `mixte` | ✅ depuis 2026-09-01 (B2B) |\n| `sirenClient` | Si destinataire = client du cabinet | ✅ depuis 2026-09-01 (B2B) |\n| `confidence` | Score 0–1 agrégeant OCR + matching champs canoniques | ✅ |\n\nSi plusieurs montants détectés (cas multi-pages, rappels), ne retenir que les valeurs présentes en zone « total » du document. Sinon, marquer `extraction-incertaine` et escalader.\n\n### Seuils sur `confidence`\n\n- `≥ 0.85` → éligible auto-classement (si autres conditions OK).\n- `0.70 – 0.85` → toujours en `needs_review`, même hors mode draft.\n- `< 0.70` → alerte `low_confidence_extraction`, escalade systématique.\n\n---\n\n## Validation des mentions obligatoires (FR)\n\nVérifier la conformité de la facture aux mentions légales françaises :\n\n- Présence des **3 mentions distinctes** : « description », « quantité », « prix unitaire ».\n- Numéro de facture **séquentiel** (warning si trou détecté dans la séquence pour le même émetteur).\n- Date d'émission présente et cohérente (≤ aujourd'hui, ≥ 1 an avant).\n- TVA cohérente (`HT × taux = TVA`, tolérance `±0.01`).\n- Si TVA = 0 → mention d'autoliquidation **ou** exonération **ou** franchise présente.\n- Depuis 2026-09-01 (B2B) : SIREN du client + catégorie d'opération obligatoires.\n- IBAN bien-formé (mod 97) si présent.\n\nRéférentiel embarqué : `assets/mentions-obligatoires.json` (structure inspirée de Paperasse `comptable/data/facturation/mentions-obligatoires.json`).\n\nSortie : score de conformité + liste des manquements. Si `manquements > 0`, le document est classé mais **flaggé** dans l'index (`statut-conformite: non-conforme`), avec notification au comptable.\n\n---\n\n## Catégorisation (nature du document)\n\nL'enum `categorie` est aligné sur les dossiers cibles (cf. `structure-cible.md`).\n\nDécision en cascade — première règle qui matche s'applique :\n\n| Indice | `categorie` | Dossier cible | Vocab comptable |\n| -------------------------------------------------------------------------------------------------------- | ---------------- | -------------------------- | ---------------- |\n| Document de type relevé (mots-clés : « relevé », « extrait de compte », IBAN en en-tête sans n° facture) | `bank-statement` | `//bank-statements/` | Relevés bancaires |\n| Contrat (mots-clés : « contrat », « avenant », pas de montant TTC en clair) | `contrat` | `contrats/` (racine client) | Contrats |\n| Émetteur = personne physique du cabinet ou d'un client | `note-de-frais` | `//notes-de-frais/` | Notes de frais |\n| `emetteur` ∈ clients du cabinet (le client a émis la facture à l'un de ses propres clients) | `vente` | `//invoices/out/` | Ventes |\n| `emetteur` ∉ clients ET le client est destinataire | `achat` | `//invoices/in/` | Achats |\n| Aucune correspondance | `autre` | `//autres/` | Autres |\n\n**Ordre important** : `bank-statement` et `contrat` sont testés AVANT `vente`/`achat` car ils peuvent être émis par un client du cabinet sans être pour autant une vente (un relevé BNP avec émetteur = client ne doit pas atterrir dans `invoices/out/`).\n\n**Précision `note-de-frais`** : l'émetteur du document est le commerçant (SNCF, restaurant…) ; ce qui qualifie en note de frais c'est le **bénéficiaire** (l'employé qui se fait rembourser) ou le contexte de réception (mail d'un collaborateur d'un client). Le slug du dossier est toujours celui du **client** qui emploie le bénéficiaire. Pour les frais perso de l'utilisateur lui-même → escalade vers `.pending-attribution/` (hors scope du skill).\n\n---\n\n## Détection de doublons\n\nAu-delà du hash fichier (étape 1 du workflow principal), vérifier les doublons **logiques** dans l'index du client cible :\n\n| Test | Verdict | Action |\n| ---------------------------------------------------------- | --------------------------------- | --------------------------------- |\n| Même `numeroFacture` + même `emetteur` + même `montantTTC` | `doublon-certain` | Skip classement, log au comptable |\n| Même `emetteur` + même `montantTTC` + écart date < 7j | `doublon-probable` | Classer mais flagger pour revue |\n| Même hash fichier | `doublon-fichier` | Stop avant traitement |\n| Tolérance arrondi : `abs(TTC1 - TTC2) < 0.01` | (s'applique aux 2 premiers tests) | — |\n\n→ Réutilise la logique du skill `factures-doublons` quand il sera buildé. Pour l'instant, implémentation locale.\n\n---\n\n## Données embarquées\n\nDans `assets/` du skill :\n\n- `mentions-obligatoires.json` — règles de conformité FR (référentiel inspiré de Paperasse, à versionner avec dates de validité).\n- `pcg-2026.json` — Plan Comptable Général (utile pour mapping catégorie → compte PCG dans une v0.2).\n- `tva-taux-fr.json` — taux de TVA en vigueur (5,5 / 10 / 20 / 0 / autoliquidation).\n- `regex-siren-iban-tva-intra.json` — patterns d'extraction réutilisables.\n\nFile v0.2.0:skill-card.md\n\n## Description:\n\nOrganises accounting documents for French accounting firms by classifying invoices and bank statements into client, year, month, and document-type folders, then reporting any items that need accountant review.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[trendex](https://clawhub.ai/user/trendex)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nAccountants and firm staff use this skill to sort incoming accounting documents, maintain client document indexes, and surface ambiguous or incomplete items for human review.\n\n### Deployment Geography for Use:\n\nFrance\n\n## Known Risks and Mitigations:\n\nRisk: The skill is intended to process sensitive accounting documents automatically.\n\nMitigation: Require explicit opt-in before unattended email or file processing and constrain the skill to a known inbox and client root.\n\nRisk: The skill writes long-lived local document copies and indexes.\n\nMitigation: Review retention expectations, access controls, output locations, and audit or rollback procedures before deployment.\n\nRisk: Company lookup may contact an external public company-data service.\n\nMitigation: Disable or document external lookup behavior when confidential workflows must remain fully local.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/trendex/skills/organisation-documents)\n- [Reference - Invocation contract and sources](references/contrat-io.md)\n- [Reference - Target structure and naming conventions](references/structure-cible.md)\n- [Reference - French accounting extraction and validation](references/validation-fr.md)\n- [Reference - 2026 electronic invoicing reform](references/reforme-facturation-2026.md)\n- [Reference - Tools, success criteria, and roadmap](references/roadmap.md)\n- [Annuaire des Entreprises API](https://annuaire-entreprises.data.gouv.fr/api)\n- [Companion bank reconciliation skill](https://github.com/developers-trendex/rapprochement-bancaire)\n\n## Skill Output:\n\n**Output Type(s):** [Text, JSON, Shell commands, Configuration, Guidance]\n\n**Output Format:** [Plain-language summary with JSON report data and shell command usage]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Produces local document copies, clients.json, _index.json, _report.json, and follow-up questions for accountant review.]\n\n## Skill Version(s):\n\n0.2.0 (source: server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nFile v0.2.0:data/company.example.json\n\n{\n \"name\": \"EXEMPLE DE SOCIETE A COMPLETER\",\n \"legal_form\": \"SASU\",\n \"capital\": 1000,\n \"address\": \"1 Rue de la Paix, 75001 Paris\",\n \"siren\": \"123456789\",\n \"siret\": \"12345678900014\",\n \"rcs\": \"RCS Paris\",\n \"naf\": \"6201Z\",\n \"president\": {\n \"title\": \"President\",\n \"first_name\": \"Jean\",\n \"last_name\": \"DUPONT\",\n \"civility\": \"M.\",\n \"_comment\": \"Utiliser 'President' pour SAS/SASU, 'Gerant' pour SARL/EURL\"\n },\n \"fiscal_year\": {\n \"start\": \"2025-01-01\",\n \"end\": \"2025-12-31\",\n \"is_first_year\": false\n },\n \"tax\": {\n \"regime_tva\": \"franchise\",\n \"regime_is\": \"reel_simplifie\",\n \"tva_rate\": 0.20\n },\n \"banks\": [\n {\n \"id\": \"bank-1\",\n \"name\": \"Banque Principale\",\n \"account\": \"5121\",\n \"fec_account\": \"51211\"\n }\n ],\n \"qonto\": {\n \"enabled\": false,\n \"_comment\": \"Mettre enabled a true si vous utilisez Qonto. Env vars: QONTO_ID, QONTO_API_SECRET\"\n },\n \"stripe_accounts\": [\n {\n \"id\": \"main\",\n \"name\": \"Mon Produit SaaS\",\n \"env_key\": \"STRIPE_SECRET\",\n \"_comment\": \"Definir STRIPE_SECRET avec votre cle Stripe (sk_live_... ou sk_test_...). Pour Stripe Connect, ajouter: stripe_account_id: acct_xxx\"\n }\n ],\n \"city\": \"Paris\",\n \"invoicing\": {\n \"prefix\": \"F\",\n \"separator\": \"-\",\n \"year_format\": \"YYYY\",\n \"next_numbers\": {\n \"2025\": 1,\n \"2026\": 1\n },\n \"avoir_prefix\": \"AV\",\n \"_comment\": \"Format: F-2026-001. next_numbers par annee (reset au 1er janvier). Modifier prefix et separateur selon besoins.\"\n },\n \"einvoicing\": {\n \"pa\": \"\",\n \"pa_name\": \"\",\n \"peppol_id\": \"\",\n \"reception_ready\": false,\n \"emission_ready\": false,\n \"ereporting_ready\": false,\n \"_comment\": \"Plateforme agreee (ex: qonto, indy, pennylane, dext). peppol_id format iso6523:siret, ex '0225:12345678900014'. reception_ready obligatoire a partir de sept. 2026.\"\n },\n \"payment\": {\n \"default_terms\": \"net_30\",\n \"default_terms_label\": \"30 jours date de facture\",\n \"methods\": [\"virement\"],\n \"bank_details\": {\n \"iban\": \"\",\n \"bic\": \"\"\n },\n \"late_penalty_rate\": \"3x_legal\",\n \"late_penalty_label\": \"3 fois le taux d'interet legal\",\n \"escompte\": \"none\",\n \"escompte_label\": \"Pas d'escompte pour paiement anticipe\",\n \"recovery_fee\": 40,\n \"_comment\": \"late_penalty_rate: '3x_legal' (defaut legal si non precise) ou taux fixe (ex 10.15). escompte: 'none' ou taux en %. recovery_fee fixe a 40 EUR par la loi.\"\n }\n}\n\nFile v0.2.0:data/facturation/mentions-obligatoires.json\n\n{\n \"version\": \"2026-04-15\",\n \"source\": \"Art. 242 nonies A CGI, Art. L441-9 C.com, Réforme facturation électronique 2026\",\n \"mentions\": {\n \"emetteur\": [\n {\n \"id\": \"nom\",\n \"label\": \"Nom ou dénomination sociale\",\n \"base_legale\": \"Art. 242 nonies A, I-1° CGI\",\n \"obligatoire\": true,\n \"depuis\": \"existant\"\n },\n {\n \"id\": \"adresse\",\n \"label\": \"Adresse du siège social\",\n \"base_legale\": \"Art. 242 nonies A, I-1° CGI\",\n \"obligatoire\": true,\n \"depuis\": \"existant\"\n },\n {\n \"id\": \"siren\",\n \"label\": \"Numéro SIREN ou SIRET\",\n \"base_legale\": \"Art. 242 nonies A, I-1° CGI\",\n \"obligatoire\": true,\n \"depuis\": \"existant\"\n },\n {\n \"id\": \"rcs\",\n \"label\": \"Numéro RCS et ville\",\n \"base_legale\": \"Code de commerce\",\n \"obligatoire\": true,\n \"depuis\": \"existant\",\n \"condition\": \"sociétés commerciales\"\n },\n {\n \"id\": \"forme_juridique\",\n \"label\": \"Forme juridique et capital social\",\n \"base_legale\": \"Code de commerce\",\n \"obligatoire\": true,\n \"depuis\": \"existant\",\n \"condition\": \"sociétés\"\n },\n {\n \"id\": \"tva_intracom\",\n \"label\": \"Numéro TVA intracommunautaire\",\n \"base_legale\": \"Art. 242 nonies A, I-2° CGI\",\n \"obligatoire\": true,\n \"depuis\": \"existant\",\n \"condition\": \"assujetti redevable (pas franchise)\"\n }\n ],\n \"client\": [\n {\n \"id\": \"nom_client\",\n \"label\": \"Nom ou dénomination sociale du client\",\n \"base_legale\": \"Art. 242 nonies A, I-3° CGI\",\n \"obligatoire\": true,\n \"depuis\": \"existant\"\n },\n {\n \"id\": \"adresse_client\",\n \"label\": \"Adresse du client\",\n \"base_legale\": \"Art. 242 nonies A, I-3° CGI\",\n \"obligatoire\": true,\n \"depuis\": \"existant\"\n },\n {\n \"id\": \"siren_client\",\n \"label\": \"Numéro SIREN du client\",\n \"base_legale\": \"Réforme 2026\",\n \"obligatoire\": true,\n \"depuis\": \"2026-09-01\",\n \"condition\": \"B2B domestique\"\n },\n {\n \"id\": \"tva_intracom_client\",\n \"label\": \"Numéro TVA intracommunautaire du client\",\n \"base_legale\": \"Art. 242 nonies A, I-4° CGI\",\n \"obligatoire\": true,\n \"depuis\": \"existant\",\n \"condition\": \"opération intra-UE\"\n }\n ],\n \"facture\": [\n {\n \"id\": \"numero\",\n \"label\": \"Numéro de facture (séquence chronologique unique)\",\n \"base_legale\": \"Art. 242 nonies A, I-5° CGI\",\n \"obligatoire\": true,\n \"depuis\": \"existant\"\n },\n {\n \"id\": \"date_emission\",\n \"label\": \"Date d'émission\",\n \"base_legale\": \"Art. 242 nonies A, I-6° CGI\",\n \"obligatoire\": true,\n \"depuis\": \"existant\"\n },\n {\n \"id\": \"date_livraison\",\n \"label\": \"Date de livraison ou d'exécution\",\n \"base_legale\": \"Art. 242 nonies A, I-7° CGI\",\n \"obligatoire\": true,\n \"depuis\": \"existant\",\n \"condition\": \"si différente de la date d'émission\"\n },\n {\n \"id\": \"categorie_operation\",\n \"label\": \"Catégorie d'opération (biens / services / mixte)\",\n \"base_legale\": \"Réforme 2026\",\n \"obligatoire\": true,\n \"depuis\": \"2026-09-01\"\n },\n {\n \"id\": \"adresse_livraison\",\n \"label\": \"Adresse de livraison\",\n \"base_legale\": \"Réforme 2026\",\n \"obligatoire\": true,\n \"depuis\": \"2026-09-01\",\n \"condition\": \"si différente de l'adresse de facturation\"\n },\n {\n \"id\": \"option_debits\",\n \"label\": \"Option pour la TVA sur les débits\",\n \"base_legale\": \"Réforme 2026\",\n \"obligatoire\": true,\n \"depuis\": \"2026-09-01\",\n \"condition\": \"si l'entreprise a opté pour les débits\"\n }\n ],\n \"lignes\": [\n {\n \"id\": \"designation\",\n \"label\": \"Désignation précise des biens ou services\",\n \"base_legale\": \"Art. 242 nonies A, I-8° CGI\",\n \"obligatoire\": true,\n \"depuis\": \"existant\"\n },\n {\n \"id\": \"quantite\",\n \"label\": \"Quantité\",\n \"base_legale\": \"Art. 242 nonies A, I-9° CGI\",\n \"obligatoire\": true,\n \"depuis\": \"existant\"\n },\n {\n \"id\": \"prix_unitaire_ht\",\n \"label\": \"Prix unitaire hors taxes\",\n \"base_legale\": \"Art. 242 nonies A, I-10° CGI\",\n \"obligatoire\": true,\n \"depuis\": \"existant\"\n }\n ],\n \"montants\": [\n {\n \"id\": \"total_ht\",\n \"label\": \"Montant total hors taxes\",\n \"base_legale\": \"Art. 242 nonies A, I-11° CGI\",\n \"obligatoire\": true,\n \"depuis\": \"existant\"\n },\n {\n \"id\": \"taux_tva\",\n \"label\": \"Taux de TVA applicable (par taux distinct)\",\n \"base_legale\": \"Art. 242 nonies A, I-12° CGI\",\n \"obligatoire\": true,\n \"depuis\": \"existant\",\n \"condition\": \"si redevable TVA\"\n },\n {\n \"id\": \"montant_tva\",\n \"label\": \"Montant de TVA (par taux distinct)\",\n \"base_legale\": \"Art. 242 nonies A, I-12° CGI\",\n \"obligatoire\": true,\n \"depuis\": \"existant\",\n \"condition\": \"si redevable TVA\"\n },\n {\n \"id\": \"total_ttc\",\n \"label\": \"Montant total TTC\",\n \"base_legale\": \"Art. 242 nonies A, I-13° CGI\",\n \"obligatoire\": true,\n \"depuis\": \"existant\"\n }\n ],\n \"paiement\": [\n {\n \"id\": \"date_echeance\",\n \"label\": \"Date d'échéance du paiement\",\n \"base_legale\": \"Art. L441-9 C.com\",\n \"obligatoire\": true,\n \"depuis\": \"existant\"\n },\n {\n \"id\": \"conditions_escompte\",\n \"label\": \"Conditions d'escompte pour paiement anticipé\",\n \"base_legale\": \"Art. L441-9 C.com\",\n \"obligatoire\": true,\n \"depuis\": \"existant\"\n },\n {\n \"id\": \"penalites_retard\",\n \"label\": \"Taux de pénalités de retard\",\n \"base_legale\": \"Art. L441-10 C.com\",\n \"obligatoire\": true,\n \"depuis\": \"existant\"\n },\n {\n \"id\": \"indemnite_recouvrement\",\n \"label\": \"Indemnité forfaitaire de recouvrement (40 EUR)\",\n \"base_legale\": \"Art. L441-10, D441-5 C.com\",\n \"obligatoire\": true,\n \"depuis\": \"existant\",\n \"valeur_fixe\": 40\n }\n ]\n },\n \"mentions_speciales\": [\n {\n \"id\": \"franchise_tva\",\n \"condition\": \"Entreprise en franchise en base de TVA\",\n \"texte\": \"TVA non applicable, article 293 B du Code général des impôts\"\n },\n {\n \"id\": \"autoliquidation_intra_ue\",\n \"condition\": \"Prestation de services intra-UE B2B\",\n \"texte\": \"Autoliquidation - TVA due par le preneur, article 283-2 du CGI\"\n },\n {\n \"id\": \"export\",\n \"condition\": \"Export hors UE\",\n \"texte\": \"Exonération de TVA, article 262 I du CGI\"\n },\n {\n \"id\": \"livraison_intra_ue\",\n \"condition\": \"Livraison intracommunautaire de biens\",\n \"texte\": \"Exonération de TVA, article 262 ter I du CGI\"\n },\n {\n \"id\": \"sous_traitance_btp\",\n \"condition\": \"Sous-traitance dans le BTP\",\n \"texte\": \"Autoliquidation de la TVA par le preneur, article 283 2 nonies du CGI\"\n },\n {\n \"id\": \"autofacturation\",\n \"condition\": \"Le client émet la facture pour le compte du fournisseur\",\n \"texte\": \"Autofacturation\"\n }\n ]\n}\n\nArchive v0.1.0: 7 files, 21220 bytes\n\nFiles: README.md (3338b), references/contrat-io.md (5249b), references/roadmap.md (3785b), references/structure-cible.md (14917b), references/validation-fr.md (7515b), SKILL.md (16737b), _meta.json (141b)\n\nFile v0.1.0:SKILL.md\n\n---\nname: organisation-documents\ndescription: Core skill for French accounting assistants (cabinets comptables). Receives, classifies, and renames accounting documents (invoices, expense reports, bank statements, contracts) into a per-client / year / month folder tree. INVOKE SYSTEMATICALLY AND WITHOUT ASKING FOR PERMISSION whenever (a) an email arrives with a PDF/image attachment, (b) an email contains an accounting keyword (facture, invoice, reçu, paiement, TVA, total, acompte, avoir, relevé), (c) the user asks to process / classify / organize a document, (d) a file is dropped into the inbox. Handles extraction, French legal mandatory-mention validation, duplicate detection, auto-creation of client records for unknown senders, and 10-year legal retention.\nlicense: Interne — usage privé OpenClaw\n---\n\n# Skill `organisation-documents`\n\n> Skill maison du domaine comptable. Réception → extraction → validation → classement → indexation → rapport.\n> Détails techniques dans `references/` (chargés à la demande, pas à chaque invocation).\n\n---\n\n## Quand utiliser ce skill\n\n**Règle d'or** : c'est le **réflexe par défaut** de l'assistant face à tout document entrant. L'assistant ne demande PAS « voulez-vous que je classe cette facture ? » — il classe et il rapporte. Si le comptable doit demander explicitement « utilise le skill », c'est un échec d'invocation.\n\nDéclencheurs :\n\n1. **E-mail avec PJ** sur `gog` ou `agentmail` → traitement immédiat.\n2. **Dépôt manuel** dans l'inbox (Drive ou local) → idem.\n3. **Import en masse** (commande explicite du comptable).\n4. **Reclassement** : correction client/nature → propage le déplacement et met à jour l'index.\n\n**Pré-requis automatiques** (silencieux, sans poser la question) :\n\n- Si `clients.json` n'existe pas → le créer vide.\n- Nouveau domaine d'expéditeur → fiche client en draft auto-créée (cf. Étape 2).\n\nNe **pas** utiliser pour : factures sortantes (→ `facturation`), FEC (→ `fec-parser`), relances (→ `relances`).\n\n---\n\n## Mode d'exécution\n\n### Inline only par défaut\n\nPour 1 à 3 documents (cas standard : 1 e-mail = 1 PJ), **exécution inline obligatoire**. Pas de subagent, pas de délégation, pas de TaskFlow secondaire. Le subagent rajoute 30-60 s d'overhead inutile et risque le timeout 180 s.\n\nSubagent autorisé **uniquement** pour `import-en-masse` (> 10 documents en une fois) — et encore, par batch de 20.\n\n### Fast-path : court-circuiter les étapes inutiles\n\nSi l'index global est vide ou ne contient pas le client cible :\n\n- **Skipper** étape 1 (dédup hash global) → forcément unique.\n- **Skipper** étape 7 (doublons métier) → l'index client est vide.\n\nSi `mode = auto` ET client identifié dès l'étape 2.a (pas d'auto-création) ET extraction confiance ≥ 0.9 :\n\n- Étapes 4 (validation FR) et 5 (catégorisation) en **un seul passage** combiné, pas deux.\n\n### Time budget\n\n- 1 document inline : **≤ 30 s** entre réception et classement.\n- Au-delà, dégrader en `needs_review` + signaler le ralentissement au comptable.\n\n---\n\n## Workflow (10 étapes)\n\nDétails dans `references/validation-fr.md` (étapes 3, 4, 5, 7), `references/contrat-io.md` (étapes 1, 9) et `references/structure-cible.md` (étapes 5, 6).\n\n| # | Étape | Sortie clé |\n| --- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------ |\n| 0 | **Pré-filtre pertinence** : si pas de PJ ET pas de mot-clé comptable → `ignore` + alerte `email_non_pertinent` | décision `ignore` ou continuer |\n| 1 | **Hash & dédup fichier** (skipper si index global vide) | hash SHA-256, `duplicate_fichier` ou rien |\n| 2 | **Identification client** (cf. ci-dessous) | `clientId` + auto-création si inconnu |\n| 3 | **Extraction des champs** (cf. `references/validation-fr.md`) | structure complète + `confidence` 0-1 |\n| 4 | **Validation FR** (mentions obligatoires, TVA, IBAN, dates) | `manquements[]` |\n| 5 | **Catégorisation** (cf. `references/structure-cible.md`) | `categorie` ∈ enum |\n| 6 | **Génération du chemin** (cf. ci-dessous) | `cheminCible` |\n| 7 | **Doublons métier** (skipper si index client vide) | `duplicate_metier` / `duplicate_probable` / rien |\n| 8 | **Décision finale** (cf. ci-dessous) | `auto_classify` / `needs_review` / `ignore` |\n| 9 | **Indexation** : index client + index global + audit log | écritures persistées |\n| 10 | **Rapport** au comptable | message court + CSV consolidé du mois |\n\n---\n\n## Étape 2 — Identification du client (cascade + auto-création + escalade)\n\nTous les documents traités appartiennent à un client connu ou auto-créé. **Pas de slug magique** pour l'utilisateur lui-même : les frais perso du comptable ne sont pas dans le scope de ce skill. Si la cascade échoue à attribuer, le document part en `.pending-attribution/` et l'utilisateur est questionné en fin de batch.\n\n### Cascade de détection (ordre de priorité)\n\n1. Adresse e-mail expéditeur matchée contre `contact.email` d'un client.\n2. Domaine de l'expéditeur matché contre `domains` d'un client.\n3. SIREN extrait du document matché contre `siren` d'un client.\n4. Raison sociale fuzzy (Levenshtein ≤ 3) contre `raisonSociale` d'un client.\n5. **Auto-création** si un signal exploitable existe (cf. ci-dessous).\n6. **Sinon → `.pending-attribution/`** : escalade utilisateur en fin de batch.\n\n### Auto-création (étape 5)\n\nPar défaut, le skill crée une fiche client en draft et classe normalement, sans demander confirmation. Config flag `clientCreation: \"confirm\"` désactive ce comportement : l'auto-création devient une proposition à valider avant exécution.\n\nSlug dérivé du premier signal exploitable, par préférence :\n\n| Source du signal | `slug` dérivé | Exemple |\n| ---------------------- | --------------------------------- | -------------------------------------- |\n| Domaine pro | domaine normalisé | `foo-corp.com` → `foo-corp-com` |\n| SIREN extrait du PDF | raison sociale slugifiée | SIREN 380… → `acme-sa` |\n| Raison sociale lisible | slugifiée directement | \"ACME Industries\" → `acme-industries` |\n\nProcédure :\n\n- Insérer dans `clients.json` : `statut: \"draft-auto-created\"`, `aValider: true`, `confiance` dégradée selon la qualité du signal.\n- `raisonSociale` candidate : extraite du PDF si possible, sinon humanisée depuis le slug.\n- Classer normalement dans le dossier nouvellement créé.\n- Notifier dans le rapport batch (un seul message en fin de run, pas un par étape).\n\n### Cas non attribuable (étape 6)\n\nSignaux insuffisants : expéditeur générique (`@gmail.com`, `@outlook.com`, `@yahoo.fr`) ET aucun SIREN ET aucune raison sociale exploitable → escalade utilisateur.\n\nProcédure :\n\n1. Déplacer le fichier dans `~/.openclaw/workspace/.pending-attribution/` (zone technique, hors `clients/`).\n2. Renommer en `_.` pour la traçabilité.\n3. Enregistrer une entrée dans `pending-attribution.json` avec les bribes extraites (montant, date, émetteur si dispo, sujet email, ID source).\n4. En fin de batch, lister tous les pending dans le rapport avec une question explicite (« À quel client rattacher ces N documents ? »).\n5. Sur réponse, déplacer vers le chemin cible définitif et purger l'entrée.\n\n---\n\n## Étape 6 — Convention de chemin\n\n> Spec exhaustive dans [`references/structure-cible.md`](references/structure-cible.md). Résumé ici pour les cas courants.\n\n### Arbo cible\n\n```\nclients//\n├── contrats/ # contrats — niveau client, pas mois\n│ └── __.\n├── /\n│ └── /\n│ ├── bank-statements/ # toujours un dossier (multi-comptes possible)\n│ │ └── _.\n│ ├── invoices/\n│ │ ├── in/ # achats — factures reçues\n│ │ │ └── _<Émetteur>_.\n│ │ └── out/ # ventes — factures émises\n│ │ └── __.\n│ ├── notes-de-frais/\n│ │ └── __<Émetteur>_.\n│ ├── autres/\n│ │ └── _.\n│ ├── relances.md # maintenu par skill `relances`\n│ └── followup.md # maintenu par skill `facturation`\n├── index.json\n└── audit.log\n```\n\n**Pourquoi un dossier par mois** : c'est le grain de travail du comptable (clôture mensuelle, TVA, rapprochement). L'année est conservée pour la conservation 10 ans.\n\n**Pourquoi `` dérivé du domaine et pas de l'e-mail** :\n\n- 1 client = souvent plusieurs e-mails → on veut **un seul** dossier.\n- `@` casse les URLs et passe mal sur certains FS.\n- L'email est un attribut de la fiche client, pas l'identifiant du dossier.\n\n**Pourquoi `invoices/in` + `invoices/out`** : un compta ne mélange jamais achats et ventes — TVA, comptes PCG et rapports différents. Coût zéro de séparer dès le classement.\n\n**Pourquoi `contrats/` au niveau client (pas mois)** : un contrat est pluriannuel et lu hors cycle mensuel. Le mettre dans un mois donné l'enterre.\n\n**Pourquoi `relances.md` / `followup.md` au mois** : ce sont les artefacts du cycle de relance courant, lus en début de chaque clôture. Ils ne sont pas produits par ce skill (`relances` et `facturation` s'en chargent) mais leur emplacement est imposé ici pour que tous les skills convergent.\n\n### Normalisation des composants\n\n- `slug` : lowercase, accents retirés, espaces → `-`.\n- `Émetteur` / `Destinataire` / `Collaborateur` : 10 premiers caractères significatifs, sans accents ni espaces.\n- `MontantTTC` : sans séparateur de milliers, point décimal, sans symbole.\n- `AAAA` / `MM` / `AAAA-MM-JJ` : dérivés de `dateEmission` du document, pas de la date de réception.\n\n### Exemples\n\n```\nclients/acme-sa/2026/04/invoices/in/2026-04-15_OrangePro_348.50.pdf\nclients/trendex-tech/2026/03/invoices/in/2026-03-26_Anthropic_21.60.pdf\nclients/acme-sa/2026/04/invoices/out/2026-04-01_TrendexTech_2400.00.pdf\nclients/acme-sa/2026/04/bank-statements/2026-04_BNP-courant.pdf\nclients/acme-sa/2026/04/notes-de-frais/2026-04-12_Marie_SNCF_84.50.pdf\nclients/acme-sa/contrats/2024-01-15_MSA_TrendexTech.pdf\n```\n\n**Aucun slug réservé** dans `clients/`. Tout dossier sous `clients/` correspond à un client réel (existant ou auto-créé en `draft-auto-created`).\n\nLe parking technique `.pending-attribution/` vit **hors** de `clients/`, à la racine du workspace :\n\n```\n~/.openclaw/workspace/\n├── clients/\n│ └── …\n└── .pending-attribution/\n ├── 2026-04-29_a7b2c3d4.pdf\n └── pending-attribution.json\n```\n\n---\n\n## Étape 8 — Décision finale\n\nCascade (première règle qui matche s'applique) :\n\n| Condition | Décision |\n| ---------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- |\n| `email_non_pertinent` OU `duplicate_fichier` OU `duplicate_metier` | `ignore` |\n| Client `non-attribué` OU `confidence < 0.85` OU `manquements > 0` OU `duplicate_probable` OU `multi_clients_possibles` | `needs_review` |\n| `mode = draft` (calendrier post-onboarding actif) | `needs_review` (preview classée mais non exécutée) |\n| Sinon | `auto_classify` |\n\n**Calendrier `mode` par défaut** : 14 jours post-onboarding = `draft` forcé. Après 14 jours + ≥ 80 % de plans validés sans correction → bascule `auto`.\n\nLe mode `auto` ne court-circuite jamais la sécurité métier : doublon probable, non conforme, non attribuable, montant incertain → toujours `needs_review`.\n\n---\n\n## Communication avec le comptable\n\nL'utilisateur est un **comptable**, pas un développeur. Règles strictes.\n\n### Silence par défaut\n\nPendant le traitement : **une ligne au début, une ligne à la fin**. Pas de narration par étape.\n\n✅ Bon :\n\n> Je traite la facture Anthropic du dernier mail.\n>\n> _(traitement silencieux 10-30 s)_\n>\n> ✅ Classée : **Trendex Tech / 2026 / Mars / Achats** — 21,60 € TTC. Nouveau client, fiche à valider.\n\n❌ Mauvais (ce qui s'est passé au test du 2026-04-29) :\n\n> Je vais analyser le mail…\n> Je télécharge la pièce jointe…\n> Je calcule un hash…\n> Je vérifie l'index global…\n> Je lance pdftotext…\n> J'extrais les champs…\n> _(10 lignes de plus)_\n\n### Vocabulaire interdit\n\n`pdftotext`, `nano-pdf`, `gog`, `agentmail`, `taskflow`, `OCR`, `regex`, `mod 97`, `SHA-256`, `pipeline`, `parser`, `webhook`, `attachment ID`, paths absolus système, IDs JSON internes, scores numériques bruts (« confidence 0.92 »).\n\n### Vocabulaire métier\n\nFacture, pièce, dossier client, mois en cours, échéance, classement, doublon, mention obligatoire, conformité, brouillon, à valider.\n\n### Format du rapport final\n\nTableau lisible. Pas de chemins techniques (`clients/acme-sa/2026/04/...` → « ACME SA / Avril / Achats »). Pas de score numérique (« extraction fiable » / « extraction à vérifier »).\n\n### Quand demander une validation\n\n**Uniquement** : multi-clients ambigus, non-conforme > 1000 €, doublon probable. Tout le reste s'auto-classe avec récap final.\n\n---\n\n## Garde-fous (sécurité, RGPD, secret pro)\n\n- **Aucune donnée client ne quitte le container LXD du user.** Pas d'OCR cloud sans consentement explicite.\n- **Logs sans PII** : `numéroFacture`, `emetteur`, `montantTTC`, `cheminDrive` autorisés ; `IBAN`, contenu textuel, e-mails clients **interdits**.\n- **Sources externes en lecture seule** : `gog` et `agentmail` jamais modifiés. Pas de `delete`, `mark as read`, `move to folder`. Inbox source intacte.\n- **Conservation 10 ans minimum** (art. L123-22 Code de commerce). Skill ne supprime jamais.\n- **Suppression RGPD** : déclenchée uniquement par le comptable. Soft-delete vers `/_archive-suppression/` + grâce 30 j.\n- **Audit trail** : chaque déplacement / renommage loggé dans `~/.openclaw/workspace/clients//audit.log` (UTC + acteur).\n- **Philosophie** : « mieux vaut escalader que mal classer ». En cas de doute → `needs_review`.\n\n---\n\n## Références complémentaires\n\n- [`references/structure-cible.md`](references/structure-cible.md) — arbo complète, conventions de nommage, mapping type → dossier, schéma de `relances.md` et `followup.md`\n- [`references/contrat-io.md`](references/contrat-io.md) — schémas JSON Input/Output, sources acceptées, enum `alerts[]`, schéma de l'index\n- [`references/validation-fr.md`](references/validation-fr.md) — champs d'extraction, seuils `confidence`, validations FR détaillées, règles de doublons, données embarquées\n- [`references/roadmap.md`](references/roadmap.md) — tools (sous-skills), critères de succès, roadmap v0.1→v0.4, questions ouvertes\n\nFile v0.1.0:README.md\n\n# organisation-documents\n\n> Claude skill for **French accounting firms** (`cabinets comptables`). Automatically receives, classifies, and renames accounting documents (invoices, expense reports, bank statements, contracts) into a per-client / year / month folder tree.\n\n## What it does\n\nTriggered whenever a document arrives (email attachment, manual drop, bulk import), the skill runs a 10-step pipeline:\n\n1. Relevance pre-filter (skip non-accounting emails).\n2. File hash & deduplication.\n3. Client identification — cascade: sender email → domain → SIREN → fuzzy raison sociale → auto-create.\n4. Field extraction.\n5. French legal validation (mentions obligatoires, TVA, IBAN, dates).\n6. Categorization (`achat` / `vente` / `bank-statement` / `note-de-frais` / `contrat` / `autre`).\n7. Target path generation.\n8. Business-level duplicate detection.\n9. Final decision (`auto_classify` / `needs_review` / `ignore`).\n10. Indexing + accountant-facing report (business vocabulary only, no technical jargon).\n\n## Output tree\n\n```\nclients//contrats/__.\nclients////invoices/in/__.\nclients////invoices/out/__.\nclients////bank-statements/_.\nclients////notes-de-frais/___.\nclients////autres/_.\n```\n\n## Why French\n\nThe skill embeds French regulatory vocabulary (TVA, SIREN, KBis, URSSAF, mentions obligatoires from art. L441-9 Code de commerce) and produces output filenames in French convention. Translating would create awkward half-translations without expanding the actual audience (French accountants). `SKILL.md` and `references/*.md` are therefore in French; only this README and the frontmatter `description` are in English to fit the clawhub directory.\n\n## Companion skills\n\n- [`rapprochement-bancaire`](https://github.com/developers-trendex/rapprochement-bancaire) — bank reconciliation; writes the `Statut paiement` column of `followup.md`.\n- `relances` *(planned)* — outgoing invoice reminders; writes `relances.md`.\n- `facturation` *(planned)* — outgoing invoice issuance; writes `followup.md`.\n\nAll four skills share the path/naming contract defined in [`references/structure-cible.md`](references/structure-cible.md) — this file is the source of truth.\n\n## Files\n\n| File | Purpose |\n| --------------------------------- | -------------------------------------------------------------------------- |\n| `SKILL.md` | Main skill definition (French) |\n| `references/structure-cible.md` | **Source of truth** for path conventions, naming, enums |\n| `references/contrat-io.md` | JSON I/O contract, alert enum, index schema |\n| `references/validation-fr.md` | French legal validation rules, extraction thresholds, duplicate rules |\n| `references/roadmap.md` | Tools, success criteria, roadmap v0.1 → v0.4, open questions |\n\n## License\n\nInternal — OpenClaw private use.\n\nFile v0.1.0:_meta.json\n\n{\n \"ownerId\": \"kn7ethsmh4zep86d7ew9wsns2x86jwhr\",\n \"slug\": \"organisation-documents\",\n \"version\": \"0.1.0\",\n \"publishedAt\": 1778591306796\n}\n\nFile v0.1.0:references/contrat-io.md\n\n# Référence — Contrat d'invocation & sources\n\n> Référence chargée à la demande par `organisation-documents`. Schémas JSON, sources acceptées, enum d'alertes, schéma de l'index.\n\n---\n\n## Sources acceptées\n\n| Source | Détection | Pré-traitement |\n| ------------------ | --------------------------------------------------------- | --------------------------------------------- |\n| Pièce jointe Gmail | Skill `gog` → push d'événement | Extraction de la PJ + métadonnées de l'e-mail |\n| Adresse AgentMail | Skill `agentmail` → webhook | Idem |\n| Lien Drive | URL `https://drive.google.com/file/d/...` dans un message | Téléchargement via `gog` |\n| Dépôt FS local | Surveillance `~/.openclaw/workspace/inbox/` | Lecture directe |\n| Upload manuel UI | API REST de l'agent | Idem |\n\n### Formats de fichiers\n\nPDF (texte ou scanné), JPG, PNG, HEIC, TIFF, e-mail `.eml` complet, Factur-X (PDF/A-3 + XML embarqué), UBL XML, CSV/OFX (relevés bancaires).\n\n### Métadonnées de l'e-mail (si applicable)\n\nAdresse expéditeur, sujet, date d'envoi, corps HTML. Utilisées pour deviner le client si non détectable depuis la pièce.\n\n---\n\n## Contrat JSON\n\n### Input\n\n```jsonc\n{\n \"email\": {\n // optionnel : absent si dépôt FS / upload manuel\n \"from\": \"compta@orange-pro.fr\",\n \"subject\": \"Facture F-2026-04-1287\",\n \"date\": \"2026-04-15T09:12:00Z\",\n \"body\": \"Bonjour, veuillez trouver ci-joint…\",\n \"messageId\": \"\",\n },\n \"attachments\": [\n {\n \"filename\": \"facture_orange_avril.pdf\",\n \"mimeType\": \"application/pdf\",\n \"path\": \"/var/lib/openclaw/inbox/staging/abc.pdf\",\n \"sizeBytes\": 184320,\n },\n ],\n \"source\": \"gmail|agentmail|drive|fs|upload\",\n \"mode\": \"draft|auto\", // override explicite ; sinon dérivé du calendrier post-onboarding\n \"clientHint\": \"acme-sa\", // optionnel : déjà connu par l'appelant (ex : reclassement)\n}\n```\n\n### Output\n\n```jsonc\n{\n \"status\": \"processed\",\n \"documents\": [\n {\n \"filename\": \"facture_orange_avril.pdf\",\n \"decision\": \"auto_classify|needs_review|ignore\",\n \"reason\": \"client identifié + extraction 0.92 + conforme\",\n \"client\": \"acme-sa\",\n \"categorie\": \"achat\", // enum : achat | vente | bank-statement | note-de-frais | contrat | autre\n \"cheminCible\": \"clients/acme-sa/2026/04/invoices/in/2026-04-15_OrangePro_348.50.pdf\",\n \"metadata\": {\n \"emetteur\": \"Orange Pro\",\n \"destinataire\": \"ACME SA\", // optionnel : peuplé pour categorie = vente\n \"numeroFacture\": \"F-2026-04-1287\",\n \"dateEmission\": \"2026-04-15\",\n \"montantTTC\": 348.5,\n },\n \"confidence\": 0.92, // 0–1, agrégat OCR + matching client\n \"alerts\": [],\n },\n ],\n \"alerts\": [], // alertes batch-level\n}\n```\n\n---\n\n## Enum `alerts[]`\n\nValeurs possibles (par document ou batch-level) :\n\n- `email_non_pertinent` — pas de PJ ET pas de mots-clés comptables → ignoré dès le pré-filtre\n- `client_inconnu` — aucune correspondance dans `clients.json`\n- `extraction_incomplete` — un ou plusieurs champs obligatoires manquants\n- `low_confidence_extraction` — `confidence < 0.7`\n- `siren_client_manquant` — facture B2B post-2026-09-01 sans SIREN destinataire\n- `tva_incoherente` — `HT × taux ≠ TVA` au-delà de la tolérance\n- `duplicate_fichier` — hash identique déjà indexé\n- `duplicate_metier` — même `numeroFacture` + `emetteur` + `montantTTC`\n- `duplicate_probable` — même `emetteur` + `montantTTC` + écart date < 7j\n- `mention_obligatoire_manquante` — au moins une mention légale FR absente\n- `iban_invalide` — IBAN présent mais mod 97 KO\n- `montant_aberrant` — TTC ≠ HT + TVA hors tolérance\n- `date_future` — date d'émission postérieure à aujourd'hui\n- `multi_clients_possibles` — plusieurs candidats clients à confiance proche\n\n---\n\n## Schéma d'une entrée d'index\n\nIndex par client (`~/.openclaw/workspace/clients//index.json`) et global (`~/.openclaw/workspace/index-global.json`).\n\n```jsonc\n{\n \"id\": \"uuid\",\n \"hashFichier\": \"sha256:...\",\n \"clientId\": \"acme-sa\",\n \"categorie\": \"achat\", // enum : achat | vente | bank-statement | note-de-frais | contrat | autre\n \"emetteur\": \"Orange Pro\",\n \"sirenEmetteur\": \"380129866\",\n \"destinataire\": \"ACME SA\", // optionnel : peuplé pour categorie = vente | note-de-frais\n \"numeroFacture\": \"F-2026-04-1287\",\n \"dateEmission\": \"2026-04-15\",\n \"montantHT\": 290.42,\n \"tva\": [{ \"taux\": 20, \"montant\": 58.08 }],\n \"montantTTC\": 348.5,\n \"cheminDrive\": \"clients/acme-sa/2026/04/invoices/in/2026-04-15_OrangePro_348.50.pdf\",\n \"cheminLocal\": \"/var/lib/openclaw/.../clients/acme-sa/2026/04/invoices/in/...\",\n \"statutConformite\": \"conforme\",\n \"manquements\": [],\n \"modeTraitement\": \"auto-validé\",\n \"validePar\": null,\n \"dateClassement\": \"2026-04-28T14:23:11Z\",\n \"sourceReception\": \"gmail|agentmail|drive|fs|upload\",\n \"messageIdSource\": \"...\",\n}\n```\n\nFile v0.1.0:references/roadmap.md\n\n# Référence — Tools, critères de succès, roadmap, questions ouvertes\n\n> Référence chargée à la demande. Pas nécessaire à l'exécution courante du skill.\n\n---\n\n## Tools (sous-skills appelés)\n\n| Tool | Skill source | Rôle |\n| ---------------------------- | ------------------- | ---------------------------------------- |\n| `nano_pdf.extract` | `nano-pdf` | OCR + extraction structurée des champs |\n| `gog.drive.upload` | `gog` | Dépôt du fichier au chemin cible |\n| `gog.drive.search` | `gog` | Vérification existence fichier |\n| `gog.gmail.fetch_attachment` | `gog` | Récupération PJ depuis un message Gmail |\n| `agentmail.fetch_message` | `agentmail` | Idem côté AgentMail |\n| `factures_doublons.check` | `factures-doublons` | Test de doublons logiques |\n| `taskflow.schedule` | `taskflow` | Replanification si extraction incertaine |\n| `1password.read` | `1password` | Récupération des creds Drive si besoin |\n\n---\n\n## Critères de succès (à mesurer)\n\n- **Taux de classement automatique** ≥ 85 % après 30 jours (hors documents non conformes / non attribuables).\n- **Taux de doublon manqué** = 0 % (doublons certains détectés à 100 %).\n- **Taux de mauvais classement** ≤ 2 % (correction manuelle par le comptable).\n- **Délai de classement** < 60 s entre réception e-mail et fichier classé.\n\n→ Métriques exposées par le skill via une commande `organisation-documents.stats` consommable par le dashboard mensuel.\n\n---\n\n## Roadmap d'implémentation\n\n### v0.1 (MVP)\n\n- Réception Gmail + AgentMail.\n- Extraction `nano-pdf` (pas encore de Factur-X / UBL).\n- Identification client par e-mail expéditeur uniquement.\n- Classement `achat` / `vente` / `autre` dans la structure cible complète (`invoices/in`, `invoices/out`, `autres`).\n- Création des dossiers `bank-statements/`, `notes-de-frais/`, `contrats/` vides au moment où ils deviennent pertinents (pas pré-créés).\n- Lecture de `relances.md` / `followup.md` s'ils existent (pour rattacher paiements aux factures), pas d'écriture (hors scope).\n- Mode draft pur.\n\n### v0.2\n\n- Validation des mentions obligatoires + référentiel embarqué.\n- Détection client par SIREN et fuzzy raison sociale.\n- Bascule auto post-14 jours.\n- CSV consolidé.\n\n### v0.3\n\n- Support Factur-X (XML embarqué) + UBL.\n- Mapping catégorie → compte PCG.\n- Détection séquentialité numéros de facture (anti-fraude).\n- Détection automatique `bank-statement` et `contrat` (mots-clés + structure), au-delà de la simple cascade émetteur ∈ clients.\n\n### v0.4\n\n- Notes de frais (OCR de tickets photo, classement par collaborateur).\n- Relevés bancaires (CSV / OFX) → préparation rapprochement (`rapprochement-bancaire`).\n- Reclassement bulk (correction comptable propage à toutes les pièces similaires).\n\n---\n\n## Questions ouvertes\n\n1. **Reverse OCR sur les images natives** (ticket photo) : `nano-pdf` couvre-t-il, ou faut-il un fallback Tesseract local ?\n2. **Multi-cabinet sur un même container** : confirmé hors scope (cf. `context.md` Q3) — on suppose 1 user = 1 cabinet.\n3. **Migration existant** : si le comptable a déjà un Drive structuré différemment, on importe en l'état ou on re-classe ? → laisser le choix au comptable à l'onboarding.\n4. **Stockage local vs Drive** : doublure complète sur disque LXD pour requêtes rapides, ou tout dans Drive et cache opportuniste ? Impact perf vs coût stockage.\n5. **Format de l'index** : JSON suffit pour < 5 000 pièces / cabinet. Au-delà, basculer SQLite. Quel volume cible ?\n\nFile v0.1.0:references/structure-cible.md\n\n# Référence — Structure cible & conventions de nommage\n\n> Référence chargée à la demande par `organisation-documents`. Spec exhaustive du classement.\n> Source de vérité pour les autres skills qui écrivent dans le même arbre (`relances`, `facturation`, `rapprochement-bancaire`).\n\n---\n\n## Arborescence complète\n\n```\n~/.openclaw/workspace/\n├── clients/\n│ ├── / # un dossier = un client réel (existant ou auto-créé)\n│ │ ├── contrats/ # niveau client — contrats pluriannuels\n│ │ │ └── __.\n│ │ ├── /\n│ │ │ └── /\n│ │ │ ├── bank-statements/ # toujours un dossier (multi-comptes possibles)\n│ │ │ │ └── _.\n│ │ │ ├── invoices/\n│ │ │ │ ├── in/ # factures reçues (achats)\n│ │ │ │ │ └── _<Émetteur>_.\n│ │ │ │ └── out/ # factures émises (ventes)\n│ │ │ │ └── __.\n│ │ │ ├── notes-de-frais/\n│ │ │ │ └── __<Émetteur>_.\n│ │ │ ├── autres/\n│ │ │ │ └── _.\n│ │ │ ├── relances.md # maintenu par skill `relances`\n│ │ │ └── followup.md # maintenu par skill `facturation`\n│ │ ├── _archive-suppression/ # RGPD soft-delete (grâce 30 j)\n│ │ ├── index.json # index par client\n│ │ └── audit.log # déplacements / renommages\n│ └── index-global.json\n├── .pending-attribution/ # parking technique HORS clients/\n│ ├── _.\n│ └── pending-attribution.json\n└── clients.json\n```\n\n### Pas de slug réservé dans `clients/`\n\nTout dossier sous `clients/` correspond à un client réel — existant ou auto-créé en `draft-auto-created`. Aucune entité technique (`_cabinet`, `_non-attribue`, etc.) ne pollue cet arbre.\n\n### `.pending-attribution/`\n\nParking technique pour les documents que la cascade d'identification n'a pas su attribuer (expéditeur générique sans signal exploitable). Vit à la racine du workspace, **hors** `clients/`.\n\n| Élément | Rôle |\n| -------------------------------- | --------------------------------------------------------------------------------- |\n| `_.` | Le fichier physique, renommé pour la traçabilité (pas le filename d'origine) |\n| `pending-attribution.json` | Métadonnées extraites partielles + question à poser à l'utilisateur |\n\nUne fois la réponse utilisateur reçue (« rattacher à `acme-sa` » ou « créer client `nouveau-client` »), le fichier est **déplacé** vers son chemin cible définitif dans `clients//…` et l'entrée correspondante de `pending-attribution.json` est purgée.\n\n---\n\n## Mapping `categorie` → dossier\n\n| `categorie` | Dossier cible | Vocab comptable | Niveau |\n| ---------------- | ---------------------------------------- | ------------------ | -------- |\n| `achat` | `//invoices/in/` | Achats | mois |\n| `vente` | `//invoices/out/` | Ventes | mois |\n| `bank-statement` | `//bank-statements/` | Relevés bancaires | mois |\n| `note-de-frais` | `//notes-de-frais/` | Notes de frais | mois |\n| `contrat` | `contrats/` (racine `/`) | Contrats | client |\n| `autre` | `//autres/` | Autres | mois |\n\nL'enum machine est en kebab-case singulier (`achat`, pas `Achats`). Le vocab capitalisé pluriel est réservé aux **messages affichés au comptable** ; il n'apparaît jamais dans un chemin ni un payload.\n\n---\n\n## Conventions de nommage\n\n### Slug client\n\n- lowercase\n- accents retirés (`é` → `e`, `ç` → `c`, etc.)\n- espaces → `-`\n- caractères non alphanumériques → `-`\n- pas de `-` consécutifs, pas de `-` en début/fin\n- dérivé du **domaine** de l'expéditeur, pas de l'email (`trendex.tech` → `trendex-tech`)\n\n### Composants de nom de fichier\n\n| Token | Règle |\n| ---------------- | ------------------------------------------------------------------------------------------------------ |\n| `AAAA-MM-JJ` | `dateEmission` du document (ISO 8601), pas date de réception |\n| `AAAA-MM` | `dateEmission` tronquée au mois — utilisé pour les relevés bancaires (couvre généralement un mois) |\n| `Émetteur` | Raison sociale source, 10 premiers caractères significatifs, sans accents ni espaces (`Orange Pro` → `OrangePro`) |\n| `Destinataire` | Idem, pour les factures émises (`out/`) — c'est le client final du client du cabinet |\n| `Collaborateur` | Prénom ou prénom+initiale, sans accents (`Thomas`, `ThomasM`) |\n| `MontantTTC` | Sans séparateur de milliers, point décimal, sans symbole (`348.50`, pas `348,50 €`) |\n| `BanqueOuCompte` | Nom court de banque + suffixe compte optionnel (`BNP-courant`, `Qonto-pro`) |\n| `Type` (contrat) | `MSA`, `NDA`, `Bail`, `CDI`, `Avenant`, etc. — vocabulaire court figé |\n| `Contrepartie` | Slug ou raison sociale courte de l'autre partie au contrat |\n| `Description` | Slug court décrivant le document quand aucune catégorie ne s'applique (`Statuts`, `KBis`, `Procuration`) |\n\n### Séparateur\n\n`_` entre composants. `-` à l'intérieur d'un composant. Jamais d'espace.\n\n### Extension\n\nPréservée du document source en lowercase (`.pdf`, `.jpg`, `.png`, `.eml`, `.csv`, `.ofx`, `.xml`).\n\n---\n\n## Cas spéciaux\n\n### Multi-comptes bancaires\n\nUn client peut avoir plusieurs comptes (courant, livret pro, devises). `bank-statements/` est toujours un dossier, jamais un fichier unique :\n\n```\nclients/acme-sa/2026/04/bank-statements/\n├── 2026-04_BNP-courant.pdf\n├── 2026-04_BNP-livret-pro.pdf\n└── 2026-04_Qonto-usd.pdf\n```\n\n### Multi-pages relevé / cas hebdomadaires\n\nSi un relevé couvre plusieurs périodes ou est fragmenté, suffixer avec la plage :\n\n```\nclients/acme-sa/2026/04/bank-statements/2026-04-01_2026-04-15_BNP-courant.pdf\n```\n\n### Contrats pluriannuels\n\nLes contrats vivent à `/contrats/`, indexés sur la date de signature, pas la date de réception. Un avenant garde le même `` préfixé `Avenant-` :\n\n```\nclients/acme-sa/contrats/2024-01-15_MSA_TrendexTech.pdf\nclients/acme-sa/contrats/2026-03-01_Avenant-MSA_TrendexTech.pdf\n```\n\n### Notes de frais — toujours rattachées à un client\n\nUne note de frais appartient toujours à un client (celui dont l'employé doit être remboursé). L'émetteur du document est le commerçant (SNCF, restaurant…) ; le **bénéficiaire** — identifié dans le composant `` du nom — est l'employé d'un client.\n\n```\nclients////notes-de-frais/__<Émetteur>_.\n```\n\nLes frais perso de l'utilisateur lui-même **ne sont pas dans le scope** de ce skill. Si un document de ce type est détecté (typiquement : ticket envoyé depuis l'adresse perso de l'utilisateur, sans contexte client) → traité comme `non attribuable` → `.pending-attribution/`.\n\n### Documents non datables\n\nSi `dateEmission` est introuvable ET non déductible (carte de visite, capture d'écran, etc.) → date de réception en fallback, et alerte `extraction_incomplete`. Décision auto-rétrogradée à `needs_review`.\n\n### Reclassement (correction d'un mauvais classement)\n\nQuand le comptable corrige une attribution (mauvais client, mauvaise catégorie), le skill :\n\n1. Déplace le fichier vers le nouveau chemin (sans renommage si le nouveau nom est identique).\n2. Met à jour `index.json` des deux clients concernés (ancien + nouveau).\n3. Logue l'opération dans `audit.log` du nouveau client avec `motif: reclassement-manuel`.\n4. Ne touche jamais à `_archive-suppression/` (la suppression est un autre flux).\n\n---\n\n## `relances.md` — schéma\n\n> Maintenu par le skill `relances`. Lu par `organisation-documents` en cas de classement d'une réponse à relance.\n\nUn fichier par mois et par client : `clients////relances.md`.\n\n**Contenu** — un fichier = deux tableaux markdown :\n\n```markdown\n# Relances — — /\n\n> Maintenu par le skill `relances`. Toute modification manuelle est tolérée mais peut être écrasée à la prochaine exécution.\n\n## À envoyer\n\n| Date prévue | Facture | Destinataire | Montant TTC | Échéance dépassée | Canal | Type | Statut |\n| ----------- | ------------- | ------------ | ----------- | ----------------- | ----- | ------ | --------- |\n| 2026-05-15 | F-2026-04-012 | TrendexTech | 2 400,00 € | 15 j | email | R1 | planifiée |\n| 2026-05-30 | F-2026-04-012 | TrendexTech | 2 400,00 € | 30 j | email | R2 | planifiée |\n\n## Effectuées\n\n| Date envoi | Facture | Destinataire | Montant TTC | Canal | Type | Réponse client | Suite |\n| ---------- | ------------- | ------------ | ----------- | ------- | ---- | -------------- | ----------------- |\n| 2026-04-15 | F-2026-03-008 | ACME Corp | 1 248,00 € | email | R1 | promesse 15/05 | R2 planifié 30/05 |\n| 2026-04-30 | F-2026-03-005 | Foo SAS | 850,00 € | courrier | R3 | aucune | escalade huissier |\n```\n\n**Colonnes obligatoires** — toute autre colonne est facultative.\n\n**Règles d'écriture** :\n\n- Le skill `relances` est seul autorisé à modifier ces fichiers. `organisation-documents` les lit uniquement.\n- L'ordre des lignes dans `À envoyer` : chronologique croissant (la prochaine en haut).\n- L'ordre des lignes dans `Effectuées` : chronologique décroissant (la plus récente en haut).\n- Quand une relance planifiée est envoyée, le skill `relances` la migre de `À envoyer` vers `Effectuées` dans le fichier du mois courant (pas du mois de la facture).\n\n---\n\n## `followup.md` — schéma\n\n> Maintenu par le skill `facturation`. Lu par `organisation-documents` en cas de classement d'une facture entrante (paiement) ou sortante (émise).\n\nUn fichier par mois et par client : `clients////followup.md`.\n\n```markdown\n# Followup factures — — /\n\n> Maintenu par le skill `facturation`. Vue mois en cours.\n\n## À émettre\n\n| Date prévue | Destinataire | Description | Montant TTC prévu | Statut |\n| ----------- | ------------ | ------------------ | ----------------- | -------------- |\n| 2026-04-01 | TrendexTech | Forfait avril | 2 400,00 € | à préparer |\n| 2026-04-15 | ACME Corp | Prestation projet X | 5 800,00 € | brouillon prêt |\n\n## Émises ce mois\n\n| Date émission | N° facture | Destinataire | Montant TTC | Échéance | Statut paiement | Prochaine relance |\n| ------------- | ------------- | ------------ | ----------- | ---------- | --------------- | ----------------- |\n| 2026-04-01 | F-2026-04-012 | TrendexTech | 2 400,00 € | 2026-04-30 | non payée | R1 le 2026-05-15 |\n| 2026-04-15 | F-2026-04-013 | ACME Corp | 5 800,00 € | 2026-05-15 | partielle (50%) | suivi 2026-05-15 |\n| 2026-04-22 | F-2026-04-014 | Foo SAS | 720,00 € | 2026-05-22 | payée 2026-04-28 | — |\n```\n\n**Statut paiement** — enum : `non payée` | `partielle` | `payée` | `litige` | `irrécouvrable`.\n\n**Mise à jour automatique** — quand `organisation-documents` classe un relevé bancaire dans `bank-statements/`, il devrait théoriquement déclencher un rapprochement (`rapprochement-bancaire` skill) qui mettra à jour `followup.md` avec les paiements détectés. Hors scope de ce skill, mais le contrat de chemin est figé ici pour permettre l'intégration.\n\n---\n\n## Pourquoi cette structure\n\n| Décision | Alternative rejetée | Raison |\n| ------------------------------------------- | -------------------------------------------- | --------------------------------------------------------------------------------------- |\n| `//` (deux niveaux) | `/` (un niveau) | Conservation 10 ans = 120 dossiers à plat ingérables sur Drive/Finder |\n| `invoices/in` + `invoices/out` séparés | `invoices/` unique | TVA et PCG différents — un compta ne mélange jamais |\n| `contrats/` à la racine client | `contrats/` au mois | Contrats pluriannuels — les enterrer dans un mois rend la lecture impossible |\n| `bank-statements/` toujours un dossier | Fichier `bank-statement.pdf` direct | Multi-comptes très courant, dossier dès le départ évite la migration |\n| `relances.md` + `followup.md` au mois | Fichier rolling à la racine client | Le comptable raisonne par mois (clôtures) — état mensuel plus utile que log global |\n| Slug dérivé du domaine | Slug dérivé de l'email | 1 client = N employés = N emails — mais 1 dossier client |\n| Aucun slug réservé dans `clients/` | `_cabinet` + `_non-attribue` pseudo-clients | Un slug = un client réel. Le reste vit dans `.pending-attribution/` hors `clients/`. |\n| Auto-création par défaut | Toujours demander à l'utilisateur | Trop interruptif au quotidien. Confirmation opt-in via `clientCreation: \"confirm\"`. |\n| Enum `categorie` kebab-case singulier | Capitalisé pluriel | Aligné sur les noms de dossiers (`invoices/in` etc.) — pas de mismatch machine/affiché |\n\nFile v0.1.0:references/validation-fr.md\n\n# Référence — Extraction & validation comptable française\n\n> Référence chargée à la demande par `organisation-documents`. Détail des champs, des règles FR, des seuils, des doublons et des données embarquées.\n\n---\n\n## Champs cibles d'extraction\n\n| Champ | Format attendu | Obligatoire |\n| ------------------------ | ---------------------------------------------------- | -------------------------- |\n| `emetteur` | Raison sociale + SIREN si présent | ✅ |\n| `numeroFacture` | Chaîne libre (peut contenir préfixe / suffixe) | ✅ |\n| `dateEmission` | ISO 8601 (`YYYY-MM-DD`) | ✅ |\n| `dateEcheance` | ISO 8601 | ⚠️ recommandé |\n| `montantHT` | Décimal, devise | ✅ |\n| `tauxTVA` | Liste (multi-taux possible) | ✅ |\n| `montantTVA` | Décimal | ✅ |\n| `montantTTC` | Décimal | ✅ |\n| `iban` | Format normalisé (mod 97) | ⚠️ |\n| `bicSwift` | Format normalisé | ⚠️ |\n| `mentionAutoliquidation` | bool | ⚠️ si TVA = 0 |\n| `categorieOperation` | `biens` / `services` / `mixte` | ✅ depuis 2026-09-01 (B2B) |\n| `sirenClient` | Si destinataire = client du cabinet | ✅ depuis 2026-09-01 (B2B) |\n| `confidence` | Score 0–1 agrégeant OCR + matching champs canoniques | ✅ |\n\nSi plusieurs montants détectés (cas multi-pages, rappels), ne retenir que les valeurs présentes en zone « total » du document. Sinon, marquer `extraction-incertaine` et escalader.\n\n### Seuils sur `confidence`\n\n- `≥ 0.85` → éligible auto-classement (si autres conditions OK).\n- `0.70 – 0.85` → toujours en `needs_review`, même hors mode draft.\n- `< 0.70` → alerte `low_confidence_extraction`, escalade systématique.\n\n---\n\n## Validation des mentions obligatoires (FR)\n\nVérifier la conformité de la facture aux mentions légales françaises :\n\n- Présence des **3 mentions distinctes** : « description », « quantité », « prix unitaire ».\n- Numéro de facture **séquentiel** (warning si trou détecté dans la séquence pour le même émetteur).\n- Date d'émission présente et cohérente (≤ aujourd'hui, ≥ 1 an avant).\n- TVA cohérente (`HT × taux = TVA`, tolérance `±0.01`).\n- Si TVA = 0 → mention d'autoliquidation **ou** exonération **ou** franchise présente.\n- Depuis 2026-09-01 (B2B) : SIREN du client + catégorie d'opération obligatoires.\n- IBAN bien-formé (mod 97) si présent.\n\nRéférentiel embarqué : `assets/mentions-obligatoires.json` (structure inspirée de Paperasse `comptable/data/facturation/mentions-obligatoires.json`).\n\nSortie : score de conformité + liste des manquements. Si `manquements > 0`, le document est classé mais **flaggé** dans l'index (`statut-conformite: non-conforme`), avec notification au comptable.\n\n---\n\n## Catégorisation (nature du document)\n\nL'enum `categorie` est aligné sur les dossiers cibles (cf. `structure-cible.md`).\n\nDécision en cascade — première règle qui matche s'applique :\n\n| Indice | `categorie` | Dossier cible | Vocab comptable |\n| -------------------------------------------------------------------------------------------------------- | ---------------- | -------------------------- | ---------------- |\n| Document de type relevé (mots-clés : « relevé », « extrait de compte », IBAN en en-tête sans n° facture) | `bank-statement` | `//bank-statements/` | Relevés bancaires |\n| Contrat (mots-clés : « contrat », « avenant », pas de montant TTC en clair) | `contrat` | `contrats/` (racine client) | Contrats |\n| Émetteur = personne physique du cabinet ou d'un client | `note-de-frais` | `//notes-de-frais/` | Notes de frais |\n| `emetteur` ∈ clients du cabinet (le client a émis la facture à l'un de ses propres clients) | `vente` | `//invoices/out/` | Ventes |\n| `emetteur` ∉ clients ET le client est destinataire | `achat` | `//invoices/in/` | Achats |\n| Aucune correspondance | `autre` | `//autres/` | Autres |\n\n**Ordre important** : `bank-statement` et `contrat` sont testés AVANT `vente`/`achat` car ils peuvent être émis par un client du cabinet sans être pour autant une vente (un relevé BNP avec émetteur = client ne doit pas atterrir dans `invoices/out/`).\n\n**Précision `note-de-frais`** : l'émetteur du document est le commerçant (SNCF, restaurant…) ; ce qui qualifie en note de frais c'est le **bénéficiaire** (l'employé qui se fait rembourser) ou le contexte de réception (mail d'un collaborateur d'un client). Le slug du dossier est toujours celui du **client** qui emploie le bénéficiaire. Pour les frais perso de l'utilisateur lui-même → escalade vers `.pending-attribution/` (hors scope du skill).\n\n---\n\n## Détection de doublons\n\nAu-delà du hash fichier (étape 1 du workflow principal), vérifier les doublons **logiques** dans l'index du client cible :\n\n| Test | Verdict | Action |\n| ---------------------------------------------------------- | --------------------------------- | --------------------------------- |\n| Même `numeroFacture` + même `emetteur` + même `montantTTC` | `doublon-certain` | Skip classement, log au comptable |\n| Même `emetteur` + même `montantTTC` + écart date < 7j | `doublon-probable` | Classer mais flagger pour revue |\n| Même hash fichier | `doublon-fichier` | Stop avant traitement |\n| Tolérance arrondi : `abs(TTC1 - TTC2) < 0.01` | (s'applique aux 2 premiers tests) | — |\n\n→ Réutilise la logique du skill `factures-doublons` quand il sera buildé. Pour l'instant, implémentation locale.\n\n---\n\n## Données embarquées\n\nDans `assets/` du skill :\n\n- `mentions-obligatoires.json` — règles de conformité FR (référentiel inspiré de Paperasse, à versionner avec dates de validité).\n- `pcg-2026.json` — Plan Comptable Général (utile pour mapping catégorie → compte PCG dans une v0.2).\n- `tva-taux-fr.json` — taux de TVA en vigueur (5,5 / 10 / 20 / 0 / autoliquidation).\n- `regex-siren-iban-tva-intra.json` — patterns d'extraction réutilisables.","readmeExcerpt":"Skill: Organisation Documents Owner: trendex Summary: Skill central de l'assistant comptable. Réceptionne, classe et nomme automatiquement les documents comptables (factures, relevés bancaires) par client / anné... Tags: latest:0.2.0 Version history: v0.2.0 | 2026-05-13T12:07:50.633Z | user Migration vers pipeline déterministe script-driven : scripts/main.py + extract.py, onboarding 2-étapes pour expéditeurs ambigus,","codeSnippets":[],"executableExamples":[{"language":"bash","snippet":"python3 scripts/main.py "},{"language":"bash","snippet":"python3 scripts/main.py []\n# racine_clients par défaut : ~/.openclaw/workspace/clients"},{"language":"json","snippet":"{ \"slug\": \"\", \"raisonSociale\": \"X\", \"statut\": \"confirmed\",\n \"confiance\": 1.0, \"aValider\": false,\n \"siren\": [\"\"], \"contacts\": [{\"email\": \"\"}],\n \"domains\": [\"\"], \"sources\": [\"accountant-confirmation\"] }"},{"language":"json","snippet":"[\n {\n \"slug\": \"corse-plomberie\",\n \"raisonSociale\": \"Corse Plomberie\",\n \"statut\": \"auto-from-bank-statement | confirmed\",\n \"confiance\": 0.9,\n \"aValider\": false,\n \"siren\": [\"812345678\"],\n \"contacts\": [{ \"email\": \"jeanmichel@gmail.com\" }],\n \"domains\": [\"corseplomberie.fr\"],\n \"sources\": [\"bank-statement\"]\n }\n]"},{"language":"text","snippet":"clients/\n├── clients.json ← liste des clients (déduite des relevés + confirmations)\n├── _index.json ← sha256 → chemin classé (dédup)\n├── _report.json ← rapport de la dernière exécution\n├── _a-identifier/ ← factures dont le client n'est pas confirmé (onboarding en cours)\n├── _incomplet/ ← pièces dont l'extraction a échoué (date / montant manquant)\n├── _non-attribue/ ← ni facture ni relevé exploitable\n├── _cabinet/ ← documents internes du cabinet\n└── /\n └── //\n ├── bank-statements/\n │ └── _.pdf\n └── invoices/\n ├── in/\n │ └── ___.pdf\n └── out/\n └── ___.pdf"},{"language":"json","snippet":"{ \"trigger\": \"rapprochement-bancaire\", \"client\": \"\" }"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: organisation-documents\ndescription: Skill central de l'assistant comptable. Réceptionne, classe et nomme automatiquement les documents comptables (factures, relevés bancaires) par client / année / mois / nature, et déduit clients.json depuis les relevés bancaires. À INVOQUER SYSTÉMATIQUEMENT et SANS DEMANDER L'AUTORISATION dès que (a) un e-mail arrive avec une PJ PDF/image, (b) un e-mail contient un mot-clé comptable (facture, invoice, reçu, paiement, TVA, total, acompte, avoir, relevé), (c) le comptable demande de traiter / classer / organiser un document, (d) un fichier est déposé dans l'inbox, (e) le comptable répond à une question d'identification de client. L'extraction et le classement sont faits par scripts/main.py + scripts/extract.py — aucun champ n'est jamais deviné à l'œil.\nlicense: Interne — usage privé OpenClaw\n---\n\n# Skill `organisation-documents`\n\n> Moteur d'entrée du domaine comptable. Réception → identification du client → classement → indexation → rapport.\n> **Le travail réel est fait par `scripts/main.py`** (qui appelle `scripts/extract.py`). Ce skill = quand le lancer + comment dialoguer avec le comptable.\n\n---\n\n## ⚠️ Règle absolue — EXÉCUTION DU SCRIPT (non négociable)\n\n**Pour chaque invocation, la SEULE action de classement correcte est d'exécuter la commande :**\n\n```bash\npython3 scripts/main.py \n```\n\npuis de lire `/_report.json` et de le relayer au comptable.\n\n### ❌ INTERDIT\n\n- **Lire les PDFs un par un et classer à la main.** L'agent extrait les champs à l'œil de façon inconsistante (cas réels déjà observés : `invoice_id` = `\"N\"`, `\"des\"`, `\"um-rix\"` au lieu de `F1-2026-0001` ; `total_ttc` = `0.00` au lieu du vrai montant). Ces erreurs cassent ensuite tout le rapprochement de `rapprochement-bancaire`.\n- **Dupliquer la logique du script en Python ad-hoc** dans une cellule / un sous-process inline. Le script EST la logique, il est déterministe, déjà testé. Le réimplémenter à chaque invocation est garanti de diverger.\n- **Créer ou déplacer des fichiers dans `/` à la main** (move, copy, write). C'est le script qui le fait.\n- **Inventer un `invoice_id`** quand le PDF n'en contient pas de lisible. Si `extract.py` ne le trouve pas, le script écrit `SANS-NUM` ; n'essaie PAS de fabriquer mieux à partir du nom de l'émetteur ou de la description.\n\n### ✅ OBLIGATOIRE\n\n1. Exécuter la commande shell ci-dessus (et UNIQUEMENT ça pour la partie classement).\n2. Lire le `_report.json` produit.\n3. Relayer au comptable un résumé court + les questions d'onboarding si la section `questions` n'est pas vide.\n\n### Si le script échoue\n\nSignale l'erreur exacte (stderr) au comptable. **NE PAS** \"rattraper\" en classant manuellement — c'est précisément ce qui produit les filenames cassés. Si le binaire `pdftotext` manque (`poppler-utils` non installé), demande-le et stoppe.\n\n> Pourquoi cette règle est aussi stricte : on a déjà eu plusieurs runs où l'agent a improvisé le classement "},{"path":"README.md","content":"# organisation-documents\n\n> Claude skill for **French accounting firms** (`cabinets comptables`). Receives accounting documents (invoices, bank statements), identifies the client of the firm by reading bank statements, and classifies each PDF into a per-client / year / month folder tree. Deterministic script-driven — never guesses.\n\n## What it does\n\nFor each invocation, the skill runs **one command** :\n\n```bash\npython3 scripts/main.py \n```\n\nThat script:\n\n1. **Deduplicates** files by SHA-256 (already-classified docs are skipped, listed in `_index.json`).\n2. **Extracts** each PDF with `scripts/extract.py` (`pdftotext -layout` + deterministic regexes — no LLM-eyeballing).\n3. **Phase 1 — bank statements first.** The account holder shown on the statement header **is** the client of the firm (unambiguous). For each statement, create/complete the `clients.json` entry and file the statement into `///bank-statements/`.\n4. **Phase 2 — invoices.** Compare emitter and recipient (extracted from the PDF) against `clients.json`. One side matches a known client → that's the firm's client ; emitter ≈ client → `invoices/out/`, recipient ≈ client → `invoices/in/`.\n5. **Phase 3 — others** : files that are neither invoices nor bank statements → `_non-attribue/`.\n6. Writes `clients/clients.json`, `clients/_index.json`, `clients/_report.json`, and prints a short summary.\n\nThe agent's job is then only to **read `_report.json` and relay it to the accountant in plain French** — including any onboarding question when the client of a new invoice is ambiguous.\n\n## Onboarding for ambiguous senders (the \"Corse Plomberie\" case)\n\nAn invoice always carries two companies. When neither is yet in `clients.json` and no bank statement covers them, the script does not guess :\n\n1. **Step 1** — the document lands in `clients/_a-identifier/` and a question is added to `_report.json → questions` :\n > « Document : facture `TUYO-2024-087` (348,50 € TTC). Émetteur « TUYO SARL », destinataire « Corse Plomberie ». Lequel est votre client ? »\n2. **Step 2** — when the accountant answers « it's Corse Plomberie », the agent adds the mapping to `clients.json` (`contacts[].email = `) and re-runs the script on `_a-identifier/`. The piece gets filed correctly, in the right direction (in/out). **The question is never asked again** for that sender.\n\n## Output tree\n\n```\nclients/\n├── clients.json ← clients of the firm (auto-derived from bank statements + accountant confirmations)\n├── _index.json ← sha256 → classified path (dedup)\n├── _report.json ← last-run report (questions, incomplete, classified, ignored)\n├── _a-identifier/ ← pieces awaiting accountant disambiguation\n├── _incomplet/ ← extraction-incomplete pieces (date or TTC missing)\n├── _non-attribue/ ← non-accounting documents\n└── /\n └── //\n ├── bank-statements/ Référence chargée à la demande par `organisation-documents`. Schémas JSON, sources acceptées, enum d'alertes, schéma de l'index.\n\n---\n\n## Sources acceptées\n\n| Source | Détection | Pré-traitement |\n| ------------------ | --------------------------------------------------------- | --------------------------------------------- |\n| Pièce jointe Gmail | Skill `gog` → push d'événement | Extraction de la PJ + métadonnées de l'e-mail |\n| Adresse AgentMail | Skill `agentmail` → webhook | Idem |\n| Lien Drive | URL `https://drive.google.com/file/d/...` dans un message | Téléchargement via `gog` |\n| Dépôt FS local | Surveillance `~/.openclaw/workspace/inbox/` | Lecture directe |\n| Upload manuel UI | API REST de l'agent | Idem |\n\n### Formats de fichiers\n\nPDF (texte ou scanné), JPG, PNG, HEIC, TIFF, e-mail `.eml` complet, Factur-X (PDF/A-3 + XML embarqué), UBL XML, CSV/OFX (relevés bancaires).\n\n### Métadonnées de l'e-mail (si applicable)\n\nAdresse expéditeur, sujet, date d'envoi, corps HTML. Utilisées pour deviner le client si non détectable depuis la pièce.\n\n---\n\n## Contrat JSON\n\n### Input\n\n```jsonc\n{\n \"email\": {\n // optionnel : absent si dépôt FS / upload manuel\n \"from\": \"compta@orange-pro.fr\",\n \"subject\": \"Facture F-2026-04-1287\",\n \"date\": \"2026-04-15T09:12:00Z\",\n \"body\": \"Bonjour, veuillez trouver ci-joint…\",\n \"messageId\": \"\",\n },\n \"attachments\": [\n {\n \"filename\": \"facture_orange_avril.pdf\",\n \"mimeType\": \"application/pdf\",\n \"path\": \"/var/lib/openclaw/inbox/staging/abc.pdf\",\n \"sizeBytes\": 184320,\n },\n ],\n \"source\": \"gmail|agentmail|drive|fs|upload\",\n \"mode\": \"draft|auto\", // override explicite ; sinon dérivé du calendrier post-onboarding\n \"clientHint\": \"acme-sa\", // optionnel : déjà connu par l'appelant (ex : reclassement)\n}\n```\n\n### Output\n\n```jsonc\n{\n \"status\": \"processed\",\n \"documents\": [\n {\n \"filename\": \"facture_orange_avril.pdf\",\n \"decision\": \"auto_classify|needs_review|ignore\",\n \"reason\": \"client identifié + extraction 0.92 + conforme\",\n \"client\": \"acme-sa\",\n \"categorie\": \"achat\", // enum : achat | vente | bank-statement | note-de-frais | contrat | autre\n \"cheminCible\": \"clients/acme-sa/2026/04/invoices/in/2026-04-15_OrangePro_348.50.pdf\",\n \"metadata\": {\n \"emetteur\": \"Orange Pro\",\n \"destinataire\": \"ACME SA\", // optionnel : peuplé pour categorie = vente\n \"numeroFacture\": \"F-2026-04-1287\",\n \"dateEmission\": \"2026-04-15\",\n \"montantTTC\": 348.5,\n },\n \"confidence\": 0.92, // 0–1, agrégat OCR + matching client\n \"alerts\": []"},{"path":"references/reforme-facturation-2026.md","content":"# Réforme de la Facturation Électronique 2026\n\n## Textes de référence\n\n- Loi n° 2022-1726 du 30 décembre 2022 (loi de finances 2023)\n- Loi n° 2023-1322 du 29 décembre 2023 (report de calendrier)\n- Ordonnance n° 2021-1190 du 15 septembre 2021\n- Décret n° 2022-1299 du 7 octobre 2022\n- Article 289 bis du Code général des impôts\n\n## Calendrier\n\n### Phase 1 : 1er septembre 2026\n\n| Obligation | Qui |\n|-----------|-----|\n| **Réception** de factures électroniques | **Toutes** les entreprises assujetties TVA |\n| **Émission** de factures électroniques | Grandes entreprises (GE) et ETI |\n| **E-reporting** | GE et ETI |\n\n### Phase 2 : 1er septembre 2027\n\n| Obligation | Qui |\n|-----------|-----|\n| **Émission** de factures électroniques | PME et micro-entreprises |\n| **E-reporting** | PME et micro-entreprises |\n\n### Déterminer la taille de l'entreprise\n\nCritères cumulatifs (2 sur 3 dépassés pendant 2 exercices consécutifs) :\n\n| Catégorie | Effectif | CA (HT) | Total bilan |\n|-----------|----------|---------|-------------|\n| Micro-entreprise | < 10 | < 900 000 EUR | < 450 000 EUR |\n| PME | < 250 | < 50 M EUR | < 43 M EUR |\n| ETI | < 5 000 | < 1 500 M EUR | < 2 000 M EUR |\n| Grande entreprise | >= 5 000 | >= 1 500 M EUR | >= 2 000 M EUR |\n\n**En pratique** : la grande majorité des utilisateurs de Paperasse sont des TPE/PME/micro. Échéance émission = **1er septembre 2027**. Échéance réception = **1er septembre 2026**.\n\n## Qui est concerné\n\n**Toutes les entreprises assujetties à la TVA établies en France**, y compris :\n- Les entreprises en **franchise en base de TVA** (art. 293 B du CGI) : elles sont assujetties, elles ne collectent simplement pas\n- Les auto-entrepreneurs\n- Les entreprises individuelles\n- Les sociétés (SASU, SAS, SARL, EURL, SA, SCI, etc.)\n\n### Opérations concernées\n\n- Livraisons de biens entre assujettis en France\n- Prestations de services entre assujettis en France\n- Acomptes liés à ces opérations\n\n### Opérations exclues\n\n- Prestations de santé (art. 261, 4° du CGI)\n- Enseignement (art. 261, 4° du CGI)\n- Opérations immobilières exonérées\n- Opérations bancaires et d'assurance (art. 261 C du CGI)\n- Activités associatives exonérées\n\n### Territoires concernés\n\n| Territoire | TVA applicable | E-facturation |\n|-----------|---------------|---------------|\n| France métropolitaine | Oui | Oui |\n| Guadeloupe, Martinique, Réunion | Oui (taux spécifiques) | Oui |\n| Guyane, Mayotte | Non | Non |\n| Saint-Pierre-et-Miquelon, Saint-Barthélemy, Saint-Martin | Non | Non |\n| Nouvelle-Calédonie, Polynésie française | Non | Non |\n\n## Architecture du système\n\n### Les trois acteurs\n\n```\nEntreprise A ──→ PA émettrice ──→ PA réceptrice ──→ Entreprise B\n │ │\n └──────┬───────────┘\n ▼\n PPF (annuaire +\n concentrateur)\n │\n ▼\n DGFiP\n```\n\n### Portail Public de Facturation "}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Skill central de l'assistant comptable. Réceptionne, classe et nomme automatiquement les documents comptables (factures, relevés bancaires) par client / anné... Skill: Organisation Documents Owner: trendex Summary: Skill central de l'assistant comptable. Réceptionne, classe et nomme automatiquement les documents comptables (factures, relevés bancaires) par client / anné... Tags: latest:0.2.0 Version history: v0.2.0 | 2026-05-13T12:07:50.633Z | user Migration vers pipeline déterministe script-driven : scripts/main.py + extract.py, onboarding 2-étapes pour expéditeurs ambigus,","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1644,"uniquenessScore":57,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T02:27:21.438Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-10T02:27:21.438Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T07:39:28.947Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}