[GNC-dev] reconciliation concept from top view

[Dale Phurrough]

This email captures my thoughts on "reconcilation" concept from a top view.
I encourage feedback.:-)
Grab a drink -- this email will walk you through terms, logic, and examples.

I believe there is value in GnuCash having a language/terms at a high-level
for reconciliation. To me, it seems a lot of the reconciliation discussions
are "lets make a field/function that matches what my bank/accountant/I do"
or "I do it this way and they do it that way". This reactive implementation
approach might lead to more gaps. Perhaps furthering GnuCash
"reconciliation" that already has different processes/effects in its
current codebase.

"Truth can be stated in a thousand different ways, yet each one can be
true." -- Swami Vivekananda. I've attached a picture (also at
https://i.redd.it/4ozwde4hk8mz.jpg) to visually represent the difference
between multiple true(s) and a single shared truth. Consider this picture
as we walk through the definitions below.

*Definitions===================================*
Facts:
thing that is known or proved to be true; it exists in reality

True:
a fact in time; something that is correct for one moment, e.g. today the
bank deposited $4.00

Truth:
state/quality of being true to someone(s) in the current situation; it is
possible for a truth to be a mistake. Example of a truth: The bank and I
agree the $4.00 deposit is correct and it happened today.

Comparative example:
When one says that the sun will always rise from the east and set in the
west, one is telling a true fact. However, when one says "I am in Los
Angeles", then that is a truth, at least for that exact moment. Several
hours from that time one may have traveled somewhere else, making one's
previous statement false. Thus, a truth is something that is not universal,
it is more subjective, and depends on the current situation. That’s why the
truth’s existence is said to be more temporary than that of facts.

Accounting example:
On 1 April 2020 the bank and I believe it is the truth that my bank account
contains $1000. Two days later, I discovered that an additional deposit of
$500 should have been posted to my account. The bank found their error,
reissued a statement, and I updated my ledger. Now the bank and I agree
the truth is my bank account contained $1500 on 1 April 2020.

*Reconciliation =======================*
Reconciliation is comparing one set of records (i.e. facts) against another
*external* set of facts to establish a shared truth. It is also an
accounting control that gives assurance of the basic accuracy and
completeness of the accounting records by comparing them with *external*
facts/evidence.

I believe that in the context of GnuCash, that...
Reconciliation is the process where 2+ parties use each their own true
facts to derive a shared truth.

   - Needs true facts as input. Therefore, these things can not be in the
   future...because things in the future are not known, and things in the
   future are not true.
   - It creates/derives a shared truth as output. Shared truths are created
   by 2+ parties where 1+ parties are *external*.
   - These *external* parties and their true facts provide the independence
   necessary to create a shared truth. Otherwise, the truth isn't shared and
   is instead a single-party's isolated/myopic set of facts. Single-party
   easily leads to errors, isolated bubbles, embezzlement, tax evasion, etc.
   If it is single-party, it isn't "reconciliation". It is instead something
   else like "future predicted math".
   - If the true facts from all parties conflict, then no shared truth can
   be created. The account(s) can't be reconciled.
   - If the true facts from all parties are compatible, then a shared truth
   is created. The account(s) are reconciled.

Reconciliation is a process that transforms true facts into a shared truth.
Reconciliation also changes state on those true facts from un-reconciled ->
reconciled.
Pseudo-code:
boolean reconciliation(vector<vector<fact>> allFacts) {
  // validate facts to be independently true, e.g. checking date
  foreach{ foreach{
    if (fact.date() > now()) return false
  }}

  // validate all facts equal
  if (not deep_broad_equal(allFacts)) return false

  // mark reconciled, digitally sign to prevent tampering, store shared
truth
  start_transaction()
    mark_reconciled(allFacts)
    sharedTruth = SharedTruth(digsign(allFacts, now(), ...))
    store_truth(sharedTruth)
  end_transaction()
  return true
}

*Scenarios==============================*
I want to walk through the scenario Derek described using the definitions
and process I wrote above. His is not a simple scenario so it exercises
more of the nuances of reconciliation. I think healthy discussion will come
from this. Derek...no insult/harm is intended. :-)

Derek's use of the current GnuCash reconciliation system isn't based on
true facts or a shared truth. Therefore, it is not reconciliation. There
are no *external* facts to which he can reconcile his account because Derek
only uses his data entry and his GnuCash. And, there are no *true* facts
because his things are in the future. True facts only exist in the now and
past.

Perhaps Derek's bank mis-deposits or holds some or all of the funds causing
delays beyond those Derek predicted. This causes Derek's
attempted reconciliation to be false -- he will need to un-reconcile,
dates/amounts corrected, and then re-reconcile. Problems also surface with
this false deposit entries, reconciliation, and the GnuCash balance. For
example, Derek believes he has enough money in this balance to pay his
electricity bill. The electricity provider automatically withdraws from his
account. However, there is not enough money because the bank delayed the
deposit. This failed withdraw causes the bank to charge a fee for an
overdrawn account. And the electricity providers charges a fee for a failed
payment. His false deposit entries and false reconciliation cascaded to
real-world problems.

Or, perhaps the error is in Derek's data entry. Perhaps he reads a single
meal receipt wrong. Or mistypes the amount into GnuCash. Or adds the same
expense twice, or misses a receipt because it is stuck on the back of
another receipt. It is likely some later *external* *true* facts from a
credit card company, bank, or his employer will conflict with Derek's false
facts. And this will cause a cascade of un-reconciles, data corrections,
and re-reconciles to correct Derek's facts and reconciliation state.

To be successful in reconciliation, Derek must wait on the bank's statement
so that there is an *external* source of *true* facts to compare against
his own *true* facts (therefore now or in the past) stored in GnuCash.

This doesn't mean that Derek can't use the Gnucash database fields in they
way he is using them today. However, such usage is not in alignment with
the process of reconciliation (2+ parties, 1+ external, facts now or in
past). Instead, Derek's usage is based on only one set of facts (Derek's
false facts in the future). Since a single set of facts can be false or
true in the local context (see the picture I attached), then this
isolated/myopic truth is easily a mistake. This single-party approach is
how false facts and false truths are kept in an isolated bubble,
embezzlement, tax evasion, etc.

I don't think GnuCash should explicitly support scenarios like Derek's.
Because his scenario isn't reconciling. That scenario is instead doing math
and predicting a future based on false facts. This scenario seems to me a
better fit for other processes like budgeting or A/R forecasting.

I believe better to focus reconciliation as a process where 2+ parties use
each their own true facts to derive a shared truth.

Discussion, ideas, perspectives?

--Dale
-------------- next part --------------
A non-text attachment was scrubbed...
Name: truth-true.jpg
Type: image/jpeg
Size: 47444 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20200415/d01b507b/attachment-0001.jpg>