> 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 ;)
Technically speaking, it's not really necessary. It does help to validate database consistency, because the sum of all transactions is zero.
It also prevents you (from an architectural perspective) to pull money out of thin air. If you create an account with 1000 on it from the start, there has to be a source for that money. That account is hidden and invisible, but will have a balance of -1000. It may look like nothing, but it helps to keep things in check.
This depends on how you look at financing and budgeting (duh). But Firefly III was originally designed (by me) to lower your running expenses. It doesn't feature a lot cool budget automation because that leads to more charts but less money.
The original idea was to make it hard (or at least with some friction) to create transactions. This also excluded any way of importing data. That way you feel your transactions twice. Once when you spend the money, and twice when you have to enter it.
Making you finances tangible is a very good way of spending less money. Importing all your shit just gives GIGO but with nicer graphics.
Apologies. Firefly III tracks the IP's you login with and warns you when a new one appears. For a demo site that gets slashdotted, that is less than convenient. The issue is fixed and the site is back up.