Automatic Reconcilliation using MT940 or OFX

[David Carlson]

On 12/2/2013 9:27 AM, Derek Atkins wrote:
> Hi,
>
> Egbert van der Wal <ewal at pointpro.nl> writes:
>
>> So I still have to do the manual reconcilliation even if there is a
>> complete match with the imported OFX file?
> Yes, because reconciliation is about making sure that your accounts
> match the bank accounts at well defined boundaries.  This is done by
> going through your bank statement and "reconciling" your accounts to the
> bank's view of your accounts.  All that an import proves is that your
> transaction has cleared the bank, which is why it gets marked as C.
>
> This is by all design.
>
>> And then still the issue remains that only half of the items are
>> actually cleared, even though all of them have been matched (and are
>> green) in the import matcher. The rest remain marked as 'N' even
>> though I did select 'R' in the import matcher. Am I running into a bug
>> here?
> Sorry, I don't have an answer for this.  It may be a bug or it may be
> user input error.  Sorry I cannot you with help that.
>
>> Thanks for your reply,
>>
>> Egbert van der Wal
> -derek
>
>> On 02/12/13 16:17, Derek Atkins wrote:
>>> Hi,
>>>
>>> Egbert van der Wal <ewal at pointpro.nl> writes:
>>>
>>> [snip]
>>>> Then, additionally, when I select 'R' (or 'U + R', doesn't make a
>>>> difference) and click 'Ok', it doesn't really work. About half of the
>>>> transactions are marked as 'C' in the 'R' column in the register. The
>>>> rest is marked 'N', and thus, nothing is marked 'Y'. This means that I
>>>> can use this function to import the transactions, but not to reconcile
>>>> them (even though the reconcilliation matcher suggests that it will do
>>>> this). I'm also puzzled as to why only half of the transactions are
>>>> actually marked 'C' and the rest 'N'. The console or GnuCash doesn't
>>>> report any errors whatsoever.
>>>>
>>>> I'm using GnuCash 2.4.13, by the way.
>>>>
>>>> Any ideas on these issues?
>>> This is how it is supposed to work.  The only way to mark items "y" it
>>> to go through the Reconcile process.  The importer will only clear your
>>> items.
>>>
>>>> Regards,
>>>>
>>>> Egbert
>>>> Please remember to CC this list on all your replies.
>>>> You can do this by using Reply-To-List or Reply-All.
>>> -derek
>>>
>>
>>

Are you sure that the transaction import assistant actually matched
every incoming transaction correctly to it's respective existing
transaction when there was one?  I have found that when there are
somewhat similar looking transactions (the amounts may even differ by a
small amount) the import assistant mistakenly matches to the wrong one.
I double click every incoming transaction to check which existing one is
matched, and too often I need to change the choice that the import
assistant made.  For the transaction mix that I typically see, it errs
this way about 3 to 5 % of the time.  I can imagine that in some cases
the error rate would be much higher. 
Then, once a match error is made, the incoming transaction will not
appear in a subsequent import because it was already matched to
something.   The easiest work-around is to click the 'R' box to change
the status to 'c' instead of 'n'. 

The other result of a mismatch is that some transaction does not get
imported.  This is harder to fix.  There are two ways to do it, but
neither of them is user friendly.
One way that I have been told works (but I have not tried it) is to
deliberately import into a different account then manually correct the
account after that import.  The other is to edit the OFX file to change
the transaction number of the missing transaction(s).  To do that you
must figure out the numbering scheme that the financial institution uses
so that you can generate a number that was not used before and will not
be used in the future.  Not worth the trouble unless you really want to
get the actual text from the import file.

The bottom line in my opinion is to follow up with a real manual
reconciliation when the statement arrives to catch errors from this
process as well as errors from any other source.

David C