As of January 1, 2025, Germany has revised its definition of an electronic invoice for domestic B2B transactions. According to the Federal Ministry of Finance, an e-invoice must now be issued, transmitted, and received in a structured electronic format that allows for electronic processing. Therefore, a simple PDF no longer qualifies as an e-invoice. At the EU level, Directive 2010/45/EU requires that invoices be authentic in origin, intact in content, and legible. XML is plain text. It is easy to open, edit, overwrite, and replace. A common misconception often arises in technical discussions. Because electronic invoices are now based on structured data formats, such as XML, developers sometimes mistakenly believe that creating the XML alone is sufficient. These changes alter how developers should think about invoice generation. The legally relevant part of a modern e-invoice is its structured data, which is usually in XML format, such as XRechnung, ZUGFeRD, or Factur-X. This is precisely why XML-only workflows are legally viable in many cases. However, there is also a practical weakness: XML is plain text. It is easy to open, edit, overwrite, and replace. Without additional integrity protection, changes may remain invisible until an audit, dispute, or validation failure exposes the problem. The legal requirement is not just to "generate XML." It is also to preserve authenticity and integrity. Industry summaries of Germany's GoBD updates clearly emphasize this distinction: For structured e-invoices, the XML data component can be the archived element, and incoming electronic documents must generally be retained in their received format. However, this does not make XML tamper-evident. It only means that the structured format is the relevant invoice format. Ensuring integrity still requires operational measures. This is where hybrid invoice formats, such as ZUGFeRD and Factur-X, become valuable. These formats may be a combination of a human-readable PDF and a machine-readable XML attachment. TX Text Control supports embedding the XML into a PDF/A-3 document, providing the best of both worlds: Structured invoice data for automated processing and a PDF container that can be digitally signed or sealed later. Why XML Alone is Allowed, but still Risky From a tax and formatting standpoint, the structured invoice payload is the most important aspect. This is why a plain XML invoice satisfies the "structured format" requirement, whereas a plain PDF does not. However, XML alone has no built-in visual trust indicator or native tamper warning in common viewers. Anyone can modify a value in the file with any editor. Without external controls, versioning, hashes, audit logs, or signatures added by your system, you are relying on process discipline instead of cryptographic proof. A PDF container changes the discussion. Once XML is embedded in a PDF/A-3 invoice, a digital signature or seal can be applied to the resulting PDF. This does not transform the invoice into a different type of business document. Rather, it turns the invoice into a tamper-evident document. If the file is modified afterward, the PDF signature will fail to validate. This is a major operational advantage for finance teams, auditors, and downstream systems. The Better Pipeline: Generate, Embed, Seal, Archive For business applications, it is safer to generate structured XML, embed it in a PDF/A-3 container, apply a digital signature or seal to the PDF, and then archive the signed PDF. This approach ensures that the invoice data complies with legal requirements and is protected against tampering. It also provides a clear audit trail and simplifies validation for recipients and auditors. The following diagram shows the two processes side by side. This architecture meets the structured e-invoice requirement and adds tamper evidence at the document level. This architecture is especially useful in long retention scenarios where invoices may be revisited years later, requiring verifiable integrity. According to Germany's BMF FAQ, the structured format is now central, and EU VAT rules continue to focus on authenticity, integrity, and legibility. Digital Sealing Makes the Document Tamper Evident In the context of e-invoicing, a digital seal is a cryptographic mechanism that ensures the integrity and authenticity of an electronic invoice. Applying a digital seal to a PDF/A-3 document containing embedded XML creates a tamper-evident file. If anyone tries to modify the invoice after it has been sealed, the digital signature will fail to validate, clearly indicating that the document has been altered. The process typically looks like this: A cryptographic hash of the PDF is calculated. The hash is signed with a digital certificate. The signature is embedded in the PDF as a digital seal. Even a single-byte modification to the document later on will cause the signature validation to fail. PDF viewers immediately indicate that the document has been altered. This provides strong evidence that the archived document has not changed since the seal was applied. Creating ZUGFeRD or Factur-X Invoices with TX Text Control TX Text Control enables the implementation of this pipeline directly within .NET applications. The document engine generates the visual invoice and embeds the XML invoice in the resulting PDF/A-3 file. This snippet demonstrates how to generate an electronic invoice with TX Text Control. The XML is embedded as an attachment in the PDF/A document via SaveSettings.EmbeddedFiles, and the attachment is labeled as XML and described as the invoice payload. This is the core building block for generating ZUGFeRD and Factur-X in TX Text Control. string xmlZugferd = xRechnung.CreateXML(); // load Xml file string metaData = File.ReadAllText("metadata.xml"); TXTextControl.SaveSettings saveSettings = new TXTextControl.SaveSettings(); // create a new embedded file var zugferdInvoice = new TXTextControl.EmbeddedFile( "ZUGFeRD-invoice.xml", Encoding.UTF8.GetBytes(xmlZugferd), metaData); zugferdInvoice.Description = "ZUGFeRD-invoice"; zugferdInvoice.Relationship = "Alternative"; zugferdInvoice.MIMEType = "application/xml"; zugferdInvoice.LastModificationDate = DateTime.Now; // set the embedded files saveSettings.EmbeddedFiles = new TXTextControl.EmbeddedFile[] { zugferdInvoice }; Learn moreThis article shows how to create ZUGFeRD 2.3 compliant invoices using TX Text Control .NET Server. ZUGFeRD 2.3 is the latest version of the ZUGFeRD data model and complies with the European standard EN 16931. The article shows how to create ZUGFeRD 2.3 invoices and how to embed the XML invoice data in a PDF document.Creating ZUGFeRD 2.3 (XRechnung, Factur-X) Documents with .NET C# Applying a Digital Seal to the PDF Invoice After generating an invoice, the final step is to apply a digital signature or seal. TX Text Control supports signing PDFs directly during the save process. When you sign a PDF document, you apply a digital signature to the entire file. A digital signature embeds a cryptographic hash that validates the document's authenticity and integrity. It is a mathematical algorithm that authenticates the signer and ensures the document has not been altered. Typically, it requires a digital certificate issued by a trusted certificate authority (CA). The diagram below shows how to sign a PDF document with a digital signature. The following code snippet shows how to add a digital signature to a PDF invoice. The signature is created using a certificate and applied to the document, which makes it tamper-evident. If the document is modified after signing, the signature will fail to validate, indicating tampering. using System.Security.Cryptography.X509Certificates; using TXTextControl; var cert = new X509Certificate2("my_certificate.pfx", "123123123", X509KeyStorageFlags.Exportable); // Initialize TXTextControl to create and save a document with the digital signature using (var tx = new ServerTextControl()) { tx.Create(); tx.Text = "Hello, World!"; // Prepare the digital signature for the document var saveSettings = new SaveSettings { DigitalSignature = new DigitalSignature(cert, null) }; // Save the document as a PDF with the digital signature tx.Save("result.pdf", StreamType.AdobePDF, saveSettings); } Console.WriteLine("PDF saved with digital signature."); Learn moreThis article shows how to sign PDF documents with PFX certificates in .NET C# on Linux. The sample code uses the TX Text Control .NET Server component to create a PDF document and digitally sign it with a PFX certificate.How to Sign PDF Documents with PFX Certificates in .NET C# on Linux Integrity Must Be Part of the Document Pipeline Structured invoice formats solve the problem of creating machine-readable financial data. However, they do not automatically ensure document integrity. Although XML invoices are legally valid, they are easy to modify if stored without additional safeguards. Embedding XML in a PDF/A document and sealing the final file with a digital signature provides stronger integrity guarantees. For modern document systems, especially those that generate invoices automatically, integrity should not be an afterthought. It should be built directly into the document generation pipeline. With TX Text Control, developers can implement this entire process in their .NET applications by generating an invoice, embedding structured XML data, applying a digital seal, and archiving a verifiable document. Frequently Asked Questions What changed with electronic invoices in Germany in 2025? Since January 1, 2025, Germany requires domestic B2B electronic invoices to be issued, transmitted, and received in a structured electronic format that enables automated processing. A simple PDF document is no longer considered a valid electronic invoice. Instead, formats such as XRechnung, ZUGFeRD, or Factur-X that contain structured XML data must be used. Why is a simple PDF no longer considered an e-invoice? A standard PDF only represents visual content. It does not contain structured data that accounting systems can automatically process. The updated German requirements and EU Directive 2010/45/EU emphasize machine-readable invoice formats to support automated financial workflows. Is creating the XML invoice alone legally sufficient? In many cases, yes. Structured XML invoices such as XRechnung can meet the legal requirement for electronic invoices because the structured data is considered the authoritative invoice content. However, XML alone does not provide tamper evidence, which means it can be modified without obvious detection. Why can XML invoices be risky from an integrity perspective? XML is plain text and can be opened and edited with any text editor. Without additional controls such as cryptographic signatures, versioning, or audit logging, changes to the file may not be immediately visible. This creates risks in audits or disputes where the authenticity of the invoice must be verified. What are ZUGFeRD and Factur-X invoices? ZUGFeRD and Factur-X are hybrid invoice formats that combine a human-readable PDF document with embedded machine-readable XML invoice data. The PDF serves as the visual representation of the invoice, while the XML attachment contains the structured data required for automated processing. Why embed XML in a PDF/A-3 document? PDF/A-3 allows arbitrary files such as XML to be embedded inside a PDF container. This makes it possible to deliver a visually readable invoice while also including the structured XML payload required for automated processing. It also enables cryptographic protection of the document. What is a digital seal or digital signature in a PDF invoice? A digital signature or seal is a cryptographic mechanism applied to the PDF document. It creates a hash of the file that is signed using a digital certificate. If the document is modified afterward, the signature validation will fail, clearly indicating that the file has been altered. How does digital sealing make invoices tamper evident? When a PDF invoice is digitally sealed, a cryptographic hash of the document is calculated and signed with a certificate. Even a one-byte change in the document will invalidate the signature. PDF viewers immediately show that the document has been altered, providing strong evidence of tampering. What is the recommended invoice generation pipeline? A robust pipeline typically generates structured XML invoice data, embeds the XML in a PDF/A-3 document, applies a digital signature or seal to the PDF, and archives the signed file. This approach ensures compliance with structured invoice requirements while also protecting the document against tampering. How can developers generate ZUGFeRD or Factur-X invoices in .NET? Developers can use TX Text Control to generate the invoice document, embed the XML payload using SaveSettings.EmbeddedFiles, export the document as PDF/A-3, and optionally apply a digital signature during the save process. This allows the entire invoice pipeline to be implemented directly inside .NET applications. Why is tamper evidence important for archived invoices? Invoices often need to be retained for many years. During audits or financial reviews, it must be possible to prove that archived documents have not been modified since their creation. Digitally sealed PDF invoices provide a clear and verifiable integrity check. Does a digital signature change the legal nature of the invoice? No. Applying a digital signature does not change the invoice format or its legal classification. It simply adds cryptographic integrity protection, ensuring that the document can be verified as authentic and unchanged.