Attestwire

Look up a French company by SIREN, SIRET or name in INSEE SIRENE open data, for the 2026-2027 French e-invoicing mandate. Confirms the company exists and is active. It CANNOT confirm whether the company has registered with an approved platform — that lives only in the CAPTCHA-protected DGFiP annuaire, which has no open API — and the result says so. FREE and needs no API key.

Current availability of VIES, the European Commission service that validates EU VAT numbers. Per-member-state status, latency and 24h/7d uptime, from a monitor that polls all member states every 5 minutes. Use this when EU VAT number validation is failing, to tell "their VAT number is wrong" apart from "that member state's VIES endpoint is down". FREE and needs no API key.

Explain one EN 16931 / XRechnung / Peppol BIS rule in plain English: what it requires, why, the business term it constrains, a concrete fix and an example. 270 rules explained — BR-*, BR-CO-*, BR-<category>-*, BR-DE-* and PEPPOL-EN16931-*. That is most, not all, of what the validator checks: a few arithmetic/decimal rules have no write-up yet, and for those it says so and links the rule reference rather than pretending the rule does not exist. FREE and needs no API key.

Generate compliant e-invoice XML from a JSON invoice, in either EN 16931 syntax. Profiles: en16931, xrechnung-ubl, peppol-bis-3, xrechnung-cii, facturx-en16931 — the profile chooses the syntax, and xrechnung-cii and facturx-en16931 come back as CII. The invoice is validated first and generation is refused if it fails, because emitting XML for an invalid invoice produces a file that passes nothing. CREDIT NOTES GENERATE TOO, from the same object: invoiceTypeCode "381" emits a UBL CreditNote document under the UBL profiles and ram:TypeCode 381 under the CII ones, since CII has one document for both. XML ONLY, NEVER A PDF: Factur-X and ZUGFeRD files are CII XML inside a PDF/A-3 container, and this build writes no container, so a facturx-en16931 result is the payload and not a Factur-X document — do not tell the user otherwise. On xrechnung-cii the generator's own FIXTURE documents were run through the official KoSIT validator on release and accepted; on facturx-en16931 they were not, because that profile's BT-24 matches no XRechnung scenario for the validator to judge. Neither is a verdict on the document you just generated — nothing is sent to KoSIT at call time. REQUIRES AN API KEY and costs 1 document.

Return a hosted checkout URL for upgrading an Attestwire key to a paid plan (starter: 2,500 documents/month at $49; scale: 25,000 at $199). THIS DOES NOT BUY ANYTHING. It creates a checkout link and charges nothing; a human must open the link, enter their own card and confirm the recurring charge on the payment provider's page. You cannot complete the purchase and must not report it as completed. Use this when a key has hit its quota or the user asks to upgrade. Costs no documents.

Mint a free Attestwire API key (100 documents/month, no signup flow, no card) so validate_invoice and generate_invoice can be used. THE KEY IS RETURNED ONCE AND CANNOT BE RECOVERED — only its SHA-256 hash is stored — so show it to the user verbatim and tell them to save it before doing anything else. One key per email address.

The official list of Plateformes Agréées (PA, formerly PDP) that DGFiP has approved to transmit invoices under the French e-invoicing mandate, from the published open dataset. Optionally filtered by name or SIREN. FREE and needs no API key.

Validate an invoice against EN 16931 and its national CIUS rule sets (XRechnung UBL/CII, Peppol BIS 3.0, Factur-X). Returns every failure as a "teaching error": the official rule id, the business term (BT-/BG-) it constrains, what the regulation actually requires, and a concrete fix. REQUIRES AN API KEY and costs 1 document against the monthly quota — call issue_api_key first if you do not have one. For explaining a rule id you already have, use explain_rule instead: it is free.

Validate an e-invoice FILE the user already has, in either EN 16931 syntax and of either document type. Reads a UBL 2.1 Invoice, a UBL 2.1 CreditNote or a UN/CEFACT CII CrossIndustryInvoice (which carries invoices and credit notes alike) into the invoice model and runs EN 16931 plus the CIUS rules (XRechnung UBL and CII, Peppol BIS 3) over it, returning the same teaching errors as validate_invoice, plus which syntax it read, the document's BT-24/BT-23 and a list of everything in the file that did not reach the model. Use it when someone says "this invoice was rejected, why?" and hands you a file. Send the file as-is; do not work out the syntax or the document type first, because the tool decides both from the root element and reports what it found in `syntax` and in the invoice model's BT-3. XML ONLY, NOT A PDF: Factur-X and ZUGFeRD are CII XML inside a PDF/A-3 container, and this tool cannot open the container — extract the XML and send that. A PDF is refused with an explanation; do not retry it. A credit note is NOT refused — send it exactly like an invoice. It is a pre-flight, not an authority: a file that passes here can still be rejected by KoSIT or by a receiving platform. REQUIRES AN API KEY and costs 1 document.