The first invoice to a German customer
It looks like any other invoice and it is not. Mandatory fields, how tax is shown, the number range and the format decide whether it gets paid or sent back.
The first invoice to a German customer is rarely a sales problem and often a form problem. It goes out, looks complete, and comes back with a polite request for correction. Not because the amount is wrong, but because a detail is missing that nobody in your home market ever asked for.
The invoice is a document with mandatory fields
In many markets an invoice is essentially a request for payment. In Germany it is also a record that has to withstand bookkeeping. From that follows a list of details that must be present, and a number range that stays complete and traceable.
The most common gaps for companies new to the market: an incomplete address for the supplying company, a missing or incorrectly presented tax statement, a number range that restarts at one with every system change, and a service period that appears nowhere. Each is trivial to fix and expensive once it surfaces after fifty invoices.
The number range matters more than it looks
It feels like a formality and is in fact the thread traceability hangs from. Two systems numbering independently produce duplicates. Switching invoicing tools without carrying the range over produces gaps. Neither is noticed by the customer; both are noticed later, when someone wants to check the sequence from outside.
The simplest rule: one range per company, issued in exactly one place, with every other piece of software asking that place rather than counting for itself.
Then the format arrives
On top of the content layer comes the structural one. An e-invoice is not a prettier PDF but machine-readable data: XRechnung as XML, ZUGFeRD as a PDF with embedded XML. What a person skims past, a machine cannot, which is precisely why moving to a structured format brings every content gap to light at once.
That is uncomfortable and useful in the end. If the mandatory fields are clean before the switch, the switch is a format question. If they are not, it is an inventory.
The route to accounting is part of it
A correctly generated invoice sitting as an email attachment in a mailbox is only half finished. The second half is the route into accounting and an archive that survives a later audit. If a human carries that route, the chain breaks exactly when that human is on holiday.
What the flow looks like once built properly is on the e-invoicing page. Why the legal form decides who even appears on the invoice is in GmbH or branch office.
What we do here and what we do not
We build the flow: generation in the correct format, handover to accounting, audit-proof archiving, connection to the existing ERP. What is correct for tax purposes is decided by a licensed practice, not by us. That separation is not caution; it is the condition under which both sides can do their work properly.
If you are preparing the first invoice right now, it is worth looking at market entry as a whole: the invoice is usually the point where every other open question converges.