Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

Factur-X: Generate & Validate E-Invoices

REMOTE · FACTURX.ORVEL.DEV

Validate Factur-X, CII & UBL e-invoices free, no key. Generate compliant invoices from JSON.

0 this week 91 Trust /100

Last scanned (4 hours ago)

Scores higher than 98% of remote servers

Unreachable for 2 days in a row. Last reached 3 Nov 2026.

Category Finance and Payments

Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →

Endpoint Security11
Transport & Reachability0
Schema Quality & AI Usability0
  • Schema not yet verified: we couldn't read the endpoint's schema, or could read only part of its tool list.Unverified
Stability & Change Management0
  • Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
Tool Coverage0
  • Tool coverage not yet verified: we couldn't read the endpoint's tools, or could read only part of the list.Unverified
Tool Safety0
  • Tool safety not yet verified: we couldn't read the endpoint's tools, or could read only part of the list.Unverified
Capabilities0
  • Capabilities not yet verified: we couldn't read the endpoint's capabilities.Unverified

Unverified: 5 categories

Categories scored 0 because we could not verify them: authentication we do not have, an unreachable endpoint, or not enough scan history. We only credit what we can confirm.

Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 4 Nov 26 0
    • Endpoint reachability: reachable → unreachable ▼ security
    • HSTS header: fail → unverified ▼ security
    • Stability: pass → unverified ▼ security
    • Tool safety: pass → unverified ▼ security
    • Authorization: pass → unverified ▼ security
    • TLS certificate: pass → unverified ▼ security
    • Transport: pass → fail ▼ security
    • Schema quality: 100 → unverified ▼ functional
    • Capabilities: pass → unverified ▼ functional
    • Tool coverage: 100 → unverified ▼ functional
  • 13 Oct 26 0
    • The server rewrote its instructions, which are the text every model session reads security
    • Tool “validate_invoice” rewrote its description, which is the text the model reads security
    • Server version: 0.1.22 → 0.1.23 functional
  • 11 Oct 26 0
    • The server rewrote its instructions, which are the text every model session reads security
    • Tool “embed_xml” rewrote its description, which is the text the model reads security
    • Tool “extract_invoice” rewrote its description, which is the text the model reads security
    • Tool “generate_invoice” rewrote its description, which is the text the model reads security
    • Tool “validate_invoice” rewrote its description, which is the text the model reads security
    • New resource “getting_started” functional
    • Server version: 0.1.21 → 0.1.22 functional
  • 9 Oct 26 0
    • The server rewrote its instructions, which are the text every model session reads security
    • Tool “view_invoice_demo” rewrote its description, which is the text the model reads security
    • Server version: 0.1.19 → 0.1.21 functional
  • 3 Oct 26 0
    • Authorization: fail → pass ▲ security
    • First check of Authorization: partial security
    • Stability: 0.97 → pass security
    • Server version: 0.1.18 → 0.1.19 functional
    • Server version: 0.1.17 → 0.1.18 functional
  • 2 Oct 26 0
    • The server rewrote its instructions, which are the text every model session reads security
    • Tool “check_invoice_parties” rewrote its description, which is the text the model reads security
    • Tool “check_party” rewrote its description, which is the text the model reads security
    • Tool “draft_credit_note” rewrote its description, which is the text the model reads security
    • Tool “get_invoice_example” rewrote its description, which is the text the model reads security
    • Tool “validate_invoice” rewrote its description, which is the text the model reads security
    • Tool “view_invoice_demo” rewrote its description, which is the text the model reads security
    • Server version: 0.1.16 → 0.1.17 functional
    • Server version: 0.1.15 → 0.1.16 functional
    • “draft_credit_note” added an optional parameter “credit_lines” cosmetic
    • “get_invoice_example” added an optional parameter “document_type” cosmetic
    • “view_invoice_demo” reworded the description of “sample” cosmetic
    • Tool “check_invoice_parties” changed its title: Check seller and buyer before generating an invoice → Check seller and buyer together cosmetic
    • Tool “check_party” changed its title: Check whether a party is invoice-ready → Check one invoice party cosmetic
    • Tool “draft_credit_note” changed its title: Draft a credit note from an invoice → Draft a full or partial credit note cosmetic
    • Tool “get_invoice_example” changed its title: Get a valid invoice body → Get an invoice or credit-note example cosmetic
    • Tool “validate_invoice” changed its title: Validate e-invoice → Validate your invoice document cosmetic
    • Tool “view_invoice_demo” changed its title: Try free invoice validation or download sample files → Try fixed invoice samples (no document input) cosmetic
  • 30 Sept 26 0
    • The server rewrote its instructions, which are the text every model session reads security
    • Tool “view_invoice_demo” rewrote its description, which is the text the model reads security
    • Server version: 0.1.14 → 0.1.15 functional
    • “view_invoice_demo” added an optional parameter “sample” cosmetic
    • Tool “view_invoice_demo” changed its title: View a free sample invoice and validation report → Try free invoice validation or download sample files cosmetic
  • 29 Sept 26 0
    • The server rewrote its instructions, which are the text every model session reads security
    • Server version: 0.1.13 → 0.1.14 functional
Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 5 Nov 2026 · Probed https://facturx.orvel.dev/mcp

TLS unreached
DNSSEC insecure

Validation of facturx.orvel.dev. — Not signed

Zone DS Keys Algorithms Outcome
. trust_anchor 20326, 38696 8, 8 Verified
dev. present 60074 8 Verified
orvel.dev. absent Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation
Authentication Inconclusive

We could not reach the endpoint well enough to judge its authorisation posture.

Result Inconclusive

Background: How OAuth 2.1 works in the 2026 MCP spec →

Transports 2 probes
Transport URL Outcome Status Location
streamable-http https://facturx.orvel.dev/mcp Unreachable
http (plaintext) http://facturx.orvel.dev/mcp HTTPS enforced
MCP tools · 10 exposed · ~3,526 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
check_invoice_parties ~285

Check a supplied seller AND buyer together, returning combined readiness and separate evidence. Use before generate_invoice; use check_party for one party and validate_invoice for document rules. Each party needs siren, siret or vat; siret wins over siren. French identifiers or country_code=FR require SIREN/SIRET; a French lookup can derive omitted vat. Address fields activate address checks. requester_vat applies to both lookups but cannot replace either party's vat. Roles follow seller/buyer argument names; no invoice lines or full invoice body is needed. Makes at most two EU Verify requests with the caller's plan key; Pro/Scale enable register access. Returns status and parties.seller/buyer, each with status, reasons and available evidence. Only two positive results yield invoice_ready; any not_ready yields not_ready, otherwise inconclusive. Inspect both results: denied plans, invalid input, quotas and outages never establish readiness. No document quota is consumed; upstream limits still apply per lookup. Results may change on retry. No invoice is generated, stored or sent.

NameTypeReqDescription
buyerobjectyesBuyer's registry identifiers and optional checks.
requester_vat––Your VAT number for VIES request evidence.
sellerobjectyesSeller's registry identifiers and optional checks.

Structured output declared, but exposes no named fields.

No examples provided.

check_party ~422

Check exactly one seller or buyer's registry identifiers and readiness through EU Verify. Use to correct one party's identifiers; use check_invoice_parties to check seller and buyer together, or validate_invoice for document rules. Supply siren, siret or vat; siret wins over siren. A SIREN/SIRET, country_code=FR or FR VAT triggers French checks requiring a SIREN/SIRET. Omitted vat can be derived from a successful French lookup; foreign parties normally need explicit VAT. Send address fields with a coherent country_code; requester_vat cannot substitute for the checked party's vat. Sends supplied fields to EU Verify and applicable registers. A Pro/Scale key enables checks; other plans return plan_excluded. No Factur-X document quota is consumed. Returns status, reasons with field pointers and available evidence: invoice_ready is positive, not_ready needs correction, upstream_unavailable is inconclusive and retryable, invalid_input indicates rejected input. Register results and evidence ids may change between calls. No invoice is created or stored.

NameTypeReqDescription
address––Street line; any address, postal_code or city activates address checking.
city––City, checked with the address.
country_code––ISO 3166-1 alpha-2 country code, for example FR or DE.
eori––EORI. Checked only when you send it.
iban––Party IBAN. Checked only when you send it.
postal_code––Postal code, checked with the address.
requester_vat––Your VAT number, so the evidence pack can include a VIES request identifier.
rolestring–Party role recorded in the evidence; defaults to buyer.
siren––9-digit French SIREN, including leading zeros.
siret––14-digit French SIRET, including leading zeros.
vat––Party's EU VAT number, for example FR40732829320.

Structured output declared, but exposes no named fields.

No examples provided.

draft_credit_note ~479

Draft a type-381 credit note from an existing invoice, for all lines or selected quantities. Use to reverse an existing invoice's charges; use get_invoice_example for a synthetic credit-note example. invoice must be the original generate_invoice input object, not extract_invoice output. number and issue_date belong to the new credit note; the original number/date are copied into preceding_invoices. Give number a distinct value and use YYYY-MM-DD dates. due_date replaces the original deadline; omitting it removes that deadline rather than inheriting it. Omit credit_lines to retain all original lines and amounts. Otherwise select distinct 1-based array positions, not line ids: [{"line_index":1,"quantity":"2"}] credits two units of the first line. Omitted lines are excluded; quantities cannot exceed the original. Prices and VAT rates are retained. Selected-line mode clears original totals, prepayments, rounding and paid status for recalculation. Document allowances/charges, or reduced quantities on adjusted lines or overridden net amounts, need explicit allocation: these cases return an error; prepare a credit body for generate_invoice. No prior-credit history is stored: the caller must prevent cumulative credits beyond the original. Keep amounts positive: type 381 expresses the credit. Existing credit notes, a reused invoice number or negative line amounts produce a tool error. Default payment remittance references follow the new number; a custom reference is preserved. Returns invoice, type_code, preceding_invoice and next. Pass the returned invoice to generate_invoice with the original profile to create the document. No key or document quota is needed for drafting; nothing is stored, sent or refunded.

NameTypeReqDescription
credit_lines––Selected original line positions and quantities. Omit for a full credit; an empty list is invalid.
due_date––Optional due date. Omit it to drop the original invoice due date.
invoiceobjectyesThe original invoice object you passed to generate_invoice. Not an extract_invoice result.
issue_datestringyesCredit note issue date, ISO 8601 (YYYY-MM-DD).
numberstringyesCredit note number, different from the invoice number. Max 35 characters: letters, digits, and . _ / -.

Structured output declared, but exposes no named fields.

No examples provided.

embed_xml ~296

Combine a visual PDF you already have with CII XML into one Factur-X PDF/A-3. Use for an existing visual invoice; use generate_invoice to render invoice data or produce UBL. Match the PDF's parties, lines and totals to xml yourself: check examines only XML and cannot detect disagreement with the visible PDF. The embedded profile comes from xml; neither check nor language changes it. language does not translate the PDF. Invalid input or failed rules return a tool error with no file; rule errors include ids. For a findings report use validate_invoice. Success returns a JSON summary (profile, size_bytes, warning count) and a base64 PDF/A-3 resource. Requires a trial, prepaid or subscription allowance via OAuth or key; success consumes one document, errors consume none. Nothing is stored or sent.

NameTypeReqDescription
checkstring–XML validation rules: fr-ctc adds French BR-FR-* to EN 16931; base uses EN 16931 only.
languagestring–Language written in the PDF metadata: fr (default) or en.
pdf_base64stringyesStandard base64 of PDF bytes starting with %PDF-. Not a URL or data-URI.
xmlstringyesUnencoded CII XML text (Factur-X / EN 16931); UBL is not supported.

No output schema declared.

No examples provided.

explain_finding ~227

Turn a validation rule id into the invoice field to change and an example value. Use after validate_invoice or a generate_invoice rule error, not to validate an invoice itself. rule is trimmed and uppercased to select a guide entry. message/json_pointer must come from that same finding: nonempty values override its generic context, but never change the selected fix or example. Omit them to use guide defaults for known rules. Returns rule, known, message, json_pointer, fix and example; known rules also include problem. Selected BR-FR rules and BR-CO-17/BR-CO-26 have guidance. Unknown ids return known=false and example=null with the supplied context, not an error; consult the original finding. No key or document quota is needed; nothing is stored.

NameTypeReqDescription
json_pointer––Original finding's json_pointer field path.
message––Original finding's message text.
rulestringyesValidation rule identifier, for example BR-FR-01 or BR-CO-26.

Structured output declared, but exposes no named fields.

No examples provided.

extract_invoice ~259

Extract invoice parties, dates, lines, totals and VAT as JSON for bookkeeping or matching. Use validate_invoice for compliance; this performs no OCR or recalculation. Supply one source: nonblank xml overrides document_base64 without inspecting it, so omit xml to extract a PDF's attachment. include_xml returns that selected source for archiving or validation, not XML reconstructed from fields. Extracted fields need mapping before use as generate_invoice input. Returns fields and format/profile metadata, plus PDF metadata for PDF input. Missing business values remain null; numeric values are strings. Missing input, invalid base64, malformed/unrecognized XML or a PDF without embedded XML returns a tool error, not an empty extraction. Requires a trial, prepaid or subscription allowance via OAuth or API key; success consumes one operation, errors consume none. Nothing is stored or sent.

NameTypeReqDescription
document_base64––Standard base64 of a Factur-X PDF, CII XML or UBL XML file; no data-URI prefix.
include_xmlboolean–Include source XML text in the result; this can substantially increase response size.
xml––CII or UBL XML as unencoded text.

Structured output declared, but exposes no named fields.

No examples provided.

generate_invoice ~747

Create an EN 16931 e-invoice from structured data: Factur-X PDF/A-3, CII XML, or UBL 2.1 XML. Use when you have the parties, lines and dates and need the document. To revise one, correct the input and regenerate; save and deliver the returned file through your own system. Do not use when you already have a visual PDF and CII XML: call embed_xml. To check a document you did not create here, call validate_invoice; to read one, call extract_invoice. Start invoice from get_invoice_example, replacing sample parties and dates. Leave totals and line net_amount omitted to compute them from quantities, prices, allowances and charges. For ubl-xml, profile must be en16931 or extended-ctc-fr; extended and basicwl are CII/PDF-only. profile selects the XML model while check selects validation rules: use check=base for non-French invoices; changing check does not disable party_check. language and footer_text affect only the visual PDF. Omitted party_check enables registry checks only for extended-ctc-fr; true/false explicitly overrides that default. Enabled checks send party identifiers/address and seller IBAN to EU Verify. A not_ready verdict blocks output with field pointers. Successful checks add evidence ids; registry outages do not block generation and are reported as warnings, not proof of readiness. XSD/business-rule failures return a tool error with rule ids; fix the input and retry. Requires an authenticated trial, prepaid or subscription allowance (OAuth or API key). Each successful result uses one document operation, including repeated calls. Returns a JSON text summary (totals, warnings, evidence) and an embedded resource: base64 PDF or XML text. No invoice is stored or sent to a recipient.

NameTypeReqDescription
checkstring–Rule set the output must pass before it is returned: fr-ctc (default) = EN 16931 + French CTC rules (BR-FR-*), base = EN 16931 only (non-French sellers).
footer_text––Optional text printed in the PDF footer. Omit it for no footer. Ignored for XML-only output.
invoiceobjectyesInvoice data: seller, buyer, lines, dates, payment terms. Amounts are decimal strings ("1200.00"), dates ISO 8601. Totals and the VAT breakdown are computed. Full JSON Schema in the resource facturx:…
languagestring–Language of the visual PDF: fr (default) or en. Ignored when output is cii-xml or ubl-xml.
outputstring–facturx-pdf (default): PDF/A-3 with the visual invoice and CII XML inside, the hybrid file French platforms accept. cii-xml: UN/CEFACT CII XML alone. ubl-xml: UBL 2.1 XML alone.
party_check––Ask EU Verify whether the seller and buyer are invoice-ready before emitting. true checks. false skips. Omit it and extended-ctc-fr checks, other profiles do not. not_ready is a tool error and no fil…
profilestring–EN 16931 conformance level written in the XML: en16931 (default, full semantic model), extended (optional business terms), extended-ctc-fr (French B2B mandate; parties are checked before the file is…

No output schema declared.

No examples provided.

get_invoice_example ~222

Return a complete invoice or credit-note example to edit and pass to generate_invoice. Use this first, instead of inventing fields. No API key is required, and the call does not count as a document. The seller and buyer are sample data: replace them, the number, the dates and the lines before you generate. For credit_note, also replace preceding_invoices with the original invoice reference. To credit a real invoice already in hand, use draft_credit_note instead of this synthetic example. Amounts are positive decimal strings. Nothing is stored, and no file is created. Returns the invoice plus the profile and check to pass to generate_invoice.

NameTypeReqDescription
document_typestring–invoice (default): type 380; credit_note: type 381 with a sample original-invoice reference.
profilestring–en16931 (default) or extended-ctc-fr. The body is the same. extended-ctc-fr sets party_check so generate_invoice asks EU Verify before emitting a file.

Structured output declared, but exposes no named fields.

No examples provided.

validate_invoice ~337

Check a Factur-X PDF, CII XML or UBL XML against EN 16931, and report the fields to fix. Use when the caller supplies a document, including after corrections; use extract_invoice for business data. With no document and only a request to try the product, choose view_invoice_demo instead. Supply one source: nonblank xml overrides document_base64 without inspecting it. To check a PDF's attachment, omit xml. check adds rules to the detected profile; it cannot change that profile. Use base for non-French invoices to avoid French-field findings. Returns validity and findings with rule ids and field pointers for explain_finding. XSD failures skip schematron; inspect checks_skipped before treating validation as complete. Warnings alone do not invalidate an invoice. Rule failures or a PDF without XML return valid=false; missing input, invalid base64, malformed or unrecognized XML return a tool error. Free without a key (shared daily limit, files up to 5 MB). With an OAuth connection or API key, completed reports consume one operation even when invalid; tool errors do not. No invoice is changed, stored or sent.

NameTypeReqDescription
checkstring–fr-ctc: EN 16931 plus French CTC rules (BR-FR-*). base: EN 16931 only.
document_base64––Standard base64 of a Factur-X PDF, CII XML or UBL XML file; no data-URI prefix.
xml––CII or UBL XML as unencoded text.

Structured output declared, but exposes no named fields.

No examples provided.

view_invoice_demo ~252

Demonstrate the engine on bundled synthetic samples only; never checks a user's invoice. Use for product evaluation without a key. To check a supplied document, choose validate_invoice. Choose sample=valid to inspect a passing CII invoice or sample=invalid to see the missing-buyer-name finding. Both use the production XSD and EN 16931 engine; results may be cached for 24 hours for the same engine version and input. Inspect validated_at and cached; a cache hit is not a fresh run. Call with {} to validate the passing sample, or sample=downloads for PDF/CII/UBL files and the published report. Accepts no document data, URLs or extra arguments. No PDF or business-register checks in live mode. Shared rate limits return a retryable tool error; unavailable checks never become a passing result. Use explain_finding for a returned rule id. Your own invoices require validate_invoice with a verified-account trial, prepaid or monthly-plan key. Nothing is stored except reports for these public fixtures.

NameTypeReqDescription
samplestring–valid (default): passing CII invoice; invalid: missing buyer name; downloads: published files.

Structured output declared, but exposes no named fields.

No examples provided.

Install

How do I install the Factur-X: Generate & Validate E-Invoices MCP server?

Factur-X: Generate & Validate E-Invoices is a hosted endpoint at https://facturx.orvel.dev/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

remote · facturx.orvel.dev

# add to Claude Code
claude mcp add --transport http leborgneantoine-facturx 'https://facturx.orvel.dev/mcp'
Common questions

What is the Factur-X: Generate & Validate E-Invoices MCP server?

Factur-X: Generate & Validate E-Invoices is an MCP server listed in the public MCP registry as io.github.LeBorgneAntoine/facturx. Validate Factur-X, CII & UBL e-invoices free, no key. Generate compliant invoices from JSON. This page covers its hosted endpoint (https://facturx.orvel.dev/mcp).

Is the Factur-X: Generate & Validate E-Invoices MCP server safe to use?

Factur-X: Generate & Validate E-Invoices scores 91 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the Factur-X: Generate & Validate E-Invoices MCP server expose?

Factur-X: Generate & Validate E-Invoices exposes 10 tools: view_invoice_demo, generate_invoice, embed_xml, validate_invoice, extract_invoice, and 5 more. Their descriptions and schemas cost roughly 3,526 tokens of context every time the server is loaded.

Does the Factur-X: Generate & Validate E-Invoices MCP server require authentication?

Its publisher declares no required credentials for Factur-X: Generate & Validate E-Invoices. We have not been able to confirm that against the live endpoint, and a server can require authorisation without declaring it here.

Is the Factur-X: Generate & Validate E-Invoices MCP server still maintained?

Factur-X: Generate & Validate E-Invoices is still listed in the MCP registry, though our most recent checks did not reach this channel. We last reached this channel on 3 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.