A German request for an Odoo interface almost always names three counterparts: the tax advisor with DATEV, the shop on Shopware or JTL, and, since last year, the e-invoice. The technical part of connecting them is rarely the problem. The problem is that each of the three expects the data in a shape Odoo does not produce by itself, and that nobody says so at the start.
So here is what the standard image actually contains, what it does not, and which seams I have had to sew by hand.
What Odoo brings for Germany, counted rather than assumed
The running image of Odoo 19 Community carries 741 modules. Exactly one of them is German: l10n_de, the chart of accounts. Modules with DATEV in the name: none at all. The European one-stop-shop module l10n_eu_oss is there, and so is the format list for electronic invoices, which already knows XRechnung.
That single count decides the shape of a German project. Accounting exports are your own work or somebody else's product. Immutability is a setting you have to find. The e-invoice is closer than most people expect. And whatever the shop needs is entirely up to the connector.
DATEV: the export is your job, and the format is the smaller half
Since the box contains nothing, the question is only who writes the export: a paid module, a partner, or me. Whoever it is, the hard part is not the CSV. DATEV wants postings, not documents: account and contra account, a tax key, the document number your advisor reconciles by, and a date that lands in the right period. Odoo happily gives you all four - once somebody has decided which Odoo account maps to which number in the advisor's chart, and what happens to the cases that have no number at all.
The cases without a number are where the month ends badly: a refund that crosses a period, a payment that arrives before the invoice, a marketplace payout that is one line for two hundred orders. I ask for last month's postings from the advisor before writing a single line of export code, because that file says more about the mapping than any meeting.
GoBD: immutability is a switch, and it has to be flicked early
Odoo does have what the German rules ask for, and it is off by default. Journals carry restrict_mode_hash_table; switch it on and every posted entry gets an inalterable_hash and a secure_sequence_number, so an altered row can be detected. The company has restrictive_audit_trail for the log that may not be pruned.
Two traps. The first: the journal also carries has_unhashed_entries - the honest admission that everything booked before you switched the mode on is outside the chain, and no later setting repairs that. Switch it on at go-live, not when the audit is announced. The second is the interface itself: a connector that "corrects" a posted invoice because the shop changed the order breaks exactly the property the hash is there to prove. Corrections are new documents - a credit note, a reversal - and the connector has to be written that way from the first day.
Shop: Shopware or JTL, and the question is ownership
Both talk fluently enough - Shopware through its admin API, JTL through its own database and connector - and neither of those is the reason projects go sideways. The reason is that stock and price exist on both sides, and both sides believe they are right.
One table settles it before any code: every field that crosses the border, and next to it the single system that may change it. Stock is owned by Odoo, the shop is told. Prices usually belong to the shop, because that is where campaigns happen. Whatever field gets the answer "both" will produce a support ticket within the quarter.
Then the German detail that costs the most time: shops think in gross prices, Odoo thinks in net. Round nineteen per cent off 49.99 € and back again, a few thousand times, and the cent differences show up in the accounts as an endless list of tiny discrepancies nobody can explain. Decide once which side is authoritative for the number the customer sees, carry it as that, and let the other side derive.
E-invoice: XRechnung is already in the box
Since the beginning of 2025 German companies must be able to receive a structured invoice; the duty to send them arrives in stages. The good news is that Odoo 19 already offers the format: on the customer, the invoice format list includes "Germany (XRechnung)" next to Factur-X and Peppol BIS 3.0. Peppol access itself lives in separate modules.
For an interface this means one thing: the invoice that leaves your system is a document with fields, not a PDF with a picture of them. Everything the XML needs - the buyer reference, the tax breakdown, the unit of measure - has to be in the record before the export runs, which usually sends me back to the shop connector to collect fields nobody mapped.
How I start such a project
One call, and three questions that decide the estimate: which chart of accounts your advisor uses and whether the export has to match an existing posting practice; whether the hash mode is on and since when; which system owns stock, price and the customer record. The answers fit on one page, and that page is the interface specification.
If you already have a connector and it runs, the useful question is a different one: what does it do when it is run twice, and how do you find out that last night it did not run at all? That is the part I am usually called about.