ERP and accounting software for Germany — XRechnung, ZUGFeRD, GoBD and HGB

The receiving obligation is already live, and it is the one people miss

Most coverage of the German transition talks about 2027 and about issuing. That is the visible half. The half already in force is the other one: for domestic business-to-business supplies, a German business has been required to be able to receive a structured electronic invoice since 2025. No announcement lands on your desk when this starts to bite; a supplier simply sends one.

The awkward part is that a business can appear to be coping while not actually complying. A structured invoice arrives, somebody opens it, reads the numbers off the screen and types them into the purchase ledger. The document has been received in the ordinary sense of the word, but the data has been re-keyed, which reintroduces exactly the transcription risk the format exists to remove.

Receiving properly means the file is taken into the system as data: supplier, invoice number, dates, line detail, tax amounts and totals populate the purchase invoice without anyone typing them, the original file is retained as the record, and the match against the purchase order and the goods receipt happens on the data rather than on a reading of the PDF.

If you do only one thing before 2027, make it this. The receiving side is already required, it is entirely within your control, and it is the part of the change that produces an immediate reduction in work rather than a compliance cost.

• Accept XRechnung XML and ZUGFeRD files without manual re-keying
• Populate the purchase invoice from the file, not from a reading of it
• Retain the original file as the record, alongside the posting
• Match to purchase order and goods receipt on the structured data
• Flag files that fail validation instead of silently accepting them

What is actually phased from 2027

The issuing obligation arrives in stages from 2027 rather than all at once, and the staging is a concession to the fact that not every business can rebuild its invoicing in the same year. What it means in practice is that for a period, different German businesses will be under different obligations at the same time, and some of your customers will be able to insist on a structured invoice before others.

That transitional asymmetry is the operational problem. You will have customers who require structured invoices and customers who do not, and possibly suppliers on both sides of the same line. A system that can only do one or the other forces you to run two processes; a system that holds the requirement against the customer record and produces the right document for each of them does not.

Do not plan against a date you read on a vendor site, including this one. The phasing calendar belongs to the German tax administration, and the date that applies to your business depends on facts about your business. Confirm it with your Finanzamt or your Steuerberater and plan from that.

What is safe to plan is capability rather than timing: master data clean enough to produce a valid structured invoice, tax recorded at line level, and an issuing process that can be switched on per customer. None of that is wasted if the calendar moves.

• Different businesses under different obligations during the phase-in
• Some customers able to require a structured invoice before others
• The requirement held against the customer record, not remembered
• Issuing switchable per customer rather than all at once
• Your own date confirmed with the Finanzamt or your Steuerberater

XRechnung, ZUGFeRD and EN 16931 in plain terms

EN 16931 is the European standard that defines what an electronic invoice has to contain and what each element means. It is a semantic model rather than a file format: it settles which fields exist and what they signify, so that a system in one country can understand a document produced in another. Both German formats are aligned to it.

XRechnung is XML. There is no document to look at without a viewer, which is the intention rather than a limitation, because it is meant to be read by systems. ZUGFeRD is the hybrid answer to the human problem. The file is a PDF that a person can open and read, and the same invoice is carried inside it as structured data for the receiving system.

Which of the two you use is largely a question of what your counterparties want and what your sector does. The important thing from a system perspective is that both are produced from the same underlying invoice record, so that the document your customer receives and the document in your ledger cannot diverge.

It also follows that structured invoicing is a data-quality project before it is a formatting project. A format aligned to a semantic standard will reject or misrepresent an invoice whose customer identifiers, tax detail or totals are incomplete. Most of the work of getting ready is in the master data, not in the export.

• EN 16931: the European semantic model both formats follow
• XRechnung: XML, machine-readable only
• ZUGFeRD: a readable PDF carrying the same invoice as data inside it
• Both produced from one invoice record, so the copies cannot diverge
• Complete customer and tax master data is the real prerequisite

GoBD is the requirement that shapes the system

Formats change; GoBD sets the terms a German finance system has to live under. Books and records kept electronically must be complete, correct, recorded in good time, orderly and unalterable, and they must remain available and readable for the applicable retention period. Every one of those words has a system consequence.

Unalterable is the demanding one. It does not mean that a mistake can never be corrected; it means that the correction has to be visible. A posted document is not edited in place and is not silently deleted. It is reversed or amended by a further entry, and both the original and the correction remain, with a record of who made it and when.

Recorded in good time and orderly are equally practical. A month of invoices entered in a single evening before the return is due does not satisfy the first, and a ledger where documents cannot be located from the entry does not satisfy the second. These are the conditions under which a system is either a help or an obstacle at audit.

Skyline Nexus posts documents that cannot be edited in place, records corrections as further entries with the user and timestamp, keeps the source document attached to the posting, and holds the audit trail as data rather than as a log file. The retention period that applies to your records, and whether your particular processes satisfy GoBD, are questions for your Steuerberater and the tax administration.

• Posted documents corrected by reversal or amendment, never overwritten
• User and timestamp recorded on every change
• Source documents retained with the posting they support
• Entries locatable from the ledger and the ledger from the entries
• Records readable for the retention period, not locked in a dead format

Two rates, and the ordinary German VAT questions

The German standard rate of VAT is 19%, with a reduced rate of 7% applying to certain supplies. That is the easy part. Which rate applies to a given supply, how a mixed supply should be treated, and how cross-border transactions inside and outside the European Union are handled are questions of tax law that a software vendor is not in a position to answer for you.

The system requirement is consistency and evidence. Tax should be determined at line level and stored with the transaction rather than derived at the document total, because a single invoice can legitimately carry both rates. Rate changes should be dated, so that historical documents keep showing what was actually charged rather than being retrospectively rewritten.

Structured invoicing raises the stakes on all of this. When the tax detail leaves your building as data in a standard format, an inconsistency between the line detail and the invoice total is not a presentational untidiness that a reader will overlook. It is a defect in the document, and the receiving system may treat it as one.

For the treatment of any specific supply, and particularly for cross-border cases, take advice from your Steuerberater or confirm with the Finanzamt. Configure the answer into the system once it is settled; do not let a system imply an answer it is not qualified to give.

• A standard rate of 19% and a reduced rate of 7%
• Both rates capable of appearing on the same invoice
• Tax determined at line level, not derived from the document total
• Rate changes dated, so historical invoices keep their original rate
• Cross-border treatment confirmed with your Steuerberater

HGB, IFRS and one ledger that serves both

German individual accounts are generally prepared under the Handelsgesetzbuch, while listed groups in the EU report under IFRS as adopted by the European Union. Many German groups therefore live with both: HGB accounts for the individual entities and an IFRS view for the consolidated statements.

The two frameworks do not merely present the same numbers differently. They take different views of when revenue arises, how assets are measured and how provisions are recognised, so the differences begin at the transaction rather than at consolidation. A system that records only a net effect has already thrown away the detail needed to produce the second view.

The practical answer is a chart of accounts and a set of posting dimensions detailed enough to support both views from the same entries, with framework differences recorded as adjustments that can be listed and explained rather than as a parallel ledger maintained by hand.

German practice is also unusually attached to a structured chart of accounts, and a system should let your account structure follow the convention your Steuerberater works with rather than imposing an internal scheme of its own. Which framework applies to which entity in your group is a question for your auditor.

• Individual accounts generally under the Handelsgesetzbuch
• Listed EU groups under IFRS as adopted by the European Union
• Differences that begin at the transaction, not at consolidation
• One detailed ledger rather than a parallel set of books
• An account structure your Steuerberater recognises

What structured invoicing does to your master data

The most common reason a German e-invoicing project runs late is not the format. It is that the customer file, built over years by people in a hurry, contains records that were adequate for a printed invoice and are not adequate for a structured one: missing identifiers, addresses living in a free-text note, tax treatments held in somebody's head.

A printed invoice tolerates all of that, because a human reads it and fills the gaps from context. A structured invoice does not. The receiving system has only the fields, and a field that is empty or wrong is not compensated for by the rest of the document being sensible.

This is why readiness work should start with a data review rather than a software demonstration. Take a hundred recent invoices, list every field a structured format requires, and check how many of the hundred could be produced completely from what you currently hold. The gap between those two numbers is your project.

The same review protects the receiving side. A supplier record with no reliable identifier makes automatic matching of an incoming structured invoice unreliable, which means the invoice ends up on somebody's desk again and the benefit of the format is lost.

• Customer and supplier identifiers complete and verified
• Addresses held as fields, not as free text
• Tax treatment held on the item or customer record, not remembered
• Units, quantities and prices consistent enough to survive validation
• Payment terms and bank details recorded where the document can read them
• A sample of a hundred real invoices tested against the required fields

Sequencing the work before 2027

There is a natural order to this, and it is not the order most projects follow. First, make receiving genuinely work, because it is already required and it pays for itself. Second, clean the master data, because everything after it depends on that. Third, produce structured invoices for the customers who want them now. Fourth, switch issuing on generally when your phase arrives.

Running the stages in that order means that by the time the issuing obligation applies to you, the only new thing is a switch. Running them in the opposite order, which is what happens when a project is organised around the 2027 headline, means doing the data work under time pressure with an authority-imposed date attached to it.

Test with real counterparties rather than in a sandbox alone. A file that validates against a schema and a file that your customer's system actually accepts and posts are not always the same file, and the difference tends to surface in details of identifiers and references that only appear with a real trading partner.

Keep a record of what you did and when. If a question later arises about the point at which your business became able to receive or to issue structured invoices, that is easier to answer from a project record than from memory.

• Make receiving genuinely work first; it is already required
• Clean the master data before anything depends on it
• Issue structured invoices to the customers who want them now
• Switch issuing on generally when your phase arrives
• Test with a real trading partner, not only against a schema
• Keep a dated project record of what became possible when

Multi-entity German groups and cross-border operations

German businesses of moderate size are frequently several entities, often an operating company and a holding company, sometimes with subsidiaries elsewhere in the European Union or outside it. That makes intercompany transactions, consolidation and a shared chart of accounts ordinary requirements rather than advanced ones.

Cross-border trade adds currency and treatment. A transaction should be recorded in the currency it happened in, with the rate applied and the date it applied, so that the difference realised on settlement can be explained rather than reconstructed. Intra-EU and third-country supplies should be reportable separately rather than folded into a domestic total.

Skyline Nexus records transactions in their original currency with the applied rate, carries entity and location as dimensions on the posting, holds the tax treatment on the line, and keeps the structured invoice file with the transaction it belongs to. It does not determine your tax position and it is not certified for any German regime; those remain matters for your adviser and the tax administration.

The other thing a group structure needs is that the same transaction is not entered twice. Where a shared service function raises invoices on behalf of several entities, or where stock moves between them, the intercompany entry should be produced by the system from the transaction rather than journalled afterwards by someone reconciling two ledgers that were never designed to agree.

• Several entities, one chart of accounts, separate statutory outputs
• Intercompany balances that agree in both directions
• Original currency and rate stored on the transaction
• Domestic, intra-EU and third-country supplies separately reportable
• Structured invoice files retained against their postings

Questions worth asking a vendor in Germany

Ask to see an incoming XRechnung file taken into a purchase invoice without anyone typing, and then ask what happens when the file is malformed. The second answer is more revealing than the first, because failure handling is where thin implementations are exposed.

Ask to see a posted document corrected, and watch whether the original survives. Ask where the source file is stored and for how long. Ask how the system behaves if a rate changes mid-year and last year's invoices need to keep showing last year's rate.

Be careful with the word certified. No accounting system can certify your compliance with GoBD, because GoBD applies to how you keep your records and not only to the software you keep them in. A vendor who claims otherwise is describing something they cannot deliver.

Where an answer has legal consequences, confirm it with the Bundeszentralamt für Steuern, your local Finanzamt or your Steuerberater. A software vendor, including this one, is not a source of tax authority.

• An incoming XRechnung posted without anyone typing
• What the system does with a malformed file
• A posted document corrected with the original still visible
• Where the source file is stored, and for how long
• How a mid-year rate change affects last year's documents
• No claim of certified GoBD compliance, because none is possible

Common questions

Is e-invoicing mandatory in Germany?

Partly, and the part already in force is the one most businesses overlook. Since 2025, being able to receive structured electronic invoices for domestic business-to-business supplies has been mandatory. The obligation to issue them is phased in from 2027. Confirm the phase and the date that apply to your business with your Finanzamt or your Steuerberater.

What is the difference between XRechnung and ZUGFeRD?

XRechnung is pure XML, meant to be read by systems rather than by people. ZUGFeRD is a hybrid: a readable PDF that carries the same invoice as structured data inside it. Both are aligned to EN 16931, the European standard defining what an electronic invoice contains. Which you use depends largely on what your counterparties expect.

Does a PDF invoice count as an electronic invoice in Germany?

Not on its own. A PDF produced by printing to file, or a scan of a paper document, is an image of an invoice and carries no structured data. A ZUGFeRD file is also a PDF, but it carries the invoice as data inside it, and that is what makes it structured. The distinction is between a document to read and a document to process.

What does GoBD require of an accounting system?

GoBD governs how electronic books and records are kept: complete, correct, timely, orderly, unalterable and available for the applicable retention period. In practice that means posted documents are corrected by further entries rather than edited or deleted, changes carry a user and a timestamp, and source documents stay attached to their postings. The retention period that applies to you should be confirmed with your Steuerberater.

Which accounting framework applies to a German company?

Individual accounts of German entities are generally prepared under the Handelsgesetzbuch, while listed groups in the EU report under IFRS as adopted by the European Union. Many groups need both views from the same transactions, which is a reason to keep the ledger detailed rather than summarised. Which framework applies to your entity is a question for your auditor.

Rates, regimes and deadlines in this summary change, and many countries are actively legislating on e-invoicing. This is general information, not tax or legal advice — confirm the current position with the authority named above or with your tax adviser before you rely on it.