Unfortunately Firefly is not really a double-entry bookkeeping system. There is a differentiation between source and destination accounts (called expense and revenue) which makes reverse transactions a pain. I pay 100€ for furniture in May and return it in July. Now I can either create the furniture store as both source and destination account or delete the first entry. Both is equally bad in my opinion.
I think a much better solution would be to differentiate between my accounts and 3rd party accounts.
Also, what I was struggeling with (and not only in Firefly, but all budgeting apps) was the sometimes significant delay between the purchase and the bank transaction. In addition there is the issue with split transactions from imported transactions. Basically manual data entry is too much work and automated data entry is too faulty. I roughly sketched a process in my head which could solve that.
It basically disinguishes between manually added information and bank information. Both is stored and then combined to one transaction. This closes the gap between the bank domain and the "user domain".
1. Let the importer bring in all the bank transactions with the date, the transaction is executed. Display on the right.
2. On the left there are manually entered transactions, possibly with split transactions.
3. Now you make matches.
4. If there is no manual entry, you can add some information like splitting the transaction, add a date you did the purchase, etc. by clicking on the bank transaction.
5. All the above could be automated by rules. Like making matches, giving it a pretty name, assigning a category, etc.
6. Last step: Manually sign off all the matches. If a time period has only signed off transactions it gets a "true" designation otherwise a "preliminary".
> There is a differentiation between source and destination accounts (called expense and revenue) which makes reverse transactions a pain
Sure, but that doesn't make it any less of a double-entry bookkeeping system.
> Now I can either create the furniture store as both source and destination account or delete the first entry. Both is equally bad in my opinion.
The first is correct bookkeeping. The second is bad.
Regarding the process you suggest, each step in your workflow is a massive undertaking to build. And it serves exactly one (1) user for whom the workflow fits: you.
It's how I started Firefly III: solving my own problem. So I guess you know what to do ;)
>> There is a differentiation between source and destination accounts (called expense and revenue) which makes reverse transactions a pain
> Sure, but that doesn't make it any less of a double-entry bookkeeping system.
Maybe let me formulate it a bit more diplomatic: It is not what I would expect from a double-entry bookkeeping system. Personally I find one account for each person more intuitive. There may be reasons for not doing this but they are not clear to me yet.
> Regarding the process you suggest, each step in your workflow is a massive undertaking to build. And it serves exactly one (1) user for whom the workflow fits: you.
> It's how I started Firefly III: solving my own problem. So I guess you know what to do ;)
I know that implementing this process is not walk in the park. Please don't see it as a request for you to implement that particular feature because I need it. But for me this would solve an issue I had with all of the personal finance tools. Therefor I wrote down my thoughts, maybe they resonate with someone and it results in a fruitful discussion. Or maybe someone had similar thoughts...
> There is a differentiation between source and destination accounts (called expense and revenue) which makes reverse transactions a pain. I pay 100€ for furniture in May and return it in July. Now I can either create the furniture store as both source and destination account or delete the first entry.
The use of expense and revenue accounts is standard, but I find it surprising that you can't enter a negative amount for a payment. There isn't even a "return" transaction type with a similar effect. That's how I would handle returns in my own accounting software (HLedger): Original payment, $100 from checking (asset) to merchant (expense). Return, $-100 from checking to merchant, with a comment identifying the original transaction. It doesn't make sense to have separate "Furniture Store" expense and "Furniture Store Return" income accounts—that does not provide accurate income & expense reporting. Logically, after the return you have no expense or income related to that purchase.
Of course HLedger, being much less opinionated, doesn't actually care about "source" and "destination" accounts—that's a matter of how you interpret them. IMHO it's far easier to just think of the accounting system as a single directed graph where nodes are accounts and edges are transactions. A "negative" edge is just a transfer in the opposite direction.
This does mean that the income/revenue accounts have negative balances, which can be counter-intuitive, but it makes sense once you learn to think of the income account balances as reflecting changes in the source of money (i.e., $-100 in an "employer" income account means your employer has $100 less because they it to paid your asset account) rather than the amount of income you've received. Likewise, a positive balance in an expense account means that the recipient of that money has more because of your payment, not that you do. Assets and liabilities are your accounts and sum to your net worth; the equity accounts, which I would define to including income and expense accounts, belong to your counterparties, and are relative rather than absolute since they only reflect the transactions which are relevant to you.
> Also, what I was struggeling with (and not only in Firefly, but all budgeting apps) was the sometimes significant delay between the purchase and the bank transaction.
HLedger addresses this by tracking two separate dates for each transaction, with options to choose which one to use for a given report. This can cause some issues with balance assertions which lie between the two dates, though, so I just use a priority system—the date my bank shows is always "right" even if the transaction occurred some days prior. It would be nice to be able to set a date for each account, which would probably fix the balance assertion issue, but then you could have transactions which didn't balance (sum to zero) for certain intervals. (Perhaps this is acceptable as long as the transaction eventually balances?) HLedger, like most other accounting software, also tracks flags for pending and cleared transaction which can be used in reports and queries.
Thanks for mentioning that. It looks like there is support in HLedger for per-posting / per-account dates via `date:` tags[0]; I'm not sure how I missed that before. For the auxiliary dates, I suppose one could just ignore balance assertions when using the `--date2` option, but IMHO it would be better to set a posting date for the bank account for when the transfer cleared rather than an auxiliary date on the transaction as a whole. The expense account would then show when the expense was incurred, and the bank account would show when it cleared. Usually only the latter would have a balance assertion.
Also, what I was struggeling with (and not only in Firefly, but all budgeting apps) was the sometimes significant delay between the purchase and the bank transaction. In addition there is the issue with split transactions from imported transactions. Basically manual data entry is too much work and automated data entry is too faulty. I roughly sketched a process in my head which could solve that.
It basically disinguishes between manually added information and bank information. Both is stored and then combined to one transaction. This closes the gap between the bank domain and the "user domain".
1. Let the importer bring in all the bank transactions with the date, the transaction is executed. Display on the right.
2. On the left there are manually entered transactions, possibly with split transactions.
3. Now you make matches.
4. If there is no manual entry, you can add some information like splitting the transaction, add a date you did the purchase, etc. by clicking on the bank transaction.
5. All the above could be automated by rules. Like making matches, giving it a pretty name, assigning a category, etc.
6. Last step: Manually sign off all the matches. If a time period has only signed off transactions it gets a "true" designation otherwise a "preliminary".
Happy to hear about your thoughts on that!