Electronic invoices: ZUGFeRD and XRechnung

edoobox can output structured electronic invoice data. Configure the output method under Settings → Payment systems → Invoice. Agree the required profile and acceptance requirements with the receiving accounts department.

Video tutorials

These videos complement this guide. The spoken language is indicated for each video.

Preview images are loaded directly from this website. Playing a video connects to YouTube, only for the video you select.

A brief overview of electronic invoice output using ZUGFeRD and XRechnung in edoobox.

The May 2025 clip mentions ZUGFeRD 2.3. This guide describes the currently available profiles, requirements and checks by the invoice recipient.

Watch on YouTube

Select current profiles

Selection	Output and notes
ZUGFeRD 2.5 (EN16931)	A currently available hybrid invoice variant consisting of a PDF with embedded structured data.
ZUGFeRD 2.4 (EN16931)	Another available hybrid invoice variant.
ZUGFeRD / XRechnung	PDF output with embedded XML offered in the account. Check the profile actually generated with the recipient.
XRechnung V3	XML only, without a PDF component. In the reviewed interface, this option is only displayed if it is already configured as a profile.

The profile names in the current selection are authoritative. An old screenshot label such as ZUGFeRD V2.3 does not fully reflect today's available options. Do not infer blanket legal compliance for every recipient from a profile name.

Set up electronic output

First check the payee, bank details, invoice number range and due date.
Enable the electronic invoice data exchange section.
Select the required available profile.
Add the commercial register details, management and, where applicable, the seller's tax number. If neither this tax number nor a saved VAT number is present, the interface displays a notice.
Check the customer's billing address; add the VAT number, routing ID and purchase order number where required.
Create a new test invoice and check the actual file in the intended receiving process.

QR invoices and electronic output are mutually exclusive in this configuration: enabling one disables the other. Check both switches after changing the configuration. QR output setup is described under QR invoices.

Check the file before sending

Are the invoice number, date, due date and currency correct?
Are the organisation and invoice recipient details complete?
Are the line items and net, tax and gross amounts correct, including reverse charge?
Does a hybrid PDF actually contain the expected XML?
Can the recipient's specific software process the selected profile?

A visually correct Rechnung.pdf does not confirm that the structured data is complete. If rejected, correct the specified fields and use the designated invoice correction process for documents already issued.

Check line items, XML and the acceptance log together

A freely designed table in Rechnung.pdf does not create additional structured invoice line items. These are generated from the underlying transactions. Therefore check an actual test invoice with a course fee, an additional service and, if used, a partial payment.

Compare the line items in edoobox with those in the generated PDF and XML: description, quantity, amount, tax rate and totals.
For a hybrid invoice, open the embedded XML using suitable invoice software. Simply viewing or printing the PDF does not show this component. If the recipient requires XML only, check the XML output method actually available and the agreed profile.
Compare the seller details, billing address, routing ID or order reference and due date. Check partial payments as payments already taken into account and check the remaining amount.
Have the file checked in the intended receiving process. Keep the acceptance or error log generated there with the invoice number and selected profile for follow-up.
If rejected, correct the specified source, such as the recipient address, transaction or tax assignment. Generate the corrected document through the designated invoicing process and check again.

Checking a Swiss QR invoice and successfully generating a file do not replace an acceptance log from the electronic invoice recipient. A missing line item is not fixed by adding it only as extra text in the PDF.

Original invoice accepted, cancellation document rejected

Check the original and cancellation document as two separate electronic documents. Successful acceptance of the original invoice does not automatically confirm that its cancellation can be processed.

Open the original invoice and its associated cancellation invoice in the invoicing process. Download the actual documents; a table PDF is unsuitable. For hybrid PDFs, also open each embedded XML file.
Compare the visible invoice number, document date and the cancellation's reference to the original invoice number and date. The reference must identify the document actually being cancelled.
Check the document type in the recipient's log. The current edoobox output method identifies a normal invoice as 380 and a cancellation as Correction 384. Clarify with the recipient whether their import supports precisely this correction type in the agreed profile.
Compare quantities, line item totals, tax and overall totals. The correction uses signs opposite to the original values; do not change them manually merely to bypass a rejection. The amount of the cancellation document is also not confirmation of an equal monetary refund.
Keep the error log with both document numbers, profile and file format. Distinguish missing or incorrect document data from an import type that the recipient does not support. Have a reproducible error investigated through the secure support channel, supplying these details and the documents.

Changing text or adding a number in the visible PDF does not change the structured XML references. Make corrections through the designated invoicing process; another payment or cancellation is not a way to repair a file format. The XRechnung document export may include processable saved cancellation documents. Therefore also check the original and cancellation files actually included in the ZIP and the selected period. This does not provide a general guarantee of acceptance by every recipient's software.

Distinguish table exports from document exports

In the invoice table, Export outputs the selected invoice rows as a table. Document export, by contrast, opens Export invoice documents: choose the start and end dates and download the available document output. A table PDF is not a collection of the actual invoice documents.

In this view, PDF document export is prepared in the background and provided in the Secure File Manager. This also applies to small exports. Wait for the response and do not restart a job that is already running.

A combined PDF job includes at most 500 documents; the XRechnung ZIP export includes at most 1,000 records from the selected period. Split large periods and reconcile the document count, invoice numbers and cancellations with the invoice table. The XRechnung ZIP contains only processable documents with saved structured invoice data; externally managed invoices require an export from the system that manages them.

Externally managed invoices

If a connected accounting system manages the document, local PDF and sending actions may be restricted. Open the available provider link and check which system generates the file and invoice correction. For Bexio, see Connection and invoice mode and Synchronisation and error handling.

Check healthcare, insurance and other industry formats

An invoice for a health course or for submission to an insurer may be subject to additional recipient requirements. The ZUGFeRD/XRechnung profiles listed above do not confirm support for a specific insurance, healthcare or tariff format. This profile selection has no separate setting for such an industry format.

Obtain requirements before issuing: Ask the recipient to specify the format name, version, required profile, mandatory details and transmission method. Clarify whether they need a readable PDF, a supplementary sheet, a hybrid invoice or a specific standalone XML structure. Also ask about the intended validation or acceptance procedure.
Map every required detail: Compare the requirements with the available invoice data. Maintain organisation and seller tax details in the account data or invoice settings. Check the name, address, VAT number, routing ID and purchase order number in the billing address. Use these fields according to their meaning; entering an arbitrary value does not automatically map a specific insurance or service identifier correctly.
Distinguish presentation from file structure: If the recipient only needs additional visible details, check the appropriate placeholders and texts in Rechnung.pdf. Such adjustments do not automatically add corresponding XML fields or line items. An additional participant data field is not a freely configurable mapping to an arbitrary XML field either.
Use a supplementary sheet only when the requirement is confirmed: An unchanged document for every recipient using the same template can be sent as a PDF attachment to the invoice email. A background PDF, by contrast, only affects the appearance of the generated document. Neither method creates a new structured invoice format. An individual supplementary sheet must be created through the agreed document process; it should not be included as a shared static attachment in every invoice email.
Clarify special formats with edoobox before use: If a required XML schema, tariff item or specialist identifier is not covered by the available selection and the data actually generated, provide edoobox with the neutral format specification and an anonymised example. Obtain explicit confirmation of the supported output method and any required approvals. Renaming a PDF or adding a free-text field does not imply native support for the special format.
Define an external invoicing process if necessary: If you need another specialist system, first check its suitability and the documented handover method. The existing external invoicing integration is a separate setup workflow, not a promise to support every industry format. Decide which system manages the authoritative document, later corrections and delivery. Do not issue a second invoice document for the same receivable without checking.
Release only after acceptance: Create a neutral test case and have the actual file processed by the intended recipient. If XML is required, check its structure and mandatory details in addition to the visible PDF. Record the acceptance log, selected profile and confirmed process. Also include any electronic correction.

Example – standard profile with an additional order reference: A training provider invoices an organisation for a health course. Its accounts department requires an available XRechnung profile and a purchase order number. The administrator enters the actual order reference in the designated billing address field and checks the generated XML in the receiving process. In this confirmed case, the administrator uses the requested standard profile and records acceptance.

Example – an insurer requires its own specialist format: An insurer specifies a particular XML schema with prescribed service codes and provider identifiers. The administrator does not treat the available standard profiles or a visually adjusted invoice as an equivalent substitute. They clarify with edoobox and the recipient whether a confirmed output method exists or which suitable external specialist system must manage the document. This process is not promised as supported until acceptance is confirmed.

Example: a business customer requires a specific profile

The recipient's accounts department confirms the required profile and mandatory fields. The administrator selects it in the account, completes the invoice recipient details and submits a test document first. The output is only used for that process after successful acceptance.

Further information: Set up invoices, Billing address and Reverse Charge.