> 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.