Verifactu : FAQ à connaître avant la conformité obligatoire pour les développeurs de logiciels.

Actuellement, diverses réglementations fiscales coexistent en Espagne, avec des objectifs similaires mais des portées d'application différentes :

Verifactu : Il s'agit d'un système promu par l'Agence Fiscale Espagnole (AEAT) au niveau national. Il exige que tous les logiciels de facturation opérant en Espagne répondent à des exigences techniques spécifiques à partir du 29 juillet 2025. À partir de 2026, les enregistrements de facturation des entreprises et des travailleurs indépendants doivent être automatiquement envoyés à l'AEAT. Il s'applique aux entreprises ayant leur résidence fiscale en Espagne et un chiffre d'affaires annuel de moins de 6 millions d'euros.

SII (Fourniture Immédiate d'Information) : Cette réglementation fiscale s'applique aux entreprises ayant un chiffre d'affaires supérieur à 6 millions d'euros, aux groupes de TVA ou à celles inscrites au REDEME. C'est un système parallèle déjà en vigueur, exigeant la soumission quasi en temps réel des entrées du registre de TVA. Cependant, la conformité au SII n'implique pas que vous devez également vous conformer à Verifactu. En d'autres termes, les deux systèmes s'excluent mutuellement. Si vous vous conformez déjà au SII, vous n'avez pas besoin d'implémenter Verifactu également. Inversement, si un contribuable adopte Verifactu dans un exercice fiscal donné et dépasse plus tard le seuil de 6 millions d'euros, il n'est pas tenu de passer au SII immédiatement. La transition vers le SII, si applicable, ne sera obligatoire qu'à partir de l'exercice fiscal suivant.

TicketBAI : Il s'agit de la réglementation fiscale obligatoire au Pays Basque (Álava, Gipuzkoa et Bizkaia), qui établit son propre système de facturation électronique. Les entreprises qui se conforment déjà à TicketBAI ne sont pas non plus tenues d'adopter Verifactu.

FACE : Il s'agit de la plateforme utilisée pour envoyer des factures électroniques aux administrations publiques. Elle restera active et ne sera pas supprimée avec l'introduction de Verifactu. Les deux systèmes peuvent coexister sans problème.

En résumé :

• Si vous vous conformez déjà au SII ou à TicketBAI, vous n'avez pas besoin de vous conformer à Verifactu.
• Verifactu s'appliquera aux contribuables restants sous juridiction nationale, qui doivent utiliser des logiciels de facturation adaptés aux exigences techniques de Verifactu.
• FACE restera le canal valide pour les factures destinées aux administrations publiques.

Verifactu sera obligatoire pour toute entreprise ou travailleur indépendant qui émet des factures dans le territoire de TVA espagnol. Cependant, la réglementation inclut certaines exemptions :

• Entreprises sous SII : Elles n'ont pas à dupliquer leur soumission de données via Verifactu.
• Entreprises sous le Régime Spécial du Surtaxe ou le REAGYP (Agriculture, Élevage et Pêche) : Elles sont exemptées d'émettre des factures, sauf dans des cas spécifiques. Dans ces cas où des factures doivent être émises, elles doivent répondre aux exigences de Verifactu.
• Contribuables déjà sous TicketBAI : S'ils se conforment à ce système, ils n'ont pas besoin d'adopter Verifactu.

De plus, la soumission obligatoire des factures à l'AEAT commencera par phases :

• À partir du 1er janvier 2027 pour les entités juridiques (entreprises)
• À partir du 1er juillet 2027 pour les personnes physiques (travailleurs indépendants)

Jusqu'à ces dates, il est possible de soumettre des informations volontairement et sans aucune pénalité de l'AEAT en cas d'erreurs. Ceci est fortement recommandé pour valider les processus avant que l'obligation entre en vigueur. Ceci a été officiellement confirmé par l'AEAT dans leur dernière publication de FAQ.

Oui. Les factures émises aux particuliers (personnes physiques sans numéro de TVA déclaré), comme les reçus d'un magasin ou d'une station-service, sont également soumises à Verifactu.

Un point clé à garder à l'esprit : chaque ticket, même si le client n'est pas identifié, doit générer son propre enregistrement de facturation individuel et se conformer à toutes les exigences techniques—code QR, CSV, hash, etc.

Puisque le mode Verifactu nécessite une connexion Internet, l'AEAT prévoit des situations exceptionnelles où la connectivité est limitée ou indisponible (pour une durée limitée). Dans ces cas :

• La facture doit être générée localement en conformité avec Verifactu, incluant le QR et le CSV, et l'enregistrement doit indiquer qu'un incident s'est produit.
• La transmission à l'AEAT peut avoir lieu plus tard, une fois la connexion rétablie.
• La clé est que la facture doit être techniquement conforme dès le début, même si elle est synchronisée plus tard.

L'absence de connexion Internet n'exempte pas de la conformité aux exigences techniques, mais elle permet une certaine flexibilité dans la transmission. Avec notre API Verifactu, vous êtes couvert : SIGN ES détecte la panne et reprend automatiquement la transmission des enregistrements lorsque la connexion est rétablie, afin que vos clients puissent continuer à émettre des factures conformes sans interrompre leur activité.

Si votre point de vente n'a pas de connexion Internet stable, il peut être utile d'envisager le mode de transmission Non-Verifactu, bien que cela puisse impliquer d'autres complexités techniques.

Oui. Les machines qui émettent des tickets—comme les distributeurs de billets, les distributeurs automatiques ou les kiosques en libre-service—doivent se conformer à Verifactu dans la mesure où elles sont tenues d'émettre des factures simplifiées.

Même les machines plus anciennes (par exemple, des machines à boutons sans connectivité) doivent être adaptées pour répondre à la réglementation ou remplacées par des solutions conformes.

Lorsque l'AEAT rejette un enregistrement soumis en mode Verifactu, trois scénarios peuvent se produire selon les validations effectuées :

1. Rejet total de la soumission : La soumission entière est rejetée lorsqu'il y a des erreurs structurelles (par exemple, des balises XML mal formées) ou des erreurs syntaxiques dans l'en-tête. Dans de tels cas, aucun enregistrement n'est traité et une réponse SoapFault est retournée indiquant l'erreur technique.

2. Acceptation partielle : Si certains enregistrements sont valides et d'autres non, une acceptation partielle se produit. Les enregistrements valides sont acceptés et les invalides sont rejetés, avec une explication détaillée pour chacun. Les erreurs de rejet peuvent inclure :

   • Validations syntaxiques (format, longueur, valeurs dans les listes déroulantes, etc.)
   • Validations de règles métier (par exemple, relations entre champs qui ne répondent pas aux règles définies)
   • Dans ce cas, le contribuable doit corriger uniquement les enregistrements invalides et les soumettre à nouveau, à condition qu'ils ne nécessitent pas une facture corrective ou d'annulation.

3. Accepté avec erreurs (erreurs admissibles) : Certaines erreurs sont considérées comme "admissibles" par l'AEAT. Ces enregistrements sont acceptés mais marqués comme "Accepté avec erreurs", incluant une description du problème. Même ainsi, les erreurs devraient être corrigées si l'émetteur veut qu'elles soient correctement reflétées, en soumettant un nouvel enregistrement de remplacement (correction).

Dans tous les cas, le SIF (Système Informatique de Facturation) doit conserver les enregistrements originaux exactement comme ils ont été générés, même s'ils contiennent des erreurs. Il n'est pas permis de modifier les enregistrements déjà générés. Toutes les corrections doivent être soumises comme de nouveaux enregistrements—qu'il s'agisse d'une correction, d'une annulation ou d'une rectification. Les enregistrements rejetés ne seront pas considérés comme officiellement soumis à l'AEAT jusqu'à ce qu'ils soient acceptés.

Oui. Même si votre activité est sporadique—par exemple, si une personne physique loue un entrepôt et n'émet qu'une facture par mois—cette facture doit se conformer à Verifactu.

Le facteur important n'est pas la fréquence à laquelle vous émettez des factures, mais si vous utilisez un logiciel de facturation pour le faire. Si vous générez des factures manuellement (par exemple en utilisant Word ou Excel sans fonctionnalité de facturation), vous ne répondrez pas aux exigences techniques et pourriez faire face à des amendes de l'AEAT.

La Déclaration Responsable est un document par lequel le fabricant ou développeur de logiciel de facturation certifie que son produit se conforme à toutes les exigences techniques et fonctionnelles établies par la réglementation Verifactu.

Ce document :

• N'a pas besoin d'être soumis à l'Agence Fiscale Espagnole (AEAT) comme exigence obligatoire, mais il doit être écrit et visiblement inclus dans le logiciel de facturation, accessible à la fois au client et au revendeur au moment de l'acquisition du produit.
• Est une déclaration légalement contraignante, ce qui signifie que le développeur assume la responsabilité en cas de fausses déclarations ou de non-conformité.

En bref : la Déclaration Responsable certifie que le logiciel se conforme à Verifactu sans nécessiter de certification officielle préalable. Elle peut être considérée comme une forme d'auto-certification.

Concernant le format, l'AEAT a récemment publié un modèle pour la Déclaration Responsable, spécifiant le contenu requis.

Chez fiskaly, nous avons déjà un modèle prêt à l'emploi que nos clients peuvent compléter et intégrer dans leur logiciel. Si vous êtes intéressé, n'hésitez pas à nous contacter et nous vous l'enverrons.

Oui. L'AEAT a clarifié que la Déclaration Responsable doit clairement spécifier la version du logiciel à laquelle elle se réfère.

Cela garantit que chaque version livrée aux clients soit explicitement liée à une Déclaration Responsable spécifique et permet la traçabilité en cas d'audits ou d'inspections futurs. Par conséquent, si votre logiciel évolue ou est mis à jour, chaque nouvelle version doit être accompagnée d'une nouvelle Déclaration Responsable.

Avoir une Déclaration Responsable n'exempte pas automatiquement le développeur des pénalités. C'est une exigence obligatoire, mais s'il est constaté que le logiciel ne se conforme pas vraiment à Verifactu, il peut y avoir des conséquences légales pour le développeur.

Cela dit, avoir une déclaration correctement émise et maintenir la traçabilité de la conformité fournit un support légal important en cas d'audit ou d'inspection.

Pour le certificat numérique nécessaire pour envoyer les enregistrements à l'AEAT :

• Un certificat électronique qualifié est requis qui identifie directement le contribuable ou est lié via une autorisation accordée par le contribuable.
• Un certificat valide pour une personne physique ou morale, émis par une autorité de certification reconnue, est suffisant pour signer les enregistrements soumis à l'AEAT.

Dans notre API Verifactu, ce processus peut être automatisé pour réduire la complexité de la gestion des certificats pour le client. Puisque nous sommes officiellement reconnus comme Collaborateur Social de l'AEAT, nous pouvons signer les transactions en utilisant uniquement notre propre certificat numérique—signant les fichiers et soumettant les enregistrements de facturation au nom du contribuable.

Tout ce dont nous avons besoin, c'est que le contribuable nous accorde l'autorisation en signant l'Annexe de Collaboration Sociale.

En principe, non. Les bons de livraison ne sont pas soumis à Verifactu, car ils ne sont pas des factures ni des documents ayant une validité fiscale—ils servent simplement de preuve de livraison. Il en va de même pour les factures proforma, devis ou pré-factures : ils ne constituent pas des enregistrements de facturation officiels.

Cependant, l'AEAT stipule que tout document généré par un SIF, même s'il ne s'agit pas d'une facture "réelle", doit être stocké de manière inaltérable. Cela inclut les bons de livraison, proformas, devis ou brouillons émis par le système. L'objectif est de s'assurer que chaque transaction est enregistrée de manière permanente et peut être tracée, même si elle ne se traduit finalement pas par une facture émise.

Si votre entreprise est couverte par le SII (Système de Fourniture Immédiate d'Information), vous n'êtes pas tenu de vous conformer à Verifactu pour vos factures de vente. Par conséquent, il n'est pas obligatoire d'inclure le code QR sur ces factures.

Dans ce cas, vous pouvez continuer à générer vos factures comme vous le faites actuellement dans le cadre du SII, et il n'est pas nécessaire d'inclure le code QR ou le CSV, car votre canal de communication avec l'AEAT est différent.

Oui. Le 29 juillet 2025 est la date limite pour que tous les Systèmes d'Information de Facturation (SIF) qui sont commercialisés, mis à jour ou livrés soient déjà conformes à Verifactu.

Cela s'applique à :

• Tous les logiciels de facturation vendus à de nouveaux clients
• Les mises à jour de logiciels livrées aux clients existants
• Toute nouvelle version de logiciel déployée en production en Espagne

En d'autres termes, il ne suffit pas d'avoir le logiciel prêt en janvier 2026 (quand l'obligation commence pour les entreprises). À partir du 29 juillet 2025, il ne sera pas permis de distribuer ou déployer tout logiciel qui ne répond pas aux normes techniques de Verifactu—même si la soumission obligatoire à l'AEAT commence plus tard (janvier ou juillet 2026, selon le type de contribuable).

Non. À partir du 29 juillet 2025, tout nouveau client recevant votre logiciel doit l'obtenir entièrement adapté à Verifactu, avec toutes les fonctionnalités requises actives.

Cela signifie :

• Le logiciel doit inclure la génération de l'enregistrement XML structuré, du code QR, du CSV et du hash chaîné
• La fonctionnalité Verifactu ne peut pas être désactivée ou retardée comme si elle était optionnelle

Même si le client n'est pas tenu de soumettre des données à l'AEAT jusqu'en 2026, le système doit être prêt à le faire dès le début.

Oui. Si une entreprise développe en interne son propre Système d'Information de Facturation, elle est soumise aux mêmes obligations techniques qu'un développeur de logiciel commercial. Cela signifie :

• Le logiciel doit se conformer à toutes les exigences de Verifactu
• Une Déclaration Responsable doit être émise en interne, confirmant que le système répond à la réglementation
• L'entreprise doit assurer la traçabilité, l'intégrité des données et la génération d'enregistrements valides

Cependant, notez : les délais changent dans ce cas. Les entreprises utilisant des logiciels internes (non commercialisés) ne sont pas tenues de se conformer avant le 29 juillet 2025. Leurs délais sont :

• 1er janvier 2026 pour les entités juridiques
• 1er juillet 2026 pour les personnes physiques (travailleurs indépendants)

En bref : le logiciel doit se conformer de la même manière, mais la date limite de conformité dépend de s'il est vendu commercialement ou utilisé uniquement en interne.