Aller au contenu principal
Invoice-Converter.comInvoice-Converter
Tarifs
Convertir une factureConvertir
Convertir
⌘K
Vue d’ensemble de la documentation
Comprendre les formats et les standards
Guides de conformité
Standard XRechnung
Format ZUGFeRD
PDF/A-3 pour ZUGFeRD
CII Cross Industry Invoice
UBL Universal Business Language
Norme DIN EN 16931-1
Réseau PEPPOL
Règles pays et réglementaires
Obligation UE de e-facturation
E-facturation UE
E‑facturation dans l’UE en 2026 : quoi mettre en place (et pourquoi)
Playbook des principaux marchés UE (DE, FR, IT, ES, PL, NL)
PEPPOL dans l’UE : comment l’échange fonctionne vraiment
CTC/clearance et portails dans l’UE : construire des intégrations fiables
Guides par pays
Allemagne
France
Italie
Espagne
Pologne
Pays-Bas
Belgique
Autriche
Danemark
Suède
Finlande
Résoudre les problèmes de validation et de soumission
Validation Leitweg-ID
Guides d’assistance
Assistance
Pourquoi les factures doivent être vérifiées
Préparation PDF
Préparation des données source
Pièces jointes et descriptions de service
Erreurs API
Automatisation de l'API
Gestion des erreurs de schéma
Aide à la validation de révision
Assistance
Informations manquantes
Référence acheteur
Paiement et IBAN
TVA et autoliquidation
Totaux et arrondis
Acomptes
Lignes de facture
Avertissements PDF ZUGFeRD
Guides de validation
Corrections de validation observées
Échéance ou conditions
IBAN de virement
Compatibilité PDF/A-3
Motif VATEX
Revue et téléchargement
Bibliothèque publique de factures de test
Facture XRechnung UBL basique valide
XRechnung invalide sans conditions de paiement
XML CII Factur-X/ZUGFeRD EN 16931
Cas limite XRechnung pour arrondis et IBAN
Erreurs du validateur KOSIT
ERREUR
BR-DE-1
BR-DE-2
BR-DE-3
BR-DE-4
BR-DE-5
BR-DE-6
BR-DE-7
BR-DE-8
BR-DE-9
BR-DE-10
BR-DE-11
BR-DE-14
BR-DE-15
BR-DE-16
BR-DEX-01
BR-DEX-03
BR-DEX-04
BR-DEX-05
BR-DEX-06
BR-DEX-07
BR-DEX-08
BR-DEX-09
BR-DEX-10
BR-DEX-11
BR-DEX-12
BR-DEX-13
BR-DEX-14
BR-CO-3
BR-CO-4
BR-CO-9
BR-CO-10
BR-CO-11
BR-CO-13
BR-CO-14
BR-CO-15
BR-CO-16
BR-CO-17
BR-CO-25
BR-CO-26
BR-S-1
BR-S-5
BR-S-8
BR-CO-05
BR-CO-06
BR-CO-07
BR-CO-08
BR-CO-12
BR-CO-18
BR-CO-19
BR-CO-20
BR-CO-21
BR-CO-22
BR-CO-23
BR-CO-24
BR-61
BR-AE-02
BR-AE-10
BR-E-01
BR-E-05
BR-DE-19
BR-05
BR-22
BR-23
BR-24
BR-25
BR-26
BR-47
BR-57
BR-DE-22
BR-DE-30
BR-DE-31
PEPPOL-EN16931-R001
PEPPOL-EN16931-R010
PEPPOL-EN16931-R020
PEPPOL-EN16931-R046
PEPPOL-EN16931-R120
PEPPOL-EN16931-R130
BR-01
BR-02
BR-03
BR-04
BR-06
BR-07
BR-08
BR-09
BR-10
BR-11
BR-12
BR-13
BR-14
BR-15
BR-16
BR-17
BR-18
BR-19
BR-20
BR-21
BR-27
BR-28
BR-29
BR-30
BR-31
BR-32
BR-33
BR-36
BR-37
BR-38
BR-41
BR-42
BR-43
BR-44
BR-45
BR-46
BR-48
BR-49
BR-50
BR-51
BR-52
BR-53
BR-54
BR-55
BR-56
BR-62
BR-63
BR-64
BR-65
BR-CL-01
BR-CL-03
BR-CL-04
BR-CL-05
BR-CL-06
BR-CL-07
BR-CL-08
BR-CL-10
BR-CL-11
BR-CL-13
BR-CL-14
BR-CL-15
BR-CL-16
BR-CL-17
BR-CL-18
BR-CL-19
BR-CL-20
BR-CL-21
BR-CL-22
BR-CL-23
BR-CL-24
BR-CL-25
BR-CL-26
BR-DEC-01
BR-DEC-02
BR-DEC-05
BR-DEC-06
BR-DEC-09
BR-DEC-10
BR-DEC-11
BR-DEC-12
BR-DEC-13
BR-DEC-14
BR-DEC-15
BR-DEC-16
BR-DEC-17
BR-DEC-18
BR-DEC-19
BR-DEC-20
BR-DEC-23
BR-DEC-24
BR-DEC-25
BR-DEC-27
BR-DEC-28
BR-S-02
BR-S-03
BR-S-04
BR-S-06
BR-S-07
BR-S-09
BR-S-10
BR-Z-01
BR-Z-02
BR-Z-03
BR-Z-04
BR-Z-05
BR-Z-06
BR-Z-07
BR-Z-08
BR-Z-09
BR-Z-10
BR-AE-01
BR-AE-03
BR-AE-04
BR-AE-05
BR-AE-06
BR-AE-07
BR-AE-08
BR-AE-09
BR-E-02
BR-E-03
BR-E-04
BR-E-06
BR-E-07
BR-E-08
BR-E-09
BR-E-10
BR-IC-01
BR-IC-02
BR-IC-03
BR-IC-04
BR-IC-05
BR-IC-06
BR-IC-07
BR-IC-08
BR-IC-09
BR-IC-10
BR-IC-11
BR-IC-12
BR-G-01
BR-G-02
BR-G-03
BR-G-04
BR-G-05
BR-G-06
BR-G-07
BR-G-08
BR-G-09
BR-G-10
BR-O-01
BR-O-02
BR-O-03
BR-O-04
BR-O-05
BR-O-06
BR-O-07
BR-O-08
BR-O-09
BR-O-10
BR-O-11
BR-O-12
BR-O-13
BR-O-14
BR-AF-01
BR-AF-02
BR-AF-03
BR-AF-04
BR-AF-05
BR-AF-06
BR-AF-07
BR-AF-08
BR-AF-09
BR-AF-10
BR-AG-01
BR-AG-02
BR-AG-03
BR-AG-04
BR-AG-05
BR-AG-06
BR-AG-07
BR-AG-08
BR-AG-09
BR-AG-10
BR-B-01
BR-B-02
AVERTISSEMENT
BR-DE-17
BR-DE-18
BR-DE-20
BR-DE-21
BR-DEX-02
BR-DE-26
BR-DE-27
BR-DE-28
Consulter les données de référence
Glossaire
E
EN 16931
E-reporting
e-Factura RO
EAS (Electronic Address Scheme)
ebInterface
C
CIUS
CII
Catégorie de taxe
Code type de facture
Code unité
Chorus Pro
Codice Destinatario
X
XRechnung
XML
Z
ZUGFeRD
F
Factur-X
Finvoice
U
UBL
P
PEPPOL
PEPPOL BIS
PDF/A-3
Paiement par QR code
PDP (Plateforme de Dématérialisation Partenaire)
A
Access Point
Autoliquidation
Avoir
I
Identifiant participant
IBAN
ISO 6523
S
SMP
SML
Schéma XML (XSD)
Schematron
SDI (Sistema di Interscambio)
Svefaktura
L
Leitweg-ID
Liste de codes
Ligne de facture
K
KoSIT
KSeF
V
Validation
ViDA
VeriFactu
ViDA Pilier 1 : Digital Reporting Requirements
ViDA Pilier 2 : enregistrement TVA unique
ViDA Pilier 3 : Économie des plateformes
B
Business Term (BT)
Business Group (BG)
BIC
Bon de commande (PO)
N
N° TVA
Numéro D-U-N-S
Numéro KvK
NemHandel
M
Moyen de paiement
R
Référence de document
Référence de contrat
Remise / charge
Reporting temps réel
Reporting de factures en temps réel (RTIR)
T
TicketBAI
G
GLN (Global Location Number)
O
OVT-tunnus
OIOUBL
D
Digipoort
Listes de codes
Codes devise (courants)
Codes pays (courants)
Codes catégorie TVA
Codes moyen de paiement
Codes unité de mesure (courants)
Codes type de facture (courants en XRechnung)
Champs XRechnung
Bases de la facture
BT-1
BT-2
BT-3
BT-5
BT-6
BT-7
BT-8
BT-10
BT-11
BT-12
BT-14
BT-15
BT-16
BT-17
BT-18
BT-19
BT-21
BT-22
BT-23
BT-24
BT-25
BT-26
Livraison et paiement
BT-9
BT-13
BT-20
BT-59
BT-60
BT-61
BT-70
BT-71
BT-72
BT-73
BT-74
BT-75
BT-76
BT-77
BT-78
BT-79
BT-80
BT-81
BT-82
BT-83
BT-84
BT-85
BT-86
BT-87
BT-88
BT-89
BT-90
BT-91
Donnees vendeur
BT-27
BT-28
BT-29
BT-30
BT-31
BT-32
BT-33
BT-34
BT-35
BT-36
BT-37
BT-38
BT-39
BT-40
BT-41
BT-42
BT-43
BT-62
BT-63
BT-64
BT-65
BT-66
BT-67
BT-68
BT-69
Donnees acheteur
BT-44
BT-45
BT-46
BT-47
BT-48
BT-49
BT-50
BT-51
BT-52
BT-53
BT-54
BT-55
BT-56
BT-57
BT-58
Remises et frais
BT-92
BT-93
BT-94
BT-95
BT-96
BT-97
BT-98
BT-99
BT-100
BT-101
BT-102
BT-103
BT-104
BT-105
Taxes et totaux
BT-106
BT-107
BT-108
BT-109
BT-110
BT-111
BT-112
BT-113
BT-114
BT-115
BT-116
BT-117
BT-118
BT-119
BT-120
BT-121
BT-122
BT-123
BT-124
BT-125
Lignes de facture
BT-126
BT-127
BT-128
BT-129
BT-130
BT-131
BT-132
BT-133
BT-134
BT-135
BT-136
BT-137
BT-138
BT-139
BT-140
BT-141
BT-142
BT-143
BT-144
BT-145
BT-146
BT-147
BT-148
BT-149
BT-150
BT-151
BT-152
BT-153
BT-154
BT-155
BT-156
BT-157
BT-158
BT-159
BT-160
BT-161
BT-162
BT-163
Profils ZUGFeRD
MINIMUM
BASIC WL
BASIC
EN 16931
EXTENDED
Comparer les formats et les outils
Comparaisons
XRechnung vs ZUGFeRD
PDF24 Tools
sevDesk
Intégrer et mettre en œuvre
Aide en cas d’incident plateforme
Assistance
Temporairement indisponible
Résultat manquant
Validation indisponible
Erreurs navigateur
Compte et limites de débit
Crédits et abonnements
Validation officielle
Guides de validation des exports ERP
DATEV
Lexware
SAP Business One
Odoo
Microsoft Dynamics
Confiance & sécurité
API développeur
Factures par e-mail
  1. Ressources e-facturation
  2. API développeur
  3. Factures par e-mail

Intégration · 2026-07-10

Export Markdown

Intégrer les factures par e-mail

Configurez un expéditeur vérifié, utilisez la boîte propre au format affichée dans votre profil et recevez des messages de réponse adossés à une preuve dans le fil d’origine, fractionnés seulement si la taille des pièces jointes l’exige.

Canal e-mail activé par comptePréparer l’expéditeur avant la première factureChoisir le format cible par l’adresse destinataireDe la réception à la réponseUnités de facturation et contexte de l’e-mailÉtats finaux et artefactsFichiers acceptés et limites du piloteCe qui exige encore une revue humaineChoisir délibérément e-mail ou APIIntégration et assistanceSchémas de flux

Canal e-mail activé par compte#

Utilisez ce canal pour des flux de factures contrôlés et de faible volume.

La conversion par e-mail est réservée aux comptes Enterprise activés dans le pilote actuel. Un abonnement actif, l’import e-mail activé et au moins un expéditeur vérifié sont requis.

Les adresses propres aux formats affichées dans votre profil font foi. Elles peuvent varier selon l’environnement; ne codez donc pas en dur une adresse reprise d’un exemple ou d’une documentation interne.

Disponibilité

L’activation et la vérification des expéditeurs sont réalisées pendant l’intégration. Un compte ordinaire n’active pas le canal en envoyant simplement un e-mail.

Préparer l’expéditeur avant la première facture#

Effectuez ces étapes dans le profil avant d’automatiser une boîte ou une règle ERP.

  1. Demandez à l’équipe Invoice-Converter d’activer le canal e-mail pour le compte Enterprise.
  2. Ajoutez l’adresse d’envoi et ouvrez le lien de vérification reçu dans cette boîte.
  3. Choisissez un retour vers l’expéditeur initial ou une adresse collective vérifiée, puis sélectionnez la langue de réponse.
  4. Copiez les adresses XRechnung et ZUGFeRD du profil et testez chaque route nécessaire avec un PDF représentatif.

Choisir le format cible par l’adresse destinataire#

CibleAdresse à utiliserRéponse réussie
XRechnungLa boîte XRechnung affichée dans le profil activé.XML validé et rapport HTML de validation lié à l’artefact.
ZUGFeRD / Factur-XLa boîte ZUGFeRD affichée dans le profil activé.PDF/A-3 hybride validé et rapport HTML de validation lié à l’artefact.

De la réception à la réponse#

Le canal accuse rapidement réception auprès du fournisseur, puis exécute la conversion stricte de façon asynchrone.

  1. Un expéditeur vérifié envoie de vraies pièces jointes PDF à une ou plusieurs boîtes propres au format.
  2. Le fournisseur entrant enregistre le message; le service résout le compte activé, l’expéditeur, la destination de réponse et les formats cibles sélectionnés.
  3. Chaque PDF accepté devient une tâche stricte avec validation d’artefact obligatoire, sans remplacement de brouillon ni d’avertissement.
  4. La sortie n’est émise qu’après validation faisant autorité, preuve persistée et contrôle de parité de l’artefact.
  5. Des messages de réponse dans le même fil renvoient les artefacts et rapports HTML; ils sont fractionnés si la taille des pièces jointes l’exige, tandis que message, élément, événement d’usage, preuve et fichiers de réponse durables restent traçables par identifiant.

Unités de facturation et contexte de l’e-mail#

Comptez le message entier avant l’envoi et traitez son texte comme une entrée de conversion.

  • Chaque PDF accepté consomme une unité de conversion par format cible correspondant. Par exemple, deux PDF envoyés aux deux boîtes de format nécessitent quatre unités.
  • Avant la conversion, le service réserve toutes les unités du message: d’abord sur le quota mensuel inclus, puis sur les crédits API disponibles.
  • Si la couverture ne suffit pas pour toutes les unités, le message entier est rejeté avant conversion. Seules les unités réussies sont débitées après stockage durable des artefacts de réponse; les unités échouées sont libérées.
  • Lorsqu’un corps de message est présent, l’objet et le corps de l’e-mail vérifié sont des entrées de conversion complémentaires. Ils peuvent fournir des modifications, corrections, références ou données de facture manquantes. En cas de conflit, les montants, totaux de taxe et lignes du PDF prévalent; le texte de l’e-mail seul ne peut pas créer de lignes de facture. Le contexte e-mail est limité et peut être tronqué; gardez donc signatures et texte d’accompagnement concis, pertinents et sans ambiguïté.
  • Les données de base vendeur enregistrées dans votre profil complètent les champs vendeur manquants (nom, adresse, numéro de TVA, contact) lorsque l’utilisation par défaut est activée; elles n’écrasent jamais les valeurs extraites du PDF.

États finaux et artefacts#

RésultatContenu de la réponsePièces jointes
ÉmisLe fichier est terminé et la validation faisant autorité a réussi.Artefact principal demandé et rapport HTML correspondant.
PartielAu moins un fichier a réussi et au moins un autre a échoué ou été ignoré.Uniquement les artefacts prouvés des fichiers terminés et le statut de chaque fichier.
Validation arrêtéeLes détails bloquants expliquent pourquoi l’émission s’est arrêtée.Aucun résultat non vérifié et aucun rapport HTML lié à un artefact.
Rejet techniqueLa réponse identifie le problème d’expéditeur, de fichier, de droit, de limite ou de traitement.Aucun résultat; suivez les indications avant de réessayer.

Fichiers acceptés et limites du pilote#

Utilisez ces points comme contrôles pratiques pour cette section.

  • Joignez de vrais fichiers PDF. Une image renommée ou un autre document est refusé même si son extension ou son type MIME indique PDF.
  • Un message peut contenir plusieurs PDF, mais le canal vise des flux contrôlés de faible volume, pas une ingestion en masse.
  • Gardez chaque pièce jointe sous la limite communiquée lors de l’intégration; les limites du fournisseur et de l’environnement peuvent évoluer.
  • Si un message atteint plusieurs boîtes de format reconnues, chaque PDF accepté est traité une fois par format sélectionné.
  • Les pièces jointes de réponse sont groupées selon un seuil de 15 Mo par message. Si l’ajout d’un fichier dépasse ce seuil, les pièces restantes continuent dans un autre message du même fil; un fichier individuel n’est pas fractionné.

Ce qui exige encore une revue humaine#

Utilisez ces points comme contrôles pratiques pour cette section.

  • Comparez fournisseur, acheteur, numéro, dates, devise, taxe, totaux, paiement et chaque ligne avec la facture source.
  • Confirmez les références de routage, identifiants de point d’accès, commandes et règles de canal propres au destinataire.
  • Examinez les preuves source peu fiables et chaque avertissement ou détail de validation avant de transmettre le résultat.
  • Une validation technique réussie prouve le fichier émis selon les règles choisies; elle ne remplace pas l’approbation commerciale, fiscale ou du destinataire.

Choisir délibérément e-mail ou API#

CanalUsage adaptéContrôle d’intégration
Canal e-mailFlux humains ou règles de boîte de faible volume pour lesquels le fil de réponse est utile.Boîte de format, expéditeur vérifié, adresse de retour, langue et résultat par message.
External API V1Flux serveur à serveur nécessitant idempotence, interrogation, statut structuré et contrôle explicite du téléchargement.Requêtes authentifiées, références client, identifiants de corrélation, en-têtes de limite et points d’accès aux artefacts.

Intégration et assistance#

Communiquez les expéditeurs attendus, formats cibles, destination de réponse, langue et volume mensuel pendant l’intégration.

Consulter la documentation External API V1
Demander l’intégration du canal e-mail

Schémas de flux#

Les schémas résument le même contrat que les sections consultables ci-dessus.

Ce qui entre dans la conversion et ce que vous recevez

Ce qui entre

  • Pièce jointe PDF

    Source principale

    Lue à la fois via sa couche texte et par OCR. Les montants, totaux de taxe et lignes de facture proviennent toujours du PDF.

  • Objet et corps de l’e-mail

    Complémentaire

    Le texte vérifié peut fournir références, corrections et données manquantes. Il ne remplace jamais les montants du PDF et ne peut pas créer de lignes de facture.

  • Données de base du profil

    Complète les champs

    Les données de base vendeur enregistrées dans votre profil (nom, adresse, numéro de TVA, contact) complètent les champs vendeur manquants lorsque l’utilisation par défaut est activée; elles n’écrasent pas les valeurs extraites.

Conversion stricte

Extraction, enrichissement et validation autoritaire avec contrôles de preuve et de parité.

Ce que vous recevez

  • Artefact validé

    XML XRechnung ou PDF/A-3 hybride ZUGFeRD / Factur-X, selon la boîte utilisée.

  • Rapport de validation HTML

    Le rapport lié à l’artefact prouve la validation du fichier livré.

  • Réponse dans votre fil

    Tout arrive en réponse à votre message d’origine.

De la boîte à la réponse prouvée

  1. 1

    Expéditeur vérifié

    Un compte activé envoie de vrais PDF.

  2. 2

    Boîte de format

    L’adresse choisit XRechnung ou ZUGFeRD.

  3. 3

    Tâche stricte

    Extraction et génération fonctionnent sans dérogation de brouillon.

  4. 4

    Porte de preuve

    Validation, persistance de preuve et parité doivent réussir.

  5. 5

    Réponse dans le fil

    Artefact et rapport reviennent dans un ou plusieurs messages; le fractionnement reste dans le fil.

Chaque état final

Résultat de conversion stricte
  • Émis

    Artefact et rapport

    Seuls les octets adossés à une preuve sont joints.

  • Partiel

    Les succès sont conservés

    Artefacts terminés et erreurs partagent le fil de réponse.

  • Validation arrêtée

    Détails, aucun artefact

    Les règles bloquantes empêchent toute sortie non vérifiée.

  • Rejet technique

    Nouvel essai exploitable

    La réponse explique quoi modifier ou réessayer.

API développeur
Sur cette page
Canal e-mail activé par comptePréparer l’expéditeur avant la première factureChoisir le format cible par l’adresse destinataireDe la réception à la réponseUnités de facturation et contexte de l’e-mailÉtats finaux et artefactsFichiers acceptés et limites du piloteCe qui exige encore une revue humaineChoisir délibérément e-mail ou APIIntégration et assistanceSchémas de flux

Invoice-Converter.com

Nous aidons les entreprises en Europe à convertir leurs factures en XRechnung et autres formats d'e-facture avec une aide à la validation. Vérifiez les cas limites avant l'envoi.

20 000+ factures traitées
Rapide et sécurisé
Approuvé par des centaines d'entreprises

Fonctionnalités

Convertir PDF & créer

  • PDF vers XRechnung
  • PDF vers UBL
  • PDF vers XRechnung (CII)
  • PDF vers ZUGFeRD
  • PDF vers Factur-X
  • Créer XRechnung
  • XRechnung vers PDF

Voir & valider

  • Visualiseur XRechnung/XML
  • Validateur XRechnung

Liens rapides

  • Ressources
  • Centre de confiance & sécurité
  • Documentation API développeur
  • Blog
  • FAQ
  • Tarifs
  • Contribution climatique

Légal

  • Mentions légales
  • Politique de confidentialité
  • Accord de traitement des données
  • Conditions générales
  • Garantie satisfait ou remboursé

Nous contacter

contact@invoice-converter.com
Commencer à convertir
© 2026 Invoice-Converter.com.Fait avec en Europe
Conforme à la réglementation RGPD
Serveur allemand