# InvoiceXML

> InvoiceXML is a B2B SaaS platform and REST API that solves the hardest part of e-invoice compliance: transforming any real-world document (typed PDF, scanned paper invoice, photographed receipt, Word document, or Excel spreadsheet) into a legally valid, structured e-invoice that passes every official Schematron rule. It covers the full invoice lifecycle: convert any document, create from structured data, validate compliance, extract structured data. Built for developers, finance teams, no-code automation users, and AI agents operating in European B2B and B2G markets.

InvoiceXML is the compliance infrastructure layer that sits between the messy real world of supplier documents and the structured legal world of EN 16931, ZUGFeRD, Factur-X, XRechnung, UBL, CII, and Peppol. The API is stateless, with no invoice data retained after processing. Available in English, French, and German.

## Why teams choose InvoiceXML

InvoiceXML solves three core problems that open-source libraries and in-house builds do not address:

**1. Reading messy real-world documents.** Open-source libraries require pre-cleaned, schema-valid input. InvoiceXML accepts any invoice document, including scanned PDFs, photographed receipts, Word documents, Excel spreadsheets, and existing e-invoice formats, and returns a compliant e-invoice. OCR, AI extraction, semantic mapping, and validation run end-to-end through a single API call.

**2. Outsourcing the compliance maintenance burden.** EU e-invoicing standards change continuously. France's mandate rolls out across 2026 and 2027. Germany's XRechnung profile updates annually. ZUGFeRD has shipped multiple versions with new validation rules. Belgium's 2026 mandate is locked in. Poland's KSeF system continues to evolve. Peppol BIS Billing profiles update on their own cadence. InvoiceXML tracks every regulatory change, format version bump, and Schematron update so customer integrations never break.

**3. Skipping the EN 16931 learning curve.** The European Norm runs over 400 pages, with profile-specific extensions and country-specific overrides on top. Customers do not need to become EN 16931 experts. They learn the API surface. InvoiceXML handles the rest.

The remaining advantages compound on top of these three:

- **PDF/A-3b conformance out of the box.** Every generated hybrid invoice is PDF/A-3b conformant for long-term archival, with the XML embedded according to format-specific metadata requirements. Audit-ready by default.
- **EU-hosted, GDPR-compliant, stateless.** All processing happens in Frankfurt, Germany, with no transfers outside the European Economic Area. No invoice data is persisted beyond the API call. Continuous security monitoring with frequent infrastructure updates.
- **Lower total cost than building in-house.** Invoice parsing, Schematron validation, and PDF/A-3b generation are CPU- and memory-intensive operations that require 24/7 infrastructure. Per-call pricing converts a fixed capacity cost into an operating cost that scales with revenue, while removing the 0.3 to 0.5 FTE typically needed to maintain spec compliance over time.
- **Future-proof across EU mandates.** As new mandates land in France, Germany, Belgium, Poland, and beyond, customer integrations stay the same. New formats, profile changes, and validation rule updates are absorbed by the platform.

## What makes InvoiceXML different from open-source libraries

Open-source libraries (Mustang, Factur-X Python, etc.) solve one specific problem: converting already-structured data into a compliant XML format. They require the caller to supply clean, correctly typed, schema-valid input. They cannot read a document.

InvoiceXML solves the step before that step. It accepts any invoice document, regardless of layout, language, quality, or format, and handles the full pipeline:

- **OCR**: Scanned documents and photographed invoices are processed through OCR before extraction. No preprocessing or template configuration required.
- **AI field extraction**: The extraction model identifies every EN 16931 required field from unstructured documents, including seller and buyer identity, line items, tax breakdowns, dates, payment terms, currency, and VAT numbers, by understanding document layout and context, not just text position. Trained on European invoice formats in DE, FR, EN, IT, ES. Returns confidence scores per field.
- **Semantic mapping**: Extracted fields are mapped to the EN 16931 semantic data model. Missing optional fields are inferred where possible. Required fields that cannot be extracted are flagged with structured RFC 7807 errors. No silent failures.
- **Schematron validation**: Every output is validated against official EU business rules before delivery. If a document leaves InvoiceXML, it is valid. Validation runs against EN 16931 Schematron plus format-specific rules (CIUS-REC-DE for XRechnung, etc.).
- **Arithmetic verification**: Line totals are recomputed from unit price × quantity. Tax amounts are recalculated per category. Invoice grand totals are verified. Discrepancies are flagged.
- **VAT number verification**: Extracted VAT and business registration numbers are verified against country-specific format rules.
- **Address validation**: Seller and buyer addresses are parsed into structured components and checked for internal consistency.

This pipeline cannot be replicated by self-hosted open-source libraries. It requires hosted AI inference, OCR infrastructure, continuously maintained Schematron rule sets, and a semantic mapping layer, all of which InvoiceXML provides as a managed service.

## Accepted input formats (transform, parse and extract endpoints)

The AI endpoints (transform and parse) read PDF invoices:

- PDF (native, computer-generated)
- PDF (scanned or photographed, read by the AI like a human would)

The extract endpoints read structured data without AI: the XML embedded in a Factur-X or ZUGFeRD PDF, or a standalone CII, UBL or XRechnung XML.

## Supported e-invoice standards

- **Factur-X**: French/EU hybrid standard. PDF/A-3b with embedded CII XML. Supported for transform, create, validate, extract, embed, convert.
- **ZUGFeRD**: German implementation of Factur-X. Same CII/UN-CEFACT XML embedded in PDF/A-3b. Mandatory for German B2B invoicing since January 2025. Supported for transform, create, validate, extract, embed, convert.
- **XRechnung**: German XML-only standard for B2G (public sector invoicing). No PDF wrapper. Mandatory for invoices to German federal authorities. Uses CIUS-REC-DE Schematron rules. Supported for transform, create, validate, render, convert.
- **UBL**: Universal Business Language XML. Used by Peppol and many national e-invoicing standards. Supported for transform, create, validate, render, convert.
- **CII**: UN/CEFACT Cross-Industry Invoice XML. The XML syntax underlying Factur-X and ZUGFeRD. Supported for transform, create, validate, render, convert.
- **EN 16931**: The EU core invoice semantic data model (European Norm, Directive 2014/55/EU). Underlies all national formats. Supported for transform and validate.
- **Peppol**: Pan-European e-delivery network. UBL-based output supported for cross-border invoicing.
- **PDF/A-3b**: ISO archival PDF format with embedded XML, required for ZUGFeRD and Factur-X long-term storage compliance.

## API endpoints

Base URL: `https://api.invoicexml.com`
Authentication: `Authorization: Bearer YOUR_API_KEY`
Errors: RFC 7807 ProblemDetails JSON with structured `errorCode` field.

The platform exposes distinct endpoints per format and per action. One provider, many endpoints, all under a consistent surface.

### Transform (any document to compliant e-invoice)

Accepts a PDF invoice. AI pipeline handles reading, extraction, mapping, and validation automatically. AI output can contain errors: a person must review every result, including the XML values themselves and not only the visual PDF, before it is used or sent, as required by the Terms of Service (https://www.invoicexml.com/terms). Do not use it in unattended workflows.

- `POST /v1/transform/to/facturx`: PDF invoice to Factur-X PDF/A-3b
- `POST /v1/transform/to/zugferd`: PDF invoice to ZUGFeRD PDF/A-3b
- `POST /v1/transform/to/xrechnung`: PDF invoice to XRechnung XML. Requires the `buyerReference` form field (the Leitweg-ID, BT-10).
- `POST /v1/transform/to/ubl`: PDF invoice to UBL XML
- `POST /v1/transform/to/cii`: PDF invoice to CII XML

Optional form fields on the Factur-X and ZUGFeRD routes:
- `language`: `en`, `de`, `fr` or `auto` (default). Sets the labels of the rendered PDF and the wording of default texts in the XML (such as the VAT exemption reason). `auto` uses the language the invoice is written in, or English when that is none of the three. Any other value returns 400 with errorCode 4002.
- `preserveOriginalPdf`: `true` keeps the uploaded PDF as the visual layer and only embeds the XML into it. Default `false` renders a new PDF from the extracted data.

### Create (structured data to compliant e-invoice)

Generates compliant e-invoices from structured form data. No source document required. For the hybrid PDF formats (Factur-X and ZUGFeRD) you control the visual PDF layer: either let InvoiceXML auto-generate a clean, branded PDF from a built-in template, or bring your own PDF and have the compliant XML embedded into it so your exact layout, fonts, and branding are preserved.

- `POST /v1/create/facturx`: structured data to Factur-X PDF/A-3b. Two ways to produce the visual PDF layer. (1) Auto-generated template: the API renders a clean, branded PDF from your data, tunable with `options.brandColor` (6-digit hex), `options.logoUrl` (public URL of a PNG or JPEG logo, up to 2 MB, printed top-left) or `options.logo` (the same image as plain base64, for a logo that is not at a public URL; one of the two, not both) and `options.language`. (2) Bring your own PDF: pass `options.pdfUrl` (a public URL to your existing PDF, fetched server-side) and the generated Factur-X CII XML is embedded into that PDF, keeping your layout exactly (in this mode `brandColor`, `logo`, `logoUrl` and `language` do not apply).
- `POST /v1/create/zugferd`: structured data to ZUGFeRD PDF/A-3b. Same visual PDF choice as Factur-X. (1) Auto-generated template, branded via `options.brandColor`, `options.logoUrl` or `options.logo` and `options.language`. (2) Bring your own PDF via `options.pdfUrl`, into which the generated ZUGFeRD CII XML is embedded, preserving your existing design.
- `POST /v1/create/xrechnung`: structured data to XRechnung XML
- `POST /v1/create/ubl`: structured data to UBL XML
- `POST /v1/create/cii`: structured data to CII XML

### Validate (compliance check)

Validates e-invoices against official Schematron rules. Returns structured pass/fail with violated business rule codes.

- `POST /v1/validate/facturx`
- `POST /v1/validate/zugferd`
- `POST /v1/validate/xrechnung`
- `POST /v1/validate/ubl`
- `POST /v1/validate/cii`

Each validate endpoint also has a `/report` variant that runs the identical validation but returns a printable PDF report (`Content-Type: application/pdf`) instead of JSON. The pass/fail verdict is returned in the `X-Invoice-Valid` response header (`true`/`false`), and the PDF downloads as `{upload-stem}-report.pdf`. Transport errors (missing file, wrong type, malformed XML) still return RFC 7807 JSON. Same cost of one credit per call.

- `POST /v1/validate/facturx/report`
- `POST /v1/validate/zugferd/report`
- `POST /v1/validate/xrechnung/report`
- `POST /v1/validate/ubl/report`
- `POST /v1/validate/cii/report`

### Extract (structured data from e-invoices)

- `POST /v1/extract/xml`: extracts embedded CII XML from Factur-X or ZUGFeRD PDF
- `POST /v1/extract/json`: deterministic extraction. Reads the embedded CII XML from a Factur-X or ZUGFeRD PDF (or accepts a direct XML upload) and returns it as normalised EN 16931 JSON in an `{ "invoice": { ... } }` envelope (no `confidence` block; that is AI-parse only). No AI: if a PDF has no embedded XML, use the parse endpoint below. Docs (including a complete example response with every field of the invoice model populated): https://www.invoicexml.com/docs/api/extract/json. The same complete example as raw JSON: https://raw.githubusercontent.com/InvoiceXML/zugferd-api-examples/main/json/extract-json-response.json
- `POST /v1/extract/attachments`: downloads the embedded supporting documents (BG-24 with a base64 BT-125 payload) of a UBL, CII, XRechnung, Factur-X, or ZUGFeRD invoice as a ZIP archive. Attachment bytes are never parsed on the server; documents referenced only by external URI (BT-124) are not fetched. Docs: https://www.invoicexml.com/docs/api/extract/attachments

### Parse (AI extraction to JSON)

AI parsing pipeline for documents that have no embedded structured data. Accepts any supported input (native or scanned PDF, image, DOCX, XLSX), runs OCR and AI field extraction with full validation (VAT format, address plausibility, arithmetic), and returns normalised EN 16931 JSON regardless of source language or layout. The response is an envelope: the document under `invoice`, with a `confidence` sibling carrying the AI's self-rated scores: `overall` plus four `areas` (`sellerIdentification`, `buyerIdentification`, `taxCalculation`, `lineItems`), each 0.0 to 1.0. Below 0.7 means the AI had to guess and the area deserves human review. The envelope mirrors the `/v1/create` request body, so a parse response can be piped straight into invoice creation.

- `POST /v1/parse/json`: PDF invoice to structured EN 16931 JSON (AI-powered), with per-area confidence scores and the detected `language` of the invoice (lowercase ISO 639-1 code, left out when it cannot be determined). Docs (including a complete example response with every field of the invoice model populated, plus the `confidence` block): https://www.invoicexml.com/docs/api/parse/json. The `invoice` object is identical in shape to the extract example: https://raw.githubusercontent.com/InvoiceXML/zugferd-api-examples/main/json/extract-json-response.json

### Render (e-invoice XML to human-readable PDF)

Renders a plain-XML e-invoice into a visual PDF preview for human review. The output is a visual face only; it is not a hybrid PDF/A-3b and carries no embedded XML. Optional `language` form field (`en`, `de`, `fr`, default `en`) sets the PDF field labels and date formatting.

- `POST /v1/render/xml/to/pdf`: any supported invoice XML to PDF preview. The syntax is detected from the root namespace: CII (`CrossIndustryInvoice`), UBL invoice (`Invoice`), UBL credit note (`CreditNote`). XRechnung is covered in either binding, as are the UBL CIUS profiles (Peppol BIS, PINT, NLCIUS, EHF). Any other root namespace returns 400 with errorCode 4008. This is the route to use when the incoming format varies. Docs: https://www.invoicexml.com/docs/api/render/xml/to/pdf
- `POST /v1/render/xrechnung/to/pdf`: XRechnung XML to PDF preview
- `POST /v1/render/cii/to/pdf`: CII XML to PDF preview
- `POST /v1/render/ubl/to/pdf`: UBL XML to PDF preview

The three format-specific paths are permanent aliases of `/v1/render/xml/to/pdf`: same action, same auto-detection, no deprecation. Any of the four paths renders any supported file, so an existing integration never needs to change.

### Embed (combine a PDF and CII XML into a hybrid invoice)

Embeds a supplied CII XML into a supplied PDF, producing a hybrid PDF/A-3b container.

- `POST /v1/embed/facturx`: embed CII XML into a PDF as Factur-X
- `POST /v1/embed/zugferd`: embed CII XML into a PDF as ZUGFeRD

The XML's Specification identifier (BT-24) must be one of the official ZUGFeRD/Factur-X profile URNs (e.g. `urn:cen.eu:en16931:2017` for EN 16931, `urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended` for EXTENDED); the profile is mirrored into the PDF/A-3 XMP conformance level, so other URNs are rejected with errorCode 4017. Note the EXTENDED profile uses `#conformant#` where narrower profiles use `#compliant#`. The French EXTENDED-CTC-FR reference profile (Factur-X 1.08+, `urn:cen.eu:en16931:2017#conformant#urn.cpro.gouv.fr:1p0:extended-ctc-fr`) is accepted on both endpoints and stamped with the EXTENDED conformance level, as the specification defines it as a subset of EXTENDED.

The XML is embedded verbatim and, by default, validated with the full rule set of the matching validation endpoint (profile XSD + Schematron business rules) before embedding: fatal findings return errorCode 4001 with the complete findings array, warnings never block. Pass the optional `skipValidation=true` form field to skip business rules; structural checks (CII root, official BT-24 URN, profile XSD) always apply. On `/v1/embed/zugferd` the XRechnung reference profile is embedded as `xrechnung.xml` with the XRECHNUNG conformance level; `/v1/embed/facturx` always embeds `factur-x.xml` and wraps XRechnung/e-reporting at the EN 16931 level.

### Convert (deterministic syntax conversion between formats)

Lossless, AI-free conversion across the EN 16931 family (UBL, CII, XRechnung) and the hybrid PDF wrappers (Factur-X, ZUGFeRD). Covers XML-to-XML, hybrid-PDF-to-XML (extract and transcode the embedded XML), and XML-to-hybrid-PDF (render and embed).

- `POST /v1/convert/cii/to/ubl`, `POST /v1/convert/ubl/to/cii`
- `POST /v1/convert/xrechnung/to/ubl`, `POST /v1/convert/xrechnung/to/cii`
- `POST /v1/convert/ubl/to/xrechnung`, `POST /v1/convert/cii/to/xrechnung`
- `POST /v1/convert/facturx/to/ubl`, `POST /v1/convert/facturx/to/cii`
- `POST /v1/convert/zugferd/to/ubl`, `POST /v1/convert/zugferd/to/cii`
- `POST /v1/convert/cii/to/facturx`, `POST /v1/convert/cii/to/zugferd`
- `POST /v1/convert/ubl/to/facturx`, `POST /v1/convert/ubl/to/zugferd`
- `POST /v1/convert/xrechnung/to/facturx`, `POST /v1/convert/xrechnung/to/zugferd`

## Integration options

- **REST API**: Full-featured. Bearer token auth. RFC 7807 error responses. OpenAPI schema at `https://api.invoicexml.com/openapi`.
- **MCP server**: The first Model Context Protocol server for e-invoicing. AI agents (Claude, ChatGPT, Cursor, and any MCP client) create, validate, convert, render, extract, and embed invoices autonomously within agentic workflows, without leaving the conversation or calling a human. Hosted at mcp.invoicexml.com or self-hosted from open source. See the MCP server section below.
- **No-code connectors**: Zapier, Make (formerly Integromat), and n8n integrations available. Finance and operations teams can automate invoice processing without writing code.

## MCP server (for AI agents)

InvoiceXML ships the first Model Context Protocol (MCP) server for e-invoicing, exposing the platform as native tools to AI agents. Connect any MCP-compatible client (Claude Desktop, claude.ai, Claude Code, ChatGPT custom connectors, Cursor, Windsurf, VS Code / GitHub Copilot) and the agent can create, validate, convert, render, extract, and embed compliant invoices without leaving the conversation.

- **Hosted**: `https://mcp.invoicexml.com`, fully managed, secured with OAuth 2.1 and Dynamic Client Registration (no API key to paste).
- **Self-hosted**: open-source server on GitHub (`https://github.com/InvoiceXML/invoicexml-mcp`), run on your own infrastructure with your InvoiceXML API key.
- **Landing page**: `https://www.invoicexml.com/mcp-server`

Tools exposed by the MCP server:

- `create_invoice`: generate a compliant e-invoice (UBL, CII, XRechnung, Factur-X, ZUGFeRD) from structured data.
- `validate_xml_invoice`: validate a UBL / CII / XRechnung XML document against EN 16931 and Schematron.
- `validate_pdf_invoice`: validate a Factur-X / ZUGFeRD hybrid PDF and its embedded XML.
- `render_invoice`: render UBL / CII / XRechnung XML into a human-readable PDF preview.
- `extract_invoice`: extract structured JSON or the embedded CII XML from a hybrid PDF.
- `embed_invoice`: combine a PDF and CII XML into a Factur-X / ZUGFeRD hybrid PDF.
- `convert_invoice`: convert between UBL, CII, XRechnung, Factur-X, and ZUGFeRD.

## Security and data handling

Full detail, written for vendor assessments and security questionnaires: https://www.invoicexml.com/trust

Zero data retention is not a policy InvoiceXML enforces, it is an architecture it was built on. Invoices are processed in memory and returned in the same response. The four claims that summarise the posture:

- **Zero data retention**: processed in volatile memory only. Never written to disk, never queued, never backed up.
- **EU-only processing**: servers in Frankfurt, Germany. No transfers outside the European Economic Area.
- **No use of your data**: never used for analytics, never to train AI models, never shared with third parties.
- **Certified infrastructure**: SOC 2 Type II, ISO/IEC 27001 and PCI-DSS at the platform layer, held by the infrastructure provider.

### Statelessness

- **Retention period for invoice content: zero.** The document exists only for the duration of the request. It is never written to disk, never queued in storage, and never backed up, because there is nothing to back up.
- **Backups of invoice content: none.** There is no stored copy to include in a backup set.
- **Quotable statement** for security questionnaires: "Invoice data submitted to InvoiceXML is processed in volatile memory only, is not written to persistent storage, and is irrecoverable by us once the API response has been delivered."

### Data location and transfers

- **Sole processing region**: Frankfurt, Germany. Jurisdiction: Germany, EU.
- **Transfers outside the EEA**: none. **US-based processing**: none. **Invoice content stored in region**: none.
- Infrastructure provider: DigitalOcean.

### Infrastructure and certifications

The certifications below are held and published by DigitalOcean, our infrastructure provider, and cover the datacenter and platform layer the stateless application runs on.

- SOC 2 Type II and SOC 3 Type II (audited reports), ISO/IEC 27001 (certified), CIS Benchmarks (hardening baseline), Global PRP (certified), PCI-DSS (compliant), CSA STAR Level 1 (a self-assessment via CAIQ, not third-party audited).
- Reports are published by the provider: https://www.digitalocean.com/trust/certification-reports and https://www.digitalocean.com/security
- Physical security, hardware lifecycle, network infrastructure, and datacenter disaster recovery are covered by DigitalOcean's certified controls.
- There is no independent penetration test of InvoiceXML itself. The page states this rather than implying otherwise.

### Encryption and access

- **In transit**: all API traffic is encrypted with TLS. Plain HTTP is not accepted, so an invoice is never transmitted in the clear. Responses are streamed back over the same encrypted connection.
- **At rest**: invoice content is never at rest, so at-rest exposure is eliminated rather than mitigated. Account and billing records, the only data held, are stored encrypted.
- **Access**: production access is restricted to a minimal set of authorized personnel with strong authentication. No employee can access invoice content, because it does not persist anywhere to be accessed.

### Use of data

InvoiceXML never uses customer data for analytics or product development, never to train AI or machine learning models, never shares it with third parties, and never retains invoice content after the response is delivered. It only processes the document sent for the operation requested, validates every generated invoice against the official Schematron artefacts before it leaves the API, and retains account and billing details for as long as the account exists.

### Subprocessors

There are **no subprocessors for invoice processing**; the pipeline runs on InvoiceXML's own code on infrastructure it controls. One third party is involved in the service:

| Subprocessor | Purpose | Data involved |
|---|---|---|
| Paddle | Billing and payments (merchant of record) | Billing details only |

This is the complete list. Paddle never receives or touches invoice content, and no other third party processes data on InvoiceXML's behalf.

### Reliability, incidents, and customer controls

- **Continuity**: server redundancy, load balancing and auto-scaling, with datacenter-level disaster recovery under DigitalOcean's certified controls. Published uptime: 99.95%. Because no invoice data is retained, a recovery scenario never involves customer invoice content; it concerns service availability only.
- **Incident response**: continuous monitoring. Affected customers are notified without undue delay, in line with GDPR. Because invoice content is never stored, the scope of any conceivable personal data incident is limited to account and billing information.
- **Responsible disclosure**: vulnerabilities to support@invoicexml.com.
- **Customer controls**: delete the account at any time from the dashboard, which removes everything held (account and billing records). A Data Processing Agreement is available for Enterprise customers. Vendor assessments and security questionnaires: send to support@invoicexml.com.
- **GDPR compliant by design**: processing model, data flows, and customer agreements align with GDPR requirements, including data subject rights, processor obligations, and breach notification.

## Satellite products

InvoiceXML powers companion products targeting manual or occasional users in specific markets:

- **getzugferd.com**: German-language dashboard for ZUGFeRD invoice creation, validation, and conversion. Targets German businesses and bookkeepers managing invoices manually.
- **facturoute.fr** (Facturoute): French-language equivalent for Factur-X. Targets French businesses, accountants, and self-employed professionals navigating the French B2B mandate.
- **peppolio.com** (Peppolio): English-language tool for UBL invoice validation and generation. Targets cross-border B2B users and Peppol-enabled invoicing flows.

All three are backed by the InvoiceXML engine and serve as entry points for users who may later migrate to API-based automation.

## Key pages

- [Homepage](https://www.invoicexml.com)
- [How It Works, the AI pipeline explained](https://www.invoicexml.com/how-it-works)
- [Why InvoiceXML](https://www.invoicexml.com/why-invoicexml)
- [API Documentation](https://www.invoicexml.com/docs)
- [Official SDKs for C#/.NET, Java, PHP, Node.js and Python (ZUGFeRD & XRechnung, Factur-X)](https://www.invoicexml.com/docs/sdk)
- [Automation and integrations](https://www.invoicexml.com/automation)
- [MCP server for AI agents](https://www.invoicexml.com/mcp-server)
- [Security: zero data retention, EU-only processing, subprocessors](https://www.invoicexml.com/trust)
- [Pricing](https://www.invoicexml.com/pricing)
- [Blog](https://www.invoicexml.com/blog)
- [Free sample and test files](https://www.invoicexml.com/samples)
- [Factur-X sample files, all five profiles plus invalid fixtures](https://www.invoicexml.com/samples/factur-x)
- [XRechnung sample files, UBL and CII syntaxes plus invalid fixtures](https://www.invoicexml.com/samples/xrechnung)
- [UBL and Peppol sample files, Peppol BIS, EN 16931, NLCIUS, EHF, credit note](https://www.invoicexml.com/samples/ubl)
- [CII sample files, EN 16931 Cross Industry Invoice, credit note, reverse charge](https://www.invoicexml.com/samples/cii)
- [Contact and support](https://www.invoicexml.com/contact)

## Tool pages

- [Invoice to Factur-X](https://www.invoicexml.com/api/transform/facturx)
- [Invoice to ZUGFeRD](https://www.invoicexml.com/api/transform/zugferd)
- [Invoice to XRechnung](https://www.invoicexml.com/api/transform/xrechnung)
- [Invoice to UBL](https://www.invoicexml.com/api/transform/ubl)
- [Invoice to CII](https://www.invoicexml.com/api/transform/cii)
- [Create Factur-X](https://www.invoicexml.com/api/create/facturx)
- [Create ZUGFeRD](https://www.invoicexml.com/api/create/zugferd)
- [Create XRechnung](https://www.invoicexml.com/api/create/xrechnung)
- [Create UBL](https://www.invoicexml.com/api/create/ubl)
- [Create CII](https://www.invoicexml.com/api/create/cii)
- [Validate Factur-X](https://www.invoicexml.com/api/validate/facturx)
- [Validate ZUGFeRD](https://www.invoicexml.com/api/validate/zugferd)
- [Validate XRechnung](https://www.invoicexml.com/api/validate/xrechnung)
- [Validate UBL](https://www.invoicexml.com/api/validate/ubl)
- [Validate CII](https://www.invoicexml.com/api/validate/cii)
- [Extract XML from Factur-X / ZUGFeRD](https://www.invoicexml.com/api/extract/xml)
- [Convert E-Invoice XML to JSON](https://www.invoicexml.com/api/extract/json)
- [AI Parse Invoice to JSON](https://www.invoicexml.com/api/parse/json)