Facturation électronique : ce qui change dans une application métier

La réforme de la facturation électronique se discute surtout chez les éditeurs de plateformes et dans les cabinets comptables. Elle finit pourtant dans les logiciels de gestion, y compris ceux qui ont été développés sur mesure pour une entreprise et qui portent ses devis, ses commandes et ses factures depuis dix ans.

Cet article ne traite que de cette partie. Pour le calendrier, les obligations et les cas particuliers, la DGFiP publie un guide pratique de démarrage qui fait autorité et qui répond mieux que nous à ces questions. Les éléments réglementaires cités ici en viennent, dans sa version de juillet 2026.

Recevoir et émettre sont deux chantiers différents

Recevoir une facture fournisseur et émettre une facture client sont deux mouvements distincts, avec des échéances distinctes selon la taille de l'entreprise. Le calendrier est dans le guide.

Pour une application, la réception consiste à absorber un fichier qui arrive d'ailleurs. L'émission consiste à produire un fichier conforme et à le confier à un tiers. Le premier de ces deux chantiers arrive avant le second, et il coûte moins cher.

Une facture fournisseur cesse d'être un document

Aujourd'hui, une facture fournisseur arrive en PDF, quelqu'un la lit et la ressaisit, ou un outil de reconnaissance s'en charge avec le taux d'erreur qu'on lui connaît.

Dans le dispositif cible, elle arrive comme un fichier structuré déposé par une plateforme. Dans un fichier structuré, chaque montant, chaque date et chaque identifiant occupent un endroit désigné, que le logiciel lit directement sans avoir à deviner ce qu'il voit. Ce n'est pas une image de la facture.

Une saisie qui coûtait quelques minutes par facture peut donc devenir un import. C'est à peu près le seul endroit de la réforme où une petite structure gagne quelque chose, et ça vaut la peine de le prendre.

Le format exact dépend de la plateforme retenue, et seules les plateformes agréées par l'administration peuvent transmettre et recevoir. La liste officielle est publiée par la DGFiP en deux fichiers, celles qui ont passé les tests d'interopérabilité et celles qui les attendent encore.

La première question à poser à un opérateur, avant le prix : quels formats en réception, sous quelle forme les fichiers sont-ils mis à disposition, et par quel moyen l'application peut aller les chercher.

Ce qui bouge dans la structure de la base

Deux factures ne peuvent plus porter le même numéro. Le guide indique qu'une facture rejetée, corrigée puis réémise doit porter un nouveau numéro, pour éviter la confusion avec la facture rejetée et le rejet lié à la réutilisation du même numéro. Une application qui numérote avec un compteur simple s'en sort sans rien changer. Celle qui reconstruit un numéro à partir d'un client et d'une date, ou qui autorise la modification d'une facture déjà envoyée, finira par produire deux factures portant le même numéro.

Une facture a maintenant des états. Le guide distingue deux choses que l'usage confond volontiers. Le rejet par une plateforme relève de la transmission : format, donnée obligatoire absente, identification incorrecte, difficulté à trouver le destinataire. Le refus par l'acheteur est ce que le guide appelle un statut de cycle de vie, autrement dit une étape de la vie de la facture, motivée et encadrée par la norme, et elle ne se traite pas de la même façon.

La plupart des applications de gestion développées sur mesure connaissent deux ou trois états : brouillon, envoyée, payée. Il va falloir de la place pour davantage, et surtout pour la date de chaque changement d'état.

Le doublon devient une situation normale. Pendant la phase de démarrage, la même facture peut arriver par plusieurs canaux. Le guide demande alors de désigner une facture de référence, de poursuivre le traitement sur cette seule base, et de marquer les autres exemplaires comme copies, sans les refuser. Pour une application, ça suppose de pouvoir enregistrer qu'un document reçu est le double d'un autre sans créer une seconde facture. Beaucoup de bases n'ont pas cet endroit.

Ces trois points ont la même nature : c'est la structure de la base qui bouge, c'est-à-dire le plan des informations enregistrées, et non les écrans. C'est la partie qu'on ne rattrape pas facilement après coup, et c'est la raison pour laquelle il vaut mieux la regarder maintenant, quand rien ne presse.

Ce qui se fait maintenant, sans rien décider

Un inventaire, une demi-journée, qui ne dépend d'aucun choix de plateforme et qui restera valable quelle que soit la décision. La démarche est la même que celle d'un audit technique, appliquée à l'application au lieu du site.

• Par où entrent les factures fournisseurs aujourd'hui, par où sortent les factures clients, et qui manipule quoi entre les deux.
• Le SIRET des clients est-il stocké, à jour, et contrôlé à la saisie. Il sert désormais à diriger la facture vers la bonne plateforme, un peu comme une adresse postale, au lieu d'être une simple mention en pied de document.
• Le numéro de facture est-il unique, et ne peut-il plus être modifié une fois la facture émise.
• Existe-t-il un endroit pour un état et pour sa date.
• Que se passe-t-il aujourd'hui si deux documents décrivent la même facture.

Cet inventaire vaut aussi comme pièce à verser au dossier : le guide demande de pouvoir démontrer qu'une démarche est engagée, et un état des lieux daté en fait partie.

Ce qui peut attendre

Faire dialoguer l'application avec une plateforme avant de l'avoir choisie. Les moyens de raccordement diffèrent d'un opérateur à l'autre, celui qui servira à l'émission dépend de la plateforme retenue, et le calendrier laisse du temps aux petites structures. Un développement mené vers le mauvais interlocuteur est du travail perdu deux fois, à l'écriture et au remplacement.

L'ordre raisonnable est celui-ci : inventaire de l'existant, puis choix de la plateforme avec les bonnes questions techniques, puis développement.

La partie réglementaire est traitée par la DGFiP dans son guide pratique de démarrage, un PDF qui répond à vingt-neuf situations concrètes de réception, d'émission et d'incident. C'est la source à lire, et c'est elle qui fait autorité, pas cette page.

La partie applicative, celle qui commence quand un fichier structuré arrive dans une base qui ne l'attendait pas, se regarde application par application. Si vous avez une question sur la vôtre, écrivez-nous.

Article adossé au guide pratique de démarrage publié par la DGFiP, version de juillet 2026. Il décrit ce que la réforme implique pour une application de gestion, et ne qualifie aucune situation fiscale : les échéances applicables à une entreprise donnée relèvent du guide et de son expert-comptable.