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:

1. A cryptographic hash of the PDF is calculated.
2. The hash is signed with a digital certificate.
3. 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 more

This 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 more

This 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