transactions, accounting, bah humbug

In these tax return days, please raise your hands all who love accounting. Anybody?

Accounting - double-entry bookkeeping - transactions. Basically unchanged since 1494.

Did they have computers in 1494?

So why do we keep doing it the same way the Venetians did it?

The double-entry bookkeeping has one requirement: Register transactions.

When your product changes owner it's deemed to be a transaction. No, hang on, not always, you have differing rules there, from country to country, from year to year. So what you register as a transaction one year may not be a transaction the next. A moving target indeed.

In practice we try our best to reflect the transaction by a an invoice, a contract, a bill of transport or a receipt of delivery. Then that travels to the accounting department who's main purpose is to make educated guesses as to what bill, receipt or invoice best reflects what the tax authorities rules as that particular transaction in section 93, part 3, clause 34.

Next year clause 34 is amended and comparing last year's results with this year is like comparing apples and bananas.

In reality most of "how we do things" in business is a direct result of the 514 year old accounting method. It created the invoice, the bill-of-whatever, the report - no other need for such massive resource wasting documents and reporting requirements.

Then you have Enterprise Software, the stuff that has made the world's best and brightest production and retail companies amazingly efficient. Guess what principles these are built on. Yep, transactions. 514 year old methods nicely translated into efficient code. Not to mention the invoices, bills-ofs, documents and forms, yech.

Is that fair to the code? Is that really smart at all?

The thing is - I do not disagree with the concept, I merely disagree with how it's done, i.e. accounting as in methodology:

Today: You make up your mind as to what report or activity that best matches the current and local rules, then register that as a "transaction". Then you make best use of that piece of manipulated data, raw data with somebody's logic stuck to it. Any changes at a later date requires unsticking the transaction, reapply a different logic (rule) and stick it back into the system.

As a result you end up comparing apples with bananas, reconciliation bloating your OH and days, weeks or even months gaps between reality and reporting of that reality. (Nice way to architect a management control system eh? Drive a car by proxy.)

Tomorrow: Register what really happens when it happens, not the transaction but what really, really happens: Widget is created, widget is painted red, widget changes owner, widget leaves our warehouse. These activities are direct results of tasks, again results of work orders and all such can be captured. If your Enterprise Software is meant for that first and foremost (and not to exist in order to register transactions), well then you have the raw data onto which you can apply some logic in the form of templates at the back end: One for UK GAAP, one for German GAAP, one for last year's rules, one for this year's rules.

As a result you have only apples or only bananas, no reconciliation and real reports in real time. Drive with direct steering.

First step to better business, better use or resources, a greener world, better profits and more time for the family is - well, rather simple: Disentangle us from the 514 year old methods!

Good riddance to accounting as we know it. It will happen.

Comments

[Dennis Howlett]

How then do you handle the rule changes? Presumably by altering whatever the rule is in the appropriate place. But how is this fundamentally different to what already happens? Is this about meta data?

[sig]

In short - back-end instead of up front, or rather presentation instead of representation like this:

Current ways: The transaction is added to the system at the appropriate account, up front. Slotted into a specific "drawer". That's the only place the system "knows" about the transaction, represented by an invoice or some bill-of-something. With a rule change you would have to reapply the transaction to another account or at another time, but in most cases you would have to pay C&L to translate the accounts into a different GAAP (or rule).
(I've done it, preparing for US GAAP, precious three years, months of work and oozes of cash paid for nothing).

If you'd like to run in parallel US and UK GAAP every invoice (or other transaction-representation) would be under the risk of having to be registered into two different accounts (and even parallel systems) up front due to the different rules.

Alternative: The system has the raw data from the actual happenings, from the workflow itself, it knows when the widget changed colour, when it changed owner, when it left our warehouse. All of that workflow results captured, no accounting thinking nor transactions involved. Mind you that a "transaction" is mostly a virtual activity, something defined by a rule. The widget does not bother about ownership, although it does bother about where it is.

For that, at the back end you could have a "template" as in a query plus presentation giving an accounting report. That "template" has it's own logic and applies that to the raw data when queering: "Add up value of all widgets that left our ownership during period A". That'll give the sum of transactions "sales of widgets for period A" according to Rule 1.

Now add another template with a different query using same untouched raw data: "Add up value of all widgets that left our ownership, and that left our premises during period A". That'll give "sales of widgets" following Rule 2.

The two reports (queries) thus yields two different results, each following a different rule (or GAAP) without influencing each other. And they can be run in parallel. Add another GAAP (Rule 3) later down the road, once the "Rule 3 templates" have been defined, using the same old raw data it'll yield all historical and current accounts according to Rule 3.