Quel endpoint génère Factur-X ?

Utilisez POST /api/v1/e-invoice/render avec settings.e_invoice.standard défini à factur_x.

gPdf génère-t-il le XML EN 16931 ?

Votre système fournit le XML CII et détient son exactitude métier. gPdf l'intègre dans le PDF hybride.

gPdf prend-il en charge XRechnung sur cette page ?

Non. Cette page est limitée au contrat public Factur-X listé dans OpenAPI.

gPdf soumet-il les factures Factur-X aux portails ?

Non. La soumission et le routage destinataire restent hors de l'API de rendu.

Compliance and archival

API Factur-X pour factures électroniques hybrides PDF/A-3b

Générez des factures Factur-X PDF/A-3b avec XML CII EN 16931 intégré via l'endpoint public E-Invoice Render.

API PRINCIPALE E-Invoice Render

ENDPOINT /api/v1/e-invoice/render

SYSTÈMES ERP / backend de facturation / workflow conformité / service d'automatisation finance

Essayer dans le Playground → Lire la documentation

Tâche à accomplir

Conditionner un PDF de facture généré en Factur-X PDF/A-3b avec XML CII EN 16931 intégré, après que votre ERP ou système de facturation a produit les données structurées de facture correctes.

Quand utiliser cette API

Vous avez besoin d'une sortie Factur-X native depuis l'endpoint public E-Invoice Render.
Votre système possède déjà un XML CII EN 16931 valide pour la facture.
Vous avez besoin du packaging PDF/A-3b avec métadonnées Factur-X et câblage de fichier associé.
Vous voulez que l'endpoint de capacités confirme le contrat de facture électronique actuellement publié.

Ce qu'elle ne remplace pas

Vous voulez que gPdf crée pour vous la sémantique métier de la facture ou les décisions fiscales.
Vous avez besoin de XRechnung, FatturaPA, KSeF, Peppol, ZATCA, NF-e ou d'autres standards natifs non listés dans OpenAPI.
Vous avez besoin d'une soumission directe à Chorus Pro ou à un autre portail gouvernemental.

Quel endpoint appeler

PRINCIPAL

/api/v1/e-invoice/render

E-Invoice Render est le chemin par défaut pour ce workflow.

SECONDAIRE 1

/api/v1/e-invoice/capabilities

À utiliser si le workflow a besoin d'un chemin API lié, d'un contrat de modèle ou d'une recherche de capacités.

Requête minimale

POST /api/v1/e-invoice/render - forme minimale d'un package Factur-X.

{
  "settings": {
    "profile": "pdfa-3b",
    "e_invoice": {
      "standard": "factur_x",
      "profile": "en16931",
      "document_type": "invoice",
      "xml": {
        "format": "cii",
        "encoding": "utf8",
        "content": "<rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
      }
    }
  },
  "pages": [
    {
      "size": "a4",
      "elements": [
        {
          "type": "text",
          "x": 20,
          "y": 24,
          "content": "Factur-X invoice",
          "style": { "font_size": 16, "font_family": "NotoSans-Regular" }
        }
      ]
    }
  ]
}

Ce que gPdf prend en charge

Packaging Factur-X via E-Invoice Render.
Gestion du profil PDF/A-3b pour le PDF de facture hybride.
Intégration du XML CII comme fichier associé avec les métadonnées standard.
Livraison PDF inline ou comportement de job object-delivery comme documenté.

Ce que votre système garde

XML CII EN 16931 correct, numéros de facture, logique fiscale, données acheteur et vendeur, et éligibilité.
Validation externe, règles destinataire, soumission portail et interprétation légale.
Stockage, piste d'audit, logique de retry et livraison au client ou portail.

Checklist de production

Valider le XML CII avant de l'envoyer à gPdf.
Définir settings.profile à pdfa-3b ou l'omettre pour appliquer le défaut de facture électronique.
Utiliser settings.e_invoice.standard = factur_x et settings.e_invoice.profile = en16931.
Passer le PDF retourné dans votre workflow de validation Factur-X.
Garder la soumission et le routage destinataire hors de l'API de rendu.

Limites de la promesse

La sortie native publique de facture électronique est Factur-X ou ZUGFeRD avec XML CII EN 16931.
gPdf ne soumet pas les factures à des portails gouvernementaux ou acheteurs.
Votre système détient l'exactitude métier, fiscale et XML.

Factur-X est un workflow de packaging de facture électronique

Factur-X combine un PDF lisible par l’humain avec un XML CII EN 16931 lisible par machine. L’endpoint public gPdf conditionne cette combinaison en sortie PDF/A-3b. Il ne décide pas la sémantique de la facture et ne soumet pas le fichier à un portail.

Choix de l’endpoint

L’appel par défaut utilise /api/v1/e-invoice/render. Utilisez JSON Render tant que le layout évolue ou que l’appelant décrit toute la page. Une fois le layout approuvé, publiez-le comme template et envoyez seulement les données métier via Template Render.

Réservez E-Invoice Render aux paquets Factur-X / ZUGFeRD PDF/A-3b avec XML EN 16931 CII embarqué. Les PDF opérationnels, étiquettes, reçus et rapports ordinaires ne doivent pas être traités comme un flux de facture électronique.

Validation avant production

Validez API Factur-X avec des données réelles et les systèmes qui consommeront le PDF. Conservez les request IDs, les sorties rendues et les preuves d’acceptation pour le support, l’audit et les réimpressions. gPdf rend le PDF ; les règles métier, le routage externe, la fiscalité, les transporteurs et la conformité marketplace restent dans votre système.

FAQ

Quel endpoint génère Factur-X ?: Utilisez POST /api/v1/e-invoice/render avec settings.e_invoice.standard défini à factur_x.
gPdf génère-t-il le XML EN 16931 ?: Votre système fournit le XML CII et détient son exactitude métier. gPdf l'intègre dans le PDF hybride.
gPdf prend-il en charge XRechnung sur cette page ?: Non. Cette page est limitée au contrat public Factur-X listé dans OpenAPI.
gPdf soumet-il les factures Factur-X aux portails ?: Non. La soumission et le routage destinataire restent hors de l'API de rendu.