12Configuration ODESA

Le gestionnaire de relances

Détection quotidienne des impayés, préparation de relances graduées, validation humaine, puis envoi / saisie automatisés.

Besoin métier

Le recouvrement courant repose sur une discipline régulière que la charge quotidienne met à mal : extraire les factures échues, les classer par ancienneté, rédiger des relances au ton adapté, puis les envoyer ou les saisir dans un portail. Faute de temps, ce rituel est irrégulier, ce qui dégrade la trésorerie et la crédibilité des relances. L'objectif : automatiser tout ce qui est automatisable (détection, préparation, envoi) tout en conservant une validation humaine avant toute action engageante.

Comment ça fonctionne

1

interroge la base des créances pour lister les factures échues et leur ancienneté ;

2

classe chaque créance par niveau de relance (1er rappel, 2e rappel, mise en demeure) selon des règles d'ancienneté ;

3

prépare la relance correspondante (courrier / mail / saisie portail) à partir de modèles ;

4

présente la liste à l'humain pour validation (tout, partiel, exclusions, ajustements) ;

5

après validation, exécute : envoi de mails, dépôt de courriers (fichiers/COM), ou saisie dans le portail extranet (navigateur).

Capacités ODESA mobilisées

sql

Lecture (query) de la base des créances : factures échues, montants, ancienneté, niveau de relance déjà atteint. Éventuellement écriture (exec) pour tracer la relance émise.

ui (interaction humaine)

Présentation de la liste des relances proposées ; confirmation, exclusion, ajustement avant action. Capacité centrale de ce cas.

web (navigateur réel)

Saisie des relances dans un portail / extranet (profil SSO, allowlist du domaine).

fichiers (fs) / com

Génération de courriers (PDF, ou via Word COM), dépôt dans un dossier courrier.

planification VAILS

Déclenchement quotidien automatique du contrôle des impayés.

Déroulé type

1

VAILS (planification) : déclenche la tâche chaque matin à 8 h 30.

2

IA (sql) : « 14 factures échues : 9 à plus de 15 jours, 4 à plus de 45 jours, 1 à plus de 90 jours. »

3

IA : applique les règles → 9 premiers rappels, 4 deuxièmes rappels, 1 mise en demeure ; prépare les textes à partir des modèles.

4

IA (ui) à l'utilisateur : « Voici les 14 relances proposées. Valider tout / exclure des clients / ajuster un ton ? »

5

Utilisateur : « Exclus le client Durand (litige) et le client Petit (règlement en cours). Valide le reste. »

6

IA (web) : se connecte au portail via le profil SSO, saisit la mise en demeure du grand compte.

7

IA (fichiers/com) : dépose les 4 deuxièmes relances en PDF dans le dossier courrier ; envoie les 9 premiers rappels par mail.

8

IA (sql, optionnel) : trace dans la base le niveau de relance émis et la date.

9

IA : « 12 relances traitées, 2 exclues. Récapitulatif déposé. »

Données & accès
  • Base des créances : connexion SQL nommée vers l'ERP/comptabilité ou une vue dédiée (factures, échéances, montants, clients, niveau de relance courant).
  • Modèles de relance : fichiers de modèles (1er rappel, 2e rappel, mise en demeure).
  • Portail / extranet : URL(s) du portail de saisie, profil de session SSO si nécessaire.
  • Dossier courrier : répertoire de dépôt des PDF générés.
  • Canal d'envoi mail : selon l'environnement (COM Outlook, ou dépôt pour envoi).
Bornage & sécurité
  • sql : connexion nommée (ex. `compta`), `query` autorisé ; `exec` autorisé uniquement si la traçabilité des relances est souhaitée, et restreint à la table/vue de suivi.
  • ui : validation humaine obligatoire avant tout envoi ou saisie, c'est le garde-fou principal.
  • web : allowlist limitée au strict domaine du portail extranet ; profil SSO dédié ; aucune navigation hors périmètre.
  • fichiers : racine d'écriture limitée au dossier courrier.
  • com (si Word/Outlook) : ProgID explicitement autorisés uniquement.
  • Jeton Bearer exigé ; configuration chiffrable/verrouillable ; exécution locale.

Mise en place

Les étapes pour configurer ODESA sur ce cas d'usage.

1

Installer ODESA sur le poste comptable.

2

Déclarer la connexion à la base des créances (lecture, et écriture de suivi si voulue).

3

Définir les règles d'ancienneté → niveau de relance et raccorder les modèles.

4

Configurer le canal de sortie : allowlist du portail + profil SSO, et/ou dossier courrier + COM.

5

Activer la validation humaine (ui) comme étape obligatoire.

6

Programmer le déclenchement quotidien via VAILS.

7

Tester sur un petit lot, valider le rendu des relances, puis verrouiller la configuration.

Limites & points d'attention
  • Validation indispensable : la valeur du cas tient à l'étape humaine ; ne pas la court-circuiter pour « gagner du temps ».
  • Stabilité du portail : la saisie web dépend de la stabilité de l'interface cible ; un portail qui change de structure peut nécessiter un ajustement.
  • Qualité des données comptables : un statut de paiement non à jour peut générer une relance indue, d'où l'intérêt de la validation.
  • Litiges et cas particuliers : ils doivent rester sous décision humaine (exclusion manuelle).
  • Cadre légal : les mentions des mises en demeure relèvent de modèles validés par l'entreprise.
Évolutions possibles
  • Scoring de risque (VScript) : prioriser les relances selon le risque client.
  • Relances multicanal : mail + courrier + appel programmé selon l'enjeu.
  • Tableau de bord : suivi du recouvrement et de l'effet des relances dans le temps.
  • Synchronisation des paiements : exclusion automatique des factures réglées la veille avant préparation.

Mettez ODESA au travail.

ODESA installe l'IA agentique chez vos clients, en local et sous contrôle. Devenez le partenaire qui la déploie.

12ODESA configuration

The dunning manager

Daily detection of unpaid invoices, preparation of graduated reminders, human validation, then automated send / entry.

Business need

Routine collection relies on a regular discipline that the daily workload undermines: extract overdue invoices, sort by age, write reminders in a suitable tone, then send them or enter them in a portal. For lack of time, this ritual is irregular, which degrades cash flow and the credibility of reminders. The goal: automate everything that can be automated (detection, preparation, send) while keeping a human validation before any binding action.

How it works

1

queries the receivables database to list overdue invoices and their age;

2

classifies each receivable by reminder level (1st reminder, 2nd reminder, formal notice) per age rules;

3

prepares the corresponding reminder (letter / email / portal entry) from templates;

4

presents the list to the human for validation (all, partial, exclusions, adjustments);

5

after validation, executes: send emails, drop letters (files/COM), or enter into the extranet portal (browser).

ODESA capabilities used

sql

Read (query) the receivables database: overdue invoices, amounts, age, reminder level already reached. Optionally write (exec) to record the issued reminder.

ui (human interaction)

Present the list of proposed reminders; confirmation, exclusion, adjustment before action. Central capability of this case.

web (real browser)

Enter reminders in a portal / extranet (SSO profile, domain allowlist).

Files (fs) / com

Generate letters (PDF, or via Word COM), drop in a mail folder.

VAILS scheduling

Automatic daily trigger of the unpaid-invoice check.

Typical flow

1

VAILS (scheduling): triggers the task every morning at 8:30.

2

AI (sql): "14 overdue invoices: 9 over 15 days, 4 over 45 days, 1 over 90 days."

3

AI: applies the rules → 9 first reminders, 4 second reminders, 1 formal notice; prepares the texts from templates.

4

AI (ui) to the user: "Here are the 14 proposed reminders. Validate all / exclude clients / adjust a tone?"

5

User: "Exclude client Durand (dispute) and client Petit (payment in progress). Validate the rest."

6

AI (web): connects to the portal via the SSO profile, enters the large account's formal notice.

7

AI (files/com): drops the 4 second reminders as PDFs in the mail folder; sends the 9 first reminders by email.

8

AI (sql, optional): records in the database the issued reminder level and the date.

9

AI: "12 reminders handled, 2 excluded. Recap dropped."

Data & access
  • Receivables database: a named SQL connection to the ERP/accounting or a dedicated view (invoices, due dates, amounts, clients, current reminder level).
  • Reminder templates: template files (1st reminder, 2nd reminder, formal notice).
  • Portal / extranet: URL(s) of the entry portal, SSO session profile if needed.
  • Mail folder: directory to drop the generated PDFs.
  • Email channel: depending on the environment (Outlook COM, or drop for sending).
Scope & security
  • sql: a named connection (e.g. `accounting`), `query` allowed; `exec` allowed only if reminder traceability is wanted, and restricted to the tracking table/view.
  • ui: human validation mandatory before any send or entry, this is the main safeguard.
  • web: allowlist limited to the strict extranet-portal domain; dedicated SSO profile; no out-of-scope navigation.
  • files: write root limited to the mail folder.
  • com (if Word/Outlook): explicitly allowed ProgIDs only.
  • Bearer token required; configuration encryptable/lockable; local execution.

Setup

The steps to configure ODESA for this use case.

1

Install ODESA on the accounting workstation.

2

Declare the connection to the receivables database (read, and tracking write if wanted).

3

Define the age rules → reminder level and link the templates.

4

Configure the output channel: portal allowlist + SSO profile, and/or mail folder + COM.

5

Enable human validation (ui) as a mandatory step.

6

Schedule the daily trigger via VAILS.

7

Test on a small batch, validate the rendering of reminders, then lock the configuration.

Limits & caveats
  • Validation essential: the value of the case rests on the human step; do not short-circuit it to "save time".
  • Portal stability: web entry depends on the stability of the target interface; a portal that changes structure may require adjustment.
  • Accounting-data quality: a payment status not up to date can generate an undue reminder, hence the value of validation.
  • Disputes and special cases: they must stay under human decision (manual exclusion).
  • Legal framework: the wording of formal notices comes from templates validated by the company.
Possible extensions
  • Risk scoring (VScript): prioritise reminders by client risk.
  • Multichannel reminders: email + letter + scheduled call depending on stakes.
  • Dashboard: tracking of collection and the effect of reminders over time.
  • Payment sync: automatic exclusion of invoices paid the day before, ahead of preparation.

Put ODESA to work.

ODESA brings agentic AI to your clients, locally and under control. Become the partner who deploys it.