Odoo GoBD compliance and DATEV export in Germany

For a GoBD review, the audit trail is the part of the books that shows what was posted, when, by whom, and whether it has changed since. Reviewers test three properties: records are complete, each posted entry can be traced to its origin, and no entry is altered or removed without a visible record of the change. Odoo's documentation states that the German localization (l10n_de) enables the audit trail by default to support GoBD. That describes the design of the software. It is not an audit result, so your team needs to test the behavior in your own configuration and version before relying on it.

Start the verification by listing what the trail records for journal entries, customer and vendor invoices, and payments, and whether a change to a posted document leaves a trace that a reviewer can read. Then confirm who can change configuration. Access rights for accounting settings, journals, fiscal positions and sequences should be limited and reviewed, and you should establish whether any administrator account can edit or delete posted records. Finally, check reversal: whether a posted entry can be cancelled, how that is done (for example, through a reversing entry with its own number), and whether the original stays visible. Confirm each answer against the release and modules you will run, because the behavior depends on both.

Several of these controls are design decisions made before go-live. The configuration of journals, fiscal positions and sequence settings determines how documents are numbered, how tax is applied and how accounts map to the DATEV export. Changing them after postings exist leaves history that a reviewer will need explained. Agree the journal structure, numbering scheme per journal, fiscal year handling and the fiscal position logic with your tax adviser, and record each decision with its reason. Also confirm with your tax adviser and auditor how gaps in sequences, cancelled documents and corrections should be documented, since those rules shape what the trail must show.

A test database is the most direct way to show the audit trail working. Odoo documents database duplication with neutralization for test copies, which lets your team post and change records without touching production and with outgoing connections such as mail and payment providers disabled. Run a written scenario: post an invoice, attempt to edit it, reverse it, change a sequence setting, change a user's access rights, and then export the general ledger to DATEV format. Record what the trail shows at each step and compare the results with the design. Keep the scenario, the outputs and the sign-off as evidence, because the test result is only useful if a reviewer can see how it was produced.

The DATEV export from the general ledger in Odoo depends on the Germany Accounting Reports module, l10n_de_reports. According to Odoo's Germany localization documentation, this module provides German accounting reports and adds DATEV export options to the general ledger, and German period-end reporting is built around that export. Treat the export as a deliverable that your tax advisor accepts, not as a button that someone clicks at month end. The first decision is which export format and which period handling your advisor and their DATEV processing expect, because the export settings, the account numbering and the cut-off rules all have to match that agreement before any data moves.

Agree the export specification in writing before the build. Ask the advisor which DATEV format version and data categories they will import, how fiscal year and period boundaries are represented, how opening balances and carry-forward entries appear, and how reversals and corrections should be exported. Then confirm each answer against the current DATEV documentation and the export options in your installed Odoo version. No format specifics are supplied for this section, so the exact field layout, version numbers and validation rules must come from the advisor and DATEV, not from this page or from assumptions about the module.

The chart of accounts and tax codes are the most common source of failed imports. Map every Odoo account and tax to the account number and tax key that DATEV processing expects, and document that mapping as a controlled table with an owner and a change log. Check that accounts used by automated journals, such as bank clearing, payment differences and rounding, are mapped too. Check that each tax code produces the correct tax key for each rate in use. Any account created after go-live needs the same mapping step, so add it to the change procedure rather than leaving it to individual users.

Test exports before the first live period. Run an export for a closed test period and reconcile it to the Odoo general ledger: total debits and credits, account balances, tax totals and entry counts should agree. Keep the reconciliation as evidence. Then send the test file to the advisor and ask them to load it into their processing environment. Repeat the test after any change to accounts, taxes, journals, the Odoo version or the l10n_de_reports module, since upgrades can alter export behavior. Plan this retesting as part of your upgrade path, not as a one-off.

A repeatable close procedure turns the export into routine work. Write down who runs the export, when the period is locked, which reconciliation is signed off, where the file is stored, and how the advisor confirms receipt. Define what happens when a late entry arrives after the export, including whether it goes into the next period and how the advisor is told. Keep the procedure and the sign-off records with the audit trail documentation so an examiner can see how each period was produced and checked.

If your company runs point of sale in Odoo in Germany, the module l10n_de_pos_cert is the component that implements the Technical Security System (TSS). Odoo's Germany localization documentation states that it uses a cloud-based solution from Fiskaly for this purpose. Businesses that operate restaurants also need l10n_de_pos_res_cert, which adds restaurant requirements on top of the base certification module. The decision starts with the till types you run. List every POS configuration, including counters, self-service and restaurant floor plans, and confirm with your tax advisor and with Odoo which module set covers each one before you install anything in production.

The module depends on services outside the Odoo database that you must arrange yourself. First, you need a contract and an account with the Fiskaly service, and the account and its credentials must exist before the POS can be configured. Ask Fiskaly and Odoo which account type, API credentials and fees apply, and who bills each one. Second, every POS terminal and the Odoo server that handles its sessions must reach the Fiskaly cloud endpoint through your firewall and any proxy. Check outbound rules for each site and test from each till location, not only from the server.

The most important question is what happens when the cloud service cannot be reached. Confirm the exact behavior with Odoo and Fiskaly in writing: whether sales can still be completed, how transactions are recorded and protected while offline, whether they are signed when connectivity returns, and whether a till must be blocked. Then write an outage procedure that staff can follow at the counter and test it in a non-production database with a simulated network block. Plan for the operational effect of a blocked till during peak trading, including who may authorize a fallback and how that fallback is logged for later review.

POS sales reach the general ledger when a POS session is closed and Odoo creates the journal entries for it. Those entries are the same ledger that the DATEV export in l10n_de_reports reads, so errors in POS posting carry into your German bookkeeping output. Check the journal and account mapping for each payment method, including cash, card and any voucher, and reconcile a test day from till to ledger before go-live. The TSS is one control among several for cash registers. Cash counts, daily closing, cash-in and cash-out records, and written procedures for voids and refunds also matter. How all of these controls are documented in your process description is a decision for your tax advisor, so agree that scope before the build starts.