Votre modèle de données pour le traitement des paiements

ACI Worldwide
Votre modèle de données pour le traitement des paiements

Votre modèle de données pour le traitement des paiements

Ce modèle vous propose une méthode structurée pour préparer les données de traitement des paiements en vue de leur analyse. Il précise les attributs essentiels à recueillir, les activités importantes à suivre et les étapes pratiques pour extraire ces informations de votre système. En suivant ces recommandations, vous disposerez d’une base fiable pour repérer les inefficacités et optimiser vos opérations financières.
  • Attributs recommandés à recueillir
  • Activités clés à suivre
  • Conseils d’extraction pour ACI Worldwide
Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Attributs du traitement des paiements

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser le traitement des paiements de manière complète.
3 Obligatoire 9 Recommandé 7 Facultatif
Nom Description
Horodatage de l’événement
EventTimestamp
Date et heure précises auxquelles l’activité a eu lieu.
Description

Cet attribut enregistre le moment exact où un événement s’est produit dans l’environnement ACI. Il sert à calculer toutes les métriques temporelles, notamment les temps de cycle, les durées d’approbation et les cadences de traitement. Une précision élevée, à la milliseconde, est préférable pour ordonner correctement les étapes automatisées rapprochées.

Pourquoi est-ce important ?

Indispensable pour ordonner les événements et calculer les durées de traitement.

Où trouver ces données

Consultez les colonnes « Date de création » ou « Date de mise à jour » dans l’historique des transactions ou les tables d’audit.

Exemples
2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z
Identifiant de transaction du paiement
PaymentTransactionId
Identifiant unique de l’instruction de paiement concernée dans l’ensemble du système ACI.
Description

Cet attribut sert de clé centrale à l’analyse Process Mining et relie tous les événements associés à une même demande de paiement. Dans les systèmes ACI Worldwide, tels que MTS ou UPP, il correspond au numéro de référence unique attribué à une transaction lors de sa saisie. Il permet de reconstituer le parcours complet du paiement, de la demande initiale à la validation, à l’approbation et au règlement final.

Pourquoi est-ce important ?

Il s’agit de l’ID de cas indispensable pour regrouper les événements distincts en instances de processus.

Où trouver ces données

Consultez les tables d’en-tête des transactions, où le champ est souvent nommé TRN_REF, REFERENCE_NUM ou UUID dans le journal principal des transactions.

Exemples
TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981
Nom de l’activité
ActivityName
Étape précise ou changement de statut survenu au cours du cycle de vie du paiement.
Description

Cet attribut définit le nœud d’événement dans la cartographie du processus, par exemple « Demande de paiement créée » ou « Fonds transférés ». Dans les systèmes ACI, il est souvent dérivé des codes de statut, des types d’opération du journal d’audit ou des changements d’état du flux de travail. Pour obtenir une visualisation pertinente, il est essentiel d’associer correctement ces états techniques à des activités compréhensibles par les équipes métier.

Pourquoi est-ce important ?

Il définit le flux du processus et permet d’en visualiser l’enchaînement des opérations.

Où trouver ces données

Dérivé des codes de statut (par exemple, 100=Créé, 200=Validé) ou des colonnes d’action du journal d’audit.

Exemples
Demande de paiement crééePaiement autoriséPaiement régléPaiement échoué
Canal de traitement
ProcessingChannel
Canal par lequel le paiement a été initié.
Description

Indique le point d’entrée du paiement, par exemple une application mobile, un portail Web, une API ou l’importation d’un fichier. Cet attribut permet d’analyser les variantes du processus de paiement et de déterminer si certains canaux sont davantage sujets aux erreurs ou aux retards.

Pourquoi est-ce important ?

Permet de comparer les performances selon le mode de saisie.

Où trouver ces données

En-tête de transaction, souvent dans des colonnes nommées CHANNEL, SOURCE_TYPE ou INPUT_METHOD.

Exemples
SWIFTServices bancaires en ligneApplication mobileImportation de fichier
Code d’erreur
ErrorCode
Code généré lorsqu’un paiement échoue ou doit être corrigé.
Description

Indique la cause précise d’un événement « Paiement échoué » ou « Erreur de paiement détectée ». Le regroupement par cet attribut dans le Dashboard « Analyse des échecs et des reprises de paiement » permet à l’entreprise de repérer les causes profondes les plus fréquentes, par exemple « Fonds insuffisants » ou « Compte non valide ».

Pourquoi est-ce important ?

Indispensable à l’analyse des causes profondes des échecs du processus.

Où trouver ces données

Journaux d’erreurs ou colonnes indiquant le motif du statut, souvent nommées REASON_CODE ou RETURN_CODE.

Exemples
R01AM04BE05TECH_ERR_001
Date d’échéance du paiement
PaymentDueDate
Date à laquelle le paiement doit être réglé pour être considéré comme effectué dans les délais.
Description

Enregistre la date d’exécution prévue au contrat ou demandée. Cette date est comparée à la date réelle de règlement pour calculer le KPI « Taux de paiements à temps » et alimenter le Dashboard « Conformité aux dates d’échéance des paiements ».

Pourquoi est-ce important ?

Référence pour mesurer le respect des SLA et le taux de paiements effectués dans les délais.

Où trouver ces données

Instructions de transaction, généralement dans les champs VALUE_DATE, EXECUTION_DATE ou DUE_DATE.

Exemples
2023-11-012023-11-05
Devise du paiement
PaymentCurrency
Code ISO de la devise du montant du paiement.
Description

Précise la devise dans laquelle le montant du paiement (PaymentAmount) est exprimé, par exemple USD, EUR ou GBP. Cet attribut est indispensable pour normaliser les données des Dashboards qui agrègent les volumes de plusieurs régions. Il aide également à comprendre les spécificités des paiements transfrontaliers.

Pourquoi est-ce important ?

Nécessaire pour interpréter correctement le montant du paiement.

Où trouver ces données

Tables détaillées des transactions, avec des champs tels que CCY, CURRENCY_CODE ou ISO_CODE.

Exemples
USDEURGBPJPY
Montant du paiement
PaymentAmount
Valeur monétaire de la transaction de paiement.
Description

Indique la valeur financière transférée. Ce champ fournit un contexte essentiel pour analyser le « volume de paiements traités » et hiérarchiser les goulots d’étranglement. Les paiements de montant élevé suivent souvent des circuits d’approbation plus stricts, à analyser par variante, que les flux automatisés de faible montant.

Pourquoi est-ce important ?

Permet de segmenter les paiements par montant et de calculer le volume total traité.

Où trouver ces données

Tables détaillées des transactions, avec des champs tels que AMT, TRANS_AMOUNT ou PRINCIPAL_AMOUNT.

Exemples
1500.00250000.5050.001000000.00
Reprises effectuées
IsRework
Indicateur précisant si le paiement a donné lieu à des activités répétées.
Description

Indicateur booléen calculé lors du traitement des données. Il prend la valeur true si des activités telles que « Détails du paiement validés » se produisent plusieurs fois ou si une boucle d’erreur est détectée. Il sert à calculer le KPI « Taux de reprises des paiements ».

Pourquoi est-ce important ?

Permet de repérer rapidement les cas inefficaces sans requêtes complexes sur le processus.

Où trouver ces données

Calculé dans le pipeline de données en recherchant les activités en double pour chaque cas.

Exemples
truefalse
Service
Department
Service interne responsable de l’activité en cours.
Description

Associe l’utilisateur lié à l’événement (EventUser) ou la file d’attente à une unité organisationnelle plus large, par exemple les opérations de paiement, la conformité ou la trésorerie. L’« Analyse des goulots d’étranglement par activité » permet ainsi de repérer les équipes qui ralentissent le processus.

Pourquoi est-ce important ?

Regroupe les performances par fonction métier.

Où trouver ces données

Dérivé des tables d’utilisateurs ou de l’association à la hiérarchie organisationnelle.

Exemples
OpérationsComplianceTrésorerieAssistance informatique
Type de paiement
PaymentType
Classification de l’instrument de paiement.
Description

Classe le paiement par type, par exemple virement, ACH, SEPA ou RTGS. Les délais de service et les flux de processus varient souvent considérablement selon le type de paiement. Cet attribut constitue un axe principal de filtrage du Dashboard « Analyse du temps de cycle des paiements de bout en bout ».

Pourquoi est-ce important ?

Essentiel pour distinguer les paiements rapides des paiements traités par lots.

Où trouver ces données

En-tête de transaction, avec des champs tels que PMT_TYPE, INSTRUMENT_TYPE ou SERVICE_ID.

Exemples
Virement nationalVirement internationalCrédit ACHPaiement instantané
Utilisateur associé à l’événement
EventUser
Identifiant de l’utilisateur ou de l’agent système responsable de l’activité.
Description

Indique qui a effectué l’action, qu’il s’agisse d’un utilisateur humain, par exemple pour une approbation, ou d’un compte système, par exemple pour un règlement automatisé. Cet attribut est essentiel à l’« Analyse des goulots d’étranglement » pour repérer les utilisateurs ou les files d’attente en surcharge.

Pourquoi est-ce important ?

Permet d’analyser les ressources et de contrôler la séparation des tâches.

Où trouver ces données

Journaux d’audit ou colonnes « UpdatedBy » dans les tables de transactions.

Exemples
SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS
Dernière mise à jour des données
LastDataUpdate
Horodatage de la dernière extraction ou mise à jour de l’enregistrement dans le modèle de données.
Description

Indique la fraîcheur des données utilisées dans l’analyse. Il ne s’agit pas de l’heure d’un événement du processus, mais du moment où les données ont été intégrées sur le plan technique. Les analystes peuvent ainsi savoir s’ils consultent des données en temps réel ou un instantané historique.

Pourquoi est-ce important ?

Permet de vérifier l’actualité des données et de repérer celles qui ne sont plus à jour dans les Dashboards.

Où trouver ces données

Heure système au moment de l’exécution du script ETL.

Exemples
2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z
Identifiant de rapprochement
ReconciliationId
Identifiant reliant le paiement au grand livre ou à l’enregistrement de rapprochement.
Description

Cet identifiant est renseigné lorsque l’activité « Paiement rapproché » se produit. Il garantit la concordance entre le paiement dans le moteur de traitement et l’écriture dans le système comptable. Son absence pour un paiement réglé signale un échec du rapprochement.

Pourquoi est-ce important ?

Essentiel au Dashboard « Efficacité du rapprochement des paiements ».

Où trouver ces données

Tables de rapprochement ou champs spécifiques tels que RECON_REF ou GL_REF.

Exemples
REC-9921GL-Entry-2023-11
Nom du bénéficiaire
BeneficiaryName
Nom de l’entité qui reçoit le paiement.
Description

Identifie la contrepartie de la transaction. L’analyse de ce champ peut aider à repérer les fournisseurs ou les clients associés à des taux élevés de reprises ou à des retards, et ainsi alimenter l’« Analyse des échecs et des reprises de paiement ».

Pourquoi est-ce important ?

Identifie le bénéficiaire du paiement, ce qui est utile pour les analyses centrées sur le client.

Où trouver ces données

Lignes détaillées du paiement, avec des champs tels que CREDITOR_NAME, BENE_NAME ou PAYEE.

Exemples
Acme CorpGlobal Supplies LtdJohn Smith
Paiement en retard
IsPaymentLate
Indicateur précisant si le paiement a été réglé après sa date d’échéance.
Description

Indicateur booléen qui compare la date réelle de règlement à la date d’échéance du paiement (PaymentDueDate). Il sert à calculer les métriques du Dashboard « Conformité aux dates d’échéance des paiements » et à repérer les dépassements de SLA.

Pourquoi est-ce important ?

Simplifie le suivi de la conformité.

Où trouver ces données

Calcul : SettlementDate > PaymentDueDate.

Exemples
truefalse
Région d’origine
OriginatingRegion
Région géographique d’où provient la demande de paiement.
Description

Indique l’emplacement physique ou logique du demandeur. Cet attribut est utile pour analyser les variantes du processus de paiement et déterminer si certaines régions suivent des parcours non standard ou connaissent davantage de rejets.

Pourquoi est-ce important ?

Fournit un contexte géographique pour analyser les performances du processus.

Où trouver ces données

En-tête de transaction, souvent dérivé du code d’agence ou du code pays.

Exemples
Amérique du NordEurope, Moyen-Orient et AfriqueAsie-Pacifique
Système source
SourceSystem
Nom du système d’où proviennent les données de l’événement.
Description

Identifie l’application ou le module concerné dans l’écosystème ACI Worldwide, par exemple ACI MTS ou ACI UPF, ainsi que les systèmes externes intervenant dans le flux. Cet attribut est particulièrement important pour rapprocher des données issues de plusieurs grands livres ou lorsque le paiement passe par des chambres de compensation externes.

Pourquoi est-ce important ?

Indique le contexte d’extraction des données, ce qui facilite le débogage de leur traçabilité.

Où trouver ces données

Renseigné en dur lors de l’extraction ou dérivé d’une colonne SystemID si plusieurs instances existent.

Exemples
ACI MTSACI UPPSAP GLSwift Gateway
Temps de cycle de l’approbation
ApprovalCycleTime
Durée passée à l’étape d’approbation.
Description

Calcule le temps écoulé entre « Paiement envoyé pour approbation » et « Paiement approuvé » ou « Paiement rejeté ». Cette métrique alimente le Dashboard « Analyse du temps de cycle d’approbation des paiements » et met en évidence les retards liés aux décisions humaines.

Pourquoi est-ce important ?

Isole la partie du processus qui dépend d’une intervention humaine.

Où trouver ces données

Calcul : Horodatage(Paiement approuvé) - Horodatage(Paiement envoyé pour approbation).

Exemples
4 heures15 minutes
Obligatoire Recommandé Facultatif

Activités du traitement des paiements

Voici les principales étapes et les jalons du processus à enregistrer dans votre journal d’événements pour découvrir avec précision le processus de traitement des paiements.
6 Recommandé 8 Facultatif
Activité Description
Demande de paiement créée
Cette activité marque le lancement d’une nouvelle transaction de paiement dans le système ACI Worldwide. Elle correspond généralement à un événement explicite enregistré lorsqu’un utilisateur ou un système en amont soumet une demande de paiement, ce qui crée une nouvelle transaction dotée d’un identifiant unique.
Pourquoi est-ce important ?

Il s’agit de l’événement de début principal du processus de paiement. L’analyse du délai entre cette activité et la fin du processus donne le temps de cycle de bout en bout, indispensable pour mesurer l’efficacité globale du processus.

Où trouver ces données

Il s’agit probablement d’un événement explicite enregistré dans la table principale des transactions ou dans un journal d’événements dédié d’ACI. Recherchez un horodatage de création associé à l’identifiant de transaction de paiement.

Données à recueillir

Repéré dans l’enregistrement de création ou dans un événement explicite « Create » du journal des transactions.

Type d’événement explicit
Erreur de paiement détectée
Indique que le système a détecté un problème à une étape du traitement du paiement, par exemple des données non valides ou une alerte de conformité. Cet événement est généralement enregistré explicitement avec un code d’erreur associé.
Pourquoi est-ce important ?

Cette activité constitue le point de départ de toute analyse des reprises et de la gestion des exceptions. Elle est indispensable aux Dashboards « Analyse des échecs et des reprises de paiement » et « Temps de cycle de résolution des erreurs ».

Où trouver ces données

Recherchez des entrées explicites dans une table de journal des erreurs ou un changement de statut vers « Erreur » ou « Correction requise » dans la table des transactions. Ces événements doivent être associés à l’identifiant de transaction du paiement.

Données à recueillir

Un événement explicite est enregistré lorsque le moteur de validation ou de traitement du système signale une erreur.

Type d’événement explicit
Fonds transférés
Indique que le réseau de paiement a confirmé le débit des fonds du compte du payeur. Cette information provient généralement d’un message de statut reçu du réseau.
Pourquoi est-ce important ?

Confirme que le réseau externe a exécuté le paiement. Cette étape marque le début de la période de règlement et constitue une donnée essentielle pour le KPI « Average Payment Settlement Time ».

Où trouver ces données

Il s’agit d’un événement explicite déclenché par la réception d’un message de mise à jour de statut, par exemple un MT103 de SWIFT ou une confirmation ACH, qui met à jour l’enregistrement du paiement.

Données à recueillir

Enregistré à la réception d’un message de confirmation externe du réseau de compensation.

Type d’événement explicit
Paiement approuvé
Étape clé au cours de laquelle un utilisateur habilité approuve le paiement, qui peut alors passer à l’exécution. Elle est généralement enregistrée comme un événement explicite lorsque la personne chargée de l’approbation intervient dans l’interface du système.
Pourquoi est-ce important ?

Cette activité constitue un point de contrôle important et souvent un goulot d’étranglement majeur. L’analyse des temps d’attente avant cette étape et de la durée du cycle d’approbation permet de repérer les possibilités d’accélérer les paiements.

Où trouver ces données

Recherchez un événement explicite dans une table du journal des approbations ou un changement de statut vers « Approved » dans la table principale des transactions, associé à l’action d’un utilisateur et à un horodatage précis.

Données à recueillir

Enregistré lorsqu’un utilisateur habilité valide le paiement dans le système.

Type d’événement explicit
Paiement autorisé
Cette étape correspond à l’autorisation du paiement par le système après l’approbation humaine. Le système vérifie les fonds ou applique les règles de détection des fraudes. Elle peut être enregistrée comme une entrée explicite dans le journal ou déduite d’un changement de statut indiquant que le paiement est prêt à être exécuté.
Pourquoi est-ce important ?

Il s’agit d’un point de contrôle essentiel avant l’ordre de transfert des fonds. Des retards à ce stade peuvent signaler des problèmes de performance du système ou des difficultés liées aux sous-systèmes de conformité et de détection des fraudes.

Où trouver ces données

Recherchez une entrée explicite dans un journal de traitement du système ou un journal de sécurité. Vous pouvez aussi déduire cette étape d’un changement de statut de « Approved » à « Authorized for Payment ».

Données à recueillir

Enregistré par le moteur de paiement du système après la réussite des derniers contrôles internes.

Type d’événement explicit
Paiement réglé
Confirmation finale indiquant que le processus de paiement est terminé et que les fonds ont été crédités sur le compte du bénéficiaire. Elle clôt la transaction et constitue un événement essentiel, qui marque la réussite du cycle de paiement.
Pourquoi est-ce important ?

Il s’agit de l’événement de fin qui marque la réussite du processus. Il sert à calculer le temps de cycle global et le débit, et constitue une donnée essentielle pour presque tous les Dashboards de performance de bout en bout.

Où trouver ces données

Généralement enregistré comme événement explicite à la réception du message de confirmation du règlement final du réseau, ou lorsque le grand livre interne est mis à jour pour indiquer que la transaction est terminée.

Données à recueillir

Enregistré à la réception d’un fichier ou d’un message de règlement final, cet événement met à jour le statut et le fait passer à « Réglé ».

Type d’événement explicit
Détails du paiement validés
Cette activité correspond à la fin des contrôles automatisés ou manuels visant à vérifier l’exactitude des détails du paiement, comme les informations sur le bénéficiaire et les codes bancaires. Elle est souvent déduite du passage du statut de la transaction de « New » à « Validated » ou « Pending Approval ».
Pourquoi est-ce important ?

Cette mesure suit l’efficacité des premières étapes de validation des données. Les retards à ce stade peuvent créer des goulots d’étranglement en amont et augmenter le risque d’erreurs de paiement par la suite.

Où trouver ces données

Déduite des champs de changement de statut de la table principale des transactions de paiement. Comparez les horodatages du statut « Created » à ceux d’un statut ultérieur, comme « Validated ».

Données à recueillir

Déduite d’un changement du champ de statut du paiement, par exemple de « Entered » à « Validated ».

Type d’événement inferred
Erreur de paiement résolue
Marque le moment où un utilisateur corrige une erreur précédemment détectée et soumet à nouveau le paiement pour traitement. Cet événement est souvent déduit du passage du statut du paiement d’un état d’erreur à un état de traitement normal.
Pourquoi est-ce important ?

Cette activité clôt la boucle de traitement de l’exception. Le temps écoulé entre « Erreur de paiement détectée » et cet événement correspond au temps de cycle de résolution des erreurs, un indicateur clé de l’efficacité opérationnelle.

Où trouver ces données

Déduit du passage d’un statut « Erreur » à un statut de traitement tel que « En attente d’approbation » ou « Validé ». Il peut également s’agir d’une action explicite enregistrée par un utilisateur.

Données à recueillir

Déduit du passage à un autre statut qu’un état d’erreur, ce qui indique qu’une correction a été apportée.

Type d’événement inferred
Instruction de paiement envoyée
Cette étape marque la compilation et la transmission de l’instruction de paiement à un réseau de paiement externe, comme SWIFT, ACH ou SEPA. Les systèmes ACI enregistrent explicitement ce transfert à des fins d’audit et de suivi.
Pourquoi est-ce important ?

Pour de nombreux types de paiement, il s’agit du « point de non-retour ». Son suivi permet de mesurer le temps de traitement interne avant la prise en charge par des systèmes externes.

Où trouver ces données

Il s’agit presque toujours d’un événement explicite enregistré dans le journal des transactions ou des messages d’ACI, souvent accompagné d’un numéro de référence propre au réseau.

Données à recueillir

Une entrée explicite est créée dans le journal lorsque le message de paiement est envoyé au réseau externe.

Type d’événement explicit
Paiement confirmé
Cette étape correspond à la confirmation interne que le paiement a été traité avec succès et que la confirmation a bien été reçue. Elle déclenche souvent une notification au bénéficiaire ou à d’autres systèmes internes.
Pourquoi est-ce important ?

Cette étape clé permet de mesurer le respect des échéances et le taux de paiements effectués dans les délais. Elle fournit un horodatage précis indiquant quand l’organisation considère que le paiement a été exécuté avec succès.

Où trouver ces données

Cette étape est généralement déduite d’un changement de statut dans la table des transactions de paiement vers « Confirmed » ou « Completed », après réception de la confirmation du réseau externe.

Données à recueillir

Déduit d’un changement de statut vers « Confirmed » ou « Processed ».

Type d’événement inferred
Paiement échoué
Statut final indiquant que le paiement n’a pas pu être effectué en raison d’un problème irrémédiable. Contrairement à une erreur pouvant être corrigée, il marque l’échec définitif du processus.
Pourquoi est-ce important ?

Le suivi de cet événement de fin est essentiel pour calculer le taux global d’échec des paiements. L’analyse des causes d’échec peut contribuer à améliorer la qualité des données et les règles du processus.

Où trouver ces données

Déduit d’un statut final, tel que « Échoué », « Annulé » ou « Rejeté par la banque », dans les données de transaction, qui ne change pas par la suite.

Données à recueillir

Déduit d’un statut d’échec final dans l’enregistrement du paiement.

Type d’événement inferred
Paiement envoyé pour approbation
Indique que le paiement a passé les premières validations et a été transmis pour obtenir l’approbation requise d’un responsable ou du service financier. Cette étape est généralement enregistrée par un changement de statut dans le flux de travail de paiement.
Pourquoi est-ce important ?

Cette étape marque le début du sous-processus d’approbation. Mesurer le délai entre ce point et « Payment Approved » est essentiel pour le Dashboard « Payment Approval Cycle Time Analysis ».

Où trouver ces données

Déduit d’un changement du champ de statut du paiement dans les données de transaction, par exemple lorsque le statut devient « Pending Approval ».

Données à recueillir

Déduit d’un changement de statut vers « Pending Approval » ou un statut similaire, accompagné de l’horodatage correspondant.

Type d’événement inferred
Paiement rapproché
Correspond à la dernière étape comptable, au cours de laquelle la transaction de paiement enregistrée dans ACI est rapprochée des relevés bancaires ou des écritures du grand livre. Cet événement peut être enregistré explicitement par un module de rapprochement ou déduit d’un changement de statut.
Pourquoi est-ce important ?

Cette activité mesure l’efficacité du processus de rapprochement du back-office. Les retards à cette étape peuvent nuire à l’exactitude des rapports financiers et masquer des problèmes de paiement non réglés.

Où trouver ces données

Ces informations peuvent provenir d’un module de rapprochement dédié dans ACI ou d’un système ERP externe. Elles sont enregistrées lors de la mise à jour du statut du paiement vers « Rapproché ».

Données à recueillir

Déduit d’une mise à jour finale du statut vers « Rapproché » ou de données de rapprochement associées par identifiant de paiement.

Type d’événement inferred
Paiement rejeté
Cette étape survient lorsqu’une personne chargée de l’approbation refuse la demande de paiement, ce qui nécessite souvent une correction et une nouvelle soumission. Cet événement explicite interrompt la progression du paiement et déclenche une boucle de reprise.
Pourquoi est-ce important ?

Cette étape met en évidence les reprises et les inefficacités du processus. Le suivi de la fréquence des rejets aide à diagnostiquer les problèmes de qualité des données initiales ou les difficultés liées aux règles de soumission, et contribue à l’analyse des reprises.

Où trouver ces données

Enregistré comme événement explicite dans le journal des approbations ou comme changement de statut vers « Rejected » dans la table des transactions. L’événement peut inclure un code indiquant le motif du rejet.

Données à recueillir

Enregistré lorsqu’une personne chargée de l’approbation rejette le paiement dans le système.

Type d’événement explicit
Recommandé Facultatif

Guides d’extraction

Comment extraire vos données d’ACI Worldwide

Prêt à commencer ?

Suivez ce modèle pour commencer à extraire les données de traitement de vos paiements. Découvrez des analyses utiles et améliorez dès aujourd’hui l’efficacité de vos flux de travail financiers.

Optimisez le traitement des paiements : démarrez votre essai gratuit dès maintenant

Éliminez les exceptions de paiement et atteignez un traitement direct de 98 %.

Démarrez votre essai gratuit

Aucune carte bancaire requise, configuration en quelques minutes