I didn’t set out to rewrite the rules of accounting. It just sort of happened. It is a tale of emergence and synchronicity. So far, everyone we’ve reviewed our tentative findings with is enthused and eager for us to finish our experiments and publish. This blog is the first sneak preview of what we believe to be the future of accounting information systems.
Emergence
Emergent properties are features of a system that do not inhere in its parts: “The whole is greater than the sum of its parts.” Heart cells, by themselves, do not have the capacity to pump blood, but the heart, which is an organized collection of them, does.
Any complex system that was designed has some emergent properties, but mostly they were designed and therefore anticipated. Some of the most enjoyable emergent properties are those that spring up along with the design, but not necessarily part of the original intent.
Most of what we have discovered in Data-Centric Accounting was emergent in this later sense. We did not set out to change accounting systems. Many people have and, looking at some leading-edge accounting approaches, we see overlap and parallel development of some of the key ideas. But we are pretty convinced that the sum total of what we are describing would not have come about by incrementally improving on accounting systems as they are now.
Synchronicity
I was blessed by a bit of synchronicity as well. Cheryl Dunn had heard about our work in ontologies and was interested in learning more and applying it to her work. She took some of our introductory training and was arranging for a sabbatical from her position to study with us more deeply. In the interim, we were growing the footprint of the domain ontologies we’ve worked with. Curiously, up to this year we hadn’t implemented any accounting systems in a Knowledge Graph. Unsurprisingly, most clients have lower hanging fruit to pursue for their early endeavors into the Data-Centric approach. And most think their accounting systems are a solved problem. (Their accounting systems are a solved problem, but as we will see, at an amazing and unnecessary cost.)
Our Moving Target
We were beginning to prepare an offering for the mid-market (most of our work to date has been with relatively large firms). With large firms our “think big / start small” methodology seems to balance the needs of progress while maintaining stability. For the mid-market, we feel that we will need to offer a more complete solution, if not right out of the box, at least in a reasonably short period of time.
We decided to “eat our own dog food.” We have been running a chunk of our company (Time Reporting, Project Management, Staff Planning, and Gross Payroll calculation) in a model driven environment running on a triple store (a.k.a., an Enterprise Knowledge Graph). However, we have known for some time that the particular architecture we implemented was not up to the tasks we had envisioned for ourselves and ultimately our clients.
The planning for this next phase of our business involved two activities:
- Rethinking and rebuilding an architecture suitable to cover all the information needs of a mid-sized firm, and doing so in a 95+% model driven execution
- Building out an enterprise ontology that would cover all the information needs of a medium sized firm.
The Professional Services Enterprise Ontology
Our initial focus is on professional services firms, as that is what we are. As we looked at our own information landscape, it was as embarrassing (proportionately) as our clients. We are a firm of 25 employees with 20 multiuser applications that we use every day. We inventoried all the data and all the use cases and began the task of building a road map: which areas do we tackle first?
There was no getting around the elephant in the room: QuickBooks. We use QuickBooks. This isn’t an endorsement, and as with so many other things, it is an accident of historical events. And to make matters worse, we don’t just use QuickBooks, we have three, nonintegrated QuickBooks databases for our foreign subsidiaries (we have employees in Canada and the UK and run payroll in local currencies and of course have to account for all this).
Cheryl and Resource Event Agent (REA)
Did I mention that Cheryl is a Professor of Accounting at Grand Valley State University in Michigan? She was not just a Professor of Accounting, but a specialist in a semantic based approach to accounting called Resource Event Agent (REA) accounting. She is the author (along with Gregory Gerard) of REA Accounting Systems and Analytics. REA shares a number of insights that we have independently derived. REA has been primarily an academic initiative, with limited commercial adoption. We intend to change this by starting with enterprise adoption and working back to the academic market.
She got permission for her sabbatical just as we were tackling the accounting aspect of our model. One thing led to another, and we decided to capture the thought process in a book, with the working title Data-Centric Accounting, which we expect to complete by the end of this year and have arranged for publishing next year. Perfect synchronicity.
No Fear
Taking on the accounting systems industry should strike fear in one’s heart. These firms are gigantic. Intuit (owner of QuickBooks) itself is no lightweight, but upmarket from there you have Microsoft Dynamics, Oracle Financials and SAP. Venture firms are constantly funding the next big thing in FinTech or Accounting.
I’m not an accountant by training. I have implemented many accounting systems for large firms over the years. Some based on packages, many custom designed and built. Two in particular had very complex accounting challenges to solve, such as buying and selling physical goods all over the globe and having to deal with changes in price and currency exchange rates even as the goods were in route. So, I know how they work. I know that they need not be as complex as they are.
I use QuickBooks every day. I’ve been deep into their data model. I know, from on-line sources, that the Quick Books version I run my business with contains 10 million lines of code.
Our replacement system will be mostly model driven, and therefore “no code.” We expect to write several pages of bespoke code for our payroll system, and a few algorithmic functions, but that’s about it.
The Key Differences in Data-Centric Accounting
There are a vast number of specific differences, but to boil it down, the key ones are:
- All accounting transactions a byproduct of a business event
- Debits and Credits mostly hidden
- Real accounts rather than ledgers
- True flow accounts for the Income Statement
- Facets rather than complex coding blocks
All Accounting Transactions a Byproduct of a Business Event
Even in traditional accounting systems, most of the activity is a reflection of events that have occurred in the business. Sometimes these events are captured in source systems which then, through the miracle of systems integration, make their way to the accounting systems. Other times, literal pieces of paper are forwarded to bookkeepers who enter them into the accounting systems. In either case “accounting policy,” which is a combination of written practice and acquired norms, determine just what account a given transaction should be posted to, and how to handle such things as accruals.
It turns out that if your scope is the data-centric enterprise, you will have already captured all the events that are going to give rise to accounting transactions. There are many, many events that are captured in the data-centric enterprise, including such things as making an appointment with a prospect, writing a blog article, responding to an email, or moving your desk to a new office. Most events do not have an impact on the financial records of the firm, but some do. The first trick is being able to identify those that do and capture them at their source. Hint: depending on the industry you are in there are 10 -20 types of events that need to be recognized in this way.
The second trick is creating a machine readable and executable accounting policy. If you’ve ever puzzled over the vast complexity of the various Accounting Standards, you might think this is an impossible task. And yes, trying to interpret and automate that would be a herculean task. But it turns out, simplification is your friend here too. We had originally thought that we would need a small domain specific language to write rules that would implement accounting policy. Some of the things we discovered along the way have greatly reduced the need for such a rule language, and instead will have a fairly simple data driven approach.
Four nice byproducts of this:
- Accounting policy is completely consistently applied (no worrying whether the branch office is recognizing revenue differently).
- Changes in the books and records are available for analysis as soon as the business event has transpired.
- The books can be closed immediately after the end of a period (no 5-10 days “closing the books” rituals).
- Almost no need for bookkeepers.
Debits and Credits Mostly Hidden
The proponents of REA have proven that, strictly speaking, debits and credits are no longer necessary in modern accounting systems. We believe that removing them entirely may have been one of the barriers to adoption of the REA approach. The entire accounting industry is steeped in double entry bookkeeping with its debits and credits. Well-understood and liked, financial statements feature them prominently. Interfaces to and from accounting systems rely on them. Debits and Credits have become the security blanket for the entire industry, and we aren’t going to snatch it away all in one go.
We have chosen to keep debits and credits but keep them hidden. Like the apocryphal urban legend that Rolls Royces have locked hoods, that only authorized Rolls Royce mechanics have access to (to prevent amateur tampering), we will be locking the hood on the debits and credits. Only those that need to see them can, and they will not be allowed to edit at the journal level. Interfaces can still generate debits and credits, and the occasional “T” account on the white board will still have a correspondence in the system.
In addition to reducing complexity, this ensures that the audit trail is direct from the business event to the books and records, without intermittent interpretation and adjustment.
Real Accounts Rather Than Ledgers
We decomposed everything that is happening in the books and records of a firm. There are a lot of true “accounts.” In our semantic interpretation an account is an agreement with a balance. For instance, when you sell something and allow your customer to pay later, you have entered into an agreement, and you (and they) will be keeping track of the balance on this agreement (you will call it an “Accounts Receivable” they will call it an “Accounts Payable.”) We call these “true accounts”, and they are with third parties.
In traditional accounting systems, there are very few true accounts in the “General Ledger.” Most of the true accounts are in subsidiary ledgers, which really means different systems. What is weird is while there are few true accounts in the General Ledger it is structurally set up as if they all are. The “ledgers” are accounts that have debits and credits and balances and can be affected by transactions or journals. This is just another example of confusing structure with meaning. Thinking that something that looks like an account really is an account is looking for trouble.
So far, we’ve identified 15 distinct types of accounts. We expect to find one or two more as we delve into other industries or special conditions. Of these 15, 10 are “true accounts” with real third parties (Bank Accounts, Credit Cards, Accounts Receivable etc.). The remaining five do not have a third party, but behave in all other ways as accounts, and include such things as Buildings, Equipment, Inventory, Goodwill and Petty Cash.
The world becomes massively simpler when the General Ledger is only an aggregation, and not the first among equals of the ledgers.
True Flow Accounts for the Income Statement
Every accounting textbook ever written says that there is a fundamental difference between the Balance Sheet accounts (Stock or point in time accounts) and the Income Statement Accounts (flow or temporary accounts). And every accounting system, under the hood, treats them the same. They are both ledgers with transactions (and even balances, although some systems hide the Income Statement balances better than others).
It turns out the accounting textbooks are right, and the industry hasn’t caught up yet (it’s only been 500 years, give them some time). When you implement the Income statement as a flow over time (literally dollars / duration) all kinds of good things fall out. Also, once you make this distinction many other benefits accrue.
Two of the main benefits that come from treating Income Statement accounts as flow:
- The system (rather than a bookkeeper) can determine whether a transaction represents a “prepaid expense” or not (if the “paid on”, or “accrued on” date is before the flow dates, it is “prepaid” for any reporting date up to the flow effective start date, and partially prepaid up to the flow end date). Lots of precision and accuracy with no additional work.
- You can get a meaningful P&L at the week and even the daily level. By dividing the flow over the duration, you can get the value per day, with no new transactions, just a query. This is unheard of. If it were currently possible people would be clamoring for it.
Facets Rather Than Complex Coding Blocks
“Facets” is just another name for orthogonal dimensions. Orthogonal (literally “at right angles”) means two sets of concepts could be arrayed in a matrix (one set of concepts on the x axis one set on the y axis). And you don’t have to limit yourself to two dimensions.
The power of facets lies in their combinatorial power. Starbucks serves 170,000 different drinks by offering caffeinated and decaf, coffee, tea or chai, espresso, drip or pour through, six kinds of milk, eight kinds of syrups, iced or hot, four kinds of sweetener, three sizes etc. (I didn’t check their math, but it seems in the ballpark). The key idea is you can get incredible variety, with a few simple categorical differences, as long as they are orthogonal (that is, they can be used in any combination).
Anyone who does financial analysis knows the power of facets (also called dimensions in data warehouses, or pivot table fields in Excel). They can easily be combined in different combinations and nested within each other to provide ad hoc fine-grained analysis.
XBRL is a standard for financial statement consistency. Even they have a running debate on facets versus hierarchical taxonomies, They call facets, “dimensions,” and hierarchical taxonomies, “tuples,” but it’s the same debate. This is because financial statement authors want to craft the presentation of the statements in the annual report. Analysts (who like dimensions) just want to understand. Financial reporters are telling a story. However, what got missed in this debate is three-fold:
- With the right tooling, the arbitrary “tuples” (hierarchical presentation) can be derived from the dimensions.
- The XBRL hierarchical approach has created 15,000 tags (it is almost as if Starbucks listed all 170,000 combinations of drinks on their menu—imagine if Steve Martin’s half caf double decaf with a twist of lemon [watch the video] had its own name).
- In order to get all the transactions in the “right” categories, a host of adjusting transactions must be performed on the transactions.
Adopting orthogonal facets has several benefits. Analysts and financial reporters can literally work from the same set of transactions. The categorization is simple. Now that senior management must sign off on the financial statements, transparency is all the more important.
Summary
We didn’t set out to change the accounting landscape, but it gives you an idea of what is possible when you look at the world through the Data-Centric lens. If you are in a professional services firm, interested in this, and want to be a guinea pig starting next year, drop me a line now.
