--- title: Référence des indicateurs description: Ce que compte chaque nombre de la page des rapports, dans les mots que le serveur envoie avec lui, et les mesures qu’inletAP choisit de ne pas rapporter section: Reference order: 33 updated: 2026-09-02 sourceHash: 0f2948edb36d translation: machine --- # Référence des indicateurs Chaque chiffre de la page des rapports est défini une seule fois, ici, dans la phrase que l’API envoie avec le nombre lui-même. C’est voulu. Une définition retapée sur une deuxième page devient une deuxième source de vérité, et deux pages en désaccord sur ce qu’est une exception coûtent plus de confiance que de ne pas publier le nombre du tout. Chaque ligne citée ci-dessous est la traduction de la chaîne exacte que le serveur place dans la réponse, et la page des rapports affiche cette même chaîne, en anglais, à côté du graphique. Lisez ceci avant de comparer deux chiffres, et surtout avant de supposer que l’un est l’inverse de l’autre. ## Comment lire un taux de cette page **Un taux est absent plutôt que nul quand il n’y a rien à diviser.** Si aucune facture n’a fait l’objet d’une décision pendant une période, il n’y a pas de pourcentage de respect des délais — « rien n’était à échéance » et « nous étions en retard pour tout » sont deux phrases différentes, et la deuxième serait un mensonge sur une semaine tranquille. **Toujours les nombres, et les pourcentages seulement quand un pourcentage veut dire quelque chose.** Sous vingt documents, les mots `trop peu de documents pour un taux` prennent la place du pourcentage, et les nombres sont affichés dans tous les cas. Trois sur cinq est vrai quel que soit l’échantillon. Soixante pour cent ne l’est pas, parce qu’un document de plus le fait bouger de vingt points. **Chaque taux est calculé sur une période que vous choisissez, dans votre propre fuseau horaire.** Les intervalles sont des jours ou des semaines civils découpés dans votre fuseau, pas dans celui du serveur. ## Les factures reçues : le volume traité Les documents reçus dans chaque intervalle, quel que soit leur sort par la suite, et combien d’entre eux ont eu besoin d’une personne à un moment ou à un autre. ## Exceptions Une exception est : > un document qui est passé au moins une fois à needs_review ou à quarantined, par le verdict du traitement automatique ou par un changement de statut fait par une personne Deux branches, parce que le traitement automatique et une personne écrivent des lignes différentes. Notre moteur de règles enregistre son propre verdict quand il achemine une facture, et une personne qui change un statut enregistre un autre genre de ligne. Ne lire qu’une des deux donne un nombre petit, plausible et faux. Le dénominateur est : > chaque document que l’espace de travail a reçu pendant la période, quel que soit son statut actuel et qu’il se soit révélé ou non être une facture — la même population que celle par laquelle divise /metrics/throughput, pour que les deux taux ne puissent pas être en désaccord **C’est un taux de cohorte, pas une file d’attente.** Il répond à la question « parmi les factures arrivées pendant cette période, combien ont eu besoin d’une personne à un moment ou à un autre », et il ne bouge plus une fois la période passée. L’ancien chiffre du tableau de bord est un instantané de ce qui attend en ce moment, qui baisse à mesure que l’équipe vide l’arriéré — une équipe rapide y obtient un meilleur résultat qu’une équipe lente avec les mêmes factures, ce qui en fait une jauge de charge de travail plutôt qu’une mesure de qualité. ### Par fournisseur, et la ligne qu’il ne faut jamais supprimer La ventilation comprend une ligne **Fournisseur non identifié**. Ce n’est pas un trou dans les données à faire disparaître : une facture arrive souvent à l’examen justement parce que personne n’a pu dire de qui elle venait. Retirer cette ligne supprimerait la population la moins performante et réduirait en même temps le dénominateur; le taux s’améliorerait donc précisément dans les espaces de travail où il ne le devrait pas. Un fournisseur en haut de cette liste n’est pas un mauvais fournisseur. C’est un fournisseur dont notre extracteur n’a pas appris la mise en page, ou un fournisseur pour qui personne n’a encore écrit de règle de correspondance. La liste est une liste de travail, pas un verdict sur l’entreprise de quelqu’un d’autre. ### Par motif, et pourquoi la ligne vide est grande > review_reason est le motif inscrit sur le document maintenant, pas le motif pour lequel il a été acheminé à l’époque; il est écrit seulement par l’analyseur, l’extracteur et les règles d’immeuble, une mise en quarantaine n’en écrit aucun, et l’intervalle sans étiquette mélange donc des documents qui n’ont jamais eu besoin de motif et des exceptions dont le motif n’a jamais été inscrit ## Taux de traitement automatique > parmi les documents qui ont atteint approved ou exported pendant la période, la part qui ne porte, depuis toujours, aucune ligne de vérification fields_updated nommant un champ important et aucune ligne de vérification allocation.* faite par un auteur de type user; appuyer sur Approuver est une décision et non une modification, et ne compte pas comme une intervention, et attribuer une facture à un ou une collègue est un acheminement et non une modification, et ne compte pas non plus comme une intervention Appuyer sur Approuver est une décision, pas une modification. Une personne responsable du contrôle qui lit une facture, est d’accord avec chacun de ses caractères et la signe n’a pas corrigé la machine; compter cela comme une intervention rapporterait votre politique d’approbation au lieu de notre extraction. ### Ce n’est pas l’inverse du taux d’exceptions > ce n’est pas un moins le taux d’exceptions : une exception est un document que le système a acheminé vers une personne, une intervention est un document qu’une personne a changé, et une facture examinée puis approuvée sans changement est à la fois une exception et sans intervention; les deux comptent aussi des populations différentes, les documents reçus d’un côté et les documents terminés de l’autre Les deux nombres sont sur le même écran et leur somme ne donne pas un. Ce n’est un défaut ni de l’un ni de l’autre. Une exception est un document que le système a **acheminé** vers une personne; une intervention est un document qu’une personne a **changé**; et ils sont calculés sur des populations différentes — l’une selon l’arrivée, l’autre selon l’arrivée à l’approbation ou à l’exportation. ## Taux de modification de l’extraction > parmi les documents reçus pendant la période que l’extracteur a réellement lus, la part qu’une personne a ensuite changée au moins une fois — une ou plusieurs lignes de vérification fields_updated faites par un auteur de type user et nommant un champ important; attribuer une facture à un ou une collègue est donc un acheminement et non une modification, et ne compte pas; le nombre brut de modifications est envoyé à côté, pour qu’une facture modifiée neuf fois soit visible au lieu d’être comptée une seule fois **Ceci mesure notre lecture de la facture, pas la facture.** Le nombre qui y ressemble dans le métier — la part des factures qui contiennent des données erronées — parle du document de votre fournisseur. Celui-ci est la part où quelqu’un a changé ce qu’inletAP avait proposé. Même forme, sujet opposé; nous n’empruntons donc pas le nom. Ce n’est pas non plus un chiffre d’exactitude, et pas seulement à cause du nom. Le journal d’activité conserve la valeur telle qu’elle était juste avant chaque modification; à la deuxième modification d’un même champ, il contient donc la valeur de la personne précédente plutôt que celle de la machine. Un chiffre champ par champ exigerait la première modification de chaque champ, et nous choisissons de ne pas le rapporter. Le nombre brut de changements de champs accompagne le taux, parce qu’un taux compte une seule fois une facture corrigée neuf fois. ## Délai d’approbation > de la réception (created_at) à la première preuve que le document a atteint approved : une ligne de vérification status_changed, une ligne de vérification approved satisfaite, ou la dernière décision d’approbation sur un document entièrement décidé Rapporté en médiane et en p90, en jours aussi bien qu’en minutes : chaque point de référence publié dans ce secteur est exprimé en jours, et un chiffre en minutes seulement ne se compare à rien de ce que vous avez déjà lu. Le chronomètre démarre quand la facture arrive dans inletAP, ce qui est plus tard que le moment où le fournisseur l’a envoyée. ## Respect du SLA d’approbation > une décision d’approbation est dans les délais quand approvals.decided_at est égal ou antérieur au sla_deadline du document; les décisions sur des documents sans échéance sont rapportées comme noDeadline et exclues du taux; une facture répartie est classée sous l’immeuble pour lequel a signé la personne qui l’approuve pour cet immeuble (approvals.scope_property_id) Ceci mesure **notre propre échéance d’approbation**, celle que fixent vos paliers. Ce ne sont pas les conditions de paiement du fournisseur, et ce n’est pas une affirmation sur le fait que quelqu’un soit payé à temps : inletAP ne fait circuler aucun argent. Un portefeuille pourrait signer chaque approbation dans les délais et quand même payer chaque fournisseur en retard. Les décisions sur des factures qui n’ont jamais eu d’échéance sont comptées à part et n’entrent dans aucun taux. Elles n’ont jamais été en retard, et les inclure dans un sens ou dans l’autre inventerait un fait. ### Le registre des dépassements est un plancher > une borne inférieure, pas un recensement : la vérification des délais s’exécute toutes les 15 minutes et ne voit que les documents encore à needs_review ou à ready_for_approval; une facture qui a dépassé son échéance et a été approuvée avant le passage suivant n’a donc jamais eu de ligne; l’intervalle est le jour où la vérification l’a REMARQUÉ, jusqu’à 15 minutes après le dépassement réel de l’échéance Le total est donc écrit « au moins ». C’est une borne inférieure et jamais un recensement. Les deux séries sur le délai de traitement (SLA) commencent aussi le jour où le produit a commencé à inscrire les échéances et à consigner les dépassements. Les jours précédents sont vides exprès : ce sont des jours non mesurés, pas des jours parfaits. ## Valeur en cours, et l’arriéré ouvert La valeur en cours est ce que chaque immeuble doit en ce moment, dans tous les statuts ouverts, calculée sur l’ensemble de l’espace de travail plutôt que sur une seule page. Une facture répartie ajoute sa propre tranche à chaque immeuble et n’est jamais comptée deux fois. L’arriéré découpe la même file ouverte en tranches d’ancienneté : > documents ouverts (needs_review, ready_for_approval, held_quota), avec l’ancienneté en jours civils complets dans tz depuis created_at, qui correspond à l’arrivée plutôt qu’au départ d’un chronomètre d’approbation L’ancienneté est un instantané; elle ignore donc la période choisie au-dessus. ## Ce qu’inletAP ne rapporte pas, et pourquoi - **Le temps qu’une personne a passé sur une facture.** Rien dans le produit n’enregistre combien de temps quelqu’un a gardé un document ouvert — il n’y a ni événement de consultation ni minuterie —, alors tout chiffre de ce genre serait inventé plutôt que mesuré. - **Le volume traité par personne.** Le seul dénominateur par personne disponible est un nombre de places, qui comprend des propriétaires, des personnes qui approuvent et des personnes en lecture seule qui ne traitent rien. - **Le champ précis que nous avons mal lu.** Voir le taux de modification de l’extraction ci-dessus. - **Un score du nombre de doublons que nous avons arrêtés.** Marquer une facture comme doublon est un geste fait par une personne; un compte de ces marques serait donc un compte de gestes administratifs plutôt que de quoi que ce soit que le logiciel a trouvé. Si vous voulez les lignes de base plutôt que le résumé, le journal d’activité conserve chaque modification avec la valeur avant et après, et s’exporte en CSV.