I’m the treasurer for Hackerspace TDvenlo in The Netherlands. Currently I try to do double entry bookkeeping using spreadsheets to do our accounting. However as the saying goes: “If you do double entry bookkeeping in a spreadsheet, you should be smart enough to not use a spreadsheet for double entry bookkeeping.”
Tryton looks very interesting because it allows for the complete workflow for running a company, uses GPL license without a freemium model, allows for importing bank statements, is multi user, programmed in a sane language (Python), has support for the Netherlands, allows for attachments, not impossible to install, people can create their own modules and is actively maintained. Which would write off most of the gratis competition.
I do have some questions though:
Could I use Tryton as a general ledger and start migrating more and us[e more features later on? I would like to input our expenses at this moment. But I don’t like to duplicate the membership administration or connect our POS for the bar.
As we currently have an association, our members pay monthly or yearly in advance via bank transfers, without receiving an invoice. At the moment all money received is put on a debit ledger account. Then at the start of the following month, I transfer the monthly revenue to the revenue ledger account. How would I do this workflow in Tryton? Or is something else more advisable.
If I start accounting for this year now from 2024-01-01. Could I also import the bank statements from previous years on a later moment. In order to import the history of our association.
At the moment my main workflow is by importing bank statements every month and then generate the expenses and revenue by consolidating them. I would guess by using Tryton, this would go the other way around?
As a small association, we currently do not have to do VAT / BTW taxes. Is that easy to handle in Tryton?
I think those are the biggest questions I have for now.
I guess the money you receive will be put on the receivable account of each party. And each month you create the membership invoice for each member.
The reconciliation wizard will try to pay the invoices with the corresponding prepayment.
Or you could also book the money received as deposit and then recall the deposit when emitting the membership invoice.
The advantage of this method will be that the exact amount will be taken from the deposit and so the invoice will always be fully paid even if the payment was more than the invoice.
You could but then you must not start with an existing balance move otherwise you will double it.
Tryton accounting is based on accruals accounting so it means that bank statement does not create expenses or revenue. You will have to create an invoice for each expenses and revenue. Then you will have to reconcile them with the payments from the statements, you have not create the invoice before the statement is imported.
Well you can book the expense with the price tax included or you can use the Account Tax Non-Deductible Module to have Tryton compute the amount tax included based on a unit price without tax and tax definitions.
PS: If you have further questions, I think it will be better to start a new thread per question from this topic.
I so that too. At the start of the year a generate the receivable line (account receivable to account revenue), and then i reconcile the movement generated by the imported statements (cash/bank to receivable). This has the problem that the account revenue doesn’t respect how many members has payed their dues. But for my case (and maybe yours) this is ok. I’m the author of the membership module, but you don’t need to use it… you can just create your module that pull a list of parties from your membership software, and generate the receivable lines based on the membership status.
Thank you for the elaborate answer. Further questions will get their own topic, but these were the most burning questions I had. Most of them are answered. I will also look at Accrual Accounting, to get a better feel for what I’m working with.(Update: After looking a bit further, it seems that Accrual Accounting is the same ‘pemanantie’ in Dutch. Which we also learned to do in double entry bookkeeping in the 90s.)
With reference to importing the bank statements. I think I will import the whole history, then only reconcile 2024 and maybe work backwards. That will probably reduce the amount of changes afterwards.
My first try I got overwhelmed with the whole workflow and possibilities and all I wanted was a ledger. I have no need for invoices, warehouse, employees and other stuff.
Thus I went back to basics to see if I could get it working. This might not be the ‘ERP’ Tryton way, but at least this is doable as a hobby. I just started with only the account, currency and country modules. Created a company, defined Euro currency and fiscal years. Using the end of 2023 to fill the balance just before 2024. Then started porting my Chart of Accounts and link them to the Account types.
I was able to do some transactions via ‘Account moves’ and I’m able to show overviews of the balances and results. This will do for now.
The next puzzle is on how to import all the bank statements as separate ‘Account moves’, edit them and then post them. Although there should be a better way I guess.
Addendum: It seems that the ‘Statement’ module should be able to import the bank statements.
Thank you. I already explored what solutions there are for the Account Statement Module. But haven’t gotten around to implementing yet. Converting the CSV I get from my bank to an accepted format looks best. Since I then have one source for my whole workflow.
If I look at the different supported formats. Both CAMT.053 and MT940 seem the most appropriate.
CAMT.053 seems to become the future. If I look around, it seems the Dutch banks have chosen to work with a separate file per transaction. Which means extra work. If I download CAMT.053 from my bank, there’s not much extra useful information than with the CSV file. But it has sequence and a unique identifier. And a zip file with lots of xml files.
MT940 is old but allows for grouping everything together and check the balance per day. Although it looks like it was developed in the 70s, at least it’s not XML.