New endpoints, tools and validation improvements, plus the compliance updates that ship
automatically on their legal effective dates, so your integration never has to chase them.
Changed
PDFs without embedded XML (errorCode 4006) now use the standard errors array
When a PDF sent to POST /v1/extract/xml, /v1/extract/json or /v1/extract/attachments carries no embedded invoice XML, the 400 response with errorCode 4006 now reports the problem in the same errors array every other error uses: a single finding with the rule PDF-EMBED, a message, and the same layer, line, btCodes, fields and raw fields as any validation finding. Previously errors was an object holding an xml list and a friendly list. If your code reads errors.friendly or errors.xml on a 4006 response, read errors[0].message instead. Code that only branches on errorCode 4006, for example to fall back to POST /v1/parse/json, keeps working unchanged. The 4006 responses of /v1/convert/facturx/to/* and /v1/convert/zugferd/to/* now carry the same finding and valid: false as well, and every finding returned by the /v1/validate/* endpoints now includes all seven fields, with layer set to null for the PDF embedding findings instead of being left out.
New
XRechnung inside a ZUGFeRD PDF: the XRECHNUNG profile on /v1/create/zugferd
POST /v1/create/zugferd now supports the XRECHNUNG reference profile, the sixth ZUGFeRD profile introduced with version 2.2 for invoices to German public-sector buyers who accept a readable PDF alongside the structured data. Set invoice.specificationId to urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0 and the PDF/A-3 embeds a complete XRechnung in CII syntax, attached as xrechnung.xml with the matching XRECHNUNG conformance level in the PDF metadata, exactly as the ZUGFeRD specification prescribes. Before delivery the XML is validated against EN 16931 and the German KoSIT rule set, the same checks POST /v1/create/xrechnung runs, so the XRechnung requirements apply: the Leitweg-ID in buyerReference, a seller contact with name, phone and email, and electronic addresses for seller and buyer (the buyer's is filled in from the Leitweg-ID when omitted). Everything else is unchanged: without a specificationId the endpoint keeps producing the EN 16931 profile exactly as before, the other profile URNs behave as they always did, and the rendered page, options.pdfUrl, options.language, branding and logo work the same way for every profile.
Improved
options.language now words every text the API adds to your XML
options.language applies to every create endpoint, not only to the rendered PDF of a hybrid. Set it to de or fr on POST /v1/create/cii, /v1/create/ubl, /v1/create/xrechnung, /v1/create/facturx or /v1/create/zugferd and every text the API fills in on your behalf is written in that language. The payment terms (BT-20) added when you supply none now follow it in every case, including credit notes and invoices that are already settled, which previously kept the English wording. New: the VAT exemption reason (BT-120) added to a reverse charge, intra-Community, export or out-of-scope breakdown that carries none is translated as well, so a French invoice reads "Autoliquidation" and a German one "Steuerschuldnerschaft des Leistungsempfängers" instead of "Reverse charge". Your own paymentTerms and exemptionReasonText always take precedence, English remains the default, and no rule, profile, code or structure is affected.
Improved
Clearer default payment terms when no due date is given
The payment due date (BT-9) stays optional on every create endpoint, but EN 16931 rule BR-CO-25 requires either a due date or a payment terms text whenever an amount is due. The API has always filled in the payment terms for you in that case; the wording is now "Payable on receipt of this invoice" instead of the bare "Payment due", the conventional reading of an invoice that names no deadline, and CII output now echoes a supplied due date as "Due by YYYY-MM-DD" exactly as UBL already did. The sentence follows options.language, so a German invoice reads "Zahlbar bei Erhalt dieser Rechnung" and a French one "Payable à réception de cette facture", with the due date formatted the local way. The rendered PDF of a hybrid invoice prints the same terms in its payment block, so the visual page and the embedded XML always agree, and the payment means description next to it (credit transfer, SEPA direct debit and the other curated codes) is now translated with the rest of the page instead of staying English. Invoices that provide their own paymentTerms text are untouched, and credit notes or fully settled invoices print nothing extra. No rule, profile or structure is affected.
New
French mandate rules before embedding: rules=br-fr on /v1/embed/facturx
POST /v1/embed/facturx now accepts the same optional rules form field as the validate and create endpoints. Pass rules=br-fr and the uploaded CII XML is checked against the French CTC mandate's BR-FR Flux 2 rules, the same rule set the Plateformes Agréées and the PPF apply to every domestic French invoice, on top of the rule set its declared profile selects, before the hybrid PDF/A-3 is produced. Mandate violations are returned as the familiar structured findings with rule ids starting with BR-FR, so the XML is fixed on your side rather than at the recipient's platform. The declared profile is never changed, the header-only MINIMUM and BASIC WL profiles are rejected with a clear 400, and the field cannot be combined with skipValidation, which runs no business rules. It is offered on the Factur-X route only; /v1/embed/zugferd rejects the field rather than silently skipping the check.
New
Your logo on the rendered PDF: options.logoUrl
The built-in PDF template can now carry your logo. Set options.logoUrl to the public URL of a PNG or JPEG (up to 2 MB) on POST /v1/create/facturx, /v1/create/zugferd and /v1/create/order-x, or pass the logoUrl form field on the /v1/render endpoints, and the logo is printed top-left of the invoice while the document title and dates move to the right, the classic letterhead layout. The image is scaled to fit, aspect ratio preserved, and is fetched with the same protections as pdfUrl, then decoded and re-encoded on our side so only the pixels ever reach the PDF. Together with options.brandColor this gives a fully branded invoice from JSON alone; when pdfUrl supplies your own PDF, logoUrl is ignored like the other template options. Documents without a logo render exactly as before.
New
French mandate rules on demand: rules=br-fr
You can now run the French CTC mandate's BR-FR Flux 2 rules, the same rule set the Plateformes Agréées and the PPF apply to every domestic French invoice, on top of any declared profile. On POST /v1/create/facturx, /v1/create/cii and /v1/create/ubl, set options.rules to ["br-fr"] and the generated invoice is additionally checked against the mandate before delivery; on POST /v1/validate/facturx, /v1/validate/cii and /v1/validate/ubl, and their /report siblings, pass the rules=br-fr form field to do the same for an existing file. The declared specification identifier (BT-24) is never changed and the profile's own validation runs unchanged; the mandate findings simply appear alongside, with rule ids starting with BR-FR. Documents declaring the EXTENDED-CTC-FR profile already carry these rules and never run them twice, the header-only MINIMUM and BASIC WL profiles are rejected with a clear 400 (the mandate reads them as booking aids, not invoices), and an unknown rules value is rejected rather than skipped, so a requested compliance check never silently fails to run.
Compliance
Peppol PINT Billing 1.1.3 and French CTC rules 1.4.0.04
PINT validation now runs Peppol PINT Billing 1.1.3, the current release on the network since 8 June 2026: rule IBR-SR-45 was removed, the code lists were refreshed with new EAS and ICD entries, and the ISO 4217 currency list adds XCG and drops ANG and BGN. The French CTC rule sets moved to release 1.4.0.04, which adds the EN 16931 alignment rules CII-SR-467 to CII-SR-494 and corrects rounding in the amount checks by calculating in exact decimals. The MINIMUM and BASIC profiles now run the Factur-X 1.0.9.2 / ZUGFeRD 2.5.2 artifacts as well, so every Factur-X and ZUGFeRD profile validates against the same release. Generated documents are unchanged and existing invoices keep validating exactly as before; the only visible difference is that a few finding identifiers may carry new names.
Compliance
KoSIT XRechnung Schematron 2.6.0
XRechnung validation and creation now run the KoSIT Schematron 2.6.0 for specification 3.0, the Summer 2026 bugfix bundle, in both CII and UBL. The notable change is BR-TMP-2, which is now fatal: the external document location of a supporting document (BT-124) must be an absolute URL with a scheme, so a relative path that passed under 2.5.0 is rejected, exactly as the German reception portals reject it. New warnings BR-TMP-4 to BR-TMP-7 report duplicate attachment descriptions or files and dates written in a format other than YYYYMMDD with format 102 in CII or YYYY-MM-DD in UBL; KoSIT has announced these become fatal in a later release, and every document the API generates already satisfies them. Every finding carries the usual rule id and a plain-English message, and generated documents are unchanged.
Compliance
Peppol BIS Billing 3.0.21 and SI-UBL 2.0.3.13
Peppol validation moved to BIS Billing 3.0.21, the May 2026 release mandatory on the network from this date: the Danish identifier checks PEPPOL-COMMON-R052 and R053 are now errors, Dutch KVK, OIN and establishment identifiers are checked for format as warnings (PEPPOL-COMMON-R054 to R057), and the type code rules recognise the new billing-with-response process. NLCIUS validation runs SI-UBL 2.0.3.13 from the Dutch Peppol Authority, mandatory from the same date, whose only change is the embedded EN 16931 rules moving to 1.3.16, the version the other UBL pipelines already used. Every finding carries the usual rule id and a plain-English message, and generated documents are unchanged.
Compliance
Factur-X 1.0.9.2 / ZUGFeRD 2.5.2
Validation now runs the official Factur-X 1.0.9.2 / ZUGFeRD 2.5.2 corrigendum artifacts, published on 4 August 2026 and effective 1 September 2026, adopted ahead of the deadline. The corrigendum cleans up the EXTENDED profile features introduced with version 2.5: line VAT category information became optional for the new line subtypes, the VAT breakdown rules now permit more than one breakdown per category, and a rounding inconsistency in the line total check was corrected. The French CTC rule sets moved to the matching 1.4.0.03 release. Generated documents are unchanged and existing invoices keep validating exactly as before; the only visible difference is that a few upstream finding identifiers carry new names, such as CII-SR-470 replacing BR-CO-27.
Changed
XRechnung output is now UBL by default
Every route that produces an XRechnung document now emits the UBL syntax by default: POST /v1/create/xrechnung, /v1/transform/to/xrechnung, /v1/convert/ubl/to/xrechnung, and /v1/convert/cii/to/xrechnung previously returned the CII binding. Both bindings are legally equivalent XRechnung, carry the same specification identifier (BT-24), and pass the same KoSIT rule set before delivery; UBL is the syntax German receivers see most in practice. On POST /v1/create/xrechnung the new options.syntax field selects the binding explicitly: ubl (the default) or cii. The options.version field was removed from the same endpoint; the API always produces the specification version currently in force and switches on the authority's effective date, announced ahead of time. Validation is unaffected, the syntax is auto-detected as always.
New
Coded invoice notes and the French CTC profile on /create
Invoice notes now carry the EN 16931 subject code (BT-21): each notes entry is either a plain string, exactly as before, or an object like { "subjectCode": "PMT", "note": "..." }. The coded form is emitted natively in CII and with the standard #CODE# convention in UBL, and it unlocks the French CTC mandate's mandatory mentions (PMT recovery costs, PMD late-payment penalties, AAB discount terms). With that in place, POST /v1/create/facturx and /v1/create/zugferd generate compliant EXTENDED-CTC-FR hybrids end to end when the declared profile carries the mandate's content: SIREN legal registrations, the billing-mode identifier in businessProcessType, French VAT rates, and the coded mentions, all validated against the official FNFE-MPE rule set before delivery. The delivery location identifier also gained its scheme (BT-71-1, e.g. 0009 for a SIRET). If your workflow needs a property you do not find in the schema, contact us and we will add it.
New
MINIMUM and BASIC WL profiles on the create endpoints
Declaring a header-only profile (specificationId urn:factur-x.eu:1p0:minimum or :basicwl, or their zugferd.de 2p0 equivalents) on POST /v1/create/facturx, /v1/create/zugferd, the /v1/convert routes ending in a hybrid, or /v1/transform/to/facturx and /to/zugferd now produces a compliant hybrid whose embedded XML is exactly the profile's official subset, validated against the profile's schema and rules before delivery. These profiles are booking aids in which the PDF is the legal invoice: your line items still render on the PDF and drive the totals, while the XML carries the header data the profile defines. Line items therefore remain required input, header totals are checked for internal consistency since the XML no longer carries the line evidence, and a case variant of an official profile identifier is normalised to the spec-exact spelling instead of failing downstream. The same applies to declared profiles on POST /v1/create/cii, whose output previously carried full content under a header-only identifier without validating against the declared profile's schema. Documents without a specificationId keep the EN 16931 default, unchanged.
Improved
Hybrid PDF conformance verified with veraPDF
Every hybrid container the API produces is now checked against veraPDF, the reference PDF/A validator: all nineteen accepted profile identifiers, on both the Factur-X and ZUGFeRD endpoints, for PDFs we render and PDFs you upload, plus the Order-X outputs, validate as PDF/A-3B. Two refinements ship with it: the embedded attachment's checksum is written in the exact form ISO 32000 prescribes, so recipient systems that verify attachment integrity now match it, and the colour profile every hybrid carries is compressed, making each response smaller.
Improved
Invoices are validated before embedding
POST /v1/embed/facturx and /v1/embed/zugferd now validate the uploaded XML with the full rule set of the matching validation endpoint (the declared profile's official schema plus the Schematron business rules) before packaging it. A rule violation returns the familiar structured findings list instead of a hybrid PDF that would bounce at the buyer's portal, so errors are caught on your side of the exchange. Warnings never block, and the new skipValidation=true form field keeps packaging-only behaviour available when you need it.
Improved
Hybrid PDF engine upgrades
Any UN/ECE unit-of-measure (BT-130) or payment-means (BT-81) code is now carried into ZUGFeRD PDFs exactly as sent; the previous unsupported-code rejection is gone. The XRechnung reference profile is now embedded under its spec-mandated attachment name xrechnung.xml with the matching CIUS version in the PDF metadata, and every hybrid output is a PDF 1.7 based PDF/A-3b container across both the Factur-X and ZUGFeRD endpoints.
Compliance
EXTENDED-CTC-FR: the French CTC mandate profile
Full support for the Factur-X EXTENDED-CTC-FR reference profile introduced for the French B2B e-invoicing mandate. Validation runs the official FNFE-MPE artifacts (the profile rules plus the BR-FR Flux 2 mandate rules), and both embed endpoints accept the profile's BT-24 identifier and stamp the EXTENDED conformance level the specification prescribes for it.
Improved
Hybrid validation matches recipient validators
Factur-X and ZUGFeRD validation now checks EN 16931 and XRechnung documents against the official profile schema, which is stricter about element placement than the generic CII schema, matching what receiving-side validators enforce. A Specification identifier (BT-24) outside the official profile list is a clear, actionable error on the hybrid endpoints, while standalone CII validation keeps treating it as an open identifier with an advisory warning.
Improved
Unified invoice JSON envelope
POST /v1/extract/json and /v1/parse/json now return the invoice wrapped in an { "invoice": ... } envelope that mirrors the /v1/create request shape, so extracted data can be fed straight back into create without remapping. AI-parsed responses additionally carry a confidence block; deterministic extraction omits it.
New endpoint
Download invoice attachments as a ZIP
POST /v1/extract/attachments pulls the embedded supporting documents (BG-24) out of a UBL, CII, XRechnung, Factur-X, or ZUGFeRD invoice and returns them as a single ZIP download: delivery notes, timesheets, the original order, whatever the sender attached. The attachment bytes are never opened on the server, and documents referenced only by external URI are left for you to fetch.
New
Show the technical details on the PDF
Set includeAdvancedProperties on the Factur-X and ZUGFeRD create endpoints to add an "Electronic invoice details" section to the rendered PDF, listing the technical XML properties a classic invoice layout leaves out: specification and business process identifiers, party identifiers and legal registrations with their scheme codes, electronic addresses, supporting document metadata, and line-level references. Handy when you want the human-readable page to mirror everything in the structured data.
New endpoint
Validation report as a PDF
Every validation can now return a polished PDF report of its findings, styled to match the web viewer, with clickable links from each finding straight to its field reference. Perfect for sharing a compliance check with a colleague or supplier.
Improved
Redesigned invoice PDF
Generated invoice PDFs were reworked to match the clean web viewer layout and typography, so the document you hand to a customer looks the part.
Compliance
Factur-X 1.0.9 / ZUGFeRD 2.5
Updated the Factur-X and ZUGFeRD conformance profiles (MINIMUM, BASIC WL, BASIC, EXTENDED) to the official Factur-X 1.0.9 / ZUGFeRD 2.5 validation artifacts, mandatory from 1 July 2026. Additive and backwards compatible: existing invoices keep validating and no integration changes are required.
New
UBL credit notes
Full credit note support for the UBL syntax on both create and validate, so you can issue and check UBL credit notes the same way you already do invoices.
New
Profile-aware validation
Validation now reads the document's declared CustomizationID and applies the matching rule set automatically: Peppol BIS 3.0, NLCIUS, PINT, and pinned XRechnung versions, each with its own profile rules on top of EN 16931.
New
Bring your own PDF
Pass a pdfUrl to the create endpoints and we embed the compliant XML into your existing PDF instead of rendering ours, so your hybrid Factur-X and ZUGFeRD invoices keep your exact design.
Improved
Richer invoice model
Added preceding invoice references, invoicing periods, and delivery details (BG-3, BG-14, BG-26), plus full ISO country and currency code coverage across every format.
New
Detailed validation report
Validation results are returned as a structured, BT-coded report: every finding maps to its exact EN 16931 business term, so you know precisely which field to fix rather than deciphering a raw rule id.
New tool
Embed, parse and extract
New endpoints to embed structured CII XML into a PDF/A-3 hybrid, parse an invoice back into JSON, and extract clean invoice data from an existing PDF or XML, making it easy to move between formats.
New
Multi-language invoice PDFs
Rendered invoice PDFs are available in English, German, and French, with the layout and labels localised for each language.
and 67 more updates…
We and our partners use cookies to deliver our services and to understand how our website is used.
By using our website, you agree to the use of cookies as described in our
Privacy Policy.