[SOLVED] BoA credit card charges (debits) come over as payments (credits) to the account.

jimrh's Avatar

jimrh

01 Apr, 2020 10:19 AM

Greetings and I hope this finds you and your loved ones safe and well.

UPDATE:
See replies #2 and #3 for workarounds to this problem.

Issue:
I have a BoA crredit card account and I have imported this year's data into Moneydance. So far, everything looks totally OK, except for one teeny-tiny  issue:  ALL the transaction amounts have come across as payments  to the account, (credits), instead of charges  (debits) against the account - resulting in a massive positive balance.

What I would like to do is select (or search for), all transactions that should have been charge transactions and move the amount to the "charge" column instead of the "payment" column.

I would greatly prefer to do this automagically, rather than one-stinkin'-transaction-at-a-time. . . .

Is this possible?

  1. 1 Posted by jimrh on 01 Apr, 2020 11:11 AM

    jimrh's Avatar

    I found the source of the issue - for all the good it'll do me. . .

    In my other two credit card accounts, charges against the card, (purchases), are marked with a transaction type of "debit".  Payments to the account are given a transaction type of "credit".

    In the Bogus of America account, purchases are styled as "payment", and payments to the account are styled as "credit" - ergo, everything is a credit to the account and nothing is a charge against it. (i.e. There are no "debit" transactions at all.)

    So, aside from doing a global search-and-replace on the original QFX files - one for each and every month! - is there a way to move the transaction amounts within Moneydance without having to re-type everything.

    Both of these solutions would entail considerable rework.  Importing corrected QFX files will result in duplicate transactions galore and moving the amounts manually entails editing every single non-payment transaction - which is the lions share and is a non-trivial task.  Actually both fix-ups are non-trivial.

    I'd really rather not have to spend a week-or-so retyping and/or de-duplicating my entire current transaction list by hand.

  2. 2 Posted by jimrh on 01 Apr, 2020 11:52 AM

    jimrh's Avatar

    OK, another update:

    What I ultimately ended up doing:

    1. Went through each BoA QFX file, (using Notepad++, it preserves the EOL formatting of the file), and replaced every occurrence of <TRNTYPE>PAYMENT with <TRNTYPE>DEBIT.
    2. Went back to the beginning of this year's BoA records and deleted all the transactions.
    3. Re-imported everything.

    Result: All the transaction amounts are in the correct column.

    I'd mark this as "[SOLVED]", but I don't know if anyone else has a better solution - yet.

  3. 3 Posted by derekkent23 on 01 Apr, 2020 01:21 PM

    derekkent23's Avatar

    I am not support staff, just a user.
    Hi jimrh

    As you have found BOA are breaking the OFX specifications.

    Moneydance have added a fix that is available in later builds of 2019.
    From the Moneydance menu bar, go to File - Preferences.
    On the 'Network' tab, tick the checkbox to 'Ignore Transaction Types in Favor of Amount Signs'.

    Do a EXPORT BACKUP before you try this in case something goes wrong.

    Hope this helps.

  4. 4 Posted by jimrh on 03 Apr, 2020 08:58 AM

    jimrh's Avatar

    BoA is breaking more than the QFX specification, that's for darn sure - and I don't call them B&^%$#@t of America for no reason. . . .

    Reminds me of Russian drivers around Moscow - I think "Must be nice being God - you can do whatever you want and the rest of the world be damned!"

    Every stinkin' year, it's something else. . . .

    Wish someone there had a pen that could sign a reality check. But then again, that's wishful thinking.
    /rant

    I decided on the search-and-replace option so that all my QFX files were in a standard format, so I don't have to remember a "trick" if I need to import them again for some reason. Not that your idea won't work, but I'd rather all my QFX files have the same, or at least a similarly effective, internal structure.

    I also left myself a note for next year reminding me to check the format and "convert" if necessary.

    Thanks!

  5. 5 Posted by jimrh on 03 Apr, 2020 09:05 AM

    jimrh's Avatar

    Marked as [SOLVED] based on replies #2 and #3.

  6. 6 Posted by jimrh on 03 Apr, 2020 01:27 PM

    jimrh's Avatar

    Guess what!

    BOA did NOT break the OFX standard - Moneydance isn't handling the <TRNTYPE> transaction type field correctly!

    Viz.: https://www.ofx.net/downloads/OFX%202.2.pdf
    (Note that the current version is 2.2.1, but the 2.2 specification was not changed.)

    The problem is that Moneydance is using the <TRNTYPE> to determine if the transaction is a debit or credit and not the sign of the <TRNAMT> as specified in the OFX 2.2 specification referenced above.

    In a nutshell, the <TRNTYPE> is used by the financial institution to categorize the transaction. (i.e. Is it a capital gain/loss or a rebase of the securities?) The sign, (positive or negative) of the <TRNAMT> is used to classify the transaction as a credit or debit. (i.e. a POS, (Point of Sale), transaction can be either a purchase or a refund depending on the sign of the amount.)

    ====================

    On page 230 of the PDF file, (Section: 11.4.4.3 Transaction Types Used in <TRNTYPE>), PAYMENT is defined as an "Electronic Transfer", whereas "DEBIT" and "CREDIT" are defined as "generic debit" and "generic credit"

    Elsewhere in the document, (page 225 of the PDF, sectiion 11.4.4.1 <STMTTRN>), states that <TRNTYPE> defines the type of the transaction, where "type" can have several identifying values. The actual fixed usage is not rigidly defined as a debit or credit. It also states that <TRNTYPE> is defined as:

    Transaction type, see section 11.4.4.3 for possible values. This element does not change the effect of the transaction upon the balance (increases and decreases are indicated by the sign of the <TRNAMT>).

    In other words, <PAYMENT> is a perfectly legal tag as used, however the tag alone should not determine if the transaction is a debit or credit, but "...the sign of the <TRNAMT>"

    So, apparently, the option to ignore the tag in favor of the sign in <TRNAMT> is actually the correct behavior according to the specification as defined above, and should be the default behavior.

  7. 7 Posted by dwg on 03 Apr, 2020 08:36 PM

    dwg's Avatar

    I'm a fellow user.

    And that is the sort of way some developers seem to be interpreting things.

    However I think it is invalid to call a transaction a Debit or Credit then use a sign to make it into the opposite type of transaction, Debit or credit in itself determines the sign of a transaction. The specification talks about using a sign with transactions that could be either type e.g. interest.

  8. 8 Posted by jimrh on 03 Apr, 2020 09:33 PM

    jimrh's Avatar

    Dwg, I agree with you, but that's not what the specification says.

    According to the spec, TRNTYPE is simply a "convenience" label for the financial institution that they can do with as they please - whereas TRNAMT actually determines both the magnitude and direction of cash flow.

    Viz.:

    [The] transaction type [...] does not change the effect of the transaction upon the balance [whereas] increases and decreases are indicated by the sign of the <TRNAMT>.

    Currently accepted convention is that a "debit" moves money away from you and a "credit" moves money toward you, but what about a "payment"?

    According to the OFX spec, a "payment" is "an electronic funds transfer" of some arbitrary type or kind. It can be a "payment" TO you, or a "payment" FROM you to someone else. The direction of cash flow is determined by the sign of the TRNAMT.

    Interest is the same. In a bank account "interest" is a credit to your account, whereas with a loan account of some kind, "interest" is a debit to the account.

    Even the definitions of "credit" and "debit" are not guaranteed to be the same everywhere.

    Because the spec is designed to be very institution, country and region agnostic, the TRNTYPE is a label and nothing more.

    The definition of the labels "credit", "debit", "payment", "interest", (etc.), is left up to the particular financial institution and, based on the sign of the TRNAMT, the cash can move one way or the other, regardless of label.

  9. System closed this discussion on 03 Jul, 2020 09:40 PM.

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