---
canonical: https://validationfacture.fr/blog/rejets-ppf-pdp-1er-septembre-2026
title: "1ᵉʳ septembre 2026 : votre facture rejetée reviendra avec un code, pas avec un diagnostic"
description: "La réception obligatoire de la facture électronique arrive. Ce que les plateformes PPF et PDP vérifient réellement, pourquoi leurs codes de rejet sont laconiques, et comment transformer un code 210 en correction actionnable — avant l'émission plutôt qu'après le rejet."
date: "2026-08-23"
slug: "rejets-ppf-pdp-1er-septembre-2026"
---

À partir du **1ᵉʳ septembre 2026**, toutes les entreprises françaises
doivent être en mesure de **recevoir** des factures électroniques ; les
grandes entreprises et ETI commencent à **émettre**, et les PME suivront en
septembre 2027. Plus de sept millions d'entreprises sont concernées. Pour
la plupart, la découverte du système se fera par son côté le plus rugueux :
le rejet.

## Ce qu'un rejet dit — et surtout ce qu'il ne dit pas

Quand une plateforme (le portail public ou une Plateforme Agréée) refuse
une facture, elle la rejette **sur le format**, avec un code de statut du
cycle de vie et un message souvent laconique. Ce que le code ne dit
généralement pas : *quel champ* est en cause, *quelle valeur* était
attendue, *quelle correction* appliquer.

Pour un éditeur de logiciel, chaque rejet devient un ticket support. Pour
un cabinet comptable, un dossier bloqué. Pour la PME émettrice, un retard
de paiement — le comble pour une réforme pensée, entre autres, pour
raccourcir les délais de règlement.

## L'anatomie d'un rejet évitable

Les causes de rejet se rangent presque toujours dans l'une de ces familles,
que nous détaillons code par code dans notre [référentiel](/codes) :

- **Syntaxe** : le XML ne respecte pas le schéma officiel (élément
  manquant, mal placé, mal typé). Détectable à 100 % avant émission par
  une validation XSD.
- **Cohérence arithmétique** : les règles BR-CO de la norme — la plus
  célèbre étant [BR-CO-15](/codes/br-co-15) : le total TTC doit être
  exactement la somme du HT et de la TVA. Les erreurs d'arrondi entre
  systèmes en font un champion des rejets.
- **TVA** : catégorie, taux et décomposition incohérents — autoliquidation
  sans mention, exonération sans motif ([BR-AE-10](/codes/br-ae-10))…
- **Identités** : SIREN/SIRET invalides, numéro de TVA intracommunautaire
  dont la clé ne correspond pas au SIREN.
- **Mentions françaises** : les obligations du droit local que la norme
  européenne ne porte pas.

Aucune de ces familles ne nécessite d'attendre le verdict de la
plateforme : **tout est contrôlable avant l'émission**, contre les mêmes
artefacts officiels que ceux qu'utilisent les plateformes — c'est
exactement [notre architecture en cinq couches](/blog/valider-facture-electronique-artefacts-officiels).

## Du code au correctif

Le deuxième problème est le chemin inverse : vous avez déjà le rejet, avec
son code. Notre opération `explain_rejection` prend un code de rejet — et,
si vous le fournissez, votre document — et renvoie le champ en cause, la
valeur constatée, la valeur attendue et la correction. Les
[fiches de rejet](/rejets) publient la même connaissance en libre accès,
code par code.

## Les huit jours qui viennent

Si vous émettez ou intégrez des factures, la checklist minimale avant le
1ᵉʳ septembre tient en trois lignes : vérifier que vos documents passent
la syntaxe officielle, la cohérence arithmétique et les mentions
françaises. Le [scanner d'essai](/essai) le fait gratuitement sur vos
propres fichiers — JSON, XML CII, UBL ou PDF Factur-X — et l'[API](/docs)
industrialise le même contrôle dans votre flux d'émission, avec
[preuve signée](/blog/journal-de-preuves-chaine) à chaque appel.

Le rejet le moins cher restera toujours celui qui n'a pas eu lieu.