Facturation électronique 2026 pour un SaaS B2B

Ce qui change, et pour qui

La réforme de la facturation électronique B2B n'est plus une échéance lointaine : la première vague est déjà en vigueur.

D'après le calendrier officiel (economie.gouv.fr, impots.gouv.fr) :

• 1er septembre 2026 : toutes les entreprises assujetties à la TVA, quelle que soit leur taille, doivent être en mesure de recevoir des factures électroniques. Les grandes entreprises et les ETI doivent en plus émettre leurs factures au format électronique et transmettre leurs données de transaction et de paiement à l'administration (e-reporting).
• 1er septembre 2027 : les PME, TPE et micro-entreprises ont un an de délai supplémentaire, puis basculent à leur tour sur l'obligation d'émission et l'e-reporting.

Si vous éditez un SaaS B2B français, vos clients sont concernés dès aujourd'hui côté réception, et le seront tous côté émission d'ici 2027. Ce n'est pas un sujet à traiter après le lancement.

Le vocabulaire, sans jargon

• PDP (Plateforme de Dématérialisation Partenaire) : un opérateur privé agréé par l'administration fiscale pour émettre, recevoir et transmettre les factures électroniques et les données d'e-reporting à sa place. C'est le rôle que joue iopole dans le code de HeartCo.
• Annuaire : le répertoire central qui associe chaque SIRET à la ou les PDP par lesquelles il est joignable, pour router une facture vers le bon destinataire sans configuration manuelle.
• e-reporting : la transmission à l'administration des données que la facture électronique ne couvre pas d'elle-même : ventes B2C, transactions internationales, encaissements. Ça concerne la quasi-totalité des SaaS qui vendent aussi en dehors du B2B franco-français.
• Factur-X : le format hybride franco-allemand qui embarque un fichier XML structuré (la donnée) dans un PDF lisible par un humain (la facture que vous connaissez). C'est le format que la réforme attend en pratique pour la majorité des flux B2B.
• Réseau Peppol : le réseau d'échange interopérable entre PDP, utilisé pour le routage international et de plus en plus pour le B2B domestique.

Ce qu'un SaaS doit émettre et recevoir

Concrètement, une facture Factur-X n'est pas un PDF avec des métadonnées en plus. C'est un document normé qui doit satisfaire des règles de cohérence vérifiables. Le profil le plus répandu, Basic, suit le modèle sémantique européen EN 16931 et impose entre autres :

• le total TVA égal à la somme des lignes de taxe (règle BR-CO-10, tolérance 0,01 €),
• le total TTC égal au total HT plus le total TVA (BR-CO-13),
• un SIRET vendeur valide (14 chiffres, clé de Luhn sur le SIREN),
• un numéro de TVA intracommunautaire au bon format,
• des dates au format calendaire AAAAMMJJ.

Le piège le plus fréquent : arrondir chaque ligne séparément avant de sommer, au lieu de sommer puis arrondir. L'écart d'un centime qui en résulte suffit à faire échouer la validation chez le destinataire, et c'est le genre de bug qui ne se voit qu'en production, sur une vraie facture avec des montants qui ne tombent pas rond.

Générer un Factur-X : PDF/A-3 et XML CII

Un Factur-X est un PDF au format PDF/A-3 (le sous-format qui autorise les pièces jointes embarquées) contenant un fichier XML suivant la syntaxe CII (Cross Industry Invoice) de l'UN/CEFACT. Le pipeline typique :

// Schéma simplifié : mapper vos données de facture, générer le XML, l'embarquer dans le PDF
const invoice = {
  profile: "BASIC",
  invoiceNumber: "FAC-2026-0001",
  issueDate: "20260922",
  seller: {
    name: "Votre société",
    siret: "73282932000074",
    vatNumber: "FR73282932000",
  },
  buyer: {
    name: "Client SCI",
    address: { postalCode: "92100", city: "Boulogne", countryCode: "FR" },
  },
  taxLines: [
    {
      categoryCode: "S",
      ratePercent: 20,
      basisAmount: 1000,
      calculatedAmount: 200,
    },
  ],
  totalHT: 1000,
  totalTVA: 200,
  totalTTC: 1200,
};
 
// existingPdfBytes : le PDF de facture que vous générez déjà
const { pdfBytes, validation } = await generateFacturX(
  invoice,
  existingPdfBytes,
);
 
if (!validation.isValid) {
  // validation.errors : liste des règles bloquantes en échec (BR-CO-*, format SIRET, etc.)
}

Dans HeartCo, ce pipeline (mapper Prisma vers les données Factur-X, générer le XML, l'embarquer dans le PDF, valider) est un module dédié avec ses propres tests unitaires sur chaque règle de validation, plutôt qu'une fonction unique difficile à faire évoluer.

Se raccorder à une plateforme agréée

Générer un Factur-X valide ne suffit pas : la réforme veut que le document passe par un opérateur agréé, pas par email ou par upload manuel. C'est le rôle d'une intégration PDP :

• Émission : envoyer la facture générée vers la PDP, qui la route jusqu'au destinataire (via l'annuaire, potentiellement par le réseau Peppol).
• Réception : recevoir un webhook quand une facture arrive, en extraire les données, et les rattacher automatiquement à la bonne organisation cliente.
• Cycle de vie : une facture transmise n'est pas un événement unique, c'est une machine à états (déposée, transmise, acceptée, rejetée, litigée...) qu'il faut synchroniser dans le temps, pas seulement au moment de l'envoi.
• e-reporting : déclarer séparément les transactions B2C et internationales, sur une base périodique.

C'est exactement ce que couvre l'intégration iopole du produit HeartCo : un client HTTP avec retry et authentification, un gestionnaire de webhooks qui vérifie la signature HMAC, et des tâches planifiées qui resynchronisent les statuts sans intervention manuelle. Le module Factur-X (génération, validation) et l'intégration iopole (transmission, cycle de vie) sont deux couches séparées : la première fabrique un document valide, la seconde le fait circuler légalement.

Tester avant de faire confiance

Une facture qui échoue silencieusement chez le destinataire coûte cher en support. Les règles de validation citées plus haut ne servent à rien si elles ne sont pas exécutées automatiquement à chaque changement de code :

// Exemple de test de règle métier
it("rejette une facture dont le total TTC ne correspond pas à HT + TVA", () => {
  const invoice = buildInvoice({
    totalHT: 1000,
    totalTVA: 200,
    totalTTC: 1150,
  });
  const result = validateFacturX(invoice);
  expect(result.isValid).toBe(false);
  expect(result.errors).toContainEqual(
    expect.objectContaining({ code: "BR-CO-13" }),
  );
});

Un aller-retour complet (générer un XML, le réinjecter, vérifier qu'on retombe sur les mêmes données) attrape les régressions qu'un test isolé sur la génération seule ne voit jamais.

Ce qui reste à votre charge

Un module de génération et une intégration PDP ne rendent pas votre SaaS conforme tout seuls. Restent, côté produit :

• Le compte PDP en votre nom (ou celui de votre client), avec son propre KYB
• Le choix du profil Factur-X adapté à vos flux (Basic couvre la majorité des cas B2B simples)
• Les mentions obligatoires sur la facture elle-même, qui évoluent avec la réforme
• La déclaration e-reporting effective si vous vendez aussi en B2C ou à l'international
• La conservation légale des factures émises et reçues

Et un point de méthode : la réforme évolue, les obligations exactes dépendent de votre situation, et cet article n'est pas un conseil juridique. Pour les cas limites, un expert-comptable ou un DPO reste la bonne ressource. Notre checklist conformité gratuite couvre le RGPD à côté de la facturation, pour une vue d'ensemble avant de lancer.

Pour aller plus loin

• Intégrer Stripe dans un SaaS français : TVA, factures, webhooks
• RGPD pour SaaS B2B français, checklist complète sans mythes
• Documentation : paiements
• La sécurité chez HeartCo