XRechnung integration and ZUGFeRD for your shop, portal or custom software

What is XRechnung integration, and does your business need it now?

XRechnung integration is the work of teaching your own software to produce, check and read invoices in a structured XML format that a computer can process without a human retyping anything. If you invoice other German businesses, you need it soon; if you receive invoices, you already need a way to handle them.

The German VAT rules changed at the start of 2025. According to the Federal Ministry of Finance FAQ on the e-invoice, every domestic business has had to be able to receive an e-invoice since 1 January 2025, and a plain PDF no longer counts as one. Issuing follows in stages, so the pressure to act now depends on your turnover and on how many invoices you create by hand.

For most of the Mittelstand, the question is not whether XRechnung integration is needed but where it should live. A shop that already creates invoices can emit XML next to the PDF. A company that invoices from a custom portal or an older in-house tool has to add the same capability there. And on the purchasing side, supplier invoices now arrive as XML attachments that someone has to read and book.

This page walks through the formats, deadlines, build steps, costs and risks from the point of view of the people who write the code. It does not replace your tax adviser: they decide which invoices, which exemptions and which archive rules apply to you, and we build the system to match their answers.

Which e-invoice deadlines apply in Germany in 2027 and 2028?

Receiving has been mandatory since 1 January 2025; issuing becomes mandatory from 1 January 2027 for companies whose previous-year turnover exceeded 800,000 euros, and for all domestic B2B invoices from 1 January 2028.

The Federal Ministry of Finance describes three steps. During 2025 and 2026 every business may still send paper or other electronic invoices, the latter only with the recipient’s agreement. During 2027 that option remains for businesses whose total turnover in the previous year was at most 800,000 euros, and existing EDI procedures that do not meet the new definition may also continue until the end of 2027. After 31 December 2027 structured e-invoices become the rule for invoices between domestic businesses.

Two exceptions matter when you plan your XRechnung integration. Invoices for small amounts of up to 250 euros gross may still be issued in other formats, according to the same ministry FAQ. Consumer invoices are outside the B2B mandate, so a shop selling only to private customers has less to change on the outbound side, though it still receives supplier invoices.

• Since 1 January 2025: every German business must be able to receive e-invoices.
• 2025–2026: issuing other invoice formats is still allowed (other electronic formats need the recipient’s consent).
• From 1 January 2027: e-invoices required for issuers above the 800,000-euro prior-year turnover line.
• From 1 January 2028: e-invoices required for all domestic B2B invoices, apart from the small-amount exception.

Working back from those dates, a company above the threshold should have its XRechnung integration tested well before the end of 2026, leaving a quarter of real traffic to catch edge cases before the obligation starts.

XRechnung vs ZUGFeRD: which format should your software produce?

Produce XRechnung when the buyer is a public authority or explicitly asks for it; produce ZUGFeRD when your business customers still want a readable PDF but need machine-readable data too. Many German systems end up supporting both.

XRechnung is maintained by KoSIT, the coordination office for IT standards. According to xeinkauf.de, it implements the European standard EN 16931 in both mandatory syntaxes, UBL 2.1 and UN/CEFACT CII, and adds German rules on top. The current release there is version 3.0, with a 4.0 pre-release published in September 2026 and a final version expected in spring 2027. An XRechnung is pure XML: no picture of an invoice, just data.

ZUGFeRD, published by the Forum Elektronische Rechnung Deutschland (FeRD), is a hybrid. It embeds the XML inside a PDF/A-3 file, so the customer sees a normal invoice and their software reads the data. FeRD lists version 2.5.2 as the latest release, and the format is technically aligned with the French Factur-X. The ministry FAQ is specific: ZUGFeRD from version 2.0.1 counts as an e-invoice, except the MINIMUM and BASIC-WL profiles, which do not carry enough data.

For XRechnung integration in a custom system, we usually recommend generating one internal invoice object and writing it out in both forms. That keeps a single source of truth and lets each customer receive the format their software prefers.

How does XRechnung integration work inside your software?

It works as a short pipeline: collect invoice data, map it to EN 16931 business terms, write the XML, validate it, deliver it, and archive the original file. Each stage is small; the hard part is making your data complete enough for the first stage.

Because each stage is separate, you can replace one without touching the rest. When XRechnung 4.0 becomes final, for example, only the writer and the validator configuration should need an update.

How do you receive and process incoming e-invoices automatically?

Give suppliers one address or upload point, extract the XML from each message, read it into a draft booking and send it to a person for approval. That is the inbound half of XRechnung integration, and since 2025 it is the half every German business needs.

Incoming invoices arrive in three shapes: a plain XRechnung XML attachment, a ZUGFeRD or Factur-X PDF with XML inside, or an old-style PDF that is not an e-invoice at all. Our reader sorts them automatically. For hybrid files it pulls the embedded XML out of the PDF/A-3 container; for pure XML it identifies whether it is UBL or CII; for plain PDFs it can queue the document for manual entry or an AI extraction step, clearly marked as such.

Humans cannot read raw XML comfortably, so the system also renders a readable view. KoSIT publishes an open-source visualisation component (XSL transformations) for exactly this purpose, and we use it or build an equivalent view inside your admin screens.

From there, invoice data can become a draft booking in your ERP, a record in your purchase approval flow, or a batch for your Steuerberater via DATEV. The approval step stays with your team: software proposes, a person decides.

Validating XRechnung files with the KoSIT validator

Every serious XRechnung integration checks its own output before sending, and the free KoSIT validator is the reference tool for doing that. If your invoices pass it, public portals and most business recipients will accept the structure.

According to its GitHub repository, the validator is an Apache 2.0-licensed Java engine that needs Java 11 or later and can run as a command-line tool, be embedded through its API, or run in daemon mode as a small HTTP server. The repository is explicit that the engine has no rules of its own: you load a separate configuration, such as the XRechnung configuration, which carries the schema and Schematron rules for a given release.

In practice we run the validator in daemon mode beside your application, often in a small container. The invoice generator posts each file to it and reads back the verdict and the report. Rejections are logged with the exact rule that failed, which turns “the portal refused our invoice” into “line 4 has no unit code”.

We also add the KoSIT test suite examples to your automated tests, so a code change that breaks invoice output fails before deployment, not after a customer complains.

Invoicing public authorities: portals, Leitweg-ID and Peppol

If you supply federal authorities, XRechnung has been the expected format for years, and your integration must also handle registration and routing to the correct authority. This is the oldest part of German e-invoicing and the most tightly defined.

The federal E-Rechnungsverordnung requires suppliers to issue and transmit invoices to federal contracting authorities electronically; §3 exempts direct orders up to 1,000 euros. Under §4, suppliers use the XRechnung standard (or another EN 16931-conform format) and a federal administrative portal, and must register a user account there before sending. The portal checks each invoice automatically and accepts or rejects it, which is why validation on your side matters.

Public buyers identify the receiving office with a routing ID, usually called the Leitweg-ID, which goes into the buyer reference field of the XRechnung. Federal states and municipalities run their own rules and portals, and several accept delivery over the Peppol network. When a client has many public customers, we build a routing table so each invoice picks up the right identifier and channel automatically.

We do not register accounts on your behalf or act as your access point; you or your chosen Peppol provider hold those accounts, and our code connects to them.

How much does XRechnung integration cost?

With BtechWaleTech, custom XRechnung integration starts at US$900, and smaller automations around an existing invoicing tool start at US$600. The final figure depends on your data and channels, not on the XML format itself.

Quotes from different providers vary widely, and the difference usually comes from four questions. How many systems create invoices today? One shop is simpler than a shop plus an ERP plus a spreadsheet the office uses for services. Do you need inbound processing as well as outbound? Reading supplier invoices adds parsing, rendering and an approval flow. How many delivery channels? Email is simple; portal uploads and Peppol need more set-up and testing. And how clean is your master data? Missing VAT IDs, free-text units and inconsistent customer addresses cost more to fix than the generator costs to write.

We quote after seeing sample invoices, your data model and a list of customer types, and the quote is itemised so you can drop or postpone pieces. Tell us if you only need the 2027 outbound minimum now and inbound automation later; splitting the work is often sensible.

How long does an XRechnung integration project take?

A single-system outbound integration typically takes three to five weeks; a full loop with inbound parsing, approvals and several delivery channels takes six to ten. Your testing time and your tax adviser’s review are usually the longest waits.

The first week goes to discovery: sample invoices of every type you issue (normal, credit note, partial delivery, reverse charge, foreign customer), your data model and access to a staging copy. Weeks two and three cover mapping and the generator. Validation, test fixtures and delivery follow. Inbound processing is a separate block that can run in parallel once the internal invoice object exists.

We plan one full invoicing cycle of parallel running before switching off the old path: the system produces e-invoices, your team compares them with what went out the old way, and only then do customers receive the new files.

XRechnung integration for Shopware, WooCommerce, Shopify and custom portals

Check the platform’s own options first. Shopware, WooCommerce and Shopify all have extension ecosystems where e-invoice modules exist, and a well-maintained module is often the cheapest route. Custom XRechnung integration makes sense when the module cannot map your data or your invoices come from elsewhere.

Common reasons we are asked to build instead: invoices are created in an ERP rather than the shop; B2B customers need purchase-order numbers or cost centres carried into the buyer reference; the shop runs heavy customisations that break a generic module; or one company runs several shops that must share numbering and archive rules.

For Shopware, output can live in a plugin written for the current version. For WooCommerce, a small plugin hooks into order completion. For Shopify, invoices are generated in an external app that reads orders through the Admin API, because Shopify does not run custom server code inside the store. For custom portals, the generator is a module in your own codebase.

If you are still choosing a shop system, our Shopware vs Shopify comparison covers how each handles B2B needs like this.

Which invoice data breaks XRechnung validation most often?

Missing buyer references, free-text units, wrong VAT category codes and inconsistent totals cause most rejections. Fixing them is master-data work, and it pays off beyond e-invoicing.

• Buyer reference: required in XRechnung; public buyers expect their routing ID here, business customers often an order number.
• Unit codes: “Stk.” or “pcs” must become standard UN/ECE unit codes.
• VAT categories: standard rate, reduced rate, reverse charge and intra-EU supplies each need the correct code and exemption reason.
• Rounding: line totals, allowances and the invoice total must add up exactly under the standard’s calculation rules.
• Seller contact data: XRechnung asks for a contact person, phone and email for the seller.
• Payment details: IBAN, payment terms and due date in structured fields, not only in a footer text.

During discovery we run your last few months of invoices through a draft mapping and list every gap. That list, rather than guesswork, drives the quote.

Technology choices: libraries, languages and where the code runs

Use the language your system already runs on, keep XML generation in a library rather than string templates, and run validation in Java because that is what the KoSIT tool needs. That combination keeps XRechnung integration maintainable.

Open-source e-invoice libraries exist for PHP, Java, .NET, Python and Node.js; we choose one after checking its release history against current XRechnung and ZUGFeRD versions. A library that has not followed the last format release is a liability, not a saving.

Where the code runs matters for data protection. Invoices contain names, addresses and bank details, so the generator and validator should run on your own servers or cloud account, ideally in an EU region. We set this up on your hosting; the invoices never pass through our machines. For the privacy side of your website more generally, see our notes on a GDPR-compliant website.

We also keep the format version configurable, because KoSIT now plans one release a year and each release has a defined validity window.

Risks and red flags in e-invoice projects

The biggest risk is treating e-invoicing as a file-format task and ignoring process, archive and exceptions. The second is choosing a provider who cannot show validated sample output from your own data.

• A provider who promises “fully compliant” without mentioning your tax adviser.
• Generated XML that has never been run through the KoSIT validator.
• No plan for credit notes, corrections or cancelled invoices.
• Invoices sent from a system that stores only a re-generated copy instead of the original file.
• Inbound PDFs silently treated as e-invoices when they carry no XML.
• No owner for format updates once XRechnung 4.0 and later releases arrive.
• Code or credentials held in the provider’s accounts rather than yours.

Ask any candidate, including us, for a validated sample built from one of your real invoices before signing a larger scope.

Working with a remote XRechnung integration team in India from Germany

India is three and a half hours ahead of German summer time and four and a half ahead in winter, so our working day overlaps with yours from late morning through the afternoon. Calls fit comfortably into that window, and WhatsApp messages get answers seven days a week.

Billing is simple: the quote is in USD, and you pay in USD or EUR by Wise or bank wire, with invoices issued from India. Please ask your own accountant how a foreign supplier invoice is treated for your VAT return; we do not advise on that.

Ownership is set from day one. Your Git repository, your hosting account and your validator server; we work inside them with access you can revoke. The written quote describes scope, milestones and how changes are handled, and our terms set out the general rules.

The first two weeks look like this: a kick-off call, a shared list of sample invoices and customer types, staging access, and by the end of week two a draft field mapping plus the first validated XML built from one of your real invoices. You see working output before most of the budget is spent.

Worked example: XRechnung integration for a hypothetical parts wholesaler

Picture a fastener wholesaler in Bielefeld, hypothetical but typical: turnover well above the threshold, a Shopware store for small orders, an ERP for key accounts, and a few municipal customers. Its XRechnung integration would need three outputs and one input.

Discovery would show two invoice sources and around a dozen invoice variants. We would build one shared invoice object fed by both systems, write ZUGFeRD PDFs for business customers who like a visual copy, and XRechnung CII for the municipalities, with each municipality’s routing ID stored in its customer record. The validator would run as a container next to the ERP.

Inbound, the purchasing team would get one invoice address. Supplier XML would become draft entries that the office approves before they go to the Steuerberater as a DATEV batch.

Rough plan: discovery and mapping in two weeks, outbound generation and validation in three, inbound reading in two more, then a full month of parallel running. Pricing would start at US$900, with the exact figure depending on the variant list found in discovery. This is an illustration, not a past project.

Does e-invoicing touch your website, SEO or AI-search visibility?

Only indirectly. XRechnung integration runs behind the scenes, but B2B buyers increasingly ask suppliers whether they can send e-invoices, and saying so clearly on your website helps procurement teams and AI assistants answer that question in your favour.

A short, factual page stating which formats you send and receive, which channels you support and how customers submit their routing ID reduces support emails and gives search engines and AI answer engines something specific to cite. We can add such a page with structured FAQ markup as part of a wider site project, and monthly SEO starts at US$150/mo. Nobody can guarantee rankings, but clear, specific answers are what these systems quote.

XRechnung integration checklist before you go live

Run through this list with your team and your tax adviser before the first real e-invoice leaves your system. Every item should have a named owner.

• All invoice sources identified, including manual office invoices.
• Field mapping to EN 16931 reviewed and approved by your adviser.
• Buyer references and routing IDs stored for every customer that needs them.
• Unit codes, VAT categories and payment terms cleaned in master data.
• Every outbound file passes the KoSIT validator with the current configuration.
• Credit notes, corrections and cancellations tested end to end.
• Inbound mailbox live, with XML extraction and a readable view.
• Original files archived unchanged with delivery records.
• One invoicing cycle of parallel running completed and compared.
• An owner named for yearly format updates.