Open source e-invoicing for Germany: what a self-hosted ERP must do
A self-hosted Odoo or ERPNext can meet the German B2B e-invoicing rules, but only when receiving, format output, validation, archiving and GoBD-compliant storage are designed as one chain rather than as separate add-ons. German companies must already be able to receive structured invoices, and the statutory obligation to issue them extends in stages. The exact scope, thresholds and exceptions that apply to your company should be confirmed with your own legal and tax advisers, who own the interpretation. This section does not restate those rules. It maps each requirement to the ERP function that has to carry it.
Start with inbound. Every supplier invoice must enter the ERP as structured data, not as a PDF that someone keys in, so the receiving path (an e-invoice intake, the XML parser, and the mapping of supplier tax IDs and buyer references to vendor records) is the first design decision. Confirm with your access point or service provider which formats they deliver and how rejected or malformed files are returned. Outbound comes next: the ERP needs to generate XRechnung (XML only) or Factur-X (a PDF with an embedded XML) with the mandatory fields filled from master data. Decide early which format each customer group requires, because that choice drives the data model.
Validation and archiving close the chain. Run every generated file through a schema and business-rule check before it leaves the system, and store the rejection log alongside the invoice. For storage, the GoBD principles require that the original structured file, the processing history and any changes remain unaltered and retrievable for the retention period, so the archive must hold the XML as the primary record, not a rendered copy. Ask your implementation partner how the archive is locked against edits, how retention is enforced, and who signs off the GoBD documentation (the process description and the test evidence) before go-live.
How each German requirement maps to ERP functions and configuration
This table maps each part of the German B2B e-invoicing workload to what the ERP must do and where Odoo or ERPNext configuration decides it. Read each row as a question to confirm with your tax adviser and your ERP partner before go-live. The MFA and logging rows mirror US FTC Safeguards controls under 16 CFR 314.4 as a parallel example only, not as a German requirement.
| Requirement | Odoo configuration | ERPNext configuration |
|---|---|---|
| Receive structured inbound invoices | Import supplier XML into vendor bills; confirm the import path for your edition and version. | Create Purchase Invoices from supplier XML through a reviewed integration; confirm before go-live. |
| Produce XRechnung and Factur-X output | Confirm the generator and PDF/A-3 embedding for your version; external API access requires the Custom plan. | Confirm that the e-invoice app or print format produces XRechnung XML with embedded Factur-X files. |
| Validate and handle errors | Validate each incoming and outgoing file before posting; queue failures with the document reference. | Track status in a dedicated field and record failures in Error Log; keep Server Scripts disabled unless reviewed. |
| Archive and keep GoBD-aligned records | Keep the original XML and rendered PDF unchanged as retained attachments; confirm retention with your auditor. | Store originals in private File storage with tested backups; confirm retention periods with your tax adviser. |
| Keep the platform supported | Standard support covers three years after a major release; Odoo 20.0 standard support runs until September 2029. | v15 is supported until the end of 2027 and v16 until the end of 2029; plan upgrades before support ends. |
| Control access with MFA and encryption | Use LDAP for central login, enforce MFA at the identity provider and encrypt traffic with TLS. | Use LDAP or social login, enforce MFA at the identity provider and encrypt traffic with TLS. |
| Log activity and manage change | Test every upgrade on the upgraded test database before production; review user activity regularly. | Keep customizations in version control, deploy tested frappe_docker images and review logs after each change. |
Which self-hosted platforms fit German e-invoicing
German B2B e-invoicing depends on whether your ERP can produce and validate XRechnung and Factur-X output, store the results as GoBD-compliant records, and fit your hosting model. The cards below compare the two open source ERP options most often considered and the checks each one needs before a build decision.
Odoo Community core
Odoo Community is the LGPL-3.0 open source core of the Odoo suite, and you can run it on your own infrastructure without a subscription. Its accounting and invoicing modules give you the document model, but structured XRechnung and Factur-X generation and validation are not something to assume from the core alone. Confirm with the vendor or a partner whether the version you plan to run includes these outputs, or whether they come from an add-on.
Odoo Enterprise and the Custom plan
Enterprise is a paid edition built on the Community core, adding upgrades, hosting and support. Per Odoo's pricing page, only the Custom plan can run on Odoo.sh or on-premise, and only Custom includes custom modules and external API access, which e-invoice connectors often need. Ask for a written statement of which e-invoice features each plan includes and who maintains them through version upgrades.
ERPNext on the Frappe framework
ERPNext is licensed under GPL-3.0 and runs on the MIT-licensed Frappe framework, so the core and the framework have no per-user fee for self-hosting. You can install it with Docker Compose or the bench command line tool, and production images are available in the frappe_docker repository. Confirm whether an XRechnung or Factur-X generator is available for your ERPNext release, or whether a partner module is required.
Version support and upgrade path
Support windows decide how long a German e-invoice setup stays valid without a major upgrade. Odoo 19.0 standard support runs until September 2028 and Odoo 20.0 until September 2029, while Frappe lists version 15 as supported until the end of 2027 and version 16 until the end of 2029. Plan the format module's validation rules against these dates, and confirm the vendor's support for each validator version.
Server scripts and custom validation
Custom XML mapping, field checks and API calls in ERPNext are often written as server scripts. Since version 15 these are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. Decide early whether your German invoice logic will live in custom apps under your own change control, and confirm this with your hosting model.
Hosting and change control
Self-hosting moves responsibility for patching, backups and validator updates into your organization or your partner's scope. Odoo on-premise Enterprise requires an active subscription code, and Community has no access to the upgrade service. Write down who applies validator updates when the XRechnung specification changes, who tests them against a copy of production, and how the change is recorded for GoBD purposes.
Odoo Enterprise or ERPNext: which fits which German company
A company already running Odoo has a different decision from one starting fresh. The question is less which ERP to buy and more which edition, hosting model and upgrade path keep the e-invoicing work supportable. Odoo's Community edition is LGPL-3.0 licensed, but on-premise use of the Enterprise features and the upgrade service requires an Enterprise subscription, so the licensing and support position should be confirmed before e-invoicing modules are scoped.
- Edition and module fit: Confirm which e-invoicing functions your Odoo version provides natively and which need partner or custom modules.
- Support window: Odoo 20.0 standard support runs to September 2029, Odoo 19.0 to September 2028, and Odoo 18.0 to September 2027. A version that falls out of standard support will not receive security patches on standard terms.
- Upgrade cadence: On Odoo Online and Odoo.sh, major upgrades are mandatory every two years, so XRechnung and Factur-X templates must be retested on each upgrade.
- Hosting tier: On-premise and Odoo.sh deployment is limited to the Custom plan, which affects where custom validation code can run.
- Upgrade testing: Plan a test database upgrade before every major version change.
Confirm your current version, subscription tier and support end date with Odoo before writing the e-invoicing scope.
A company on ERPNext has a free, GPL-3.0 licensed core and a framework, Frappe, under MIT. Self-hosting carries no license fee, but support and warranty coverage depend on the Frappe version and the support plan. The e-invoicing work often depends on Server Scripts or custom apps, and those behave differently depending on the version and hosting model.
- Supported versions: Version 14 reached end of life on January 31, 2026. Version 15 is planned to be supported until the end of 2027, and version 16 until the end of 2029.
- Release frequency: Both v15 and v16 receive frequent minor releases, so a patch cadence must be part of operations.
- Server Scripts: From version 15, Server Scripts are disabled by default and must be enabled with the
server_script_enabledsetting. Public shared benches on Frappe Cloud do not allow them. - Warranty terms: Frappe warranty coverage requires running a listed version and a matching Frappe Cloud support plan. Check this before relying on vendor support for a self-hosted build.
- Data import limits: The Data Import tool is documented for a few thousand records at a time, which matters for backfilling historical invoices.
Confirm the version you will run, whether you need a support plan, and whether your e-invoicing logic can live in an app rather than in Server Scripts.
A group with several legal entities in Germany needs one set of rules for multiple companies, but each entity may have its own tax number, numbering scheme and receiving routes. The choice of platform affects how entity-level master data, chart of accounts and invoice numbering are kept consistent, and how one entity's configuration change is prevented from breaking another's e-invoice output.
- Entity structure: Confirm which platform handles multiple companies natively and whether it is available in your edition or plan.
- Odoo tiers: Odoo's pricing page lists multi-company support in the Custom plan only, so the group's entity count affects the tier choice.
- Shared versus separate instances: Decide whether entities share one database or run separately, since that changes how upgrades and XRechnung templates are rolled out.
- Numbering and archiving: Each entity needs its own sequence and archive trail that satisfies GoBD requirements.
- Change control: A single upgrade affects every entity, so testing must cover all of them.
Confirm with the platform vendor which multi-company features your target tier includes before designing the entity model.
Some groups run a German entity alongside Polish or French entities, each with its own national e-invoicing rules. A single ERP instance can serve all of them, but the national formats, portals and deadlines differ. The choice of platform should account for whether country-specific modules are available for each country and whether they can coexist on one database without conflicting configurations.
- Country modules: Confirm which national e-invoicing modules are available for Poland and France on your chosen platform and edition.
- Format separation: Keep XRechnung, Factur-X, KSeF and French reform requirements in separate configuration sets so a change for one country does not alter output for another.
- Timing: National rules apply on different dates, so the rollout for each entity should follow its own deadline.
- Partner coverage: Check whether implementation partners support all the countries in scope, since specialist skills may differ.
- Testing: Partner testing with trading partners must run per country and per format.
Ask each vendor and partner to document which country, format and version combinations they have tested in production-like conditions.
How the German e-invoice project runs from master data to live invoices
The sequence turns German e-invoice obligations into a tested, archived and monitored setup in a self-hosted Odoo or ERPNext system, with a written record at each gate. Timing depends on the scope agreed with you, so confirm it in the written scope before work starts.
Confirm your obligations and document scope
Start by confirming which obligations apply to your entity: receiving structured invoices, issuing XRechnung or Factur-X, and whether the turnover threshold or EDI exception changes your position for 2027. Your tax advisor and legal team own the position, and DeployOpen maps it to system requirements. The step closes with a signed list of in-scope invoice flows, buyer types and document formats, which becomes the basis of the written scope.
Clean master data for tax and routing
Audit the customer and supplier records that drive invoice output and inbound matching: VAT and tax registration numbers, legal names and postal addresses, contact points, and the routing identifiers your trading partners use. Your finance team decides the source of truth, and DeployOpen writes the import templates and validation rules. The step closes when a sample extract passes the agreed checks and exceptions are assigned to named owners.
Configure output and inbound processing
Configure the ERP to generate XRechnung and Factur-X output from sales documents, and to receive, parse and post incoming structured invoices into payables. Where the platform's built-in capability does not cover a required rule, DeployOpen scopes a custom module or integration and confirms the method with your team, including any server-side scripting and whether it is permitted in your hosting model. The step closes with sample output and inbound files reviewed against the agreed format rules.
Test with trading partners in a neutralized copy
Run end-to-end tests in a duplicated database with neutralization, so outbound e-mails, payment connectors and external transmissions cannot reach live partners. Exchange test invoices with a defined set of trading partners and record every rejection and correction. The step closes when each in-scope flow has a documented pass result and the test log is signed off by the business owner.
Validate files and handle errors
Run every output and inbound file through the validators and schema checks chosen for the project, and define how errors are routed, corrected and resubmitted. Confirm with the validator vendor or standard body which rule versions are in force on the go-live date. The step closes with a validation procedure, an error-handling runbook and evidence that rejected files were traced to a cause and resolved.
Set up archiving aligned with GoBD
Configure retention so that issued and received e-invoices are stored in their original structured form, with the attachments, audit trail and metadata needed for review. Your tax and compliance owners confirm the retention periods and storage rules against GoBD and their own policies. The step closes with a documented archive design, a restore test and a written retention schedule.
Go live with monitoring and change control
Move the approved configuration to production through your change process, with a rollback plan and a named owner for the first live cycle. Set up monitoring for failed transmissions, unprocessed inbound files and validation errors, and agree how mandate or format changes are assessed and applied. The step closes with a go-live record, monitoring dashboards in use and a support arrangement confirmed in writing.
Evidence the auditor or tax reviewer will ask for
This table maps each component of a self-hosted German e-invoicing setup to the evidence a tax reviewer or auditor typically asks for and where teams usually fall short. Read it as a checklist to build before the first inspection, not after. DeployOpen prepares this evidence from your environment, but it does not issue audit reports or certifications; independent auditors and certification bodies do.
| Component | Evidence to prepare | Where it usually fails |
|---|---|---|
| Configuration exports | Exported ERP settings for tax codes, numbering, invoice templates, XRechnung and Factur-X output, dated and versioned | Settings changed in production with no dated export, so the reviewer cannot see what was in force when an invoice was issued |
| Validation logs | Logs from the schema and business rule checks run on each outgoing and incoming XML file, with the rule version used | Validation runs only in the test system, or errors are rejected silently and never retained |
| Sample files per format | Representative XRechnung (UBL or CII) and Factur-X files, each paired with the PDF or source record it came from | Samples are generated from a demo dataset that does not match live tax and buyer master data |
| Test records with trading partners | Dated test exchanges with key customers and the public sector recipients, including rejected and corrected files | No test history kept, so the team cannot show the format was agreed before go-live |
| Inbound invoice records | Receipt log for structured invoices received, with the original file, processing status and the posted document linked | Received XML is stored only as a converted PDF, losing the structured data the rules require |
| Archive retention settings | Documented retention periods, storage location, immutability controls and proof that original files and their metadata are kept together | Archive folders with no retention rule, or deletion jobs running on the ERP database that also purge attachments |
| Access reviews | Current user and role lists for ERP, archive and any access point, with dated review sign-offs and removed leavers | Shared administrator accounts, or no review since the first go-live |
| Change records for upgrades and module updates | Change tickets, test results and the release notes for each ERP or e-invoicing module update, including the Odoo or ERPNext version in use | Patches applied directly in production, or mandatory major upgrades completed without a tested copy |
| Backup and restore tests | Backup job logs, retention settings and a dated restore test showing that invoices, XML files and archive links can be recovered | Backups exist but no restore has been run, so recoverability is unproven |
What tooling alone does not satisfy
An ERP with XRechnung and Factur-X support still leaves decisions and records to the company. The cards below cover the gaps that no module, template or validator closes on its own, and what to put in place for each.
Tax treatment stays with the company
The software applies the tax codes, rates and invoice fields that someone configures. It does not decide whether a supply is taxable, which rate applies, when the supply takes place or whether a reverse charge is used. Assign a named owner in tax or finance to sign off the tax configuration, and review it when rules or business models change. Confirm with your tax adviser which cases your invoices actually cover.
A GoBD process document
Storing invoices correctly is only part of the obligation. The company needs a written process description that explains how invoices are created, received, changed, approved, archived and retrieved, and who is responsible for each step. Auditors look for this document and for evidence that staff follow it. Ask your implementation partner to map the document to your actual ERP workflows rather than a generic template.
A retention policy that matches the records
A retention policy sets how long each category of document is kept, where it is stored and when it may be deleted. Invoices, attachments, XML files, validation logs and audit trails may each follow different rules, and the policy must cover the ERP, the archive and any backups. Write the policy with your tax adviser and legal team, then configure the platform to match it. Do not rely on the default retention settings of any tool without checking them.
Odoo Community has no upgrade service
The Odoo upgrade service moves a database to a newer supported version and is available only with an Enterprise subscription for on-premise use. Odoo Community users must plan and run their own major upgrades, including the e-invoicing modules and their validation rules. Odoo documents that Odoo Online and Odoo.sh require major upgrades every two years, and that standard support covers three years after a major release. Confirm which edition and support model you plan to run before you choose the module set.
Server Scripts are limited on Frappe Cloud
In ERPNext, Server Scripts run Python on document events, such as validating an invoice before it is saved. From version 15 they are disabled by default and must be enabled with the server_script_enabled setting. Frappe Cloud public shared benches do not allow them at all. If your XRechnung or Factur-X checks depend on custom scripts, plan a dedicated or self-hosted deployment, and confirm the setting in your environment before go-live.
Validation rules need a change process
Validation rules for XRechnung, Factur-X and Peppol BIS change as the standards and national rules evolve. A validator that passed invoices last quarter may reject them after an update. Assign an owner for rule updates, test each update against sample invoices from your trading partners, and keep a record of which rule version validated each invoice. Ask any partner how they track and deploy these updates in your environment.
Questions German finance and IT teams ask before hiring help
What drives the cost of a self-hosted Odoo or ERPNext e-invoicing project?
The cost is driven mostly by edition, customization depth, the number of legal entities, partner integrations and archive design. Odoo Community is free to download, but the Enterprise edition requires a subscription, and the Enterprise source code is not publicly available. Odoo's pricing page says only the Custom plan can be hosted on Odoo.sh or on-premise and that only Custom includes multi-company, Odoo Studio, external API access and custom modules, so a multi-entity German group will often land there. ERPNext is free to self-host, but the ERPNext pricing page notes that implementation is available through certified partners. Ask any quote to separate one-time work (configuration, validation rules, format mapping, archive setup) from recurring items (subscriptions, hosting, support, upgrades and test runs).
How long does a German e-invoicing project take on self-hosted ERP?
Duration depends on the number of entities, how many inbound and outbound invoice flows exist, how clean the master data is, and whether the ERP must be upgraded first. No fixed duration applies to every company, so ask for a timeline built from your own scope and not a generic estimate. Upgrade timing matters: Odoo 20.0 standard support runs until September 2029, Odoo 19.0 until September 2028, and Odoo 18.0 until September 2027, and on-premise upgrades need an Enterprise subscription. Odoo SaaS versions are released every two to three months, so the target version affects the plan. Confirm with the implementer which ERP version and upgrade path they will validate against before work starts.
What must our company provide before an e-invoicing implementation starts?
Your team must provide the decisions, data and access that the implementer cannot infer. Expect to supply:
- Master data for customers, suppliers, tax IDs, legal entities and any Leitweg-ID or buyer routing identifiers your public-sector customers use
- A set of real sample invoices, inbound and outbound, covering standard, credit note and exception cases
- Named test partners willing to exchange test documents
- Decision owners in finance, tax, IT security and records management who can approve formats, validation rules and archive retention
- Access to a test environment that is a copy of production with personal data neutralized where needed
Missing any of these typically extends the testing phase, so agree on them in the written scope.
Can our internal team implement XRechnung and Factur-X output alone?
A capable internal team can do parts of the work, but the full job usually needs skills across ERP configuration, XML formats, validation, archiving and security. Internal staff can often own master data, business rules and testing with trading partners. Harder areas include mapping invoice fields to the required formats, building validation and error handling, designing archive storage that supports GoBD-style record keeping, and running upgrades without breaking document output. ERPNext offers Server Scripts for custom logic, but from version 15 they are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. Assess which of these skills you already hold before deciding to hire.
What is the difference between Odoo Enterprise and Odoo Community for e-invoicing?
Odoo Community is the LGPL-3.0 open source core, while Odoo Enterprise is a paid edition built on it with additional features and support. The Enterprise source code is not publicly available and requires a subscription or partner access. Standard support on Odoo Online, Odoo.sh and on-premise covers the first three years after a major release and includes security updates and bug fixes. The Community edition has no access to the upgrade service, which matters because German e-invoicing features and format changes must be kept current. Confirm with the vendor which e-invoicing functions are included in each edition for your target version, because module availability can differ.
What should a fixed-scope quote for this work include?
A fixed-scope quote should state the scope, deliverables, assumptions and timeline in writing before work starts. Ask for the following items to be listed separately:
- Which ERP version and edition are in scope, and which legal entities
- Inbound and outbound formats covered, including XRechnung and Factur-X, with the validation approach
- Integrations with ERP modules, document storage, identity systems and any access point or service provider
- Archive design, retention approach and how records are exported for review
- Testing scope with trading partners and acceptance criteria
- Customer responsibilities, change requests and how new mandate changes are handled
- Support and upgrade terms, including whether ongoing support is a retainer
DeployOpen does not publish a price list, and a quote follows from the written scope.
Does archiving e-invoices in a self-hosted system satisfy GoBD requirements?
Archiving design is a compliance question that your tax advisor, auditor and records owner must confirm, and no implementer can certify it for you. The implementation can supply storage that keeps invoices in their original structured form, links them to ERP records and supports retrieval during an audit. Ask the implementer how documents are kept unchanged after issue, how access is logged, how backups are tested and how retention periods are enforced. For broader context, the SEC's Rule 17a-4(b) on record preservation applies only to broker-dealers, so most German companies will rely on their national tax record requirements instead. Confirm the applicable rules with your tax adviser.
How to confirm the German rules and platform capability before you commit
Confirm the current German obligations before any scope is fixed. Ask your tax adviser to state, in writing, which of your invoice flows fall under the receiving obligation, which fall under the issuing obligation, and how the turnover threshold and the EDI exception apply to your company's figures for the years in question. Then check the same points against the official publications of the German tax authority and the *XRechnung* and *Factur-X* specifications, and record the version of each document you relied on. Rules and exceptions in this area change, so the written answer should carry a date and a named reviewer. Treat a verbal confirmation as an open item.
Next, verify platform capability against the exact version you intend to run, not against the marketing page. For Odoo, read the release notes and the localization documentation for the version on your support timeline, and confirm whether the module generates and validates XRechnung and Factur-X output, which validation rules it applies, and whether receiving and parsing of inbound structured invoices is native or depends on an add-on. For ERPNext, check the same points in the release notes of the minor version you will deploy, and confirm whether the output is produced by the standard code or by a community app that your own maintenance process must follow. Ask the vendor to show a generated file and its validation report for your scenario, not a demo file. Note any feature that depends on a paid module, an AI credit or a hosting tier, because those costs recur.
How DeployOpen delivers German e-invoicing on self-hosted ERP
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source ERP platforms inside the client's own infrastructure, including the invoice validation, archiving and receiving steps that German e-invoicing requires. Each engagement starts with a written scope that sets out which platform, formats and processes are covered.
How we scope
- Map which invoice flows are in scope: outbound XRechnung or Factur-X, inbound receipt and any EDI exception cases.
- Confirm the ERP platform, version and edition, including whether Odoo Enterprise or ERPNext is in use.
- Agree deliverables, timelines and acceptance tests in writing before work starts; engagements are fixed-scope.
How we build
- Configure ERP invoice output and validation so documents are checked against the agreed format before they leave the system.
- Connect inbound invoice processing, error queues and master data checks for tax IDs and buyer routing details.
- Set up archiving and access controls designed to support GoBD-oriented record keeping, tested with sample documents.
How we hand over
- Deliver configuration records, test evidence and runbooks that your finance and IT teams can review and reuse.
- Document the validation rules, archive retention settings and change steps for future mandate or format updates.
- Walk your auditors and compliance leads through the controls and evidence, without issuing any audit opinion ourselves.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Plan ERP version upgrades and retest e-invoicing flows on a copy of production before cutover.
- Ask us to confirm which platform versions and support plans apply to your environment before each change.
