--- title: "Conditions de paiement" description: "Les conditions de paiement fixent quand et comment une facture doit être réglée." --- > Documentation Index > Fetch the complete documentation index at: https://docs.beelocity.com/llms.txt > Use this file to discover all available pages before exploring further. # Conditions de paiement Les **conditions de paiement** fixent quand et comment une facture doit être réglée. Elles se créent au niveau de l'organisation, puis s'affectent aux tiers un par un — vous définissez donc vos conditions standard une fois et vous les réemployez sur tout votre annuaire. ## Ce que définissent les conditions de paiement | Champ | Définition | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | **Nom** | Un libellé lisible qui décrit les conditions (par exemple « Net 30 », « 2/10 net 30 », « Paiement à réception »). | | **Code** | Un identifiant court à usage interne (par exemple `NET30`, `DOR`). Employé dans les références et les états. | | **Jours** | Le nombre de jours entre la date de facture et l'échéance du règlement. | | **Escompte %** | Un escompte de règlement anticipé, exprimé en pourcentage (facultatif). | | **Jours d'escompte** | Le nombre de jours pendant lesquels l'escompte de règlement anticipé reste acquis (facultatif). | | **Désignation** | Une explication détaillée des conditions, en langage clair (facultatif). Utile aux équipes qui ne connaissent pas les codes de conditions de paiement. | Quand l'**escompte %** et les **jours d'escompte** sont tous deux renseignés, cela crée une incitation au règlement anticipé : « réglez sous X jours pour un escompte de Y %, ou réglez la totalité à l'échéance ». Quand ni l'un ni l'autre n'est renseigné, il s'agit simplement d'un règlement à tant de jours. ## Conditions de paiement courantes Voici des conditions typiques que vous pourriez définir pour votre organisation : | Condition | Code | Jours | Escompte | Signification | | -------------------------- | --------- | ----- | -------------------- | ----------------------------------------------------------------------------------------------------- | | **Net 30** | `NET30` | 30 | — | Règlement intégral sous 30 jours à compter de la date de facture. La condition standard la plus répandue. | | **Net 60** | `NET60` | 60 | — | Règlement intégral sous 60 jours. Courante pour les grosses commandes ou les relations anciennes. | | **2/10 net 30** | `2-10-30` | 30 | 2 % sous 10 jours | Réglez sous 10 jours et obtenez 2 % d'escompte. Sinon, la totalité est due à 30 jours. | | **Paiement à réception** | `DOR` | 0 | — | Le règlement est dû dès réception de la facture. Courante pour les petites affaires ou les affaires ponctuelles. | | **Paiement d'avance** | `PREPAID` | 0 | — | Règlement intégral exigé avant l'expédition des marchandises. Employée pour les nouveaux tiers ou les affaires risquées. | | **Net 90** | `NET90` | 90 | — | Délai de règlement étendu à 90 jours. Parfois employée pour les marchés publics ou les activités saisonnières. | ## Affecter des conditions de paiement à un tiers Chaque tiers peut porter des **conditions de paiement distinctes** pour son rôle fournisseur et pour son rôle client : - **Conditions fournisseur** — les conditions auxquelles **vous réglez le fournisseur** des marchandises que vous lui achetez. Votre fournisseur de métal peut par exemple vous accorder du Net 60. - **Conditions client** — les conditions auxquelles **le client vous règle** les marchandises que vous lui vendez. Un client de détail peut être en Paiement à réception là où un client entreprise est en Net 30. Un tiers qui est à la fois fournisseur et client peut avoir des conditions différentes de chaque côté de la relation. C'est courant — les conditions que vous négociez comme acheteur diffèrent souvent de celles que vous offrez comme vendeur. Lorsque des conditions de paiement sont affectées à un tiers, elles servent de **valeur par défaut** pour les nouvelles opérations avec lui. Elles se préremplissent sur les nouveaux documents, ce qui fait gagner du temps et garantit la cohérence. La liste **Conditions de paiement** se restreint depuis son **bouton de filtre** par **Actif** ou une fourchette de **Jours**, d'**Escompte %** ou de **Jours d'escompte** — « les conditions au-delà de 60 jours », c'est la question de la politique de crédit ([Utiliser les listes](../getting-started/working-with-lists.html#narrowing-the-list)). ## Créer des conditions de paiement 1. Ouvrez **Tiers > Conditions de paiement** et cliquez sur **Ajouter**. 2. Renseignez le nom, le code, les jours et, si besoin, les champs d'escompte. 3. Ajoutez une désignation si les conditions risquent d'être obscures pour d'autres membres de l'équipe. 4. Enregistrez. ### Bonnes pratiques de paramétrage - **Définissez votre jeu standard dès la mise en route** — créez toutes les conditions de paiement que votre organisation emploie couramment avant de commencer à saisir des tiers. Elles seront ainsi prêtes à être affectées. - **Gardez la liste maniable** — la plupart des organisations emploient 4 à 8 conditions standard. En avoir trop crée de la confusion et rend les règles plus difficiles à tenir. - **Employez des noms clairs et courants** — « Net 30 » et « 2/10 net 30 » se comprennent partout dans les affaires. Évitez d'inventer des noms non standard que votre équipe devrait apprendre. - **Désactivez plutôt que de supprimer** — quand une condition de paiement n'est plus employée, désactivez-la au lieu de la supprimer : ouvrez-la et prenez **Désactiver** dans **Autres actions** (les trois points). Des tiers existants et des documents d'archive y renvoient encore, et la suppression casserait ces renvois. Source: https://docs.beelocity.com/fr/business-partners/payment-terms/index.mdx