Frequently Asked Questions
Find answers to your questions about e-invoicing and faktoora.
What is an electronic invoice?
An electronic invoice is a legally compliant, machine-readable XML data set that contains all mandatory details under EU Directive 2014/55/EU and is imported automatically into ERP systems (e.g. SAP, MS Dynamics). Common formats such as XRechnung (B2G), ZUGFeRD Extended (B2B) and international standards such as Peppol BIS/UBL enable efficient validation, digital signatures (XAdES) and audit-proof archiving in line with GoBD (the German principles for proper digital bookkeeping and record-keeping, § 146 AO, German Fiscal Code). With OCR- and RPA-supported workflows you cut printing and postage costs, reduce errors and increase transparency in your invoicing workflow. You can find further practical tips on GoBD-compliant archiving and on the EU Directive on the pages of the European Commission
What formats are there for electronic invoices?
The formats for electronic invoices are based on the European standard EN 16931, which defines the content requirements. The actual technical formats are UBL (Universal Business Language) and CII (Cross Industry Invoice), two XML-based data structures for structured invoice information. Building on these, there are specific application specifications such as XRechnung and ZUGFeRD in Germany, which standardise these formats for particular contexts:
- XRechnung is the mandatory specification for electronic invoices to public-sector clients in Germany. Technically, it is based on UBL or CII.
- ZUGFeRD is a hybrid format that combines a PDF/A-3 with an embedded CII data set. It is used mainly in the B2B context.
Internationally, UBL is used above all within the Peppol network, a Europe-wide standard for the structured exchange of invoice data. You can find more information on Peppol at peppol.org and on CII at unece.org.
What is an XRechnung?
XRechnung is the mandatory specification in Germany for electronic invoices to public-sector clients. It is based on the European standard EN 16931 and consists exclusively of structured XML data. Unlike ZUGFeRD, which also contains a visual PDF, XRechnung does without layout and presentation entirely. Distinctive features of XRechnung are the mandatory Leitweg-ID (routing ID) used to address the receiving authority, and the embedding of supporting documents directly in the XML. Invoices are usually transmitted via platforms such as the German federal government's central invoice receipt platform, by upload or email. XRechnung invoices are required for all companies that invoice contracts from public bodies at federal or state level. faktoora ensures that all requirements are met automatically and that the current version of XRechnung is always used.
What is a ZUGFeRD invoice?
ZUGFeRD is a hybrid invoice format that combines a PDF/A-3 document with an embedded XML data set. It is based on the European standard EN 16931 and is particularly suited to exchanging electronic invoices in the B2B context. The visual part is used for display and archiving, while the structured XML data can be processed by machine. Unlike the purely structured XRechnung, ZUGFeRD allows a customisable invoice design while still meeting the requirements for electronic invoices. Various profiles are supported, for example ZUGFeRD Basic or Extended, depending on the level of detail required. ZUGFeRD is not prescribed by public-sector clients, but it is widespread in the private sector and is supported by many ERP and accounting systems. faktoora automatically creates valid ZUGFeRD invoices according to the current profile and lets you embed additional supporting documents.
What does PDF/A mean and why does it matter?
PDF/A is an ISO-standardised format for the long-term archiving of digital documents. It ensures that all content such as fonts, colours and images is fully embedded and that the document can be displayed unchanged at any time. This means an invoice remains readable and legally usable even after many years. For electronic invoices, PDF/A is particularly relevant for ZUGFeRD. Here the PDF/A-3 format is used, which additionally contains an XML file within the same document. The invoice is therefore both visually readable and machine-readable. PDF/A meets the requirements of GoBD (the German principles for proper digital bookkeeping and record-keeping) and is suitable for audit-proof archiving.
What does EN 16931 mean?
EN 16931 is the European standard for electronic invoices in the B2G and B2B context. It specifies which data an electronic invoice must contain, the structure in which it is transmitted and which validation rules apply. The aim is a uniform, machine-readable standard for exchanging invoices within the EU. The standard defines a so-called semantic data model that is independent of the technical format. Technical implementations such as UBL and CII were developed on this basis. National application specifications such as XRechnung or ZUGFeRD are so-called CIUS (Core Invoice Usage Specifications), which adapt EN 16931 to the specific legal and organisational requirements of individual countries or industries. XRechnung is the CIUS for the public sector in Germany and is technically based on UBL or CII. ZUGFeRD is another CIUS, used in Germany mainly in the B2B context and built on CII. Both formats implement the requirements of EN 16931 but differ in structure and scope of application.
What is Peppol and how does it work?
Peppol is an internationally used network for the secure, standardised exchange of structured business documents such as electronic invoices, orders or delivery notes. It was originally initiated by the EU and has since become established worldwide, including in Germany, the Netherlands, Norway, Australia, Singapore and Japan. Peppol is based on uniform data formats such as UBL and a defined transport protocol. Every participant can be reached via a unique Peppol ID and communicates via certified Access Points. Transmission is encrypted, traceable and works across systems. Another component is the Peppol SMP (Service Metadata Publisher), which manages how recipients can be reached.
A major advantage of Peppol is global interoperability without bilateral interfaces. Companies and public authorities can exchange structured invoices directly worldwide. Peppol is also a key technical building block for upcoming EU requirements such as ViDA (VAT in the Digital Age), which aims at mandatory e-invoices and transaction-based reporting.
faktoora is a certified Peppol provider, enabling seamless receiving and sending via the Peppol network.
When is my company required to use electronic invoices in B2B, and does this also apply to small businesses?
Since 1 January 2025, businesses in Germany have been required to be able to receive electronic invoices in the B2B sector. This rule applies to all domestic companies, regardless of size, industry or legal form. Freelancers, partnerships and associations with economic activities are also included, provided they operate as businesses and owe VAT in Germany or are entitled to deduct input VAT as recipients of supplies. The legal basis is § 14 UStG (German VAT Act) as amended by the Wachstumschancengesetz (Growth Opportunities Act). This extends the existing obligation to use electronic invoices in the public sector, introduced in 2020 by the E-Rechnungsverordnung (the federal E-Invoicing Ordinance, for XRechnung in B2G), to the B2B sector. The obligation to issue electronic invoices is being phased in. Since 2025, only receiving them is mandatory. The obligation to issue them applies to large companies from 2026 and will be extended to all companies by 2028. Transitional rules exist for invoices that do not have to be issued electronically, for example:
- Small-amount invoices under 250 euros (§ 33 UStDV, German VAT Implementing Ordinance)
- Tickets and similar receipts (§ 34 UStDV)
- Exceptions for cash sales and supplies to private individuals (B2C)
Electronic invoices within the meaning of the law must comply with the EN 16931 standard, for example as XRechnung or ZUGFeRD with a structured XML file.
Can I still send PDF invoices?
Since 2025, simply sending PDF invoices is no longer sufficient in the B2B sector in Germany. Under § 14 UStG (German VAT Act), electronic invoices must comply with the EN 16931 standard, i.e. be created in a format such as XRechnung or ZUGFeRD with structured XML data. A PDF without structured data does not meet this requirement and is not permitted in this context. A paper invoice, on the other hand, is formally not an electronic invoice and therefore remains permitted in certain exceptional cases, for example for small-amount invoices or during the transitional periods for the obligation to issue e-invoices. In other words: paper may be allowed where PDF is explicitly no longer recognised.
We make sure that all invoices you create with faktoora meet the legal requirements. You choose the format; we take care of structure, validation and compliance.
Does the e-invoicing obligation also apply to small businesses?
Yes. The e-invoicing obligation also applies to small businesses, provided they operate as businesses and supply goods or services to other companies in Germany. What matters is not the size of the company, but whether a B2B supply is made in Germany. The obligation to use electronic invoices therefore also affects small businesses under § 19 UStG (the small business scheme of the German VAT Act) as soon as they invoice other companies.
Small businesses are not exempt from the obligation to receive e-invoices and have had to be able to accept electronic invoices in a structured format (e.g. XRechnung or ZUGFeRD) since 2025. For issuing them, a transitional rule applies until 2028 at the latest. However, if you switch early, you benefit from fewer media breaks and automated processes.
Can PDF files be converted automatically into electronic invoices?
No. PDF files cannot be converted automatically into valid electronic invoices because they do not contain structured data. Conversion via OCR (optical character recognition) is technically possible, but not reliable enough to meet the requirements of EN 16931. OCR recognises content purely visually, but cannot semantically map it to mandatory fields such as BT-20 or BT-126. Nor can validation rules or mandatory tax details be derived reliably. Creating electronic invoices requires structured source data, for example from an ERP system or by entering it directly in faktoora. Trying to process PDFs via OCR is not a sustainable digitalisation strategy but an error-prone workaround.
What is the difference between UBL and CII?
UBL (Universal Business Language) and CII (Cross Industry Invoice by UN/CEFACT) are two XML-based formats for representing structured electronic invoices. Both meet the requirements of the EN 16931 standard and serve as the technical foundation for national invoice standards such as XRechnung or Peppol BIS. The difference lies in their approach:
- UBL is more open, simpler in structure and more widespread in northern and western Europe. It is used, for example, in the Netherlands, Denmark and in the Peppol network.
- CII is semantically stricter and comes from UN/CEFACT. It places more emphasis on formal clarity but is more complex to implement. Germany partly relies on CII for XRechnung, as does ZUGFeRD.
The existence of both formats has historical and political reasons. With EN 16931, the EU wanted to define uniform content, but deliberately allowed two technical variants so that national standards could build on them flexibly.
Is Peppol EDI?
Peppol is not classic EDI such as EDIFACT or ANSI X12, but a modern infrastructure for structured document exchange based on open standards. While traditional EDI is usually based on proprietary formats, bilateral connections and individual interfaces, Peppol uses standardised formats such as UBL and an open, Europe-wide networked system with unique Peppol IDs.
EDI offers advantages such as a high degree of process automation, direct system integration and fast data exchange. However, it is often expensive to set up, maintenance-intensive and offers little interoperability. This is exactly where Peppol comes in: it reduces complexity, lowers integration costs and is interoperable between companies, public authorities and countries.
In many use cases, Peppol can fully replace classic EDI, especially for transmitting structured invoices in B2B and B2G. For highly customised EDI scenarios in industry, classic EDI remains partly relevant, but Peppol offers a future-proof, standardised alternative for anyone who wants to exchange invoices digitally in an interoperable, legally compliant and cost-efficient way.
Can I create invoices with prices including VAT?
No. Under EN 16931, invoices must always be created with net prices. VAT must be shown separately. Showing gross prices without a breakdown is not permitted, because structured electronic invoices have to be processed by machine and checked unambiguously for tax purposes.
This requirement applies regardless of the format used, whether XRechnung, ZUGFeRD or another EN 16931-compliant schema. Even if the PDF part of a ZUGFeRD invoice contains additional information, the net price rules are binding for the machine-readable XML file.
How do I have to show a security retention?
A security retention must be shown in an electronic invoice in a structured, traceable way. The amount must not simply be deducted from the total or only mentioned as free text. Instead, the retention is shown as a separate invoice line with a negative quantity and a positive unit price. Example: "Security retention 5 percent as per contract", quantity minus one, unit price 500 euros. The retention thus visibly reduces the amount payable and complies with the requirements of EN 16931. In the final invoice, this line is not listed again; the retained amount then becomes payable in full. Negative unit prices are not allowed in XRechnung; only negative quantities are permitted. This modelling is machine-readable, can be validated and is also accepted by public-sector clients such as Deutsche Bahn.
How do cancellation invoices work?
In electronic invoicing, a cancellation invoice is identified by TypeCode 381. This type stands for a credit note and is used when an invoice that has already been issued is to be cancelled in full or in part. The amounts are shown as negative values, typically via negative quantities. A reference to the original invoice, for example via the invoice number and the issue date, is recommended so that the link can be traced by machine.
By contrast, TypeCode 384 stands for an invoice with a negative total amount. It is used when, for example, a credit balance or a subsequent price reduction is invoiced without cancelling an existing invoice. This is a new invoice with a negative effect, not a classic cancellation invoice.
In practice: if you want to correct or withdraw an invoice, use TypeCode 381. If you want to invoice a credit balance without referring to a specific invoice, TypeCode 384 is the right choice. Both variants are EN 16931-compliant and are supported by XRechnung and ZUGFeRD.
Practical use: In faktoora, use the "Cancellation invoice" or "Credit note" function in the menu of an existing invoice to automatically create a cancellation invoice with the correct reference. This ensures the correct assignment for the recipient and the authorities.
What is relevant for tax purposes: the PDF or the XML data?
For an electronic invoice, only the structured XML data is relevant for tax purposes. This applies to both XRechnung and ZUGFeRD. With ZUGFeRD, the PDF merely serves as a visual representation and has no tax or legal relevance within the meaning of GoBD (the German principles for proper digital bookkeeping and record-keeping) or the German VAT Act. The XML data set according to EN 16931 is what counts for machine processing, for checking by the invoice recipient and for archiving.
Even with a hybrid invoice such as ZUGFeRD, only the XML component determines validity for tax purposes. Companies should therefore make sure that it is the XML data that is archived correctly, completely and unalterably.
What has to be archived under GoBD?
Under GoBD (the German principles for proper digital bookkeeping and record-keeping), all tax-relevant documents must be archived completely, unalterably, in a machine-evaluable form and traceably. For electronic invoices, this means: the structured XML data set must be archived, not just the visual PDF. This applies regardless of whether it is an XRechnung or a ZUGFeRD invoice.
With ZUGFeRD, the PDF does contain the visual representation, but the entire PDF/A-3 including the embedded XML part must be archived, as this is the only way to meet the requirements for completeness and machine evaluability. With XRechnung, the XML file alone is decisive and must be stored in its original state.
In addition, all related information, such as validation reports, approval notes and receipt confirmations, must also be kept securely and traceably. The retention period is generally ten years.
What has to be processed when receiving an electronic invoice?
When you receive an electronic invoice, it is primarily the structured XML data set according to EN 16931 that has to be processed. It contains all tax-relevant content such as the invoice amount, tax rates, line items, delivery details, invoice issuer and recipient. The visual layout, such as an attached PDF, is not decisive.
The receiving system must be able to read in, check and archive the XML data automatically. This includes validation for technical correctness, e.g. whether mandatory fields such as the invoice number or tax rate are present and filled in correctly. Incorrect invoices must be rejected or given a review note. In addition, optionally embedded documents such as proof of performance or measurement records should be evaluated or archived.
For GoBD-compliant processing (GoBD: the German principles for proper digital bookkeeping and record-keeping), you also need to make sure that the review history, for example approval notes or comments, is documented. This is the only way to ensure traceability in a tax audit.
Which version of XRechnung is valid?
For XRechnung, the current version released by the Coordination Office for IT Standards (KoSIT) always applies. KoSIT centrally specifies which version is currently mandatory. Only invoices that comply with this valid standard are accepted by public-sector clients. Older versions regularly lose their validity and may then no longer be used. faktoora ensures that the currently permitted version is always used automatically. You can find the currently valid XRechnung version directly at KoSIT.
How can I invoice work on a percentage basis?
In many industries, percentage-based invoicing is common practice, for example for progress invoices in construction, plant engineering or for planning services under the HOAI (the German fee schedule for architects and engineers). Partial work completed is invoiced as a percentage, for example 80 percent of a line item. However, electronic invoices according to EN 16931 (i.e. in ZUGFeRD or XRechnung format) do not support a direct percentage. The standard requires a specific quantity and a unit price per line item. A value such as "80 percent" is therefore not permitted.
The solution: the percentage is expressed arithmetically via the quantity. Example: for 80 percent of a line item with the unit "piece", you enter the quantity 0.8. This keeps the invoice standard-compliant, machine-readable and automatically verifiable.
How can I attach supporting documents to an invoice?
Supporting documents such as measurement records or proof of performance can be uploaded directly in the invoice form. faktoora always embeds these files in the XML, regardless of the format. For both XRechnung and ZUGFeRD, attachments are included in the XML in base64-encoded form. This is what XRechnung requires and is proven practice for ZUGFeRD, ensuring that all relevant information is transmitted and archived completely, in machine-readable form and in an audit-proof way. External links are not needed and are not supported by many receiving systems anyway.
What do the BT fields mean?
BT fields (Business Terms) are clearly defined data fields in the EN 16931 standard, which forms the basis for XRechnung and ZUGFeRD. Each BT field specifies precisely which information must be entered in that field and in which format, for example BT-20 for the invoice date or BT-126 for the total amount. This unambiguous structure enables machine validation and automated processing of electronic invoices. At the same time, it simplifies coordination between the parties involved, as it is clear where which details are expected.
Can I create construction invoices?
Yes. With faktoora, you can create construction invoices with the invoice types 875 (progress invoice), 876 (partial invoice) and 877 (final invoice). These type codes are part of the EN 16931 standard and identify the purpose of each invoice. For a complete and verifiable construction invoice, you can upload the required documents, such as measurement records or proof of performance, directly in the invoice form. These are automatically embedded in the XML as attachments. In final invoices, all previous progress payments must be stated correctly so that the electronic invoice is complete and traceable.
Can I create invoices with GLNs/GTINs?
Yes. In faktoora, you can create invoices that contain all relevant GS1 data. You can specify GLNs for both the goods recipient and the invoice recipient, store your own GLN and assign GTINs at line-item level. These functions meet key requirements of retail and of the GS1 standard and are particularly important in the retail sector, where clear identification of products and business partners is required. faktoora fully supports these details within ZUGFeRD and XRechnung.
Can I use faktoora without a software integration?
Yes. You can use faktoora entirely without a software integration. Via the browser-based web interface, you create electronic invoices directly online, without installation or an interface. The platform can be used on its own and offers all functions for creating, validating and archiving XRechnung- or ZUGFeRD-compliant invoices. Alternatively, a REST API is available for system integration.
How much does faktoora cost?
faktoora offers three clearly structured plans, suitable for every company size and every use case. Every customer starts with a free one-month trial, with no subscription trap. The trial ends automatically; no cancellation is needed.
The Business plan at €29 per month lets you send and receive standard-compliant electronic invoices in ZUGFeRD or XRechnung format. This makes it ideal for SMEs with a B2B focus that want to invoice in a legally compliant and efficient way.
For companies with high volumes, complex requirements or ERP systems, the Premium plan at €129 per month offers the full specification according to EN 16931, including API integration, attachments, complex type codes and automated processing.
For individual requirements, such as a dedicated account manager, an SLA guarantee or tailored integrations, we also offer the Enterprise plan, priced on request.
All prices are per month, plus VAT.
You can find all features and prices here
Can I create invoices automatically via an API?
Yes. faktoora offers a powerful REST API for the automated creation, sending and receiving of electronic invoices according to EN 16931. The interface is designed specifically for high invoice volumes and easy integration into existing systems, such as ERP or document management solutions. Processing entire invoice batches is also possible. This makes faktoora ideal for companies that want to digitalise their invoicing processes in a scalable and efficient way. You can find the complete API documentation here: https://docs.faktoora.com/
Does faktoora support approval processes?
Yes. faktoora supports structured approval processes both when creating and when receiving invoices. Outgoing invoices can, for example, be created according to the four-eyes principle, where a project manager prepares the invoice and accounting gives final approval. For incoming invoices, rule-based checking mechanisms are available, allowing invoices to be accepted or rejected automatically or manually. Additional approval levels can also be defined to reflect individual compliance requirements. faktoora places particular emphasis on smart workflows that adapt flexibly to existing processes and ensure transparency and control throughout the invoicing process.
You can find more information on the incoming invoice process here, among other places: https://faktoora.com/wissensdatenbank/eingangsrechnungspruefung/
Can I send invoices directly from faktoora?
Invoices can be sent flexibly with faktoora. You can send them by email via our mail server, via your own SMTP server or via the Peppol network. Alternatively, you can download the finished electronic invoice and send it manually. The right delivery channel depends on the recipient's requirements and your internal processes. You can find instructions for setting up SMTP sending in our knowledge base under Setting up and sending via SMTP.
How do I send invoices via faktoora?
Invoices can be sent flexibly with faktoora. You can send them by email via our mail server, via your own SMTP server or via the Peppol network. Alternatively, you can download the finished electronic invoice and send it manually. The right delivery channel depends on the recipient's requirements and your internal processes. You can find instructions for setting up SMTP sending in our knowledge base under Setting up and sending via SMTP.
Are incoming invoices processed too?
Yes. faktoora supports receiving electronic invoices in EN 16931 format, i.e. both ZUGFeRD and XRechnung. Invoices can be received by email, by upload or via the Peppol network. Emails can be sent to a faktoora mailbox or received via your own IMAP account. Incoming invoices are processed automatically, validated for structure and content, and presented visually. If there are errors, the sender immediately receives a detailed error report. In addition, you can use whitelisting to admit only authorised senders. Once an invoice has been checked successfully, you can manually reject it, approve it or pay it directly via the bank integration. You can find more information under Incoming invoice review.
Is there a DATEV integration for my tax adviser?
Yes. faktoora offers a direct integration with DATEV Unternehmen Online via the DATEV Rechnungsdatenservice. Both incoming and outgoing invoices can be passed to your tax adviser automatically. All accounting-relevant data is transmitted in the correct format, including document data and attachments. The integration saves manual effort and ensures a clean handover to financial accounting. faktoora is an officially listed interface partner in the DATEV Marketplace at https://www.datev.de/web/de/marktplatz/datev-schnittstellen-anbieter/
Can I use my own invoice templates?
Yes. Using individual invoice templates in addition to the standard layout is included in all plans. If you would like to create your own invoice layout or have an existing one adapted, we offer this as a service on request. Technically, the layout is mainly relevant for ZUGFeRD, as a designed PDF is sent there together with the structured XML data. With pure XRechnung invoices, on the other hand, only the XML file is transmitted, so the layout no longer plays a role, as only the structured data is used for processing and validation.
Can several users use one account?
Yes. From the Premium plan upwards, you can create multiple users with individual permissions. This lets you control roles specifically, for example for entering, checking or approving invoices. This is particularly relevant for companies with defined approval processes or compliance requirements. All actions are logged in an audit-proof way. In principle, several people can also share one login, for example to cover holidays. However, if several employees use one user account at the same time, faktoora accepts no liability for any data inconsistencies.
Can I also create invoices with a foreign tax number?
Yes. faktoora supports creating electronic invoices with a foreign tax number or international VAT ID for both invoice issuers and invoice recipients. You can create cross-border invoices according to EN 16931, for example for intra-Community supplies or services to foreign business customers. Whether there is an obligation to use electronic invoices in Germany in a specific case depends on the tax framework. If you have questions about using a foreign tax number or about correct invoicing abroad, we will be happy to advise you. Please use our contact form at https://faktoora.com/contact
How long does the API integration take?
How long it takes to integrate the faktoora eInvoicing API depends heavily on the connected system, the depth of integration, the available development resources and the internal data structure. In practice, you should allow 4 to 8 weeks for a complete implementation through to productive go-live. We deliberately rely on proven, well-known concepts and offer a clear, well-documented interface for easy integration. You can find a technical overview of processes and data fields at https://docs.faktoora.com/docs/getting-started. If you have questions about the integration or about aligning data fields, we will be happy to advise you directly at faktoora.com/kontakt.
How does archiving of my data work?
At faktoora, electronic invoices are archived in a GoBD-compliant (GoBD: the German principles for proper digital bookkeeping and record-keeping) and audit-proof way. In audit-proof mode, invoices can no longer be changed after they have been created, to ensure immutability under GoBD. Users can export their data at any time, for example for their own archiving or external backups. All data is stored on our servers in compliance with data protection law. You can find more information on our data security in our SLA: https://faktoora.com/sla