API développeur · Côté réception
InvoiceIn.
Chaque facture électronique reçue, en un seul JSON.
Un seul endpoint sans état. Envoyez en POST ce qui arrive dans votre boîte de réception — XRechnung, ZUGFeRD, Factur-X, Peppol BIS 3, FatturaPA, KSeF — et récupérez un JSON canonique EN 16931, un rapport de validation qui dit ce que l'émetteur doit corriger, un PDF lisible par un humain, et un export CSV ou DATEV pour la comptabilité. Traitement en mémoire, ~10–50 ms par document.
Traitement en mémoire uniquement. Rien n'est stocké. Aucun point d'accès Peppol requis.
Pourquoi ce produit existe
Depuis le 1er septembre 2026, vos clients reçoivent leurs factures fournisseurs en Factur-X, UBL ou CII via leur PDP (plateforme de dématérialisation partenaire) — et XRechnung en Allemagne, KSeF en Pologne, FatturaPA en Italie — alors que votre code a été écrit pour des PDF. Au lieu de cinq parsers et cinq jeux de règles, vous nous envoyez le fichier et recevez un seul JSON, plus la liste de ce qui ne va pas, formulée de façon qu'un comptable puisse la transmettre au fournisseur. Nous ne conservons jamais le document.
Démo en direct
Déposez une vraie facture que vous avez reçue. Nous la lisons, la validons avec les jeux de règles officiels et affichons les indications de correction — rien n'est conservé.
En-tête
Anomalies
JSON brut
Cinq sorties. Un seul appel.
JSON canonique EN 16931
Une seule structure pour toutes les syntaxes. Champs nommés d'après le modèle sémantique avec les numéros BT/BG : vendeur, acheteur, lignes, ventilation de TVA, totaux, paiement et IBAN, références, pièces jointes. Les extensions nationales se trouvent sous extensions.
Rapport avec indications de correction
Jeux de règles officiels plus contrôles arithmétiques croisés. Chaque règle en échec est accompagnée d'une indication en langage clair, en anglais, allemand, français, italien ou polonais — ce que l'émetteur doit modifier et quel champ (numéro BT) est concerné.
PDF ou HTML lisible par un humain
Même mise en page A4 pour toutes les syntaxes, libellés en anglais, allemand, français, italien ou polonais. Pour l'approbateur qui veut voir la facture, pas le XML.
CSV et DATEV
CSV à plat par ligne ou par document, et un lot d'écritures DATEV (Buchungsstapel EXTF 700, le format comptable allemand) pour la facture reçue — SKR03 ou SKR04, votre compte fournisseur.
Serveur MCP
À distance sur /mcp ou en local via stdio. Claude, Cursor, n8n ou votre propre agent lit et valide une facture en un seul appel d'outil.
Ce qui entre, ce qui est vérifié.
La détection est automatique — envoyez le fichier, nous vous disons ce que c'était. Les PDF hybrides sont ouverts et le XML embarqué est extrait ; le PDF lui-même n'est jamais écrit sur disque.
| Format | Syntaxe | Conteneur | Validation appliquée |
|---|---|---|---|
| XRechnung 3.0 | UBL 2.1 ou CII D16B | XML | XSD · Schematron EN 16931 1.3.17 · XRechnung 3.0.2 · arithmétique |
| EN 16931 | UBL 2.1 ou CII D16B | XML | XSD · Schematron EN 16931 1.3.17 · arithmétique |
| Peppol BIS Billing 3 | UBL 2.1 | XML | XSD · EN 16931 · règles Peppol BIS 3 · arithmétique |
| ZUGFeRD 2.x / Factur-X — EN 16931, EXTENDED, XRECHNUNG | CII D16B | PDF/A-3 hybride ou XML seul | XSD · Schematron EN 16931 1.3.17 · arithmétique |
| ZUGFeRD 2.x / Factur-X — BASIC, BASIC WL, MINIMUM | CII D16B | PDF/A-3 hybride ou XML seul | XSD · règles de profil Factur-X 1.09.2 (FX-SCH) · arithmétique (les règles de base EN 16931 ne s'appliquent pas sous le profil EN 16931) |
| ZUGFeRD 1.0 | CII (CrossIndustryDocument 1p0) | PDF/A-3 hybride ou XML seul | Schéma · arithmétique |
| FatturaPA 1.2 | FatturaPA | XML | XSD FatturaPA 1.2.2 · arithmétique (fichiers multi-corps renvoyés en lot) |
| KSeF FA(2) / FA(3) | Schéma FA | XML | XSD FA(2) / FA(3) · arithmétique |
| France — CTC-FR (vendeur et acheteur établis en France) | UBL 2.1 ou CII D16B | XML ou PDF Factur-X | XSD · EN 16931 · FNFE CTC-FR 1.4.0.04 (règles BR-FR, Flux 2) · arithmétique |
| RO e-Factura (CIUS-RO) | UBL 2.1 | XML | XSD · CIUS-RO 1.0.1, qui intègre déjà les règles EN 16931 · arithmétique |
| Émirats arabes unis — PINT AE (Billing, Self-Billing) | UBL 2.1 | XML | XSD · OpenPeppol PINT AE 1.0.4 (règles PINT communes + règles émiraties) · page de vérification gratuite (EN) |
Les versions des règles sont aussi listées en direct sur GET /v1/formats. Il manque un format que vous recevez ? Dites-le-nous.
Conçu pour les équipes qui doivent désormais recevoir ces factures.
Recevoir des factures structurées n'est plus optionnel : Allemagne depuis le 1er janvier 2025, Belgique via Peppol depuis janvier 2026, KSeF en Pologne pour le B2B depuis le 1er avril 2026, France pour toutes les entreprises depuis le 1er septembre 2026. Le côté réception a besoin d'un parser, d'un validateur et d'un moyen de montrer la facture à un humain — c'est tout le produit.
SaaS de comptabilité fournisseurs
Vos clients vous transmettent ce que leurs fournisseurs envoient. Un endpoint transforme six syntaxes en un seul JSON que votre flux de rapprochement et d'approbation comprend déjà — plus une indication à transmettre au fournisseur quand son fichier est incorrect.
Plugins ERP & e-commerce
Dolibarr, InvoicePlane, Sylius, Shopware, Odoo — un plugin capable de lire les Factur-X et XRechnung reçues est une fonctionnalité livrable dans ce sprint, au lieu d'un projet de parser de six mois. Pas de Java, pas de chaîne d'outils Schematron dans votre build.
Agences qui outillent des PME
Vos petits clients en France, en Belgique, en Allemagne, en Italie et en Pologne reçoivent des factures électroniques et vous demandent quoi en faire. Valider, afficher, exporter en CSV ou DATEV — et renvoyer le rejet à l'émetteur avec le champ exact à corriger.
Trois lignes jusqu'à votre première lecture.
Envoyez le fichier comme champ multipart file ou comme corps brut XML/PDF. Authentifiez-vous avec Authorization: Bearer <key> ou X-Api-Key. Sans clé, vous disposez du quota démo : 20 factures par IP et par jour.
curl -X POST "https://invoicein-api.peculiar.systems/v1/invoice?include=validation&lang=en" \
-H "Authorization: Bearer $INVOICEIN_KEY" \
-F "[email protected]"import { readFile } from "node:fs/promises";
const form = new FormData();
form.append("file", new Blob([await readFile("invoice.xml")]), "invoice.xml");
const res = await fetch("https://invoicein-api.peculiar.systems/v1/invoice?include=validation,datev&lang=de", {
method: "POST",
headers: { Authorization: `Bearer ${process.env.INVOICEIN_KEY}` },
body: form,
});
const data = await res.json();
if (!data.ok) throw new Error(`${data.error.code}: ${data.error.message}`);
console.log(data.invoice.totals); // { net, tax, gross, due, … }
console.log(data.validation.issues); // [{ id, severity, hint, field, who }]import os, requests
r = requests.post(
"https://invoicein-api.peculiar.systems/v1/invoice",
params={"include": "validation,pdf", "lang": "en"},
headers={"X-Api-Key": os.environ["INVOICEIN_KEY"]},
files={"file": open("invoice.pdf", "rb")},
timeout=30,
)
data = r.json()
if not data["ok"]:
raise SystemExit(f'{data["error"]["code"]}: {data["error"]["message"]}')
print(data["source"]["format"], data["source"]["profile"])
print(data["validation"]["valid"], data["validation"]["errors"], "errors")Exemple de réponse (abrégé)
{
"ok": true,
"source": {
"format": "xrechnung-ubl",
"syntax": "UBL",
"profile": "XRechnung 3.0",
"container": "xml"
},
"invoice": {
"document": {
"id": "RE-2026-0421",
"issue_date": "2026-08-30",
"type_code": "380",
"currency": "EUR",
"buyer_reference": "04011000-12345-03"
},
"seller": {
"name": "Nordlicht Werkstatt GmbH",
"vat_id": "DE123456789",
"electronic_address": { "value": "[email protected]", "scheme": "EM" },
"address": { "line1": "Kanalstraße 12", "city": "Kiel", "postcode": "24103", "country": "DE" }
},
"buyer": { "name": "Beispiel Bau AG", "address": { "city": "Hamburg", "country": "DE" } },
"payment": {
"means_code": "58",
"credit_transfers": [{ "iban": "DE02120300000000202051" }]
},
"totals": { "line_net": 314.86, "net": 314.86, "tax": 22.04, "gross": 336.09, "due": 336.09 },
"tax_breakdown": [{ "category": "S", "rate": 7, "taxable": 314.86, "tax": 22.04 }],
"lines": [
{ "id": "1", "quantity": 3.5, "unit": "HUR", "net_amount": 314.86,
"price": { "amount": 89.96 }, "tax": { "category": "S", "rate": 7 },
"item": { "name": "Wartung Lüftungsanlage" } }
],
"extensions": {}
},
"validation": {
"valid": false,
"errors": 1,
"warnings": 0,
"rule_sets": [
{ "id": "EN16931-UBL", "version": "EN 16931 validation artefacts 1.3.17" },
{ "id": "XRechnung-UBL", "version": "XRechnung 3.0.2 Schematron 2.6.0" }
],
"issues": [
{
"id": "BR-CO-15",
"severity": "error",
"rule_set": "EN16931-UBL",
"message": "[BR-CO-15]-Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110).",
"hint": "Le total TTC (BT-112) doit être égal au total HT (BT-109) plus le total de TVA (BT-110). 314.86 + 22.04 = 336.90, mais le document indique 336.09 — l'émetteur a arrondi ses totaux indépendamment des lignes.",
"field": "totals.gross (BT-112)",
"who": "sender"
}
]
},
"timings_ms": { "detect": 1.2, "map": 3.8, "validate": 18.1, "total": 23.4 }
}Endpoints
- POST /v1/invoice
- Tout en un seul JSON.
?include=validation,html,pdf,csv,datev&lang=en|de|fr|it|pl - POST /v1/validate
- Rapport seul.
- POST /v1/parse
- JSON canonique seul, sans validation.
- POST /v1/render.html
- HTML lisible par un humain.
- POST /v1/render.pdf
- PDF A4 lisible par un humain.
- POST /v1/export.csv
- CSV à plat.
?level=lines|documents - POST /v1/export.datev
- Lot d'écritures DATEV (Buchungsstapel).
?skr=03|04&creditor_account=70000 - GET /v1/formats
- Formats d'entrée pris en charge et versions des jeux de règles.
- GET /v1/rules/{id}
- Explique un identifiant de règle en langage clair.
?lang=de - GET /v1/countries
- Quel format impose l'obligation de chaque pays, et avec quoi nous le validons.
- GET /v1/vat/{number}
- Vérifie un numéro de TVA intracommunautaire : format hors ligne, puis VIES en direct, avec un justificatif daté.
- GET /v1/peppol/{id}
- Un partenaire est-il publié sur Peppol, et que peut-il recevoir.
- GET /docs
- Référence OpenAPI.
- MCP /mcp
- Serveur MCP distant ; build stdio local sur demande.
Les erreurs reviennent sous la forme {"ok": false, "error": {"code", "message", "hint"}} avec le statut HTTP correspondant. Les crédits restants sont indiqués dans l'en-tête X-Credits-Remaining.
Payez par document. Les crédits achetés n'expirent jamais.
Une facture = un crédit, quelles que soient les sorties demandées dans l'appel ; un fichier contenant plusieurs factures coûte un crédit par facture. Pas de minimum mensuel, pas de licences par utilisateur.
Avec votre première clé, valables 30 jours. Sans carte. De quoi câbler l'intégration et la tester sur de vrais fichiers fournisseurs.
Pour un plugin en production avec une poignée de clients.
La tranche habituelle pour un outil de comptabilité fournisseurs ou une agence qui gère plusieurs clients.
Volumes plus élevés et images on-premise sur facture — contactez-nous.
Prix hors TVA. Paiement sur facture ou par lien de paiement ; le paiement en libre-service arrive. Facture sur demande pour les volumes plus élevés. Le quota démo (20 factures par IP et par jour) ne nécessite aucune clé.
Demander une clé.
Laissez votre e-mail et, si vous le souhaitez, ce que vous recevez. Nous répondons avec une clé et, pour les offres payantes, la facture ou le lien de paiement.
Les résultats de validation décrivent ce que les jeux de règles officiels disent d'un fichier. Ils ne constituent ni un conseil juridique ou fiscal ni une garantie de conformité, et aucun contrôle automatisé ne peut certifier qu'un document sera accepté par une administration fiscale, une PDP ou un acheteur.
Réponses courtes.
Est-ce une PDP ou un point d'accès Peppol ?
Stockez-vous mes factures ?
Quelles versions des règles utilisez-vous ?
- Artefacts de validation EN 16931 1.3.17 (Schematron UBL et CII)
- XRechnung 3.0.2 — Schematron KoSIT 2.6.0 (UBL et CII)
- Règles Peppol BIS Billing 3.0, master courant
- Profil de transition FNFE CTC-FR 1.4.0.04 (règles BR-FR, Flux 2) — appliqué quand le vendeur et l'acheteur sont tous deux établis en France
- CIUS-RO 1.0.1 (ro16931-ubl-1.0.9) — le verdict et la formulation correspondent à ce que renvoie le SPV de l'ANAF
- Conventions de marché qu'aucun Schematron ne lit : conditions d'escompte allemandes (Skonto) en texte libre, et le numéro KSeF polonais (
?ksef=) - XSD UBL 2.1 · XSD CII D16B · XSD FatturaPA 1.2.2 · XSD KSeF FA(2) et FA(3)
- Contrôles arithmétiques croisés (sommes des lignes, TVA par catégorie, totaux) sur tous les formats
Chaque réponse nomme les versions utilisées : validation.rule_sets dans le corps et l'en-tête X-Invoicein-Rulesets. Les changements sont datés sur /rules/changelog (flux Atom) et GET /v1/rulesets ; tout identifiant de règle peut être expliqué via GET /v1/rules/{id}?lang=fr.
Et Factur-X BASIC et MINIMUM ?
coverage: schema.