Envoi de fichiers XML

La conformité TicketBAI prévoit la création de deux types de fichiers XML :

• Fichiers d’enregistrement : Fichier XML créé lorsqu’une nouvelle facture est émise.

• Fichiers d’annulation : Fichier XML créé lorsqu’une facture est annulée, par exemple pour des transactions non effectuées.

TicketBAI exige que ces fichiers soient envoyés à l’autorité fiscale compétente, selon l’endroit où est déclaré l’adresse légale du contribuable qui émet les factures.

Araba et Gipuzkoa

SIGN ES effectue l’envoi automatiquement à Araba et Gipuzkoa. Les factures envoyées par SIGN ES sont utilisées comme le « Livre des factures émises » du système SII (Suministro Inmediato de Información) pour les contribuables qui y sont soumis. Cependant, si des informations supplémentaires sont requises comme le prévoit le SII, telles que des références externes, des transferts immobiliers soumis à la TVA, entre autres, celles-ci devront être envoyées via un service supplémentaire appelé OSATU, non prévu dans les spécifications TicketBAI (voir les exigences du service OSATU disponibles en espagnol).

Le processus d’envoi des fichiers TicketBAI est effectué dans le composant de signature de l’API SIGN ES. Le composant de signature synchronise l’état des fichiers TicketBAI du serveur SIGN ES au serveur de l’autorité fiscale espagnole. Cette synchronisation est implémentée sur le modèle de requête/réponse fourni par l’autorité fiscale espagnole.

Réponse

Lorsqu’un fichier est soumis, les systèmes des autorités fiscales effectuent automatiquement diverses validations, et les résultats de ces vérifications sont inclus dans la réponse.

L’état d’enregistrement idéal est REGISTERED. SIGN ES aide à réduire les rejets en garantissant que les fichiers XML sont correctement structurés et que les données sont formatées avec précision grâce à ses processus de validation.

Cependant, si l’état d’enregistrement d’une facture apparaît comme REQUIRES_CORRECTION, il peut être nécessaire de soumettre à nouveau le fichier, à condition que la réglementation espagnole de facturation n’exige pas l’émission d’une facture rectificative.

Renvoi des factures

SIGN ES permet le renvoi des factures dans les états d’enregistrement REGISTERED, REQUIRES_CORRECTION et REQUIRES_INSPECTION via des factures REMEDY à Zuzendu dans les cas suivants :

• les fichiers d’enregistrement ont été rejetés
• les fichiers d’enregistrement ont été acceptés avec des erreurs mais ne nécessitent PAS de correction légale
• les fichiers acceptés par TicketBAI, où le contribuable doit modifier des informations qui ne nécessitent pas de correction légale

Si une erreur est reçue parce que le contribuable n’a pas enregistré le certificat dispositif à Araba ou a dépassé la période d’acceptation de 30 jours à Gipuzkoa, le contribuable doit rapidement enregistrer ou accepter le certificat dispositif, selon le territoire concerné.

Le renvoi des factures avec un état d’enregistrement PENDING ou STORED n’est pas autorisé. Ces factures sont soit en attente de soumission par SIGN ES, soit stockées parce que la transmission à l’autorité fiscale n’est pas nécessaire.

Bizkaia

Envoi de factures avec SIGN ES

L’envoi est effectué à l’aide d’un certificat dispositif qui doit être enregistré auprès de DFB/BFA par le contribuable obligé. Cela doit être fait avant que le dispositif ne commence à générer des factures au nom du contribuable.

En envoyant les factures en temps réel, nous garantissons le respect des délais imposés par BATUZ.

SOCIÉTÉS : SIGN ES effectue l’envoi automatique des factures TicketBAI dans la sous-section 1.1 du LROE – Factures émises avec logiciel garant (Modèle 240). Cette soumission est en temps réel.

PERSONNES PHYSIQUES : une fois que le code d’activité est fourni, SIGN ES effectue l’envoi des factures TicketBAI dans la sous-section 1.1 du LROE – Revenus avec factures émises avec logiciel garant (Modèle 140).

Idéalement, l’activity_code devrait être fourni au moment de la création de la facture. Cela permet la transmission en temps réel de la facture aux autorités fiscales. Sinon, la facture restera dans l’état STORED et ne sera transmise aux autorités fiscales qu’après la mise à jour de la facture avec le code d’activité.

📘Note

Veuillez vérifier que le code d’activité est valide à Bizkaia, sinon la facture sera rejetée par l’autorité fiscale.

Pour les personnes physiques, il existe deux champs optionnels supplémentaires : income_tax_amount et pay_collect qui, avec l’activity_code, forment un ensemble groupé de données. Si ces champs sont laissés vides tandis que le code d’activité est fourni, ils seront automatiquement marqués comme ‘Non’ par défaut.

Si la base TVA est différente des revenus IRPF du contribuable, le contribuable devra renseigner le champ income_tax_amount. Pour des conseils sur le calcul de ce montant, vous pouvez consulter notre article Comment calculer le montant des revenus IRPF sur une facture ?

Le champ pay_collect indique si le contribuable a choisi de participer au critère d’encaissements et de paiements.

📘Note

Le code d’activité ne peut être introduit qu’une seule fois, soit lors de la création de la facture, soit lors de sa mise à jour, et ne peut pas être modifié par la suite. Cela s’applique également aux champs income_tax_amount et pay_collection, une fois que vous les soumettez avec le code d’activité. Cela garantit que ces informations, une fois saisies, restent cohérentes et immuables.

Le champ vat_withholding dans notre API pourrait s’appliquer à la fois aux personnes physiques et aux sociétés, spécifiquement aux transactions B2B incluant des factures complètes et leurs corrections. Ce champ répond à un scénario spécifique du système fiscal impliquant des travailleurs indépendants qui, lorsqu’ils émettent des factures à des sociétés ou à d’autres travailleurs indépendants, sont tenus de retenir une partie de l’IRPF (impôt sur le revenu des personnes physiques) sur leurs revenus. Dans ce système, c’est l’acheteur, et non le vendeur, qui remet directement une partie de l’impôt à l’autorité.

Réponse

À réception d’une demande, les systèmes de l’autorité fiscale de Bizkaia effectuent automatiquement des validations, et le résultat de ces validations se reflète dans la réponse, comme dans les autres provinces.

Idéalement, l’état d’enregistrement devrait être REGISTERED. SIGN ES aide à minimiser les rejets en garantissant la structure correcte des fichiers XML et le format correct des données saisies grâce aux validations appliquées.

Cependant, si l’état d’enregistrement d’une facture affiche REQUIRES_INSPECTION, il est probable que les fichiers doivent être soumis à nouveau au système de l’autorité fiscale de Bizkaia, à condition que la réglementation de facturation espagnole n’exige pas de facture rectificative. Selon le cas, cela peut se faire soit par le renvoi de la sous-section 1.1 pour les factures émises avec logiciel garant, soit via la sous-section 1.2 pour les factures émises sans logiciel garant.

Renvoi des factures

SIGN ES permet le renvoi des factures dans l’état d’enregistrement REQUIRES_INSPECTION via des factures REMEDY à travers les sous-sections 1.1 et 1.2. Le renvoi des factures avec les états d’enregistrement PENDING et STORED n’est pas autorisé. Ces factures attendent soit la soumission par SIGN ES, soit sont stockées parce que la transmission à l’autorité fiscale n’est pas requise ou des informations importantes manquent.

La re-soumission via la sous-section 1.1 est possible si :

• l’erreur est due à des données non valides introduites dans les champs du bloc annotations
• le certificat dispositif n’était pas enregistré ou était incorrectement enregistré par le contribuable au moment de la transmission

La re-soumission via la sous-section 1.2 est possible si :

• la sous-section 1.1 a été rejetée et la re-soumission via 1.1 n’est pas possible
• si la facture a déjà été corrigée et envoyée via 1.2. Il est également possible de corriger la facture corrigée si la facture de remède est dans l’état REGISTERED

Factures hors ligne

Les factures émises hors ligne à Bizkaia sont classifiées comme « émises sans logiciel garant » et doivent être transmises à la sous-section 1.2 du LROE.

Pour transmettre ces factures, vous devez d’abord les enregistrer dans le système SIGN ES en tant que factures externes, en utilisant le type de facture EXTERNAL. Cette étape est essentielle pour attribuer un UUID à la facture générée hors ligne.

Lorsque la facture est téléchargée en tant que facture EXTERNAL, elle ne sera pas transmise à l’agence fiscale. Au lieu de cela, comme toute autre facture externe, elle aura un état d’enregistrement INVALID.

Pour transmettre la facture, l’étape suivante nécessite la création d’une facture de type REMEDY, en référençant l’UUID précédemment attribué à la facture externe.

Environnement de test

L’environnement de test à Bizkaia nécessite un NIF, un numéro de TVA et un certificat dispositif spécifiques pour éviter les erreurs de rejet. Chez fiskaly, nous avons formellement demandé et obtenu ces informations auprès des autorités. Ces détails spécifiques remplaceront automatiquement les données de test fournies lors de la création des fichiers XML, UNIQUEMENT DANS L’ENVIRONNEMENT DE TEST. Ce faisant, nous garantissons un flux de travail de test fluide avec des réponses de transmission efficaces.

📘Note

L’API SIGN ES effectue des validations qui empêchent le rejet des fichiers XML lors de leur envoi à l’autorité fiscale.