Solution · Encaissement & rapprochement

Sachez ce qui est réglé. Agissez sur ce qui reste dû.

Reliez la facture, le paiement observé et son affectation. Les équipes voient ce qui est soldé, ce qui reste dû et si la suite demande une relance, une revue ou la résolution d’une véritable exception.

FACTUREFAC-10428 400 €
PAIEMENT OBSERVÉ5 000 €
AFFECTÉ À LA FACTURE5 000 €
Reste dû3 400 €

Paiement partiel · suivi

Rapprocher

Séparez l’observation du paiement de la manière dont il règle l’obligation

Un paiement est un fait financier observé ; une affectation explique comment ce montant est appliqué à une facture ou autre obligation. Les séparer permet de traiter paiements partiels, allocations multiples et calcul du solde restant.

Les extensions peuvent amener la preuve provider dans le parcours tandis que le modèle canonique de paiement et rapprochement reste stable pour les processus aval.

VIREMENT GROUPÉ3 500 €
01

Preuve de paiement

Un virement bancaire de 3 500 € arrive pour l’acheteur.

02

Affectation automatique

Ormuz rapproche le virement et un avoir de 500 € de deux factures de 2 000 €.

FACTUREFAC-10422 000 €
FACTUREFAC-10432 000 €
AVOIRAV-1043−500 €
ormuzAFFECTATION AUTOMATIQUE
FAC-10422 000 € du virementSoldée
FAC-10431 500 € du virement + 500 € d’avoirSoldée
03

Factures soldées

Les deux factures sont réglées et le virement est entièrement affecté, sans relance nécessaire.

3 500 € affectés · 0 € dû
Systèmes impliqués

Un même parcours, plusieurs autorités.

Le rôle d’Ormuz est de coordonner ces frontières, pas de les effacer.

ERPFacture
PAIEMENTFonds observés
ORMUZAffectation
COMMSCanal de relance
HUMAINException
Relancer
Utilisez le canal adapté à l’étape de recouvrement

La marketplace contient actuellement SMTP et Twilio pour les notifications, Maileva pour le courrier postal et AR24 pour les communications recommandées. Un processus peut escalader les canaux explicitement au lieu d’enfouir la logique dans le système de facturation.

Conséquence opérationnelle

Ce que cela change dans le parcours

Un véritable modèle de processus « Relance de paiement » est distribué dans le dépôt. Il utilise une configuration SMTP et constitue un point de départ à vérifier et personnaliser — pas la preuve que toute stratégie de recouvrement existe déjà sous forme de template.

Exceptions

Rendez les litiges et cas ambigus visibles au lieu de relancer aveuglément

Une relance en échec peut signaler une donnée manquante, une erreur provider, un règlement partiel ou un véritable litige commercial. Le processus peut distinguer ces états et router la prochaine action.

Traitez un litige dans une étape dédiée : réunissez les justificatifs, demandez une revue et reprenez le recouvrement selon son issue.

À mesurer pendant un pilote

Évaluez le changement sur votre opération réelle.

Choisissez les indicateurs utiles à votre activité et comparez-les avant et pendant votre pilote.

01

Part de paiements non affectés

Mesurez les encaissements observés qui n’ont pas encore d’affectation claire à une obligation.

02

Délai de résolution des exceptions

Suivez la durée des paiements partiels, écarts et litiges non résolus.

03

Part de suivi manuel

Mesurez les actions de recouvrement qui demandent encore une intervention opérateur.

Solution · Encaissement & rapprochement

Testez ce parcours avec vos systèmes, vos règles et vos exceptions.

Un pilote utile part du résultat métier à améliorer, puis mesure où l’expérience, l’automatisation et le contrôle changent réellement l’opération.