---
name: s12-documentary-evidence-validite
scenario: S12
description: Vérifier la validité réelle des justificatifs — distinguer "fichier attaché" (provided) de "document valide" (validity.valid)
tags: [payables, documentary-evidence, compliance, receipts, audit]
when_to_use: Quand un comptable ou auditeur veut identifier les dépenses avec des justificatifs non conformes ou manquants
risk: P1 — documentaryEvidenceStatus=provided signifie "fichier attaché", PAS "document conforme". Des documents peuvent être attachés mais invalides selon les règles de conformité.
---

# Instructions — Validité des justificatifs (documentary evidence)

## ⚠️ Distinction critique

| Filtre | Ce que ça signifie | Ce que ça ne signifie PAS |
|--------|-------------------|--------------------------|
| `documentaryEvidenceStatus=provided` | Un fichier est attaché | Que le document est valide ou conforme |
| `documentaryEvidenceStatus=providedAndDpr` | Fichier attaché + processing DPR | Que le document est valide |
| `documentaryEvidenceStatus=missing` | Aucun fichier attaché | |
| `documentaryEvidenceStatus=declaredAsInvalid` | Marqué invalide par l'utilisateur | |

**Pour la vraie validité** : lire `documentaryEvidence.validity.valid` (boolean) et `documentaryEvidence.compliances` sur chaque payable.

## Cas d'usage 1 — Identifier les dépenses sans justificatif

Appelle `get_payables` avec :
```json
{ "field": "documentaryEvidenceStatus", "operator": "=", "value": ["missing", "declaredAsInvalid"] }
```

→ Toutes les dépenses nécessitant un suivi justificatif.

## Cas d'usage 2 — Vérifier la conformité des justificatifs attachés

Étape 1 : Récupérer les payables avec justificatif attaché
```json
{ "field": "documentaryEvidenceStatus", "operator": "=", "value": ["provided", "providedAndDpr"] }
```

Étape 2 : Pour chaque payable, inspecter :
```
documentaryEvidence.validity.valid       → true/false
documentaryEvidence.compliances          → {} (vide) ou { règles de conformité }
documentaryEvidence.type                 → "invoice" | "creditNote" | ...
documentaryEvidence.invoiceNumber        → présent si facture
```

Étape 3 : Signaler les cas où `validity.valid=false` ou `compliances` contient des erreurs.

## Structure complète du champ documentaryEvidence

```json
{
  "validity": {
    "valid": true/false
  },
  "compliances": {
    // règles métier de conformité (peut être vide {}  sur comptes sans compliance stricte)
  },
  "type": "invoice" | "creditNote" | "other",
  "invoiceNumber": "XXXX",              // si type=invoice
  "creditNoteNumber": "XXXX",           // si type=creditNote
  "referenceInvoiceNumber": "XXXX"      // si avoir avec référence
}
```

## Cas d'usage 3 — Audit complet des justificatifs

Pour un audit exhaustif, combiner les deux recherches :

1. Sans justificatif : `status=["missing","declaredAsInvalid"]`
2. Avec justificatif potentiellement invalide : `status=["provided","providedAndDpr"]` + filtrer sur `validity.valid=false` côté client

Afficher :
- % de payables avec justificatif valide
- Liste des cas problématiques (sans justificatif + avec justificatif invalide)
- Priorité aux montants élevés

## Note sur le compte démo

Sur le compte de démonstration Spendesk, tous les justificatifs `provided` ont `validity.valid=true` et `compliances={}`. En production avec des règles de conformité activées, `compliances` peut contenir des erreurs de validation (TVA manquante, date invalide, montant non lisible, etc.).

## Exemple de prompt

- "Quelles dépenses n'ont pas de justificatif ?" → filter status=missing
- "Y a-t-il des justificatifs joints mais non conformes ?" → provided + validity.valid=false
- "Audit des reçus manquants avant clôture" → missing + declaredAsInvalid