Get access to the industry's best-kept secrets that affiliated providers never share with you.
Why hasn’t the ERPNext Hungarian invoicing solution been completed yet?
Many laypeople often say that invoicing is straightforward because there is a lot of data available, and ERPNext is used in many countries along with other international solutions for invoicing. In such cases, the simplest way is to show the Hungarian VAT law, which regulates most of the invoicing-related questions. Yes, not only is the 27% VAT a world champion, and although we haven’t compared, it is almost certain that our VAT law is the longest, which is not necessarily advantageous. Invoices have mandatory content elements, such as dates. However, the specific dates to be included in a date-type field in invoicing are determined by the kilometer-long VAT law. This can largely be said for other content elements of the invoice as well. And then we haven’t even mentioned the mazes of exceptions and exemptions with their special conditions.
We can conclude that Hungarian invoicing, in light of the above, is more complex than being quickly implementable into an international system. And here is another crucial point: we are talking about an international system concerning ERPNext Hungarian invoicing. The system provides solutions for general matters, but for most - country-specific - issues, it does not. We need to complement this by saying that we want a solution - since ERPNext can handle multiple organizations/companies with a so-called multicompany setup - that allows the combined operation of companies in multiple different countries.
We could say that the Hungarian invoicing solution isn’t ready because it’s too complex, not a priority, etc. While all these reasons are true, the reality is that we’ve previously developed an invoicing solution for ERPNext version 13 towards the szamlazz.hu system using the make (formerly integromat) solution. We also have experience with Odoo invoicing. However, based on all these experiences, we wanted to provide a more comprehensive solution for our clients, requiring more planning and decision-making.
It is crucial for us to maintain the fundamental accounting functionality of ERPNext, and we want to enhance and supplement it to comply with Hungarian regulations in the future. Thus, we are not just talking about invoicing. Besides the mentioned synchronization solution for invoicing integration, we have various possibilities for native NAV API-based solutions and intermediaries, such as using szamlazz.hu and billingo.hu. We can create our invoicing module with our own doctype and workflow or complement the existing invoicing system with the necessary Hungarian invoicing functionalities. This involves not only adding new fields and data exchange but also overriding basic functions. All of this with company-specific administration and long-term sustainability, updateability. Previously, there was no or limited ERPNext implementation suitable for other countries, so the basic ERPNext software was not always suitable for Hungarian invoicing implementation. It would have required replacing many nonexistent functions or completely rewriting existing logic in a customizable way, so it wouldn’t have been just about localization. Some of this has persisted, such as advances, cancellations, and modifying invoices. However, the new ERPNext versions have not only reduced/simplified our tasks in various invoicing-related aspects but also provided guidance on certain questions, especially those related to solutions in other countries and the necessary foundational modifications, as discussed below.
Approach to Developing Hungarian ERPNext Invoicing
Considering various factors, such as those mentioned above, we initially planned a direct invoicing submission through the NAV API. We also explored the option of Chrome headless Online Invoice submission, but ultimately, we opted for integration.
What are the advantages of this approach? It ensures that ERPNext is not the invoicing program itself. Although it’s no longer mandatory to report the invoicing program to the National Tax and Customs Administration (NAV) nowadays, the need for mandatory data export functionality still exists. Our solution simplifies our lives and the lives of our clients by maintaining the status of a business management system with invoicing capabilities. Even though the use of the NAV online invoice API is unavoidable if we want to obtain Hungarian name and address data based on the tax number for free, and load supplier numbers into the system, we don’t intend to implement this as the first step. Similarly, we don’t plan to implement the download of taxpayer and taxpayer status from VIES in the initial phase (although proof of concept has already been completed for both). However, this implies that our solution needs to be built in a way that is compatible with these aspects. This approach allows for potential future direct NAV online invoice submission or the replacement of the chosen invoicing API with another partner, making the task even more complex. APIs provide some guidance, especially when the extensive VAT law is not formulated precisely enough. In such cases, the data received by the API can be treated as a suggestion, subject to our evaluation.
Although we’ve mentioned it before, it’s important to emphasize at this point that we need to understand the basic functionality of ERPNext. This is crucial because the basic ERPNext system is already complex, with various functions related to invoicing, which, to some extent, can be used or must be considered during the implementation of Hungarian invoicing. For instance, we want seamless cooperation of all functions with the Hungarian localization. Although it may seem trivial at first, features like automatic invoice generation, subscription management, and their compatibility with continuous performance Hungarian invoices are not straightforward in reality. Adding to the complexity is the fact that some countries have already released ERPNext invoicing localizations, fortunately built on the basic ERPNext, and not starting from scratch, only solving the implementation on the Frappe Framework. Since we want to remain compatible with these implementations in a multi-company setup, it becomes a challenging task. Even though modifications in these implementations and the core (basic) system needed for them can assist in shaping Hungarian invoicing, it remains a non-trivial task.
For example, the globally spreading e-invoicing (mandatory in all EU member states from 2028) has implementations in Italy, and there are solutions in Gulf countries, India, and the English Make Tax Digital. Hence, we try to take into account both Hungarian and foreign APIs and existing implementations, which is not an easy task.
How do others do it?
We would like to introduce another perspective: industry best practices. Since there are Hungarian solutions for other software as well, we have collaborated with many professionals who have been decision-makers in similar projects. Based on their implementations, we might think that it is easier to develop Hungarian invoicing in ERPNext. This is partly true because we will probably make new mistakes that those who have worked on similar projects before have not made. However, it is important to highlight a fundamental question that we have not observed with any software regarding Hungarian invoicing. We touched upon this briefly earlier: the implementation of invoicing did not happen from an accounting perspective; in most cases, only invoicing questions were taken into account.
We know of two specific examples where they paid significant attention to the usage of dates (such as invoice date, fulfillment date, etc.). However, they reused the existing date functions of the base system in such a way that they cannot correctly record every economic event, requiring various tricks. We were also inclined to this approach, for instance, making the VAT performance date the base ERPNext invoice date. However, in our opinion, this is a dead-end, as it does not provide as much benefit—meaning, we won’t save much effort on other developments—as the headache it causes. Staying with the example, we prefer to take on the approach of using additional date fields, even if their number doesn’t matter much when automatically populated. This way, every economic event becomes recordable in the system.
The essence is that we not only enable the recording of mandatory invoice data but also provide the data necessary for its accounting. This becomes interesting, for example, when we want to account for invoices not only from our own system. More specifically, if we use the base date field for accounting or VAT dates, many basic ERPNext functions would still be available by default. So, what’s the problem? The issue is that, for example, basic ERPNext reports, such as the VAT report, would still not comply with Hungarian rules, and they would need further refinement. Here came the realization that if we have to create custom reports for Hungarian invoicing, it’s simpler to build it from scratch, as mentioned earlier, ensuring that all necessary data is available—meaning, handling multiple dates, for instance.
Then, what do we use the existing dates for? Everything they are fundamentally meant for. This reduces the number of additional date fields to be introduced, for example. Most misunderstandings arose here about what each field is actually for. The base invoice date field is the date when we want to include the invoice in our own accounting. This is often not a matter of choice, but for example, if we receive an invoice for a closed tax year later, we can only book it for the current/following year, despite the need for the original VAT return date and leaving the issue of deferrals aside. Also, we haven’t mentioned continuous performance invoices, with start and end dates, which can be considered as a period but can also function as a financial performance date.
Due to the thoroughly dissected complexity, we try to take these discussed topics into account. However, precisely because of these complexities, we are working on delivering smaller, more manageable units. Regarding invoicing, the goal is to enable the issuance of customer invoices as soon as possible, and only then expand the scope. Although it would be good to include as many features as possible, such as using the Nomenclature of Goods and Services codes, as the Indian solution does, we do not want to further delay the release with that.
What did we forget? What we forgot is that we want a customer invoicing solution that can be easily applied to recording supplier invoices as well. This means that the workflow, fields, and operations on both sides can be identical, simplifying the everyday lives of users, which is also not trivial. And then there’s the VAT. Yes, from 2024, it’s the eVAT, expanding the approximately 30 tax codes known so far to 236, and we haven’t even talked about other taxes and declarations related to invoicing, such as packaging product fees or the National Tax and Customs Administration (NTCA) in the case of accommodation and catering. That’s why we focus on the smallest unit, which is issuing customer invoices. However, we can also mention the cash bases accounting (e.g., sole proprietorship) and VAT cases, which we currently do not plan to implement because we see a detour for them, for example, with the mentioned custom reports, but we try to take them into account. Furthermore, it is an interesting question how to handle manual and automatic submissions, errors, resubmissions, cancellations, amends, and any corrections.
Another interesting question was the organization of the app. Earlier, we considered several smaller apps, so that each part could be used separately. However, since this is almost all Hungarian-specific, and here, without each element, it is hardly usable, we prefer to think in terms of a comprehensive solution. For example, there is a need for MNB exchange rates in most cases, which has also been completed at the PoC level.
Why was this post created? Beyond welcoming feedback, questions, ideas, and suggestions, we follow these as guiding principles when making decisions, and it also helps summarize thoughts from which we can create goals and tasks for their implementation.
We don’t know the details of the publication yet. The idea of a free open-source edition has come up several times, which is still a possibility, despite one of the solutions we created - bank account synchronization with GoCardless integration - being offered as a monthly subscription SaaS, i.e., as a cloud service. We made it available in this way because another ERPNext partner developed a similar paid solution, and we didn’t want to interfere with them by releasing a free competing solution. So, we consider this solution not as a source of income but rather as a feasibility study, which is still uncertain for Hungarian invoicing.
A copy of this post has been published on the forum to facilitate discussion:
https://discuss.frappe.io/t/hungarian-invoice-magyar-szamlazas/64970/15