Freelancers and small businesses
Create a familiar invoice document while also supplying structured data for automated processing.
Generate a readable invoice PDF with embedded structured CII XML through one REST endpoint.
PDF and XML are derived from the same accepted invoice payload. QuoteCash validates the XML before attachment and returns the result with the generated files.
On success, POST /api/v1/invoices/zugferd returns a base64 PDF with factur-x.xml attached, plus the generated CII XML as a separate response field.
The generated XML is checked through the configured KoSIT-compatible validator. A failed 422 response returns XML and error details for diagnosis, but no send-ready PDF.
Use business-scoped API keys and predictable JSON responses in billing, ERP, agency, and SaaS workflows. The legacy endpoint returns files without storing the invoice.
POST /api/v1/invoices/zugferd maps the accepted JSON payload into generic EN 16931 CII XML, validates that XML, generates the visible PDF, and attaches factur-x.xml. The successful response contains the PDF, XML, validation result, and suggested filename.
The current generator emits the UN/CEFACT CII namespace ending in :100 and the generic guideline identifier urn:cen.eu:en16931:2017. It does not emit a release-specific ZUGFeRD/Factur-X identifier, so QuoteCash does not currently claim conformance with ZUGFeRD 2.5 / Factur-X 1.09.
Validation covers the XML rules executed by the configured service. The final PDF container, PDF/A level, attachment relationship, and XMP metadata are not independently validated. A 422 response contains diagnostic XML and validation details only.
Create a familiar invoice document while also supplying structured data for automated processing.
Add server-side PDF/XML generation and explicit validation outcomes to billing products.
Use one documented response contract and route invalid XML into a controlled correction workflow.
Connect invoice payloads, XML validation, and artifact handling without relying on a manual export screen.
Last reviewed: July 24, 2026
QuoteCash currently creates a PDF with generic EN 16931 CII XML attached. XML validation, PDF/A conformance, and formal support for a specific ZUGFeRD/Factur-X release are separate claims.
The current joint release, ZUGFeRD 2.5 / Factur-X 1.09, is technically identical, uses UN/CEFACT CII D22B, and should be used from July 1, 2026 according to FeRD. It includes dedicated XSD and Schematron artifacts for five profiles.
QuoteCash does not currently use those release-specific artifacts. Its internal xmlbuilder2 generator writes the :100 CII namespace with the generic guideline identifier urn:cen.eu:en16931:2017. The product copy therefore does not name a supported ZUGFeRD release.
The generator produces only its generic EN16931 output, and EN16931 is the default. Other profile values do not change the XML and are rejected by the canonical artifact request.
MINIMUM and BASIC WL would not meet the usual EN-16931-based German B2B e-invoice requirements. QuoteCash does not offer those profiles, BASIC, or EXTENDED. Public-sector and other receivers may additionally require XRechnung, a buyer reference, or a specific portal.
QuoteCash sends generated CII XML to the configured KoSIT-compatible validation service. The exact XSD, Schematron, and code-list versions are controlled by that service and are not versioned in this repository.
Only after XML passes does pdf-lib attach factur-x.xml to the visible PDF. No independent PDF/A-3 validator runs, and the PDF attachment relationship and XMP metadata are not checked. The result must not be marketed as proven PDF/A-3 conformant.
The visible PDF and structured XML must represent the same invoice information. QuoteCash derives both from the same accepted API payload but uses separate transformations, so integration tests should compare totals, tax, parties, payment data, and line items. If a hybrid e-invoice differs, the structured part is decisive under the German guidance.
If XML validation fails, the legacy endpoint returns only XML and error details with status 422; it does not assemble a PDF. Treat that XML as diagnostic, not as a valid invoice. Preserve the successfully transmitted hybrid original unchanged in your retention process; the BMF currently states eight years for VAT invoice retention. This is not legal advice.
This example matches the actual request schema. The legacy endpoint uses EN16931 as its fixed profile and does not store the invoice.
POST /api/v1/invoices/zugferd
Authorization: Bearer <api_key>
Content-Type: application/json
{
"schema_version": "1",
"invoice_number": "RE-2026-2048",
"issue_date": "2026-07-24",
"due_date": "2026-08-07",
"currency": "EUR",
"seller": {
"name": "Muster GmbH",
"vat_id": "DE123456789",
"street": "Musterstraße 1",
"city": "Berlin",
"postal_code": "10115",
"country": "DE",
"email": "rechnung@muster.example",
"phone": "+49 30 123456"
},
"buyer": {
"name": "Kunde GmbH",
"vat_id": "DE987654321",
"street": "Kundenweg 2",
"city": "Hamburg",
"postal_code": "20095",
"country": "DE"
},
"line_items": [
{
"description": "Support package",
"quantity": 10,
"price": 95,
"total": 950,
"vatRate": 19,
"unitCode": "C62"
}
],
"totals": {
"net": 950,
"tax": 180.5,
"gross": 1130.5
},
"payment": {
"iban": "DE02120300000000202051",
"bic": "BYLADEM1001"
}
}