Relevés bancaires

Un relevé (bank_statement) est un fichier que vous téléversez dans une entreprise : PDF, JPEG, PNG ou HEIC, 50 Mo au maximum. Scribee en lit l'en-tête - IBAN, période, soldes - puis les lignes d'opérations, que vous relisez et corrigez.

Un compte bancaire est ce qui reçoit le fichier (Comptes bancaires). Le téléversement de relevés sert les comptes qu'aucune connexion bancaire n'alimente : un compte rattaché à une connexion refuse le téléversement, parce que ses opérations arrivent déjà par Synchronisations bancaires.

Un fichier, un relevé

Le téléversement est multipart et accepte plusieurs parties. Chaque fichier devient son propre relevé, avec son compte, son état et son erreur. Le 202 répond donc une collection - une ligne par fichier, dans l'ordre de la requête - et vous interrogez N identifiants plutôt qu'un seul. Un fichier dont l'extraction échoue n'entraîne jamais ses voisins avec lui.

Un 202 ne signifie jamais que l'extraction est terminée. Il signifie que les fichiers existent et qu'ils vous appartiennent.

Ce que cette surface publie

Onze opérations, et rien d'autre sur les relevés :

Verbe et chemin	Ce qu'elle fait
`POST /api/v1/workspaces/{workspace_id}/companies/{company_id}/bank_statements`	Téléverse un lot de fichiers
`GET /api/v1/workspaces/{workspace_id}/companies/{company_id}/bank_statements`	Liste les relevés de l'entreprise
`GET /api/v1/bank_statements/{id}`	Lit un relevé
`DELETE /api/v1/bank_statements/{id}`	Supprime un relevé et son fichier
`POST /api/v1/bank_statements/{id}/retry`	Relance une extraction
`GET /api/v1/bank_statements/{id}/lines`	Lit les lignes extraites
`PATCH /api/v1/bank_statements/{id}/lines`	Corrige les lignes et les soldes
`POST /api/v1/bank_statements/{id}/commit`	Comptabilise le relevé, et tout son téléversement avec lui
`POST /api/v1/bank_statements/{id}/route_account`	Nomme le compte d'un relevé dont le routage est ambigu
`POST /api/v1/bank_statements/{id}/exclude`	Exclut un fichier de la comptabilisation de son téléversement
`POST /api/v1/bank_statements/{id}/include`	Réintègre un fichier exclu dans la comptabilisation de son téléversement

La comptabilisation passe par POST /api/v1/bank_statements/{id}/commit. Il n'existe en revanche AUCUNE opération pour confirmer une révision séparément, et c'est délibéré - la comptabilisation ouvre elle-même la révision des fichiers qu'elle va passer.

Deux modes, choisis au téléversement

mode vaut extract par défaut : le relevé naît en pending et une extraction est demandée. Demandée, pas garantie - elle peut ne pas être mise en file, ou ne pas tourner du tout si la fonction est désactivée pour l'entreprise, et le relevé reste pending dans les deux cas.

mode: archive conserve le fichier et ne lance rien : le relevé naît directement en archived. Un relevé archivé n'a ni ligne à réviser, ni extraction à relancer, et il ne peut pas être supprimé par l'API.

Toutes les parties d'un même téléversement doivent porter le même mode : un téléversement est un lot, et des parties qui divergent décrivent deux téléversements.

Téléverser des relevés

Un token portant le scope write est requis, ainsi qu'un en-tête Idempotency-Key.

Cet appel écrit : il stocke les fichiers et, en mode extract, met une extraction en file. Chaque relevé créé reste supprimable tant que son extraction n'a enregistré aucune opération - committed: false.

En mode extract, le fichier est lu par un prestataire tiers. L'extraction le transmet à Mistral AI, prestataire d'OCR, sous la forme d'une URL signée vers le fichier stocké : Mistral vient chercher le document à cette adresse. L'URL est valable 5 minutes, ce qui borne la RE-RÉCUPÉRATION du fichier par cette adresse - et rien d'autre. L'extraction n'a lieu que si la fonction est activée pour l'entreprise ; si elle ne l'est pas, aucun appel n'est émis et le relevé reste pending.

En mode archive, rien n'est mis en file et le fichier ne quitte pas la plateforme.

curl -X POST https://app.scribee.tech/api/v1/workspaces/YOUR_WORKSPACE_ID/companies/YOUR_COMPANY_ID/bank_statements \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Idempotency-Key: 3f1c6d20-8a55-4d0e-9f3b-7c2e5a81b004" \
  -F "statements[][file]=@releve-juillet.pdf" \
  -F "statements[][bank_account_id]=771"

Réponse 202, une ligne par fichier :

{
  "data": [
    {
      "id": 8801,
      "company_id": 34,
      "bank_account_id": 771,
      "mode": "extract",
      "state": "pending",
      "progress": null,
      "error_code": null,
      "error_message": null,
      "retryable": true,
      "started_at": null,
      "finished_at": null,
      "iban_masked": null,
      "iban_last4": null,
      "opening_balance": null,
      "closing_balance": null,
      "period_start": null,
      "period_end": null,
      "operations_count": 0,
      "filename": "releve-juillet.pdf",
      "byte_size": 184320,
      "committed": false,
      "excluded": false,
      "excluded_at": null
    }
  ]
}

Deux refus portent sur le téléversement entier, et dans les deux cas rien n'est stocké : une partie qui nomme un compte hors de cette entreprise, et un fichier dont le format ou la taille est refusé. Ce sont des requêtes mal formées, pas le résultat d'un traitement - contrairement à un échec d'extraction, qui reste propre à son fichier.

L'enfilement partiel répond 202, pas 422

Les fichiers peuvent être acceptés et stockés alors qu'une extraction au moins n'a pas pu être mise en file. Ce n'est pas un refus : les relevés existent, donc la réponse reste un 202, et c'est meta.unqueued_statement_ids qui nomme les lignes dont l'extraction n'a pas démarré.

{
  "data": [
    { "id": 2559, "state": "pending", "filename": "releve-07.pdf" },
    { "id": 2560, "state": "pending", "filename": "releve-08.pdf" }
  ],
  "meta": {
    "unqueued_statement_ids": [2560]
  }
}

Les identifiants sont des entiers, les mêmes que l'id publié dans data.

C'est l'ABSENCE de meta qui est le signal. Sur un téléversement ordinaire la clé ne figure pas du tout dans le corps - ni null, ni {} : elle est absente. Vous branchez donc sur sa présence, sans avoir à inspecter un tableau vide.

Vérifiez meta AVANT de commencer à interroger. Un 422 vous aurait forcé à regarder ; un 202 ne le fait pas, et un client qui ignore meta interrogera indéfiniment un relevé qui ne bougera jamais. Dans l'exemple ci-dessus, 2559 a été mis en file et 2560 ne l'a pas été - et les deux affichent "state": "pending". Rien d'autre que meta ne les distingue.

Le remède est POST /api/v1/bank_statements/{id}/retry sur chaque identifiant de meta.unqueued_statement_ids, et exactement ceux-là.

Ne téléversez pas les fichiers une seconde fois. Les relevés de data existent déjà : un second téléversement crée des relevés en double, et leur extraction sera de toute façon refusée comme doublon - voir plus bas. Vous n'y gagnez rien, et vous laissez derrière vous des relevés failed qui n'ont rien à voir avec l'enfilement.
Ne relancez pas les autres. Ils sont mis en file ; les relancer paie une seconde extraction pour rien.
Ne traitez pas ce 202 comme un échec. Rejouer l'Idempotency-Key est sans danger et ne crée rien - voir ci-dessous.

Rejouer une clé d'idempotence

Si vous n'avez pas vu passer la réponse - un délai d'attente, une connexion coupée -, renvoyez la MÊME requête avec la MÊME Idempotency-Key. Vous récupérez le corps stocké, octet pour octet, meta compris, et rien n'est créé : pas de second lot, pas de seconde extraction. La réponse porte alors l'en-tête Idempotency-Replayed: true. Les noms d'en-têtes HTTP étant insensibles à la casse, comparez-les sans tenir compte de celle-ci plutôt que d'attendre cette graphie exacte.

C'est la manoeuvre à faire après un délai d'attente, et ce n'est pas une condition d'erreur.

Un 409 idempotency_request_in_progress ne signifie pas toujours qu'un appel tourne encore. Il signifie que la clé est retenue et que son résultat n'est pas rejouable - le plus souvent parce qu'un premier appel est effectivement en cours, mais aussi lorsqu'un premier appel a produit son effet puis a échoué au moment de composer sa réponse. Dans ce second cas la clé reste retenue jusqu'à la purge des 24 heures, et attendre ne changera rien.

Allez donc voir ce que le premier appel a fait, plutôt que d'attendre qu'il finisse. Listez les relevés de l'entreprise : s'ils existent, le téléversement a abouti et il ne reste qu'à relancer ceux dont l'extraction ne tourne pas. Ne reprenez pas la même clé en espérant qu'elle se libère, et ne retentez pas le téléversement sous une clé neuve avant d'avoir regardé - ce serait dupliquer les relevés déjà créés.

Le même fichier, déjà téléversé

Un fichier dont les octets sont identiques à ceux d'un fichier déjà téléversé dans cette entreprise n'est pas extrait une seconde fois. Le téléversement répond un 202 parfaitement ordinaire, sans meta : le relevé est créé et son extraction est bien mise en file. C'est cette EXTRACTION qui est refusée, un instant plus tard, quand elle tourne. Le relevé passe en failed, et son error_message nomme le relevé qui possède déjà ce fichier.

{
  "id": 8802,
  "state": "failed",
  "error_code": "operation_failed",
  "error_message": "Ce fichier a déjà été importé (relevé 8801) ; il n'a pas été extrait une seconde fois.",
  "retryable": true,
  "operations_count": 0,
  "committed": false
}

L'identité comparée est celle des OCTETS : l'empreinte du fichier stocké et sa taille, jamais l'IBAN ni la période. Ces deux-là sont PRODUITS par l'extraction, donc les lire coûterait justement la lecture que ce refus existe pour éviter. Deux fichiers qui décrivent la même période sans être le même document sont donc extraits tous les deux, et le même document envoyé deux fois ne l'est qu'une.

La comparaison ne sort jamais de l'entreprise. Le même relevé téléversé dans deux entreprises d'un même groupe est extrait deux fois, et le téléversement d'une entreprise n'est jamais visible depuis une autre.

Un relevé archived ne bloque rien, et un relevé failed ne bloque que s'il détient déjà des lignes. Ce qui donne à un relevé la propriété du fichier, ce sont ses LIGNES d'abord et son état ensuite : un relevé qui porte des opérations possède ses octets quel que soit son état - failed compris - et quel que soit son identifiant. Une extraction peut en effet échouer APRÈS avoir écrit ses lignes, celles-ci étant enregistrées plusieurs étapes avant que le relevé ne soit finalisé, et ce relevé-là refuse bien un re-téléversement identique. Re-téléverser un document dont l'extraction avait échoué reste le recours normal tant que cet échec n'a rien laissé derrière lui, et committed est le champ qui le dit : committed: false sur le relevé failed et le même fichier est extrait à nouveau, committed: true et il est refusé en doublon. Ne lisez pas operations_count pour cela : il n'est écrit qu'à la finalisation de l'extraction, donc un échec survenu après l'écriture des lignes ne le met jamais à jour. Un fichier conservé en mode: archive n'a jamais été lu et ne détient donc aucune ligne : un téléversement ultérieur du même document en mode: extract est extrait.

Quand deux téléversements simultanés portent le même fichier, exactement un des deux est extrait - le plus ancien des deux relevés, par identifiant - et l'autre est refusé. Les deux ne se refusent jamais l'un l'autre.

Ce refus n'est pas une erreur HTTP et ne figure dans aucun tableau de la section Les erreurs : il arrive APRÈS le 202, sur le relevé, exactement comme un échec d'extraction ordinaire. Ne le confondez pas avec l'enfilement partiel ci-dessus : celui-là se lit dans la réponse elle-même, à la présence de meta, et laisse le relevé pending jusqu'à ce que vous le relanciez ; celui-ci ne se lit que sur le relevé, après coup, et le laisse failed. Un relevé refusé en doublon ne figure jamais dans meta.unqueued_statement_ids, puisque son extraction a bien été mise en file - c'est elle qui refuse.

Pour un intégrateur c'est le résultat recherché. Après un délai d'attente, la manoeuvre est de rejouer la même Idempotency-Key, qui ne crée rien ; un renvoi qui re-téléverse le même fichier sous une clé neuve obtient, lui, un relevé failed et non une seconde lecture du même document.

Suivre l'extraction

Un token read suffit. state est le champ à interroger.

Un pending qui ne bouge pas ne travaille pas forcément. pending signifie stocké et pas encore révisable - il ne promet PAS qu'une extraction soit en cours. Un fichier attend à pending que son extraction ait été mise en file, que l'extraction par IA soit désactivée pour l'entreprise, ou que le téléversement n'ait pas pu la mettre en file (meta.unqueued_statement_ids), et l'état seul ne permet pas de distinguer ces trois cas. processing est l'état qui, lui, signifie que le travail tourne. Bornez donc votre interrogation : un relevé qui reste pending est un relevé à relancer par POST /api/v1/bank_statements/{id}/retry, pas un relevé à attendre plus longtemps - lorsque son retryable vaut true. Un pending dont retryable vaut false appartient à une entreprise dont l'extraction par IA est désactivée : aucune extraction ne viendra, et la relance est refusée par operation_failed tant que le réglage n'est pas réactivé dans Scribee.

curl https://app.scribee.tech/api/v1/bank_statements/8801 \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

state prend l'une de ces huit valeurs :

`state`	Ce qu'il signifie
`pending`	Le fichier est stocké et pas encore révisable - une extraction peut tourner, ou pas
`processing`	L'extraction est en cours
`completed`	L'extraction s'est terminée avec un relevé complet
`partial`	Elle s'est terminée en sachant sa lecture tronquée
`failed`	Elle a échoué
`archived`	Le fichier a été conservé sans extraction (`mode: archive`)
`reviewing`	Un humain a ouvert la révision du fichier
`posted`	Le relevé a été comptabilisé et la révision est close

posted est produit par POST /api/v1/bank_statements/{id}/commit - voir « Comptabiliser un relevé » plus bas.

reviewing, lui, n'a aucune opération qui le produise pour lui-même. Cette API ne publie aucun appel de confirmation de révision : la comptabilisation ouvre la révision juste avant de comptabiliser, dans le même appel. Vous pouvez tout de même LIRE reviewing, car l'ouverture de la révision n'est pas annulée par un refus de comptabilisation : un lot refusé laisse en reviewing les fichiers dont la révision avait été ouverte. Corriger une ligne d'un tel fichier le ramène à l'état où l'extraction l'avait laissé, comme partout ailleurs.

started_at et finished_at sont les horloges de l'extraction elle-même. started_at est l'instant où une passe a PRIS le fichier et commencé, celui où le relevé est passé en processing : ni le téléversement, ni la mise en file. finished_at est l'instant où cette passe s'est ARRÊTÉE. Une durée se calcule donc bien sur ces deux champs, sous les quatre réserves qui suivent.

Un null est une réponse, pas un trou. Un relevé pending n'a encore été pris par aucune passe et ne porte donc ni début ni fin ; un relevé archived n'en portera jamais, mode: archive ne lançant aucune extraction ; un relevé processing publie un début et pas de fin, ce qui est le cas normal et non le signe d'un fichier bloqué. Un relevé antérieur à la mise en place de ces deux horloges n'en porte aucune non plus.

finished_at n'est pas une preuve de succès. Il est écrit sur CHAQUE issue terminale, et pas seulement sur les bonnes : une lecture completed ou partial, un fichier refusé en doublon, et la tentative qui a épuisé ses reprises l'écrivent toutes. C'est state qui dit ce qui s'est passé, et il le reste.

Une relance remet le chronomètre à zéro. POST /api/v1/bank_statements/{id}/retry efface les deux valeurs - le relevé repart pending avec started_at et finished_at à null - puis la nouvelle passe inscrit son propre started_at en prenant le fichier. Une durée calculée après une relance mesure donc la DERNIÈRE tentative, jamais l'historique complet.

finished_at ne bouge plus ensuite, et ce n'est pas updated_at. Corriger un solde par PATCH /api/v1/bank_statements/{id}/lines écrit sur le relevé sans déplacer la fin de l'extraction qui l'avait produit. Ne substituez donc jamais l'un à l'autre : updated_at est la dernière écriture, finished_at est la fin de la lecture.

partial n'est pas un arrondi de completed. L'extraction s'est achevée en sachant qu'elle n'avait pas tout lu : ses lignes valent la relecture, et une relance vaut la peine.

error_code vaut operation_failed sur tout échec terminal, et null sinon ; error_message dit pourquoi, en toutes lettres. progress vaut toujours null : rien ne produit de pourcentage pour une extraction, et un chiffre inventé serait pire que rien.

L'IBAN lu sur le document ne sort jamais en entier. iban_masked n'en laisse voir que le code pays et les quatre derniers caractères - FR*********************0189 - et iban_last4 répète ces quatre caractères pour qu'un humain reconnaisse le compte. En dessous de huit caractères, la valeur est entièrement masquée et iban_last4 vaut null.

committed passe à true une fois que les opérations du relevé ont été enregistrées ; operations_count en donne le nombre. Les deux ne sont pas la même horloge : committed se lit sur les LIGNES elles-mêmes, alors que l'extraction écrit le compteur quelques étapes plus tard - un relevé en cours d'extraction peut donc rapporter committed: true pendant que operations_count vaut encore 0. C'est committed qu'il faut lire, jamais le compteur. C'est la frontière que la suppression applique : un relevé à true n'est plus supprimable, et la réconciliation ne déplace pas cette clé.

account_detection dit COMMENT le compte du relevé a été résolu, et c'est la clé à lire avant de comptabiliser. auto : l'IBAN lu correspondait à un compte et un seul. manual : le compte a été désigné, par l'interface Scribee ou par POST /api/v1/bank_statements/{id}/route_account. ambiguous : l'IBAN ne correspondait à aucun compte, ou à plusieurs - et toute comptabilisation est refusée tant qu'un relevé ambiguous en fait partie. Lisez cette clé après l'extraction plutôt que de découvrir le refus au moment de comptabiliser.

excluded dit si le fichier est exclu de la comptabilisation de son téléversement, et excluded_at depuis quand - null tant qu'il y participe. POST /api/v1/bank_statements/{id}/exclude les écrit et POST /api/v1/bank_statements/{id}/include les efface : voir « Exclure un fichier de son téléversement » plus bas.

La liste et ses six filtres

curl "https://app.scribee.tech/api/v1/workspaces/YOUR_WORKSPACE_ID/companies/YOUR_COMPANY_ID/bank_statements?state=completed&per_page=50" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

Les relevés sortent du plus récent au plus ancien, paginés (meta porte current_page, per_page, total_pages et total_count).

Filtre	Ce qu'il restreint
`state`	Un état d'extraction
`mode`	`extract` ou `archive`
`bank_account_id`	Les relevés routés vers un compte
`period_start_from`	Les relevés dont la période COMMENCE à cette date ou après (ISO 8601)
`period_end_to`	Les relevés dont la période FINIT à cette date ou avant (ISO 8601)
`committed`	`true` ou `false`, selon que les opérations ont été enregistrées

Une valeur hors de l'ensemble attendu ne déclenche pas d'erreur : elle ne correspond simplement à rien et la page revient vide. Un relevé dont l'extraction n'a pas su lire la période ne porte pas de date et n'est retenu par aucun des deux filtres de période.

Lire les lignes extraites

curl https://app.scribee.tech/api/v1/bank_statements/8801/lines \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

Les lignes sortent dans l'ordre du relevé - operation_date croissant, puis id - et sont paginées comme toute collection.

{
  "data": [
    {
      "id": 55021,
      "operation_date": "2026-07-14",
      "value_date": null,
      "label": "VIR SEPA ACME",
      "amount": "300.0000",
      "direction": "incoming",
      "operation_type": "transfer",
      "corrected": false
    }
  ],
  "meta": { "current_page": 1, "per_page": 20, "total_pages": 1, "total_count": 1 }
}

amount est signé : positif à l'entrée, négatif à la sortie, et jamais en désaccord avec direction. corrected dit qu'un opérateur a déjà touché un champ de cette ligne. value_date et operation_type sont publiés et ne sont pas corrigeables.

label ne publie jamais un IBAN en entier. Un IBAN cité dans le libellé est rendu sous la forme de iban_masked - FR*********************0189 - selon la règle décrite pour les opérations bancaires, et la description de chaque opération embarquée par include=bank_operations suit la même règle. Un label que vous corrigez est enregistré tel que vous l'envoyez, puis relu sous cette même forme masquée.

Deux lignes du même jour et du même montant qui ne diffèrent que par leur direction sont deux lignes distinctes, chacune avec son id : une entrée et une sortie de même montant le même jour sortent toutes les deux. Identifiez une ligne par son id, jamais par le couple operation_date + amount.

amount est une CHAÎNE décimale, à l'échelle de sa colonne : quatre décimales, toujours quatre. La colonne est un DECIMAL(19, 4), donc dix-neuf chiffres significatifs, là où le double dans lequel JSON.parse lit un nombre JSON en porte environ seize : un montant proche du haut de la plage vous arriverait déjà arrondi. La chaîne est ce qui traverse le trajet intact. Lisez-la avec le type décimal de votre langage, jamais avec un Float - un parseFloat sur "300.0000" vous ramène exactement au nombre que la chaîne existe pour éviter.

Les jours qu'une connexion bancaire tient déjà

Un même compte physique peut exister deux fois dans une entreprise : le compte qui reçoit vos relevés, et un compte alimenté par une connexion bancaire qui porte le même IBAN. Sur ce compte physique, la première source qui écrit un jour le garde.

Une ligne dont l'operation_date tombe sur un jour où le compte connecté porte déjà des opérations n'est pas créée, quels que soient ses chiffres. Elle est absente de GET /api/v1/bank_statements/{id}/lines : pour ce jour, les opérations du compte sont celles de la connexion bancaire.
Un jour sur lequel le compte du relevé porte déjà des lignes de relevé reste au relevé, même si la connexion bancaire a importé des opérations pour ce jour depuis.
Une correction ne déplace pas une ligne sur un jour que tient la connexion bancaire. Un PATCH /api/v1/bank_statements/{id}/lines dont une operation_date tombe sur un jour où le compte connecté porte des opérations est refusé en entier par un 422 validation_failed, dont le message nomme le jour ; rien n'est écrit.
Une ligne ainsi écartée n'est pas un défaut de lecture : elle ne fait pas passer le relevé en partial et n'écrit rien dans error_message.
La règle suppose un IBAN des deux côtés. Elle ne s'applique qu'entre comptes de la même entreprise dont les IBAN sont égaux ; si l'un des deux comptes n'a pas d'IBAN, aucun jour n'est écarté à ce titre. Elle ne s'applique pas non plus quand l'IBAN lu sur le document diffère de celui du compte du relevé.
Les jours écartés sont signalés dans l'interface Scribee : l'écran de révision du relevé les liste à l'opérateur. L'API ne les publie pas.

La règle joue dans les deux sens. Une synchronisation de la connexion bancaire n'importe pas de nouvelle opération sur un jour que les lignes d'un relevé tiennent déjà : pour ce jour, les opérations du compte sont celles du relevé. Les opérations que la connexion avait déjà importées pour un jour continuent d'être mises à jour, sauf si la banque en déplace une sur un jour que tient un relevé : elle est alors retirée, comme une opération supprimée. Quand un relevé rend un jour - relevé supprimé, réaffecté à un autre compte, compte bancaire du relevé supprimé, ou date d'une ligne corrigée -, la synchronisation suivante relit le compte depuis le début et importe les opérations des jours qu'aucune ligne de relevé ne tient plus.

Réviser : les lignes et les soldes en un seul appel

La ressource relevé elle-même n'accepte aucun PATCH : corriger un solde est le même acte de révision que corriger une ligne, donc les deux voyagent ensemble sur PATCH /api/v1/bank_statements/{id}/lines. Un token write est requis ; l'en-tête Idempotency-Key est accepté sans être exigé, la correction convergeant sur les valeurs envoyées.

La soumission est atomique. Un seul chiffre mal formé refuse l'ensemble et n'écrit rien : vous ne vous retrouvez jamais avec un relevé à moitié modifié derrière un 422.

curl -X PATCH https://app.scribee.tech/api/v1/bank_statements/8801/lines \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "opening_balance": "1000.00",
        "closing_balance": "1300.00",
        "lines": [
          { "id": 55021, "label": "VIR SEPA ACME SARL", "amount": "300.00", "direction": "incoming" }
        ]
      }'

Quatre règles gouvernent le corps :

Chaque entrée de lines porte l'id d'une ligne de CE relevé. Un identifiant absent, ou appartenant à un autre relevé, refuse toute la soumission.
amount est une magnitude, jamais un chiffre signé : le signe est dérivé de direction, si bien que les deux ne peuvent pas se contredire. Corriger direction seule réécrit donc aussi le montant.
Un solde absent signifie « laisse-le tel quel », ce qui n'est pas la même chose que l'effacer. Les deux soldes s'écrivent en décimal simple, sans séparateur de milliers et avec au plus quatre décimales.
Une soumission porte au plus 500 lignes. Au-delà, l'ensemble est refusé par un 422 sans que rien ne soit écrit ; découpez la révision en plusieurs appels.

Seuls opening_balance, closing_balance, et sur une ligne operation_date, label, amount et direction sont corrigeables. Une ligne déjà réconciliée ou passée en comptabilité est refusée.

Les trois états qui acceptent une révision

completed, partial et reviewing : l'extraction est terminée et le fichier est encore ouvert. Les cinq autres refusent, chacun pour sa raison.

posted - la comptabilisation est faite, et corriger une ligne ensuite invaliderait une écriture comptable qui existe déjà.
pending - le fichier est stocké et pas encore révisable. Cela ne dit rien d'une extraction en cours : voir plus haut, un pending n'est pas la preuve qu'un travail tourne.
processing - l'extraction tourne, il n'y a donc rien de définitif à corriger.
failed - la dernière extraction a échoué. Cela ne veut pas dire que le relevé n'a aucune ligne : une relance repart d'un relevé partial ou reviewing sans toucher aux lignes de la passe précédente, donc un échec après relance laisse ces lignes en place. GET /api/v1/bank_statements/{id}/lines les sert toujours ; c'est la révision qui est fermée, pas la lecture. Elles redeviennent corrigeables lorsqu'une extraction réussie ramène le fichier à completed ou partial.
archived - le fichier a été conservé sans qu'aucune extraction ne tourne.

Tout état hors de ces trois-là est refusé par un 422 portant statement_not_reviewable. Ouvrir la révision ne restreint rien : dans reviewing comme dans completed ou partial, les deux corrections restent entièrement autorisées - n'importe quelle ligne du relevé qui n'est pas déjà réconciliée ou passée en comptabilité, et l'un comme l'autre des deux soldes.

La réponse est paginée, et porte trois clés de plus

Les lignes révisées reviennent paginées comme sur le GET - corriger une ligne d'un relevé de 400 n'en renvoie pas 400 - et meta transporte, à côté du bloc de pagination, opening_balance, closing_balance et reconciliation_errors.

{
  "data": [
    {
      "id": 55021,
      "operation_date": "2026-07-14",
      "value_date": null,
      "label": "VIR SEPA ACME SARL",
      "amount": "300.0000",
      "direction": "incoming",
      "operation_type": "transfer",
      "corrected": true
    }
  ],
  "meta": {
    "current_page": 1,
    "per_page": 20,
    "total_pages": 1,
    "total_count": 1,
    "opening_balance": "1000.0000",
    "closing_balance": "1300.0000",
    "reconciliation_errors": []
  }
}

Les deux soldes de meta sont des chaînes décimales à quatre décimales, comme l'amount d'une ligne, et pour la même raison : opening_balance et closing_balance sont eux aussi des DECIMAL(19, 4). Les deux côtés de opening_balance + somme des lignes = closing_balance sont donc des chaînes, et c'est ce qui permet de recontrôler l'égalité avec un type décimal sans qu'un côté ait perdu des chiffres que l'autre a gardés. L'échelle est fixe et complétée : ce que vous envoyez en "300.00" vous revient en "300.0000" - le même nombre à l'échelle publiée, donc comparez en décimal plutôt qu'en égalité de chaînes.

Une reconciliation_errors non vide n'est pas un échec : c'est un avertissement porté par un 200. La correction a été appliquée, et cette liste vous dit que le relevé ne s'équilibre plus - soit opening_balance plus la somme des mouvements de la période ne donne pas closing_balance, soit l'IBAN lu ne correspond pas au compte. Elle est recalculée à chaque révision, donc elle ne périme jamais.

Les mouvements de cette équation ne se limitent pas aux lignes que /lines vous sert. Pour chaque jour que l'extraction a écarté (voir plus haut, « Les jours qu'une connexion bancaire tient déjà »), l'équation compte, à la place des lignes absentes, le net des opérations du compte connecté pour ce jour, tel qu'il était au moment de l'extraction. Ce net est enregistré avec le relevé : les synchronisations suivantes de la connexion bancaire ne le modifient pas, aucun autre jour du compte connecté n'entre dans l'équation, et period_start et period_end n'y jouent aucun rôle. Seule une nouvelle extraction le recalcule. Un routage vers un autre compte (POST /api/v1/bank_statements/{id}/route_account) efface les jours écartés : l'équation signale alors les lignes manquantes, jusqu'à ce qu'une nouvelle extraction relise le fichier contre le compte choisi. Quand le relevé compte un jour écarté, la somme des lignes de /lines ne suffit donc pas à refaire le calcul. La comptabilisation contrôle le même équilibre, sur les mêmes montants.

Ce qu'une correction fait à `state`

Une correction ne déplace state que si une révision était ouverte, c'est-à-dire si le relevé était en reviewing : elle invalide cette révision, et le relevé revient alors à l'état où l'extraction l'avait laissé - partial si l'extraction avait signalé ce qu'elle n'avait pas su lire, completed si elle n'avait rien signalé. Corrigé depuis completed ou partial, donc sans révision ouverte, le relevé garde son état.

Une correction ne promeut jamais un relevé. Elle porte sur la révision, pas sur l'extraction : corriger une ligne d'un fichier lu de façon tronquée ne le déclare pas complet. C'est error_message qui porte la distinction - l'extraction l'écrit, la correction n'y touche pas, et un relevé qui le porte revient en partial.

Le PATCH répond les lignes révisées, pas le relevé : c'est GET /api/v1/bank_statements/{id} qui vous donne le nouvel état.

retryable suit state, si bien qu'un relevé revenu en partial reste relançable - tant que l'extraction par IA est activée pour l'entreprise. Corriger une ligne ne vous ferme pas la relance de l'extraction.

Router un relevé vers un compte

À lire seulement si account_detection vaut ambiguous. L'extracteur lit l'IBAN du document et le rapproche des comptes de l'entreprise ; quand il ne correspond à aucun, ou à plusieurs, le fichier sort en ambiguous - et toute comptabilisation le refuse tant que la question n'est pas tranchée. Cet appel la tranche.

curl -X POST https://app.scribee.tech/api/v1/bank_statements/8801/route_account \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"bank_account_id": 771}'

Le 200 retourne le relevé sur le compte choisi, avec account_detection passé à manual. Le scope write est requis.

Le relevé ET toutes ses lignes sont repointés sur le compte nommé, et la comptabilité déjà projetée contre l'ancien compte est retirée - la comptabilisation reposera sur le nouveau. Les CHIFFRES extraits ne sont pas touchés : une révision déjà confirmée le reste, et aucune confirmation supplémentaire n'est à faire entre cet appel et la comptabilisation.

Le compte nommé doit appartenir à l'entreprise du relevé, ne pas être alimenté par un agrégateur bancaire - un compte de connexion porte déjà ses propres mouvements et n'est pas une destination pour un document que vous téléversez - et ne pas être archivé.

Aucun en-tête Idempotency-Key n'est requis : router deux fois vers le même compte, c'est le même fichier au même endroit. Nommer un compte DIFFÉRENT la seconde fois est en revanche un second routage, et il sera effectué - l'en-tête ne vous en protégerait pas, lire la réponse si.

Les deux familles de refus se distinguent par details :

sans details, statement_not_reviewable : le FICHIER n'est pas ouvert au routage. Il est archivé, encore en extraction, déjà comptabilisé, il a été stocké en mode: archive, ou son routage n'a jamais été ambigu (account_detection vaut auto). Rien de ce que vous envoyez n'y changera quoi que ce soit : relisez le relevé.
avec details.bank_account_id, validation_failed : le COMPTE que vous avez nommé n'est pas une destination pour ce fichier - il appartient à une autre entreprise, il est synchronisé depuis un agrégateur, il est archivé, ou le déplacement a été refusé parce que les lignes de ce fichier portent déjà un travail de rapprochement. Renvoyez avec un autre compte.

Comptabiliser un relevé

C'est l'appel qui passe les lignes extraites en comptabilité et clôt la révision. Le 200 retourne le relevé en posted, avec committed: true.

curl -X POST https://app.scribee.tech/api/v1/bank_statements/8801/commit \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Idempotency-Key: 3f1c8a90-2d47-4b6e-9c05-8ab21e7f4d33"

Le scope write est requis, et l'en-tête Idempotency-Key aussi. La requête ne porte pas de corps.

Votre POST est la confirmation, et il n'y en a pas d'autre à faire. Scribee ne comptabilise pas des chiffres dont personne n'a pris la responsabilité, et c'est cet appel qui porte cette assertion : vous avez lu les lignes (GET /api/v1/bank_statements/{id}/lines), corrigé ce qui devait l'être (PATCH /api/v1/bank_statements/{id}/lines), et vous les comptabilisez. Il n'existe aucune opération « confirmer la révision » à appeler d'abord - la comptabilisation ouvre elle-même la révision des fichiers qu'elle va passer, juste avant de les passer.

L'unité est le TÉLÉVERSEMENT, pas le fichier

Tous les relevés nés d'un même téléversement multipart appartiennent à un même lot, et un lot est comptabilisé en entier ou pas du tout. Comptabiliser n'importe lequel de ses fichiers les comptabilise donc TOUS : un téléversement de trois fichiers se passe en un seul appel, sur l'identifiant de votre choix.

La contrepartie est symétrique. Un seul fichier voisin qui doit encore être traité refuse l'appel entier, par un 422 portant batch_unresolved, sans que rien n'ait été écrit. Comptabilisez une fois par téléversement, pas une fois par fichier ; un second appel nommant un voisin trouve le travail déjà fait.

Un fichier que vous avez exclu ne compte pas : il ne bloque pas l'appel et n'est pas comptabilisé avec les autres. C'est la sortie prévue pour un fichier qui ne sera jamais comptabilisable - voir « Exclure un fichier de son téléversement » plus bas.

Recomptabiliser est sans danger

Un relevé déjà comptabilisé répond 200, pas un refus, et ne comptabilise rien une seconde fois : il vous revient tel qu'il est, en posted et committed: true. Ce n'est PAS un statement_not_reviewable - vous renvoyer vers l'interrogation d'un fichier posted n'aurait pas de fin. Un appel rejoué après un timeout est donc toujours sûr.

Un `4xx` n'est pas une annulation

Toute la comptabilisation tient dans une seule transaction, si bien que chacun des six refus ci-dessous laisse le grand livre exactement dans l'état où il était, et que la même Idempotency-Key peut être renvoyée une fois corrigé ce qui a été refusé.

Mais un 4xx ne prouve pas à lui seul que rien n'a été écrit. Si la plateforme échoue pendant qu'elle construit la réponse, la comptabilisation, elle, a déjà abouti - et vous recevez un 4xx portant sur une comptabilité qui EST au grand livre.

C'est ce que votre Idempotency-Key ferme, et c'est la raison de l'envoyer. Rejouez la même clé : un 409 portant idempotency_key_consumed vous dit que le premier appel est allé jusqu'au bout et a comptabilisé. Ce code est terminal - rien ne tourne, rien n'aboutira, n'interrogez donc pas en boucle. Confirmez par GET /api/v1/bank_statements/{id} : state: posted et committed: true signifient que le travail est fait.

idempotency_request_in_progress est l'autre moitié du 409 et ne dit pas la même chose : un premier appel court encore, ou s'est terminé sans qu'on sache ce qu'il avait fait. Là aussi, c'est le relevé qu'il faut lire plutôt que la clé qu'il faut rejouer en boucle. La clé se libère 24 heures après sa première réception.

idempotency_key_reuse est inatteignable ici : une comptabilisation n'a pas de corps, son empreinte ne peut donc jamais différer de celle du premier appel. Et un premier appel terminé normalement rejoue son 200 stocké plutôt que d'entrer en conflit.

Les six refus, et où est le remède

Branchez sur code : les six ne sont pas interchangeables, et c'est lui qui dit CE QUE vous devez changer.

`code`	Ce qui bloque	Ce qu'il faut changer
`statement_not_reviewable`	L'état propre du fichier : il est `archived`, ou son extraction n'est pas terminée	Interrogez le relevé jusqu'à ce que `state` bouge. Corriger des lignes n'y changera rien. Pas de `details`
`statement_excluded`	Le fichier que vous avez NOMMÉ est exclu de son téléversement (`excluded: true`) : la comptabilisation le laisserait de côté, et elle ne passe pas ses voisins en son nom	Nommez un autre fichier du téléversement, ou réintégrez celui-ci par `POST /api/v1/bank_statements/{id}/include` puis comptabilisez de nouveau. Interroger le relevé ne sert à rien. Pas de `details`
`account_not_ready`	Le compte bancaire visé ne peut pas recevoir de comptabilité : aucun journal rattaché, compte désactivé, ou banque qui ne le partage plus	Le remède est sur le COMPTE. Interroger le relevé ne sert à rien
`batch_unresolved`	Un AUTRE fichier du même téléversement doit encore être traité	`details` nomme lesquels, et pourquoi - voir ci-dessous
`validation_failed`	L'extraction de CE fichier est défectueuse	`details` est indexé par le champ à corriger via `PATCH /api/v1/bank_statements/{id}/lines`
`posting_failed`	Le grand livre a refusé la projection, ou un rapprochement confirmé n'a pas pu être imputé	Rien n'a été comptabilisé et le relevé reste comptabilisable : c'est le seul refus qu'il vaut la peine de rejouer tel quel, une fois la configuration comptable corrigée

validation_failed porte aussi details.idempotency_key quand l'en-tête manque ou sort de 1-255 caractères, ce qui est refusé avant même d'entrer dans l'opération.

Lire un `batch_unresolved`

Le relevé que vous avez nommé est comptabilisable : ce qui bloque est l'un de ses voisins. message dit combien de fichiers bloquent, et details dit LESQUELS - indexé <statement_id>.<raison>, en tableaux de chaînes comme partout ailleurs.

{
  "error": "unprocessable_entity",
  "code": "batch_unresolved",
  "details": {
    "8802.not_reviewed": ["Personne n'a confirmé la revue de ce fichier : ouvrez sa revue, vérifiez les valeurs extraites et confirmez-la avant de comptabiliser le dépôt."]
  }
}

Lisez la raison, pas la phrase. Le texte ci-dessus est celui de l'interface Scribee, où la revue est un acte humain avec son écran ; sur cette API il n'y a rien à « ouvrir » ni à « confirmer », puisqu'aucune opération de confirmation de révision n'y est publiée. C'est le suffixe qui porte le remède.

.not_reviewed veut dire que ce fichier-là n'avait pas de quoi être confirmé, et cela se lit sur SON état : appelez GET /api/v1/bank_statements/8802. pending ou processing veut dire qu'il faut laisser l'extraction se terminer ; failed, qu'il faut le relancer par son propre retry - ou, s'il ne doit pas être comptabilisé, l'exclure. Un fichier exclu n'apparaît jamais dans details. Un voisin simplement non confirmé ne bloque PAS - la comptabilisation ouvre elle-même la révision de tout le téléversement, donc un fichier completed est confirmé par votre appel. Ce qui ne peut pas l'être est un fichier qui n'a pas encore de chiffres.

Tout autre suffixe nomme un champ de CE fichier à corriger par son propre PATCH /api/v1/bank_statements/8802/lines. Puis comptabilisez de nouveau, une seule fois.

Exclure un fichier de son téléversement

Un téléversement est comptabilisé en entier ou pas du tout, si bien qu'un fichier en échec bloque tout son téléversement : nommé, la comptabilisation est refusée par statement_not_reviewable ; voisin du fichier nommé, par batch_unresolved. L'exclure est la sortie explicite : la comptabilisation ne l'attend plus et le laisse de côté. À l'inverse, un fichier valide que vous ne voulez pas en comptabilité ne bloque rien : la comptabilisation ouvre sa révision et le passe avec le reste du téléversement, sauf si vous l'excluez d'abord.

curl -X POST https://app.scribee.tech/api/v1/bank_statements/8802/exclude \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

Le 200 retourne le relevé avec excluded: true et excluded_at renseigné. POST /api/v1/bank_statements/{id}/include fait l'inverse : le 200 retourne le relevé avec excluded: false et excluded_at à null. Le scope write est requis pour les deux.

Aucun en-tête Idempotency-Key n'est requis ; il est accepté sans être exigé. Exclure un fichier déjà exclu ne change rien et garde le premier excluded_at, et réintégrer un fichier qui n'est pas exclu ne change rien non plus.

L'exclusion ne retire le fichier que de la comptabilisation. Son state et ses lignes restent tels quels : GET /api/v1/bank_statements/{id}/lines les sert toujours, et elles continuent de tenir leurs jours face à une connexion bancaire (voir « Les jours qu'une connexion bancaire tient déjà »). Une relance ne lève pas l'exclusion : seul POST /api/v1/bank_statements/{id}/include ramène le fichier.

Ce que fait la comptabilisation ensuite. Comptabiliser en nommant un AUTRE fichier du téléversement passe tous les fichiers non exclus et laisse l'exclu à l'écart : il n'est pas comptabilisé, ne passe pas en posted, et n'apparaît pas dans le details d'un batch_unresolved. Comptabiliser en nommant le fichier exclu lui-même est refusé par un 422 portant statement_excluded, sans que rien n'ait été écrit. Un téléversement dont tous les fichiers sont exclus ne peut donc pas être comptabilisé : quel que soit le fichier nommé, la réponse est statement_excluded.

{
  "error": "unprocessable_entity",
  "code": "statement_excluded",
  "message": "Ce fichier est exclu de son dépôt : il ne peut pas être revu. Réintégrez-le au dépôt pour le revoir."
}

Lisez le code, pas la phrase : le texte est celui de l'interface Scribee, qui parle de revue ; sur cette API, c'est la comptabilisation qu'il refuse. Le remède est un acte, jamais une attente - nommez un autre fichier du téléversement, ou réintégrez celui-ci.

Réintégrer rend le fichier tel qu'il était. Même state, mêmes lignes : un fichier qui bloquait la comptabilisation avant son exclusion la bloque de nouveau jusqu'à ce qu'il soit résolu.

Un fichier encore en extraction, en échec ou déjà en révision peut être exclu. Deux états le refusent : posted, dont les écritures sont déjà au grand livre, et archived, qui ne participe jamais à la comptabilisation. L'exclusion comme la réintégration y sont refusées par un 422 portant statement_not_reviewable, sans details.

Relancer une extraction

Lisez retryable avant d'appeler : l'indication et le point de terminaison lisent la même règle. Quatre états ne se relancent pas : archived, completed, posted et processing. Et aucun relevé ne se relance tant que l'extraction par IA est désactivée pour l'entreprise : retryable vaut alors false dans tous les états.

curl -X POST https://app.scribee.tech/api/v1/bank_statements/8801/retry \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Idempotency-Key: 7c9a1e44-5b02-4c81-a0d7-9e63f1b28a55"

Le 202 retourne le relevé remis à pending, l'erreur précédente effacée. Le scope write est requis, et l'en-tête Idempotency-Key aussi.

Un 422 operation_failed ne porte pas sur l'état du relevé, et il a deux causes. Si l'extraction par IA est désactivée pour l'entreprise, le relevé est laissé exactement tel qu'il était et rien n'a été mis en file : réactivez le réglage dans Scribee avant de rappeler. Sinon, c'est l'extraction qui n'a pas pu être mise en file : le relevé a été remis à pending sans que rien ne le lise, et ce même appel est le remède - relancez-le. Dans les deux cas, attendre que l'état change ne mènerait nulle part.

Un relevé refusé parce que son fichier avait déjà été téléversé rapporte retryable: true, et la relance ne le débloque pas. Elle le remet bien en pending et relance l'extraction, qui applique de nouveau la même règle et le ramène en failed avec le même message. Tant que le relevé qui possède le fichier existe, le second ne sera pas extrait.

Supprimer un relevé

curl -X DELETE https://app.scribee.tech/api/v1/bank_statements/8801 \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

La suppression est définitive et emporte le fichier stocké. Le corps de la réponse est le relevé tel qu'il était au moment où vous en avez demandé la suppression - il est sérialisé avant l'effacement, puisqu'ensuite son fichier n'existe plus pour être décrit.

Elle n'est possible que tant que l'extraction n'a enregistré aucune opération, et c'est committed qui porte cette frontière - pas la réconciliation. Un relevé qui rapporte committed: true est refusé par un 422 portant statement_not_reviewable quel que soit son state - même si personne n'a rapproché ces lignes - et ce refus est définitif : le relevé ne redeviendra pas supprimable. Un relevé archived est refusé aussi.

Ce qui reste supprimable est donc un relevé dont l'extraction n'a rien produit, ce qui en est l'usage principal : annuler un import raté. Le scope destroy convient, write également.

Les erreurs

Statut	`code`	Quand
`422`	`validation_failed`	Aucune partie ne porte de fichier ; `details` nomme `file`
`422`	`validation_failed`	Les parties ne s'accordent pas sur `mode` ; `details` nomme `mode`
`422`	`validation_failed`	Une partie nomme un compte hors de cette entreprise ; `details` nomme `bank_account`
`422`	`validation_failed`	Le format ou la taille d'un fichier est refusé, ou le compte visé est alimenté par une connexion bancaire ; `details` nomme `base`
`422`	`validation_failed`	`lines` n'est pas une liste ; `details` nomme `lines`
`422`	`validation_failed`	Une entrée de `lines` ne porte pas d'`id`, ou nomme une ligne d'un autre relevé
`422`	`validation_failed`	Un chiffre mal formé : séparateur de milliers, plus de quatre décimales, valeur hors plage
`422`	`validation_failed`	Une ligne déjà réconciliée ou passée en comptabilité
`422`	`statement_not_reviewable`	L'état du relevé interdit la révision, la relance ou la comptabilisation
`422`	`operation_failed`	La relance est refusée : l'extraction par IA est désactivée pour l'entreprise, ou l'extraction n'a pas pu être mise en file - voir « Relancer une extraction »
`422`	`statement_not_reviewable`	La suppression est refusée : le relevé rapporte `committed: true`, ou il est `archived`
`422`	`statement_not_reviewable`	Le routage est refusé : le fichier n'est pas ouvert au routage, ou son routage n'a jamais été ambigu
`422`	`statement_not_reviewable`	L'exclusion ou la réintégration est refusée : le relevé est `posted` ou `archived`
`422`	`validation_failed`	Le routage nomme un compte qui n'est pas une destination pour ce fichier ; `details` nomme `bank_account_id`
`422`	`account_not_ready`	Le compte visé par la comptabilisation ne peut recevoir aucune comptabilité
`422`	`statement_excluded`	La comptabilisation nomme un fichier exclu de son téléversement
`422`	`batch_unresolved`	Un autre fichier du même téléversement bloque la comptabilisation ; `details` nomme lesquels
`422`	`posting_failed`	Le grand livre a refusé la projection, ou un rapprochement confirmé n'a pas pu être imputé
`422`	`validation_failed`	L'en-tête `Idempotency-Key` manque sur le téléversement, la relance ou la comptabilisation
`409`	`idempotency_key_reuse`	La même `Idempotency-Key` a déjà servi pour un téléversement DIFFÉRENT. Rien n'a été stocké par cet appel : prenez une clé neuve, ou renvoyez les fichiers d'ORIGINE sous la même clé pour rejouer le `202` stocké
`409`	`idempotency_request_in_progress`	La clé est retenue et son résultat n'est pas rejouable - voir ci-dessous
`409`	`idempotency_key_consumed`	Un premier appel portant cette clé est allé jusqu'au bout, a produit un effet, puis a été refusé. Terminal : n'interrogez pas en boucle, vérifiez ce que le premier appel a fait
`404`	-	Le relevé n'est pas atteignable par vos habilitations

Un refus qui porte sur l'état du relevé plutôt que sur un champ ne transporte pas de details : c'est code qu'il faut lire.

Tout 422 de ce téléversement vaut validation_failed, et aucun n'a rien stocké : le lot est refusé en entier, donc corrigez le champ nommé et renvoyez la requête - sous la même Idempotency-Key si vous le souhaitez. Les valeurs de details sont toujours des tableaux de CHAÎNES, et message est toujours présent.

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": ["Les comptes connectés via Bridge ne peuvent pas être utilisés pour les téléversements de relevés."]
  }
}

{
  "error": "unprocessable_entity",
  "code": "statement_not_reviewable",
  "message": "n'est pas dans un état qui autorise cette opération"
}

statement_not_reviewable nomme un ÉTAT, pas une erreur passagère : relisez le relevé plutôt que de rappeler le même point de terminaison.

Un fichier, un relevé​

Ce que cette surface publie​

Deux modes, choisis au téléversement​

Téléverser des relevés​

L'enfilement partiel répond 202, pas 422​

Rejouer une clé d'idempotence​

Le même fichier, déjà téléversé​

Suivre l'extraction​

La liste et ses six filtres​

Lire les lignes extraites​

Les jours qu'une connexion bancaire tient déjà​

Réviser : les lignes et les soldes en un seul appel​

Les trois états qui acceptent une révision​

La réponse est paginée, et porte trois clés de plus​

Ce qu'une correction fait à state​

Router un relevé vers un compte​

Comptabiliser un relevé​

L'unité est le TÉLÉVERSEMENT, pas le fichier​

Recomptabiliser est sans danger​

Un 4xx n'est pas une annulation​

Les six refus, et où est le remède​

Lire un batch_unresolved​

Exclure un fichier de son téléversement​

Relancer une extraction​

Supprimer un relevé​

Les erreurs​

Référence API​