[GNC] Request for Automatic Reconciliation Function

[Jim DeLaHunt]

Bite Gao:

Thank you for your feature request. And thank you for your second 
message, where you make your request clear enough that I finally 
understand it.

What I think you are requesting is that GnuCash's Reconciliation command 
add an option for GnuCash to read in a data file supplied by the bank. 
This data file has the same information as the bank's human-readable 
statement, but in a machine-readable form. GnuCash reads a starting and 
ending statement balance from the data file. Then GnuCash attempts to 
match each transaction in the data file with a transaction in the data 
file.  It does the equivalent of marking the matching transactions in 
the GnuCash register as tentatively reconciled, and ends by displaying a 
list of GnuCash and data file transactions which it could not match.  
This list might be empty. Then the human modifies the tentative 
reconciliations, or accepts them, and finishes the reconciliation. The 
final state of the Register after reconciliation with the aid of a data 
file is the same as after reconciliation by the human using the 
human-readable statement.

To me, the matching which this requires is not very different from what 
the Import Matcher does. So, if the data file is a format which GnuCash 
can read, say an OFX file or a CSV file with the right configuration, 
then it seems feasible to use a data file to help reconciliation. And, 
this request does not seem to require reading the human-readable content 
of a PDF file.

Bite Gao: do you have banks which provide statements as machine-readable 
data files?  If so, what format does the bank provide?   Do the start 
and end dates of the data file match the start and end dates of the 
human-readable statement? Does the bank certify that the data file has 
the same transaction and balance content as the human-readable 
statement, and is just as trustworthy?

Among my statements from banks, credit cards, and investment companies, 
all provide human-readable statements in PDF format. Most provide 
transaction data in CSV format, and only some provide data in OFX or QFX 
or QIF format.  Most provide data files with the same start and end 
dates as the human-readable statement, but some offer only my choice of 
arbitrary start and end date. I could choose dates  for a transaction 
data file which match a statement's dates. But none of my statement 
providers certify that the data files have the same content as the 
human-readable statement. If there were a difference, I am pretty sure 
they would tell me that the data file is wrong and the human-readable 
file is correct. And reconciling to an incorrect data file is not helpful.

Thus, I can imagine that — for me, with my present statements — reading 
in a transaction data file to help with reconciliation would turn a 
10-minute task into a 5-minute task in most cases, but not in all cases.

Bite Gao, do I understand you correctly?  What machine-readable data 
files do your banks provide? Maybe your banks offer options which mine 
do not offer.

Best regards,
     —Jim DeLaHunt

On 2023-01-05 17:50, Bite Gao wrote:
> GnuCash Developers and Maintainers:
>   Hello! While you have mentioned the requirement of human intervene 
> in the reconciliation process, I do not see it contradicts with the 
> presence of automatically reconciliation system.
>   In a reconcile process, the accountant check the record in the 
> account book with the record in the bank statement (or statement from 
> other institution). He (or she) may found out that two record are 
> identical, or he (or she) may found that some record are not 
> identical. Only the latter requires human notice, since there its no 
> point wasting time on reconciled accounting transactions. An automatic 
> reconciliation system can load the digital statement from the 
> institution, compares the statement with the transaction in the 
> accounting book, and pinpoints the discrepancies out. Then human 
> accountant could step in and perform manual operations, such as 
> checking other vouchers, contact with banks, etc. In the situation of 
> single user, the automatic reconcile system have no reason to block 
> manual reconciliation.
>   Besides, when I means "human err", I means that the accountant 
> overlook an discrepancy and regards it as identical. People do not 
> spend too much time on identical records, since major of the 
> transaction would be in that state. However, it could cause severe 
> consequences if there do have a discrepancy.
>   Yours,
>
>  Bite, Gao
> Jan 6th, 2023
>
> On 2023/1/5 12:03, Liz Dodd Wrote:
>> On Wed, 4 Jan 2023 15:42:41 +0800
>> Bite Gao<redfrog2000 at outlook.com>  wrote:
>>
>>>     GnuCash Developers and Maintainers:
>>>        Hello! While your software has done many tedious jobs previously
>>>     done by
>>>     accountants manually, it cannot automatically reconcile its
>>> accounting data
>>>     to the bank statement in its digital form. In my opinion, the
>>>     automation of
>>>     reconciliation is not only efficient but also accurate since it
>>> reduces human-caused errors.
>>>        I would appreciate you a lot if you could add an
>>> auto-reconciliation function to your software.
>>>        Yours,
>>>       Bite Gao
>>>     Jan 4th, 2023
>> Bite, this is an interesting idea, but to me reconciliation requires
>> human input.
>> While I manually reconcile, I have to attend to pending transactions,
>> for example a payment made on a card which never is taken from the bank
>> account. At what time do I take that from the active list? Where will I
>> put the the never finished transactions?
>>
>> A number which is different in my list to the banks? How will I check
>> for the correct number? When do I contact the bank?
>>
>> They are human decisions, different in each jurisdiction.
>> They are the reason I reconcile - not to have my numbers the same as
>> the banks, but to see the discrepancies and decide on an action.
>>
>> Could you please describe more what you want from automated
>> reconciliation? Your statement about "human-caused errors" implies that
>> reconciliation introduces errors rather than highlights them.
>>
>>
>> Liz
>> _______________________________________________
>> gnucash-user mailing list
>> gnucash-user at gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>