1. This is a familiar problem and it is where I spend the majority of time. If a bank provides a unique transaction ID the it would be a simple matter of code; however, none of mine do. What I do when I spot problems is run `hledger areg <account> --begin=<last month> --end=<this month>` and compare with the CSV. Opening the output of that command + this months CSV in vim using vertical split (`vsp`) and scrollbind (`scrollbind`) so each line scrolls together works well and is pretty quick. It's still a problem and a pain.
2. This is solved in my system in a robust way (I believe) with a "virtual account." I do most of my spending on my credit card. Then every month I pay off the card from my checking. To represent this I need to see:
- liabilities:credit with any balance I carry
- expenses should show a transfer from liabilities:credit to the correct expense category/account
- I should avoid being "double charged"; i.e., when I pay off liabilities:credit it should NOT be an expense.
I've set it up like this:
- rules/debit/journal.rules: if (payment to credit) then account2 assets:transfer:credit
- rules/credit/journal.rules: if (payment from debit) then account2 assets:transfer:credit
This becomes a way to spot problems. If assets:transfer:credit ever has a balance then something may be awry and you should spend some time digging. I do the same thing for Amazon. Each Amazon order is for multiple expenses. I have assets:transfer:amazon. This is how I learned the the $0.29 Colorado retail delivery fee is not universally applied to orders from Amazon—that was a frustrating journey!
3. I haven't worried about this. Looks like other good responses in this thread.
1. This is a familiar problem and it is where I spend the majority of time. If a bank provides a unique transaction ID the it would be a simple matter of code; however, none of mine do.
This is an annoying problem I've had to deal with also (banks have some unique ID somewhere, why not provide it?).
I create my own unique ID to the extent that it's possible. Some txns have the exact same info but are 2 sep txns, requires a bit of messy logic.
Comments
Great questions.
1. This is a familiar problem and it is where I spend the majority of time. If a bank provides a unique transaction ID the it would be a simple matter of code; however, none of mine do. What I do when I spot problems is run `hledger areg <account> --begin=<last month> --end=<this month>` and compare with the CSV. Opening the output of that command + this months CSV in vim using vertical split (`vsp`) and scrollbind (`scrollbind`) so each line scrolls together works well and is pretty quick. It's still a problem and a pain.
2. This is solved in my system in a robust way (I believe) with a "virtual account." I do most of my spending on my credit card. Then every month I pay off the card from my checking. To represent this I need to see:
- liabilities:credit with any balance I carry
- expenses should show a transfer from liabilities:credit to the correct expense category/account
- I should avoid being "double charged"; i.e., when I pay off liabilities:credit it should NOT be an expense.
I've set it up like this:
- rules/debit/journal.rules: if (payment to credit) then account2 assets:transfer:credit
- rules/credit/journal.rules: if (payment from debit) then account2 assets:transfer:credit
This becomes a way to spot problems. If assets:transfer:credit ever has a balance then something may be awry and you should spend some time digging. I do the same thing for Amazon. Each Amazon order is for multiple expenses. I have assets:transfer:amazon. This is how I learned the the $0.29 Colorado retail delivery fee is not universally applied to orders from Amazon—that was a frustrating journey!
3. I haven't worried about this. Looks like other good responses in this thread.
This is an annoying problem I've had to deal with also (banks have some unique ID somewhere, why not provide it?).
I create my own unique ID to the extent that it's possible. Some txns have the exact same info but are 2 sep txns, requires a bit of messy logic.