Puzzled by by balance changes in investment account
I started from scratch by importing via .qif from another application. My main investment account is about 12 years old and has a couple of dozen positions, long only. The value of the account is way off. I see two things:
(1) In the portfolio view, the positions all look good except all the shares (i.e., sizes of positions) are negative, as is are the current values.
(2) In the Register, some transactions puzzle me as to their signs or their effect on the Balance. Many look fine and I'm not mentioning those here. Puzzlers:
--action XFR, "check#" DEP, negative amount (huh?); in the .qif the amount is positive and the type is DEP. EDIT: this transaction decreases the balance.
--bought a stock; the amount is negative (OK), but the balance increases (huh?).
--sold a stock; amount is positive and the balance increases (all OK, but both buys and sells increase the balance?).
--foreign tax paid; action XFR, "check#" WITHD, amount positive (huh?), balance increases. EDIT: in the .qif the amount is negative.
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by dwg on 29 Mar, 2023 12:11 AM
I would suggest you post screen shots so the people here can see what is happening,
That being said migrating Investment accounts will require work.
2 Posted by brec on 29 Mar, 2023 02:19 AM
Wouldn't feel comfortable posting screen shots of my investment transactions. Anyway, a picture wouldn't add any detail to the examples I provided.
No screen shot required for this: tax paid and securities buys increase the account balance, so that it ends up preposterously inflated -- millions of dollars!
Edit: Also, no screen shot would add to the fact of the Portfolio View having all share amounts, and hence current position values, as negative.
3 Posted by brec on 29 Mar, 2023 06:26 PM
I understand that. I've been working on this migration for 4 solid days so far. But I am not willing to put in the work of manually entering or changing hundreds of transactions, because that's an activity that I hate. I am willing to put in a roughly equivalent amount of time fixing the jagged .qif export->import interface between two excellent programs, SEE Finance and MD, if I can do that by writing code or finding a procedure* that will work to get the data imported. But it appears to me I won't be able to do that without some technical support at a level which may not be available.
*An example of a procedure I'm wondering about it is creating a "stub" book containing only my set of accounts, categories, and securities, with no transactions. Then importing transactions one account at a time to see what needs fixing and how other accounts are affected (by inter-account transfers). Maybe doing this import from an account's slice of SEE Finance's .qif export, or maybe creating my own account transaction .qif from SEE's CSV export.
For example, in my OP:
This transaction (incorrectly) decreases the balance, i.e., it adds a negative amount to the previous balance. But how did the amount become negative? Since posting I've formed the hypothesis that the "check#" field (scare quotes because it can contain various user-created transaction codes) is not used in the accounting logic. So MD has only "xfr" to go on, and guesses that a "xfr" with no other accounting info is a withdrawal, so it negates the imported amount.
This hypothosis also explains the last example in my OP:
I neglected to mention that in the .qif the amount here is negative (will edit above). I think MD is "thinking" -- OK, it's a XFR with no other info, so a withdrawal; let's negate the imported amount and add that to the previous balance.
Conclusion: For investment account cash transactions I have to alter the .qif so that it uses another Action code instead of XFR, or I have to invert the sign of the amount in the original .qif. This is an example of an issue that occurs in hundreds of transactions.
System closed this discussion on 28 Jun, 2023 06:30 PM.