Datev vs. Integrated Accounting

Datev vs. Integrated Accounting

This topic is always a major point of discussion in every project. 

The reasoning is clear: an integrated accounting system with real-time feedback on various financial aspects is more than just a convenient feature. The most straightforward example is the ability to track the payment status of an invoice and its corresponding receivable. This enables an integrated dunning process, which in turn makes the customer's dunning status transparent for sales and account management.

And of course, it eliminates the need for separate financial software and removes the necessity for a bridge - whether bidirectional or unidirectional, manual or automated.

Then why the discussion?

Here is the current status of all relevant information, starting with the most well-known examples.

DATEV

Pro Datev

Datev is the dominant player in Germany, and this is likely the main reason this discussion even takes place. Datev is perceived as flawless and 100% secure. Whether this is actually true - or whether its reputation is similar to that of SAP, where failed implementations are never attributed to the system itself - is difficult to say. After all, no system is infallible, and none can entirely prevent user errors. The only way a system could completely eliminate mistakes would be if no one were able to enter any data into it at all.

However, the sense of security is likely the biggest factor behind Datev’s dominance. The fact that Odoo is not certified in Germany further reinforces this. Additionally, most finance professionals have experience working with Datev or other well-known alternatives, making it the default choice for many businesses.

These points clearly speak in favor of Datev.

Interfaces and Data Exchange

It gets even better: Datev offers a CSV export for batch bookings, an XML export for document-based accounting entries, and, more recently, a REST API. This means that data transfer to Datev is reliably possible via export. As for the REST API, we are not yet familiar enough with its full capabilities to determine exactly what data can be exchanged and retrieved. However, expectations and hopes are high that it will provide greater flexibility and automation.

Whatever the scope of data exchange may be, it remains an integration, and integrations are cost-intensive - both in terms of implementation and ongoing maintenance. Additionally, as long as an API is not in use, there will always be a time lag in data synchronization between systems.

These points should be carefully considered, and they don’t just apply to Datev but also to its alternatives.

The Data Transfer Itself

Which data is affected, what is critical and what is not?

Fundamentally, there are two main data categories: master data and transactional data. However, Datev divides them into four categories: master data, accounts, cost centers, and bookings. The good news is that, unlike e-commerce integrations, a bidirectional data exchange is rarely necessary in any of these categories. Master data is typically most up-to-date within the ERP system. Bookings are generally not modified - any corrections are handled through reversal entries. New accounts and cost centers only need to be created in the leading system, which, in most cases, is the ERP. Since an established chart of accounts remains largely unchanged (except for debtors and creditors), adjustments are relatively rare. This significantly reduces complexity and risk, making the integration more manageable.

But let’s take a closer look at each point individually:

Master Data

Master data is perhaps the least critical aspect, which is why it is addressed first.

There is a dedicated specification for importing debtors and creditors, along with a corresponding file format. However, the number of columns required for transmission is so extensive that development would be highly complex and time-consuming. In practice, master data is mainly needed for the dunning process, which is typically handled within the ERP system. As a result, transferring this data is not a top priority, especially since address data can be included with the booking entry.

Bookings

At the end of the day, Odoo also generates a batch of accounting entries, whether automatically in the background through the creation of documents or directly by the user. Since posted transactions cannot be modified, an export simply processes the confirmed booking batch and transmits it either via an API or as a file. With Datev, the only distinction that needs to be made is whether the booking has an associated document. If so, the export is in XML format; otherwise, it is in CSV format. Theoretically, using only a CSV file would also be an option.

This approach naturally requires that the chart of accounts and all assignments recorded in the bookings align with Datev or the respective financial software.

Since Odoo can mark exported booking entries as "exported" after a successful export process, this ensures that duplicate exports cannot occur.

Whether the reverse process is necessary depends heavily on the system setup. If dunning is handled in Odoo, a return import is unavoidable. However, if this is not the case, importing data back from the financial system is more of a luxury feature, as month-end or year-end closing results are generally not highly relevant for ERP operations. That said, even if the data itself is not essential, synchronization between both systems could still be beneficial for one key reason: If discrepancies arise, there needs to be a starting point for investigating and identifying the root cause. If each system is missing key information from the other, troubleshooting can become significantly more time-consuming and frustrating.

However, if dunning is to be handled in Odoo - perhaps because it supports multiple languages, unlike Datev, or because the dunning status is needed for deliveries or a prepayment process - then at the very least, payments must be imported back into Odoo. While the status of an invoice is technically stored in a physical field, this value cannot be manually set by a user; instead, it is calculated by the system based on open items. This means that the balance is automatically determined by the difference between the linked entries - one for the receivable or payable and another for the payment.

How this scenario will work with Datev’s REST API is still unclear at this point. For now, the only available option remains a file-based export to Odoo. Datev does offer an "XML variant", but in reality, it is simply a CSV file embedded in XML format - nothing more. The CSV export is essentially a batch export of pre-marked bookings. And this is where the challenge lies: Bookings must first be manually marked in Datev before they can be exported. There is no delta export - meaning there is no automatic option to request only the records that haven’t been exported yet.

Error-free looks different, but if there’s no alternative, this is the path that must be taken. Perhaps this will change in the future with the API.

Accounts

Here too, Datev provides a dedicated import function for creating accounts. However, how often does a chart of accounts actually change, excluding debtors and creditors? Since such changes are rare or should be, this function is generally unnecessary - especially if Datev is defined as the leading system. In that case, any newly created account in Datev would simply need to be added in Odoo as well.

Challenges with Debtors and Creditors

The situation becomes more complex with debtors and creditors, as Datev and Odoo follow two fundamentally different approaches.

Odoo maintains a hidden field in the master data called "Commercial Partner" (or "gewerbliche Einheit" in German). When a user creates a company, this field stores its own database ID. If the user creates a contact, the field contains the database ID of the associated company. When an invoice is created - whether addressed directly to the company or to a different billing address - several automatic assignments take place upon validation of the booking entry:

• Revenue/Expense: 
  Each product belongs to a product category. Either at the category level or directly on the product, a revenue and expense account can be configured. This information is used for posting revenue and expenses accordingly.
• Taxes: 
  The tax rate assigned to the product, combined with the tax configuration on the customer or invoice, determines the tax treatment. This setup is designed to significantly simplify accounting.
• Receivables/Payables: 
  When an invoice is created, the debtor or creditor account is pulled from the customer or supplier record and assigned to the invoice. During the posting process, this account is used, and the corresponding gross amount from the invoice is applied.

The principle remains the same, whether it’s a customer invoice or vendor bill, or a credit note for either.

However, in the journal entry, Odoo always records the Commercial Partner (or gewerbliche Einheit) in a separate field. This means that regardless of the account used, the account structure, or even if the entire structure has been modified, all transactions related to a specific customer or supplier can always be retrieved and viewed through their respective partner record. This system works both ways, allowing navigation from the partner (customer or supplier) to all related bookings, or from a booking entry to the full partner record, including all transactions, invoices, sales orders, and any other relevant information - provided the user has the appropriate permissions.

This means that in Odoo, it doesn’t really matter whether a general account or a dedicated account per partner is used. The actual receivable or payable is always determined through the Commercial Partner assignment. However, this also means that billing addresses in master data should not be changed, as this could impact historical records and financial reporting.

Since this setup makes Odoo significantly more flexible, the system is designed by default to post to a general account, which is even the main ledger account. I am aware that this might cause an uproar in accounting, but we will address this separately. However, regardless of the reasoning behind this approach, the fact remains that this is how Odoo operates. Datev, on the other hand, uses individual sub-ledger accounts and consolidates them into a main ledger account. Odoo, in contrast, posts directly to the main ledger without creating separate accounts, eliminating the need for consolidation. In other words, these are two fundamentally different accounting approaches coming together.

Of course, Odoo can be configured to check, upon order or invoice confirmation, whether it is the customer’s first transaction. If so, a dedicated account can be created for the partner, replacing the general account. This setup aligns Odoo’s logic with Datev’s approach.

However, this also means that before exporting to Datev, the account must first be manually created in Datev. Another drawback arises within Odoo itself. In Datev, accounts belonging to the main ledger are configured to appear on the balance sheet, and the same setup applies in Odoo. Since Odoo does not consolidate from a sub-ledger to the main ledger, each individual account appears as a separate entry in the balance sheet. An alternative approach would be to configure newly created debtor and creditor accounts as balance-relevant during automatic account creation, but this would result in every single account appearing in the balance sheet. While this can be adjusted based on the specific scenario, it requires additional configuration to ensure proper reporting.

In short, no matter how you approach it, none of the available solutions are entirely ideal. The simplest option might be a return import from Datev, but as mentioned earlier, this also introduces potential sources of error.

This can only be resolved through collaborative coordination.

Cost Centers

Odoo also links the cost center directly in the journal entry. Since each journal entry generates individual line items, multiple cost centers can be assigned within a single accounting entry. This information can also be exported and transmitted to Datev.

Whether this is truly necessary remains the key question. Cost centers primarily serve as a business analysis tool and are less relevant for general ledger accounting, month-end, or year-end financial statements. The same applies to reallocations within the cost center structure, whether for distributing general costs to projects or transferring material expenses.

If cost centers are to be included, Odoo should be considered the leading system. This means that whenever a new project, cost center, or cost unit is created, it must be set up in Odoo before exporting data to Datev.

The Configuration

Of course, Odoo and Datev must be configured in alignment. Special attention should be given to the problematic aspects mentioned earlier. Since the export process is manual, it becomes even more critical to clearly define the leading system for each area to ensure consistency and accuracy.

ODOO

One might think that everything against Odoo is a point in favor of Datev, and vice versa. However, it's not that simple. So, what are the advantages of Odoo, and what needs to be considered when setting it up?

What Speaks in Favor of Odoo?

What clearly speaks in favor of Odoo is the real-time processing of documents and the immediate availability of information across all modules, ensuring seamless interaction between all components. Another advantage is that there is no need for translation between different accounting logics. Every translation introduces potential errors and maintenance efforts, particularly when troubleshooting issues, as it requires considering the logic of the external system as well.

As the volume of data to be processed grows, the number of systems involved should be minimized to reduce interfaces and potential points of failure. Utilizing Odoo’s integrated accounting module is the most logical approach. In summary, one could say:

Odoo introduces new concepts that may seem unfamiliar to traditional accounting systems but can significantly simplify processes when properly utilized. Otherwise, the fundamental principles remain the same, and when correctly configured, Odoo operates within standard accounting rules.

Another strong argument in favor of Odoo is that by utilizing the Sales, Purchase, and Inventory modules, a large portion of all business transactions is already captured and pre-processed. After a review, the necessary accounting information is readily available. This means that after a visual and content check, the system can automatically generate journal entries upon confirmation. This process extends beyond just creating customer invoices or reviewing and posting vendor bills and their associated payments—it also includes inventory valuation, contract management, and the generation of recurring journal entries based on those contracts.

What Needs to Be Considered?

To achieve this, several aspects must be carefully considered during setup and usage:

The Technical Base

The most important aspect is ensuring that no installed modules compromise or undermine audit security. We have published a seperate Blog ​

This includes canceling an existing booking without a reversal entry and the ability to delete generated invoice documents, both of which could compromise audit security.

Specialized Personnel

Even though Odoo automates part of the process by pre-accounting business transactions, tasks such as bank reconciliation, clearing receivables, recording receipts, correcting misclassified transactions due to incorrect master data, and rebooking incorrect postings still require manual evaluation. In these cases, assessing and correctly recording financial information is no easier than in other systems. Therefore, these tasks should always be handled by a user with proper accounting expertise.

Training

Equally important is conducting training with a knowledgeable instructor who understands common use cases and can address questions in industry-specific terminology. This training goes beyond simply teaching how to use the module correctly - it is also about building trust in the system. Since Odoo is a web-based application and may be an unfamiliar name to some users, it introduces new conceptual approaches that must be explained and demonstrated. Addressing these concerns is crucial not only to instill confidence in achieving the same reliable results but also to help users understand and embrace the new methodology, ensuring that its advantages are fully realized.

Lack of Certification

The final point of criticism remains: Odoo has not yet obtained certification in Germany. While achieving this is not overly complex, Odoo currently lacks a GoBD-compliant export. However, it is important to note that this export is merely a recommendation and is not a mandatory requirement for software compliance. To meet regulatory standards, the system must ensure that individual transactions on an account can be tracked and printed (Odoo fulfills this requirement), that for each document-based booking, the corresponding document must be available (Odoo also fulfills this), and that documents must be unalterable (This can also be ensured - see "Technical Prerequisites" above).

Regarding the integration with Datev, this means that it is not sufficient to reconcile a trial balance with Datev on a monthly basis. Instead, an export of individual entries should take place. However, if a month-end closing is also performed in Odoo, the corresponding transactions could be part of the batch export to Datev. In this case, Odoo would be the leading system, and Datev would be used for the year-end closing, which could also be done based on the individual transactions.

Conclusion

Odoo technically and structurally meets the requirements to properly integrate comprehensive accounting. However, since it follows an international and generic approach, too many things are allowed and left open that are specifically defined and regulated in Germany. This must be taken into account during setup and implemented accordingly. The majority of these issues can be resolved through configuration, but some aspects will still require programming.

Since we did not have a clear understanding of the details and could not accurately estimate the scope, we (like many others) relied on the Datev export, with all the associated discussions and half-hearted solutions when it came to importing the data back. However, depending on the project size and the accounting setup on the client’s side, we are now moving towards an integrated solution. Even though an alternative with a significantly better API is available, using it would require additional effort in the setup to integrate and utilize that API effectively. Furthermore, this would also require linking different accounting logics together.

However, a preference remains a preference. On one hand, every project must approach the decision with reason and careful consideration. Additionally, the individual pros and cons must be evaluated, leading to a decision on how much of one solution and how much of another should be utilized. Even if Odoo achieves certification, this topic and careful consideration will not be resolved immediately. This is because Odoo will first need to gain more recognition and, as a result, build trust in the process.

Was this article helpfull information to you? 
Would you mind to leave us a review of your experiences with openfellas?

​​​​​​review openfellas