Prévoir les décaissements fournisseurs à 90 jours

# Prévision des décaissements fournisseurs à 90 jours

## But

Estimer les sorties de cash à venir à partir des factures fournisseurs encore à payer, par horizon : en retard, sous 30 jours, 31 à 60 jours, 61 à 90 jours. Puis comparer l'échéance la plus proche au disponible du wallet.

**Ce que la prévision ne contient pas** : les factures pas encore reçues ou encore en attente d'approbation, les dépenses carte à venir, les abonnements futurs, et tout ce qui ne passe pas par Spendesk (salaires, loyers). C'est un plancher, pas une prévision de trésorerie complète : le dire dans le rapport.

Annoncer la date du jour et les bornes exactes de chaque horizon avant les appels.

## Étape 1 — En retard et total à venir

```json
{ "tool": "spendesk_get_due_invoices", "params": { "includeUpcoming": true, "includeLineItems": false } }
```

- `summary.totalOverdueAmount` : ce qui aurait déjà dû être payé.
- `data.upcoming` : **toutes** les factures impayées à échéance future, sans limite d'horizon. Ce n'est pas le chiffre « à 90 jours » ; il sert de contrôle pour les étapes suivantes.

## Étape 2 — Répartir par horizon

Un appel sur les 90 prochains jours :

```json
{
  "tool": "get_payables",
  "params": { "filters": { "operator": "and", "subfilters": [
    { "field": "paymentStatus", "operator": "=", "value": ["toPay"] },
    { "field": "payableType", "operator": "=", "value": ["invoicePurchase"] },
    { "field": "dueDate", "operator": "between", "value": { "from": "2026-10-05T00:00:00.000Z", "to": "2027-01-03T23:59:59.999Z" } }
  ] } }
}
```

Classer chaque facture selon son `dueDate` : 0-30, 31-60, 61-90 jours. Additionner `outstandingFunctionalAmount`, le reste à payer en devise fonctionnelle — pas `amount`, qui est le montant total même si la facture est déjà payée en partie. Paginer avec `cursor`.

La valeur du statut est `toPay` ; il n'existe pas de valeur `approved` ou `unpaid`. Le champ de statut comptable s'appelle `bookkeepingStatus` et ne sert pas ici.

## Étape 3 — Factures sans date d'échéance

```json
{
  "tool": "get_payables",
  "params": { "filters": { "operator": "and", "subfilters": [
    { "field": "paymentStatus", "operator": "=", "value": ["toPay"] },
    { "field": "payableType", "operator": "=", "value": ["invoicePurchase"] },
    { "field": "dueDate", "operator": "=", "value": null }
  ] } }
}
```

Les présenter sur une ligne à part. Ne pas leur inventer une échéance : si l'utilisateur veut une hypothèse (par exemple 30 jours après la date de facture), l'appliquer en l'annonçant.

## Étape 4 — Comparer au disponible

```json
{ "tool": "get_wallet_summary", "params": {} }
```

Comparer « en retard + 0-30 jours » à `totalAvailableAmount`, et nommer ce chiffre. Si `scheduledTransfersAmount.scheduledInvoicesAmount` est supérieur à zéro, ces factures sont déjà déduites du disponible : ne pas les compter deux fois.

## Rapport

```
Décaissements fournisseurs prévus — au <date du jour>

En retard          X EUR   (N factures)
0-30 jours         X EUR   (N)
31-60 jours        X EUR   (N)
61-90 jours        X EUR   (N)
Sans échéance      X EUR   (N)

Disponible wallet : X EUR — couvre / ne couvre pas « en retard + 0-30 jours »
Non inclus : factures non reçues ou non approuvées, cartes, abonnements, hors Spendesk
```

Tous les montants sont en devise fonctionnelle. Une société à la fois.

## Résultat observé (compte démo, 5 octobre 2026)

EUR 19 095,67 en retard sur 11 factures, rien à venir dans les 90 jours, et un disponible de EUR 97 300,29 : le retard est couvert cinq fois.

## Exemples de prompts
- "Quels sont nos décaissements fournisseurs prévus sur les 90 prochains jours ?"
- "Est-ce qu'on a assez dans le wallet pour couvrir les factures du mois prochain ?"
- "Combien de factures à payer n'ont pas de date d'échéance ?"