Section 1
The artifact: the weekend sequence
Here is the whole job as a checklist. The rest of the article explains each row. Work top to bottom. Receiving comes before sending on purpose, because receiving is the obligation that already applies and sending is the one you still have runway on. That is roughly half a day of actual work, spread across a weekend so nothing is rushed. Now the detail.
Section 2
Step 1: Confirm your real deadline
Your sending deadline depends on turnover. If your prior-year turnover is 800,000 euros or less, you may keep sending paper or PDF (with the recipient's agreement) through the end of 2027, and must send e-invoices from 2028. Above that line, the send date is 2027. Everyone, regardless of turnover, must already be able to receive. Write your date on the checklist. It changes your urgency on sending, but not on receiving, which is why receiving is step 3 and not step 7.
Section 3
Step 2: Pick or confirm your software
Do not build anything. The market has solved this. Tools built for German small firms (lexoffice, sevDesk, DATEV, and others in that category) read and produce compliant e-invoices as a standard feature. If you already use one, your job in this step is to confirm it supports XRechnung and ZUGFeRD, which almost all of them now do. If you are still on Word or Excel invoice templates, this is the moment to leave them. They cannot produce a structured e-invoice, and as the survival brief notes, an editable document is also a GoBD problem. Choosing a proper invoicing tool fixes two obligations at once. Selection rule for the non-technical: pick the tool your Steuerberater already receives data from. If your advisor works in DATEV, a tool that exports cleanly to DATEV removes friction from the handoff (the Steuerberater bottleneck is its own topic, angle 8.11). Compatibility with your advisor beats a marginally cheaper standalone tool.
Section 4
Step 3: Set up receiving first
This is the obligation already in force, so it goes first. You need two things: • An inbox that can receive the file. A dedicated invoicing email address ([email protected]) is cleaner than mixing e-invoices into your general inbox, but a normal inbox works. The XRechnung arrives as an XML file, the ZUGFeRD as a PDF with XML inside. • A GoBD-conform archive. The received file must be stored unaltered, retrievable, and kept for the retention period. Your invoicing software's inbound-document feature usually does this for you. If not, a dedicated document-management archive does. What does not count is "it is somewhere in my email," because that is neither reliably unaltered nor reliably retrievable. Test it: have a supplier or a colleague send you an XRechnung, or generate a sample, and confirm you can open it, read the contents, and find it again in your archive a week later. When that works, the already-live obligation is met.
Section 5
Step 4: Choose ZUGFeRD or XRechnung for sending
Two compliant formats, and the choice is genuinely simple. • ZUGFeRD is a PDF a human can read with the machine-readable XML embedded inside. Your customer sees a normal invoice whether or not their system processes the data. For a small firm sending to a mix of customers with varying sophistication, this is the low-friction default. • XRechnung is pure XML, no human-readable layer without a viewer. It is the standard for invoicing public bodies (B2G) and is fully valid for B2B. Choose it if your customers specifically ask for it or you invoice the public sector. For most small B2B firms: default to ZUGFeRD, and switch specific customers to XRechnung only when they request it.
Section 6
Step 5: Enter your master data correctly
An e-invoice is rejected when required structured fields are wrong or missing, and the usual culprit is master data entered carelessly once and propagated forever. Get these right: • Your full legal company details and tax numbers (Steuernummer and, where relevant, USt-IdNr). • Correct customer data, including their VAT ID for the relevant transactions. • Correct tax rates and a clean line-item structure. One myth to kill: the Leitweg-ID (a routing identifier) is a public-sector B2G requirement. For ordinary B2B invoices you do not need one, and hunting for it is a common way small firms waste an afternoon.
Section 7
Step 6: Issue one test invoice and check it
Produce a single e-invoice inside your tool and validate it. Most tools have a built-in validation, and free EN 16931 validators exist online if you want a second check. You are confirming the file is structurally valid and the numbers match what you intended. Fix any flagged field now, while it is one invoice and not fifty.
Section 8
Step 7: Send one real invoice to a willing customer
Pick a friendly, patient customer and send them a genuine e-invoice. Ask them to confirm their system accepted it. This is the step that turns "it works in the tool" into "it works in the world," and it surfaces the practical snags (their email filter, their format preference) while the stakes are one invoice.
Section 9
Step 8: Write the two-paragraph process note
You changed how invoices are made and stored, so your Verfahrensdokumentation (the GoBD process description) should reflect it. Two honest paragraphs: what tool you now use, what format you send, how received e-invoices are archived and for how long. File it with your bookkeeping documentation. This closes the loop between the e-Rechnung switch and your GoBD obligations, so the same weekend satisfies both.
Section 10
Common rejections and quick fixes
When a real e-invoice bounces, it is almost always one of a short list of causes. Keep this next to the checklist so a rejection costs minutes instead of an afternoon. None of these needs a technician. They are configuration and habit, which is why the boring steps (5 and 3) prevent most of them before they happen.
Section 11
What this does not cover
Cross-border invoicing and the EU's ViDA reporting layer are outside this playbook, because they land later and most small domestic firms do not need to act on them yet. If you invoice across EU borders at volume, that is a separate conversation with your advisor. The playbook here gets a domestic B2B firm from paper to compliant, receiving and sending, in a weekend.
Section 12
The fitness test
You are ready to run this playbook if: • You invoice other businesses domestically and can name your software or are ready to pick one. • You accept that receiving is the obligation to close first, before you worry about your sending deadline. • You will do the boring master-data step properly, because that is where rejected invoices come from. If you are still on Word or Excel invoices, do not treat this as an e-invoicing project. Treat it as the weekend you fix invoicing and GoBD at the same time. Start at step 3, get receiving working today, and let your turnover-based deadline set the pace for the sending half.