Business Events Ledger
Back in 2018 I noticed something that I referred to as a fact ledger, see Introducing the Fact Ledger. I described a fact ledger thus: "A fact ledger is a new type of ledger that offers utility and leverage when accounting, reporting, auditing, and analysis is done in a digital environment.
My thinking on this has evolved and now I see what I would call a business events ledger. And I am not the only one that sees this. Kurt Cagle has the notion of what he refers to as an event graph or event ledger (see Coherence, Holons, and the Spinning of Plates). Another accountant seems to have a similar idea and created an "events ledger". I don't have permission to show this to you at the present time.
And so fundamentally, my original notion of a "fact ledger" is an "event graph" or "event ledger" in terms of a holon as described by Kurt Cagle, see my Example Financial Statement Holon. Applying this specifically to financial statements; a business events ledger or the event graph is the detailed financial transactions which have been appended with business event information so you can get traceability functionality working correctly. Basically, you simply cannot "drill down" into transaction information if there is no way to parse transactions within an account into the financial statement line item groupings which is business event information. Likewise, you cannot "aggregate" financial transactions into financial statement line items (i.e. automatically generate a complete financial statement) unless you have that business event information.
Remember, a financial statement is a formal semantic structure. A published general purpose financial statement provides a standard set of line items that are specified by a published financial reporting framework like US GAAP or IFRS or other reporting framework. A company's chart of accounts is "mapped" to those standard line items and standard superordinate subtotals and totals for the balance sheet and income statement. Standard line items are also used in the cash flow statement and statement of changes in equity but that information, which is basically business event information, is not in any accounting system. It is those standard line items and standard business event information which enables comparability across financial statements with consistency. (This will help you understand trace and track. That is part of provenance.)
Most accountants don't think in terms of business events; rather they think in terms of financial transactions. But financial transactions spawn from business events. Business events cause financial transactions to be created. Every financial transaction is the result of a business event. But it is not the case that every business event results in a financial transaction.
Business events are described by REA (Resources, Events, Agents), The Theory of Accounting and Control which refers to them as business contracts, ACTUS which focuses on business events related to financial institutions and are financial contracts, The Future of Accounting which describes business events as part of what they call data centric accounting (DCA).
Why would you need a business events ledger?
Before I answer that, let me point out that because without information about the type of business event a financial transaction relates to; it is simply impossible to autogenerate a proper complete set of financial statements (i.e. balance sheet, income statement, cash flow statement, statement of changes in equity) from every accounting system that I have ever run across. All accounting systems generate balance sheets and income statements; some generate half-baked cash flow statements that do not comply with US GAAP or IFRS). This is a consequence of "starting at the end of the chain"; effectively, information needs to be appended to financial transactions later in the process because it was not added earlier.
Workday addresses this. Workday has the notion of the "worktag". This PDF says worktags are used to classify transactions. This article, The Wonders of Worktags in Workday, describes worktags as "identifiers used to describe and group transactions in Workday". Workday's worktags sound like a good idea, but I would point out that (a) this is an informal system and (b) worktags could be used for many different things and the same time which can confuse groupings of transactions.
An example of a more formal system is a chart of accounts. Accounts are formally defined and every entry for every transaction MUST be associated with an account from the defined chart of accounts. This gives you the balance sheet and income statement line items.
But what provides the cash flow statement line items, the statement of changes in equity line items, and the ability to group financial transactions WITHIN an account in order to separate one group from some other group of financial transactions? Because there is nothing, that is why cash flow statements and statements of changes in equity cannot be generated from accounting systems.
So how are cash flow statements and statements of changes in equity created then? Well, by retroactively adding information to the financial transactions to get them properly grouped, usually in Excel. This is part of the transaction chasing accountants do. Alternatively, sometimes line items are plugged. That sort of plugging can be very dangerous as it can mask issues.
Here is a set of financial transactions where a business event code has been added to every transaction. This is part of my Record to Report example where I show that by adding the business event code and the standard line item code (or map the standard line item code to the account code) you CAN autogenerate a complete set of financial statements.
As others have pointed out, the information in most business systems is pretty much a mess when it comes to trying to get artificial intelligence to make use of that information. Something like an LLM can only take you so far. The messy data needs to be fixed to get maximum benefits.
The business events ledger seems to be part of this fix. Why? Again I point out, most systems did not start at the beginning. Business event information needs to, therefore, be "retrofitted" to financial transactions. Or saying this another way, the business events ledger seems to be the correct starting point, all other systems are subordinate to that system. This could help fix the "integration hairball problem".
More to come; so stay tuned.
Additional Information:
Comments
Post a Comment