Aide - Questions / Réponses
Rechercher :
PA / eReporting
- À quoi sert la page « Envoi vers PA / eReporting » ?
- Où consulter l’historique des dépôts, erreurs et statuts PA ?
- Comment Tempolia distingue B2B France, B2C et international ?
- Que faut-il contrôler sur la fiche client avant un dépôt PA ?
- Que se passe-t-il lors de l’envoi d’une facture B2B France ?
- Que se passe-t-il pour une facture B2C ou internationale ?
- Quelle différence entre TVA sur les débits et TVA sur les encaissements ?
- Comment déclarer les règlements d’une facture B2B France ?
- Comment gérer les prélèvements SEPA et les rejets ?
- À quelle fréquence envoyer les déclarations PA et comment éviter les doublons ?
La page Envoi vers PA / eReporting sert à lancer un dépôt précis vers une PA à un instant donné. On y accède depuis les outils d’export Tempolia, via la page Envoi vers PA / eReporting. Cette page permet de choisir la plateforme agréée utilisée par le cabinet : JeFacture/Banqup, Sage Network, Pennylane, Inqom, Iopole, B2BRouter, Billit, Storecove, Pagero, Avalara, Basware ou SUPER PDP selon les connecteurs configurés. Après le choix de la PA, Tempolia affiche le texte d’introduction correspondant au connecteur.
L’utilisateur coche ensuite les opérations à lancer :
- dépôt de factures ;
- envoi e-reporting et règlements ;
- synchronisation des statuts ;
- consultation annuaire ponctuelle ;
- test de connexion avec la plateforme.
Les opérations cochées sont exécutées dans un ordre stable pour éviter les oublis : contrôle technique si demandé, consultation annuaire si demandée, dépôt des factures, e-reporting et règlements, puis synchronisation des statuts.
Le contrôle annuaire n’est pas imposé à chaque dépôt. Il sert à rafraîchir les informations de routage quand on veut contrôler les clients de la période.
Le formulaire permet aussi de sélectionner une société, une période, le format attendu par la plateforme et une option différentielle. L’option différentielle sert à n’envoyer que les éléments qui ne sont pas déjà tracés comme transmis.
Cette page n’est pas une page d’analyse historique : elle sert à exécuter une opération. Pour consulter ce qui s’est passé avant ou comprendre une erreur, il faut utiliser la page d’historique PA. En pratique, le bon réflexe est donc : lancer les dépôts depuis Envoi vers PA / eReporting, puis contrôler les traces dans Gestion et historique PA.
L’historique se consulte sur la page Gestion et historique PA. Cette page est séparée de la page de dépôt pour éviter de mélanger deux usages différents.
- Le dépôt répond à la question : qu’est-ce que j’envoie maintenant ?
- L’historique répond à la question : qu’est-ce qui a été envoyé, quand, avec quel statut et quelle réponse technique ?
La page d’historique affiche plusieurs tableaux :
- factures envoyées ;
- flux e-reporting ;
- règlements inclus dans les déclarations ;
- annuaire PA ;
- événements techniques.
Chaque tableau peut être filtré par plateforme, société et statut. Les identifiants de flux, identifiants de suivi, statuts, dates d’envoi, erreurs et réponses de la plateforme sont conservés pour analyse. Les événements techniques permettent de voir les détails d’échange avec la plateforme, ses messages, les erreurs de validation ou les statuts reçus.
Si une facture ou un règlement est refusé par la PA, c’est cette page qu’il faut consulter en premier.
Si un règlement déjà transmis est ensuite corrigé par une écriture inverse, par exemple un rejet de prélèvement, Tempolia conserve les deux événements dans l’historique. Cette séparation est importante pour la traçabilité : on ne supprime pas silencieusement un événement déjà transmis.
Tempolia qualifie chaque facture avant l’envoi PA. Cette qualification détermine si la facture relève de l’e-invoicing B2B France ou de l’e-reporting.
| Situation | Traitement PA |
|---|---|
| Client professionnel établi en France, identifiable par SIREN, SIRET ou TVA intracommunautaire | Facture électronique B2B France déposée auprès de la PA |
| Client professionnel hors France | E-reporting transaction unitaire |
| Particulier ou non-assujetti | E-reporting transaction B2C |
Sur la page d’envoi, les cases d’action correspondent à ces familles de flux : dépôt de factures B2B France, e-reporting transaction et règlements.
Une facture B2B France ne doit pas partir dans le flux e-reporting transaction. Quand l’information est explicitement enregistrée sur le client ou la facture, Tempolia la respecte. Sinon, Tempolia infère prudemment le périmètre depuis le pays, le SIRET/SIREN et le numéro de TVA.
Avant un envoi, il faut donc vérifier les fiches clients : pays, SIRET, TVA intracommunautaire et informations PA. Une mauvaise qualification peut empêcher un dépôt ou orienter la facture vers le mauvais type de flux.
La fiche client doit contenir les informations nécessaires à l’identification de l’acheteur. On la vérifie dans « Clients et Affaires > Clients ».
Pour un client professionnel français, il faut renseigner correctement le SIREN ou SIRET. Il faut aussi renseigner la raison sociale, l’adresse, le pays et, si disponible, le numéro de TVA intracommunautaire.
Pour les échanges PA, l’ "Id d’adressage PA" (identifiant de routage annuaire) peut être nécessaire. Cet identifiant indique à quelle plateforme ou quel service de réception la facture doit être adressée. Cette information peut être remplie des fiches client en haut de l’onglet Facturation. Tempolia peut également rechercher ou mettre en cache des informations d’annuaire PA selon les connecteurs disponibles.
Selon la plateforme agréée utilisée, une facture B2B France sans identifiant de routage peut être bloquée avant dépôt. Ce contrôle dépend du connecteur PA configuré dans Tempolia et évite d’envoyer une facture impossible à router correctement.
Pour un client particulier, il ne faut pas inventer de SIRET : la facture relève du B2C et sera traitée par e-reporting. Pour un client étranger professionnel, le pays et le numéro de TVA ou identifiant professionnel permettent de qualifier le flux international.
Une facture B2B France est déposée auprès de la PA comme facture électronique. Selon la plateforme et les options, Tempolia envoie une Factur-X ou des données structurées au format CII ou UBL. Par défaut, Tempolia privilégie la Factur-X lorsque le connecteur l’accepte, car Tempolia sait déjà générer ce format. Certains connecteurs imposent ou préfèrent l’UBL ; dans ce cas Tempolia génère des données au format UBL.
Avant le dépôt, Tempolia contrôle le périmètre PA de la facture. Si la facture est B2C ou internationale, Tempolia bloque le dépôt facture B2B France et indique d’utiliser l’action e-reporting.
Après le dépôt, Tempolia stocke les identifiants retournés :
- document PA ;
- identifiant de flux PA ;
- identifiant de suivi ;
- statut ;
- date d’envoi.
Ces informations sont visibles dans l’historique PA. Ensuite, les statuts PA peuvent être synchronisés : dépôt accepté, rejet technique, mise à disposition, refus, statut fonctionnel, etc.
Si la facture est une prestation avec TVA exigible à l’encaissement, les paiements ultérieurs ne sont pas envoyés comme une nouvelle facture. Ils sont envoyés comme statuts de cycle de vie rattachés à cette facture.
Une facture B2C ou une facture B2B internationale ne suit pas le même circuit qu’une facture B2B France. Elle ne doit pas être déposée comme facture électronique domestique B2B France : elle alimente le flux e-reporting transaction.
Pour un client professionnel hors France, Tempolia prépare une transaction unitaire rattachée à la facture. Pour le B2C, les données peuvent être agrégées selon les règles de déclaration applicables.
Le flux transmis contient les informations fiscales utiles :
- période ;
- société déclarante ;
- type d’opération ;
- montants HT, TVA et TTC ;
- devise ;
- ventilation par taux de TVA.
Tempolia conserve la transmission dans l’historique PA, avec le statut, l’identifiant de suivi et la réponse de la plateforme. Si l’opération est soumise à TVA à l’encaissement, les règlements peuvent aussi alimenter l’e-reporting paiement. Les paiements B2C ou internationaux sont alors transmis dans le flux réglementaire de paiement.
Si l’opération est soumise à TVA sur les débits, l’e-reporting transaction suffit fiscalement pour la TVA : les paiements reçus ensuite ne déclenchent pas une déclaration de paiement PA.
L’utilisateur lance ces envois en cochant Envoyer les flux e-reporting et règlements sur la page Envoi vers PA / eReporting. L’historique permet ensuite de vérifier quelles factures ou quels règlements ont été inclus.
La différence est essentielle pour comprendre ce que Tempolia doit envoyer à la Plateforme agréée.
| Mode d’exigibilité TVA | Conséquence PA |
|---|---|
| TVA sur les débits | La TVA est déclarée sans attendre le règlement. Tempolia envoie la facture électronique ou l’e-reporting transaction selon le type de client, mais le règlement reçu plus tard ne crée pas à lui seul une déclaration de paiement PA. |
| TVA sur les encaissements | La TVA devient exigible lorsque le règlement est réellement encaissé. Tempolia doit transmettre les données d’encaissement, ventilées par taux de TVA, en plus de la facture ou du flux de transaction. |
Le paiement reste utile pour le suivi client, le lettrage, les relances et la comptabilité, même lorsqu’il ne constitue pas une donnée fiscale d’encaissement à transmettre à la PA. Pour une facture B2B France passée en e-invoicing, l’encaissement est transmis comme un statut de cycle de vie rattaché à la facture. Ces statuts utilisent le format CDAR, c’est-à-dire Cross Domain Acknowledgement and Response, le message normalisé du socle AFNOR pour les événements de cycle de vie de facture. Pour une facture B2C ou internationale relevant de l’e-reporting, l’encaissement est transmis dans un flux de paiement.
Si une facture contient des éléments mixtes, par exemple une partie taxable sur les débits et une partie taxable à l’encaissement, seules les lignes ou montants soumis à TVA sur les encaissements doivent alimenter les données de paiement PA.
En pratique, l’utilisateur doit donc vérifier le régime de TVA applicable au dossier, à la prestation et au client avant d’interpréter les flux de paiement. Pour cette raison, la notion d’encaissement déclaré dans Tempolia se lit toujours après cette qualification TVA. Tempolia ne doit déclarer à la PA qu’un encaissement considéré comme effectif dans Tempolia, et seulement pour les opérations dont la TVA est exigible à l’encaissement.
Si la facture est soumise à TVA sur les débits, le règlement reste utile pour le suivi client et le lettrage, mais il ne crée pas à lui seul une déclaration de paiement PA. Un règlement prévu n’est pas un encaissement. Un règlement seulement lettré indique une cohérence comptable, mais il doit aussi respecter les règles métier Tempolia pour entrer dans un flux PA. La date utilisée pour déclarer le paiement reste la date d’échéance du règlement.
Pour un virement, un chèque ou un règlement manuel, le règlement lettré et présent dans la période peut alimenter la déclaration PA. Pour un prélèvement SEPA, Tempolia exige en plus que le règlement soit marqué Transféré en banque. Cette règle évite de déclarer un prélèvement simplement préparé mais pas encore envoyé à la banque.
Si le prélèvement est rejeté, le rejet se gère par la création d’un autre règlement, négatif, avec sa propre date d’échéance, cf. la FAQ "Comment gérer un rejet de prélèvement ?". Ce règlement négatif doit être lettré comme les autres écritures liées à la facture. Il sera alors visible dans l’historique et pourra corriger le montant déclaré sur la période concernée.
Pour une facture B2B France dont la TVA est exigible à l’encaissement, les encaissements ne partent pas dans le même bloc e-reporting qu’une facture internationale ou B2C. Ils sont envoyés sous forme de statut de cycle de vie CDAR, c’est-à-dire Cross Domain Acknowledgement and Response, le message normalisé utilisé pour les événements de cycle de vie de facture. Le statut utilisé pour l’encaissement est le statut 212 Encaissée.
Si la facture B2B France est soumise à TVA sur les débits, l’obligation PA porte sur la facture et ses statuts de transmission ou de traitement, pas sur une déclaration fiscale d’encaissement.
Tempolia construit un message de cycle de vie au format CDAR, Cross Domain Acknowledgement and Response, rattaché à la facture déposée. Ce CDAR, Cross Domain Acknowledgement and Response, contient la référence de la facture, la date d’échéance du règlement utilisée comme date de paiement et les montants encaissés ventilés par taux de TVA.
Chaque paiement partiel peut produire un statut d’encaissement distinct. Par exemple, une facture réglée en trois fois donnera trois événements d’encaissement si les trois règlements sont encaissés à des dates différentes.
Tempolia exige qu’un identifiant de dépôt PA existe déjà pour la facture. Cela évite d’envoyer un encaissement impossible à rattacher côté PA. Si la facture n’a pas encore d’identifiant PA, Tempolia signale l’erreur dans le résultat et l’historique.
Les statuts d’encaissement envoyés sont enregistrés dans l’historique PA, afin de pouvoir retrouver la facture, le règlement, la date d’envoi et la réponse de la plateforme.
Lorsqu’un fichier SEPA est généré, Tempolia marque les règlements comme transférés en banque. Pour la déclaration PA, Tempolia considère alors le prélèvement comme encaissé. Il n’y a pas de statut PA séparé à renseigner sur le règlement. La date déclarée reste la date d’échéance, qui doit représenter la date bancaire attendue pour ce règlement.
Si le prélèvement est rejeté avant la déclaration PA, il faut créer le règlement négatif de rejet avant de lancer l’envoi. Dans Tempolia, le rejet se crée depuis l’action de rejet sur la ligne de règlement. Cette action crée une nouvelle ligne de règlement négative, dont la date d’échéance doit correspondre à la date bancaire du rejet.
Si un encaissement avait déjà été transmis puis qu’un rejet arrive ensuite, Tempolia ne supprime pas l’historique. Le règlement initial reste historisé comme il a été transmis. La ligne négative de rejet devient l’événement correctif à transmettre sur la période adéquate. L’utilisateur voit donc dans l’historique l’encaissement initial, puis le règlement négatif qui corrige le montant.
L’important est de conserver la chaîne complète : encaissement déclaré, rejet bancaire matérialisé par un règlement négatif, puis nouvelle transmission PA si nécessaire.
La fréquence réglementaire dépend du régime de TVA.
| Régime TVA | Fréquence | Jours limites |
|---|---|---|
| Réel normal mensuel | Données de transaction e-reporting par décades | 20 du même mois pour la première décade, 30 du même mois pour la deuxième, 10 du mois suivant pour la troisième |
| Réel normal trimestriel | Transmission mensuelle | Avant le 10 du mois suivant |
| Régime simplifié d’imposition TVA | Données de transaction et, lorsqu’elles existent, données de paiement mensuelles | Entre le 25 et le 30 du mois suivant |
| Franchise en base de TVA | Données de transaction et, lorsqu’elles existent, données de paiement bimestrielles | Entre le 25 et le 30 du mois suivant la fin de la période de deux mois |
Pour février, la deuxième échéance du régime réel normal mensuel est naturellement adaptée à la fin du mois. Ces jours correspondent aux délais indiqués par l’administration fiscale dans le tableau officiel des fréquences et délais de transmission e-reporting. Les échéances de données de paiement ne signifient donc pas que tous les règlements doivent être déclarés : elles concernent les encaissements des opérations à TVA exigible à l’encaissement.
La PA peut accepter des dépôts plus fréquents, mais Tempolia conserve la trace de ce qui a déjà été envoyé. Dans le formulaire PA, l’option différentielle permet de n’envoyer que les factures et règlements qui ne sont pas déjà validés comme transmis. Cette option est recommandée pour les traitements périodiques, car elle évite de redéclarer un règlement déjà envoyé.
Si une erreur a eu lieu, il faut consulter l’historique PA avant de relancer. Une ligne en erreur peut être corrigée puis renvoyée. Une ligne déjà envoyée puis corrigée doit être analysée avec son historique. Dans ce cas, il ne faut pas simplement supprimer la trace : il faut comprendre l’événement, créer si nécessaire le règlement correctif négatif, puis transmettre les éléments attendus par la PA utilisée.
