factory/vibe/PRD/ai-back-office/compliance.md

[vibe](../../README.md) > [PRD](../README.md) > [AI back-office](README.md) > **Compliance**

# Ledger compliance — operating to certified-accounting standards

> **Status:** In design
> **Last Updated:** 2026-07-11
> **Up:** [AI back-office hub](README.md)
> **Related:** [Agent architecture](agent-architecture.md) · [Task inventory](task-inventory.md) · [QA strategy](qa-strategy.md) · [Challenges](challenges.md)

Arcodange self-hosts Dolibarr, so it is not just a software *user* — it is the software *operator*, and the agent fleet is part of that software. This page maps the French bookkeeping obligations onto fleet mechanisms, and states the operating rule that makes the [sandbox-vs-production split](agent-architecture.md#environments--sandbox-vs-production) a compliance device: **the sandbox is exempt because it is disposable; production is bound because it is the ledger.**

> [!CAUTION]
> This page is engineering's reading of the law, not legal advice. Every mapping below feeds the expert-comptable checkpoint ([QA strategy](qa-strategy.md#fiscal-parity-checks)) before it is relied on.

## Obligations → fleet mechanisms

| Obligation | Source | How the fleet satisfies it |
| --- | --- | --- |
| **Inaltérabilité** — books kept without blanks or alteration; validated entries are immutable | Code de commerce L.123-22, PCG | The [ledger grammar](#the-ledger-grammar-production) below: corrections are *new documents* (avoirs, contre-passations), never edits; enforced by the promote-plan **compliance linter**, detected by snapshots ([T13](task-inventory.md#t13--erp-snapshot--drift-detection)) and, if enabled, Dolibarr's BlockedLog chain. |
| **FEC** — the fichier des écritures comptables must be producible in the normed format at any tax audit | LPF art. L.47 A / A.47 A-1 | Quarterly FEC export + validation with the DGFiP *Test Compta Demat* tool, folded into [T15](task-inventory.md#t15--monthly-coherence-audit). **Gap to close first:** the read skills bypass Dolibarr's double-entry accounting module — whether it is enabled and account-mapped (prerequisite for a clean FEC) is unverified. Verification runs on the sandbox ([checklist](#dolibarr-verifications-sandbox-first)). |
| **Piste d'audit fiable (PAF)** — documented, permanent controls linking invoice ↔ service ↔ payment | CGI art. 289 VII 1° | The fleet *is* the PAF: run journals, deterministic payment↔bank linkage by `transaction_id`, GED originals hash-addressed, monthly audit packs ([T15](task-inventory.md#t15--monthly-coherence-audit)). The PA lane (e-invoices) carries its own platform guarantees; the PAF remains load-bearing for everything outside it — notably the **KM export invoices**, which stay out of e-invoicing scope. |
| **Sequential numbering** of invoices | CGI art. 289 | Dolibarr owns the sequence (numbering masks); the linter rejects any manifest supplying a manual ref where Dolibarr must assign it; [T05](task-inventory.md#t05--client-invoice-issuance) guardrail. |
| **Retention** — 10 years commercial, 6 years fiscal | L.123-22 / LPF L.102 B | Daily backups with 10-year tiered retention, restore-tested ([T14](task-inventory.md#t14--backup--restore-verification)); GED attachment presence audited monthly. |
| **Copie fiable** for digitized paper originals | LPF A.102 B-2, arrêté 2017-03-22 | Mostly moot: sources are native PDFs/e-invoices. Any paper original is *kept* — the fleet never destroys paper; a copie-fiable process (PDF/A + fingerprint + timestamp) is deferred until paper volume justifies it. |
| **Permanence des méthodes** — rules and procedures applied consistently across exercices; departures justified | PCG art. 121-5 | The [ADC register](#accounting-decision-records-adc): every method choice is a record, immutable once Accepted — changes supersede with an impact note, never edit; `fiscal.yaml` rules cite their ADC; the annexe's « règles et méthodes » section is generated from the register. |
| **Accounting-organisation documentation** — a description of procedures and organisation sufficient to understand and control the processing system | PCG art. 911-3 | The agent-facing doc surface *is* it: AGENTS.md + SKILL.md + the atom registry + the ADC register + run journals — versioned in git, kept as long as the accounts they explain. |
| **Certified cash-register software** (inaltérabilité/sécurisation/conservation/archivage attested NF525 or editor certificate) | CGI art. 286-I-3° bis | **Not applicable today**: it binds *systèmes de caisse* (B2C payment recording); Arcodange is B2B-only. Dolibarr's **BlockedLog** module (chained, hash-linked event register — Dolibarr's answer to this law) is the cheap belt-and-braces anyway: evaluated on the sandbox first because enabling it is designed to be hard to undo. Re-scoped the day any B2C receipt appears. |

## The ledger grammar (production)

Production accepts **only append-shaped operations**:

- `thirdparty` create / complete (non-ledger fields);
- `invoice` (customer/supplier) create as draft → **validate** (the locking event);
- `payment` record (with `transaction_id`);
- `creditnote` (avoir) create — *the* correction primitive for anything already validated;
- GED attach (source documents).

Forbidden regardless of who asks: editing or deleting a validated document, renumbering, back-dating a validated entry, detaching a GED original. A correction is always a new document that references the old one.

**Enforcement is layered:** (1) the **compliance linter** in `promote-plan` — a manifest containing an op outside this grammar never reaches the Telegram approval card; (2) Dolibarr's own validation locking (+ BlockedLog if adopted); (3) detection — every promote is bracketed by snapshots ([T13](task-inventory.md#t13--erp-snapshot--drift-detection)), and a diff that is not pure-append is an incident ([QA strategy](qa-strategy.md#write-path-qa)).

The sandbox is deliberately **exempt**: rehearsals may create, mangle and wipe anything — its state is refreshed iso-prod on demand and never *is* the books. Exemption stops at the boundary: a manifest is linted against the production grammar **before** rehearsal, so the sandbox rehearses only what production would accept.

## Accounting decision records (ADC)

Software records its architectural choices in ADRs; accounting has the same need — **consistency you can justify** — but scatters it across instruments: the **permanence des méthodes** principle (PCG art. 121-5 — methods apply identically from one exercice to the next; departing requires justification), the **annexe** of the annual accounts (where règles et méthodes and any change of method are disclosed), the **organisation documentation** (PCG art. 911-3), and — in audit practice — the *accounting position memo* (one memo per significant judgment, kept for the auditor). None of these give a TPE a lightweight, versioned, per-decision artifact. The **ADC** (*décision comptable*) is that artifact: the house MADR-lite ADR discipline ([factory#22](https://gitea.arcodange.lab/arcodange-org/factory/issues/22)) plus the fields accounting demands.

**Home:** `fleet/profile/decisions/adc-NNN-<slug>.md` in the erp repo — next to `fiscal.yaml`, which the records justify (both are [erp#54](https://gitea.arcodange.lab/arcodange-org/erp/issues/54) deliverables).

**Format — MADR-lite + accounting fields:** Status (Proposed → Accepted → Superseded-by-NNN) · decided date + **`effective_from`/`effective_until`** (aligned with `fiscal.yaml` rules) · Context (the *fait générateur* — the transaction that forced a choice) · Decision · **Base légale & doctrine** (PCG / CGI / BOFiP / expert-comptable advice — the field tech ADRs don't need) · Alternatives rejected, with why · Consequences (accounts touched, annexe impact, downstream rules) · QA & validation (sandbox rehearsal, €-parity, expert review) · References (example écritures, issues).

**Four rules make it comptable:**

1. **Immutable once Accepted — supersede, never edit.** Permanence des méthodes made structural: a method change is a new ADC with an explicit impact note and an effective date (ideally an exercice boundary), never a silent drift.
2. **Every `fiscal.yaml` rule cites its ADC** (`decision: adc-NNN`). The machine-readable rule is the *what*; the ADC is the *why*. Run journals already cite the rule they applied, so the chain **écriture → règle → ADC → base légale** answers a vérificateur's « justifiez ce traitement » in four hops, identically every time ([challenges C6](challenges.md)).
3. **The annexe writes itself at close:** the « règles et méthodes » section is generated from the ADCs Accepted and in force during the exercice, plus any change of method with its impact note.
4. **Proposed ADCs are the expert-comptable agenda.** The periodic checkpoint reviews them; **acceptance is a human act**, journaled — an agent may draft an ADC (with sources), never Accept one.

**Seed register** — real decisions already made (to formalize) or pending (Proposed); first content of `fleet/profile/decisions/`:

| id | Decision | Status |
| --- | --- | --- |
| adc-001 | KM invoices under autoliquidation art. 259-1° CGI — no French VAT, CA3 box E2, invoice mention | to write — Accepted in practice since the first invoice |
| adc-002 | FX deltas on customer wires → 766/666 produits/charges financiers (payment recorded at invoice remaining; delta booked separately) | to write — applied in the 2026-07-11 regularization |
| adc-003 | AI/SaaS subscriptions expensed (6xx), never immobilized at current unit costs | to write — implicit today |
| adc-004 | Stay réel simplifié until the legal abolition; quarterly CA3 from 2027-01-01, no early opt-out | to write — Accepted in practice |
| adc-005 | Personal-card business expenses through the compte courant d'associé (455 lane) | to write — practiced; formalized with [erp#57](https://gitea.arcodange.lab/arcodange-org/erp/issues/57) |
| adc-006 | KM retainer currency & composition (USD multicurrency vs EUR-at-settlement; line structure) | **Proposed — blocks [erp#53](https://gitea.arcodange.lab/arcodange-org/erp/issues/53) wiring; operator input needed** |
| adc-007 | Capital-deposit entry path (1013; module compta vs paiement divers) | Proposed — awaits [erp#51](https://gitea.arcodange.lab/arcodange-org/erp/issues/51) findings |

## Dolibarr verifications (sandbox first)

Each of these runs on a fresh iso-prod checkpoint before any prod change; results land in [STATUS](STATUS.md):

1. **Accounting module state** — is double-entry accounting (`Comptabilité expert`) enabled, is the chart of accounts bound, are invoice/payment journals generated? If not, enabling + mapping it becomes a phase-5 chantier (prerequisite for FEC).
2. **FEC export** — produce it on the sandbox, validate with *Test Compta Demat*, file the report.
3. **Validation locking** — confirm a validated invoice rejects mutation through both UI and API paths with the write agent's permissions.
4. **BlockedLog trial** — enable on a sandbox checkpoint, exercise the invoice/payment flows, verify the chain, then **refresh the checkpoint** (the reversibility the module denies is exactly what the sandbox provides); decide adoption via a short ADR.
5. **Numbering masks** — confirm the customer/supplier sequences are gapless across a validate + avoir cycle.

## Questions for the expert-comptable

- FEC expectations for the first exercice (mid-January 2026 incorporation, close 2026-12-31) given the accounting-module timeline;
- whether adopting BlockedLog pre-emptively has any downside for a B2B-only SAS;
- confirmation that the PAF-by-architecture approach (journals + tx-id reconciliation + monthly packs) satisfies art. 289 VII documentation expectations for the export invoices;
- review of the seed [ADC register](#accounting-decision-records-adc): confirm adc-001…005 as written, arbitrate the two Proposed (adc-006 retainer currency/composition, adc-007 capital-entry path), and confirm the generated-annexe approach is acceptable for the first exercice.