VERI*FACTU et logiciels de facturation sur mesure : ce que l'Espagne exige au 1er janvier 2027

Avant le 1er janvier 2027, toute société établie en Espagne qui dépose une déclaration d'impôt sur les sociétés (Impuesto sobre Sociedades) et facture à l'aide d'un logiciel doit utiliser un logiciel adapté au Real Decreto 1007/2023. Chaque facture reçoit un enregistrement haché, chaîné au précédent, et un QR code que le client peut vérifier auprès de l'administration fiscale. Tous les autres assujettis concernés, surtout les travailleurs indépendants, ont jusqu'au 1er juillet 2027.

Si vos factures sortent d'un progiciel du commerce, c'est en grande partie l'affaire de votre éditeur. Si elles sortent d'un logiciel écrit pour vous, ou par votre propre équipe, c'est la vôtre. Vous modifiez le code, et c'est vous qui signez la déclaration attestant sa conformité.

Les dates, et les deux reports

C'est le troisième calendrier, un certain scepticisme est donc légitime.

• Le Real Decreto 1007/2023 laissait à l'origine aux entreprises jusqu'au 1er juillet 2025.
• Le Real Decreto 254/2025, du 1er avril 2025, a repoussé cette date au 1er janvier 2026 pour les sociétés soumises à l'impôt sur les sociétés et au 1er juillet 2026 pour les autres. La raison était concrète : l'arrêté technique, l'Orden HAC/1177/2024, n'avait été publié que le 28 octobre 2024.
• Le Real Decreto-ley 15/2025, du 2 décembre 2025, a décalé les deux dates d'un an. Son texte figure au BOE, et le Congrès l'a validé le même mois.

La note de l'AEAT sur la prolongation, mise à jour le 26 mars 2026, ne laisse aucune ambiguïté : « las entidades que presenten el Impuesto sobre Sociedades deberán tener adaptados sus SIF antes del 1 de enero de 2027. El resto de obligados tributarios, antes del 1 de julio de 2027. »

Cela peut-il encore bouger ? Rien d'officiel ne l'indique en octobre 2026. Le premier report avait une cause technique qui n'existe plus. Les services de transmission de l'AEAT sont en production depuis le 23 avril 2025, et depuis le 29 juillet 2025 les éditeurs ne peuvent plus proposer que des systèmes adaptés. Miser sur un troisième report est un pari, pas un plan.

Quelle date est la vôtre ? Une SL ou une SA dépose l'Impuesto sobre Sociedades : une société qui fait tourner son propre ERP est donc presque à coup sûr soumise à la date du 1er janvier 2027. C'est dans moins de trois mois. La date de juillet concerne les indépendants et les autres contribuables visés.

Qui est concerné, et qui ne l'est pas

La FAQ de l'AEAT sur le champ d'application le ramène à quatre négations. Vous êtes concerné si vous ne facturez pas exclusivement à la main, si vous n'êtes pas au SII (à titre obligatoire ou par option), si votre domicile fiscal n'est ni au Pays basque ni en Navarre, et si vous ne bénéficiez d'aucune décision d'exemption.

Les exclusions, en pratique :

• Les entreprises au SII. Le Suministro Inmediato de Información est obligatoire pour les sociétés dont le chiffre d'affaires dépasse 6 millions d'euros, les groupes TVA et les entreprises inscrites au registre de remboursement mensuel de TVA (REDEME), et d'autres peuvent y adhérer volontairement. L'AEAT le dit sans détour : « El ámbito subjetivo de ambos proyectos es excluyente. » Si vous passez au SII, vous cessez d'envoyer des enregistrements VERI*FACTU et d'imprimer le QR code.
• Le Pays basque et la Navarre. Les entreprises qui y ont leur domicile fiscal relèvent des administrations fiscales forales et de leurs propres règles, pas du RD 1007/2023.
• La facturation purement manuelle. Un carnet de factures papier est hors champ. Un tableur servant uniquement à saisir, imprimer et conserver les factures l'est aussi ; un tableur qui produit également vos registres de TVA ne l'est pas.

Les sociétés étrangères sont concernées dès lors qu'elles ont un établissement stable en Espagne.

Si vous facturez avec un progiciel du commerce (A3, Sage, Holded et équivalents), l'éditeur est le producteur et doit livrer une version adaptée accompagnée de sa propre déclaration. Mettez à jour, vérifiez que la déclaration est bien là, et vous pouvez arrêter votre lecture ici.

Cet article est pour les autres : un ERP sur mesure, un programme Access, Delphi ou FileMaker écrit il y a quinze ans, ou un module de facturation intégré à votre propre plateforme web.

Votre société est le producteur

L'article 13.1 du règlement fait peser la certification sur celui qui produit le système, au moyen d'une declaración responsable (déclaration sur l'honneur). La FAQ de l'AEAT sur la certification répond directement au cas du développement interne : « Cada sistema en operación debe disponer de una Certificación emitida mediante declaración responsable de su productor (artículo 13.1 RRSIF). Si el software hubiera sido desarrollado por la propia empresa, será esta la que deba certificarlo. »

Ce que cela signifie en pratique :

• Il n'y a pas d'audit externe. L'AEAT parle d'une « auto-certificación » du producteur. Personne n'approuve votre système à l'avance. Vous signez, et vous en répondez.
• Un prestataire qui développe pour vous une extension commercialisée comme produit certifie cette extension. Si vous l'avez développée vous-même, c'est vous qui la certifiez.
• La déclaration doit être visible dans le système, dans chaque version, et accessible aussi en dehors de lui, indépendamment du produit.
• Son contenu est fixé par l'article 15 de l'Orden HAC/1177/2024 : entre autres, le nom, l'identifiant et la version du système, ses composants, le fait qu'il fonctionne ou non uniquement en mode VERI*FACTU, le nom, le NIF et l'adresse du producteur, ainsi que la date et le lieu de signature.

Le cas délicat est celui du programme dont l'auteur est parti depuis des années. Quelqu'un doit malgré tout produire la version adaptée et signer pour elle. Décidez qui, par écrit, avant le début des travaux.

La personnalisation d'un produit commercial certifié n'exige une déclaration distincte que si la modification touche à la manière dont les exigences du règlement sont mises en œuvre. Une modification faite hors du contrôle du producteur et susceptible de les altérer n'est pas conforme.

Les enjeux sont fixés par l'article 201 bis de la loi générale fiscale : une amende fixe de 150 000 € par exercice et par type de système pour la production de systèmes non conformes aux exigences, et de 50 000 € par exercice pour la détention d'un système qui devrait être certifié et ne l'est pas, ou qui a été altéré. Laquelle de ces amendes viserait un système développé en interne est une question pour votre conseiller fiscal. Aucun des deux montants n'est anodin.

Ce que le logiciel doit faire

Un enregistrement par facture, au moment de l'émission

L'article 9.1 exige que le système génère un registro de facturación de alta « de forma simultánea o inmediatamente anterior a la expedición de cada factura ». Une facture annulée reçoit un enregistrement d'annulation (registro de anulación).

L'article 10 énumère le contenu de l'enregistrement : NIF et nom de l'émetteur, le destinataire lorsqu'il est requis, la série et le numéro, les dates d'émission et d'opération, le type de facture, les références de toute facture rectifiée, une description, le total, le régime de TVA, la base imposable, les taux et montants, les motifs d'exonération ou de non-assujettissement, l'identité du système et de son producteur, et un horodatage à la seconde.

Dans les systèmes anciens, c'est là que le travail se cache :

• Les ventilations de TVA sont souvent calculées à l'impression et jamais stockées. Elles doivent exister sous forme de données au moment de l'émission.
• « Émettre » consiste souvent à imprimer un état. Il doit exister un point explicite où un brouillon devient une facture, et c'est à ce moment que l'enregistrement est créé.
• La réutilisation des numéros, c'est fini. Supprimer une facture et réutiliser son numéro, une habitude dans bien des petits systèmes, échoue désormais : l'AEAT rejette le second enregistrement avec « Registro de facturación duplicado. » Les factures de test émises en production sont de vraies factures et doivent être annulées.
• Personne ne modifie les enregistrements. La FAQ de l'AEAT précise que la modification directe de la base des enregistrements émis ne doit pas être une opération permise. Si votre personnel corrige aujourd'hui des factures en SQL, cela s'arrête. Les corrections passent par des factures rectificatives.

La chaîne de hachage

Chaque enregistrement porte la série, le numéro et la date de l'enregistrement précédent, ainsi qu'une partie de son empreinte (huella). L'algorithme est SHA-256, et les champs exacts et leur concaténation figurent dans la documentation technique de l'AEAT, avec les dessins d'enregistrement, les schémas XSD, le WSDL et le catalogue des validations et des erreurs.

Avant de générer un nouvel enregistrement, le système doit vérifier que le dernier est correctement chaîné et que son horodatage ne dépasse pas l'heure actuelle de plus d'une minute. Les enregistrements sont générés dans l'ordre d'émission des factures.

Cela a une conséquence d'architecture. Chaque installation a besoin d'un point unique et sérialisé où les enregistrements sont créés. Deux serveurs web qui ajoutent des maillons à la même chaîne sans se coordonner la casseront. L'AEAT accepte des montages mixtes, par exemple des terminaux de point de vente qui reçoivent l'enregistrement d'un back-office central, mais la chaîne elle-même vit à un seul endroit.

Chaque système est identifié par le NIF du contribuable, un identifiant de système à deux caractères et un numéro d'installation qui ne doit jamais se répéter, même lorsque le même logiciel est réinstallé sur la même machine.

Le QR code sur la facture

Chaque facture porte un QR code conforme à l'ISO/IEC 18004, d'une taille comprise entre 30 x 30 et 40 x 40 mm, avec un niveau de correction d'erreur M. Il encode une URL contenant le NIF de l'émetteur, la série et le numéro, la date d'émission et le total, que le client peut vérifier auprès de l'AEAT. En mode VERI*FACTU, la facture porte en outre la mention « VERI*FACTU » ou « Factura verificable en la sede electrónica de la AEAT ».

Pour un logiciel ancien, cela signifie retravailler le modèle de facture (un état Access, une mise en page FileMaker, un générateur de PDF) et ajouter une bibliothèque QR à une pile technique qui n'en a jamais eu.

Deux modes : VERI*FACTU ou non

Mode VERI*FACTU. Le système envoie automatiquement chaque enregistrement à l'AEAT, au fur et à mesure de sa génération. En contrepartie, les enregistrements ont besoin d'une empreinte mais pas de signature électronique, l'AEAT les conserve, et un système qui ne fonctionne qu'en ce mode n'a pas besoin de journal d'événements. Il vous faut un client SOAP pour les services publiés par l'AEAT, un certificat électronique qualifié, et une file d'attente pour les coupures de connexion. La FAQ développeurs de l'AEAT traite une panne comme un incident : les enregistrements attendent dans la file et sont renvoyés, et la facturation continue.

Mode non VERI*FACTU. Les enregistrements restent chez vous, et chacun doit être signé (XAdES Enveloped, ETSI EN 319 132) avec un certificat qualifié. Le système doit aussi tenir un journal d'événements signé couvrant le démarrage et l'arrêt dans ce mode, les contrôles d'anomalies et leurs résultats, les restaurations de sauvegarde et les exportations, avec un événement récapitulatif au moins toutes les six heures de fonctionnement, et il doit remettre les enregistrements quand l'AEAT les demande.

Pour un système sur mesure, le mode VERI*FACTU seul est généralement le chantier le plus léger. Pas d'infrastructure de signature, pas de journal d'événements, pas d'outillage de détection d'anomalies. Un système qui propose les deux modes doit tout implémenter.

Un plan qui tient avant le 1er janvier 2027

Début octobre, une société soumise à l'impôt sur les sociétés dispose d'environ treize semaines. Voici l'ordre qui fonctionne.

1. Semaine 1 : inventaire. Recensez tous les systèmes qui émettent des factures : l'ERP, le module de facturation de la boutique en ligne, le script d'abonnements, le terminal de comptoir. Vérifiez que vous n'êtes ni au SII ni sous régime foral.
2. Semaines 1 et 2 : décider qui signe et quel mode. Désignez le producteur de chaque système. Choisissez le mode VERI*FACTU seul, sauf raison contraire. Assurez-vous que le certificat qualifié de la société existe et qu'une personne en est responsable, car la FAQ développeurs de l'AEAT note que le système ne peut pas fonctionner sans.
3. Semaines 2 à 4 : analyse des écarts de données. Comparez ce que votre système stocke avec l'article 10 et le dessin d'enregistrement de l'AEAT. Les ventilations de TVA manquantes, les codes de type de facture et les références de rectification apparaissent à ce stade.
4. Semaines 3 à 8 : développement. Génération de l'enregistrement à l'émission, la chaîne et ses contrôles, un stockage inaltérable, l'annulation, le QR code sur chaque modèle, et le client de transmission avec sa file de renvoi. Supprimez les modifications directes des enregistrements émis.
5. Semaines 6 à 10 : tests. Commencez dans l'environnement de test de l'AEAT, puis envoyez de vrais enregistrements. L'AEAT considère la période précédant votre échéance comme une période de test, pendant laquelle vous pouvez interrompre l'envoi et revenir à un autre système. Lisez la FAQ développeurs avant d'écrire les flux d'annulation et de rectification : elle couvre la plupart des cas limites.
6. Semaines 9 à 12 : déclaration et formation. Rédigez la declaración responsable, affichez-la dans l'application et en dehors, et consignez la version. Expliquez au service financier que les numéros ne sont jamais réutilisés et que les erreurs se corrigent par des factures rectificatives.
7. Mi-décembre : mise en production. Une échéance libellée « antes del 1 de enero » n'est pas une date de démarrage. Démarrez quinze jours plus tôt, pour que les premiers problèmes apparaissent pendant qu'il reste du temps.

Pour l'échéance du 1er juillet 2027, le même plan s'applique avec plus de marge. Commencez en janvier, pas en mai.

Deux alternatives à la refonte méritent d'être pesées honnêtement. L'AEAT accepte les architectures mixtes : votre ERP peut continuer à préparer les données de facture pendant qu'un composant séparé, acheté ou développé, génère les enregistrements, le QR code et la transmission, à condition que les déclarations couvrent la façon dont les éléments s'articulent. Et si le vieux programme émet une poignée de factures par mois, l'application de facturation gratuite de l'AEAT pour les petites entreprises, ou un progiciel standard, peut coûter moins cher que son adaptation.

Où trouver de l'aide

Nous modifions le code de facturation que les entreprises font déjà tourner, y compris sur des piles anciennes : génération des enregistrements, chaîne de hachage, QR code sur vos modèles et client de transmission vers l'AEAT, avec des tests que nous vous laissons. Notre service d'intégration de la facturation électronique couvre le développement, et la maintenance de systèmes anciens est le point de départ quand plus personne ne sait comment fonctionne le vieux programme.

Si vous avez une échéance au 1er janvier 2027 et un système sur mesure, écrivez à office@c9group.dev. Nous sommes ingénieurs, pas conseillers fiscaux : les questions de périmètre et de responsabilité relèvent du vôtre, et nous construisons selon sa réponse.