Déclarer les transactions

Les ventes aux particuliers et les opérations facturées avec l'étranger ne passent pas par la facturation électronique : elles se déclarent par l'e-reporting. Pour une facture de vente que vous déposez sur Scribee, cette déclaration est établie seule : Scribee lit les identifiants de l'acheteur et en déduit laquelle des deux obligations la vente porte. Les endpoints de cette page servent à ce qu'aucune facture déposée ne porte, à ce que la déclaration automatique refuse, et à corriger ce qui a été déclaré : en agrégé pour le B2C, facture par facture pour les factures émises hors du circuit de facturation électronique. Les enregistrements que vous créez se rattachent à la déclaration dont vous donnez l'identifiant, et se relisent par les endpoints de liste.

Ce que Scribee déclare seul depuis vos factures

Déposer une facture de vente suffit. Les deux obligations s'excluent : une vente ne fait jamais l'objet d'un dépôt de facture et d'une déclaration d'opération.

Acheteur de la facture déposée	Ce que Scribee fait
Porteur d'un SIREN, et établi dans le territoire de TVA français ou sans pays renseigné	La facture est déposée auprès du PPF, et rien n'est déclaré en e-reporting (voir Le cycle de vie d'une facture). Une exception, pour un vendeur établi dans l'outre-mer hors du territoire de TVA : voir L'outre-mer hors du territoire de TVA.
Sans SIREN, mais porteur d'un autre identifiant - numéro de TVA intracommunautaire, immatriculation étrangère -, ou porteur d'un SIREN mais établi hors du territoire de TVA français, dans un pays étranger comme dans l'outre-mer hors de ce territoire	Une facture d'e-reporting est créée dans la déclaration de la période, sans que vous ayez à l'y déposer.
Sans aucun identifiant	La vente est comptée dans l'agrégat B2C du jour, dans la déclaration de la période.

Le territoire de l'acheteur se lit sur son country_code, et sur son postal_code pour une adresse FR (voir L'outre-mer hors du territoire de TVA). Un SIREN ne suffit donc pas au dépôt de facture : il faut encore que l'acheteur soit établi dans le territoire de TVA français. Un acheteur porteur d'un SIREN dont le country_code n'est pas renseigné reste sur la première ligne, et c'est le dépôt qui réclame ce pays (voir Le cycle de vie d'une facture).

La catégorie de TVA des lignes ne change rien à ce tableau. Une facture dont toutes les lignes et ventilations de TVA sont en catégorie O (hors champ de la TVA) le suit comme les autres : Scribee n'en déduit pas qu'il s'agit de débours. Elle est déclarée par une facture d'e-reporting pour un acheteur de la deuxième ligne, et comptée en TNT1 dans l'agrégat B2C pour un acheteur de la troisième (voir La catégorie et les montants comptés). Pour un acheteur de la première ligne, en revanche, elle ne peut pas être déposée auprès du PPF, qui rejette un flux 1 dont toute la ventilation de TVA est en catégorie O (règle G2.32) : pour une société déclarée dans la vague d'émission, le dépôt est refusé en 422 et la facture reste en brouillon (voir Le cycle de vie d'une facture). S'il s'agit de débours, marquez ses lignes comme décrit ci-dessous ; sinon, corrigez ses catégories de TVA. Ce refus ne vaut pas lorsque l'acheteur est une entité publique, que la règle G2.32 exclut : Scribee la reconnaît quand le SIREN de l'acheteur désigne, dans l'annuaire national, une unité légale de type public, en juge au dépôt et garde cette réponse pour toute la transmission de la facture. Une telle facture est déposée ; le contrôle du flux 1 ne lui oppose pas davantage G2.32 lorsque toute sa ventilation de TVA est en catégorie E avec un motif d'exonération de l'article 261 du CGI (VATEX-FR-CGI261-1, VATEX-FR-CGI261A...), ou qu'elle mêle des ventilations O et E.

Seul le marquage explicite des lignes en débours change ce qui est déclaré (Émettre une facture de vente) : une facture de vente dont chaque ligne porte disbursement à true, et dont chaque ventilation de TVA est en catégorie O - ou E avec un tax_exemption_reason_code valant VATEX-EU-79-C - sans montant de TVA, n'est ni déposée auprès du PPF, ni déclarée par une facture d'e-reporting, ni comptée dans l'agrégat B2C, quelle que soit la ligne du tableau où se trouve son acheteur. Une seule ligne non marquée la replace dans ce tableau, et le code VATEX-EU-79-C n'y suffit pas sans le marquage : une facture dont les lignes sont en catégorie E sous ce code sans porter disbursement suit ce tableau comme les autres.

La période retenue est celle qui couvre le fait générateur - la date de livraison, à défaut la date d'émission. Rien n'est transmis à l'administration au moment du dépôt : la déclaration reste à l'état draft Brouillon.

Ce que Scribee lit comme un SIREN

La première ligne du tableau décide de tout le reste, et l'acheteur y est porteur d'un SIREN dès que son couple legal_registration_id / legal_registration_scheme_id en donne un - y compris sous une forme qui n'est pas celle d'un SIREN nu :

Ce que porte l'acheteur	Le SIREN retenu
Neuf chiffres sous le schéma siren (0002)	la valeur elle-même
Quatorze chiffres - un SIRET - sous le schéma siren (0002)	ses neuf premiers chiffres
Quatorze chiffres sous le schéma siret (0009)	ses neuf premiers chiffres
Neuf chiffres sans schéma déclaré, pour un acheteur dont le country_code est dans le territoire de TVA français	la valeur elle-même
Neuf chiffres sans schéma déclaré, pour un acheteur établi ailleurs	aucun : la vente suit la deuxième ligne du tableau

Les neuf premiers chiffres d'un SIRET sont le SIREN de la même unité légale (annexe 7, règle G1.80) : la réduction ne perd rien de l'identité de l'acheteur, qui est la seule question posée ici.

La restriction de territoire sur la quatrième ligne est délibérée. Neuf chiffres est aussi la forme d'un numéro d'organisation norvégien, d'un code d'entité lituanien ou d'un NIF portugais. Les lire comme des SIREN classerait des ventes étrangères comme franco-françaises : elles partiraient en dépôt de facture au lieu de la déclaration d'opération qu'elles doivent, et cette déclaration ne serait jamais faite. Déclarez donc le schéma de l'immatriculation de vos contreparties étrangères - c'est ce qui rend leur identifiant lisible sans être deviné.

Ces lectures ne rattrapent pas une immatriculation illisible, et ce refus-là est inchangé : chez un acheteur établi dans le territoire de TVA français, une valeur présente qu'aucune des lignes ci-dessus ne permet d'exploiter - 987/654/321 - fait refuser le dépôt en 422, avec details indexé sur buyer.legal_registration_id (voir Le cycle de vie d'une facture). Un acheteur qui ne porte réellement aucune immatriculation reste, lui, sur la troisième ligne du tableau.

:::danger Ne redéposez pas ce que Scribee a déjà déclaré Créer ici un enregistrement pour une vente déjà déposée comme facture la déclare deux fois. Une sur-déclaration est un manquement réglementaire au même titre qu'une sous-déclaration, et l'API ne la détecte pas pour vous : elle ne rapproche pas un enregistrement que vous créez d'une facture déposée. Avant chaque création, vérifiez qu'aucune facture de vente déposée sur Scribee ne porte l'opération, et relisez la déclaration par ses endpoints de liste. :::

L'outre-mer hors du territoire de TVA

Le territoire de TVA français se limite à la métropole, à la Guadeloupe, à la Martinique et à La Réunion. La Guyane (GF), Mayotte (YT), les collectivités d'outre-mer - Saint-Pierre-et-Miquelon (PM), Saint-Barthélemy (BL), Saint-Martin (MF), Wallis-et-Futuna (WF), la Polynésie française (PF), la Nouvelle-Calédonie (NC) - et les Terres australes et antarctiques françaises (TF) en sont exclues. Deux cas en découlent, qui priment sur le tableau ci-dessus :

Partie établie dans l'un de ces territoires	Ce que Scribee fait
Le vendeur	Rien n'est déclaré : ni dépôt de la facture auprès du PPF, ni facture d'e-reporting, ni vente comptée dans l'agrégat B2C, et aucune adresse d'annuaire n'est cherchée pour l'acheteur.
L'acheteur, porteur d'un SIREN	La facture n'est pas déposée auprès du PPF : une facture d'e-reporting est créée dans la déclaration de la période, comme pour un acheteur sans SIREN, et aucune adresse d'annuaire n'est cherchée.

Le premier cas ne vise que ces territoires français : un vendeur établi dans un pays étranger suit le tableau du début de page. Le second vaut aussi pour un pays étranger : un acheteur établi dans un pays étranger qui porte un SIREN reçoit lui aussi une facture d'e-reporting, sa facture n'est pas déposée auprès du PPF, et aucune adresse d'annuaire n'est cherchée pour lui.

:::warning Changement de comportement Jusqu'ici, un acheteur établi dans un pays étranger qui portait un SIREN gardait le dépôt de facture auprès du PPF. Sa vente est désormais déclarée par une facture d'e-reporting, et son encaissement relève de la déclaration des paiements, dans les conditions décrites dans Déclarer les paiements. :::

Le territoire se lit sur le country_code de la partie. Une adresse dont le country_code vaut FR est rattachée à son territoire par le début de son postal_code :

Début du code postal	Territoire
973	Guyane
976	Mayotte
975	Saint-Pierre-et-Miquelon
97133	Saint-Barthélemy
97150	Saint-Martin
984	Terres australes et antarctiques françaises
986	Wallis-et-Futuna
987	Polynésie française
988	Nouvelle-Calédonie

Tout autre code postal - y compris un autre code en 971, qui reste en Guadeloupe - laisse l'adresse dans le territoire de TVA français.

Opération triangulaire

Une facture de vente dont triangular_position vaut intermediary - votre entreprise est l'intermédiaire d'une opération triangulaire intracommunautaire - ne fait l'objet d'aucune déclaration d'opération : ni facture d'e-reporting, ni vente comptée dans l'agrégat B2C, quelle que soit la ligne du tableau que suivrait son acheteur. Le champ ne change rien au dépôt auprès du PPF : un acheteur de la première ligne reçoit la facture comme toute autre.

Scribee ne déduit jamais cette position de la facture. Tant que triangular_position vaut null, la vente suit le tableau du début de page comme une vente ordinaire ; une facture de vente first_supplier le suit aussi. Le champ se renseigne à la création ou à la modification du brouillon, avant le dépôt (voir Émettre une facture de vente).

Ce qui reste à votre charge

• Les achats. Une facture d'achat n'est jamais déclarée automatiquement : l'obligation côté acheteur (BY) dépend de votre propre régime de TVA et non de celui de l'émetteur. Déclarez-la par les endpoints de cette page.
• Les sociétés hors vague d'émission. Tant que la société émettrice n'est pas déclarée dans la vague en vigueur, aucune déclaration n'est établie automatiquement pour ses factures. C'est le même réglage de société que celui décrit dans Le cycle de vie d'une facture.
• Les sociétés dont le régime ne porte pas l'obligation. Rien n'est déclaré pour elles, et aucune déclaration n'est préparée.
• Les opérations qu'aucune facture ne porte. Un cumul de caisse enregistreuse, un ticket : rien ne les déposera à votre place.

Les ventes que l'agrégat B2C refuse

Sur la voie B2C, neuf cas sont refusés plutôt que comptés, et ils le sont au dépôt de la facture, avant que quoi que ce soit ne soit déclaré. Comme la voie elle-même, ce contrôle ne vise que les sociétés déclarées dans la vague d'émission. Le dépôt échoue en 422, la facture reste en brouillon et aucun numéro définitif n'est consommé ; le message nomme la cause (Le cycle de vie d'une facture). Vous n'avez donc rien à rattraper ici : corrigez la facture, puis redéposez-la.

Cas	Ce que porte la facture
Cadre de facturation mixte (M1, M2, M4)	Le cadre annonce à la fois des livraisons de biens et des prestations de services. La répartition se lit sur les lignes de facture, qu'un agrégat ne porte pas : Scribee ne la devine pas.
Cadre de facturation absent, ou hors de la liste des cadres	La catégorie de l'opération se déduit du cadre de facturation (voir La catégorie et les montants comptés).
Vente au régime de la marge mêlée à d'autres ventilations	Une ventilation de TVA de catégorie E dont le motif d'exonération est VATEX-EU-F, VATEX-EU-I, VATEX-EU-J ou VATEX-EU-D, à côté d'une autre ventilation de TVA - taxable, G ou O. L'agrégat compte une vente au régime de la marge dans une catégorie qui lui est propre : émettez-la sur une facture distincte.
Vente au régime de la marge sans base de marge	Une ventilation de TVA de catégorie E dont le motif d'exonération est VATEX-EU-F, VATEX-EU-I, VATEX-EU-J ou VATEX-EU-D. L'agrégat déclare une telle vente sous TMA1, sur la marge hors TVA et la TVA due sur cette marge - deux montants que la facture ne porte pas, et que vous fournissez avec elle dans margin_bases (voir Les ventes au régime de la marge). Sans aucune base, la vente est refusée au dépôt.
Vente au régime de la marge avec une base incohérente	Une margin_vat_amount s'écarte de plus d'un centime de sa margin_base_amount taxée à son vat_rate, ou les marges TVA comprise dépassent le prix de vente que porte la facture (voir Les ventes au régime de la marge).
Totaux absents	Le total hors taxes ou le total de TVA manque.
Devise étrangère sans contre-valeur en euros	Un agrégat porte ses montants en EUR : la facture doit porter son total de TVA en euros. Une vente au régime de la marge n'a pas besoin de ce total : c'est la TVA sur la marge qui est convertie en euros, au taux de change figé au dépôt (voir Facturer dans une autre devise que l'euro).
Ventilation de TVA absente	Un agrégat porte toujours une ventilation par taux de TVA, y compris quand les montants sont nuls.
Ventilation et totaux discordants	Le total hors taxes et le total de TVA de la facture n'égalent pas, au centime près, la somme de sa ventilation de TVA.

Trois refus, en revanche, ne se produisent qu'après un dépôt réussi, au moment où la déclaration est établie. Dans ces trois cas-là, le dépôt de la facture aboutit normalement ; la déclaration, elle, n'est pas établie. Relisez la déclaration de la période pour vérifier qu'une vente attendue y figure bien.

• Un code devise que l'ISO 4217 ne reconnaît pas, sur la facture elle-même ou sur l'une de ses lignes de ventilation de TVA.
• Une vente qui mêle des ventilations de TVA taxables et des ventilations G ou O que Scribee ne peut pas répartir entre deux agrégats (voir La catégorie et les montants comptés) : une ventilation dont le tax_category_id n'est pas une catégorie de TVA connue, une ventilation G ou O qui porte un montant de TVA, ou des ventilations dont les bases hors taxes ou les montants de TVA ne correspondent pas aux totaux de la facture. Une telle vente n'est jamais déclarée en entier sous TLB1 ou TPS1.
• Un cadre de facturation B7 ou S7 (TVA déjà collectée). Ce cadre indique que l'opération figure déjà dans un agrégat B2C : la compter à nouveau la déclarerait deux fois. Une facture émise dans ce cadre s'adresse à un acheteur professionnel identifié ; identifiez l'acheteur, ou utilisez le cadre de la vente si elle n'a jamais été déclarée.

Dans les deux premiers cas, la vente reste à déclarer ici. Dans le dernier, ne créez rien pour elle : l'opération est déjà déclarée.

Une ventilation de TVA en catégorie O (hors champ de la TVA) peut ne porter aucun taux. Elle n'est pas refusée : sur les deux voies, l'agrégat comme la facture d'e-reporting la déclarent avec un vat_rate à 0.

La catégorie et les montants comptés

La catégorie (category_code) d'une vente comptée dans l'agrégat se déduit de son cadre de facturation : TLB1 pour un cadre de livraison de biens (B1, B2...), TPS1 pour un cadre de prestation de services (S1, S2...). Une exception prime : une facture dont toutes les lignes de ventilation de TVA sont en catégorie G (exportation hors de l'Union européenne) ou O (hors du champ de la TVA) est comptée en TNT1, opérations non taxables, que son cadre soit de biens ou de services. C'est le cas d'une vente de biens à un particulier établi en Guyane, à Mayotte ou dans une collectivité d'outre-mer. Une facture qui mêle de telles lignes à des lignes taxables est ventilée entre deux agrégats : ses lignes de ventilation G et O sont comptées en TNT1, pour leur base hors taxes et une TVA nulle, et le reste de la vente dans la catégorie de son cadre, TLB1 ou TPS1, pour le total hors taxes de la facture diminué de la part TNT1 et pour la totalité de sa TVA. La vente compte alors pour une opération dans chacun des deux agrégats. Elle n'est jamais déclarée en entier sous TLB1 ou TPS1 : quand ses lignes ne se répartissent pas ainsi, elle est refusée (voir Les ventes que l'agrégat B2C refuse).

L'octroi de mer n'entre pas dans l'agrégat. Une ligne de ventilation de TVA en catégorie O dont le tax_exemption_reason vaut OCTROI_MER n'est reportée ni dans les tax_subtotals de la transaction, ni dans son total_amount_excluding_taxes, qui reçoit le total hors taxes de la facture diminué du amount_without_taxes de cette ligne. Elle n'est pas prise en compte non plus pour décider de la catégorie TNT1.

Les ventes au régime de la marge

Une vente au régime de la marge porte sa ventilation de TVA en catégorie E, avec le motif d'exonération VATEX-EU-F, VATEX-EU-I, VATEX-EU-J ou VATEX-EU-D : la facture indique le prix de vente, jamais la marge. L'agrégat, lui, déclare cette vente sous TMA1, sur la marge hors TVA et la TVA due sur cette marge, taux par taux. Ces montants, vous les fournissez avec la facture, dans le tableau margin_bases de POST /api/v1/workspaces/{workspace_id}/invoices ou de PATCH /api/v1/invoices/{id} (référence API).

Chaque élément du tableau décrit la marge à un taux de TVA, une seule ligne par taux :

• vat_rate : le taux de TVA auquel la marge est taxée, l'un des taux français positifs (20.0, 10.0, 5.5...) ;
• margin_base_amount : la marge hors TVA ;
• margin_vat_amount : la TVA due sur cette marge ;
• source : actual pour la marge réelle, estimated pour une marge établie à partir d'un taux de marge moyen estimé, quand la marge réelle n'est pas connue au moment de la vente. Les deux sont acceptées et déclarées de la même façon.

Les deux montants sont positifs ou nuls, à deux décimales au plus, et exprimés dans la devise de la facture (currency_code). Scribee ne rapproche pas la vente de vos factures d'achat : aucune marge n'est calculée pour vous, la base déclarée est celle que vous fournissez.

Extrait d'une charge utile de création :

{
  "invoice": {
    "invoicing_process_id": "B1",
    "tax_subtotals": [
      { "tax_category_id": "E", "vat_rate": 0, "amount_without_taxes": 1500.0, "vat_amount": 0, "currency_code": "EUR", "tax_exemption_reason_code": "VATEX-EU-F" }
    ],
    "margin_bases": [
      { "vat_rate": 20.0, "margin_base_amount": 300.0, "margin_vat_amount": 60.0, "source": "actual" },
      { "vat_rate": 10.0, "margin_base_amount": 45.45, "margin_vat_amount": 4.55, "source": "estimated" }
    ]
  }
}

Relisez les bases avec GET /api/v1/invoices/{id}?include=margin_bases : elles reviennent triées par taux croissant, chacune avec son id. Sans include=margin_bases, la clé est absente de la réponse.

En modification, margin_bases suit sa propre règle : une clé absente conserve les bases enregistrées, un tableau les remplace toutes, [] les efface. Seul un brouillon se modifie : une fois la facture déposée, un PATCH est refusé en 403 et ses bases ne changent plus. Fournissez-les donc avant le dépôt.

Pour ne changer que les bases, envoyez margin_bases seule. Un PATCH /api/v1/invoices/{id} dont c'est la seule clé remplace les bases, ou les efface avec [], et répond 200 avec la facture ; il ne reconstruit pas le reste de la facture à partir de la charge utile. Dès qu'une autre clé l'accompagne, l'appel redevient une modification complète, soumise aux règles de l'étape 2 d'Émettre une facture de vente : une collection comme lines envoyée sans les champs de la facture est refusée en 422.

{
  "invoice": {
    "margin_bases": [
      { "vat_rate": 20.0, "margin_base_amount": 300.0, "margin_vat_amount": 60.0, "source": "actual" }
    ]
  }
}

Une ligne refusée - taux hors de la liste des taux français positifs, montant négatif ou à plus de deux décimales, source inconnue, deux lignes au même taux - fait échouer tout l'appel en 422, avec le code validation_failed et un details indexé sur l'attribut fautif (vat_rate, margin_base_amount...). Rien n'est enregistré ; en modification, les bases précédentes restent en place.

Quand la déclaration est établie, la vente compte pour une opération en TMA1, avec une ligne de ventilation par base, à son taux : son total hors taxes est la somme des margin_base_amount, son total de TVA la somme des margin_vat_amount. Hors euro, la TVA sur la marge est convertie en euros au taux figé lors du dépôt (voir Facturer dans une autre devise que l'euro). La vente de l'exemple ci-dessus apporte ainsi 345.45 hors taxes et 64.55 de TVA à l'agrégat TMA1.

Les bases sont transmises telles que vous les fournissez. Scribee en contrôle donc la vraisemblance au dépôt de la facture : pour une société déclarée dans la vague d'émission, le dépôt est refusé en 422, et la facture reste en brouillon, dans trois cas :

• aucune base n'est fournie ;
• une margin_vat_amount s'écarte de plus d'un centime de sa margin_base_amount taxée à son vat_rate et arrondie au centime ;
• les marges TVA comprise (margin_base_amount plus margin_vat_amount, tous taux confondus) dépassent le prix de vente que portent les lignes de ventilation de TVA de la facture.

Une seule base incohérente suffit à refuser le dépôt. Corrigez les bases par un PATCH qui ne porte que margin_bases, puis redéposez la facture. Ce sont les refus décrits dans Les ventes que l'agrégat B2C refuse.

Les factures d'acompte reprises de l'agrégat B2C

Une facture d'acompte dont l'acheteur ne porte aucun identifiant est comptée dans l'agrégat B2C, comme toute vente de la troisième ligne du tableau. La facture définitive qui la solde l'en fait reprendre, pour une société déclarée dans la vague d'émission, dans deux cas :

• la facture définitive quitte l'agrégat B2C : son acheteur, lui, est identifié, et elle est déposée auprès du PPF ou déclarée dans les données de transaction (10.1). L'acompte se trouve alors déclaré dans le mauvais agrégat. La reprise suit le dépôt de la facture définitive.
• la facture définitive est elle-même comptée dans l'agrégat B2C : elle y est comptée pour son montant entier, si bien que l'acompte y figurerait deux fois ; seul le solde doit rester déclaré. La reprise suit le comptage de la facture définitive.

Sont repris les acomptes que la facture définitive désigne par document_id dans invoice_references (Facture d'acompte et facture définitive après acompte). Ne les déduisez pas en plus par une ligne négative qui cite leur numéro dans invoice_reference_number : ils seraient déduits deux fois, et le dépôt de la facture définitive est refusé dans ce cas.

Chaque comptage est repris par son opposé : ce que l'acompte avait apporté - total hors taxes, total de TVA et ventilation taux par taux - est porté en négatif, sous la même catégorie (category_code) et dans la même devise qu'au comptage. Le jour de la reprise dépend du cas. Quand la facture définitive quitte l'agrégat B2C, c'est le jour de sa date d'émission (issue_date, BT-2), et non de sa date de livraison. Quand elle est elle-même comptée dans l'agrégat B2C, c'est le jour où elle y est comptée : sa date de livraison (delivery_date), à défaut sa date d'émission. La reprise est écrite dans la déclaration qui couvre ce jour. Si cette déclaration est déjà déposée auprès du PPF, la reprise passe au premier jour de la déclaration suivante, et ainsi de suite jusqu'à la première déclaration qui ne l'est pas, sans jamais dépasser la date du jour. Une déclaration en cours d'acheminement n'est pas sautée : la reprise attend la réponse du PPF et est retentée automatiquement, un nombre limité de fois. Une reprise n'est pas une vente : elle ne change pas transaction_count, le nombre de ventes (TT-85). GET /api/v1/e_reportings/{e_reporting_id}/transactions peut donc renvoyer une transaction aux montants négatifs, ou, quand une reprise est sa seule opération, une transaction dont transaction_count vaut 0 et dont les totaux sont négatifs ; le flux 10.3 omet alors le nombre de transactions. Les transactions que vous écrivez déclarent toujours au moins une opération : un transaction_count à 0 y est refusé (voir plus bas). Pour une facture définitive comptée dans l'agrégat B2C, sauf déclaration déjà déposée, la reprise tombe donc le jour où la facture a été comptée : quand l'acompte et la facture définitive relèvent de la même catégorie et de la même devise, la transaction de ce jour porte le solde.

La reprise n'est pas écrite :

• lorsque ce jour est postérieur à la date du jour ;
• lorsque la déclaration qui couvre ce jour et toutes les suivantes jusqu'à la date du jour sont déposées auprès du PPF ;
• lorsqu'aucune déclaration ne couvre ce jour pour la société, son régime de TVA ne portant pas l'obligation ce jour-là ;
• lorsque ce que l'acompte avait apporté ne peut plus être recalculé à partir de la facture d'acompte telle qu'elle est enregistrée ;
• lorsque l'un des refus décrits dans Facture d'acompte et facture définitive après acompte, qui s'appliquent au dépôt de la facture définitive, survient entre ce dépôt et la reprise.

L'acompte reste alors compté dans l'agrégat B2C à côté de la facture définitive, qui porte l'opération entière : la transaction où il avait été compté garde ses montants, et aucun montant négatif n'est écrit. Scribee ouvre un dossier de son côté pour traiter la reprise ; ce dossier n'est pas exposé par l'API.

Une facture définitive annulée (220), ou rejetée (213) sans pouvoir être renvoyée sous le même numéro (voir plus bas), avant que la reprise ne soit écrite ne fait rien reprendre : l'acompte reste compté dans l'agrégat B2C, sans montant négatif. Un rejet après lequel la facture peut être renvoyée sous le même numéro n'arrête pas la reprise, et le renvoi de la facture la relance.

La reprise compensée après l'annulation ou le rejet de la facture définitive

Lorsqu'une facture définitive dont la reprise est écrite est ensuite annulée (220) ou rejetée (213), les acomptes qu'elle soldait ne sont plus soldés par aucune facture : Scribee compense la reprise. Ce que chaque acompte avait apporté - total hors taxes, total de TVA et ventilation taux par taux - est porté à nouveau, en positif, sous la même catégorie (category_code) et dans la même devise qu'au comptage, sans changer transaction_count. Quand la facture définitive était elle-même comptée dans l'agrégat B2C, elle en est retirée dans la même opération, sans quoi les acomptes y figureraient deux fois : ce qu'elle avait apporté est porté en négatif, sous sa catégorie et dans sa devise, sans changer non plus transaction_count : quand la compensation est sa seule opération, une transaction a un transaction_count à 0. La compensation est écrite le jour où l'annulation ou le rejet a pris effet, dans la déclaration qui couvre ce jour ; si cette déclaration est déjà déposée auprès du PPF, elle passe au premier jour de la déclaration suivante, comme la reprise. Seul compte un rejet après lequel la facture ne peut pas être renvoyée sous le même numéro : un rejet prononcé à l'émission, ou un rejet de la plateforme du destinataire pour doublon (motif REJ_UNI). Tout autre rejet de la plateforme du destinataire laisse la reprise en place ; l'annulation ultérieure de la facture la compense. Chaque reprise n'est compensée qu'une fois. Une facture définitive qui n'est plus annulée ni rejetée lorsque la compensation s'exécute n'en déclenche aucune. Une facture définitive annulée ou rejetée que remplace une facture rectificative n'en déclenche aucune non plus : une facture rectificative (corrected_invoice, corrected_factored_invoice ou leur variante auto-facturée) de la même entreprise, de même nature auto-facturée ou non, dont l'unique entrée de invoice_references désigne la facture définitive, qui ne désigne pas un autre acheteur - quand les parties buyer des deux factures portent chacune un legal_registration_id, c'est le même -, et qui est déposée. La facture rectificative porte alors l'opération : les acomptes restent repris, et rien n'est porté à nouveau pour eux. Quand la facture définitive était elle-même comptée dans l'agrégat B2C, seul son propre comptage en est retiré, comme ci-dessus, la facture rectificative y étant comptée à son tour. Une facture rectificative rejetée (213) qui peut être renvoyée sous le même numéro la remplace toujours, et une facture rectificative remplacée à son tour par une autre laisse l'opération à cette dernière. La facture définitive n'est plus remplacée, et sa reprise est compensée, lorsque la facture rectificative qui porte l'opération est annulée (220) sans être remplacée à son tour, ou rejetée (213) sans pouvoir être renvoyée sous le même numéro. Rien n'est écrit, et Scribee ouvre un dossier de son côté, non exposé par l'API, lorsque la facture rectificative qui porte l'opération est refusée par l'acheteur (210), lorsqu'elle a pris effet avant que la reprise ne soit écrite, lorsqu'elle remplace une facture définitive dont la reprise a déjà été compensée, lorsque la facture définitive, comptée dans l'agrégat B2C, a été remplacée avant qu'aucune reprise ne soit écrite, l'acompte qu'elle solde y restant compté, ou lorsque la facture définitive, qui quitte l'agrégat B2C, a été remplacée sans qu'aucune reprise ne soit écrite pour elle, un acompte qu'elle solde restant compté dans l'agrégat B2C ; dans ce dernier cas, le dossier reste ouvert tant que cet acompte y est compté. Une facture rectificative qui cite une facture définitive dont la reprise est en place ne déduit pas en plus ses acomptes par une ligne négative qui cite leur numéro dans invoice_reference_number : ils ne seraient déclarés nulle part, et son dépôt est refusé dans ce cas. Un avoir émis sur la facture définitive ne déclenche aucune compensation : la facture définitive reste en vigueur, et les acomptes qu'elle solde ne sont pas comptés à nouveau. Quand la compensation ne peut pas être écrite - aucune déclaration ouverte jusqu'à la date du jour, ou un comptage, de l'acompte ou de la facture définitive, dont l'apport n'a pas été enregistré -, rien n'est écrit et Scribee ouvre un dossier de son côté, non exposé par l'API.

Un acompte dont la reprise a été compensée n'est plus repris une seconde fois : une autre facture définitive qui le solde est refusée au dépôt (Facture d'acompte et facture définitive après acompte).

Une fois la reprise écrite, ni la transaction où l'acompte avait été compté, ni celle qui porte le montant négatif ou sa compensation, ni celle où une facture définitive comptée dans l'agrégat B2C a été comptée ne peuvent plus être modifiées ou supprimées (voir 422 : transaction d'une reprise d'acompte plus bas).

Une fois écrite la reprise pour une facture définitive qui quitte l'agrégat B2C, et tant qu'elle n'est pas compensée, les paiements de la facture d'acompte ne se déclarent plus en données de paiement : Scribee ne les déclare plus depuis les paiements de facture, et refuse une déclaration de paiement que vous écrivez vous-même et qui désigne la facture d'acompte (422 : paiement d'une facture d'acompte reprise).

Ce que Scribee fait pour vous

• Déclarations préparées à l'avance : chaque entreprise soumise à l'obligation de déclaration des transactions reçoit ses déclarations à venir, à l'état draft Brouillon, avant toute donnée. Une entreprise dont le régime de TVA courant ne porte pas cette obligation est explicitement écartée du balayage : aucune nouvelle déclaration n'est préparée pour elle - ne traitez pas une liste vide comme une anomalie. La liste n'est pas garantie vide pour autant : les déclarations déjà alimentées sont conservées et restent visibles, y compris après un changement de régime. La préparation porte - avec la période (start_date, end_date), la périodicité dérivée de son régime de TVA (décade, mois ou bimestre) et l'échéance déclarative (due_date).
• Séparation par rôle déclarant : les données sont agrégées par entreprise, par période et par rôle - vendeur (SE) ou acheteur (BY) ; une opération de vente et une opération d'achat d'une même période ne partagent jamais une déclaration.
• Déclarations en lecture seule : le champ state de la déclaration s'observe en lecture, aucun endpoint ne le modifie, et sa valeur est toujours draft. Chaque déclaration porte aussi un tableau available_transitions, déprécié et toujours [] : ne construisez rien dessus (L'e-reporting).

Transactions ou factures : quel enregistrement choisir

Deux types d'enregistrements alimentent une déclaration de type transactions :

• Une transaction agrège plusieurs opérations B2C : une date, une catégorie (category_code), un nombre d'opérations (transaction_count), des montants cumulés et une ventilation par taux de TVA. Aucune donnée client n'y figure. Une transaction ne se rattache qu'à une déclaration de rôle vendeur (SE).
• Une facture d'e-reporting décrit individuellement une facture émise ou reçue hors du circuit de facturation électronique - typiquement une opération internationale : numéro, dates, identification du vendeur et de l'acheteur, lignes et ventilation de TVA. Elle se rattache à la déclaration dont le rôle correspond au sens de l'opération : SE quand l'entreprise déclarante vend, BY quand elle achète.

Choisir la déclaration cible

L'identifiant de la déclaration figure dans le chemin de chaque appel de création : vous choisissez la période en choisissant la déclaration. Listez les déclarations du workspace, puis retenez la bonne sur trois critères, pas deux : le type (kind vaut transactions), la période qui couvre la date à déclarer, et le rôle déclarant (role).

:::caution Le couple type + période ne suffit pas à identifier une déclaration Chaque période ouvre deux déclarations transactions par société - une où elle déclare en tant que vendeur (role vaut SE) et une en tant qu'acheteur (role vaut BY). Ajoutez role et company_id à votre sélection : retenir la première déclaration dont le type et la période correspondent revient à choisir au hasard entre les deux, et une déclaration de rôle incompatible est refusée en 422. :::

L'appel de création vérifie ensuite la cohérence avec le rôle déclarant de la déclaration choisie et refuse toute incompatibilité (voir 422 : rôle déclarant incompatible plus bas). Il ne vérifie en revanche pas la période : c'est à vous de viser la déclaration dont les bornes couvrent la date de l'opération.

La liste est paginée (page, per_page - 20 par défaut, 100 au maximum) et triable (sort_by : start_date, end_date, due_date, kind, state, created_at, updated_at ; sort_order : asc ou desc ; tri par défaut : start_date décroissant) ; elle n'expose pas de filtre.

curl https://app.scribee.tech/api/v1/workspaces/YOUR_WORKSPACE_ID/e_reportings \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

Réponse abrégée aux champs utiles ici :

{
  "data": [
    {
      "id": 512,
      "kind": "transactions",
      "role": "SE",
      "state": "draft",
      "start_date": "2026-07-01",
      "end_date": "2026-07-31",
      "due_date": "2026-08-10",
      "company_id": 7
    }
  ],
  "meta": {
    "current_page": 1,
    "per_page": 20,
    "total_pages": 1,
    "total_count": 3
  }
}

Déclarer des transactions B2C

Cet appel crée un enregistrement de transaction dans la déclaration, dans votre compte de production. Rien n'est transmis à l'administration au moment de l'appel ; l'enregistrement se corrige (PATCH) et se supprime (DELETE). Le scope write est requis et la réponse est un 201.

POST /api/v1/e_reportings/{e_reporting_id}/transactions exige date, category_code, transaction_count, total_amount_excluding_taxes et total_tax_amount. Deux champs sont facultatifs : currency_code, omis, est enregistré à EUR ; tax_due_date_code, omis, revient null dans la réponse - une chaîne vide est acceptée elle aussi. S'y ajoute tax_subtotals, la ventilation par taux de TVA, dont chaque élément exige amount_without_taxes, vat_rate et currency_code (un code de la liste ISO 4217, voir l'encadré ci-dessous) et accepte vat_amount, tax_category_id, tax_exemption_reason et tax_exemption_reason_code.

category_code désigne la nature de l'opération : TLB1 livraisons de biens taxables, TPS1 prestations de services taxables, TNT1 opérations non taxables, TMA1 opérations taxables sur la marge.

tax_due_date_code porte le code d'exigibilité de la TVA, parmi 5, 29 et 72 (UNTDID 2475) et 3, 35 et 432 (UNTDID 2005). Il est facultatif : la réglementation ne l'attend que des opérations relevant de la TVA sur les débits, et l'API ne vérifie pas cette condition - si votre régime ne l'impose pas, omettez le champ plutôt que d'y placer une valeur par défaut.

:::caution Ce que l'API contrôle, et ce qu'elle ne contrôle pas Cinq champs sont contrôlés, à la création comme à la modification, et répondent 422 (voir 422 : champs manquants ou invalides plus bas) : un category_code hors de ses quatre valeurs - TLB2, par exemple - est refusé ; un transaction_count nul ou négatif est refusé ; une date postérieure au jour de l'appel est refusée ; un tax_due_date_code hors des six codes ci-dessus est refusé - son absence, elle, ne l'est pas ; un currency_code absent de la liste ISO 4217 que Scribee embarque est refusé, sur la transaction comme sur chaque sous-total de tax_subtotals.

Le contrôle de la devise porte sur l'existence du code, pas seulement sur sa forme, et la comparaison est sensible à la casse : EUR passe, eur et USd sont refusés, et un jeton bien formé qui ne nomme aucune devise - XYZ, par exemple - l'est aussi. Ce contrôle est propre à Scribee : le schématron du flux 10 vérifie la forme du code et ne contrôle pas son existence dans le référentiel, donc une valeur que le PPF accepterait est refusée ici. Mettez vos codes en majuscules avant l'appel : rien n'est normalisé à l'écriture.

Les totaux doivent se rapprocher de la ventilation de TVA, comme sur la facture d'e-reporting (voir plus bas). total_amount_excluding_taxes doit égaler la somme des amount_without_taxes de tax_subtotals, quelle que soit la devise de la transaction ; total_tax_amount doit égaler la somme des vat_amount, mais seulement quand currency_code vaut EUR - ce qui est le cas quand vous l'omettez. L'écart admis est de 0,01 par montant additionné ; chaque montant est d'abord arrondi à deux décimales, et un sous-total sans vat_amount compte pour 0.00. Ne comptez pas sur cette tolérance : le PPF compare les montants en nombres à virgule flottante binaires, et Scribee reproduit son calcul, si bien qu'un écart égal à la tolérance peut la dépasser - 1.01 déclaré sur un seul sous-total de 1.00 est refusé, alors que 1000.01 sur 1000.00 passe. Envoyez des totaux égaux à la somme de leur ventilation. Au-delà, la requête est refusée en 422 avant que quoi que ce soit ne soit enregistré (voir 422 : totaux non rapprochés plus bas) : le PPF rejetterait sinon la déclaration entière pour cette seule transaction. Une transaction sans tax_subtotals n'est pas contrôlée. En modification, le contrôle porte sur la transaction qui résulte de la requête, mais seulement quand celle-ci envoie total_amount_excluding_taxes, total_tax_amount, tax_subtotals ou currency_code : un PATCH sur d'autres champs n'est pas rapproché, et un remplacement de tax_subtotals refusé est annulé et laisse les sous-totaux existants intacts.

Le reste ne l'est pas. Une date en dehors des bornes start_date / end_date de la déclaration visée est acceptée, et l'enregistrement reste rattaché à cette déclaration. Des montants à zéro ou négatifs passent également : un agrégat négatif est légitime, il porte les avoirs. Ces données alimentent ensuite une déclaration destinée à la DGFiP : pour tout ce que l'API ne vérifie pas, validez-les avant l'appel. :::

curl -X POST https://app.scribee.tech/api/v1/e_reportings/YOUR_E_REPORTING_ID/transactions \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction": {
      "date": "2026-07-15",
      "category_code": "TPS1",
      "currency_code": "EUR",
      "tax_due_date_code": "35",
      "transaction_count": 42,
      "total_amount_excluding_taxes": 3500.0,
      "total_tax_amount": 700.0,
      "tax_subtotals": [
        {
          "amount_without_taxes": 3500.0,
          "vat_amount": 700.0,
          "vat_rate": 20.0,
          "currency_code": "EUR",
          "tax_category_id": "S"
        }
      ]
    }
  }'

Réponse abrégée aux champs utiles ici ; elle porte aussi created_at et updated_at :

{
  "data": {
    "id": 3101,
    "date": "2026-07-15",
    "category_code": "TPS1",
    "currency_code": "EUR",
    "tax_due_date_code": "35",
    "transaction_count": 42,
    "total_amount_excluding_taxes": 3500.0,
    "total_tax_amount": 700.0,
    "report_id": 512
  }
}

Les montants sont stockés avec quatre décimales mais renvoyés arrondis à deux : 3500.1234 est enregistré tel quel et relu 3500.12. Ne rapprochez pas vos écritures sur la valeur relue.

Le découpage des agrégats vous appartient : un enregistrement par jour et par catégorie d'opération est le motif le plus lisible, mais l'API n'impose pas de granularité.

Corriger ou supprimer une transaction

Un enregistrement se lit, se corrige et se supprime par son identifiant, sans e_reporting_id dans le chemin. La correction et la suppression opèrent sur votre compte de production et ne transmettent rien à l'administration.

PATCH /api/v1/e_reportings/transactions/{id} ne modifie que les champs envoyés, avec les mêmes contrôles - et les mêmes absences de contrôle - qu'à la création ; le rapprochement des totaux, lui, ne s'y applique que dans les conditions décrites plus haut. Fournir tax_subtotals remplace l'intégralité du jeu existant : les sous-totaux en place sont supprimés puis recréés, donc leurs id changent à chaque remplacement ; envoyer "tax_subtotals": [] vide la ventilation, qu'un PATCH ultérieur peut reconstituer. Une transaction qui fait partie d'une reprise d'acompte ne se modifie pas du tout : le PATCH est refusé en 422, avec un corps sans details (voir 422 : transaction d'une reprise d'acompte plus bas). Il en va de même d'une transaction dans laquelle Scribee a lui-même compté des factures de l'agrégat B2C (voir 422 : transaction où Scribee a compté des factures plus bas).

curl -X PATCH https://app.scribee.tech/api/v1/e_reportings/transactions/YOUR_TRANSACTION_ID \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction": {
      "transaction_count": 45,
      "total_amount_excluding_taxes": 3750.0,
      "total_tax_amount": 750.0
    }
  }'

Réponse abrégée aux champs utiles ici ; comme à la création, elle porte tous les champs de l'enregistrement, y compris ceux que le PATCH n'a pas touchés :

{
  "data": {
    "id": 3101,
    "date": "2026-07-15",
    "category_code": "TPS1",
    "currency_code": "EUR",
    "tax_due_date_code": "35",
    "transaction_count": 45,
    "total_amount_excluding_taxes": 3750.0,
    "total_tax_amount": 750.0,
    "report_id": 512
  }
}

DELETE /api/v1/e_reportings/transactions/{id} répond 204 sans corps et supprime aussi les sous-totaux de TVA associés ; la suppression est définitive. Elle peut aussi être refusée en 422 lorsque la déclaration est déposée auprès du PPF ou en cours d'acheminement vers lui (voir 422 : déclaration déposée ou en cours d'acheminement plus bas), et lorsque la transaction fait partie d'une reprise d'acompte - elle porte le comptage d'une facture d'acompte que Scribee a repris de l'agrégat B2C, ou le montant négatif de cette reprise (voir 422 : transaction d'une reprise d'acompte plus bas) -, et lorsque Scribee y a lui-même compté des factures de l'agrégat B2C (voir 422 : transaction où Scribee a compté des factures plus bas). L'endpoint accepte destroy ou write : le scope write de la combinaison courante read write suffit (Authentification).

curl -X DELETE https://app.scribee.tech/api/v1/e_reportings/transactions/YOUR_TRANSACTION_ID \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

Déclarer une facture hors facturation électronique

Cet appel crée une facture d'e-reporting dans la déclaration, dans votre compte de production. Rien n'est transmis à l'administration ni au client final au moment de l'appel ; l'enregistrement se corrige (PATCH /api/v1/e_reportings/invoices/{id}, qui remplace lui aussi chaque ensemble imbriqué fourni) et se supprime (DELETE /api/v1/e_reportings/invoices/{id}, réponse 204, ou 422 si la déclaration est déposée ou en cours d'acheminement). Le scope write est requis et la création répond 201.

POST /api/v1/e_reportings/{e_reporting_id}/invoices exige invoice_number, issue_date, due_date, type_code, currency_code (un code de la liste ISO 4217, contrôlé comme sur la transaction), seller_scheme_id et buyer_scheme_id. type_code accepte la clé Scribee (invoice, credit_note, corrected_invoice, ...) ou le code UNTDID 1001 équivalent (380, 381, ...) ; les réponses renvoient toujours la clé. S'y ajoutent le reste de l'identification des parties (seller_id, seller_vat_number, seller_country, buyer_id, buyer_vat_number, buyer_country), les montants (total_amount_excluding_taxes, total_tax_amount), la ventilation tax_subtotals, les ensembles item_notes, discounts et expenses au niveau de la facture, les lignes invoice_lines (avec leurs propres item_notes, discounts et expenses) et les références invoice_references.

tax_due_date_code porte ici le code d'exigibilité TT-24, l'élément TaxDueDateTypeCode du flux 10 - le même fait métier que BT-8 sur la facture du flux 1, sous l'identifiant que l'e-reporting lui donne. Il reste facultatif, avec un défaut sur les ventes : omis - ou envoyé vide - sur une déclaration de rôle SE dont l'entreprise déclarante a opté pour la TVA sur les débits, il est enregistré à 5. Une valeur que vous envoyez l'emporte toujours, et une déclaration de rôle BY n'est jamais complétée : la facture y est celle du fournisseur, à qui il revient d'énoncer son propre point d'exigibilité. Le défaut ne joue qu'à la création ; un PATCH n'y revient pas.

issue_date ne peut pas être postérieure au jour de la transmission. L'écriture accepte une date future, mais POST /api/v1/workspaces/{workspace_id}/e_reportings/{id}/submit refuse alors la déclaration entière en 422, avec code: "validation_failed" et un motif qui nomme la facture, sa date et le jour du dépôt (L'e-reporting). Une date postérieure à la fin de la période, mais pas au jour de la transmission, reste admise.

Quantité, prix unitaire, montant de remise et montant de frais sont obligatoires. Chaque entrée d'invoice_lines porte quantity et article_unit_price_excluding_taxes ; chaque entrée de discounts comme chaque entrée d'expenses porte amount_excluding_taxes, aussi bien au niveau de la facture qu'imbriquée dans une ligne. Une clé absente et un null explicite sont refusés de la même façon, en 422, avant que quoi que ce soit ne soit enregistré (voir 422 : champs manquants ou invalides plus bas) ; 0 reste valide, une quantité, un prix unitaire, une remise ou un frais réellement nul se déclare. Le flux 10 ne rapproche aucune de ces quatre valeurs d'un autre montant : un chiffre inconnu y partirait en 0.00 sans que rien ne le signale. En modification, le contrôle ne porte que sur ce que votre requête envoie : un PATCH qui ne mentionne pas invoice_lines ne réclame rien des lignes déjà enregistrées, tandis qu'un PATCH qui les envoie doit chiffrer chaque entrée qu'il met en place - un remplacement refusé est annulé et laisse les lignes existantes intactes.

Les totaux doivent se rapprocher de la ventilation de TVA. total_amount_excluding_taxes doit égaler la somme des amount_without_taxes de tax_subtotals, quelle que soit la devise de la facture ; total_tax_amount doit égaler la somme des vat_amount, mais seulement quand currency_code vaut EUR. L'écart admis est de 0,01 par montant additionné - 0,03 pour une ventilation de trois sous-totaux ; chaque montant est d'abord arrondi à deux décimales, et un sous-total sans vat_amount compte pour 0.00. Ne comptez pas sur cette tolérance : le PPF compare les montants en nombres à virgule flottante binaires, et Scribee reproduit son calcul, si bien qu'un écart égal à la tolérance peut la dépasser - 1.01 déclaré sur un seul sous-total de 1.00 est refusé, alors que 1000.01 sur 1000.00 passe. Envoyez des totaux égaux à la somme de leur ventilation. Au-delà, la requête est refusée en 422 avant que quoi que ce soit ne soit enregistré (voir 422 : totaux non rapprochés plus bas) : le PPF rejetterait sinon la déclaration entière pour cette seule facture. Un total omis n'est pas rapproché, et une facture sans tax_subtotals n'est pas contrôlée. En modification, le contrôle porte sur la facture qui résulte de la requête, mais seulement quand celle-ci envoie total_amount_excluding_taxes, total_tax_amount, tax_subtotals ou currency_code : un PATCH sur d'autres champs n'est pas rapproché, si bien qu'une facture enregistrée avant ce contrôle reste modifiable même si ses totaux s'écartent de sa ventilation, et un remplacement de tax_subtotals refusé est annulé et laisse les sous-totaux existants intacts.

Les deux schémas d'identifiant sont obligatoires à la création. seller_scheme_id et buyer_scheme_id doivent porter une valeur : une charge utile qui en omet un, ou qui l'envoie vide, est refusée en 422 avant que quoi que ce soit ne soit enregistré (voir 422 : schéma de partie manquant plus bas). Le flux 10 réclame le schéma sur les deux parties, donc une facture qui n'en déclare pas n'est pas déclarable ; le refus tombe désormais sur l'appel qui l'a produite, et non sur une transmission ultérieure. En modification, le contrôle ne porte que sur ce que votre requête envoie : un PATCH qui ne mentionne pas buyer_scheme_id ne le réclame pas, mais un PATCH qui envoie "buyer_scheme_id": "" est refusé comme à la création.

L'identifiant doit ensuite respecter le format qu'implique le schéma déclaré à ses côtés : siren (0002) et tahiti (0229) exigent exactement neuf chiffres, ridet (0228) neuf ou dix, european_union (0223) et international (0227) dix-huit caractères au plus. Un seller_id ou un buyer_id qui sort de ce format est refusé en 422 (voir 422 : identifiant hors du format de son schéma plus bas). Le contrôle ne vise qu'un identifiant renseigné : une partie décrite par son seul numéro de TVA, sans seller_id ni buyer_id, n'a pas de format à vérifier.

La cohérence avec le rôle déclarant est vérifiée à la création : Scribee situe l'entreprise déclarante sur la facture, puis refuse l'écriture si le côté trouvé ne correspond pas au role de la déclaration. Un côté n'est reconnu comme celui de l'entreprise déclarante que si son seller_id - ou son buyer_id - est exactement le SIREN à neuf chiffres de l'entreprise, tel qu'il est enregistré dans Scribee, et qu'il ne porte pas de schéma déclaré autre que siren. Autrement dit, seller_scheme_id - ou buyer_scheme_id - vaut siren (le code 0002 est accepté aussi). Un schéma absent n'écarte pas le côté qui le porte, mais depuis que les deux schémas sont obligatoires à la création, ce cas ne concerne plus que les factures enregistrées avant cette obligation, qu'un PATCH portant sur d'autres champs laisse en l'état. La comparaison ignore la casse et les espaces de bord, et exige qu'une seule des deux parties corresponde, hors le transfert de stock décrit ci-dessous.

Un schéma déclaré european_union, international, ridet ou tahiti décrit une contrepartie, jamais le déclarant, et un identifiant plus long que neuf chiffres ne correspond pas davantage : un SIRET envoyé du côté déclarant ne le désigne pas. siret n'entre plus dans cette liste : le flux 10 ne l'admet sur aucune des deux parties, et seller_scheme_id comme buyer_scheme_id le refusent par un 422. En pratique, envoyez le côté que désigne le role de la déclaration - seller_id sur une déclaration SE, buyer_id sur une déclaration BY - avec le SIREN à neuf chiffres et le schéma siren : c'est la forme non ambiguë, et elle reste recommandée. Décrivez la contrepartie sous l'un des quatre autres schémas.

Un transfert de vos propres biens entre la France et un autre État membre porte votre SIREN des deux côtés. Quand seller_id et buyer_id désignent tous deux l'entreprise déclarante, Scribee départage les côtés par les numéros de TVA : le côté déclaré est celui dont le seller_vat_number - ou le buyer_vat_number - est un numéro de TVA français rattaché au SIREN de l'entreprise, à condition que l'autre côté porte le numéro de TVA d'un autre État membre de l'Union européenne. Un numéro français côté vendeur fait de la facture une sortie de France, à déclarer sur une déclaration SE ; côté acheteur, une entrée en France, à déclarer sur une déclaration BY. La cohérence avec le role de la déclaration est ensuite vérifiée comme pour toute autre facture. La Grèce s'écrit ici sous le préfixe EL, et le préfixe XI d'Irlande du Nord est admis. Toute autre paire - aucun numéro de TVA, deux numéros français, un numéro suisse, britannique ou norvégien de l'autre côté - laisse le côté indéterminé et la requête est refusée (voir 422 : rôle déclarant incompatible plus bas).

Sur une déclaration de rôle BY, la ventilation déclare la TVA que vous autoliquidez. Une facture y est une acquisition : chaque sous-total de tax_subtotals porte la catégorie AE au taux appliqué en comptabilité, et non la ventilation à taux nul du fournisseur. Un sous-total en catégorie K ou G, ou en AE sans taux positif - vat_rate absent ou à 0 -, est refusé en 422 (voir 422 : acquisition non autoliquidée plus bas) ; à la création, le refus emporte l'ensemble : ni la facture ni ses sous-totaux ne sont enregistrés. Le contrôle porte sur chaque sous-total que la requête enregistre, en création comme en modification. Une déclaration de rôle SE n'est pas concernée.

:::caution VATEX-FR-CNWVAT n'est admis que sur trois types de facture Un sous-total de tax_subtotals dont le tax_exemption_reason_code vaut VATEX-FR-CNWVAT n'est accepté que si la facture porte l'un de ces trois types : credit_note (381), self_billed_credit_note (261) ou factored_credit_note (396). Sur tout autre type_code - invoice (380) compris - la requête est refusée en 422, et le refus emporte l'ensemble : ni la facture ni ses sous-totaux ne sont enregistrés.

Cet ensemble est plus étroit que celui des avoirs. self_billed_factored_credit_note (502) et retainer_credit_note (503) sont bien des avoirs et sont admis partout ailleurs comme tels, mais ils ne portent pas ce motif d'exonération.

Le contrôle se rejoue en modification, y compris quand la requête ne renvoie pas la ventilation : un PATCH qui change le type_code d'une facture dont les sous-totaux déjà enregistrés portent VATEX-FR-CNWVAT est refusé si le nouveau type ne fait pas partie des trois. :::

curl -X POST https://app.scribee.tech/api/v1/e_reportings/YOUR_E_REPORTING_ID/invoices \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "invoice": {
      "invoice_number": "FAC-2026-0192",
      "issue_date": "2026-07-12",
      "due_date": "2026-08-12",
      "type_code": "invoice",
      "currency_code": "EUR",
      "seller_id": "843811544",
      "seller_scheme_id": "siren",
      "buyer_vat_number": "DE811907980",
      "buyer_country": "DE",
      "buyer_scheme_id": "european_union",
      "total_amount_excluding_taxes": 12000.0,
      "total_tax_amount": 0.0,
      "tax_subtotals": [
        {
          "amount_without_taxes": 12000.0,
          "vat_amount": 0.0,
          "vat_rate": 0.0,
          "currency_code": "EUR",
          "tax_category_id": "K"
        }
      ]
    }
  }'

Réponse abrégée aux champs utiles ici :

{
  "data": {
    "id": 2087,
    "invoice_number": "FAC-2026-0192",
    "issue_date": "2026-07-12",
    "due_date": "2026-08-12",
    "type_code": "invoice",
    "currency_code": "EUR",
    "seller_id": "843811544",
    "buyer_vat_number": "DE811907980",
    "buyer_country": "DE",
    "total_amount_excluding_taxes": 12000.0,
    "total_tax_amount": 0.0,
    "report_id": 498
  }
}

Consulter les enregistrements d'une déclaration

GET /api/v1/e_reportings/{e_reporting_id}/transactions et GET /api/v1/e_reportings/{e_reporting_id}/invoices renvoient les enregistrements de la déclaration, paginés (page, per_page - 20 par défaut, 100 au maximum). Les transactions se trient par date (défaut), category_code, transaction_count, total_amount_excluding_taxes, created_at ou updated_at ; les factures par issue_date (défaut), due_date, invoice_number, type_code, created_at ou updated_at. sort_order vaut asc ou desc, décroissant par défaut. Le paramètre include charge les associations dans la réponse : report et tax_subtotals pour les transactions ; report, invoice_lines, tax_subtotals, item_notes, discounts, expenses et invoice_references pour les factures. Un enregistrement isolé se lit sur GET /api/v1/e_reportings/transactions/{id} ou GET /api/v1/e_reportings/invoices/{id} ; le scope read suffit partout.

Sur les sous-totaux renvoyés par include=tax_subtotals, tax_exemption_reason et tax_exemption_reason_code ne sont pas restitués tels quels : le code est mis en majuscules, et quand l'un des deux manque Scribee le complète depuis son catalogue de régimes de TVA - y compris à partir du seul tax_category_id quand celui-ci ne désigne qu'un régime. Le K de l'exemple ci-dessus revient ainsi avec tax_exemption_reason_code à VATEX-EU-IC et la mention française correspondante, alors que la requête ne portait ni l'un ni l'autre ; le S de l'exemple de transaction laisse les deux champs à null.

Ce qui se passe ensuite

• L'enregistrement rejoint la déclaration dont vous avez donné l'identifiant, dans votre compte de production ; vous pouvez le relire immédiatement via les endpoints de liste. Rien n'est transmis à l'administration au moment de l'appel.
• L'API n'expose aucun cumul de déclaration. La liste des déclarations renvoie les bornes de période, l'échéance et l'état, jamais un total ; include=transactions n'ajoute qu'un résumé de chaque enregistrement rattaché. Faites vos totaux vous-même depuis les endpoints de liste.
• Le champ state de la déclaration est votre observation, en lecture : aucun appel de votre côté ne le modifie (L'e-reporting).
• L'échéance déclarative de la période est portée par due_date sur la déclaration.

Erreurs et cas limites

401 Unauthorized

Token absent, expiré ou invalide. Corps vide ; redemandez un token sur /oauth/token (Authentification).

403 Forbidden : scope insuffisant

Création, modification ou suppression avec un token limité à read :

{
  "error": "forbidden",
  "message": "Vous n'êtes pas autorisé à effectuer cette action"
}

Redemandez un token portant read write.

403 Forbidden : accès au workspace

Sur le seul appel de cette page qui porte un workspace_id - la liste des déclarations - un workspace qui existe mais auquel votre application n'est pas rattachée renvoie un message distinct :

{
  "error": "forbidden",
  "message": "L'application n'a pas accès à cet espace de travail"
}

404 Not Found

La déclaration ou l'enregistrement n'existe pas, ou appartient à un workspace hors du périmètre de votre application :

{
  "error": "not_found",
  "message": "La ressource demandée est introuvable"
}

Les endpoints /api/v1/e_reportings/... de cette page résolvent la déclaration et l'enregistrement parmi les workspaces que votre application peut atteindre depuis votre adresse IP : une adresse refusée par l'allowlist IPv4 du workspace donne donc un 404 ici, et non le 403 que renvoie la liste des déclarations (Votre premier appel). Vérifiez l'identifiant contre la liste des déclarations du workspace, puis votre adresse d'appel.

400 Bad Request : page au-delà de la dernière

Sur les listes, demander une page au-delà de la dernière page d'une collection non vide retourne :

{
  "error": "bad_request",
  "message": "Le numéro de page dépasse le nombre de pages disponibles"
}

Bornez vos requêtes avec meta.total_pages.

422 : mauvais type de déclaration

Une transaction ou une facture créée sur une déclaration de type payments est refusée :

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": ["Ce rapport ne peut pas contenir de transactions - son type doit être \"transactions\""]
  }
}

Pour une facture, le message est Ce rapport ne peut pas contenir de factures - son type doit être "transactions". Visez une déclaration de type transactions ; les paiements ont leur propre déclaration (Déclarer les paiements).

422 : rôle déclarant incompatible

Une transaction sur une déclaration de rôle BY est refusée avec le message Les transactions ne peuvent être rattachées qu'à un rapport de rôle vendeur (SE). Pour une facture dont les parties ne correspondent pas au rôle de la déclaration :

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": ["Le vendeur/acheteur de cette facture ne correspond pas au rôle déclarant du rapport"]
  }
}

Quand ni seller_id ni buyer_id ne permettent de situer l'entreprise déclarante - ou que les deux y correspondent sans que leurs numéros de TVA ne départagent les côtés - le message est Impossible de déterminer si la société est le vendeur ou l'acheteur pour cette facture - vérifiez les valeurs seller_id et buyer_id. C'est la réponse à attendre d'une charge utile qui identifie le déclarant sous un autre schéma que siren, ou par un identifiant plus long que son SIREN. Le même message tombe dans un troisième cas, où votre charge utile n'est pourtant pas en cause : la fiche de l'entreprise déclarante ne porte pas d'identifiant légal exploitable dans Scribee - aucun, ou moins de neuf chiffres - donc aucune comparaison n'est possible. Si vos deux identifiants sont corrects, complétez l'identifiant légal de la société avant de réessayer. La vérification se rejoue en modification dès que seller_id, buyer_id, l'un des deux schémas ou l'un des deux numéros de TVA figure dans la requête.

422 : champs manquants ou invalides

Un champ obligatoire absent renvoie l'enveloppe de validation, avec les messages toujours regroupés sous details.base - jamais sous le nom du champ fautif, même quand un seul champ est en cause. Chaque message associe le nom de la colonne, en anglais, au texte de validation, en français :

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": ["Category code doit être rempli(e)"]
  }
}

Les cinq champs contrôlés de la transaction empruntent la même enveloppe et le même regroupement sous details.base. Ils sont cumulables : une charge utile fautive sur les cinq reçoit les cinq messages.

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": [
      "Devise ne fait pas partie de la liste des devises ISO 4217",
      "Category code doit être TLB1 (livraisons de biens taxables), TPS1 (prestations de services taxables), TNT1 (opérations non taxables) ou TMA1 (opérations taxables sur la marge)",
      "Tax due date code doit être 5, 29 ou 72 (UNTDID 2475) ou 3, 35 ou 432 (UNTDID 2005), ou rester vide",
      "Transaction count doit être supérieur à 0",
      "Date ne peut pas être postérieure à la date du jour"
    ]
  }
}

La devise emprunte le même message sur la facture d'e-reporting et sur chaque sous-total de tax_subtotals. Ce message nomme l'attribut Devise, jamais currency_code, et n'indique pas quel sous-total est en cause. Un sous-total refusé emporte l'ensemble de l'écriture : ni l'enregistrement ni les autres sous-totaux ne sont créés.

Une entrée de discounts ou d'expenses sans amount_excluding_taxes emprunte la même enveloppe et le même regroupement sous details.base. Le message est Amount excluding taxes doit être renseigné : le flux 10.1 déclarerait sinon une remise de 0,00 (AllowanceCharge/Amount) pour une remise, et Amount excluding taxes doit être renseigné : le flux 10.1 déclarerait sinon un frais de 0,00 (AllowanceCharge/Amount) pour un frais. Les deux partagent le même préfixe Amount excluding taxes : seul le mot remise ou frais les distingue, et ni l'un ni l'autre n'indique quelle entrée du tableau est en cause.

Les champs de la facture à valeurs contraintes - type_code, seller_scheme_id, buyer_scheme_id, seller_tax_proxy_scheme_id, invoicing_process_id - suivent un autre chemin quand la valeur envoyée n'est pas reconnue : la réponse reste un 422 avec la même enveloppe, mais le message placé dans details.base est brut et entièrement en anglais, de la forme 'BAD' is not a valid type_code. Rapprochez-vous du nom de champ qu'il cite plutôt que de son libellé. siret fait exception sur seller_scheme_id et buyer_scheme_id : la valeur est reconnue, mais le flux 10 ne l'admet pas, et le message revient traduit, toujours regroupé sous details.base, sous la forme Seller scheme doit être siren (0002), european_union (0223), international (0227), ridet (0228) ou tahiti (0229) ; siret (0009) n'est pas admis en flux 10.

422 : schéma de partie manquant

seller_scheme_id et buyer_scheme_id sont contrôlés avant tout le reste, et leur message ne suit pas la forme des autres messages de validation : il cite le champ sous son nom d'API, en minuscules, au lieu du nom de colonne anglicisé. Le regroupement sous details.base, lui, est le même. Les deux côtés se cumulent - une charge utile qui n'envoie aucun des deux schémas reçoit les deux messages :

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": [
      "seller_scheme_id : le schéma d'identifiant de la partie est obligatoire ; sans lui la facture ne peut pas être déclarée en flux 10",
      "buyer_scheme_id : le schéma d'identifiant de la partie est obligatoire ; sans lui la facture ne peut pas être déclarée en flux 10"
    ]
  }
}

422 : identifiant hors du format de son schéma

Un seller_id ou un buyer_id qui ne respecte pas le format de son schéma reprend la forme habituelle : nom de colonne en anglais, texte en français, sous details.base. Les deux parties se cumulent.

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": ["Buyer ne respecte pas le format du schéma siren (siren et tahiti : 9 chiffres ; ridet : 9 ou 10 chiffres ; european_union et international : 18 caractères au plus)"]
  }
}

Ce contrôle vient après celui du rôle déclarant, et non avant : une charge utile dont le côté déclarant est lui-même mal identifié reçoit d'abord Impossible de déterminer si la société est le vendeur ou l'acheteur pour cette facture - vérifiez les valeurs seller_id et buyer_id. Le message de format est donc celui que vous verrez quand la partie fautive est la contrepartie, ou quand le déclarant est correctement identifié par ailleurs.

422 : motif d'exonération réservé aux avoirs

Un tax_exemption_reason_code à VATEX-FR-CNWVAT sur une facture dont le type_code n'est pas credit_note (381), self_billed_credit_note (261) ou factored_credit_note (396) :

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": ["Tax exemption reason code est réservé aux avoirs (types 261, 381, 396) ; cette facture porte le type 380"]
  }
}

Le message désigne le type de la facture par son code UNTDID 1001, même si votre requête a envoyé la clé Scribee. Il ne dit pas quel sous-total est en cause : la ventilation n'est pas indexée dans le message, à vous de retrouver la ligne portant ce code.

422 : acquisition non autoliquidée

Un sous-total en catégorie K ou G, ou en AE sans taux positif, sur une facture d'une déclaration de rôle BY. Le motif, dans details.base, nomme la catégorie refusée et rappelle qu'une acquisition se déclare avec la TVA autoliquidée, en catégorie AE au taux appliqué en comptabilité. Comme pour le motif d'exonération ci-dessus, il ne dit pas quel sous-total est en cause.

422 : totaux non rapprochés

Une transaction ou une facture dont total_amount_excluding_taxes s'écarte de la somme des amount_without_taxes de tax_subtotals, ou - en EUR seulement - dont total_tax_amount s'écarte de la somme des vat_amount, au-delà de la tolérance de 0,01 par montant additionné, évaluée comme le fait le PPF (voir plus haut : un écart égal à la tolérance peut être refusé). Chaque total en écart reçoit son propre message, et les deux se cumulent. Sur une facture :

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": [
      "[G1.53] total_amount_excluding_taxes : le total déclaré 1000.00 ne correspond pas à la somme des amount_without_taxes de tax_subtotals (1200.00), au-delà de la tolérance de 0,01 par montant additionné. Le PPF rejetterait tout le rapport sur cette facture.",
      "[G1.53] total_tax_amount : le total déclaré 200.00 ne correspond pas à la somme des vat_amount de tax_subtotals (150.00), au-delà de la tolérance de 0,01 par montant additionné. Le PPF rejetterait tout le rapport sur cette facture en EUR."
    ]
  }
}

Le message cite le total déclaré, puis la somme calculée entre parenthèses, tous deux arrondis à deux décimales et écrits avec un point décimal (1000.03), comme dans votre requête. Sur une transaction, les deux messages sont identiques, à leur fin près : sur cette transaction. et sur cette transaction en EUR. au lieu de sur cette facture. et sur cette facture en EUR.. Corrigez le total ou la ventilation pour qu'ils concordent ; un refus en création n'enregistre rien, un refus en modification laisse l'enregistrement tel qu'il était.

422 : déclaration déposée ou en cours d'acheminement

Une déclaration dont le PPF a accepté le dépôt (deposit_outcome à "300", L'e-reporting) ne change plus, et une déclaration transmise dont le PPF n'a pas encore répondu ne change pas non plus tant que la réponse n'est pas arrivée. Les trois verbes sont concernés de la même façon - créer, modifier et supprimer un enregistrement - parce qu'une ligne qui apparaît et une ligne qui disparaît éloignent autant l'enregistrement de Scribee de ce qui a été transmis. Une déclaration rejetée ("301") reste corrigeable : c'est exactement ce que la réforme attend.

À la création et à la modification, le refus emprunte l'enveloppe de validation décrite plus haut :

{
  "error": "unprocessable_entity",
  "code": "validation_failed",
  "message": "La validation a échoué",
  "details": {
    "base": ["Cette déclaration a été déposée auprès du PPF (300) : son contenu ne peut plus être modifié."]
  }
}

À la suppression, l'enveloppe diffère : le refus porte sur la déclaration entière et non sur un champ, donc le corps ne comporte pas de details et le motif est dans message. Branchez sur code, qui n'est ni traduit ni reformulé, plutôt que sur message.

{
  "error": "unprocessable_entity",
  "code": "operation_failed",
  "message": "Cette déclaration a été déposée auprès du PPF (300) : son contenu ne peut plus être modifié."
}

Quand la déclaration est en cours d'acheminement, le code est le même et le message dit que le PPF n'a pas encore répondu et invite à réessayer une fois la réponse arrivée. Ce refus-là est temporaire : il se lève dès que le verdict tombe.

422 : transaction d'une reprise d'acompte

Une transaction qui fait partie d'une reprise d'acompte (voir Les factures d'acompte reprises de l'agrégat B2C) ne se modifie ni ne se supprime plus. Trois transactions sont concernées : celle où Scribee avait compté la facture d'acompte, dont le comptage repris doit être conservé ; celle qui porte le montant négatif de la reprise, ou sa compensation, qui doit continuer de correspondre à ce qui avait été compté ; et celle où Scribee a compté une facture définitive dont la reprise a retiré des acomptes, vente qui doit rester déclarée à côté de la reprise. Le refus porte sur l'enregistrement entier : à la modification comme à la suppression, le corps porte code: "operation_failed", le motif dans message, et pas de details. Le PATCH d'une transaction peut donc répondre 422 sous deux formes : validation_failed avec details quand la charge utile est refusée, operation_failed sans details dans ce cas-ci. Branchez sur code.

À la suppression, le message dépend du rôle de la transaction dans la reprise. Pour celle où l'acompte avait été compté :

{
  "error": "unprocessable_entity",
  "code": "operation_failed",
  "message": "Ce cumul journalier de transactions ne peut pas être supprimé : une mensualité qui y est comptée a été reprise des données de transaction B2C par la facture finale qui la solde, et ce comptage doit être conservé."
}

Pour celle qui porte le montant négatif, le message est Ce cumul journalier de transactions ne peut pas être supprimé : il porte le montant négatif qui reprend une mensualité des données de transaction B2C, enregistré pour la facture finale qui la solde, et cette reprise doit être conservée., y compris pour celle qui porte une compensation. Pour celle où la facture définitive a été comptée, le message est Ce cumul journalier de transactions ne peut pas être supprimé : il compte une facture de solde dont la reprise a retiré des données de transaction B2C les mensualités qu'elle solde, et cette vente doit rester enregistrée à côté de la reprise.

À la modification, l'enveloppe est la même, et le message est Ce cumul journalier de transactions ne peut pas être modifié : une mensualité qui y est comptée a été reprise des données de transaction B2C par la facture finale qui la solde, et le modifier ne correspondrait plus à ce qui a été repris. pour la transaction où l'acompte avait été compté, et Ce cumul journalier de transactions ne peut pas être modifié : il porte le montant négatif qui reprend une mensualité des données de transaction B2C, enregistré pour la facture finale qui la solde, et le modifier ne correspondrait plus à ce qui a été compté. pour celle qui porte le montant négatif ou sa compensation, et Ce cumul journalier de transactions ne peut pas être modifié : il compte une facture de solde dont la reprise a retiré des données de transaction B2C les mensualités qu'elle solde, et le modifier ne correspondrait plus à cette reprise. pour celle où la facture définitive a été comptée.

422 : transaction où Scribee a compté des factures

Une transaction dans laquelle Scribee a lui-même compté des factures de l'agrégat B2C (voir Ce que Scribee déclare seul depuis vos factures) ne se modifie ni ne se supprime plus, qu'elle fasse partie d'une reprise d'acompte ou non : ses totaux doivent continuer de correspondre à ce qui y a été compté. Scribee compte une vente dans la transaction de la déclaration qui porte déjà la même date, la même category_code et la même currency_code, et n'en crée une que s'il n'en existe aucune : une transaction que vous avez déclarée vous-même tombe donc sous ce refus dès que Scribee y compte une facture. Une transaction dans laquelle Scribee n'a compté aucune facture reste modifiable et supprimable. Le refus porte sur l'enregistrement entier, avec la même enveloppe que pour une reprise d'acompte : code: "operation_failed", le motif dans message, et pas de details. Lorsque la transaction fait aussi partie d'une reprise d'acompte, c'est le message de la reprise qui est renvoyé (voir 422 : transaction d'une reprise d'acompte plus haut).

À la suppression :

{
  "error": "unprocessable_entity",
  "code": "operation_failed",
  "message": "Ce cumul journalier de transactions ne peut pas être supprimé : la plateforme y a compté elle-même des factures déclarées dans les données de transaction B2C, et ces déclarations doivent être conservées."
}

À la modification, l'enveloppe est la même, et le message est Ce cumul journalier de transactions ne peut pas être modifié : la plateforme y a compté elle-même des factures déclarées dans les données de transaction B2C, et le modifier ne correspondrait plus à ce qui a été compté.

Pages liées

• L'e-reporting - les déclarations, leurs périodes et leurs états
• Déclarer les paiements - la déclaration des encaissements
• Référence API : lister les factures d'e-reporting
• Référence API : créer une facture d'e-reporting
• Référence API : lister les transactions d'e-reporting
• Référence API : créer une transaction d'e-reporting
• Référence API : créer une facture
• Référence API : modifier une facture