Documentation

Entreprises, régions et personnes

Chaque espace de travail Pleaxy appartient à une seule entreprise. Votre domaine e-mail ne fait pas partie de l'arborescence : Pleaxy ne l'utilise que comme indice lors d'une inscription.

• Entreprise - l'organisation dans Pleaxy. Rien au-dessus : ni groupe ni société mère. Ses administrateurs sont les administrateurs de n'importe lequel de ses profils acheteur ou fournisseur.
• Région - un espace de travail au sein d'une entreprise, par exemple EMEA. Une région ne passe jamais à une autre entreprise.
• Profils acheteur et fournisseur - les deux côtés d'une région, qui en a un ou les deux. Chacun a ses propres utilisateurs et rôles, bons de commande, factures et connexions avec des acheteurs ou des fournisseurs.

Qui se retrouve dans quelle entreprise

• La première personne d'un domaine professionnel crée une nouvelle entreprise et en devient administratrice.
• Un collègue qui s'inscrit ensuite voit, une fois son e-mail confirmé, les entreprises Pleaxy qui ont déjà des personnes sur son domaine, chacune avec ses régions. Il peut demander à un administrateur de l'une d'elles une invitation dans une région, ou confirmer que la sienne est une autre entreprise et en créer une distincte. Des entreprises distinctes ne voient pas les commandes, factures ni fournisseurs des autres.
• Un administrateur qui ajoute une région l'ajoute à sa propre entreprise.
• Les entreprises ne peuvent pas être fusionnées. Si une entreprise distincte a été créée par erreur, invitez plutôt ses membres dans les régions de votre entreprise.

Démarrage rapide

Connectez-vous, connectez un fournisseur cloud et créez votre premier bon de commande. La console et les SDK appellent la même API /v1, que vous pouvez aussi appeler avec une clé API à portée limitée (voir Agents IA pour en générer une). Certaines actions nécessitent toujours une personne connectée à Pleaxy, jamais une clé API : valider, modifier les circuits de validation ou l’autonomie, et enregistrer un paiement.

import { Pleaxy } from "@pleaxy/sdk";

// The base URL is the origin only: the SDK adds /v1/workspaces/<Workspace ID>.
const pleaxy = new Pleaxy({
  baseUrl: "https://api.pleaxy.ai",
  apiKey: process.env.PLEAXY_API_KEY, // "<keyId>.<secret>"
  workspaceId: process.env.PLEAXY_WORKSPACE_ID, // Company profile → Workspace ID
});

// AWS: start the connection, run the returned setup script in your own
// account, then pass back the read-only IAM role it created.
const setup = await pleaxy.cloudConnections.initAwsCloudConnection();
await pleaxy.cloudConnections.createCloudConnection({
  provider: "aws",
  accountLabel: "Production payer",
  awsConnectionId: setup.connectionId,
  roleArn: "arn:aws:iam::912345678901:role/PleaxyBillingRead",
});

const po = await pleaxy.purchaseOrders.createPurchaseOrder({
  supplier: "Amazon Web Services",
  provider: "aws",
  lineItems: [
    {
      scopeType: "sku",
      scopeId: "AWS-EC2-M5LG",
      name: "EC2 m5.large",
      ruleType: "quantity",
      unit: "hr",
      unitPrice: 0.096,
      qty: 5_000,
      nteAmount: 0,
      paymentTerms: "Net 30",
      validFrom: "2026-01-01",
      validUntil: "2026-12-31",
    },
  ],
});

// po.status is "pending_approval" while your approval flow runs, then
// "awaiting_fulfillment". Autonomy, if on, can approve it straight away.

Bons de commande et lignes

Un bon de commande se compose d’une ou plusieurs lignes, chacune tarifée et suivie indépendamment :

• Lignes SKU : un article précis du catalogue d’un fournisseur, facturé à la quantité × prix unitaire. Lorsque le fournisseur publie un catalogue dans Pleaxy, l’identifiant de l’article sur la ligne est validé côté serveur.
• Lignes forfaitaires par service ou par compte : un plafond à ne pas dépasser couvrant un service entier ou un compte cloud entier.
• Lignes personnalisées : pour tout ce qui ne figure pas au catalogue d’un fournisseur, soit à la quantité, soit sous forme de montant fixe à ne pas dépasser.

Chaque ligne est libellée dans la devise de la région, porte ses propres conditions de paiement et sa propre période de validité, et suit un solde en temps réel (consommé ou restant) sur cette période, en signalant les lignes en voie d’épuisement anticipé.

Connexions cloud

Pleaxy se connecte en lecture seule à la facturation d’Amazon Web Services (AWS), Google Cloud, Microsoft Azure et Oracle Cloud Infrastructure (OCI), grâce à un accès que vous créez dans votre propre compte avec un script de configuration et que vous pouvez révoquer à tout moment. Pleaxy conserve chaque bon de commande comme un enregistrement distinct et n’écrit aucun bon de commande chez un fournisseur cloud :

• Amazon Web Services (AWS) : un rôle IAM inter-comptes que Pleaxy endosse. Il lit vos factures émises et Cost Explorer. Pour qu’AWS imprime un numéro de bon de commande Pleaxy sur ses factures, ajoutez-le sous Purchase orders dans la console AWS Billing and Cost Management.
• Google Cloud : Workload Identity Federation vers un compte de service qui ne peut que lire votre export de facturation BigQuery. Google ne propose pas d’API de factures, donc Pleaxy utilise le total mensuel de l’export.
• Microsoft Azure : un identifiant fédéré sur une application de votre propre tenant. Il lit les factures de votre profil de facturation et le coût du mois en cours. Pleaxy n’associe pas de numéros de bon de commande aux factures EA.
• Oracle Cloud Infrastructure (OCI) : une clé de signature d’API générée par Pleaxy ; vous ne téléversez que la clé publique. Il lit les factures de consommation lorsque votre compte en dispose, et à défaut le coût de chaque mois clôturé.

Dépenses d’IA

Les dépenses d’IA sont ce que coûtent les services d’IA de la facturation cloud que vous avez connectée : Amazon Bedrock, SageMaker, Vertex AI, Azure OpenAI, OCI Generative AI et les modèles du marketplace sur la même facture. Pleaxy les montre par émetteur de facture, éditeur du modèle, modèle et compteur (tokens d’entrée, de sortie et en cache, heures provisionnées), mois en cours et prévision pour la période, par rapport au dernier mois clôturé, et à côté de chaque émetteur les lignes de bon de commande ouvertes émises à son nom et ce qu’il y reste : vous savez ainsi que Bedrock coûtera plus que ce qui reste sur PO-8842 avant que la facture ne l’annonce. Chaque montant est dans la devise de facturation de l’émetteur, jamais converti ni additionné entre devises.

• Le fournisseur est celui qui facture. L’entreprise dont le modèle a été utilisé est le vendor de la ligne. Claude sur Bedrock est une dépense AWS avec vendor anthropic, jamais une dépense Anthropic : grouper par émetteur correspond à vos factures, et grouper par éditeur répond à ce que vous dépensez pour Claude, quel que soit celui qui le facture. Rien n’est compté deux fois.
• D’où viennent les chiffres : des lignes de services d’IA de la facturation AWS, Google Cloud, Azure et OCI que vous avez connectée, lues avec le même accès en lecture seule que le reste de la facture et avec le même choix de sources de données : une connexion qui autorise current_cost donne le mois en cours et une prévision ; une qui autorise invoices, le mois clôturé. AWS ne fournit ses lignes d’IA que via Cost Explorer : un compte AWS a besoin de current_cost pour les voir, et montre alors aussi le mois clôturé. Rien de nouveau n’est demandé à votre compte, et un type d’usage que Pleaxy ne connaît pas encore est conservé avec son nom brut, jamais écarté.
• Grilles tarifaires : Pleaxy tient à jour les prix publics de chaque éditeur et émetteur qu’il mappe, avec leurs dates d’effet : un changement de prix est une nouvelle entrée, si bien qu’une ligne est jugée au prix qui s’appliquait le jour même. Le tarif négocié d’un contrat ou sa remise sur le prix public prime ; les grilles elles-mêmes ne se modifient pas.

Dans l’API, les dépenses d’IA sont une ressource réservée aux acheteurs : GetAiSpend pour les chiffres par émetteur, éditeur, modèle ou centre de coûts, ListAiUsageLines pour les lignes qui les composent, ListAiRateCards pour le prix en vigueur un jour donné et CheckAiSpend pour savoir si la prévision tient dans les lignes de bon de commande ouvertes et le budget. Le serveur MCP expose la même chose sous get_ai_spend et check_ai_spend (voir Agents IA).

Au-delà de votre facturation cloud, les dépenses d’IA couvrent les fournisseurs d’IA que vous payez directement, les lignes IA de vos commandes et factures, les centres de coûts et les plafonds chez le fournisseur :

• Fournisseurs d’IA directs : OpenAI et Anthropic se connectent avec une clé d’administration en lecture seule que vous créez dans leur console et pouvez révoquer ; Mistral aussi, si votre organisation dispose de son Admin API (une fonction Enterprise). OpenRouter se connecte avec une clé de gestion, CoreWeave avec un jeton d’API doté du rôle Billing Viewer et Databricks avec un principal de service ; pour Snowflake, Pleaxy génère une paire de clés et vous attribuez sa clé publique à un utilisateur de service. La clé est vérifiée par une lecture avant d’être enregistrée, stockée chiffrée et jamais utilisée pour modifier quoi que ce soit chez le fournisseur. Les lignes de chaque fournisseur sont lues chaque jour et apparaissent comme leur propre émetteur (ListAiProviders, CreateAiProvider).
• Factures d’IA rapprochées ligne à ligne : une ligne IA sur une commande, une condition de contrat ou une facture indique son modèle et son compteur, et chaque ligne de facture est contrôlée par rapport à la ligne de commande et à la condition du contrat pour ce modèle : son tarif face au contrat et au prix catalogue du mois, sa quantité face à la consommation déclarée par le fournisseur, et ce qu’elle consomme d’un engagement. Les lignes ne sont jamais rapprochées sur leur libellé. SuggestAiPoLines préremplit les lignes IA d’une commande à partir de la consommation du mois précédent, et ListAiCommitments indique ce qui a été utilisé de chaque engagement.
• Centres de coûts et budgets : des règles d’imputation associent les tags, libellés, projets et espaces de travail des fournisseurs à des centres de coûts (GetAiAttribution). Chaque budget compte alors la consommation IA imputée du mois comme dépense en cours, et Pleaxy alerte quand la prévision atteint 80 % ou 100 % du budget (ListAiCostCenters).
• Plafonds chez le fournisseur : facultatifs. Une ligne de commande validée peut fixer le plafond mensuel du fournisseur lui-même : un budget AWS, une limite de projet OpenAI, une limite d’espace de travail Anthropic lorsque Anthropic la propose sur votre compte, un budget ou un plafond de dépenses Google Cloud, ou un budget Azure, qui ne fait qu’alerter. Il faut un identifiant distinct que vous créez, jamais celui de la connexion en lecture seule (SetAiSpendLimit).
• IA facturée par siège : les factures par siège de ChatGPT Enterprise, Claude Enterprise, Microsoft 365 Copilot, GitHub Copilot et Cursor sont contrôlées par rapport aux utilisateurs actifs enregistrés pour le mois (SetAiSeatCount). Pleaxy ne lit pas votre fournisseur d’identité : une personne, un script ou un agent enregistre le nombre.

Validations et autonomie

Chaque région dispose d’un circuit de validation pour les bons de commande et d’un autre pour le paiement des factures, que vous modifiez sous Workflows dans Pleaxy. Une nouvelle région démarre avec une seule étape, attribuée à un administrateur de la région. Vous construisez un circuit à partir de trois types d’étapes :

• Valideur : une personne donne son accord.
• Valideurs en parallèle : plusieurs personnes différentes donnent chacune leur accord, dans n’importe quel ordre.
• Valideur conditionnel : n’intervient que lorsque toutes ses conditions sont remplies. Les conditions peuvent porter sur le montant (dans la devise de la région), le fournisseur ou le demandeur.

Chaque étape désigne une personne précise, et seule cette personne peut agir dessus. Cochez Uniquement au-delà du seuil des montants élevés sur une étape et les montants inférieurs ou égaux au seuil la sautent. Un circuit doit comporter au moins une étape sans condition, afin que chaque commande et chaque facture parvienne à une personne. Si vous avez vous-même émis le document, votre étape est confiée à un autre administrateur. Vous ne pouvez le valider vous-même que si personne d’autre dans la région ne le peut, et il est alors marqué Auto-validé.

Avec le plan Autonomous, vous pouvez activer l’autonomie, également sous Workflows. Pleaxy valide alors de lui-même un bon de commande ou une facture jusqu’à votre montant de validation automatique, en tant que Pleaxy Autonomy, avec la même piste d’audit. Il ne le fait jamais lorsqu’une étape conditionnelle ou au-dessus du seuil s’applique, ni lorsqu’un bon de commande dépasse le plafond de dépenses de son demandeur. Pour les factures, la règle est plus stricte : seule une facture rapprochée d’une facture AWS émise peut être validée automatiquement, jamais une facture saisie par un acheteur ni une facture dans une autre devise. Les règles d’automatisation vous permettent de traiter un fournisseur différemment : toujours envoyer ses documents à une personne ou, avec le plan Autonomous, les valider automatiquement jusqu’à un certain montant.

Une clé API peut lire les circuits de validation et les paramètres d’autonomie, mais seule une personne connectée à Pleaxy peut les modifier, et une clé API ne valide jamais une étape.

const flow = await pleaxy.approvalChains.get("purchase_order"); // or "invoice_payment"

const autonomy = await pleaxy.settlement.getAutonomy();
// { enabled, maxAutoApproveAmount, approvalThreshold }
// approvalThreshold is the high-value threshold. Change these in Pleaxy, under Workflows.

Rapprochement des factures

Une facture émise sur un bon de commande, pour un fournisseur cloud avec lequel vous avez une connexion de facturation active, démarre avec le statut de rapprochement pending. Le rapprochement compare le montant facturé à la consommation déclarée par le fournisseur :

• Écart inférieur ou égal à 3 % → matched, et la facture passe dans votre circuit de validation des factures.
• Écart supérieur à 3 %, ou devise différente → discrepancy. Pleaxy ne convertit pas les devises. Une personne la compare à la facture du fournisseur, puis la transmet au circuit de validation ou la refuse. Si l’autonomie est activée et que l’écart ne dépasse pas votre montant de validation automatique, Pleaxy la valide lui-même, dans les limites applicables aux factures décrites sous Validations et autonomie.

Une facture sans bon de commande, ou sans connexion de facturation permettant de la vérifier, est unverified. Une personne connectée à Pleaxy l’examine, puis la transmet au circuit de validation ou la refuse.

Avoirs et notes de débit

Un avoir réduit ce que doit l’acheteur : marchandises retournées, correction de prix, remboursement. Le fournisseur l’émet sur la facture qu’il corrige, ou au seul nom de l’acheteur, et un acheteur peut enregistrer un avoir que le fournisseur a envoyé hors de Pleaxy. Un avoir qui corrige une facture sans la dépasser est accepté aussitôt ; tout autre attend que l’acheteur l’accepte ou le refuse. Accepter un avoir pour des marchandises retournées ou une correction de prix rend son montant hors taxes à la ligne du bon de commande, qui peut ainsi resservir.

Qui règle les crédits est un réglage de l’espace de travail :

• Pleaxy les règle. Les avoirs acceptés s’imputent sur les factures impayées et réduisent leur montant à payer, et un avoir sur une facture impayée s’y impute dès son acceptation. Les avoirs peuvent couvrir une facture en entier : une fois validée, elle est réglée par avoir, sans rien à payer. Refuser une facture rend les avoirs qui y étaient imputés.
• Votre système comptable les règle. Rien n’est compensé dans Pleaxy, et chaque avoir accepté figure une fois dans l’export des paiements, en ligne négative.

Une note de débit facture davantage sur une facture déjà envoyée, par exemple un montant oublié. Elle indique la facture qu’elle modifie et en reprend le bon de commande, la ligne et la devise, puis passe par le rapprochement, la validation, le paiement et l’export comme toute facture. Elle ne peut pas modifier une facture refusée ni une autre note de débit.

Les deux se trouvent sous Factures dans l’application, liés à la facture qu’ils modifient, et les avoirs d’AWS et d’Azure arrivent tout seuls comme avoirs. Dans l’API, ils forment la ressource des factures avec un documentType credit_note ou debit_note (voir CreateInvoice), et un flux de factures les envoie comme avoirs et notes de débit UBL, credit et debit memos cXML, ou JSON avec documentType.

Paiements

Pleaxy ne paie pas les factures. Une fois le circuit de validation d’une facture terminé, l’acheteur la paie lors de son propre cycle de paiement (les factures validées peuvent être exportées à cet effet) et enregistre le paiement dans Pleaxy. L’enregistrement ne déplace aucun fonds. Le fournisseur voit le paiement comme enregistré par l’acheteur et reçoit un avis de paiement. Enregistrer un paiement nécessite une personne connectée à Pleaxy, jamais une clé API.

Avec le paiement, ou à tout moment ensuite, l’acheteur peut envoyer au fournisseur un avis de paiement : une preuve de paiement, comme le reçu de virement de la banque (PDF, PNG ou JPEG, jusqu’à 10 Mo), et une note de 1 000 caractères au plus. Le fournisseur est prévenu, aussi dans son canal Slack ou Teams s’il y dirige les notifications de paiement, et retrouve l’avis sur la facture. Comme l’enregistrement d’un paiement, l’envoi nécessite une personne connectée à Pleaxy (voir SendRemittance). Exporter pour paiement fonctionne aussi pour une seule facture.

Agents IA (MCP)

Pour connecter un agent en votre propre nom, sans clé API : Connecter un agent IA.

Le serveur MCP de Pleaxy expose les bons de commande et les factures sous forme d’outils pour Claude ou tout autre agent compatible MCP. C’est une simple surcouche : chaque appel d’outil correspond à une requête authentifiée vers la même API /v1 que celle qu’utilisent la console et les SDK, de sorte qu’un agent peut faire exactement ce que sa clé API autorise, et rien de plus.

1. Générez une clé API à portée limitée avec POST /v1/workspaces/:regionId/api-keys en étant connecté sous votre propre identité : une clé API existante ne peut pas en générer une autre (voir Clés API). La clé reprend votre propre rôle dans l’espace de travail, acheteur ou fournisseur, et seul un administrateur peut en générer une. Une clé acheteur est en lecture seule, sauf si vous lui attribuez un procurementRole, par exemple requisitions pour créer des bons de commande. La réponse contient la clé (affichée une seule fois). Copiez ensuite l’ID de l’espace de travail depuis Profil de l’entreprise dans la console Pleaxy : vous aurez besoin des deux ci-dessous.
2. Vérifiez qu’il fonctionne (Node.js 22.18 ou version ultérieure). Le serveur est publié sur npm sous le nom pleaxy-mcp : rien à compiler ni à cloner, npx le télécharge.
   shell

   npx -y pleaxy-mcp --version

3. Ajoutez-le à votre client MCP. Pour Claude Desktop ou Claude Code, ajoutez ceci à votre configuration MCP. L’URL de base se limite à l’origine : le serveur ajoute lui-même /v1.
   mcp config · json

   {
     "mcpServers": {
       "pleaxy": {
         "command": "npx",
         "args": ["-y", "pleaxy-mcp"],
         "env": {
           "PLEAXY_API_BASE_URL": "https://api.pleaxy.ai",
           "PLEAXY_API_KEY": "<keyId>.<secret>",
           "PLEAXY_WORKSPACE_ID": "<Company profile → Workspace ID>"
         }
       }
     }
   }

Un processus serveur dessert un seul espace de travail : une clé API, un ID de l’espace de travail. Les clés acheteur et fournisseur voient la même liste d’outils, mais un appel hors du rôle de la clé (par exemple une clé fournisseur qui appelle create_purchase_order) est rejeté par l’API exactement comme il le serait via REST.