GmbH or branch office: what the decision means for your systems

The sequence is almost always the same: months of discussion about the legal form, then the formation, and then someone notices that the systems know nothing about it. The invoice template still names the foreign parent company, the imprint shows an address that no longer applies, and accounting receives documents it cannot assign to anything.

This article takes nothing away from the legal decision. Which form fits your case is for a law firm; what it means for tax is for a licensed tax practice. What follows is the part after that: what the decision, once taken, sets off inside your systems.

The decision is a data model, not just a register entry

A separate company and a branch of the same company look similar day to day and behave differently in software. With a separate company there is a second legal person: its own number ranges, its own bank account, its own bookkeeping, its own imprint. With a branch the legal person stays the same, and the systems have to distinguish between company and location without somebody correcting it by hand each time.

The practical test is mundane and still rarely run: can your system produce an invoice today showing the correct legal person, the correct address and the correct tax number, without anyone overwriting a field? If the answer is no, the legal-form decision has not reached the software yet.

Four places it shows up immediately

Invoices. Mandatory fields, number ranges and how tax is shown belong to the company, not the location. Two parallel number ranges without a clear assignment is the fastest route to accounting cleaning up afterwards.

Imprint and privacy notice. Both name a specific legal person and how it is represented. Anyone who does not touch the site after formation publishes something incorrect for months.

Document flow. Accounting needs not only the document but the information about which unit it belongs to. If that is not decided in the system, it gets decided in an email, and there it gets lost.

Contracts and payments. The account holder at your payment provider, the contracting party in your terms and the sender on the invoice should be the same entity. When they are not, the customer notices first.

Why the order usually goes wrong

Because formation is a project with an end date and adapting the systems is not. The notary appointment is in the calendar, the register entry arrives by post, and after that the matter feels finished. The system work has no such moment; it becomes a list of small tasks, each individually too minor to prioritise.

The way out is unremarkable: write the list before the formation, not after. If you know which four or five systems need to learn about the new entity, you can work through them in the week after the register entry rather than spreading it across a quarter.

What this has to do with e-invoicing

More than it first appears. A structured invoice is less forgiving than a PDF: fields a human would skip over cannot be ignored by a machine. If the legal person is not cleanly stored in the system, that surfaces on the first structured invoice, not the twentieth.

What that flow looks like technically is on the e-invoicing page. How the administrative part of formation runs alongside the digital part is under company formation.

Who decides what

We do not make the legal-form decision and we advise neither on tax nor on law. Formation and ongoing accounting run through our partner practice, regulated tax work is carried out by a licensed partner firm, and legal questions go to partner law firms. Our part is making sure the decision reaches the systems before the first customer notices it has not.

If this is where you currently are, a short look at market entry as a whole helps more than another legal-form comparison table.