Open source accounting software for German GoBD compliance

How a self-hosted ledger can meet GoBD expectations for German entities, which platform fits, and what the hosting company must document and prove to a tax auditor.

Book a callTalk to us
On this page

Can open source accounting software meet GoBD for a German entity?

Open source accounting can meet GoBD expectations for a German entity, but only when the system configuration, the access model, retention and the operating procedures are designed and documented together. The software alone does not make a company compliant. GoBD is the set of German administrative principles on proper bookkeeping and on record keeping with computer systems, issued by the Federal Ministry of Finance (BMF). It shapes how a tax auditor expects postings, changes, storage and data access to behave. The exact current text lives in the BMF letter in force, and your tax advisor should confirm which version applies to your entity and year before any design decision is made.

In practice, the hosting company has to be able to show how the ledger behaves over time. For a self-hosted Odoo, ERPNext or LedgerSMB instance, that means documenting how posted entries are locked and corrected, which roles can change master data such as the chart of accounts, and how the audit trail of user actions is kept. For a German chart of accounts such as SKR03 or SKR04, confirm with your advisor which account structure, tax codes and reporting mappings the auditor will expect to see. Also confirm how the system will produce a complete, readable export of journals and master data for a tax audit, in the format the tax office accepts. Test that export on a copy of production before the first audit request arrives.

The decisions to make early are who holds administrator rights, where backups are stored, how long records are retained, and how structured e-invoices are received and archived alongside the ledger. Plan a documented procedure for each, with named owners and evidence kept for each change. Ask any implementation partner to walk through a sample tax audit request end to end on a test instance, and to show the written procedures, configuration baseline and change records that would be handed to the auditor. Those documents, not the license type, are what will determine how defensible the system is.

Which GoBD requirement areas the ledger must cover, and how to configure each

This table maps each GoBD requirement area that a self-hosted ledger must support to what the function has to do and how to configure it on Odoo, ERPNext or a similar platform. Read each row as a design checklist, and confirm the exact requirement wording and retention periods with your tax advisor before configuring anything. The main takeaway is that most findings come from configuration gaps and undocumented operating procedures, not from the software itself.

Requirement areaWhat the function must doHow to configure it
Chart of accounts (SKR03 and SKR04)Map accounts to the chosen standard chart, SKR03 or SKR04, consistently across entities and keep account codes stable over time. Confirm the exact wording of the requirement with your tax advisor.Load the localized German chart, document the mapping for any custom accounts, and lock account codes and master data after first posting. Restrict who can create or rename accounts.
Audit trail and immutability of posted entriesKeep posted entries unchanged, with traceable corrections through reversal or cancellation entries that show who made them and when. Confirm the audit trail expectations with your tax advisor.Use cancellation and reversal workflows instead of editing posted documents. Enable change logging on ledger doctypes and models, and test that posted entries cannot be silently altered at the database level.
Retention and tax audit data accessKeep books and records for the retention period your advisor confirms, and provide auditors with data in readable form along with the data needed to evaluate it. Confirm the retention period and export expectations with your tax advisor.Define an export procedure that produces readable exports with account, document and posting data. Test the export against a restored backup, and store retention copies in a location that stays available for the full period.
Receipt of structured e-invoicesReceive and process structured electronic invoices in the formats your suppliers and the applicable rules require, and keep the original file with the booking. Confirm accepted formats and archiving requirements with your tax advisor.Configure inbound invoice import or a validated connector, link the stored original file to the posting, and record rejected or manually corrected invoices with a reason. Check how the chosen platform stores attachments.
User and change control on the ledgerLimit ledger access to authorized users, log their activity, and manage changes to configuration, customizations and upgrades through a documented approval process.Use role-based permissions and separate creation and approval rights. Keep customizations in version control, test them in a staging copy, and record each production change with an approver. Enable authentication controls such as multi-factor authentication where the platform supports them.
Documentation of hosting and operating proceduresDocument how the system is hosted, backed up, restored, updated and operated, so an auditor can see that the procedures are followed and that data stays complete and available.Maintain a procedures manual covering hosting location, backup schedule, restore tests, upgrade steps, access reviews and incident handling. Keep dated evidence such as restore test records and change tickets, and review the manual at least once a year.

Odoo or ERPNext: which open-source platform fits a German ledger

The platform decision for a German ledger turns on license, support model and who carries the upgrade and customization work. Each card below covers one option or one decision point, so you can test every candidate against the same GoBD, German localization, chart mapping and entity-count requirements.

Odoo Community as a self-built core

Odoo Community is the open source core under the LGPL-3.0 license, and it has no access to the upgrade service. Every major version move, German localization update and customization retest falls to your team or your partner, and the work repeats on each cycle. For GoBD, that means the audit trail, locking of posted entries and retention settings must be verified again after each upgrade. Confirm which German chart and tax configurations are maintained in the community code and which you would have to build yourself.

Odoo Enterprise on your infrastructure

Odoo Enterprise is a paid subscription edition with a non-public source code, and on-premise use is activated with a subscription code. The subscription includes access to the upgrade service, which moves a database to a newer supported version through a test copy you validate before production. Ask the vendor which GoBD-relevant features sit in Enterprise and which are in Community, and get the subscription terms in writing before you rely on them for the ledger.

Odoo plan limits for multi-company and modules

Only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company, Odoo Studio, external API access and custom modules. A German group with several entities, each with its own chart and tax settings, therefore points to the Custom plan. Settle the entity count and the required modules before pricing, because the plan decides whether you can host the ledger yourself at all.

ERPNext on the Frappe Framework

ERPNext is licensed under GPL-3.0 and built on the Frappe Framework, which is MIT-licensed. Self-hosting the software is free, and you can install it with Docker Compose from the frappe_docker project or manually with the bench command line tool. Production use needs a database, Redis, background workers and a scheduler, so check that your operations team can run that stack. Confirm the German chart of accounts, tax templates and GoBD-related settings against the current release before you commit.

ERPNext support and version policy

Frappe's supported versions policy requires you to run a listed version and hold a matching Frappe Cloud support plan to receive warranty coverage from Frappe. Self-hosting therefore leaves the warranty question open unless you contract support elsewhere, so ask any implementation partner which version they will support and for how long. Server Scripts, which often carry custom GoBD logic, are disabled by default from version 15 and must be enabled deliberately. Plan that change under your change management controls.

LedgerSMB as a candidate to assess

LedgerSMB is a third option that should be assessed against the same requirements, but no verified facts about its German localization, GoBD features, license or upgrade path are available in this comparison. Build a short scoring sheet with the same items for each platform: chart mapping, immutability of posted entries, data access for tax audits, e-invoice receipt and hosting responsibilities. Ask the candidate vendor or partner to show evidence for each item rather than accepting a general claim.

Fit with localization, charts and entities

The choice depends on how well each platform covers German localization, the SKR03 or SKR04 chart you need, and the number of legal entities. Map your chart of accounts and tax codes to each candidate and test a sample of posting scenarios, including intercompany entries if you run a group. A platform that fits a single German GmbH may not fit a group with several charts, so treat entity count as a hard gate. Run this test on a non-production copy before you decide.

How SKR03 and SKR04 charts are set up and how posted entries stay locked

Start by confirming which German chart of accounts the entity uses, SKR03 or SKR04, and whether the localization for your exact Odoo or ERPNext version loads that chart completely. Both Odoo and ERPNext need the German localization confirmed for the version you plan to run, because chart templates, tax mappings and report layouts are version-specific. Load the chart into a configured copy first, then compare account types, tax codes and report mappings against the chart documentation your tax advisor provided. Record the source of the chart, the version of the localization and the person who approved the mapping. Master data changes after go-live, such as renaming an account, changing an account type or altering a tax mapping, should go through a written change request with an approver and a log entry, because these changes alter how every later posting appears in the reports an auditor will read.

Posted journal entries should be corrected by reversal and a new entry, not by editing the original. Configure the system so that posted documents cannot be modified in place, then test the correction workflow in the copy: post an entry, reverse it, post the corrected entry and confirm that the audit trail shows all three records with timestamps and users. Period locking is the second control. Close each fiscal period for postings after the close checklist is signed, and restrict who can reopen a period to a named role that is separate from the people who post entries. Test that a user without that role cannot post, edit or delete into a closed period, including through imports and API calls, because the Data Import tool in ERPNext and integration connectors can bypass the screens your staff normally use.

Test in a configured copy before production. Run a scripted set of cases: post into an open period, attempt to post into a closed period, reverse and correct an entry, change a master data field and confirm the log, and import a test file to see whether locked periods reject the rows. Repeat the tests after every upgrade and every customization. Check whether server-side customizations can alter posted data, because ERPNext Server Scripts are disabled by default from version 15 and must be enabled explicitly, which is a setting you should document and restrict. Keep the test results as evidence for the hosting company's documentation. The hosting partner should confirm the exact configuration keys and menu paths for your version rather than relying on general descriptions in this section.

Evidence a tax auditor asks for and which component produces it

This table maps each item a German tax auditor typically requests during a GoBD review to the system component that produces it and the routine that keeps it current. Read it as a checklist for the hosting company: the application generates most ledger evidence, while the operating team must generate and retain the rest. DeployOpen prepares these artifacts and runbooks, but independent auditors and tax authorities make the assessment, and DeployOpen does not issue audit reports or certifications.

EvidenceSource componentHow to keep it
Chart of accounts and mapping documentation with change historyAccounting module configuration (Odoo, ERPNext or LedgerSMB), plus the version-controlled mapping file or exportExport the SKR03 or SKR04 chart and mapping at each release, store versions under change control, and record who approved each account change
Posting and change logs from the applicationApplication audit log and database-level history of posted and modified entriesConfirm that posted entries cannot be edited or deleted in place, that corrections use reversing entries, and that logs are retained for the full retention period
Period closing recordsFiscal year and period lock settings, plus closing checklists and sign-off recordsLock periods after close, restrict who can reopen them, and file each reopening with its reason and approver
User and permission lists with review recordsApplication role and user tables, and directory integration where LDAP or single sign-on is usedExport roles and users on a fixed schedule, document the review and removals, and keep segregation of duties rules written down
Data export and tax audit data access test resultsThe export function that produces the auditor's structured data set, run against a copy of productionRun a test export on a schedule, check file completeness and totals against the ledger, and keep the results with the date and tester
Backup and restore test recordsDatabase and file backups, plus restore procedures run on a separate environmentRestore a recent backup to a test instance, compare balances and document the result, and record any failures and fixes
E-invoice inbound recordsInbound e-invoice receiving component and the archive that stores the original structured filesStore original files unchanged with their hash and receipt date, and confirm that the import links each file to its booked entry
Hosting and operating documentationRunbooks, architecture diagrams, change tickets and the hosting company's own control descriptionsKeep one controlled document set, update it with every upgrade or customization, and confirm what the hosting company and the support partner each maintain

What the hosting company must document before the first audit

This sequence turns a self-hosted accounting system into a documented, reproducible environment that an auditor can examine. Each step ends with a named artifact that the company, the hosting partner or the tax advisor can hand over and keep current.

  1. Define entities, charts and the system version

    The company, with its tax advisor, records which legal entities are booked in the system, which chart of accounts applies to each (SKR03 or SKR04 is a choice the tax advisor should confirm for each entity), and the exact edition and version in production, such as an Odoo 19.0 or ERPNext v15 or v16 release. Confirm the version against the vendor's support pages so it is still within its support window. The step is done when a signed scope note lists entities, charts, fiscal years and the running version, and the hosting partner confirms the same version in the live environment.

  2. Document the hosting environment and access model

    The hosting partner documents where the system runs (cloud account, data center or private network), the components involved (application, PostgreSQL or MariaDB, cache, workers, scheduler, reverse proxy), network paths, encryption in transit and at rest, and who holds administrative, database and backup access. Access is mapped by role, with named accounts and a record of who approved each grant. The company reviews the document and signs off. The output is an architecture diagram, an access matrix and a list of privileged accounts that can be produced on request.

  3. Document backup, restore and retention procedures

    The hosting partner describes what is backed up (database, file storage, configuration, custom code), how often, where copies are stored, how they are encrypted, and who may restore them. The most important evidence is a documented restore test: a copy is restored to an isolated environment and the ledger totals are compared with production. The tax advisor confirms the retention periods that apply to the entity's books and vouchers, and the company confirms that the backup policy keeps those records accessible for the full period. The output is a backup policy, a restore test record with date and result, and a retention schedule.

  4. Document change, upgrade and test copy procedures

    The hosting partner documents how changes move from development to production: who requests them, who approves them, how they are tested, and how they are deployed and rolled back. Test copies must be created in a controlled way. For Odoo, the documented method is database duplication with neutralization, which keeps production data out of the test environment and disables outgoing mail and payment connections. For ERPNext, staging is built with the bench command line tool or a Docker Compose setup, and server scripts are only enabled where the design requires them. Upgrades are tested on a copy before production. The output is a change log, approval records and a test copy procedure that the company can reproduce.

  5. Document how audit data is produced

    The company and the tax advisor agree which exports and reports the auditor will receive, such as journal, account balances, open items and fixed asset records, and in what structured format. The hosting partner documents how each export is produced from the system, who can run it, and how its completeness is checked against control totals. It also documents how the auditor can be given read-only access during the audit, and how that access is logged and removed afterwards. The step closes when a test export has been produced, checked against the ledger and filed with its procedure. The output is an export runbook and a sample export package.

How Odoo edition, ERPNext version and hosting model change the work

Odoo Enterprise on-premise or on Odoo.sh gives the German entity access to the official upgrade service and the vendor's standard support window. According to Odoo's pricing page, only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company, Odoo Studio, external API access and custom modules, so the edition choice also determines which configuration features are available for a GoBD-compliant setup. Standard support covers the first three years after a major release, including security updates, and Odoo.sh and on-premise are the only paths with paid extended support for select versions.

  • Upgrade path: The upgrade service builds a test database on the target version that should be validated before production, which becomes part of the change record for each major upgrade.
  • Mandatory upgrades: On Odoo Online and Odoo.sh, major upgrades are mandatory every two years, so the schedule and the test evidence must be planned in the audit calendar.
  • Support windows: Odoo 20.0 has standard support planned until September 2029, and Odoo 19.0 until September 2028. Confirm which version the entity runs on and when its window closes.
  • Hosting responsibility: On-premise shifts backups, access control and patching to the entity's own infrastructure team, which must document them for the auditor.
  • Enterprise activation: On-premise databases are activated with the subscription code, which should be recorded in the license file.

Confirm with Odoo which extended support options apply to your version and hosting model, and ask the partner how the upgrade test database is validated and retained as evidence.

What the software does not settle for a German ledger

A configured ledger is only one part of GoBD compliance. The gaps below sit with tax advisors, the entity's own obligations, the e-invoicing approach, daily operations, third-party extensions and the auditor, and each needs a named owner before go-live.

Legal interpretation of GoBD

The software can store and lock postings, but it cannot tell you how the principles of proper bookkeeping apply to your business model, your document flows or your scanning practices. That reading belongs to the tax advisor, who should confirm it against the current BMF letter on GoBD. Ask the advisor to sign off the process description before the system is configured, and keep the written answer with the project documentation.

Retention periods per entity

Retention depends on the record type and on the obligations of the specific entity, including tax and commercial law and any sector rules. Accounting vendors and implementation partners do not set these periods. Ask the tax advisor for a retention schedule by document class, then confirm that the hosting design, backups and archive exports all honor it, including after the system is decommissioned.

E-invoice format and inbound process

Whether inbound structured e-invoices can be received, validated and posted depends on the format you accept, the channel you receive them through and the approach you choose, such as a direct connection or an access point service. The ERP does not decide this by default. Confirm the supported formats, the validation step and who handles rejected invoices before you commit to a design.

Operating procedures around the system

A configured system does not produce compliance on its own. Auditors also look for written procedures covering user provisioning, posting approvals, corrections by reversal, period closing, backups and restore tests, and who may change master data. The company owns these procedures and must run them. Assign an owner in finance and an owner in IT, and schedule the first evidence collection before the first closed period.

Add-ons and custom scripts

Third-party apps, custom fields and server-side scripts can change how postings are created, numbered or stored. Each one becomes part of the bookkeeping process and needs its own change control, testing and ownership. Note that custom server scripts in ERPNext are disabled by default from version 15 and must be enabled deliberately. Ask the implementation partner to list every customization that touches posting logic and who approves its release.

Auditor judgment on sufficiency

Whether the system, the procedures and the evidence are sufficient for a tax audit is decided by the auditor on the facts of the case, not by the software or the vendor. Preparing the records, access paths and documentation is the implementation partner's job, but the conclusion is not. Ask your tax advisor which audit questions are likely for your entity, and rehearse a data access request before an auditor arrives.

What German finance teams ask before they bring in an implementation partner

What does a GoBD-oriented implementation cost and what drives it?

No price can be stated without a written scope, and DeployOpen does not publish a price list. The main cost drivers are the number of legal entities and bank accounts, the localization and tax setup for German entities, the volume and quality of historical data to migrate, the number of interfaces (payroll, banking, e-invoicing, document archive), and the documentation and evidence pack the finance team needs. One-time costs cover planning, configuration, migration, testing and handover. Recurring costs cover hosting, backups, upgrades, support and the software subscription where the chosen edition requires one. For the software side, ERPNext can be self-hosted at no license cost, while Odoo on-premise requires an Enterprise subscription. Ask every bidder for a quote that lists these components separately so you can compare scope, not just totals.

How long does a GoBD accounting implementation take?

The timeline depends on the scope agreed in writing, so no duration can be assumed in advance. A single-entity setup with a standard chart and few interfaces will take far less time than a group with several entities, custom reports, historical data migration and integration with payroll or document management. Ask the partner to break the timeline into phases such as design, build, data migration, parallel bookkeeping, testing with sample tax audit exports, and go-live. Also confirm when the finance team must be available for approvals and test sign-off, because those reviews often set the pace more than the technical work does.

What must our finance team provide before implementation starts?

The finance team carries the business decisions that a partner cannot make for you. Typical inputs are:

  • A decision on the chart of accounts, either SKR03 or SKR04, and mapping rules for any existing ledger
  • A named list of approvers for postings, payment runs and period closes, with their roles
  • Sample requests the team expects from a tax auditor, such as data exports and document retrieval, so the system can be tested against them
  • Input from your tax advisor on VAT setup, retention periods and how e-invoices must be received and stored
  • Opening balances, open items and the cutover date

Without these inputs, configuration tends to be redone, so settle them before the scope is signed.

Can our team run a GoBD-oriented accounting setup on its own?

A small single-entity team can often run a basic self-hosted setup without outside help, provided it has written procedures for posting, approvals, period closes, backups and user access, and someone who can administer the server and database. Multi-entity groups, customized builds with custom reports or server-side logic, and migrations from an older system are much harder to keep compliant internally, because each change can affect posted data and audit evidence. Be honest about your team's depth in ERP administration, Linux, database operations and change control. A partner can cover the gaps through a fixed-scope project, an ongoing support retainer or both.

Does our hosting partner need to be audited for GoBD?

The answer depends on what the partner is asked to deliver. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies. In practice, the hosting and implementation partner should document the hosting setup, access controls, backup and restore procedures, change records and configuration decisions so your tax advisor and auditor can review them. Ask the partner which evidence it produces, in what format, and who within your organization owns the final assessment of GoBD conformity.

Which Odoo or ERPNext license and edition is needed for on-premise hosting?

The edition decides what you can run on your own servers. Odoo Community is open source under LGPL-3.0, but Odoo's upgrade service requires an Enterprise subscription for on-premise use, and the Community edition has no access to it. Odoo's pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company, Odoo Studio, external API access and custom modules. Odoo standard support covers three years after a major release, so plan upgrades early. ERPNext is licensed under GPL-3.0, and its pricing page states that self-hosting is free, though a Frappe support plan matches warranty coverage. Confirm current edition terms directly with the vendor before you commit.

How DeployOpen scopes, builds and documents a self-hosted ledger for audit

DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source accounting platforms inside the client's own infrastructure. For German entities, we set up the ledger, its controls and its evidence in writing before the books move, so the hosting company can show how bookkeeping meets GoBD expectations.

How we scope

  • Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
  • The written scope names the edition, chart of accounts (SKR03 or SKR04), entities, tax settings and retention periods for your German entities.
  • Scope also lists which e-invoice formats, bank feeds and data import sources the system must receive and reconcile.
  • We ask you to confirm which tax auditor access formats and retention rules apply to your entity, with your tax advisor.

How we build

  • We install and configure the chosen platform in your cloud account, data center or air-gapped network, with the database and file storage in your control.
  • Posting controls, approval workflows and locks on posted entries are configured and tested against the written requirements.
  • Any customization is built as versioned code, reviewed and tested in a separate environment before it reaches production.
  • Access controls, role assignments and logging of user activity are set up and checked against the written access model.

How we hand over

  • You receive documentation of the configuration, the posting and locking rules, the backup and restore procedure, and the change log.
  • We prepare control descriptions and evidence samples that your auditors and tax advisors can review, without issuing any audit opinion ourselves.
  • Handover includes a test of the data export and access procedures that a tax auditor would request, run on your own data copy.
  • Your staff are trained on the controls they own, and the open items from testing are listed with owners.

How we support

  • Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
  • Upgrades to the platform are tested on a copy of the production database before they go live, with the test results kept as evidence.
  • Retainer scope can cover security patches, release review and periodic re-checks of the controls against your written requirements.
  • Ask any implementation partner which upgrade, support hours and evidence retention terms apply, and get them in the quote.

Sources and further reading

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com