Mise à jour du 6 octobre 2026. Ce qui a désormais une date ferme, c'est la facturation électronique obligatoire entre entreprises : l'arrêté HAC/1028/2026, en vigueur depuis le 6 octobre 2026, a lancé les délais du décret royal 238/2026 (douze mois pour les entreprises dont le volume d'opérations dépasse 8 millions d'euros et vingt-quatre pour les autres, soit octobre 2027 et octobre 2028 selon notre calcul). Le ministère espagnol des Finances a annoncé le report de VeriFactu à octobre 2028 afin qu'il converge avec la facturation électronique, mais ce changement n'est pas encore publié au BOE (Journal officiel espagnol) : d'ici là, les dates du décret-loi royal 15/2025 restent en vigueur (1er janvier 2027 pour les contribuables soumis à l'impôt sur les sociétés et 1er juillet 2027 pour les autres). Nous mettrons cette page à jour dès la publication du texte.
Adapter votre logiciel de facturation n'est pas quelque chose que l'on active à la dernière minute. Cela implique de confirmer le périmètre, de mettre à jour ou de remplacer le logiciel, de revoir les données et les séries, de générer des registres avec intégrité et traçabilité, de tester les corrections, de former le personnel et de préparer des plans de contingence. Suite à la prorogation approuvée en décembre 2025, les contribuables de l'impôt sur les sociétés doivent avoir leurs systèmes adaptés avant le 1er janvier 2027 ; toutes les autres parties couvertes par la réglementation, avant le 1er juillet 2027.
Ce qui change en 2027, et ce qu'il ne faut pas confondre
Le décret royal 1007/2023 a approuvé le règlement établissant les exigences applicables aux systèmes et logiciels qui prennent en charge les processus de facturation. L'arrêté HAC/1177/2024 en a précisé le détail technique et fonctionnel. Le décret-loi royal 15/2025 a ensuite prorogé les délais d'adaptation jusqu'en 2027.
Dans le langage courant des entreprises, « Verifactu » est utilisé comme raccourci pour désigner l'ensemble du changement, mais il est utile de séparer les concepts :
- Le RRSIF (le règlement SIF, Reglamento de los Sistemas Informáticos de Facturación) établit les exigences que doivent respecter les systèmes informatiques de facturation entrant dans son périmètre.
- VERI*FACTU est le mode qui transmet les registres de facturation au bureau électronique de l'Agence fiscale espagnole (AEAT) selon les modalités techniques établies.
- Un système non-VERI*FACTU doit lui aussi respecter les exigences qui lui sont applicables et conserver des registres et des contrôles supplémentaires.
- La facturation électronique B2B relève d'un cadre et de flux différents. Elle partage des données et des intégrations, mais elle n'est pas synonyme de VERI*FACTU.
La première décision n'est donc pas « quel fournisseur acheter », mais quelles entités, activités, établissements, séries et applications entrent dans le périmètre, et quel mode de fonctionnement sera utilisé.
Calendrier officiel et comment le lire
Suite à la modification de 2025, l'Agence fiscale espagnole (AEAT) établit :
| Groupe | Délai d'adaptation |
|---|---|
| Entités assujetties à l'impôt sur les sociétés | Avant le 1er janvier 2027 |
| Toutes les autres parties couvertes | Avant le 1er juillet 2027 |
La période précédant ces dates peut être utilisée pour les tests. Elle ne doit pas être lue comme une autorisation à reporter le projet. Une organisation avec plusieurs points de vente, des intégrations ou des processus de clôture complexes doit réserver du temps pour corriger les défauts sans mettre la facturation en danger.
Les dates et le périmètre doivent être vérifiés à nouveau avant de publier ou d'exécuter le plan, car des changements réglementaires, des particularités territoriales ou des situations exclues peuvent exister. Les entreprises soumises au régime de Suministro Inmediato de Información (SII) et celles opérant sous des systèmes régionaux (foraux) comme TicketBAI doivent analyser leur situation spécifique. Il n'est pas prudent d'extrapoler une réponse générale.
Étape 1. Faire l'état des lieux de la manière dont la facturation se déroule réellement
L'inventaire doit couvrir plus que le programme principal. De nombreuses entreprises facturent aussi depuis des plateformes e-commerce, des terminaux de point de vente, des feuilles de calcul, des applications verticales, des ERP secondaires ou des processus manuels.
Pour chaque flux, enregistrer :
- l'entité et le numéro d'identification fiscale (NIF) qui émet la facture ;
- l'activité, l'établissement et la série de facturation ;
- l'application et sa version ;
- le fournisseur et le responsable interne ;
- l'origine de la commande ou du service ;
- les règles fiscales et les remises ;
- les factures ordinaires, simplifiées et rectificatives ;
- les copies, doublons et avoirs ;
- l'intégration comptable et bancaire ;
- les pics de volume et les périodes critiques ;
- le mode de contingence actuel.
L'inventaire doit repérer la « facturation fantôme » : modèles bureautiques, reçus retapés ou documents émis en dehors du système. S'ils subsistent, le projet peut sembler terminé alors qu'un canal résiduel reste non conforme.
Étape 2. Confirmer le périmètre avec un conseil fiscal
L'entreprise doit documenter qui est assujetti, quelles transactions sont couvertes et quelles exceptions s'appliquent. Cette décision ne doit pas reposer uniquement sur le fournisseur du logiciel.
Un dossier de périmètre utile comprend :
- les entités et établissements analysés ;
- les réglementations et critères appliqués ;
- les applications concernées ;
- les flux exclus et leur justification ;
- le mode choisi pour chaque système ;
- la validation fiscale et la date de révision.
Il faut aussi définir la relation avec le SII, les régimes régionaux (foraux), la facturation par le destinataire ou par un tiers, l'autofacturation et les systèmes étrangers. Quand un groupe partage une plateforme, le périmètre se décide par entité et par flux, pas par installation.
Étape 3. Exiger des preuves du fournisseur
Une allégation commerciale de « compatible Verifactu » ne suffit pas. Le fournisseur doit identifier le produit, la version et la configuration ; fournir la déclaration de responsabilité exigée par la réglementation ; expliquer le mode ; et documenter les exigences techniques, les mises à jour, le support et la conservation.
Questions essentielles :
- Quelle version précise est conforme, et à partir de quelle date ?
- Comment génère-t-il, enchaîne-t-il et conserve-t-il les registres ?
- Comment gère-t-il les corrections et les annulations ?
- Que se passe-t-il en cas de panne de la connexion ou de l'AEAT ?
- Comment les clés et les certificats sont-ils protégés ?
- Quels champs les utilisateurs doivent-ils remplir ?
- Comment le code QR et les mentions de la facture sont-ils mis à jour ?
- Quel export permet-il pour les audits ou la migration ?
- Quelles preuves subsistent des événements et des changements ?
- Quel SLA propose-t-il pendant les périodes de clôture et les échéances ?
Il n'existe pas d'« homologation individuelle » qui permette à un logo commercial de se substituer à la diligence propre de l'entreprise. La déclaration de responsabilité doit être conservée, et il faut vérifier que la version déployée correspond à la version déclarée.
Exigences fonctionnelles à tester
La réglementation vise à garantir l'intégrité, la conservation, l'accessibilité, la lisibilité, la traçabilité et l'inaltérabilité des registres. Les spécifications définissent la structure, l'enchaînement, les empreintes, les événements, les codes QR et la transmission.
Les tests doivent parcourir tout le cycle :
Création d'une facture
Vérifier la numérotation, la date, l'émetteur, le destinataire, la description, les bases imposables, les taux, les montants d'impôt, les totaux et les règles d'arrondi. Le registre est généré au bon moment et reste lié à la facture.
Correction et annulation
Une facture émise ne se « modifie » pas comme un document texte. Les erreurs doivent être corrigées par les mécanismes prévus par la réglementation, en conservant la traçabilité intacte. Tester les changements de montant, de destinataire, de taux d'imposition, les remboursements et l'annulation abusive.
Enchaînement et empreinte
Cela valide que la séquence reste cohérente et que toute altération est détectée. Les tests incluent un changement d'exercice fiscal, de série, une restauration de sauvegarde et la concurrence entre terminaux.
Code QR et affichage de la facture
La facture doit inclure les éléments exigés pour chaque cas. Vérifier l'impression, la sortie PDF, l'affichage mobile, les factures simplifiées, les modèles personnalisés et les documents générés par les intégrations.
Transmission et réponse
En mode VERI*FACTU, tester les transmissions, les réponses, les rejets, les nouvelles tentatives et le rapprochement. Une transmission technique n'équivaut pas à une acceptation ; les statuts doivent être visibles et actionnables.
Journalisation des événements
Le cas échéant, il doit y avoir des preuves des actions pertinentes du système. Les accès et les exports sont restreints et protégés contre toute modification non autorisée.
Migration sans perdre la traçabilité
La mise à jour peut impliquer de migrer des données ou de changer de fournisseur. L'objectif n'est pas de tout copier sans discernement, mais de conserver la capacité à consulter et à prouver ce qui est nécessaire.
Le plan distingue :
- les données de référence actives : clients, produits, taxes et séries ;
- les documents en attente : devis, commandes, bons de livraison et factures ;
- l'historique légal et comptable ;
- les registres et événements techniques ;
- les pièces jointes et les preuves ;
- les utilisateurs, rôles et autorisations.
Avant la bascule, nettoyer la qualité des données : numéros d'identification fiscale, adresses, codes fiscaux, doublons, séries et règles. Ensuite, rapprocher les décomptes et les montants par entité, exercice fiscal, série et taxe. Conserver une copie protégée de l'ancien système et documenter comment l'interroger.
Une migration ne doit jamais être improvisée pendant une période de clôture. La répétition s'effectue sur une copie représentative, chronométrée, avec un critère d'abandon défini à l'avance. Le plan de retour arrière précise jusqu'à quel point l'ancien système peut être réutilisé sans créer deux sources de vérité.
Intégrations : où les projets échouent le plus souvent
L'ERP, l'e-commerce, le TPV, le CRM et les applications sectorielles peuvent tous partager la création de documents. Il doit y avoir un système unique responsable de la numérotation et du statut final. Si deux systèmes génèrent des numéros ou émettent des corrections de manière indépendante, des trous, des doublons ou des incohérences apparaîtront.
Chaque intégration doit définir :
| Élément | Décision nécessaire |
|---|---|
| Système maître | Qui crée et numérote la facture |
| Moment de l'émission | L'événement exact qui déclenche le registre |
| Identifiant | Une clé partagée et idempotente |
| Erreurs | File d'attente, nouvelle tentative, alerte et responsable |
| Correction | Quel système initie et synchronise |
| Rapprochement | Comparaison quotidienne des statuts et des montants |
Les nouvelles tentatives doivent être idempotentes : répéter une requête après un délai d'attente dépassé ne doit pas créer une autre facture. Les pannes partielles, la latence et les messages désordonnés doivent aussi être répétés en test.
Sécurité, accès et protection des données
Les profils utilisateurs doivent séparer l'administration, l'émission, la correction, la consultation et l'export. Les comptes partagés rendent difficile l'attribution des actions. Une authentification adéquate, la révocation immédiate des accès, la protection des sauvegardes, la journalisation de l'activité et la gestion des vulnérabilités sont toutes requises.
Les certificats ou identifiants utilisés pour la transmission ne doivent pas être intégrés dans le code ni accessibles à tous les utilisateurs. Ils doivent être stockés de manière sécurisée, renouvelés et surveillés.
Les factures contiennent des données personnelles. L'adaptation doit être intégrée avec les accords de sous-traitance des données, le contrôle d'accès, la conservation, la gestion des droits des personnes concernées et l'analyse des transferts partout où un hébergement cloud ou international est impliqué. L'obligation fiscale justifie certaines durées de conservation, mais pas un usage commercial indiscriminé.
Plan de déploiement par phases
Phase 1. Diagnostic
- Inventaire des entités, systèmes et flux.
- Décision de périmètre validée par les conseillers fiscaux.
- Classification de la criticité et des intégrations.
- Sélection du mode et du fournisseur.
Phase 2. Préparation
- Mise à jour des données de référence et des règles.
- Contrat, déclaration de responsabilité et plan de support.
- Environnement de test et cas de tests d'acceptation.
- Conception de la migration, de la sécurité et de la contingence.
Phase 3. Tests
- Factures ordinaires, simplifiées et rectificatives.
- Enchaînement, code QR, transmission et erreurs.
- Intégrations, concurrence et pics de volume.
- Restauration, consultations historiques et retour arrière.
Phase 4. Pilote
- Une entité, un établissement ou une série contrôlés.
- Rapprochement quotidien et cellule d'incidents.
- Formation basée sur des tâches réelles.
- Corrections avant le déploiement général.
Phase 5. Mise en production
- Bascule approuvée et communiquée.
- Surveillance renforcée.
- Support pendant les périodes de clôture.
- Registre d'acceptation et archive de preuves.
Matrice de tests d'acceptation
| Cas | Résultat attendu | Preuve |
|---|---|---|
| Facture correcte | Registre et affichage cohérents | PDF, registre et journal |
| Données fiscales invalides | Blocage contrôlé ou avertissement | Capture d'écran et ticket |
| Correction | Lien vers l'original et traçabilité | Registres liés |
| Panne réseau | File d'attente et nouvelle tentative sans duplication | Journal et rapprochement |
| Restauration | Séquence intacte et consultation disponible | Registre de test |
| Changement d'exercice fiscal | Série et enchaînement corrects | Rapport de séquence |
| Appel d'intégration en double | L'idempotence empêche une seconde facture | Journal des requêtes |
Plan de contingence
Il doit couvrir trois scénarios : l'indisponibilité de l'application, la panne de la connexion avec l'AEAT, et une erreur massive suite à une mise à jour. Pour chacun, définir qui déclare l'incident, comment les opérations se poursuivent légalement, quelles données sont enregistrées, comment elles sont récupérées et comment elles sont rapprochées par la suite.
Une feuille de calcul parallèle non contrôlée ne doit pas être conservée comme solution permanente. Le plan de contingence doit être approuvé, numéroté, limité dans le temps et répété en test. Une fois le service rétabli, un responsable désigné rapproche chaque opération et conserve les preuves.
Erreurs courantes
- Confondre le règlement SIF avec le mode VERI*FACTU.
- Attendre l'échéance légale pour demander la mise à jour.
- N'inventorier que l'ERP en oubliant le TPV, l'e-commerce ou Excel.
- Accepter un « logiciel homologué » sans vérifier la version et la déclaration.
- Ne tester qu'une facture simple, pas les corrections ni les pannes.
- Migrer les données historiques sans rapprochement ni plan de retour arrière.
- Autoriser des comptes partagés et des changements non traçables.
- Ne pas coordonner les conseillers fiscaux, l'entreprise, l'informatique et le fournisseur.
- Traiter la facturation électronique B2B et VERI*FACTU comme un seul projet.
- Ne pas réserver de support pour les périodes de clôture et les pics de facturation.
Checklist pour la direction
- Périmètre documenté par entité et par flux.
- Dates applicables confirmées auprès d'une source officielle.
- Logiciel, version et mode décidés.
- Déclaration de responsabilité et documentation archivées.
- Données de référence, séries et taxes nettoyées.
- Corrections, code QR, registres et transmission testés.
- Intégrations avec idempotence et rapprochement.
- Sécurité, certificats et rôles révisés.
- Migration et retour arrière répétés en test.
- Plan de contingence testé et responsables formés.
- Registre d'acceptation et archive de preuves.
Questions fréquentes
VERI*FACTU est-il obligatoire pour toutes les entreprises ?
La réglementation exige que les systèmes entrant dans son périmètre respectent ses exigences. Le mode de transmission VERI*FACTU doit être distingué d'un système non-VERI*FACTU. L'adéquation spécifique doit être validée pour chaque assujetti et chaque flux.
Quelles sont les dates de 2027 ?
Avant le 1er janvier 2027 pour les entités assujetties à l'impôt sur les sociétés, et avant le 1er juillet 2027 pour toutes les autres parties couvertes, en vertu de la prorogation approuvée en 2025.
Puis-je continuer à facturer avec Excel ?
Il faut analyser si l'outil est utilisé comme un système informatique de facturation entrant dans le périmètre. Un modèle qui génère et conserve des factures ne doit pas être présumé exclu sans analyse.
Existe-t-il un logiciel officiellement homologué ?
La réglementation repose sur des exigences et sur la déclaration de responsabilité du producteur. L'entreprise doit vérifier le produit, la version, la configuration et les preuves, sans se fier uniquement à un label commercial.
Est-ce la même chose que la facturation électronique B2B ?
Non. Ce sont des cadres différents, bien qu'ils partagent des données et puissent nécessiter une architecture coordonnée.
Vaut-il la peine d'attendre jusqu'en 2027 ?
Non. 2026 doit servir à l'inventaire, au choix du fournisseur, aux tests, au pilote et à un déploiement progressif. Cette marge permet de corriger les problèmes sans bloquer la facturation.
Sources officielles consultées
- Décret royal 1007/2023 (texte consolidé).
- Arrêté HAC/1177/2024.
- Décret royal 254/2025.
- Décret-loi royal 15/2025.
- AEAT : prorogation des délais d'adaptation.
Summum Sistemas peut accompagner l'inventaire, la sélection, la migration, les intégrations et les tests. La responsabilité fiscale doit être validée avec un conseil compétent ; l'objectif technique est que le changement soit traçable, réversible et compatible avec la façon dont l'entreprise fonctionne réellement.