ZUGFeRD Explained: the Hybrid Invoice Format, its Profiles and a Real Example

Summary

12 min

ZUGFeRD is a German invoice format that puts two things into a single file: a PDF for people and a structured XML data set for software. Open the file and you see an ordinary invoice. Drop it into an accounting system and amounts, tax rates and line items are read in automatically. The standard is maintained by the Forum elektronische Rechnung Deutschland (FeRD) and published through the AWV, and the current release is version 2.5.2 of August 4, 2026. The number that matters is not the version but the profile: two of the five profiles are explicitly not accepted in Germany as a complete invoice. Outside Germany the same format carries a different name, Factur-X, and the files are interchangeable. This guide covers the structure, the profiles, a full example invoice with its XML, and who actually needs the format.

What is ZUGFeRD?

ZUGFeRD is a hybrid format for electronic invoices. Hybrid means one file with two ways of reading it. On the outside it is a PDF, the kind everyone knows, with a letterhead, line items and totals. On the inside the same invoice content sits a second time as XML, a data set in which every field has a defined meaning. The recipient opens one or the other, depending on whether a person or a program is looking at the invoice. A ZUGFeRD invoice is therefore not a separate file format next to PDF. It is an ordinary PDF file with an extra data set inside it.

The name is a German acronym for Zentraler User Guide des Forums elektronische Rechnung Deutschland, the central user guide of the German forum for electronic invoicing. Who stands behind it matters more than what it spells. FeRD is an association of trade bodies, public administration and software vendors, supported by the German Federal Ministry for Economic Affairs and Energy. The standard is published through the AWV and is freely available, with no license fee and no vendor who owns it.

E-invoice, ZUGFeRD and XRechnung kept apart

Mixing up the three terms leads either to asking your software for the wrong format or to assuming a PDF sent by email already does the job. Electronic invoice is the umbrella term, meaning any invoice issued, transmitted and received in a structured format that can be processed automatically. A PDF attached to an email does not qualify, not even when it comes out of an invoicing program, because to a piece of software its content is just text without meaning. ZUGFeRD is one way to meet that requirement and the XRechnung, a pure data file with no visual layer, is the other common one in Germany. Both implement EN 16931 and both are equally valid, and the difference is whether anything readable is left at the end.

Where the German obligation comes in

Since January 1, 2025 every business established in Germany has to be able to receive electronic invoices, with no transition period and no turnover threshold. Issuing them is phased in, becoming mandatory for domestic business-to-business invoices from January 1, 2028, with earlier dates for larger companies. For the format this means one thing: the law does not prescribe ZUGFeRD, it prescribes conformity with EN 16931. ZUGFeRD is one route there, but only in certain versions and profiles, and that is exactly where the trap sits.

The ZUGFeRD format: PDF and XML in one file

The format solves a problem that is very real during a transition. One half of your customers can process structured data and the other half cannot. Send a pure XML file and you lose the second half, send a PDF and you do not meet the requirement. The hybrid format sidesteps the decision by putting both into the same file.

How the XML gets into the PDF

Technically ZUGFeRD uses PDF/A-3, the long-term archiving flavour of PDF, which unlike an ordinary PDF may carry arbitrary files as attachments. That is where the XML sits, invisible but firmly tied to the document. Software that knows ZUGFeRD picks up the attachment and reads it, while a person who double-clicks the file notices nothing.

The XML itself is written in UN/CEFACT CII syntax, one of the two notations in which EN 16931 can be expressed, the other being UBL. For the hybrid format only CII is permitted. That becomes a topic wherever UBL is already produced in house, for Peppol or for an XRechnung in its UBL flavour, because such a data set cannot simply be dropped into the PDF. It has to be converted first, and anyone who overlooks that plans one work step too few.

Which file counts legally

This is where it gets serious for accounting. With a plain XRechnung the XML file is the original and the answer is simple. With ZUGFeRD both sit in the same file, and the structured part governs. If the visual layer and the data set disagree, for instance because someone edited the PDF afterwards, the XML wins. So the PDF must not travel on alone as the record. Anyone moving an invoice from a mail client into an archive has to make sure the embedded XML survives the trip, because some tools that compress or merge PDFs silently discard attachments, and that only shows up at audit time.

Versions and profiles: which variant counts as an e-invoice

There is no such thing as the ZUGFeRD. There is a version line, and within it five data profiles that contain different amounts of information. Overlook that and at best you send an invoice the recipient rejects, at worst one that does not count as an electronic invoice at all.

From 1.0 to 2.x

The first release appeared in 2014, long before the European standard, and followed a logic of its own. Version 2.0 aligned the format with EN 16931, and since then German law draws a clear line: ZUGFeRD counts as an electronic invoice only from version 2.0.1 onwards, and anything older is a data exchange format rather than an e-invoice. The current release is 2.5.2 of August 4, 2026. Newer versions mostly extend the upper profiles while the core stays stable, so the question to put to your software stays concrete: which version and which profile does it produce, and can that be changed.

The five profiles and the pitfall

A profile decides how many fields the data set contains. From very little to a great deal the sequence runs MINIMUM, BASIC WL, BASIC, EN 16931 (COMFORT) and EXTENDED. On top of those sits a reference profile called XRECHNUNG, which describes no data volume of its own but defines how a standard-conforming XML is embedded into the PDF.

The two smallest profiles are the most common reason for rejected invoices. MINIMUM and BASIC WL contain no invoice lines and are explicitly intended by FeRD as a posting aid rather than an invoice. When a program produces MINIMUM by default, the file looks perfectly normal to the sender because the PDF is complete, and the fault only surfaces at the recipient. For everyday business EN 16931 (COMFORT) is the safe choice, covering the core data set of the standard in full, with tax rates per line, the delivery period and the payment terms each in their own field. EXTENDED only pays off where an industry asks for additional entries, in construction or logistics for example.

How to find out what your software produces

Do not rely on the vendor's website, where the word ZUGFeRD usually appears without any qualifier. The reliable route takes two minutes. Write a test invoice to yourself, open the file in a PDF viewer and pull the embedded XML out of the attachment list. Right at the top of that file, in a field called GuidelineSpecifiedDocumentContextParameter, sits an identifier, and it gives away the profile. If it ends in minimum or basicwl, you have found the problem before your customer does.

A validation tool is faster still, because it reads the file and reports version and profile in plain language. If your software does not let you set the profile and produces one of the two small variants, that is a hard reason to switch rather than a cosmetic flaw.

What a ZUGFeRD invoice looks like inside

Almost every explanation of the format stops exactly where it gets interesting. So here is a complete example invoice, first as the person sees it, then as the software reads it. It is the same transaction, shown twice.

The invoice as the recipient sees it

Say an engineering office bills a client for the structural calculation of a roof truss. Invoice number 2026-0184, invoice date October 14, 2026, delivery period up to September 30, 2026, one line covering 12.5 hours at 95 euros. That gives a net total of 1,187.50 euros, 19 percent German VAT on top at 225.63 euros, and a final amount of 1,413.13 euros, payable by October 28. In the PDF this appears as a table with a letterhead, a line item and a totals block, exactly like any other invoice. Nothing on the page reveals that the file holds more.

The same invoice as XML

Inside that same file sits the data set. Trimmed down to the load-bearing parts it looks like this:

<rsm:CrossIndustryInvoice>
  <rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
  <rsm:ExchangedDocument>
    <ram:ID>2026-0184</ram:ID>
    <ram:TypeCode>380</ram:TypeCode>
    <ram:IssueDateTime>
      <udt:DateTimeString format="102">20261014</udt:DateTimeString>
    </ram:IssueDateTime>
  </rsm:ExchangedDocument>
  <rsm:SupplyChainTradeTransaction>
    <ram:IncludedSupplyChainTradeLineItem>
      <ram:SpecifiedTradeProduct>
        <ram:Name>Structural calculation, roof truss</ram:Name>
      </ram:SpecifiedTradeProduct>
      <ram:SpecifiedLineTradeAgreement>
        <ram:NetPriceProductTradePrice>
          <ram:ChargeAmount>95.0000</ram:ChargeAmount>
        </ram:NetPriceProductTradePrice>
      </ram:SpecifiedLineTradeAgreement>
      <ram:SpecifiedLineTradeDelivery>
        <ram:BilledQuantity unitCode="HUR">12.5000</ram:BilledQuantity>
      </ram:SpecifiedLineTradeDelivery>
      <ram:SpecifiedLineTradeSettlement>
        <ram:ApplicableTradeTax>
          <ram:TypeCode>VAT</ram:TypeCode>
          <ram:CategoryCode>S</ram:CategoryCode>
          <ram:RateApplicablePercent>19.00</ram:RateApplicablePercent>
        </ram:ApplicableTradeTax>
      </ram:SpecifiedLineTradeSettlement>
    </ram:IncludedSupplyChainTradeLineItem>
    <ram:ApplicableHeaderTradeSettlement>
      <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
      <ram:SpecifiedTradeSettlementHeaderMonetarySummation>
        <ram:LineTotalAmount>1187.50</ram:LineTotalAmount>
        <ram:TaxBasisTotalAmount>1187.50</ram:TaxBasisTotalAmount>
        <ram:TaxTotalAmount currencyID="EUR">225.63</ram:TaxTotalAmount>
        <ram:GrandTotalAmount>1413.13</ram:GrandTotalAmount>
        <ram:DuePayableAmount>1413.13</ram:DuePayableAmount>
      </ram:SpecifiedTradeSettlementHeaderMonetarySummation>
    </ram:ApplicableHeaderTradeSettlement>
  </rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>

Three places deserve a second look. Right at the top, urn:cen.eu:en16931:2017 states which standard the invoice was built to, so a validating program immediately knows which rule set to apply. The TypeCode 380 simply means invoice, where a credit note would carry 381. And in the totals block every value appears separately, from the line total to the amount due, so that validation can check whether the numbers add up. That arithmetic check is the most frequent reason for rejection in practice. Not a missing field, but a tax amount that differs by one cent from the sum of the lines because rounding happened somewhere else.

The same invoice in the wrong profile

Now the revealing part. If the same invoice were produced in the MINIMUM profile, the entire middle block would fall away, meaning IncludedSupplyChainTradeLineItem with the description, the hours and the hourly rate. What would remain is a data set that knows the invoice number, the date, the total and the tax amount, but not what the money is for. The visible PDF page would be completely unchanged.

That is where the invoice fails. Not on looks, but on the fact that the governing part no longer carries the mandatory details. The sender sees a correct document, the recipient gets an incomplete data set, and neither notices until accounts payable asks. This is why the profile is the one piece of information that really matters with this format, rather than the version number everyone talks about.

How to tell whether a PDF contains ZUGFeRD

You cannot see it from the outside, and experienced bookkeepers fall for this too. A PDF viewer has an attachment list, and the embedded file shows up there, usually under the name factur-x.xml or zugferd-invoice.xml. A validation tool is the better route, because it reports not only whether an XML is inside but also which profile and which version.

ZUGFeRD and Factur-X: one format, two names

Outside Germany the format is usually met under its French name. Factur-X and ZUGFeRD are technically the same thing. Germany and France develop the specification together, the versions are released in step, and a file created in one country is read in the other without any conversion. For the receiving side the difference is the name on the paper and nothing else.

Which name you encounter depends on where your counterpart sits rather than on what the file contains. A French customer asks for Factur-X, a German one for ZUGFeRD, and your software produces one file for both. The practical consequence is worth noting: support for Factur-X in an international accounting package is also support for ZUGFeRD, even when the German name appears nowhere in the vendor's documentation. If you are looking for the capability in a system that was not built for the German market, search for Factur-X first.

Do companies outside Germany need ZUGFeRD?

This is the question most guides on the topic skip, and it is the one that decides whether the rest matters to you at all. The short answer is that the German obligation to issue electronic invoices applies to businesses established in Germany. A supplier based in Spain, the United States or the United Kingdom is not caught by it simply because the customer is German.

That leaves three situations worth separating, because the practical answer differs in each.

You invoice German businesses from abroad

No obligation applies to you, but the pull from the other side is real. Your German customers have had to be able to receive electronic invoices since the start of 2025, and many have rebuilt their accounts payable around that. A supplier who still sends a plain PDF breaks no rule, but is increasingly the one piece of manual work in an otherwise automated process. ZUGFeRD is the gentlest way to meet that expectation, because the file still looks like the invoice everybody knows.

You invoice German public authorities

Here the picture changes. Invoices to German federal authorities have to be electronic regardless of where the supplier is based, apart from a few exceptions. For that case ZUGFeRD is the weaker choice. The invoice submission portals are built around the XRechnung and expect a pure data file together with a routing identifier known as the Leitweg-ID. Some portals accept a ZUGFeRD file in the XRECHNUNG reference profile, but that is not something to rely on.

A third case is the German subsidiary, and it is the most common reason English-speaking finance teams end up reading about ZUGFeRD at all. The subsidiary is established in Germany, so the obligation applies to it in full, including the staged dates above. The decision is then not whether to comply but which of the two German formats fits the customer base, and the next section covers that.

ZUGFeRD vs XRechnung: which one to send

Both meet EN 16931 and both are legally valid in Germany, so the choice is not about compliance. It is about who receives the invoice and what they can do with it.

The answer depends on the recipient, not on the technology.

Put simply: ZUGFeRD is the format for business-to-business invoicing during a transition, XRechnung the one for the public sector. If you do not know what a given customer can process, which is the normal case, the hybrid file leaves the question open, and that is precisely what it was built for.

How to create a ZUGFeRD invoice

The format cannot be produced by hand. A PDF/A-3 with a correctly embedded, standard-conforming XML does not come out of a word processor, and exporting from a spreadsheet does not help either. It takes software that knows the format. The available routes differ less in the result than in how much work falls either side of it.

This article comes from Unusual Software GmbH, the vendor behind Unusual Suite. The overview below also names our own product. We have written it so that it stays useful if you decide on something else.

Prices and scope depend on the plan and the number of users. Ask the vendor for a firm quote.

If you work outside Germany, there is a shorter route worth trying before any of these. Check whether the accounting system you already run supports Factur-X, since that is the same format under its international name. Many packages sold across Europe list it without ever mentioning ZUGFeRD.

The routes differ mainly in where the invoice data comes from. Accounting packages are strong downstream, in receipts, the chart of accounts and the handover to your accountant, but anyone who records hours and bills from them keeps that data elsewhere and types it in twice. Integrated business software comes from the other direction, building the invoice from projects and time entries that are in the system anyway, at the price of thinner bookkeeping. Free generators are fine for a test run and useless for ongoing work, since every invoice starts from nothing.

Unusual Suite

Unusual Suite sends a hybrid PDF. That belongs at the start, because it answers the question this guide is about. Every invoice issued goes out as a readable PDF that carries the machine-readable e-invoice to EN 16931 embedded inside it and attached alongside it, for Germany and most countries as XRechnung in version 3.0.1, for Spain as Peppol BIS 3.0. The format follows the country of your own company address rather than the language you use the app in. A person and the accounting software read the same delivery, and the recipient takes whichever form its system understands.

What it does instead is bring CRM, project management, time tracking and invoicing into one interface. Invoice lines are built from recorded working time along with the project, the billing rule and the period, and a correction goes out as an electronic credit note that refers back to the invoice it amends. It is built for service firms that bill by effort. A separate guide covers what electronic invoicing software has to do and how to recognize a suitable one.

Receiving and processing ZUGFeRD invoices

Much is written about issuing and little about receiving, yet in Germany the receiving side has been everyone's problem since the start of 2025. Anyone who receives an electronic invoice in ZUGFeRD format has to be able to accept it, read it and keep it.

Validate rather than trust

An incoming file should not simply be waved through. A validation tool reads the embedded XML, reports missing mandatory fields, recalculates the totals and states which profile is present, which is exactly where the two smallest profiles become visible. If an invoice arrives in the MINIMUM profile, the line items are missing and it does not stand as a complete invoice. The second point concerns the visual layer: when the PDF and the XML state different amounts, the data set governs, so anyone posting by hand should read the figures from the XML rather than from the printed page.

What happens with an incorrect invoice

If a mistake only surfaces after sending, the invoice is neither overwritten nor deleted. It stays as it is and gets a second document alongside it. In the data set the two differ by a single value: an invoice carries 380 in the TypeCode and a credit note carries 381, and the credit note additionally names the invoice it relates to. For accounting this is cleaner than any correction to the original, because the sequence of events stays traceable. In practice it means your software should issue a correction as an electronic document in its own right, not as a new PDF with the word cancellation in the subject line. Simple invoicing tools tend to lack this, so try it on a test invoice before deciding.

For archiving the rule is short. Keep the original file unchanged, in a way that preserves the embedded ZUGFeRD XML, and test on a sample whether your document archive lets the attachment through. A printout does not count and neither does a regenerated PDF copy. One more limit belongs here, because many invoicing programs share it: not every tool that writes e-invoices can read incoming ones. That applies to the cheaper plans of some accounting vendors, so when you compare tools it pays to look at issuing and receiving separately.

Conclusion: understand the format first, then choose the tool

ZUGFeRD is not a requirement but an answer to a transition in which half of your customers read structured data and the other half do not. As long as that holds, the hybrid format is the most convenient option in business-to-business invoicing. For public authorities the road runs through the XRechnung, and abroad the picture changes again, usually towards Peppol or towards the same file under the name Factur-X.

What to take away from this is less the technology than the one question to put to your software: which version and which profile does it produce. Version 2.0.1 or higher and at least the EN 16931 profile, and the foundation is sound. Everything else, from time tracking to the archive, is decided after that.