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).  A business event is a formal record.

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".

Ultimately, moving to a business event based system transforms accounting from a reactive, compliance-driven back-office function into a proactive, strategic engine for business intelligence.

More to come; so stay tuned.


In REA, the “frozen raindrop approach” means: capture each individual business event exactly as it happens, with full contextual detail, before aggregating or summarizing anything. 

To “freeze each raindrop” is to record every atomic economic event as its own object, with its own resources, agents, commitments, policies, and dualities; not a journal entry, not a batch, not a ledger posting.

This metaphor is one of Bill McCarthy’s most important ideas. It comes from his broader REA philosophy: accounting should model reality, not the artifacts of legacy bookkeeping. The accounting and bookkeeping entries and other artifacts are then derived from the business event information. (for more information see here)

Willi Brammertz, who is behind ACTUS see this similarly for the financial contracts of financial institutions.

* * *

The REA (Resources, Events, Agents) framework serves as the structural bridge between operations and accounting not by replacing traditional double-entry bookkeeping, but by capturing financial information at its earliest operational source. Conceived by William McCarthy in 1982, REA builds a single, shared data model that unites physical enterprise workflows with the financial controls necessary for accounting.

Traditional systems often isolate these functions: operations tracks physical movements in one database, while finance translates those movements into debits, credits, and journals in a separate general ledger. This separation can strip away the rich operational context; the who, what, and why; needed for deep analysis, forcing organizations to reconcile two separate sets of books.

REA solves this by structuring the foundational data layer around three core business elements:
  • Resources: Economic goods or services that have value to the enterprise (e.g., inventory, cash, labor).
  • Events: Operational activities that change the value of economic resources (e.g., shipments, production steps, cash receipts).
  • Agents: The individuals or organizations participating in those events (e.g., customers, vendors, employees).
By recording transactions at this fundamental event level, REA preserves all the granular details required to run daily operations. Crucially, it does not reject double-entry bookkeeping; rather, it subsumes it. Traditional accounting concepts like debits, credits, and journals are maintained as essential audit tools, but instead of being hardcoded into isolated data silos, they are treated as dynamic, authoritative views generated directly from the underlying REA data.

Furthermore, double-entry's core principle of duality is mirrored structurally by linking economic inflows and outflows (for example, pairing a "Shipment" event with a "Cash Receipt" event). This architectural integration ensures that a single operational transaction simultaneously populates a robust audit trail, satisfies the demands of double-entry accounting, and maintains full epistemic traceability from financial statements back to the warehouse floor.

This approach enables full traceability/trackability and provenance.  This approach enables the automatic generation of a complete set of primary financial statements (e.g. balance sheet, income statement, cash flow statement, statement of changes in equity) including quantitative disclosures such as aggregations, disaggregations, and movement analysis.

This approach enables new dimensions in reporting.  Think of the business event ledger which is connected to the accounting ledgers as in terms of a manifold. A manifold is a mathematical structure.  Imagine this business events ledger and accounting ledgers as a big landscape. Every business event and  related financial transaction is a dot on the map of that landscape. The journal is a notebook listing all the dots you visited. The ledger is a map showing only certain regions (accounts). The trial balance is a summary of how many dots ended up in each region. The landscape is the manifold. The notebook, map, and summary are views (e.g. projections) of it, not copies.

This approach enables maximal benefit from artificial intelligence and is always audit ready. This is quite similar to what many refer to as a "digital twin" of an enterprise.  I would not necessarily refer to it  as a digital twin, rather more as one copy of all the important information about business events and the financial transactions they generate of an enterprise free from semantic and other forms of fragmentation which enables defensible compliance.

One version of the truth exists because the gap has been bridged. Everything is reliably machine readable because everything is "graph first" and digital.  Everything is reliably machine interpretable. All human readable documents are projections of the digital graph.  Work systems are industrial strength representations which fail loudly; not spreadsheets which mask errors.

Additional Information:

Comments

Post a Comment

Popular posts from this blog

Internationalized Resource Identifier (IRI)

Image
An Internationalized Resource Identifier (IRI) is a standard proposed by the IETF ( RFC 3987 ).  An IRI is a unique sequence of characters that identifies a resource.   IRIs are a generalization of URIs ( RFC3986 ) that permits a wider range of Unicode characters. A  Uniform Resource Identifier (URI) is a unique sequence of characters that identifies an abstract or physical resource.  The difference between an IRI and a URI is that IRIs use the more modern  Universal Character Set (a.k.a. UNICODE)  and URIs use the older ASCII character set. The newer IRI format is compatible with the older URI format. The most  current version of RDF  uses IRIs to identify resources. Don't confuse IRIs with URLs and URNs.  A URL is a web address. A URN is a Uniform Resource Name. This Venn diagram shows the relationship between these different tools: Why are IRIs and URIs important?  If you are thinking in terms of a single database, a silo ...
Read more

Digital Proficiency

Image
A paradigm shift is occurring.  The territory is changing.  A new map is necessary. Trying to use your old map to understand the new territory will be unsatisfying. This shift is caused by the difference between how "realspace" (the real world, analog) and "cyberspace" (the internet, digital) operate. While many things will stay the same; it is also the case that entirely new business models and products are possible. Probably the biggest mistake one can make is misunderstanding the notion of intelligence and grouping "human intelligence" and "machine intelligence" together. I would contend that it is a fool's errand to try and compare machine-intelligence to human-intelligence.  They are not even in the same ballpark and they won't be for a long time, if ever.  The notion of "superintelligence" in computers is a fantasy. Computers are nowhere close to achieving superintelligence which I would consider as being human-level inte...
Read more

Example Financial Statement Holon

Image
As I have mentioned in other posts on my blog, a financial statement is a formal semantic structure , in fact a financial statement is a special type of formal semantic structure referred to as a holon . As I mentioned in my blog posts, Kurt Cagle and Chloe Shannon are providing a lot of very good information about holons on their substack. ( Here is Kurt Cagle's and Chloe Shannon's answers to my questions. Here is an example Kurt Cagle created of a financial statement as a DataBook.) I have provided a bunch of good examples of financial reporting frameworks and reports   In this blog post I want to focus on one specific financial statement and see if I can explain that a financial statement is a "container" of  blocks of information and the "information blocks" that the financial statement contains. Cagle and Shannon point out that a holon is made up of four distinct knowledge graphs that maximize coherence and operationalize the holon which are: The Sc...
Read more