L'adaptation aux systèmes informatiques de facturation ne se résume pas à activer un bouton au dernier moment. Elle exige 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 enregistrements intègres et traçables, de tester les rectifications, de former les utilisateurs et de préparer des plans de contingence. Après la prorogation approuvée en décembre 2025, les contribuables assujettis à l'impôt sur les sociétés doivent avoir adapté leurs systèmes avant le 1er janvier 2027 ; les autres obligés visés par le règlement, avant le 1er juillet 2027.
Ce qui change en 2027, et ce qu'il ne faut pas confondre
Le Real Decreto 1007/2023 a approuvé le règlement fixant les exigences applicables aux systèmes et programmes qui soutiennent les processus de facturation. L'Orden HAC/1177/2024 en a précisé les spécifications techniques et fonctionnelles. Le Real Decreto-ley 15/2025 a ensuite prolongé les délais d'adaptation jusqu'en 2027.
Dans le langage commercial courant, « Verifactu » sert à désigner l'ensemble du changement, mais il convient de distinguer les concepts :
- Le RRSIF (le règlement SIF, Reglamento de los Sistemas Informáticos de Facturación) régit les exigences que doivent respecter les systèmes informatiques de facturation relevant de son champ d'application.
- VERI*FACTU est la modalité qui transmet les enregistrements de facturation au siège é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 incombent et conserver des registres et des contrôles supplémentaires.
- La facture électronique B2B relève d'un autre cadre et d'autres flux. Elle partage des données et des intégrations, mais n'est pas synonyme de VERI*FACTU.
La première décision n'est donc pas « quel fournisseur choisir », mais quelles entités, activités, établissements, séries et applications entrent dans le périmètre, et quelle modalité opérationnelle sera utilisée.
Calendrier officiel et lecture pratique
Après la modification de 2025, l'Agence fiscale espagnole (AEAT) fixe :
| Groupe | Date limite d'adaptation |
|---|---|
| Entités assujetties à l'impôt sur les sociétés | Avant le 1er janvier 2027 |
| Autres obligés visés | Avant le 1er juillet 2027 |
La période antérieure peut être utilisée pour les tests. Elle ne doit pas être interprétée comme une autorisation à reporter le projet. Une organisation disposant de plusieurs points de vente, intégrations ou clôtures complexes doit se réserver du temps pour corriger les anomalies sans mettre en péril la facturation.
Les dates et le périmètre doivent être vérifiés à nouveau avant de publier ou d'exécuter le plan, car des évolutions réglementaires, des particularités territoriales ou des situations exclues peuvent exister. Les entreprises relevant du Suministro Inmediato de Información (SII) et celles opérant sous des régimes forales, comme TicketBAI, doivent analyser spécifiquement leur situation. Il n'est pas prudent d'extrapoler une réponse générale.
Étape 1. Faire l'inventaire de la facturation réelle
L'inventaire doit couvrir plus que le logiciel principal. De nombreuses entreprises facturent également depuis l'e-commerce, les TPV, des tableurs, des applications verticales, des ERP secondaires ou des processus manuels.
Pour chaque flux, il convient d'enregistrer :
- l'entité et le numéro fiscal (NIF) qui facture ;
- activité, établissement et série ;
- application et version ;
- fournisseur et responsable interne ;
- origine de la commande ou du service ;
- règles fiscales et remises ;
- factures ordinaires, simplifiées et rectificatives ;
- copies, doublons et avoirs ;
- intégration comptable et bancaire ;
- volume maximal et périodes critiques ;
- mode de contingence actuel.
L'inventaire doit repérer la « facturation de l'ombre » : modèles bureautiques, tickets réécrits ou documents émis hors système. S'ils subsistent, le projet peut sembler terminé tout en restant non conforme sur un canal résiduel.
Étape 2. Confirmer le périmètre avec un conseil fiscal
L'entreprise doit documenter qui est assujetti, quelles opérations entrent dans le périmètre 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 :
- entités et établissements analysés ;
- réglementation et critères appliqués ;
- applications concernées ;
- flux exclus et leur justification ;
- modalité choisie pour chaque système ;
- validation fiscale et date de révision.
Il faut également définir la relation avec le SII, les régimes forales, la facturation par le destinataire ou un tiers, l'autofacturation et les systèmes étrangers. Lorsqu'un groupe partage une plateforme, le périmètre se décide par entité et par flux, non par installation.
Étape 3. Exiger des preuves du fournisseur
Une simple affirmation commerciale « compatible Verifactu » ne suffit pas. Le fournisseur doit identifier le produit, la version et la configuration ; fournir la déclaration de responsabilité prévue par la réglementation ; expliquer la modalité ; et documenter les exigences techniques, la mise à jour, le support et la conservation.
Questions essentielles :
- Quelle version précise est conforme, et depuis quelle date ?
- Comment génère-t-il, enchaîne-t-il et conserve-t-il les enregistrements ?
- Comment traite-t-il les rectifications 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 renseigner ?
- Comment le QR et les mentions de la facture sont-ils mis à jour ?
- Quel export permet-il pour l'audit ou la migration ?
- Quelles preuves conserve-t-il des événements et des changements ?
- Quel SLA propose-t-il pendant les clôtures et les échéances ?
Il n'existe pas d'« homologation individuelle » permettant de remplacer la diligence de l'entreprise par un simple logo commercial. 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
Le règlement vise à garantir l'intégrité, la conservation, l'accessibilité, la lisibilité, la traçabilité et l'inaltérabilité des enregistrements. Les spécifications précisent la structure, l'enchaînement, les empreintes, les événements, le QR et la transmission.
Les tests doivent parcourir le cycle complet :
Création de la facture
Vérifier la numérotation, la date, l'émetteur, le destinataire, la description, les bases, les taux, les montants de taxe, les totaux et les règles d'arrondi. L'enregistrement est généré au moment voulu et reste lié à la facture.
Rectification et annulation
Une facture émise ne s'« édite » pas comme un document texte. Les erreurs doivent être corrigées par les mécanismes prévus, en conservant la traçabilité. Il faut tester les changements de montant, de destinataire, de taux d'imposition, les remboursements et les annulations abusives.
Enchaînement et empreinte
On valide que la séquence reste cohérente et que toute altération est détectée. Les tests incluent un changement d'exercice, de série, la restauration d'une sauvegarde et la concurrence entre terminaux.
QR et représentation de la facture
La facture doit intégrer les éléments exigés selon le cas. On vérifie l'impression, le 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 modalité VERI*FACTU, on teste les envois, les réponses, les rejets, les nouvelles tentatives et la réconciliation. Un envoi technique n'équivaut pas à une acceptation ; les statuts doivent être visibles et exploitables.
Registre des événements
Le cas échéant, il doit exister une preuve des actions pertinentes du système. Les accès et les exports sont limités et protégés contre toute modification non autorisée.
Migration sans perte de traçabilité
Une 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é de consulter et de justifier ce qui est nécessaire.
Le plan distingue :
- données maîtresses actives : clients, produits, taxes et séries ;
- documents en cours : devis, commandes, bons de livraison et factures ;
- historique légal et comptable ;
- enregistrements techniques et événements ;
- pièces jointes et preuves ;
- utilisateurs, rôles et autorisations.
Avant la bascule, on nettoie la qualité des données : NIF, adresses, codes fiscaux, doublons, séries et règles. Ensuite, on réconcilie les comptages et les montants par entité, exercice, série et taxe. On conserve une copie protégée de l'ancien système et on documente comment la consulter.
Une migration ne doit jamais être improvisée pendant une clôture. La répétition se fait sur une copie représentative, elle est chronométrée, avec un critère d'abandon défini à l'avance. Le plan de retour arrière indique jusqu'à quel moment l'ancien système peut être réutilisé sans créer deux sources de vérité.
Intégrations : le point où les projets échouent le plus
ERP, e-commerce, TPV, CRM et applications sectorielles peuvent partager la création des documents. Il doit exister un seul système responsable de la numérotation et du statut final. Si deux systèmes génèrent des numéros ou rectifient de façon 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 d'émission | L'événement exact qui déclenche l'enregistrement |
| Identifiant | Une clé commune et idempotente |
| Erreurs | File d'attente, nouvelle tentative, alerte et responsable |
| Rectification | Système qui initie et synchronise |
| Réconciliation | 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 ne doit pas créer une autre facture. Il faut aussi tester les pannes partielles, la latence et les messages désordonnés.
Sécurité, accès et protection des données
Les profils doivent séparer l'administration, l'émission, la rectification, la consultation et l'export. Les comptes partagés compliquent l'attribution des actions. Une authentification adéquate, une révocation immédiate des accès, une protection des sauvegardes, une journalisation de l'activité et une gestion des vulnérabilités sont exigées.
Les certificats ou identifiants utilisés pour la transmission ne doivent pas être intégrés au code ni accessibles à tous les utilisateurs. Ils doivent être stockés de façon sécurisée, renouvelés et surveillés.
Les factures contiennent des données personnelles. L'adaptation doit s'intégrer avec les contrats de sous-traitance, le contrôle des accès, la conservation, le traitement des droits des personnes et l'analyse des transferts lorsqu'il existe un hébergement dans le cloud ou à l'international. L'obligation fiscale légitime certaines conservations, mais pas un usage commercial indiscriminé.
Plan de mise en œuvre par phases
Phase 1. Diagnostic
- Inventaire des entités, systèmes et flux.
- Décision de périmètre validée fiscalement.
- Classification de la criticité et des intégrations.
- Sélection de la modalité et du fournisseur.
Phase 2. Préparation
- Mise à jour des données maîtresses et des règles.
- Contrat, déclaration de responsabilité et plan de support.
- Environnement de test et cas 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, QR, transmission et erreurs.
- Intégrations, concurrence et volume maximal.
- Restauration, consultation historique et retour arrière.
Phase 4. Pilote
- Une entité, un établissement ou une série contrôlée.
- Réconciliation quotidienne et cellule d'incidents.
- Formation fondé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 clôtures.
- Procès-verbal d'acceptation et archive des preuves.
Matrice des tests d'acceptation
| Cas | Résultat attendu | Preuve |
|---|---|---|
| Facture correcte | Enregistrement et représentation cohérents | PDF, enregistrement et journal |
| Donnée fiscale invalide | Blocage ou avertissement contrôlé | Capture et ticket |
| Rectification | Lien avec l'original et traçabilité | Enregistrements liés |
| Panne réseau | File d'attente et nouvelle tentative sans doublon | Journal et réconciliation |
| Restauration | Séquence intègre et consultation disponible | Procès-verbal de test |
| Changement d'exercice | Série et enchaînement corrects | Rapport de séquence |
| Intégration en doublon | L'idempotence évite une seconde facture | Journal de requête |
Plan de contingence
Il doit couvrir trois scénarios : application indisponible, connexion à l'AEAT indisponible et erreur massive après une mise à jour. Pour chacun, on définit qui déclare l'incident, comment continuer à opérer légalement, quelles données sont enregistrées, comment elles sont récupérées et comment elles sont réconciliées ensuite.
Il est déconseillé de conserver une feuille parallèle non maîtrisée comme solution permanente. La contingence doit être approuvée, numérotée, limitée dans le temps et testée. Une fois le service rétabli, une personne responsable réconcilie toutes les opérations et conserve les preuves.
Erreurs fréquentes
- Confondre le règlement SIF avec la modalité 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, sans rectifications ni pannes.
- Migrer l'historique sans réconciliation ni plan de retour arrière.
- Autoriser des comptes partagés et des changements sans traces.
- Ne pas coordonner conseil fiscal, métier, IT et fournisseur.
- Traiter la facture électronique B2B et VERI*FACTU comme un seul projet.
- Ne pas réserver de support pour les clôtures 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 modalité décidés.
- Déclaration de responsabilité et documentation conservées.
- Données maîtresses, séries et taxes assainies.
- Rectifications, QR, enregistrements et transmission testés.
- Intégrations avec idempotence et réconciliation.
- Sécurité, certificats et rôles revus.
- Migration et retour arrière testés.
- Contingence testée et responsables formés.
- Procès-verbal d'acceptation et archive des preuves.
Questions fréquentes
VERI*FACTU est-il obligatoire pour toutes les entreprises ?
Le règlement exige que les systèmes concernés respectent ses exigences. La modalité de transmission VERI*FACTU doit être distinguée du système non-VERI*FACTU. L'adéquation précise doit être validée pour chaque obligé et chaque flux.
Quelles sont les échéances 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 les autres obligés visés, selon 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 relevant du 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 norme repose sur des exigences et sur la déclaration de responsabilité de l'éditeur. L'entreprise doit vérifier le produit, la version, la configuration et les preuves, et non se fier uniquement à une étiquette commerciale.
Est-ce la même chose que la facture é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 mieux attendre 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 sans bloquer la facturation.
Sources officielles consultées
- Real Decreto 1007/2023 (texte consolidé).
- Orden HAC/1177/2024.
- Real Decreto 254/2025.
- Real Decreto-ley 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 par un conseil compétent ; l'objectif technique est que le changement soit traçable, réversible et compatible avec le fonctionnement réel de l'activité.