Tryton vs. ERPnext


I’m evaluation an ERP system for a small service company, 2 persons (1 FTE) doing invoicing, accounting, payment (SEPA with direct debit) and reconciliation. Both Tryton and ERPnetxt are on the short list. I already gave both a trial and found pros and cons for both.

I’d be eager to learn: Why should I choose Tryton over ERPnext? What makes Tryton superior to ERPnext?

Thanks in advance

Hi James,

Your requirements can be fully managed with our standard modules. It will be great if you can share the country your company is based on to see if Tryton has the localization chart by default or you will need to create your country localization or setup your accounting manually.

This should be an important point to take the decision.

Sincerely I do not know enough details of ERPNext to give this comparison. I know they use a similar stack (Python and PostgreSQL as backend) but IIRC they only have a web interface, while on Tryton we have a desktop application and a web interface also.

I will try to summarise some good aspects of Tryton:

  • We prioritize quality over quantity: we may have less features but we focus on implement them very well and complete
  • One result of the previous point is that Tryton is so much stable and we have stable and LTS releases
  • There is a very active community on this forum which may help you if there is some issues but there is also a list of service providers if you want some professional services

Probably there are more things of the list, just wanted to share some, maybe some other members may complete my reply :wink:

Feel free to ask if you want to have more detailed information of some points that are relevant for you!

Hi James,

Just to add to Sergi’s post.

I also like the fact that:

  • Tryton seems to be well thought out and designed
  • it is fully modular, which means:
    • you can activate just the modules that you need for the functionality that you use,
    • extra modules can be created which can extend, or change, the behaviour of existing modules and your system.

Hi James,

We wil be interested in the result of your comparison.

1 Like

jmiller asked me for an evaluation. Here is my report:

Last weeks I’ve spend some days evaluating ERPnext and Tryton. I read docs, searched the forums, watched tutorials, played with the demo installations available online and inspected the code publically available at this time. My primary aim was to understand the basic concepts of each software, as these are the parts which are near to impossible to change. (Whereas modules/doctypes can be added easily.) I might have missed some details, anyhow I’m confident that the central results are appropriate. Since I’ve been in touch with Tryton some years ago already, the test was more like I benchmarked ERPnext vs. Tryton. This is also why I did not list Tryton’s shortcomings here - which actually exist.

The test was conducted in early February 2021. Tested online ERPNext 13 beta something and Tryton 5.8.

Here is summary of the most relevant insights. TL;DR: I suggest to use Tryton. Tryton is more mature and has a better technical fundament than ERPnext. If you want detailed information, please get in touch at

  • ERPnext’s seems to be more end-user/customer oriented, while Tryton seems to focus more on integrators. E.g. ERPnext has quite some functions (“onboarding”) making it easy to get started and testing, whereas in Tryton such wizards are rejected since there are other (manual) means to achieve the result.

  • In ERPnext you can customize quite some things via the WebUI, not coding is required. E.g. you can easyl customize reports by simple dragging “variables” to the right place. Anyway, one of the Videos warns about customizing DocTypes via the WebUI as this can conflict with updates. Anyhow this might ease prototyping.

  • For customizing Tryton there is a single programming language to know: Python (and some basic XML). Whereas for ERPnext you need to know both Python and JavaScript, as some of the functionality is done on the client side. The later also means you might have duplicate code, e.g. validating data must not only be done in the client.

  • Tryton is much more mature. ERPnext is lacking behind, e.g. my “standard” strings (like “My Settings”) are not translated to German, German charts of accounts is lacking information like account type, SEPA-support, while a central feature for 36 European countries, requires an external “app”, which again is quite huge and and beside SEPA also bings a lot of Swiss-specific extensions. Of course, ERPnext might catch up here in the next years. But given how long it took (in both ERPnet and Tryton) to get to the currents state, I’m afraid this will actually be some more years.

  • Most important IMHO are the basic concepts, which are hard to impossible to change. And this is where ERPnext drops far behind. Some examples:

    • ERPnext is a monolith, it is huge and complex: Alone the source is 20MB ERPnext plus 14 MB for Frappe framework. Plus additional requirements nodesjs and redis. tryton and all core modules total to 13 MB - and one only installs the required ones. While this is only a rough comparison, it gives some idea. And to emphasis: Just the Frappe framework is as huge as entire Tryton.
    • Installing ERPnext is much more work, as there are many more components to be installed. For Tryton you just need Python - not even a DBMS is required for first steps and tests.
    • ERPnext used strings (varchar) as primary keys instead of integers. This not only imposes quite some problems when changing entries, but also is slow and increases storage and memory consumption. The later is esp. true, since every table contains a “modified-by” and “owner” user-id as a string.
      ('I. Vorräte - M','2021-01-28 00:03:29.024872','2021-01-28 00:03:31.265353','', '',0,NULL,NULL,NULL,0,0, 'I. Vorräte','',1,'MyCool','Asset','Balance Sheet','EUR',0, 'B - Umlaufvermögen - M','',0.000000,'No','', 21,26,NULL,0,NULL,NULL,NULL,NULL)
    • As a result of using strings as primary keys: If someone renames an object while working with it, there are also strange effects - because the name is in the URL, and that is no longer valid.
  • ERPnext stores too much personal identifiable data, without any need to store this. E.g. many (all?) tables store timestamps and user, even tables like the user’s own settings. This seems to be build deep into the fundaments of Frappe and implies that removing personal identifiable data is hard up to impossible - which is a thread to GDPR compliance. There is also an “Activity Log” which login/logout timestamps and many other timestamps like when an invoice was created for a order.

1 Like

Thank you @htgoebel for your comparison.

For the Tryton side I would like to share some additional information.

The first-install-wizards infrastructure in Tryton is already in use in several modules:

  • Create User
  • Create company
  • Create chart of accounts

Also we have separated user configurations for every functional topic. And don’t forget to participate our Blank State and Onboarding discussion.

In Tryton you can customise most reports with LibreOffice or an text editor.

Tryton also uses these fields for every table:

  • id as primary key,
  • create-uid,
  • create_date,
  • write-uid,
  • write_date

but we use integer for id and uid and timestamp(6) for the dates. id has default database INDEX and uses sequences. The uid refers to the res_user table, but is not JOINT for some reasons, but Tryton disallows the deletion of res_user entries.

Please become part of our GDPR discussion. E.g. Art. 17 of the GDPR in Tryton is addressed with the possibility to Erase parties at any time. The deletion of a party is done by removing personal identifiable data in fields, but keeping the records to satisfy the existing relational data integrity.


Since this is the Tryton forum, I’m also adding some major drawbacks of Tryton. As you can see, these critic points are quite different to those about ERPnext. While for ERPnext the software fundamentals are deficient, for Tryton it’s “only” the environment.

  • Missing focus on first-time user/evaluators and UX. This can be seen by

    • Tryton having barely setup wizards (Recently I suggested some simple ones, which have been rejected since this can be done otherwise),
    • common feature request being rejected instead of offered as an “contributed” module (e.g. getting prices from articles in invoices, tax-included prices)
    • recent discussion about hiding fields on views
      Your mileage may vary, of course :slight_smile:
  • The scattered and antiquated development tooling (mercurial, codereview, roundup) is a obstacle for contributions. Even simple doc changes are a lot of effort, requiring learning new tools. And IMHO Tryton is in urgent need of contributions, esp. for documentation.
    As a result, many contributors are maintaining theri own copy of Tryton on github or gitlab - which again is scattering the community.

  • Documentation and tutorials are also scattered. (GSoD docu is still not integrated)

  • A common place to collect “contributed” extensions is missing.


I may understand that our tools are not the usuall one but we use them because people that regualiry commit on the project prefer them. We are not gonna change it and we found that this is not really a problem for people that want to contribute.

Having said that I’m always happy to help somebody with the contribution process, so feel free to ask on our forum and we will provide as much as help as possible.

If you plan to contribute to our documentation and you do not want to deal with or tools I offer myself as bridge between them. In order to do so please create the files following our guideliness, delivery them to my PM box and I will upload to our review process.

Please note that reviewing all the patches that should be included takes time. We can not avoid reviewing patches without lowering our quality. IMHO lowering the quality is not something that will benefit the project.

Having said that, if you want to speed up the process please join the review process.

There is a Third Party Modules category in this module where everyone can share their extensions.

Also there is a Tryton Framework classifier on PyPI which contains oficial and “contributed” extensions.

Personally I prefer to discuss all the features with the tryton community and try to integrate them with the project. Altought this is harder on the short term it produces more benefits on the long.

By the way I was curious if this topic had been discussed on the ERPNext forum and indeed it was:

Some users there have some valid complains wrt Tryton (but @dave is working on the point that is for me one of the biggest : our documentation … thanks a lot!). The UI seems both a blessing and a curse so I would not consider it a complain :slight_smile:

For the biggest issue I had with ERPNext / Frappe was the duplication of the business logic in Python and JS. From my POV this is a big warning sign. But I don’t know much more about it (apart from the fact that indeed their UI is more modern).


Thanks for sharing the link @nicoe! It’s very interesting to see how others see our project.

I really like the comment where they says that Tryton improved a lot in 4 years. This means we are on the right path and we should continue working this way. Big congrats to all how made it :partying_face::partying_face:

On the other side, I think they are right with reporting and dashboards. For now the dashboard functionslity is hidden because we are missing some default dashboards. I know there is a proposal to improve it but is still not implemented.

1 Like