Really, really bad auto-matching -- Is Account unknown Bank unknown the culprit?

[Jeff Kletsky]

David Reiser wrote:
> On Mar 5, 2010, at 9:55 PM, Jeff Kletsky wrote:
>
>   
>> Somehow GNUCash is thinking that Caribou Coffee Denver is a good match for Safeway becuase
>> * The dollar value is similar
>> * And, what were they thinking???
>>     
>
> I don't believe the Description is used in the match at all. Caribou Coffee Denver might be showing up on a credit card statement as "UBERCOFFEE #3456 CCDENV".  So trying to match on Description is too risky in general. Most checking accounts don't report anything useful in that field either, so the default is for the matcher to accept what you entered in the register as the authoritative Description. If you are importing new transactions, the matcher puts whatever the bank/credit card company uses for the merchant name. All of my checks have a payee of "Share Draft" on my statements/ofx files, so matching that wouldn't ever be useful.
>
> IIRC, the match is primarily date and amount. For checks, I think the check number is also considered.
>   

Thanks for your insights on this!

I was (incorrectly) thinking that the user-supplied description was 
tokenized and matched against corresponding OFX data, or the like. I 
agree that the text supplied by the bank, even for credit transactions 
where it identifies the merchant account, aren't the most obvious.

In this case, "CARIBOU COFFEE DENVE" for $15.34 was matched to (also 
automatically generated) "SAFEWAY STORE00006676 SAN F" for $15.14 which 
seemed a big stretch.


(Yeah, I know, "That would be a good enhancement for someone to work on" 
-- let me get to budgets first, ok?)

>> I suspect that the problem with the bizarre matching that I have been getting is the
>>
>> "Account unknown Bank unknown"
>>
>> that gets stuffed into all of the transactions coming in through OFX.
>>
>> How can I kill this useless bit of information?
>>     
>
> That's being inserted by aqbanking, not libofx. It doesn't affect the match either - it gets inserted in the memo field of a split. I think the only way to turn that off is to edit the aqbanking source.
>
>   
>> Any other hints at improving the auto-match? It has gotten to the point where I don't trust it at all...
>>     
>
>  If you have more than one similar-amount (within the default bank fee amount) transaction within a day or two, the matcher frequently screws at least one of them up. The most aggravating thing is that you could be marking two potential matches as "R" in the matcher window, but if the code thinks they're pointed at the same existing transaction, the matcher marks one as cleared and dumps the other with no message instead of matching one and creating a new transaction for the other. Or at least mentioning that it's ignoring a transaction.
>   

I've had similar problems where we've had two ATM withdrawals on the 
same day. Only one ever shows up as the second matches to the first as 
well. This is another case that the matcher code could use some help in 
the future.

> The biggest chance for error comes when you have some transactions already in the register to match, but some additional ones to import as new transactions. You'll have fewer mismatches/errors if you either just import all the transactions as new, or have almost all the transactions entered ahead of time and use the import to clear the transaction

Alas, that is every time for us. Most of the transactions are entered, 
but some aren't.

I've done the unthinkable and removed all the import-maps from my XML 
file, so everything shows up fresh again.

More importantly, I suspect, I've also set the ATM threshold to $0.00. 
I'm hoping that helps until I can figure out just how gnc-ofx-import is 
working.

I'm ok with reconciling against paper records, so this isn't a 
show-stopper for me.

Thanks again!