1. Entries in one month's CSV file may be repeated in the previous or following ... Is your system robust against it?
People use various strategies for this.
You can treat the data as partitioned (eg in months), or as a continuous stream.
In general you can't rely on unique ids, including ones generated from the data (because identical transaction records are common).
hledger has a simple built in method, which works pretty well for most people: it remembers the latest transaction date processed (for each input source).
https://hledger.org/hledger.html#date-skipping
2. Credit card: the total amount for a month is one single entry in the bank's CSV file, while a separate CSV file contains all the details. Do you rely on accounts to handle this indirect flow, e.g. one transaction of 1000$ from checking to cc, based on the single entry of the bank's CSV, then several transactions from cc to the various expense categories, based on the details CSV, and checking that the cc account has a zero balance?
Yes, purchases made with a credit card and paying off the credit card balance are all separate transactions, so the most standard way is record them as such - either manually, or by downloading/converting/importing the data from both accounts. And for extra assurance, assert that the credit card's balance is zero after payoff.
When downloading from both accounts, you get the payoff transaction in both downloads; one of them can be ignored by rule or manually, or both can be recorded with a dummy transfer account keeping things balanced.
If you don't care enough about the detailed credit card purchases, you'd just record the checking data.
3. Some utility companies bill every 2 or 3 months. This makes monthly stats meaningless...
One workaround is to split the expense posting into several expense postings, each with its own date (still keeping them within the one journal entry).
A more strictly correct one is to add transactions and accounts like in evrimoztamur's answer.
Most often I'll just use hledger's -MA flags (--monthly --average).
Can a rule expeess such calculated fields like "set virtual date at 3 month before transaction date"?
hledger's CSV rules can't do this, no. You'd need to either do that manually, or write a custom conversion script (or a custom preprocessor that modifies the CSV before hledger sees it).
That's good for forecasting, but I don't see how to write automatic rules that ensure the accrued amount = billed amount.
Similar answer, if you wanted to generate those verbose entries from a single CSV record, it would need some manual entry or a custom preprocessor script. hledger's CSV rules will only generate 0 or 1 transactions per CSV record.
Comments
Another answer:
People use various strategies for this. You can treat the data as partitioned (eg in months), or as a continuous stream. In general you can't rely on unique ids, including ones generated from the data (because identical transaction records are common).
hledger has a simple built in method, which works pretty well for most people: it remembers the latest transaction date processed (for each input source). https://hledger.org/hledger.html#date-skipping
Yes, purchases made with a credit card and paying off the credit card balance are all separate transactions, so the most standard way is record them as such - either manually, or by downloading/converting/importing the data from both accounts. And for extra assurance, assert that the credit card's balance is zero after payoff.
When downloading from both accounts, you get the payoff transaction in both downloads; one of them can be ignored by rule or manually, or both can be recorded with a dummy transfer account keeping things balanced.
If you don't care enough about the detailed credit card purchases, you'd just record the checking data.
One workaround is to split the expense posting into several expense postings, each with its own date (still keeping them within the one journal entry). A more strictly correct one is to add transactions and accounts like in evrimoztamur's answer. Most often I'll just use hledger's -MA flags (--monthly --average).
Can a rule expeess such calculated fields like "set virtual date at 3 month before transaction date"?
That's good for forecasting, but I don't see how to write automatic rules that ensure the accrued amount = billed amount.
hledger's CSV rules can't do this, no. You'd need to either do that manually, or write a custom conversion script (or a custom preprocessor that modifies the CSV before hledger sees it).
Similar answer, if you wanted to generate those verbose entries from a single CSV record, it would need some manual entry or a custom preprocessor script. hledger's CSV rules will only generate 0 or 1 transactions per CSV record.
What about the --average option ?