Nordlet

← Documentation / Guides

Importations bancaires et de paiements

Relevés camt.053, CSV Stripe, rapprochement des règlements PSP et flux JSON personnalisés.

Toutes les importations atterrissent en tant qu'opérations bancaires sur un compte bancaire (bank/accounts/create). Les opérations comportent un externalId : la réimportation d'un même fichier est sans risque, les lignes dont le couple (bankAccountId, externalId) existe déjà sont ignorées et comptabilisées dans le compteur skipped. Les opérations importées commencent avec le statut new et ne sont comptabilisées dans le grand livre qu'une fois Rapprochées (bank/transactions/match, avec bank/transactions/suggest-matches pour les suggestions de rapprochement).

L'application web expose ces mêmes importations sous Banque → Importer un fichier (téléversement de fichier, sélecteur de modèle).

Un rapprochement erroné s'annule avec bank/transactions/unmatch (Annuler le rapprochement dans Banque → Opérations). Les écritures validées ne sont jamais modifiées ni supprimées : un paiement rapproché d'une facture, ou une ligne qu'un modèle d'importation a comptabilisée dans un compte, fait l'objet d'une écriture de journal d'annulation inversant tous les débits et crédits, datée du jour indiqué par date (par défaut : aujourd'hui, et jamais avant la comptabilisation initiale). Le montant réglé et le statut de paiement de la facture sont ramenés au montant de cette ligne bancaire. Une ligne liée au règlement d'un prestataire de services de paiement (PSP) est seulement dissociée, car la comptabilisation du règlement appartient au lot. La ligne repasse au statut new et peut être rapprochée de nouveau. La date d'annulation doit tomber dans un exercice comptable ouvert.

Modèles d'importation

Un modèle d'importation désigne une source de données, liste les champs fournis par la source et associe les champs monétaires aux comptes du grand livre. Les modèles se gèrent sous Banque → Modèles d'importation et via bank/import-templates/create|update|delete|get|list.

POST /v1/bank/import-templates/create
{
  "name": "Stripe payments export",
  "type": "stripe",
  "fields": [
    { "name": "id" },
    { "name": "Created date (UTC)" },
    { "name": "Amount" },
    { "name": "Fee", "accountCode": "6800" },
    { "name": "Amount Refunded" }
  ],
  "metaFields": ["order_id"]
}
  • type prend l'une des valeurs suivantes : stripe, iso20022, bank_connection ou revolut.
  • Chaque champ possède un name et un accountCode optionnel. Seuls les champs monétaires acceptent un compte : Amount, Fee et Amount Refunded pour Stripe ; Ntry/Amt pour camt.053 ; transaction_amount.amount pour le flux bancaire. Le compte doit exister dans le plan comptable (créez-le avec ledger/accounts/create).
  • Le paramètre fields peut être omis ; il utilise alors par défaut la liste standard des champs du type concerné : les noms de colonnes du fichier Paiements → Exporter de Stripe (à l'exclusion des 19 colonnes Card …, que le formulaire laisse également décochées par défaut), les éléments camt.053 présents dans tout relevé (Stmt/Id, Stmt/Acct/Id/IBAN, Stmt/Bal/…, Ntry/Amt, Ntry/CdtDbtInd, Ntry/Sts, Ntry/BookgDt), ou les attributs renvoyés par un flux bancaire PSD2 par opération. Ajoutez ou supprimez des entrées pour correspondre à votre fichier : l'importateur lit également les éléments camt.053 optionnels Ntry/ValDt, Ntry/NtryRef, Ntry/AcctSvcrRef, Ntry/AddtlNtryInf, TxDtls/Refs/EndToEndId, TxDtls/Refs/TxId, TxDtls/RltdPties/Dbtr/Nm, TxDtls/RltdPties/DbtrAcct/Id/IBAN, TxDtls/RltdPties/Cdtr/Nm, TxDtls/RltdPties/CdtrAcct/Id/IBAN, TxDtls/RmtInf/Ustrd et TxDtls/AddtlTxInf.
  • Un champ Customer Email de Stripe peut comporter la mention "createPartner": true. L'importation crée alors un client (partenaire de type personne physique, qualifié de client) pour chaque adresse e-mail du fichier absente des partenaires existants, en utilisant Customer Description comme nom (ou l'e-mail si ce champ est vide) et les colonnes Card Address … comme adresse lorsque le fichier les contient. Les partenaires existants sont rapprochés par adresse e-mail, sans distinction de majuscules et minuscules. La réponse indique le nombre total dans customersCreated.
  • metaFields (réservé à Stripe) liste les clés de métadonnées associées à vos prélèvements. Stripe exporte chaque clé sous la forme d'une colonne <key> (metadata) ; cette liste est libre et peut s'avérer longue.
  • invoiceItemId (réservé à Stripe, optionnel) désigne un article du catalogue. Lorsqu'il est défini, chaque ligne de facture et d'avoir créée par l'importation fait référence à cet article (pour sa comptabilisation et, si invoiceVatRatePercent est vide, pour son taux de TVA) ; le libellé de la ligne provient toujours du prélèvement.
  • companyMetaField (réservé à Stripe) désigne l'une de ces clés en tant qu'indicateur d'entreprise. Lorsqu'un prélèvement contient true, 1, yes, company, business ou b2b dans cette colonne, le client créé devient un partenaire de type entreprise au lieu d'une personne physique.
  • invoiceMetaField (réservé à Stripe) désigne l'une de ces clés, par exemple un numéro de commande, et invoiceVatRatePercent indique le taux de TVA pour les factures générées à partir de celle-ci. Lors de l'importation, chaque ligne de prélèvement et de remboursement est regroupée par la valeur de cette clé :
    • une valeur correspondant à une facture de vente existante, à savoir un bon de commande dont le champ externalRef correspond à cette valeur (ecommerce/orders/create, tous canaux confondus) ou une facture dont le champ fullNumber correspond à cette valeur, associe le groupe à ladite facture ;
    • une valeur sans facture correspondante en crée une nouvelle : un partenaire issu de Customer Email (créé s'il est absent, comme pour createPartner), une ligne par prélèvement (Checkout Line Item Summary ou Description comme libellé, le montant du prélèvement exprimé TTC au taux invoiceVatRatePercent), une date d'émission égale à la date du premier prélèvement, et un traitement de TVA déterminé par l'entreprise et le pays de la carte. La facture est émise et comptabilisée immédiatement, et un bon de commande associé au canal stripe et portant cette valeur comme externalRef est enregistré afin que les importations ultérieures effectuent un rapprochement plutôt qu'une création ;
    • chaque prélèvement du groupe est ensuite rapproché de la facture en tant que paiement (comptabilisation de l'encaissement) ; chaque remboursement génère un avoir émis à l'encontre de la facture pour le montant remboursé et rapproche ce remboursement de celle-ci. Les compteurs renvoyés sont invoicesCreated, invoicesLinked, creditNotesCreated et paymentsMatched ; les groupes qui n'ont pu être traités (absence d'e-mail client, devises mixtes, facture liée toujours à l'état de brouillon ou déjà soldée) sont répertoriés dans warnings et conservés comme opérations bancaires à l'état new. Veillez à ne pas associer simultanément le champ Amount à un compte du grand livre dans le même modèle : un prélèvement rapproché d'une facture n'est pas comptabilisé une seconde fois, mais un prélèvement non rapproché le serait.
  • Les noms de modèles sont uniques par entreprise.
  • Les modèles camt.053 et de connexion bancaire comportent les mêmes options, lues directement depuis le relevé au lieu des colonnes Stripe :
    • Création des partenaires manquants : l'option createPartner sur la ligne du nom du débiteur (TxDtls/RltdPties/Dbtr/Nm, flux debtor.name) crée un client pour chaque payeur inconnu d'fonds entrants ; sur la ligne du nom du créancier (TxDtls/RltdPties/Cdtr/Nm, flux creditor.name), elle crée un fournisseur pour chaque bénéficiaire inconnu de fonds sortants. Les partenaires sont identifiés par leur IBAN (enregistré dans partner_bank_accounts), puis par leur nom exact ; un nouveau partenaire est considéré comme une entreprise si son nom comporte une forme juridique (UAB, MB, SIA, GmbH, Ltd, etc.), et comme une personne physique dans le cas contraire. Le total est renvoyé sous customersCreated (importation de fichier) ou partnersCreated (synchronisation du flux).
    • Rapprochement des factures par référence : l'option invoiceMetaField définie sur une ligne de communication ou de référence (TxDtls/RmtInf/Ustrd, TxDtls/RmtInf/Strd/CdtrRefInf/Ref, TxDtls/Refs/EndToEndId ; flux remittance_information, reference_number) rapproche chaque nouvelle ligne bancaire dont la référence, la communication ou le libellé contient le numéro d'une facture de vente émise non soldée (fonds entrants) ou d'une facture d'achat enregistrée (fonds sortants), et comptabilise le paiement. Lorsque l'IBAN du payeur est enregistré sur un partenaire, ou que le nom du payeur est identique au nom ou au code d'un partenaire, la facture doit appartenir à ce partenaire. Un paiement émanant d'un payeur inconnu n'est lié que s'il correspond exactement au solde restant de la facture et que le numéro de facture comporte son préfixe de série, garantissant qu'un numéro brut tel qu'un montant n'est jamais interprété comme une référence. Un paiement supérieur au solde restant n'est jamais rapproché. Les lignes échouant à ces vérifications restent à l'état new pour un rapprochement manuel et sont listées dans les avertissements (warnings). Avec advanceInvoices: true, un encaissement non rapproché provenant d'un partenaire connu génère une facture d'acompte émise (de type advance) pour le montant calculé au taux invoiceVatRatePercent ou celui de l'article invoiceItemId, et rapproche le paiement de celle-ci ; le partenaire devant être connu, veillez à cocher également la ligne du débiteur.
    • Règles de comptabilisation par code d'opération : outre Ntry/Amt / transaction_amount.amount, la liste des champs intègre des lignes de règles Ntry/BkTxCd=CHRG, =INTR, =TAXE, Ntry/CdtDbtInd=DBIT, =CRDT (flux : bank_transaction_code=…, credit_debit_indicator=…). Une ligne est imputée au compte de la première règle à laquelle elle correspond : d'abord la famille de codes d'opération bancaire, puis le sens, et enfin la ligne de montant brut. Les lignes de règles ne sont pas vérifiées par rapport au fichier.
    • Frais bancaires du partenaire : l'option createPartner sur la ligne de règle …=CHRG crée un fournisseur dont le nom correspond à celui de la banque (provenant du relevé Stmt/Acct/Svcr/FinInstnId/Nm, de la banque de la connexion, ou du nom du compte bancaire du grand livre) et comptabilise chaque frais avec ce partenaire.
    • Les modèles de connexion bancaire sont sélectionnés pour chaque compte de flux via bank/feeds/accounts/configure (Banque → Connexions dans l'application), ce qui définit également syncSchedule (manual, daily, weekly, monthly) : l'API synchronise automatiquement les comptes dotés d'un calendrier dès que leur période est échue. Les modèles sont appliqués à chaque exécution de bank/feeds/sync ; la réponse de la synchronisation renvoie alors également les indicateurs posted, partnersCreated, invoicesLinked, invoicesCreated, paymentsMatched et warnings.

Transmettez templateId à bank/statements/import à la place de format : le type du modèle détermine l'analyseur syntaxique, et le fichier doit impérativement contenir tous les champs listés dans le modèle. Tout fichier omettant l'un d'eux est rejeté avec le code HTTP 422, accompagné du nom de la colonne ou de l'élément manquant. Les champs de métadonnées ne sont pas obligatoires. Les modèles de connexion bancaire décrivent un flux PSD2 en direct et ne peuvent pas servir à l'importation de fichiers.

Un modèle ISO 20022 lit également les fichiers au format MT940 : un fichier débutant par {1: ou :20: (ou transmis avec "format": "mt940") est analysé en tant que MT940, et les règles de rapprochement par référence ainsi que de comptabilisation du modèle sont appliquées à ses lignes. La vérification des éléments est ignorée pour le format MT940, et les règles Ntry/BkTxCd=… ne s'appliquent jamais aux lignes MT940 puisque ce format ne transporte aucun code d'opération bancaire ISO 20022 ; utilisez à la place les règles Ntry/CdtDbtInd=….

Un compte bancaire ne gère qu'une seule devise. Un relevé exprimé dans une autre devise est rejeté avec le code HTTP 422 (dans le cas d'un fichier camt.053 contenant des relevés en plusieurs devises pour un même IBAN, seul le relevé correspondant à la devise du compte est importé), de même qu'une ligne envoyée à bank/transactions/import avec une devise différente de celle du compte.

Chaque mouvement généré à partir d'un champ doté d'un accountCode est comptabilisé lors de l'importation sous la forme d'une écriture unique : l'entrée de fonds débite le compte du grand livre de la banque et crédite le compte associé ; la sortie de fonds débite le compte associé et crédite le compte du grand livre de la banque. Les montants sont convertis dans la devise de base à la date du mouvement. L'opération bancaire est ensuite rapprochée (matched) de cette écriture de journal (matchedDocumentType = journal_transaction) et n'est plus proposée pour le rapprochement de factures. La réponse indique le nombre dans posted. Les mouvements issus de champs non associés restent à l'état new et sont rapprochés des factures comme auparavant ; par exemple, associez Fee au compte de charges de frais PSP et laissez Amount non associé afin que les prélèvements continuent d'être rapprochés des factures de vente.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "templateId": "…",
  "content": "id,Created date (UTC),Amount,…"
}

ISO 20022 camt.053 (XML open banking)

Les banques lituaniennes (Swedbank, SEB, Luminor, Šiaulių bankas, etc.) vous permettent de télécharger vos relevés de compte au format XML camt.053 ISO 20022 depuis leur banque en ligne, généralement sous la rubrique d'exportation ou de téléchargement de relevés, au format "ISO XML" ou "camt.053". Ce même format est renvoyé par les API d'information sur les comptes PSD2.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "format": "camt053",
  "content": "<?xml version=\"1.0\"…>…"
}
  • Un fichier peut contenir plusieurs relevés ; l'IBAN de chaque relevé doit correspondre à celui du compte bancaire (les relevés dépourvus d'IBAN, ou les comptes sans IBAN, sont acceptés en l'état).
  • Les références d'écriture (AcctSvcrRef/NtryRef, avec repli sur un hachage du contenu) constituent l'externalId.
  • La réponse renvoie les métadonnées de chaque relevé : identifiant du relevé, période, soldes d'ouverture et de clôture, nombre d'opérations.
  • Le nom de la contrepartie, l'IBAN et le motif du paiement sont extraits pour chaque écriture en vue du rapprochement.

Les paiements dans l'autre sens sont exportés au format pain.001 via bank/payments/export.

CSV Revolut Business

Téléchargez le relevé d'opérations d'un compte Revolut Business au format CSV et importez-le à l'aide du modèle intégré Revolut Business (templateId: "builtin-revolut"). Chaque entreprise dispose de ce modèle sans avoir à le créer : bank/import-templates/list-builtin le liste, bank/import-templates/get le renvoie, tandis que bank/import-templates/update et bank/import-templates/delete le refusent avec le code HTTP 400. Dans l'application, il apparaît en premier sous Banque → Modèles d'importation ; son ouverture affiche ses paramètres, et son enregistrement génère votre propre modèle d'entreprise modifiable.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "templateId": "builtin-revolut",
  "content": "Date started (UTC),Date completed (UTC),ID,Type,State,…"
}
  • Seules les lignes dont le champ State est égal à COMPLETED sont importées. Les autres lignes (par exemple PENDING) sont ignorées et comptabilisées dans warnings ; elles seront importées lors d'un chargement ultérieur d'un fichier où elles apparaîtront comme complétées.
  • Chaque ligne devient une opération bancaire dont la date provient de Date completed (UTC), le montant de Total amount, la devise de Payment currency, l'identifiant ID sert d'externalId et Description constitue le libellé.
  • La contrepartie d'une sortie de fonds est constituée de Beneficiary name et Beneficiary IBAN ; pour un paiement par carte sans bénéficiaire, il s'agit du commerçant indiqué dans Description. La contrepartie d'une entrée de fonds est constituée de Sender name et Sender account.
  • Les lignes sont regroupées par compte et par devise. Le champ International account number doit correspondre à l'IBAN du compte bancaire, et seules les lignes libellées dans la devise du compte bancaire sont importées.
  • Pour chaque ligne, l'importateur vérifie que le solde de la ligne précédente additionné de Total amount est égal à Balance, et liste dans warnings toutes les lignes où cette condition n'est pas remplie.
  • Le fichier doit obligatoirement contenir les colonnes Date completed (UTC), ID, Type, State, Description, Payment currency, Total amount, Reference, Sender name et Beneficiary name.

À chaque importation, le modèle intégré procède ainsi :

  • il crée un client pour tout émetteur inconnu d'entrées de fonds, et un fournisseur pour tout bénéficiaire ou commerçant de carte inconnu pour les sorties de fonds, selon les modalités décrites ci-dessus à la section Création des partenaires manquants ;

  • il rapproche chaque ligne dont la référence (Reference) ou la description (Description) contient le numéro d'une facture d'achat ou de vente ouverte, et comptabilise le paiement en appliquant les vérifications de la section Rapprochement des factures par référence ci-dessus ;

  • il impute les lignes pour lesquelles aucune facture n'a été trouvée, en fonction de leur type (Type), au compte défini par une règle de comptabilisation :

    Type Règle de comptabilisation Compte par défaut Plan roumain Écriture
    FEE bank.fees 6800 627 débiter le compte de la règle, créditer le compte du grand livre de la banque ; partenaire : un fournisseur nommé d'après le compte bancaire
    CARD_PAYMENT bank.cardPayments 6209 628 débiter le compte de la règle, créditer le compte du grand livre de la banque, sans TVA
    TOPUP bank.topUps 3010 1012 débiter le compte du grand livre de la banque, créditer le compte de la règle

    Les lignes d'autres types, tels que TRANSFER, restent à l'état new en vue d'un rapprochement.

Modifiez les comptes avec ledger/posting-rules/update ; le modèle intégré appliquera les nouveaux comptes dès l'importation suivante. Il est impossible de désactiver une règle de comptabilisation : pour importer des paiements par carte ou des rechargements sans les comptabiliser, créez un modèle d'entreprise de type revolut dépourvu des lignes de règles Type=CARD_PAYMENT ou Type=TOPUP et effectuez l'importation avec celui-ci. Un paiement par carte ainsi comptabilisé ne sera pas rapproché de la facture du fournisseur si celle-ci est enregistrée ultérieurement ; comptabilisez l'un ou l'autre, mais pas les deux.

Un modèle d'entreprise de type revolut utilise les mêmes colonnes et peut imputer les lignes par type à l'aide des lignes de règles Type=FEE, Type=CARD_PAYMENT, Type=TRANSFER et Type=TOPUP. Une importation effectuée avec "format": "revolut-csv" sans spécifier de modèle importe les lignes sans exécuter aucune de ces étapes.

CSV Stripe

Exportez les données depuis le tableau de bord Stripe (l'un ou l'autre de ces rapports convient) :

  • Rapports → Solde → Évolution détaillée du solde par activité (recommandé) : colonnes balance_transaction_id, created_utc, currency, gross, fee, net, reporting_category, description.
  • Paiements → Exporter : colonnes id, Created (UTC), Amount, Fee, Currency, Description, Customer Description.
POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "format": "stripe-csv",
  "content": "balance_transaction_id,created_utc,currency,gross,fee,net,…"
}

Créez un compte bancaire dédié pour Stripe (par exemple nommé "Stripe", rattaché au compte GL 2710 ou à son propre sous-compte) : le solde Stripe se comporte comme un compte bancaire, les prélèvements y affluent, les frais en sont déduits, et les versements transfèrent le solde vers votre véritable compte bancaire.

Comportement lors de l'importation :

  • Chaque opération de solde génère une opération bancaire pour le montant brut (externalId = identifiant de l'opération de solde).
  • Des frais non nuls génèrent une seconde opération de signe opposé (externalId = <id>:fee, contrepartie "Stripe"), permettant ainsi de rapprocher ou de comptabiliser les frais en tant que charges séparément du chiffre d'affaires. Les frais restitués sur les remboursements apparaissent sous forme de montants positifs.
  • Les lignes de versement (Payout) sont importées sous forme d'opérations uniques négatives ; rapprochez-les de l'opération entrante correspondante sur le relevé de votre véritable compte bancaire.
  • Les lignes dont le montant est nul sont ignorées ; la date est extraite de created_utc (UTC).
  • Les lignes d'exportation de paiements n'ayant entraîné aucun mouvement d'argent sont ignorées : Captured = false (autorisations ou captures différées) et Status Échoué/Annulé.
  • Un montant remboursé (Amount Refunded) non nul engendre une troisième opération négative (externalId = <id>:refund) datée du Refunded date (UTC), garantissant qu'aucun remboursement partiel ou total inclus dans les lignes de paiement ne soit perdu.

Rapprochement des règlements PSP (rapports de versement Stripe)

Pour ventiler un versement global en ses commandes, remboursements, frais et rétrofacturations sous-jacents, utilisez les points de terminaison de règlements plutôt que l'importation de relevés bruts. Deux types d'exports Stripe sont acceptés (détectés automatiquement) :

  • Rapports → Versements → Rapprochement des versements, détaillé (types de rapports payout_reconciliation.itemized.* ou payout_reconciliation.by_id.itemized.*) : précis, une ligne par opération de solde ; option recommandée sur les comptes de production.
  • Paiements → Exporter (paiements unifiés) : l'export au niveau du prélèvement ; fonctionne en mode test/bac à sable où le rapprochement des versements n'est pas disponible. Les prélèvements capturés sont regroupés par identifiant de versement dans la colonne Transfer ; les lignes non capturées ou échouées sont ignorées (skippedNotSettled) ; un Amount Refunded non nul crée une ligne de remboursement synthétique dans le lot de versement du prélèvement, ce qui constitue une approximation dans la mesure où le remboursement a pu être effectivement réglé lors d'un versement ultérieur. Les références de rapprochement proviennent de l'identifiant du prélèvement, de PaymentIntent ID, de Invoice Number, de Client Reference ID et de chaque colonne … (metadata) (par exemple, un numéro de commande inclus dans les métadonnées).

Un fichier CSV unique peut s'étendre sur de nombreux versements. Stripe télécharge le rapport détaillé un fichier par section (…_charge_…, …_refund_…, …_fee_…) ; importez-les tous : les lignes d'un versement déjà importé se fusionnent dans le lot existant (signalé dans le compteur updated) tant que celui-ci n'a pas été validé, et les totaux du lot sont recalculés.

POST /v1/bank/settlements/import
{
  "bankAccountId": "…",
  "provider": "stripe",
  "content": "balance_transaction_id,created_utc,…,reporting_category,…,automatic_payout_id,…"
}

Comportement lors de l'importation :

  • Les lignes sont regroupées par automatic_payout_id en lots de règlements (un lot par versement), accompagnés des totaux bruts, des frais et nets (la somme des champs net de chaque ligne représentant le montant versé sur votre banque). La réimportation d'un versement est ignorée (compteur skipped). Les lignes non encore rattachées à un versement ainsi que les lignes de type payout proprement dites sont ignorées et comptabilisées séparément.
  • Chaque ligne de prélèvement, de remboursement ou de litige fait l'objet d'un rapprochement automatique avec une facture de vente en utilisant, dans l'ordre : le champ externalRef d'une commande e-commerce (toute valeur provenant de order_id, payment_intent_id, source_id, charge_id ou de toute colonne *_metadata[...]), le numéro fullNumber d'une facture figurant dans ces colonnes, et pour les remboursements et rétrofacturations, le champ charge_id d'un prélèvement précédemment rapproché (provenant du même fichier ou d'importations antérieures).
  • Contrôlez les résultats avec bank/settlements/list / bank/settlements/get ; corrigez les éléments restants via bank/settlements/match { lineId, invoiceId } (ou invoiceId: null pour supprimer le rapprochement).

L'appel POST /v1/bank/settlements/post { id, date?, commissionPercent? } comptabilise le lot entier sous la forme d'une écriture de journal équilibrée unique et solde les factures rapprochées (paidAmount/paymentStatus, webhooks sale_invoice.paid) :

  • Débit du compte GL de la banque pour le versement net ; débit des frais PSP (settlements.fees, par défaut 6800) pour les frais retenus et les lignes de frais.
  • Crédit des comptes clients pour chaque prélèvement rapproché ; les remboursements et rétrofacturations inversent cette écriture. L'imputation est plafonnée au solde restant de chaque facture, tout excédent étant affecté au compte d'attente assorti d'un avertissement.
  • Prélèvements non rapprochés : si commissionPercent est renseigné, ils sont ventilés entre le chiffre d'affaires sur commissions (settlements.commissionRevenue, par défaut 5001) et une dette envers le vendeur (settlements.sellerPayable, par défaut 4499), ce qui correspond au modèle de place de marché où les fonds encaissés appartiennent pour l'essentiel aux vendeurs. En l'absence de ce paramètre, ils sont immobilisés dans settlements.suspense (par défaut 4440, avances reçues).
  • Les lignes platform_earning (frais d'application Stripe Connect) sont imputées au chiffre d'affaires sur commissions ; les lignes transfer (versements aux vendeurs connectés) réduisent la dette envers le vendeur.
  • Les quatre comptes peuvent être redéfinis par entreprise par le biais des règles de comptabilisation (ledger/posting-rules).
  • Une ligne dont le prélèvement, les frais ou le remboursement a déjà été importé sur un autre compte bancaire par le biais de l'exportation de paiements Stripe (bank/statements/import) n'est pas comptabilisée dans les frais, les comptes clients ou le compte d'attente. Son montant net est crédité à la place sur le compte du grand livre de ce compte bancaire, de sorte que le compte bancaire Stripe se solde versement après versement. La propriété summary.clearedAmount représente le total transféré de cette manière ; toute ligne dont le montant diffère de celui détenu par ce compte est mentionnée dans warnings. S'il ne reste rien à comptabiliser, le lot est validé avec une valeur nulle pour journalTransactionId.

Les points de terminaison bank/settlements/list et /get renvoient, pour chaque lot, clearedNet, clearingDifference (les lignes de versement moins les montants détenus pour elles par l'autre compte bancaire ; égal à zéro en cas de concordance) et clearingOpenCount (les lignes présentant un écart ou un mouvement non comptabilisé) ; /get renvoie des informations similaires par ligne sous les libellés clearingBankAccountId, clearingBooked, clearingDifference et clearingUnposted. Les lignes de remboursement d'un même prélèvement sont comparées ensemble, car l'exportation des paiements ne conserve que le total remboursé. Une exportation de paiements Stripe importée après la validation de son versement ignore les mouvements de ce versement et les signale dans warnings.

La TVA sur la commission elle-même fait l'objet d'une facturation distincte (émission d'une facture de commission au vendeur) ; la ventilation se borne à répartir les liquidités encaissées.

Versements dans une autre devise

Le journal est systématiquement tenu dans la devise de base de l'entreprise, mais un versement dans une devise différente est comptabilisé automatiquement, sans saisie manuelle requise :

  • Le lot est converti au taux de change applicable à la date de comptabilisation (date, avec repli sur la date du versement, puis sur la date du jour). Ce taux correspond au taux propre de l'entreprise pour cette devise (reference/exchange-rates/set) lorsqu'il est au moins aussi récent que le taux officiel, ou à défaut, au taux officiel le plus récent à cette date ou avant celle-ci. En l'absence de taux à cette date ou à une date antérieure, l'appel échoue avec le code 422 et indique reference/exchange-rates/sync.
  • Chaque compte est converti au taux du lot, à l'exception des comptes clients, qui sont soldés au taux de change fxRate en vigueur lors de l'émission de chaque facture. L'écart résiduel entre ces deux taux est imputé au compte de gains de change bank.fxGain (par défaut 5803) ou de pertes de change bank.fxLoss (par défaut 6803) en tant que différence de change réalisée, garantissant ainsi l'équilibre de l'écriture.
  • L'objet summary de la réponse renvoie le taux de change fxRate utilisé ainsi que la différence de change résultante (exchangeDifference), et le lot conserve le taux auquel il a été comptabilisé. Une facture rapprochée dont la devise diffère de celle du lot n'est pas soldée : son montant est affecté au compte d'attente avec un avertissement.
  • Une limite d'importation subsiste : un versement unique dont les lignes mélangent plusieurs devises est rejeté avec le code 422, de même qu'une réimportation dont la devise diffère du lot déjà enregistré pour ce versement.

Flux manuels / personnalisés

N'importe quel autre flux peut être transmis sous forme de données JSON brutes :

POST /v1/bank/transactions/import
{
  "bankAccountId": "…",
  "transactions": [
    { "date": "2026-07-01", "amount": "-25.00", "currency": "EUR",
      "counterpartyName": "…", "description": "…", "externalId": "unique-ref-1" }
  ]
}

Fournissez un identifiant stable externalId par opération afin de garantir l'idempotence des réimportations.