Changelog

Toute évolution de l'API est documentée ici dès sa publication. La version active est annoncée dans le header Facturino-Version renvoyé sur chaque réponse. La politique de dépréciation (préavis 12 mois minimum, aucune suppression silencieuse) est détaillée dans Versions de l'API.

L'API est en production. La version contractuelle courante est 2026-09-01 — le premier contrat stable, et la seule version servie. Une date publiée ne change jamais rétroactivement : les futures versions datées seront immuables et coexisteront. Chaque évolution est consignée ci-dessous — un ajout rétro-compatible conserve la même version (ligne datée).

Versions

2026-09-01

1 septembre 2026

Modifié 5 novembre 2026 Formes juridiques : toutes les catégories juridiques INSEE de niveau III sont acceptées en entrée (`legalForm: { code }`) et publiées par `GET /v1/reference/legal-forms`. `sigle` n’est présent que sur les formes qui ont un sigle usuel (SAS, SARL, SCI…) ; les autres portent leur `code` et leur `label` INSEE, comme le contrat le permettait déjà. SASU et EURL ne sont pas des catégories INSEE : `{ sigle: "SASU" }` et l’ancien code `5720` sont enregistrés sous `5710` (SAS), `{ sigle: "EURL" }` et `5498` sous `5499` (SARL) ; les fiches enregistrées sous `5720` ou `5498` sont reprises sous ces codes. Les nouvelles fiches portent le libellé INSEE ; les autres fiches existantes gardent le leur et un document émis ne change pas. Ajout compatible, date de contrat inchangée.
Modifié 26 octobre 2026 E-reporting : opérations hors du champ de la TVA française (catégorie O), pas de données de paiement. Une déclaration de paiement non transmise exclusivement issue de telles opérations peut être close localement avec `state: skipped`, `status: skipped`, `skippedReason: nothing_to_declare` et `obligation.state: completed`, sans modifier les décisions fiscales figées. Le résumé historique `status: skipped` pouvait déjà désigner une déclaration bloquée dont l’obligation restait due : lire l’état réel et le motif. État et motif documentés dans OpenAPI ; date d’API inchangée 2026-09-01.
Ajouté 26 octobre 2026 E-reporting : `obligationBasis` (`legal`, `voluntary_early_adoption` ou null) et `obligationDueFrom` (date légale d’ouverture de la vague, ou null) sont figés à la réservation. `acknowledgedBy` distingue l’accusé de l’administration (PPF) de celui de la plateforme ; les accusés historiques gardent null. `obligationBasis` est aussi publié sur `TaxDecision` et `TaxSnapshot`. Ajouts compatibles, date d’API inchangée 2026-09-01.
Ajouté 24 octobre 2026 TGCA de Saint-Martin, sous les deux sources fiscales (`facturino` et `integration`) : une prestation située à Saint-Martin porte la taxe générale sur le chiffre d’affaires de 4 % (CGIsm art. 252 et 258 à 264), jamais comme de la TVA. Profil fiscal du vendeur : `localTaxRegistrations` (jusqu’à 10 entrées `{ territory: "MF", reference, effectiveFrom, effectiveTo }`). Ligne de la demande de décision, sous les deux sources : `localTaxExemption` (`cgism_253`, `not_used_in_saint_martin`). Lignes de la décision, de la facture, de l’avoir et du `taxSnapshot` : `localTax` (`code` `tgca_mf`, `rateCentipercent`, `amount`, `reference`, `exemption`) ; totaux : `totals.totalLocalTax` (`totalLocalTaxCents` dans le snapshot), absent quand aucune ligne n’en porte et inclus dans `totalTTC` et dans le montant à encaisser. Sans immatriculation en vigueur ni exonération déclarée, la décision reste en attente (`pending_verification`, `com_taaf_supplier_local_tax_liable`). Facture électronique : charge de niveau document (BG-21, catégorie `O`). Sous la source `integration`, Facturino calcule la TGCA sur les mêmes faits : l’intégration déclare l’exonération, jamais un taux, et `vatRate` ne décrit que la TVA française. Ajouts compatibles, date de contrat inchangée.
Ajouté 24 octobre 2026 `Customer.taxStatus` (`taxable` ou `non_taxable`) sur la création et la mise à jour des clients : le statut TVA que le vendeur déclare (CGI art. 256 A et 259-0). Une association, un organisme public ou une forme juridique dont le statut dépend de l’activité (catégories 7, 8 et 9) sans `taxStatus` laisse la décision en attente (`business_status_not_evidenced`, `detailCode` `tax_status_not_declared`). `null` en `PATCH` retire la déclaration, un champ omis est conservé ; sans objet pour un client `individual`. Ajout compatible, date de contrat inchangée.
Modifié 24 octobre 2026 Décisions fiscales : Facturino ne retient plus d’hypothèse à la place d’un fait que le vendeur peut compléter. Trois cas laissent la décision en attente (`pending_verification`), sans montant : un acheteur déclaré professionnel sans SIRET, sans numéro de TVA validé ni preuve de l’art. 18 §3 (`business_status_not_evidenced`, ou le code précis `eu_b2b_vat_number_not_validated`, `non_eu_business_status_not_evidenced`) ; des indices de localisation d’un particulier insuffisants ou contradictoires au-delà des deux cas que le moteur tranche (`location_evidence_insufficient`, `location_evidence_contradictory`) ; un seuil UE de 10 000 € non déclaré (`eu_threshold_state_missing`). Une adresse d’un État membre sans code postal, quand ce code sépare des territoires de TVA (Espagne, Italie, Allemagne, Finlande, Grèce) ou une région à taux propre (Portugal), est refusée (`destination_regional_scope_undetermined`). Date de contrat inchangée.
Modifié 24 octobre 2026 Codes VATEX : la liste officielle du Schematron CIUS-FR (88 codes, liste VATEX du CEF) est acceptée en entrée et publiée en sortie — `vatexCode` de `LineItemInput`, `LineItem`, `CreateProductInput`, `UpdateProductInput` et `Product`, lignes de la décision d’intégration et de ses sorties — et chaque code imprime une mention française dérivée du code. Les anciennes écritures `VATEX-FR-261` (formation, art. 261-4-4° a du CGI) et `VATEX-FR-AUTOLIQ` (autoliquidation BTP) restent acceptées ; elles sont enregistrées sous le code officiel qu’elles désignent (`VATEX-FR-CGI261-4`, `VATEX-FR-AE`) sur les nouvelles décisions, les nouveaux avoirs et les produits, la mention précise de la formation étant conservée ; le document est émis sous le code officiel en BT-121, dans le PDF et dans la mention légale. Les documents déjà émis et les données déjà enregistrées gardent leur code, sans migration : une lecture renvoie ce qui est enregistré, et une ligne de devis garde l’écriture reçue. Sous la source `integration`, le code est lié à sa catégorie comme dans la liste VATEX du CEF : `VATEX-EU-AE`, `VATEX-FR-AE` et l’ancienne écriture `VATEX-FR-AUTOLIQ` avec `AE`, `VATEX-EU-IC` avec `K`, `VATEX-EU-G` avec `G`, `VATEX-EU-O` avec `O`, tous les autres avec `E` ; toute contradiction est refusée, jamais corrigée, et une catégorie `S` ou `Z` ne porte aucun code (BR-S-10, BR-Z-10). Les dix codes d’origine gardent exactement les catégories qu’ils avaient, `VATEX-FR-CNWVAT` comprise. Un produit refuse un code avec une catégorie `S` ou `Z` ; une ligne de devis n’est pas contrôlée, la décision fiscale contrôle tout à la facturation. `vatexCode` est désormais enregistré sur les produits, comme le contrat le publiait. Ajouts compatibles. Facture électronique (EN 16931 BR-O-02, BR-O-04, BR-CO-26) : un document qui utilise la catégorie `O` — sur une ligne, dans la ventilation ou par la TGCA — ne porte pas d’identifiant de TVA du vendeur (BT-31) ni de l’acheteur (BT-48) dans le CII et l’UBL ; le SIREN (BT-30, BT-47) identifie les parties, et le PDF conserve le numéro de TVA. Date de contrat inchangée.
Correctif 24 octobre 2026 Produits : `kind` (`goods`, `service`) et `supplyCategory` (`goods`, `services`, `electronically_supplied_services`, `deposit`, `ancillary_costs`) étaient acceptés à la création mais jamais enregistrés. Ils le sont désormais à la création et à la modification (`POST` et `PATCH /v1/products`, et l’application), et publiés sur `Product`, `CreateProductInput` et `UpdateProductInput`. La nature fiscale d’un produit alimente la décision d’une ligne qui le reprend : un service fourni par voie électronique n’est plus ramené à une prestation ordinaire, et un produit qui n’en porte pas ne fait plus écraser la nature choisie sur la ligne. Un produit créé auparavant n’a pas de nature enregistrée : elle se précise à la décision ou en le modifiant. `ancillary_costs` (des frais de port, par exemple) et `deposit` suivent l’opération principale du document : la ligne qui reprend le produit la désigne. `UpdateProductInput` documente enfin tous les champs que le serveur acceptait déjà (`reference`, `category`, `active`), et `LineItemInput` son `kind`. Ajouts compatibles, date de contrat inchangée.
Modifié 24 octobre 2026 Nature fiscale d’une ligne : une ligne de devis porte un `supplyCategory` facultatif (`LineItemInput`, `LineItem`), stocké et recopié par la conversion en brouillon de facture avec le `kind` du devis. La conversion n’invente plus « services » : seul `kind: goods` donne `goods`, un fait. Une intégration qui reprend `commercialDraft.lines[].supplyCategory` d’un brouillon converti pour demander sa décision déclare `supplyCategory` sur la ligne de devis : sans elle, la ligne du brouillon n’en porte aucune et la demande publique, qui exige `category`, est refusée. La nature non déclarée ne concerne que les lignes de service des devis et des brouillons : la demande publique `POST /v1/tax-decisions` exige toujours `category` (champ requis, refus `validation_error` inchangé). Pour une ligne de devis ou de brouillon qui n’en déclare aucune, la décision distingue ce que l’on sait. Une prestation (`kind: service`) est lue sous `services` et sous `electronically_supplied_services` — seules les natures que le profil du vendeur active — et le résultat complet est comparé (traitement, catégorie, taux, code d’exonération, mentions, taxe locale, trois axes, dépendance au registre du seuil) : le même, elle est finale, la ligne est décidée en `services` et un avis `supply_category_not_declared` le dit ; différent, elle reste en attente (`pending_verification`, motif `supply_category_not_declared`, sans montant). Une ligne dont on ne sait rien (ni nature ni `kind`) n’est jamais lue en service : la décision attend la nature, sans aucune lecture. `TaxDecisionLine.category` vaut `null` uniquement sur ces décisions en attente, jusqu’à la déclaration ; une décision prise sur la demande publique la porte toujours. Une ligne qui déclare sa nature est décidée comme avant. Code nouveau, contrat de la demande publique inchangé : date de contrat inchangée.
Modifié 24 octobre 2026 TGCA de Saint-Martin, prestation générale à un particulier : elle reste localisée chez le prestataire (CGI art. 259-2°) et porte la TVA française ; utilisée à Saint-Martin, elle doit aussi la TGCA (CGIsm art. 252), et aucun texte détenu ne règle le cumul des deux taxes. Sans `localTaxExemption`, la source `facturino` refuse la décision (`unsupported`, `com_taaf_local_regime_not_sourced`, `detailCode` `french_vat_and_tgca_cumulation`) : `not_used_in_saint_martin` décide la TVA française seule, `cgism_253` y ajoute la mention d’exonération de TGCA. Sous la source `integration`, la décision reste finale avec la TVA fournie ; un avis du même code dit que la TGCA n’est pas facturée. Nouveau `detailCode`, ajout compatible, date de contrat inchangée.
Modifié 24 octobre 2026 Taxes locales des collectivités d’outre-mer et des TAAF : la taxe que Facturino ne détient pas — Wallis-et-Futuna, TAAF, retenue à la source de la Polynésie française, taxe locale d’un particulier — n’est ni calculée ni supposée nulle. Sous la source `facturino`, la décision est refusée (`unsupported`, sans montant) avec `com_taaf_local_regime_not_sourced`, `com_taaf_local_tax_not_determined` ou `com_taaf_payment_withholding_not_modelled`, et le message propose la source `integration`. Sous la source `integration`, elle est finale, porte l’avis du même code et `foreignTaxReviewRequired: true` : la taxe que l’intégration a déterminée est la sienne à facturer. Restent finales sous les deux sources les cas qu’un texte officiel de la collectivité règle : taxe autoliquidée par le preneur assujetti en Nouvelle-Calédonie, aucune taxe sur le chiffre d’affaires à Saint-Barthélemy et à Saint-Pierre-et-Miquelon, biens expédiés à Saint-Martin. Date de contrat inchangée.
Ajouté 24 octobre 2026 Nouveau motif `vat_category_o_split_required` (`unsupported`) : un document ne mêle pas la catégorie `O` (hors du champ de la TVA) à une autre catégorie (EN 16931 BR-O-02, BR-O-11 à BR-O-14, BR-S-02), par exemple un bien taxé en métropole et une prestation située à Saint-Martin. Sous les deux sources, aucun montant : décidez chaque groupe de lignes dans sa décision et facturez-les sur deux documents. Ajout compatible, date de contrat inchangée.
Modifié 24 octobre 2026 Décisions fiscales, particulier aux indices divergents : un indice qui ne dit que le pays soutient le territoire de ce pays que l’adresse ou un autre indice désigne ; seul, il désigne le territoire du pays — et, pour la France, tous les territoires français (métropole, Corse, départements et collectivités d’outre-mer, TAAF), jamais la métropole seule. La règle « tous les territoires possibles mènent au même traitement » compare le résultat fiscal complet — TVA, catégorie, mentions, taxe locale facturée (TGCA selon l’immatriculation réelle du vendeur) et axes de transmission —, non le seul taux. Date de contrat inchangée.
Modifié 24 octobre 2026 Décisions fiscales, présomption de l’art. 18 §2, 2e alinéa, du règlement d’exécution (UE) 282/2011 : appliquée dans son seul champ, à un acheteur établi dans le territoire de TVA de l’Union (Monaco compris ; ni la Guadeloupe, la Martinique ou La Réunion) qui n’a communiqué aucun numéro de TVA. Un numéro communiqué et non validé laisse la décision en attente (`eu_b2b_vat_number_not_validated`) ; une association, un organisme public ou une fondation (catégories 7, 8 et 9) sans `taxStatus` garde son refus (`tax_status_not_declared`). Dans la zone de TVA du vendeur, un acheteur déclaré professionnel sans preuve ne bloque pas une prestation ordinaire tant que son résultat complet — TVA, mentions, trois axes de transmission — est le même sous les deux statuts ; une fois le vendeur entré dans la réforme, les axes diffèrent et la décision attend. Date de contrat inchangée.
Modifié 24 octobre 2026 Client `non_taxable` identifié à la TVA (CGI art. 259-0) : VIES est consulté quel que soit le statut préliminaire du client. Numéro validé : ses services suivent les règles des assujettis (autoliquidation pour un client allemand, par exemple) ; VIES injoignable : ses services attendent (`vies_unavailable`) ; numéro rejeté ou absent : règles des non-assujettis. Ses biens n’attendent VIES que lorsqu’ils sont expédiés dans un autre État membre (entrée suivante). En France, l’immatriculation nationale tient la place de la consultation VIES. Date de contrat inchangée.
Modifié 24 octobre 2026 Biens expédiés dans un autre État membre, ou en Irlande du Nord, à une personne morale non assujettie qui a communiqué un numéro de TVA que VIES valide (`Customer.taxStatus: non_taxable`) : la livraison est exonérée (livraison intracommunautaire, catégorie `K`, `VATEX-EU-IC`, directive 2006/112/CE art. 138 §1, b) si les acquisitions de ce client sont soumises à la TVA, et soumise à la TVA comme une vente à distance sinon (art. 3 §1 et 139 §1 ; CGI art. 256 bis I 2°, 258 A, 262 ter I). Ce fait est celui du client et aucun champ ne le porte : sous la source `facturino`, la décision est refusée (`unsupported`, nouveau code `non_taxable_legal_person_goods_regime_not_modelled`, `foreignTaxReviewRequired: true`, aucun montant) et le message propose la source `integration` ; sous la source `integration`, les deux traitements sont admis — `K` avec le numéro du client, ou la vente à distance selon le seuil — et la décision est finale, avec l’avis du même code. VIES injoignable : les biens attendent (`vies_unavailable`). Un client sans numéro ou dont VIES rejette le numéro, des biens qui restent en France, une exportation hors de l’Union et les services ne sont pas concernés. Ajout compatible, date de contrat inchangée.
Modifié 24 octobre 2026 Territoires exclus de la TVA de l’Union (Canaries, Ceuta, Melilla, Åland, mont Athos, Büsingen, Helgoland, Livigno, Campione d’Italia) : l’impôt indirect du territoire (IGIC, IPSI…) pèse sur le montant à facturer et Facturino n’en détient aucune règle, comme la taxe locale d’une collectivité. Un acheteur qui y est établi donne, sous la source `facturino`, une décision refusée (`unsupported`, `eu_special_territory_not_implemented`, `foreignTaxReviewRequired: true`, aucun montant) dont le message propose la source `integration` ; sous la source `integration`, la décision est finale, avec l’avis du même code et `foreignTaxReviewRequired: true` : l’impôt que l’intégration a déterminé est le sien à facturer. Un vendeur qui y est établi reste refusé sous les deux sources. Date de contrat inchangée.
Ajouté 24 octobre 2026 `TaxDecision.legalCategory` : pour un acheteur français déclaré professionnel dont le SIREN est connu mais ni la forme juridique ni le statut TVA, Facturino interroge le registre SIRENE à la décision — jamais en écrivant sur la fiche client — et fige la catégorie juridique, sa source et sa date (`source`, `siren`, `status` `found`, `not_found` ou `unavailable`, `legalCategoryCode`, `checkedAt`) ; une consultation de moins de 30 jours est reprise du cache serveur. Catégorie 7, 8 ou 9 : en attente (`business_status_not_evidenced`, `detailCode` `tax_status_not_declared`) ; registre injoignable ou SIREN introuvable : en attente (`detailCode` `legal_category_unresolved`) ; autre catégorie : l’immatriculation établit la qualité d’assujetti. Le champ est absent quand aucune consultation n’était due. Ajouts compatibles, date de contrat inchangée.
Modifié 24 octobre 2026 Mention légale du code `VATEX-FR-CGI261-4` : fourni par un client, une intégration ou une ligne hors parcours de formation, il porte la mention générale « TVA non applicable — exonération de l’article 261-4 du CGI » ; le parcours formation de Facturino (et l’ancien code `VATEX-FR-261`) garde « TVA non applicable, art. 261-4-4° a du CGI ». `VATEX-FR-CNWVAT` est le code d’un avoir sans TVA : Facturino ne l’émet jamais de lui-même sur une facture, et un code déclaré est repris tel que déclaré. Date de contrat inchangée.
Correctif 18 octobre 2026 Statut « Encaissée » : jamais émis sur une facture rejetée ou refusée, ni après la réponse « La facture possède déjà un statut final » de la plateforme. `Payment.fr212.state` vaut alors `blocked` avec `lastErrorCode` `transmission_final` ou `pa_status_already_final` (motif dans `lastErrorReason`) : sans objet, définitif pour cette tentative et sans action attendue ; aucune alerte n’est émise, et un nouveau dépôt accepté de la facture remet le statut en file. Aucune valeur nouvelle : date de contrat inchangée (2026-09-01).
Correctif 18 octobre 2026 Position de transmission : les événements de paiement du destinataire (211, 212, `allegedly_paid`, `PAYMENT_SENT`, `PAYMENT_RECEIVED`, `collected`) ne masquent plus la position chez Super PDP, AFNOR, Iopole, Seqino et B2Brouter ; ils sont lus à part et ne modifient que l’axe de paiement. Un événement Seqino `completed` (209 « Complétée ») n’est plus lu comme un encaissement. Rejets : `REJ_UNI` et `DOUBLON` donnent la catégorie `duplicate` (« Numéro déjà connu de la plateforme ») ; les avoirs CII et UBL portent la date de la facture d’origine (BT-26, CIUS-FR BR-FR-CO-05).
Correctif 10 septembre 2026 Contrôle de campagne : intention colorimétrique Factur-X GTS_PDFA1 et validation renforcée ; réparation des archives préparée sans écrasement des originaux. Le PATCH établissement recalcule le SIREN ; les motifs B2Brouter et les codes Iopole restent structurés et verbatim. Les routes d’encaissement B2Brouter et Seqino et la ventilation Iopole sont vérifiées localement ; cette porte ne remplace pas une qualification distante.
Modifié 10 septembre 2026 Train préparé : app 2026.3.23, Functions 2.7.0, SDK Node, Go, Python et PHP 2.7.0. Date de contrat inchangée (2026-09-01). Les reçus des webhooks entrants sont isolés par établissement, plateforme et événement ; une échéance durable précède la première livraison sortante. Les mutations protégées conservent leur reçu d’effet après perte de la réponse ; les autres rejeux ambigus sont refusés avant réexécution.
Modifié 10 septembre 2026 Les crons de maintenance reprennent leurs parcours depuis un curseur durable. Les écritures financières bornent les données sérialisées à 512 Kio et archivent les historiques volumineux dans des segments vérifiables. Les journaux masquent les appelants et les contenus fournisseur. Les files internes terminées de facturation sont conservées 90 jours ; les pièces légales gardent leur règle de conservation.
Modifié 10 septembre 2026 Réception Iopole : pagination distante par recherche, avec borne documentée de 1 100 résultats pour les pages de 100. Les avis annuaire sont dédoublonnés ; un e-mail dont l’acceptation est incertaine attend une preuve signée du prestataire avant tout renvoi. Les compteurs API utilisent des blocs de 20 autorisations par minute et 10 par mois : après arrêt ou éviction du cache, chaque bloc peut laisser jusqu’à 19 ou 9 autorisations inutilisées réservées jusqu’à la fin de la fenêtre. Ces réservations peuvent se cumuler ; les en-têtes de solde sont conservateurs.
Correctif 9 septembre 2026 Capacités des plateformes : les obligations sont vérifiées par code avant émission. Iopole (date d’encaissement non vérifiée), B2Brouter (montants et date absents) et Seqino (lecture seule) laissent le statut bloqué avec un motif précis. La page de connexion distingue couverture implémentée, preuve historique ou simulée, et obligations non couvertes.
Correctif 9 septembre 2026 Sécurité : transport HTTPS à résolution DNS fixée, clés incohérentes refusées, journaux d’e-mail sans adresse ni sujet, secrets liés par famille de fonctions et disjoncteur isolant les erreurs de compte. La validation fiscale requise échoue fermée et conserve sa preuve ; les historiques volumineux sont archivés sans perte en sous-collection.
Correctif 9 septembre 2026 Contrat et retours : les paiements exposent `recorded_by` (`api`, `app`, `system`) ; JSON invalide et corps trop grand répondent 400/413 avec `request_id` ; un curseur disparu répond 400 `invalid_field_value`. Les webhooks disposent de données discriminées par famille, de cinq tentatives sur 2 h 36 de délais planifiés et de 90 jours de conservation. La récupération des tâches perdues lit les échéances durables. `ereporting.submitted` est écrit avec la transition durable, REST et cron, une fois par déclaration et tentative. Les quatre SDK partagent les réponses HTTP locales de référence, y compris les champs absents et null.
Ajouté 8 septembre 2026 SDK Node, Go, Python et PHP 2.7.0 : contrat de lecture aligné. Rejets : `rejectionCode`, `rejectionSource`, `rejectionNote`, `rejectionReason`, `rejectionCategory` (onze catégories) et `paErrorCode` dans les événements ; routage et suivi : `routingIdentifier`, `buyerReachableAt`, `directoryCheckedAt`, `submissionArtefact.routingIdentifier`, `previousSubmissions` ; paiements : `Payment.fr212` avec `state` (`awaiting_deposit` inclus), `sentAt`, `lastErrorCode`, `lastErrorReason`, `updatedAt` ; avertissements : `Customer.warnings` et `TaxDecision.warnings` (`BuyerNatureWarning`) ; avoirs et événements associés : `relatedInvoiceNumber`. Les exemples et la nullabilité sont décrits dans OpenAPI, sans changement de date du contrat. Python et PHP reprennent aussi les modèles des versions 2.5 et 2.6 et le reçu de rejeu ciblé.
Ajouté 8 septembre 2026 Messages par langue du compte : catalogue français commun, historique structuré par `code` et `params` avec `details` conservé, notifications et e-mails cohérents. Les erreurs API gardent leurs codes, leurs messages anglais et leur `doc_url`. Aucune autre langue ni sélecteur dans cette version.
Correctif 8 septembre 2026 Classification des rejets par code : REJ_ADR désigne une incohérence de routage ; AUTRE attend une explication en note. La source du verdict est enregistrée explicitement, les motifs et notes restent verbatim. Le renvoi archive le verdict puis efface les champs courants.
Ajouté 8 septembre 2026 Revérification quotidienne des acheteurs absents de l’annuaire, plafonnée à 200 SIREN par établissement : dates `directoryCheckedAt` et `buyerReachableAt`, notification réglable `buyer_reachable`, sans renvoi automatique. Avertissement non bloquant `buyer_nature_suspect` sur les clients et décisions fiscales ; numéro de facture liée servi sur les avoirs et leurs événements. Le signal fr:211 est une mention d’historique seule, sans changement de statut ni webhook.
Correctif 8 septembre 2026 Statut « Encaissée » : aucune émission sur une tentative rejetée ou sans identifiant courant. Les items attendent en `awaiting_deposit`, sans reprise par le cron, puis sont réveillés par le dépôt accepté. Un refus HTTP 4xx devient `blocked` avec son motif conservé sur l’item, le paiement et la notification ; les issues de transport et 5xx restent à rapprocher. Le travailleur requalifie les anciens items en attente d’un dépôt utilisable.
Correctif 8 septembre 2026 Routage du dépôt : le CII porte l’adresse de réception active renvoyée par l’annuaire, en priorité pour le SIRET de l’acheteur. `einvoicing.routingIdentifier` expose l’adresse utilisée ; l’artefact régénéré la conserve aussi. Les identifiants légaux, l’original archivé et la clé d’idempotence du dépôt sont conservés. Un annuaire indéterminé laisse le dépôt inchangé.
Ajouté Premier contrat stable de l'API Facturino : 147 endpoints REST sous `/v1/*` couvrant la facturation électronique française (Factur-X EN 16931, CIUS-FR, e-reporting, cycle de vie DGFiP).
Ajouté Ressource immuable `POST /v1/tax-decisions` et `GET /v1/tax-decisions/:id` : la TVA, les montants de la facture et les trois obligations de transmission sont arrêtés pour tout le cycle, quel que soit le moyen de paiement. Une décision non finale ne porte aucun montant. L'en-tête `Idempotency-Key` y est obligatoire : `201` à la création, `200` au rejeu de la même clé, `409` si la même clé est réutilisée avec un corps différent.
Ajouté Deux sources fiscales de même niveau, en union discriminée par `taxSource` : `facturino` (la TVA est déterminée par les moteurs Facturino) et `integration` (la TVA est fournie par l'intégration — `vatRate`, `vatCode`, `vatexCode` par ligne — validée en cohérence, jamais corrigée en silence). Dans les deux parcours, les montants, les mentions légales et les trois axes d'obligation sont décidés côté serveur.
Ajouté Cycle documentaire décision-premier : les factures exigent `taxDecisionId` + `decisionLines`, les avoirs référencent les lignes originales (`creditedLines`) et héritent strictement de la source et du snapshot de la facture corrigée, les récurrences portent `taxInputs` et prennent une nouvelle décision à chaque occurrence. Une décision finale adosse exactement une facture.
Ajouté Cycle du devis sur un seul document : `POST /v1/quotes/:id/convert` produit un brouillon commercial (`taxSource: null`, `items` vide, opération lisible dans `commercialDraft`), puis `POST /v1/invoices/:id/bind-tax-decision` adosse une décision finale à ce même brouillon avant sa finalisation. L'appel est idempotent sur la décision ; adosser une autre décision à une facture déjà adossée, ou la même décision à une seconde facture, répond `409`.
Ajouté Les factures et avoirs exposent trois axes indépendants — `documentStatus`, `transmissionStatus`, `paymentStatus` ; le champ `status` est un résumé dérivé de ces axes, jamais une autorité propre.
Ajouté Le dépôt PA est autorisé uniquement quand la décision figée porte `invoiceChannel: einvoicing`. Les refus portent des codes stables (`tax_decision_required`, `not_einvoicing_channel`, `tax_snapshot_inconsistent`) et un chemin de sortie — demandez une décision, puis réémettez. Le téléchargement Factur-X / XML et le dépôt manuel restent disponibles sur tous les plans.
Ajouté Un acompte doit être **intégralement réglé** avant qu'une facture de solde puisse le déduire (BT-113/BT-115) ; l'échéancier répartit exactement le montant décidé restant dû.
Ajouté Reprise d'une déclaration e-reporting refusée : `POST /v1/ereporting/declarations/:id/retry` crée la tentative suivante des mêmes données. La déclaration refusée est CONSERVÉE et les deux sont chaînées (`supersedesDeclarationId` / `supersededByDeclarationId`). Un refus de la plateforme répond `422 ereporting_declaration_rejected`.
Ajouté Modèle BYOPA (Bring Your Own PA) : 4 Plateformes Agréées supportées en production + un connecteur générique AFNOR XP Z12-013.
Ajouté 4 SDKs officiels (Node, Python, PHP, Go) avec auto-pagination, retry exponentiel et types stricts.
Ajouté Format d'erreur stable inspiré de Stripe : `error.type`, `error.code`, `error.param`, `error.request_id`, `doc_url`, `hint`. Webhooks signés HMAC-SHA256 (tolérance 5 minutes, idempotence par `event_id`, retries exponentiels). Idempotence native via `Idempotency-Key` sur les POST. `Facturino-Version` renvoyé sur toutes les réponses.
Ajouté Endpoints `/v1/usage` (compteurs de quota en temps réel) et `/v1/billing/subscription` (plan, renouvellement, état de l'abonnement).
Ajouté 2 septembre 2026 Ventes B2C dans l'Union : registre annuel des seuils `/v1/eu-threshold-ledgers` (ouverture, mouvements, ajustements, corrections, revue), trace `euB2cDestination` sur la décision, `goodsMovement` sur les lignes d'intégration, registre daté des taux normaux des 27 États membres.
Ajouté 3 septembre 2026 `error.issues` : les raisons détaillées d'un refus, `{ code, param, message }`, facultatif et additif, au plus 500 raisons, identiques entre la première réponse et son rejeu idempotent.
Modifié 3 septembre 2026 Preuves de localisation réseau (`ip_geolocation`, `bank_details`, `sim_mobile_country`, `fixed_line`) transmises sans code postal : résolues au niveau du pays, `territoryId: null` sur la preuve, l'adresse de facturation portant le territoire fin. Une `reference` de preuve qui est une adresse IP ou un IBAN est refusée.
Ajouté 4 septembre 2026 `POST /v1/invoices/:id/finalize` accepte un `payment` facultatif : une facture encaissée d'avance est émise acquittée dans la même transaction, son original PDF et Factur-X rendus sur la facture réglée. `dates.paidAt` porte la date réelle de règlement.
Ajouté 6 septembre 2026 Webhooks : `data` porte désormais, en plus du saut (`status`, `previous_status`), le document tel qu'écrit : `number`, `documentStatus`, `transmissionStatus`, `transmissionDetail`, `paymentStatus` et `metadata` ; les avoirs ajoutent `relatedInvoiceId`, les devis `number` et `metadata` ; `payment.received` ajoute `total` et `amountDue`. Ajout compatible, date de contrat inchangée. Le bac à sable émet le même payload que la production (`previous_status`).
Ajouté 6 septembre 2026 `POST /v1/events/:id/retry` accepte `{ "endpointId" }` pour rejouer un événement vers un seul endpoint, même déjà livré ; nouveau code `endpoint_not_subscribed`.
Ajouté 6 septembre 2026 Avoirs : journal de cycle de vie (`lifecycle`) écrit à la création, à la finalisation, au dépôt et au remboursement, affiché sur la fiche ; libellés d'encaissement propres aux avoirs (« Non remboursé », « Remboursé ») ; les actions de dépôt sont masquées avec leur motif quand le document est adressé au SIREN de son émetteur ; le suivi du dépôt s'ouvre d'office sur un rejet.
Correctif 6 septembre 2026 Renvoi d'une facture rejetée par la plateforme : `send` ouvre une nouvelle tentative sous le même numéro. Les identifiants, le statut et le motif du dépôt rejeté sont conservés dans `einvoicing.previousSubmissions`, les identifiants courants et la clé de dédoublonnage repartent à zéro, la réponse de la plateforme à la nouvelle tentative est adoptée et le premier contrôle planifié. Un événement de cycle de vie qui désigne l'ancien dépôt, ou qui ne désigne aucune tentative et date d'avant le renvoi, n'est pas appliqué : le contrôle planifié et le sondage, qui lisent la plateforme par l'identifiant courant, établissent le verdict. Un statut d'encaissement (fr:212) encore en file suit la nouvelle tentative.
Ajouté 7 septembre 2026 Lecture des rejets : `einvoicing.rejectionCategory` (`buyer_not_in_directory`, `format_invalid`, `semantic_error`, `duplicate`, `platform_auth`, `platform_unavailable`, `refused_by_buyer`, `suspended`, `unknown`) sur les factures et les avoirs, aussi dans les tentatives closes. Les événements de facture et d'avoir portent `paErrorCode`, `rejectionReason` et `rejectionCategory` (renseignés sur `invoice.rejected`, `invoice.refused`, `credit_note.credit_refused`). L'e-mail, la notification et l'historique mènent avec cette lecture et la prochaine étape ; le motif brut reste en détail.
Modifié 7 septembre 2026 Annuaire consulté avant tout dépôt : un acheteur absent est rejeté localement (`paErrorCode` et `rejectionCategory` `buyer_not_in_directory`), sans appel de plateforme ; un annuaire injoignable ne bloque pas. Un statut fr:211 « Paiement transmis » émis par l'acheteur ne rétrograde plus une facture encaissée : le grand livre commande l'axe de paiement.
Ajouté 7 septembre 2026 Paiements : `fr212` (`state`, `sentAt`, `lastErrorCode`, `updatedAt`) dit où en est le statut « Encaissée » de chaque encaissement auprès de la plateforme. Un statut bloqué déclenche la notification `payment_status_blocked`.
Ajouté 17 octobre 2026 Décisions fiscales : champ `notices` sur toute décision — tableau de `{ code, message, reference?, lineId? }`, vide quand rien n'est à signaler — qui dit ce que la décision a retenu et ce que le vendeur peut faire ensuite, avec `detailCode` quand le code ne suffit pas (`threshold_exceeded`, `destination_option`, `multi_member_state_establishment` sur `destination_mechanism_missing`). `issues` garde son sens : pourquoi une décision n'est pas finale, et porte désormais `detailCode` quand le code ne suffit pas (`einvoicing_buyer_registration_required`, `tax_status_not_declared`, `legal_category_unresolved`, `french_vat_and_tgca_cumulation`). Les avis sont figés dans `taxSnapshot.notices` des factures et des avoirs (tableau vide sur un document antérieur). Nouvelle valeur `customer.natureBasis: declared_business_not_evidenced`. Ligne `integration` : `placeOfSupplyRule` facultatif ; absent, il vaut déclaration de la règle générale par le vendeur, qui en répond. Ajouts compatibles, date de contrat inchangée.
Modifié 17 octobre 2026 Décisions fiscales : Facturino ne suppose jamais un fait que le vendeur peut compléter, et n'applique une présomption légale que dans son champ. Un fait manquant laisse la décision en attente (`pending_verification`), avec un code existant et le remède ; un cas non modélisé est refusé clairement (`unsupported`), la source `integration` restant ouverte. Professionnel sans preuve : en attente, la seule présomption étant celle de l'art. 18 §2, 2e alinéa, du règlement 282/2011 pour ses services fournis par voie électronique quand il est établi dans le territoire de TVA de l'Union et n'a communiqué aucun numéro de TVA — traité comme non assujetti, avec un avis ; VIES injoignable et acheteur sans SIRET quand la facture électronique est due : en attente ; acheteur français ou monégasque avec SIRET et numéro de TVA incohérent : professionnel, numéro ignoré avec un avis ; particulier aux indices divergents localisé par l'art. 24 ter quand deux indices de natures différentes concordent sur un seul territoire — un indice national et un indice régional du même pays concordent — ou quand tous les territoires possibles mènent au même résultat fiscal, sinon la décision attend un indice de plus ; seuil UE non déclaré : en attente (`eu_threshold_state_missing`) ; seuil franchi sans guichet unique : TVA du pays du client, avec l'avis qui dit comment s'inscrire ; adresse UE sans code postal : refusée (`destination_regional_scope_undetermined`) quand ce code sépare des territoires de TVA ou une région à taux propre ; Monaco : TVA française ; territoires exclus de la TVA de l'Union : traités comme un pays tiers, l'impôt indirect du territoire que Facturino ne détient pas étant refusé sous la source `facturino` et signalé (`foreignTaxReviewRequired` et un avis) sous la source `integration` ; collectivités d'outre-mer et TAAF : hors champ de la TVA française, la taxe locale que Facturino ne détient pas étant refusée sous la source `facturino` et signalée sous la source `integration` ; biens expédiés dans un autre État membre à une personne morale non assujettie qui a communiqué un numéro de TVA : refusés sous la source `facturino`, les deux traitements possibles (livraison intracommunautaire ou vente à distance) admis sous la source `integration`. Sous la source `integration`, le lieu et la catégorie déclarés sont confrontés au moteur sur les mêmes faits : une contradiction répond `422 integration_vat_incoherent`, et là où le moteur ne conclut pas, la décision ne conclut pas davantage. Le mouvement des biens et la règle de lieu de chaque ligne entrent dans les empreintes des nouvelles demandes et opérations, sous les deux sources.
Ajouté 17 octobre 2026 Décisions fiscales : `customer.retainedVatNumber`, le numéro de TVA RETENU par la décision — seul porté par le document, son UBL, son CII, son Factur-X et l'e-reporting —, distinct de `customer.vatNumber`, le numéro déclaré conservé pour l'audit ; `null` quand le numéro est écarté (nouvel avis `detailCode: vat_number_ignored_national_registration` : la qualité professionnelle est établie par l'immatriculation nationale) ou que l'acheteur est traité comme non assujetti sans numéro qui l'identifie (une personne morale non assujettie identifiée à la TVA garde le sien). Registre du seuil UE : une vente retirée avant émission apparaît comme un mouvement `reservation_released` à montants négatifs. Nouveau code d'erreur `einvoicing_buyer_siren_missing`. Ajouts compatibles, date de contrat inchangée.
Modifié 17 octobre 2026 Décisions fiscales : quand les indices d'un particulier divergent, un candidat de l'UE est évalué sur l'état RÉEL du registre du seuil, lu avant la comparaison, l'opération elle-même incluse — sous le seuil, la TVA française d'origine ; franchi, aucune ; un registre non ouvert ne mène au même traitement que lui-même — et le candidat retenu est réservé sur l'état même où il a été évalué. Factures : à l'adossement d'une décision à un brouillon, l'instantané de l'acheteur est relu sur la fiche client (SIRET ou SIREN, numéro de TVA retenu, adresse, routage) ; une facture ou un avoir électronique dont l'acheteur ne porte pas de SIREN est refusé à la finalisation, `400 einvoicing_buyer_siren_missing`, avant numérotation. Application : un brouillon porte une seule décision vivante — réutilisée si la demande et l'identité de l'acheteur n'ont pas changé, sinon abandonnée (sa vente retirée du registre) avant d'en prendre une autre — et deux finalisations simultanées d'un même brouillon n'en laissent passer qu'une.
Correctif 18 octobre 2026 Décisions fiscales, vendeur en franchise en base (CGI art. 293 B) : aucune TVA facturée sur une opération située en Guadeloupe, en Martinique ou à La Réunion — catégorie `E`, `VATEX-FR-FRANCHISE`, mention 293 B —, sous les deux sources ; la TVA du département (8,5 % ou 2,1 %) était décidée pour une prestation à un professionnel ou un service en ligne à un particulier de ces départements. Les biens expédiés de métropole vers un département d'outre-mer, Guyane et Mayotte comprises, et les opérations d'un vendeur en franchise établi en Guadeloupe, en Martinique ou à La Réunion situées dans le champ de la TVA française sont réglés de même, au lieu d'une décision non finale (`inter_french_goods_regime_not_sourced`, `seller_territory_direction_not_sourced`). Source `integration` : seule la catégorie `E` est admise sur ces lignes. Une opération située en Guyane ou à Mayotte reste hors du champ de la TVA (`O`, CGI art. 294-1), vendeur en franchise ou non ; un vendeur établi en Guadeloupe, en Martinique ou à La Réunion qui y rend un service la reçoit aussi, au lieu d'une décision non finale. Date de contrat inchangée.
Correctif 18 octobre 2026 Décisions fiscales, particulier aux indices divergents : seules les lignes dont le lieu suit le client — services électroniques, de télécommunication et de radiodiffusion — comparent les lieux candidats. Une ligne à lieu fixe (bien, prestation générale) dont le taux n'est pas tabulé à son lieu n'écarte plus aucun candidat et ne rend pas la décision indécidable : un livre numérique vendu à un particulier domicilié au Maroc dont la banque est suisse reste situé au Maroc (hors champ, `O`), sous les deux sources — un livre papier retiré en Corse se décide et se facture sur son propre document, la catégorie `O` ne se mêlant pas à une autre (`vat_category_o_split_required`) ; avec une banque en métropole, les deux territoires mènent à deux traitements et la décision attend un indice de plus (`location_evidence_contradictory`). Date de contrat inchangée.
Modifié 18 octobre 2026 Décisions fiscales, facture mixte : les indices de localisation d'un particulier (règlement d'exécution (UE) 282/2011 art. 24 ter) ne situent plus que les lignes dont le lieu d'imposition suit le client — services électroniques, de télécommunication et de radiodiffusion. Sur la même facture, un bien garde le lieu de son transport et une prestation générale l'établissement du vendeur ; le registre du seuil ne compte que les lignes couvertes. Un appareil livré à Paris à un client dont les indices pointent le Maroc est taxé à 20 %, et non exporté. Nouveau motif `eu_destination_split_required` quand des biens livrés dans un État membre et un service situé dans un autre partageraient une facture. Ajout compatible, date de contrat inchangée.
Modifié 18 octobre 2026 Décisions fiscales, source `integration` : une demande ou une décision enregistrée avant la prise en compte de `goodsMovement` dans l'empreinte reste reconnue sous son empreinte d'origine — un rejeu avec la même `Idempotency-Key` et le même corps rejoue la décision, une reprise garde sa filiation ; une demande nouvelle distingue les mouvements de biens. Les lieux candidats d'un particulier sont évalués sur la bande de taux qu'identifie le taux fourni, comme sous la source `facturino` : un livre numérique à 2,1 % en Guadeloupe n'est plus confronté au taux normal de la Corse. Un taux qui n'identifie aucune bande française — taux nul d'une exportation, d'une opération hors champ ou située dans une collectivité d'outre-mer, taux d'un autre État membre — n'en reçoit aucune inventée : l'opération est lue une fois par bande publiée — normale, intermédiaire, réduite, hors l'intermédiaire quand la Guadeloupe, la Martinique ou La Réunion est en concurrence, faute de cette bande en droit (CGI art. 296) — et la demande n'est refusée que si la TVA fournie est incohérente sur toutes ces lectures, le refus disant alors le lieu tranché sous chacune. Les bandes super-réduite et particulière, publiées nulle part, ne sont jamais lues : la TVA française n'est jamais sous-collectée. Entre candidats, le résultat comparé est le résultat fiscal complet, taxe locale facturée comprise, sous les deux sources.
Modifié 18 octobre 2026 Décisions fiscales : les avis disent ce qui a été retenu, puis ce que le vendeur peut faire — le geste de preuve professionnelle selon le territoire du client, le territoire retenu, sa règle et les indices écartés, la démarche du guichet unique quand le délai du 10 est dépassé. Sur `location_evidence_contradictory`, `detailCode` nomme la règle : `concordant_evidence` ou `same_treatment`. Messages en anglais dans l'API, libellés français dans l'application. Ajout compatible, date de contrat inchangée.
Modifié 17 octobre 2026 Le refus `409 tax_decision_retake_required` de `POST /v1/invoices/{id}/finalize` vaut aussi pour une décision prise avant que Facturino n'enregistre sa position dans le registre du seuil UE : sa trace figée (`euB2cDestination`) en tient lieu, et sans position, toute vente retirée du registre après la date de la décision suffit. Ajout compatible, date de contrat inchangée.
Ajouté 17 octobre 2026 Nouveau code d'erreur `draft_finalization_in_progress` (409) : réponse de `DELETE /v1/invoices/{id}` et `POST /v1/invoices/{id}/cancel` pendant une finalisation en cours dans l'application, rien n'est supprimé. Ajout compatible, date de contrat inchangée.
Modifié 17 octobre 2026 `POST /v1/invoices/{id}/finalize` refuse de numéroter une facture dont la décision a été pesée sur le registre du seuil UE avant qu'une vente y soit retirée : 409 `tax_decision_retake_required`, aucun numéro brûlé, la facture reste un brouillon. Supprimez-la, redemandez une décision et recréez-la. Ajout compatible, date de contrat inchangée.
Modifié 17 octobre 2026 `DELETE /v1/invoices/{id}` et `POST /v1/invoices/{id}/cancel` retirent du registre du seuil UE la vente comptée pour le brouillon, dans la même transaction que la suppression ; un second appel répond 404 sans rien retirer deux fois. Une suppression pendant une finalisation en cours dans l'application répond 409. Ajout compatible, date de contrat inchangée.
Ajouté 17 octobre 2026 Nouveau code d'erreur `tax_decision_retake_required` (409) : une vente retirée du registre du seuil UE invalide les décisions en cours qui avaient été pesées sur elle — ni écrites ni comptées ; redemandez la décision sous une nouvelle `Idempotency-Key`, elle est pesée sur le total corrigé. Le registre reste ouvert. Ajout compatible, date de contrat inchangée.
Modifié 17 octobre 2026 Factures et avoirs électroniques : le SIREN de l'acheteur est lu sur l'identité du document, puis sur l'identifiant fiscal figé par la décision (`taxSnapshot.buyer.legalRegistrationId`), qui complète alors l'instantané du document émis — l'avoir d'une facture émise avant que son instantané porte le SIRET est donc émis avec le SIREN, sans réécrire la facture. S'il ne figure nulle part, `400 einvoicing_buyer_siren_missing` indique la correction qui change l'issue ; un avoir d'annulation totale relit l'acheteur, SIRET compris, sur la fiche client. `POST /v1/invoices/{id}/finalize` garde son chemin : il finalise la décision que l'intégrateur a adossée, sans la remplacer.
Modifié 6 septembre 2026 `POST /v1/credit-notes/:id/send` refuse aussi `self_invoicing_not_allowed` quand l'avoir est adressé au SIREN de son émetteur, avant tout changement d'état. Au renvoi d'une facture rejetée, un statut d'encaissement (fr:212) resté à rapprocher sur le dépôt rejeté repart en file et suit la nouvelle tentative.
Correctif 6 septembre 2026 Un statut d'encaissement rapporté par la plateforme (fr:212) n'efface plus un remboursement enregistré : une fois `refundedTotal` renseigné, `paymentStatus` suit le grand livre (`refunded` ou `partially_refunded`), le résumé reste `paid`.
Ajouté 5 septembre 2026 La fiche facture affiche le motif et le code de refus, ainsi que le CII corrigé préparé pour le dépôt, sans confondre sa préparation avec son acceptation. Les objets `einvoicing` et `files` sont décrits dans le schéma OpenAPI Invoice et la documentation ; le contrat conserve sa date. Le suivi e-reporting distingue les contrôles techniques (`acknowledged`), les déclarations non transmises (`skipped`), bloquées et à rapprocher. La reprise est proposée aux administrateurs uniquement.
Correctif 5 septembre 2026 Les faits de soumission reçus tardivement ne sont pas rattachés à un dépôt dont un identifiant connu désigne une autre soumission. Les identifiants manquants du même dépôt sont toujours complétés sans changement de position ni nouvel événement.
Correctif 5 septembre 2026 E-reporting FRR : les dates sont sérialisées sans tirets (`AAAAMMJJ`, G1.09) et la date-heure du rapport sur quatorze chiffres (`AAAAMMJJHHMMSS`, TT-3), conformément aux spécifications DGFiP v3.2. Le stockage et les dates de l’API conservent leur format ISO.
Ajouté 5 septembre 2026 E-reporting : les lignes unitaires portent le type du document source (`documentType`, `380` facture ou `381` avoir) et, pour un avoir, la référence de la facture corrigée (`originalInvoiceNumber`, `originalInvoiceDate`), figées à l'agrégation depuis la facture liée (BT-25/BT-26, G1.32). FRR : l'avoir est un bloc typé 381 à montants positifs qui nomme la facture corrigée (TG-11) ; Seqino : `preceding_invoice_reference` et `preceding_invoice_issue_date`. Un avoir sans cette référence, ou un flux international dont l'établissement déclarant n'a pas de numéro de TVA intracommunautaire (G2.33), est refusé avant tout appel à la plateforme, avec le champ à compléter. Champs facultatifs, déclarations antérieures inchangées.
Correctif 5 septembre 2026 La réponse immédiate au dépôt conserve ses identifiants de plateforme et sa date d'envoi même lorsqu'un statut reçu par webhook l'a devancée : la position atteinte est gardée, les identifiants absents sont rattachés dans la même transaction.
Correctif 5 septembre 2026 Dépôt d'une facture figée avant un correctif du générateur : si l'original ne satisfait plus une règle du CIUS-FR (BR-FR-08 par exemple), le dépôt envoie un CII régénéré depuis le document figé — même numéro, mêmes montants — enregistré sous `files.correctedXmlPath` et tracé dans le cycle de vie ; l'original Factur-X archivé n'est jamais réécrit. La régénération part de l'état d'émission (encaissement à l'émission, pas les encaissements postérieurs). Nouveau code `document_not_conformant`, renvoyé par `send` quand aucune régénération ne suffit, le document étant remis en `pending`.
Modifié 5 septembre 2026 E-reporting : les ventes B2C d'une journée sont déclarées par nature (biens `B1`, services `S1`), jamais en bloc mixte ; `status: accepted` signifie l'acceptation par l'administration, rapportée par la plateforme, et sort du suivi ; Seqino : acheteur identifié sur les factures internationales (TT-36, schémas 0223/0227), encaissements B2C déclarés par jour d'encaissement, reprise d'une transmission partielle par correction des enregistrements déjà créés, encaissements internationaux déclarés par facture et par jour d'encaissement. Le suivi des déclarations est monotone : un accusé technique reçu après l'acceptation de l'administration ne la remet jamais en cause ; les flux de cycle de vie des rapports sont lus dans leur CDAR, par fenêtres qui progressent.
Modifié 5 septembre 2026 E-reporting : les lignes conservent la catégorie de TVA décidée (`vatCategoryCode`), son motif d'exonération (`vatexCode`, nullable) et, pour les factures unitaires, la raison sociale figée de l'acheteur (`partnerName`). Ces champs restent facultatifs pour les déclarations antérieures. Les ventilations de même taux mais de catégorie ou de motif différents restent distinctes. FRR et Seqino identifient l'acheteur selon les règles TT-36/TT-37 : TVA intracommunautaire (0223) ou code pays suivi des seize premiers caractères de la raison sociale (0227). Une identité requise absente entraîne un refus avant tout appel à la plateforme.
Correctif 5 septembre 2026 La réponse immédiate au dépôt suit les mêmes écritures transactionnelles que les webhooks : une approbation déjà reçue ne recule pas vers `deposited`, et une acceptation tardive du fichier ne remplace pas un identifiant de plateforme déjà enregistré.
Correctif 5 septembre 2026 Factur-X : le CII porte désormais le cadre de facturation BT-23 (`B1`/`S1`/`M1` selon la nature de l'opération, `B2`/`S2`/`M2` pour une facture émise acquittée). Sans lui, une plateforme appliquant le CIUS-FR rejetait tout dépôt (règle BR-FR-08). La validation avant dépôt le contrôle.
Correctif 5 septembre 2026 Dépôt sur la Plateforme Agréée : `sending` est conservé tant que la plateforme n'a pas confirmé le dépôt ; `deposited` n'est plus présumé à l'acceptation du fichier. Un premier contrôle du statut a lieu une minute après l'envoi, puis toutes les quinze minutes ; la plateforme ne fait jamais reculer une facture le long de la chaîne de transmission. Une facture encaissée avant son dépôt garde `status: paid` une fois approuvée (`transmissionStatus: approved`) ; l'événement `invoice.approved` est émis même si `status` ne change pas. Les webhooks des plateformes et la récupération après incident suivent la même règle : aucun dépôt présumé, aucun recul sur la chaîne, motif de rejet complété dès qu'il est connu.
Ajouté 5 septembre 2026 Rejet ou refus par la plateforme : `einvoicing.rejectionReason` et `einvoicing.paErrorCode` portent le motif et le code de la plateforme ; l'e-mail et la notification le reprennent. Nouveau code `self_invoicing_not_allowed` sur `POST /v1/invoices/:id/send` quand le client porte le SIREN de l'émetteur.
Modifié 5 septembre 2026 E-reporting : l'accusé technique de la plateforme (contrôles antivirus, schéma, unicité) est distingué de l'acceptation par l'administration ; `status` reste `submitted` jusqu'à cette acceptation, `rejected` dès un refus, avec le motif. Seqino : déclarations transmises sur son API reporting native (transactions B2C par jour, factures internationales, encaissements) et suivies par ses événements de cycle de vie.
Modifié 4 septembre 2026 La copie PDF de présentation suit les encaissements : après un paiement, une annulation ou un remboursement, `GET /v1/invoices/:id/pdf` répond 202 avec un job de rendu au lieu de servir une copie périmée. L'original Factur-X est figé à l'émission et ne change jamais.

Comment être notifié des changements

Surveillez le header Facturino-Version renvoyé sur chaque réponse — il indique la version contractuelle utilisée pour traiter votre requête.
Surveillez le header Facturino-Version renvoyé par l'API et la page Versions de l'API : il n'existe pas d'évènement webhook de dépréciation. Toute dépréciation est annoncée dans le changelog et sur la page versioning, avec un préavis de 12 mois minimum.
Consultez régulièrement cette page : nous ne diffusons pas de notifications e-mail globales, mais chaque entrée du changelog liste précisément les endpoints et champs concernés.

Notre engagement

Préavis 12 mois minimum sur toute dépréciation.
Aucune suppression silencieuse : un champ ou endpoint déprécié reste fonctionnel jusqu'à sa date de retrait annoncée.
Aucun changement cassant sans nouvelle version contractuelle annoncée (voir Versioning).
Préservation du contrat : l'ajout d'un champ ou d'un endpoint n'est jamais un breaking change.