Invoice formats and conversion: formats, profiles and conversion

Overview of supported formats

faktoora supports a wide range of electronic invoice formats. The right format depends on the type of invoice recipient and on legal or contractual requirements.

ZUGFeRD: profiles and versions

faktoora creates ZUGFeRD invoices with the Extended profile, which offers the greatest functionality. There are two versions:

• ZUGFeRD 1.0 (zf:1:extended): the original version based on the CII standard. It is still supported.
• ZUGFeRD 2.1 (zf:2:extended): the current version according to EN 16931 and the recommendation for new invoices.

The Extended profile is the most complete profile and meets the EN 16931 standard. The message "You can only download as PDF and as XRechnung" means that the selected profile only offers these two formats for download; this is intended for certain configurations and invoice types.

XRechnung and CII/UBL

XRechnung is the German standard e-invoice for public-sector clients. faktoora automatically generates it in the version currently in force. Which version is currently mandatory is determined by the Coordination Office for IT Standards (KoSIT); the binding overview is maintained at xeinkauf.de.

Technically, XRechnung is based on CII (Cross Industry Invoice), not on UBL (Universal Business Language). CII is the XML format preferred by Germany and Austria, while UBL dominates mainly in the Peppol network (Northern Europe, Netherlands).

The two schemas differ in their structure:

• CII: strict, hierarchical structure; used by Germany, Austria and the EN 16931 specification for XRechnung.
• UBL: more modular and open; the standard in the Peppol network.

ZUGFeRD always uses CII, so when you create a ZUGFeRD invoice, the schema option is set to CII (it cannot be selected).

Peppol (UBL) for international B2B invoices

Peppol (Pan-European Public Procurement Online) is a Europe-wide network for structured invoices. faktoora creates Peppol invoices as UBL-based EN 16931 invoices and, with Peppol delivery enabled, can send them automatically via the Peppol network. This is ideal for B2B invoices to European companies that have a Peppol access point.

PDF and format conversion

PDF to electronic format: what is possible and what is not

PDF invoices cannot be converted automatically into an electronic format (XRechnung, ZUGFeRD, etc.). This is because:

1. Structural information is missing: a PDF contains only a visual representation, no structured data.
2. OCR is not reliable: faktoora uses OCR to extract text from scanned invoices (incoming invoices), but OCR cannot guarantee 100% reliable field detection. Recognition therefore serves as an aid, not as complete automation.
3. Data loss: complex information such as tax categories, discounts at line item level or payment terms cannot be reconstructed automatically from a PDF.

Exception: if the PDF is in XRechnung or ZUGFeRD format (i.e. a PDF/A-3 with embedded XML), faktoora can extract the XML and convert it into other formats.

Excel/CSV to electronic format

faktoora does not offer a direct automated import of Excel or CSV for creating e-invoices via the web UI. The API offers ways to pass structured data, but you need to structure the data manually or write an integration script.

Workaround: you can import customer data and products via CSV (see Import contacts, Import products) and then create invoices manually or via the API.

Word to electronic format

A Word file (DOCX) cannot be converted automatically into XRechnung or another e-invoice format. The same restrictions apply as for PDF: the format contains only visual and formal information, not the structured data that an e-invoice format requires.

Procedure: create the invoice directly in faktoora or import the relevant data (customer, line items, taxes) manually.

Foreign invoices and tax numbers

Foreign tax numbers and IBAN

faktoora supports invoices that are not issued by a German company. You can enter a foreign tax number (e.g. Austrian UID, Spanish NIF) and a foreign IBAN in your profile settings, but this must be configured via a contact request or administrator access, because the web UI is preconfigured for German entries.

Formats for other countries

• International: Peppol (UBL) is the standard for Europe-wide B2B e-invoices.
• Spain: Verifactu format for authorities and B2B.
• France: Factur-X for companies; France-PA for public-sector clients (via a Plateforme Agréée).
• Italy: FatturaPA for authorities and B2B transmission via the SdI network.
• Poland: KSeF (FA(3)) for authorities and B2B.

Limitations of electronic invoices

Negative amounts at line item level

In electronic invoice formats (XRechnung, ZUGFeRD, Peppol), negative amounts cannot be entered at line item level. This is a requirement of the EN 16931 standard.

Reason: EN 16931 provides for corrections to be made via separate credit notes (invoice type code 381) or corrected invoices (code 384), not via negative line items in a normal invoice.

Solution: create a credit note (invoice type 381) or a corrected invoice (384) as a separate invoice instead.

Delivery date in ZUGFeRD 2.x

The delivery date (BT-72 in EN 16931) is recorded in the XML data in ZUGFeRD 2.x, but is not visible on the PDF representation by default. You can enable it in the invoice UI so that it is shown in the PDF layout.

Service date without a separate date per line item

For individual invoice line items (e.g. services without a separate delivery date), you can also set a delivery date at product level; this is optional. If you do not set a separate service date or service period for the invoice, the following applies automatically: the service date is the invoice date. This default is also stated as such on the invoice and requires no additional input.

Validation and error handling

Validation errors on export/download

If exporting an invoice as PDF or CSV fails with a validation error, common causes are:

• BT field violation: a field required by EN 16931 is not set or has an invalid format.
• Tax inconsistency: negative tax rates, unsupported tax categories or invalid category combinations.
• Field format: a date is not in the expected format, a phone number contains invalid characters, etc.

Procedure: read the error message carefully; it typically names the affected BT field or the validation rule. Adjust the data and try again.

PDF generation errors with ZUGFeRD

If a ZUGFeRD invoice downloaded as a PDF fails or is not displayed when opened, possible causes are:

• PDF/A-3 conformance: the PDF is not PDF/A-3-compliant, which causes problems in some readers. Try opening it with Acrobat Reader or another PDF reader.
• Embedding problem: the embedded XML is damaged. This is rare and is detected by the validation.

Solution: use the validation function (validate: true when creating via the API) to detect errors before downloading.

Contact person in ZUGFeRD invoices

If you define a contact person in the XML (e.g. via the API), it is not automatically shown in the PDF layout. The PDF typically shows a standard contact or the company itself. The contact person is nevertheless present in the structured data (XML) and is taken into account by systems that read the XML.

Automatic PDF generation in API integrations

If an invoice is created via an external API integration (e.g. by a worker or a batch process), the PDF may be generated with a standard layout instead of your individual invoice template. This is the case if:

• The API call does not pass a template ID.
• The system falls back to a fallback template (e.g. for system-generated invoices).

Solution: make sure your API payload contains the correct template ID or configuration references.

Field BT-18: document reference

The BT-18 field (reference to a business document) is maintained in faktoora via the buyerReference field or similar contexts. In the API, you can use invoiceReferencedDocument.IssuerAssignedID to set a reference to another invoice (e.g. for corrections). The precise BT-18 field mapping depends on the invoice type and the context.

Testing

To test ZUGFeRD invoices, you can:

1. Create an invoice in the web UI, save it as a draft and then show it to a customer.
2. Create the invoice with the customer's data in the customer's test account (with their API key).
3. Create a test invoice via the API with draftOnly: true.

All options let you show a working example without sending it in production.

Combining ZUGFeRD and XRechnung

An invoice created as ZUGFeRD 2.1 (Extended) cannot automatically be downloaded as an XRechnung. This is because ZUGFeRD 2.1 is built with the CII schema (PDF + CII XML), while XRechnung also uses CII but has its own validation rules and a different output format.

The right procedure:

• For private-sector clients: create ZUGFeRD 2.1 (Extended).
• For public-sector clients: explicitly select XRechnung.
• ZUGFeRD in the zf:2:xrechnung profile offers a hybrid profile between ZUGFeRD and XRechnung, but does not allow a free choice afterwards.

If you want to create a genuine XRechnung, select Format: xrechnung when creating the invoice. If you want a ZUGFeRD hybrid with XRechnung compatibility, use zf:2:xrechnung. Converting between them afterwards is not possible; the format is set when the invoice is created.