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
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
