Le procure to pay est le cycle complet qui va de l'identification d'un besoin au paiement du fournisseur : demande, commande, réception, facture, paiement.
Le procure to pay, souvent abrégé P2P, est le cycle complet qui démarre lorsqu'une personne identifie un besoin dans l'entreprise et se termine lorsque le fournisseur est payé et l'opération soldée en comptabilité. Les étapes standard sont la demande d'achat, l'approbation, la commande d'achat, la réception des biens ou du service, la réception de la facture, le rapprochement, la comptabilisation et le paiement. Ce cycle traverse volontairement deux services qui sont mesurés séparément, les achats sur la première moitié et la comptabilité fournisseurs sur la seconde, et c'est précisément à la jonction que se concentrent les problèmes.
Chaque rupture entre ces étapes se traduit en trésorerie ou en risque. Une commande passée sans bon de commande laisse la comptabilité fournisseurs avec une facture que personne n'attendait et aucun document sur lequel la rapprocher : elle reste en attente pendant que le délai de paiement s'écoule. Une réception jamais comptabilisée signifie que la marchandise est en stock physique mais que la dette n'est pas au bilan, et la période clôture sous-évaluée. Les approbations tardives font sortir les factures de la fenêtre d'escompte, puis de l'échéance, ce qui coûte de l'argent d'un côté et de la crédibilité fournisseur de l'autre.
Business Central couvre en standard la colonne vertébrale transactionnelle : commandes d'achat, réceptions directes ou par entrepôt, factures d'achat, reprise des lignes de réception via Récupérer lignes réception, écritures comptables fournisseur, et journal de paiement avec suggestion de paiements fournisseur et fichiers SEPA. Le moteur de workflow d'approbation natif achemine les documents d'achat vers les approbateurs définis dans la configuration des utilisateurs approbateurs, avec des limites de montant. Ce qui est plus mince en standard, c'est l'amont et la gestion des exceptions : pas de document de demande d'achat pour un demandeur non acheteur, pas de portail fournisseur, pas de référentiel de contrats, pas de file d'attente listant chaque facture bloquée avec son motif. Ces manques se comblent par des extensions ou par de la discipline de processus, et le guide dédié à l'automatisation des achats détaille ce que cela implique.
Un responsable maintenance a besoin de pompes de remplacement et exprime le besoin le 3 mars. Un acheteur émet la commande PO-104217 chez Alpine Technik pour 6 unités à CHF 780, soit CHF 4 680, conditions de paiement 30 jours net. Les pompes arrivent le 17 mars et la réception est comptabilisée le jour même. La facture, datée du 18 mars, se rapproche de la commande et de la réception et se comptabilise avec une échéance au 17 avril. Du besoin au décaissement, le cycle dure 45 jours : 14 jours de délai fournisseur, un jour entre la réception et la date de facture, et les 30 jours du délai de paiement que l'entreprise a choisi d'utiliser.
Les points de rupture récurrents sont les factures sans commande, les réceptions saisies plusieurs jours après l'arrivée physique et les approbateurs en vacances sans suppléant configuré. Les équipes suivent quatre indicateurs plutôt qu'un seul : la part des dépenses passées par une commande, la part des factures qui se rapprochent sans intervention humaine, le délai moyen entre réception de la facture et comptabilisation, et le nombre de factures actuellement bloquées. Un délai de cycle moyen unique masque les quatre et n'indique pas où agir.
content[5] = (no sixth element; the array ends after the five real paragraphs, the last being "Les points de rupture récurrents sont les factures sans commande, les réceptions saisies plusieurs jours après l'arrivée physique et les approbateurs en vacances sans suppléant configuré. Les équipes suivent quatre indicateurs plutôt qu'un seul : la part des dépenses passées par une commande, la part des factures qui se rapprochent sans intervention humaine, le délai moyen entre réception de la facture et comptabilisation, et le nombre de factures actuellement bloquées. Un délai de cycle moyen unique masque les quatre et n'indique pas où agir." La FAQ est rendue à partir du tableau `faq`, rien ne remplace le placeholder.)
Non. Le source to pay est plus large : il ajoute en amont le sourcing, la consultation, la négociation et l'attribution du contrat. Le procure to pay commence une fois le fournisseur et le prix déjà arrêtés.
Pas nécessairement. BC gère nativement commandes, réceptions, factures et paiements. La vraie question est de savoir si vous avez besoin de demandes d'achat, d'un portail fournisseur et d'une gestion des exceptions par-dessus. Avec quelques acheteurs seulement, beaucoup d'entreprises font tourner tout le cycle dans BC.
Les outils d'IA de Zentriq automatisent de nombreux processus manuels liés à procure to pay (p2p, du besoin au paiement) dans Business Central. Découvrez l'Agent Zentriq ou essayez Zentriq PunchOut pour voir comment l'IA simplifie les achats dans BC.