E-invoicing for municipal utilities: Why XML alone is not enough

An invoice can be unique for processing and still raise questions during automated processing. The address window shows the recipient of the correspondence. Elsewhere, the recipient of the service is named. Which of these details belongs in the structured invoice record?

It is at such points that it is decided whether an e-invoice works in everyday life. The target format is necessary. The more demanding task, however, is to correctly adopt the technical significance of the existing information.

For municipal utilities and other utility companies, it is therefore worthwhile to take a closer look before a major restructuring of billing: What information does the existing system already provide? What is in the PDF outgoing invoices? And what rules are missing to make it a reliable structured process?

The target format does not yet solve the assignment question

EN 16931 describes a semantic data model for the core elements of an electronic invoice. It is therefore about the meaning of invoice information and its relationships. XRechnung specifies this basis for defined application requirements. Any XML file is therefore not yet XRechnung. XStandard's Purchasing

With ZUGFeRD, there is also the choice of profile. Not every profile covers the same content; the name "ZUGFeRD" alone does not imply blanket EN-16931 conformity. If you  want to classify the differences between XRechnung, ZUGFeRD and Peppol, you should consider the data format, profile and transmission path separately. FeRD

The industry perspective begins where this structure meets the actual bill. For example, for electricity and gas bills, the Energy Industry Act requires information on the point of consumption, consumption and billing period. At the same time, the bill should be understandable to people. These requirements explain why their information cannot simply be reduced to the invoice number, total amount and bank details. Laws on the Internet

Where the subject-specific assignment is decisive

The address in the address window is not automatically the buyer

Correspondence recipient, VAT recipient and place of supply can be different. The data model distinguishes between invoice parties and delivery information. However, this does not mean that every address found in the PDF fits unchanged in a standard field of the same name. XStandards Purchasing

A typical point of clarification is an invoice that explicitly identifies a service recipient in addition to the address window. The processing department must know which information is decisive for the buyer role and which is only used for shipping. A consumption point address, in turn, answers another question.

This assignment should be determined by the specialist department. The position of an address on the page is a distinguishing feature, but not sufficient technical proof of its role.

Free text can be important from a technical point of view

An invoice notice at the bottom of the page can be more important for processing than its design suggests. A tax notice is to be treated differently from a general explanatory text or a description of a point of consumption.

XRechnung provides invoice notes in the BT-22 field. A corresponding subject code in BT-21 can identify your item. This is useful, but does not automatically turn any text into a complete structured tax or address information. XStandard's Purchasing

The task is therefore not: "Place all text blocks somewhere in the XML." It is: Recognize what information the text contains and assign it appropriately. Where the target model provides its own fields, a collection field for notes is not an equivalent substitute. It is precisely this distinction that becomes important if structured invoice data is to be created from a PDF.

Performance periods must fit the right level

A period for the entire invoice and a period for a single item perform different tasks. The invoice model knows both levels. If they are found in the PDF, the processing must not equate them or overwrite each other without looking at them. Peppol Documentation

If an item contains its own performance period, this must be retained in connection with the item. A project-specific recognition rule can determine which reference is to be read. However, this does not become a general standard rule according to which item information always supersedes all information at document level.

Similarly precise attention should be paid to quantities and units. The structured invoice item requires a quantity and a suitable unit code. A number read from the PDF can only be used when it is clear what it measures. Customer-specific designations therefore need a technically comprehensible assignment to the intended codes. Peppol Documentation

A tax amount of zero does not declare a tax case

Zero tax rate, tax exemption and the tax liability of the recipient of the service are different facts. In the relevant code lists, they are differentiated accordingly, for example by Z, E and AE. Category S stands for regular taxation with an applicable tax rate; it is not simply another word for "19 percent". Peppol Documentation

For the conversion, this means that no tax category may be derived from a missing tax amount or one shown as zero. A technically approved basis from the invoice or from supplementary data is required.

In addition, item information, tax breakdown and totals must match. A file can contain formally well-formed XML and still violate such business rules. The software is intended to map and check a defined tax treatment, not to make a tax decision itself. Peppol Documentation

Several pages remain one invoice

In the case of multi-page documents, the summary may be in a different place than the items or the tax statement. For processing, it is not the individual page that is the decisive unit, but the technical context of the invoice.

This also applies to supplementary documents. The data model offers options for integrating or referencing documents accompanying invoices. Which variant can actually be used also depends on the target profile and the acceptance process of the recipient. Peppol Documentation

However, an attachment is not a blanket substitute for structured mandatory information. The Federal Ministry of Finance distinguishes between the required invoice information and supplementary details; special regulations apply to certain billing cases. A mere reference "see PDF" is therefore not a general solution for missing structured content. Federal Ministry of Finance

For an implementation project, this separation should be clear at an early stage: What belongs in the invoice data record, what serves as an explanation, and how do the two parts remain clearly connected?

A generated file is not yet an accepted invoice

The outgoing invoice also includes the transfer. A processing result, a successful technical transmission and acceptance by the recipient are different states. This separation can also be found, for example, in Peppol's status concepts. Peppol Documentation

Therefore, a project should not end with the storage of the finished file. Comprehensible references, understandable error messages and an agreed handling of rejected documents are required. In the case of time-delayed processing, it must also be possible to see whether an order is still being processed or whether a result is already available.

Some of the required information can be provided outside the PDF. Depending on the recipient, this includes, for example, routing information. The routing ID is not a general mandatory feature of every B2B invoice, but is particularly relevant for invoicing public recipients. E-invoice federal government

When the existing PDF is a useful starting point

These requirements do not automatically mean that the billing system must be replaced first. If a system reliably generates recurring PDF invoices, downstream processing can extract the required information from them, assign them professionally and transfer them to the agreed e-invoice format. The prerequisites are suitable documents, defined rules and controlled handling of exceptions. PEDIF

The advantage of this approach lies in the separation of tasks: The existing system remains responsible for billing. The additional processing prepares the output for structured exchange.

This means that the PDF itself does not subsequently become an e-invoice. The structured data set generated and transmitted from it is decisive. In the case of hybrid formats such as ZUGFeRD, the readable representation and the XML data must match; in the event of deviations, the structured part is decisive. FeRD

Before making a decision, however, it should be checked whether the source system can already provide suitable structured data. If these are complete and easily accessible, additional extraction from the PDF is not automatically the better way.

How PEDIF complements existing outbound processes

We are familiar with such allocation issues from projects with several city and utility companies. PEDIF's PDF-to-e-invoice approach starts with the existing outgoing invoices and examines how a defined structured process can be created from them.

At the beginning there are representative receipts. This is not only about the most beautiful invoice template, but also about the variants that regularly cause work for the specialist department: different address roles, additional information, different periods of time or supplementary documents. The rules for recognition, assignment and verification are derived from this. PEDIF

It is then determined how documents and, if necessary, supplementary metadata are processed. Depending on the project, this can be done via SFTP, an API or integration into an existing portal process. Preliminary checks, for example on the authorized business unit, are also part of the process agreement.

Only then does the actual output process emerge: record data, assign it professionally, take over the necessary additions from defined sources, generate the target profile and validate the result. Abnormalities need defined feedback instead of being sent unnoticed.

PEDIF is intended to complement existing ERP and EDI processes, not replace their technical tasks. Which invoice sources, variants and transfer channels are included must be determined for the respective application. PEDIF

The boundaries should be visible before take-off

A meaningful aptitude test considers more than the recognition quality of a sample document. It should show whether the necessary data is available, what deviations occur and who decides on cases of doubt.

Dealing with missing information is particularly important. A technical item identifier can be assigned on a rule-based basis. A missing quantity of services, an unclear buyer role or a tax classification, on the other hand, cannot be made technically correct by any standard value. This requires a reliable source or clarification.

Layout changes are also part of the planning. Who is responsible for new invoice templates? How can it be recognized that a previous assignment no longer fits? And how are affected documents treated until they are approved? Such questions are not a counterargument against automation, but part of a sustainable operating model.

For the selection, a joint test by billing, finance and IT is therefore recommended. The specialist side assesses the importance of the data. IT checks the connection and operation. A successful format check does not replace this joint acceptance.

Examine the current legal framework separately

The B2B e-invoice obligation for VAT purposes does not apply across the board to every utility company's invoice. Private customer invoices must be distinguished from this; public contracting authorities have their own requirements. Laws on the Internet

As of October 2026, the general transitional rule still allows other invoices for 2025 and 2026 transactions if transmitted by the end of 2026; electronic PDF invoices require the consent of the recipient. For 2027, extended regulations apply with a maximum turnover of 800,000 euros in the previous year as well as for certain EDI procedures. Companies should examine exceptions and the specific use case separately. Laws on the Internet

The correct translation of the invoice logic is crucial

For utility companies, e-invoicing is primarily a task at the interface between business and technology. A correct target format is of little help if the wrong address has been taken over as the buyer or a service period has been inappropriately assigned.

The pragmatic starting point is therefore one's own invoice reality. If existing PDFs reliably contain the necessary information, supplementary processing can be a suitable way. If data is missing or is already available in a more structured way, the solution must look different. This distinction should be made before implementation – not after the first rejection.

Does the PDF approach fit your billing?

Would you like to check whether your existing PDF outgoing invoices can be converted into structured e-invoices without fundamentally restructuring the billing system? The decisive factors are your invoice variants, the existing data and the requirements of your recipients.

To the PEIF approach for utilities

Frequently asked questions about e-invoicing at municipal utilities

Does a municipal utility have to replace its billing system for this?

Not necessarily. Supplementary processing may be suitable if the existing system delivers reliable PDF output. Whether this method makes more sense than direct structured output depends on data quality, interfaces and invoice variants. PEDIF

Is every ZUGFeRD invoice automatically a suitable e-invoice?

No. Profile and actual content are decisive. In particular, MINIMUM and BASIC WL do not contain the full scope of a VAT e-invoice. Even with suitable profiles, the specific data and recipient requirements must be checked. FeRD

Can missing information simply be added automatically?

Only if there is a reliable source or a technically permissible, approved rule. Technical identifiers are something different from missing quantities, performance data or tax information. Arbitrary substitute values do not make a calculation correct.

Does every outgoing invoice need a routing ID?

No. For ordinary B2B invoices, there is no general routing ID requirement. For invoices to the federal government, the routing ID specified by the recipient is used for assignment. Other recipient references and acceptance requirements must be observed separately. E-invoice federal government

Does a successful validation prove tax accuracy?

No. It examines technical specifications and the implemented business rules. It cannot confirm that a service has actually been provided or that a fact has been classified in a tax-correct manner. Technical examination and tax responsibility remain separate from this. Federal Ministry of Finance

This article describes technical and organizational contexts. It does not replace individual legal or tax advice.