Double Entry Bookkeeping

A common way to look at DoubleEntryBookkeeping is to use the AccountingEquation?, which says Assets = Liabilities + Owners Equity.

Each side of the equation must equal the other, therefore a change to one side must be made to the other. This is most commonly (and preferably) a non-zero value. -- MichaelLeach

I needed two insights to get the Aha! of double entry bookkeeping and remove what seemed like its obvious nincompoopicies (the extra work and the fact that numbers keep getting bigger):

The invariant Equity = Assets - Liabilities involves subtraction. tut tut. To turn it all into addition, rephrase as Assets = Liabilities + Owners Equity. Now, give the the owner $500, and both Assets and Equity go up. Owner spends $100, and Liabilities goes up and Equity goes down. (oops, how'd that subtraction get in there!?)

We still haven't gotten rid of the subtraction. To get rid of the subtraction, keep a Left and a Right side to each account. I think of it as a Negative and a Positive side, but they didn't use negatives back then. To add $100 to an account, list it in the Right side, and to subtract $100 from the account, list it in the Left side.

Now we don't need to subtract, we only need to add up all the columns in particular ways and see that the (ever growing) numbers just add up to the same value.

Now it works out. If the Owner hands out $100, we add $100 to the Right (Positive) side of Liabilities, and also to the Left (ahem Negative) side of Owner's Equity. We can't subtract anything to get a zero, but we can see that the Lefts and the Rights balance out.

Uh, no. If the owner hands out $100 in cash; that is a reduction in assets. Liabilities refers to money that the company owes; liabilities are incurred when the company borrows money, makes purchases on account, etc.

Using Lefts and Rights and only addition, the invariant now becomes:

For the example above, with $500 coming in and $100 going out, you see that 500 + 0 + 100 = 0 + 100 + 500, which is 600 = 600, which is true. It always seemed idiotic (to me) because there never was any $600 in the story, and complicated (which it is), and laborious, which it also is.

But along the way, it very quickly catches those little addition mistakes that send accountants crying into the night. The absence of those adding mistakes made the Medici accountants much more reliable than their competitors, which is why they grew so rich. Hence, the Medicis kept their accounting system as closely guarded a secret as Coca-Cola keeps its formula - - - and they made an equivalent fortune from it, etc etc.

Next, if you have sub-accounts, apply the invariants&additions idea recursively ad infinitum.

The complications in the system come from remembering which columns are supposed to be added to which to balance against the others. It is further complicated that in the sub-accounts some of the columns change places to make the additions balance out when summing up. And that is further complicated by the fact that the words "credit" and "debit" don't mean the same thing to us in English as they did to the 15th century Italian bookkeepers. Students learning DoubleEntryBookkeeping have to learn all the column names and how they combine... to me that's at least as hard as learning the names of the bones in the body...

Look at the examples below and you'll see that every example involves restoring the invariant and using only addition. --AlistairCockburn

I find that people are most often confused by the fact that their bank uses "opposite" credit-debit terminology: User says "the bank credited my account, so I should credit that account in my journal." "No," I say, "a credit on their books is a debit on your books. To them, your account is a liability (they owe you money), while on your books it's an asset (you "have" the money that's in the account)." -- JeffGrigg

So, EverythingIsRelative, eh? :-)

Every accounting entry in a DoubleEntryBookkeeping system is a movement of money from one account to another.

It's a ZeroSumGame: The total of all accounts in the business must, at all times, be zero. The need to add up to zero is an error checking mechanism, left over from several hundred years of doing the books manually.

How can everything add up to zero? Well...

I Want to start a business.

I put $1000 into a checking account for the business. This translates to "debit the business' checking account $1000 + credit the 'owner equity' account $1000 = $0 total".

I take out $100 and put it in a "petty cash" box: Credit checking $100 + debit petty cash $100 = $0.

Now... 

  Owner Equity= $1000 CR  (a "negative" number)
  Checking Account = $ 900 DB
  Petty Cash= $ 100 DB
----------
Total
$0(as always)

I buy $50 of office supplies and pay for it with a company check: Credit checking $50 + debit office supplies (an asset) $50 = $0.

And so on...

One can also get tricky, and have any number of lines in a given transaction: Like, I pay an invoice for some stuff I bought from office depot. It may include a computer, which is an asset I wish to depreciate over time, some office supplies, which I may just expense immediately, and some office furniture, which I'll treat much like the computer. In any case, the sum of all credits and debits will be zero.

When I first worked on accounting systems, starting in 1986, the ZeroSumGame confused me. "Why do all this when it all adds up to zero anyway? Isn't it kinda' pointless?" Some experience, college training, and a certification as an entry level bookkeeper taught me different. -- JeffGrigg

For all the benefits of DoubleEntryBookkeeping, it's interesting that the success of QuickBooks? and Quicken is credited to removing this complexity and providing a soft-checkbook UI for small business owners. But internally, the data is maintained in double entry. --MichaelLeach

I once listened to a customer plead with developers to add double entry bookkeeping to their accounting tools. The customer claimed that they spent several weeks every month hunting down errors that double entry bookkeeping would find immediately. The developers protested that the system as built could produce every report that was asked for and did so error free. So where was the disagreement? The system may have been self-consistent, but it had to interact with other legacy systems that would get out of sync for various reasons including running in different data centers on different schedules. The solution was of no surprise to the customer: create accounts that parallel those on the remote machines and make complementary entries in those accounts that would be logged and checked at the earliest opportunity. We spent another hour discussing how this would be done before the light went on for the developers: "Oh, you just want us to maintain these extra accounts to find the mistakes you make." -- WardCunningham

DoubleEntryBookkeeping is a "technological" AntiPattern reminiscent from the way accounting was done manually. Before computers took over, accountants put the sums corresponding to the operation in at least 2 places, the credited account(s) and the debited account(s) because they kept separate ledgers for each account, to facilitate manual calculations. A computer does not have this problem because the operation is recorded only once. The example above becomes 

 Operation_No | Credit_Account | Debit_Account | Amount
 ------------------------------------------------------- 
     1001     | "Owner Equity" | "Checking"    |   900
     1001     | "Owner Equity" | "Petty Cash"  |   100
While a manual accounting would have done this with three entries : 

  Operation_No | Debit  | Credit
 --------------------------------
      1001     |        |  1000   -- in the "Owner Equity" book


 ...


      1001     |   900  |         -- in the "Checking" book
 ...


      1001     |   100  |         -- in the "Petty Cash" book
And what was for accountants an equality useful to verify the correctness of their scripts, for an accounting database it becomes a trivial identity. However, I've seen enough bad accounting software that effectively mimicked the manual operation mode.

This is an example where operations can and should be done sensibly different in a software system. If you interview an accountant, he will tell you effectively that the transaction above is composed of one credit line and two debit lines, and an analyst/designer will be tempted to model the accounting world by the objects Account, Operation, Account_Entry while the correct solution is Account, Operation, Operation_Entry. Therefore a software engineer should sometimes go beyond the immediate perspective of the user on how things should be done. --CostinCozianu

---

WARNING: Costin describes"Singe Entry Bookkeeping"! Costin, you describe 'single entry bookkeeping', because you store only one record here. This approach is a valid bookkeeping approach and there's nothing wrong with it. Just don't confuse the labeling, this is SINGLE ENTRY BOOKKEEPING. There are good reasons why the accounting folks use DOUBLE ENTRY BOOKKEEPING. If you map the process to a computer you need to save two records. And No, they are not redundant, they are complementary. A common fault is, that people think "-100" equals "+100". Well, this is not true! -- Gerhard Muth

I think Gerhard Muth confuses the physical aspect of a single transaction row with the concept of "single entry". The example clearly accepts an "entry" of both dr & cr in their respective fields. The fact that what is best for a manual system may not be best for a virtual system, seems to escape Gerhard. - CompuSolver? ---

Yes, we pave the cow path.

In the 1980's I had several customers who insisted on implementing their accounting systems by writing the transactions into ledgers first, and then data entering each ledger. In other words, they intentionally threw the books out of balance, and relied on reports, including the traditional balance sheet, to find and correct all their data entry errors at the end of each month. Later, people got smarter about data entering one business transaction at a time. -- JeffGrigg

I think I had the same discussions, the users insisted in having the software test the identity (sum of credits = sum of debits) but I managed to explain that a software program cannot err in the same way as an accountant. They asked me then how they would detect some errors and I explained to them that the data entry program won't let them make the errors they were used to. Of course there are plenty of other errors one can do in an accounting system, but the manual DoubleEntryBookKeeping? doesn't detect any errors other than incorrect redundancy of data or failure to add correctly. -- CC

Hmmm... So it doesn't bother you that your table has two foreign key columns, Credit_Account and Debit_Account, which differ only in the processing (add or subtract) being done? Many accounts will get both credits and debits in any given month, so you'd have to check both columns (with an "or" or maybe a union) to get all activity for an account. -- JeffGrigg

No, this is the essence of each accounting operations: you move an amount between two accounts (the credit one and the debit one), if you put it separately you don't have a good and safe way to eliminate redundancy. It is true that depending on the database engine, calculating the balance for an account within a single SQL statement might take a bit longer than optimal ( you can create a view selecting sum of amounts group by credit_account and the same for debit_account, then join the two views together on the account column and subtract credit from debit). Some sql optimizers might transform this thing into a nightmare, but you can always add optimizer hints forcing the database to do it your way or write a trivial stored procedure or create materialized views or consider a better DBMS. Luckily I didn't have to do any of those.

There's an interesting discussion in here on how the quality of the logical schema should always take precedence over the query performance considerations. In an ideal database, supporting query performance should be dealt by using redundancy only at the physical level, managed internally by the DBMS engine as opposed to explicitly managed by the external application at the logical level - the way it is done now. We are moving there but slowly because the marketing departments from Oracle and the likes decided that such features are not as sexy as object/relational and XML. -- CC

I think that in an ideal world, I should be able to state as a database constraint that the sum of debits and credits equals zero. The fact that this constraint is violated in the middle of a transaction shouldn't be an issue, because it need only be valid at commit time. Unfortunately, I know of no production relational database that can process this constraint. -- JeffGrigg

Oracle as of release 8.1.0 (late 1999 or early 2000 release) allows you to create a constraint as

Deferrable
By default checked after each DML statement, but can on a transaction basis be deferred to the end of the transaction.
Initially Deferred
By default checked only at the end of the transaction.
-- AnOracleGuy?

There's quite a bit of misunderstanding above about how manual accounting systems are run. As transactions occur, they are recorded in a journal, which is a list of transactions of some particular sort (i.e. sales). The journal will contain entries similar to your first account; each transaction will list two or more accounts that are affected by the transaction, and each transaction maintains the invariant that the sum of credits and the sum of debits are equal. Journals generally correspond to functions and not to accounts.

At closing, the various journals are "closed", and the transactions recorded therein are "posted" into the ledgers. A ledger is a list of all transactions on a particular account (or a set of accounts). Individual items in a ledger do not obey the double-entry invariant; however for each credit in a given ledger there is a corresponding debit in some other ledger (or combination thereof).

Many outside the accounting/bookkeeping profession are unaware of the distinction between a "journal" and a "ledger", and use the terms interchangeably; when they are most definitely not the same thing.

I think I've understood all this. Now suppose I buy same paper for my printer. I could have an account called "Consumables", and the purchase effectively moves 100JellyBabies from the "PettyCash" account to the "Consumables" account. How and where does the "Consumables" account lose its value?

In theory, as you use the paper, you would reduce the balances of Consumables and Owner's Equity. But in practice, many companies would simply reduce Cash and Owner's Equity at the time of the purchase of the paper, as it is an operating expense. (This is what is meany by expensing something). Many companies only keep asset accounts for capital assets (buildings, factories, equipment, etc.), liquid assets, and for inventory that can be sold. This is the kind of thing that got WorldCom? into trouble: treating expenses as assets. -- KrisJohnson

That's correct and the concept that justifies the practice is "materiality". If the amount of printer paper you bought was equivalent to your annual profit, and you bought it on the last day of the year, then expensing the entire purchase would dramatically change your financial results and cause a reader of your financial statements to come to a different conclusion about the health of your company. An amount is material if it changes a reader's conclusions (textbook definition). In the example, and in theory, the "Consumables" account only loses value as the paper is actually used (since we don't ascribe any value to the paper after it has been printed on). In practice it's just easier to write it off when purchased. Sometimes consumables are in fact treated as office inventory, although I don't think it's very common anymore. The same rationale is used for expenses whose use is for a fixed term, and are therefore recorded as prepaid expenses and written off over the term, e.g. insurance, licenses, etc. -- MarkTilley

There are also intangible assets, such as intellectual property and "goodwill". Goodwill is accounting-speak for the difference between the value of the company as recorded in its books and its likely value if sold as a whole. As most companies are greater than the sum of their parts, goodwill is how accountants deal with the difference. Note that while IP can be recorded as the amount of money you spent aquiring/developing it, goodwill is generally only recorded when one company buys another and needs a way to answer the question "Why did we pay $1M for $900K worth of equipment/receivables etc.?".

Discussion about capitalizing assets and writing them off as they are used.

Also, if you record a capital asset you do not write it off as it is used. You leave the initial amount untouched and create a contra account (a credit account that offsets a debit account) to the asset. In the case of capital assets, this is usually called Accumulated Amortization. Using some formula you expense part of the value of the asset each accounting period with a debit to Amortization Expense (Equity) and a credit to Accumulated Amortization. Then when you report the value of the asset you usually show the gross value, the accumulated amortization, and the net of the two. When the net reaches zero you reverse the asset out: debit Accumulated Amortization and credit the Asset. Contra accounts are a significant part of accounting systems.

This discussion hasn't touched on two extremely important accounting concepts: GAAP and auditability. Generally accepted accounting principles (GAAP) lay out, for each country (and the IASB is putting together international standards), the guidelines companies must obey in reporting their financial position. This is usually a legal requirement and is a very good reason clients want data journalized. Audits verify a company's financial reports against supportable evidence in order to, among other things, catch fraud and ensure GAAP compliance. Journal entries are an important part of this process as well, especially the concept of reversal rather than deletion: debt credits and credit debit when mistakes are made, do not just remove entries.

It is a very good thing if you are able to back up the output of your financial systems with an audit trail, and journal entries are an audit trail all auditors instantly understand. The alternative is probably significant testing time by the audit staff, which will be very, very expensive, or calling in someone (disclosure: like I will be soon) with a computer science degree and a financial accounting certification to audit the actual code, again at great cost.

So double entry is in some cases a legal requirement, is probably a good way to save money when you're audited, and is definitely a good way to catch and record human mistakes and fraud. A computer system that doesn't at least allow a transform between its internal representation and a set of books is missing out on a lot of end user value. And why add the extra step of the transform (something else to be audited) and not just store the data that way in the first place? The benefits of some other representation would have to be pretty significant. -- AF

If we build our systems following the principle of double entry do we reduce the probability of errors? Or do we increase the probability of them? From accounting experience, it would seem we should follow this double entry system, but AirplaneRule apparently goes against increasing complexity by doing things twice. Does anyone here know of a mathematical proof that double entry actually decreases the probability of errors? Or does it only increase the probability of detecting errors but in fact it also makes them more likely to occur?

I doubt you can find a mathematical proof, beyond the obvious implications of ensuring debits equal credits. However, in a manual bookkeeping system, such as one using paper or computer spreadsheets, it can be shown empirically that double entry decreases the probability of errors. With immediate verification that debits equal credits, combined with the data entry techniques that promote validation -- e.g., each side of a transaction is done at different times, or by different people, or one side is a summary while the other is detailed, etc. -- we have a reasonable assurance that data entry has or hasn't been done correctly. A skilled bookkeeper can even use the amount of imbalance to quickly search for transactions that are likely to have been mis-keyed. I've seen single entry systems that were rife with errors, but which were only detected when they had aggregated sufficiently -- sometimes over such a long period of time that the source data no longer exists -- to simply look wrong with no knowledge of why they look wrong.

In automated bookkeeping systems -- such as typical computerised accounting packages, the financial component of ERP systems, etc. -- the need for true double entry is arguably reduced, but it can still provide verification that manual data entry is accurate and that automated processes are likely to have worked properly. This is especially true if combined with with data entry, summarisation, and/or transfer techniques that promote validation, e.g., each side of a transaction is done at different times, or by different (sub)systems, or by different data entry personnel, or one side is a summary while the other is detailed, etc.

I developed and maintained automated bookkeeping systems for two decades. Use of double entry successfully flagged problems on innumerable occasions, especially during development and testing, but also in production. I can't think of an occasion where it ever caused a problem. Double entry should not be considered an example of the AirplaneRule; rather, it is a form of double-checking that data entry is correct and automated processes are working correctly. -- DaveVoorhis

As described in AccountingModeling, one can guarentee on the "machine side" that everything balances after each transaction. Double-entry appears to be obsolete. But this may be different than reducing human errors such as omission of a complete transation or putting stuff to the wrong account (even though its one that satisfies technical balance). It is hard to describe how to reduce human errors that are not machine-detectable because it is a matter of psychology. The machine can verify that what you asked for is correct (and not accept it otherwise), but it cannot tell you what you really wanted. It could be argued that double-entry forces one to see their transaction from two perspectives, increasing the chance that somebody will correct it. But a pre-acceptence simulation can do the same thing. It is comparable to being able to order the wrong crap on ebay by clicking on the wrong button. If you went to a physical store, it takes longer to make the transaction and you wait in line staring at what you selected. Automation can remove the "wallow factor" that used to be a check on what we do. Perhaps a "wizard" can show the user the consequences of his/her transaction by emulating the paper way before the "Go" button is hit. But it will slow things down. Maybe it could be set up so that amounts above a threshold require the wizard.

Many low-volume, home and small-business bookkeeping systems employ mechanisms such as you've described to present double entry in a user-friendly single entry guise, but double entry is by no means obsolete. Indeed, in many cases it is a legal requirement.

Double entry should not be viewed as a form of duplication, but as a fundamental model for representating the financial position of an entity in a manner that conforms to Generally Accepted Accounting Principles, while supporting error detection and correction without compromising auditability. For more on that, see the section above this one. 

   ChargeAcct   Qty
   ----------------
   FA063         12
   KY004          1
   BK361        342
   Etc...
Furthermore, while simple transactions are often machine-validated as they are created, or are structured so they are implicitly in balance, complex transactions may involve a time component (e.g., waiting for a currency conversion to be performed) or integration with legacy systems that prevents them from being treated as an atomic unit. Not only that, but in large, high-volume accounting shops the data entry tasks may be distributed among a pool of clerks, with one clerk entering the debit side of a memo and another entering the credit side. This "duplication" of entry serves as a valuable and efficient cross-check on data-entry validity, while conforming to the accepted accounting model. With a single entry, the only method of verification is to re-reference the original document. -- DaveVoorhis

How is "memo" defined here?

It's an example. I was thinking of debit memos or credit memos, which are documents used to make an adjustment to an account -- usually in an Accounts Receivable or Accounts Payable system -- but it could refer to any document that represents an adjustment. The same approach could apply to entering a large volume of hand-written invoices, cheques, petty cash receipts, till tapes, etc. In a perfect world, these would be automated and require no human data entry, but it ain't a perfect world. -- DV

Wouldn't there be a holding account while the transaction is still pending from the remote source? Internally you don't leave stuff open, you usually move (change) it to a special kind of temporary internal account such as "Estimated Conversion Value", and then move (change) it again when it completes remotely. In other words, an external "pending" transaction does not have to be a pending internal transaction in the same sense.

You're perhaps thinking of a suspense account, which is somewhat different (see http://en.wikipedia.org/wiki/Suspense_account) though I suppose it could be used to handle complex transactions. However, under the model above, the assumption is that transactions close sufficiently quickly that their temporarily open state doesn't otherwise matter. Complex transactions, as described above, usually remain out of balance for seconds at most. Out-of-balance for longer is indicative of a problem, for which the out-of-balance state becomes a useful diagnostic tool.

It should time-out as a transaction failure, not left half-completed. I don't see why being out-of-balance is necessary to track/log errors. Just record the failed transaction in the log for review. Has all the same info.

Reasons why your A.B. approach is insufficient are covered above.

May I ask for specific locations? I don't see significant flaws.

From the above, for example: "For simple transactions, where the debit and credit sides of a transaction each reference a single account, it will work fine. More complex transactions -- which reference varying accounts and have varying amounts on each side (though the total debits must equal the total credits) -- will not work with the model as it is presented. It also won't work very well with transactions generated by systems that present the debit and credit sides of a business transaction at different times. You could represent a complex transaction as a series of simple transactions, of course, but you're going to be duplicating dates, descriptions, reference numbers and so forth and I wouldn't want to be in the room when your auditor or accountant sees the result. [...]"

One's going to need some kind of "batch header" regardless. As far as the timing issue, it's discussed further down from the original quoted part.

I'm not clear what you mean by that, and your A.B. approach doesn't handle complex transactions as described above.

For example, the check for invoice X clears, the system creates a "transaction header" with a memo such as "Check for invoice X cleared" (or equiv. event-type code) with the date and other metadata. The A.B. transactions are just details under this parent "event" (for lack of a better name).

That appears to differ from, or at least extend, from the "Assume Balance" model you presented at AccountingModeling. If you've decided to start revising your model to effectively handle complex transactions, that's a move in the right direction.

As far as "different times" or "complex transactions", I'd like to see a specific example along with specific business scenario context. -t

Imagine you sell motorcycle-related products, and issue an invoice to a customer for $125.48 of which $93 is repair parts and $10 for clothing, plus $11.24 in provincial sales tax and $11.24 in federal value-added tax (VAT). To account for this, you would likely debit A/R for $125.48, credit clothing sales for $10, credit parts sales for $93, credit provincial sales tax for $11.24 and credit VAT for $11.24 -- all (ideally) in one transaction. It could easily also take into account cost of sales and shipping charges, which would add more detail. If there are currency conversions because you sell out of country, the calculations for these might be deferred until later, or at least delayed by obtaining the conversion rate from an external system. That's a simple but typical example. All of this detail is best represented as a single transaction in order to avoid duplication (which, in its original form, your "Assume Balance" model would require duplication) and to clearly relate all the detail to the given invoice in order to keep your auditor happy. Some billing systems (for example) record sales and tax amounts on an invoice-by-invoice basis and then compute the A/R credit later on a batch basis, so the credit side of the transactions can be computed later. A G/L system should not impose arbitrary restrictions on the systems that feed data into it, so being able to effectively handle simple transactions (like those your A.B. model supports), complex transactions, and complex transactions with deferred detail is a good idea.

Both were covered above already (headers to avoid duplication & conversion delay). You don't necessary have to hold open a transaction while currency conversion is happening. Holding transactions open for long periods is a bad idea regardless of encoding technique.

Have you actually read any of the above, or are you responding to what you'd like it to have said? By the way, business transactions and database transactions may be related, but aren't the same thing.

Your writing style is difficult, but I gave it my best shot. It appears to be a repeat. The reasons to keep DB transactions short apply to accounting also. You don't want half-ass or ambiguous accounting information floating around. It's reasonable to use something similar to a suspense account if exchange rate conversions may take a while rather than risk the integrity of the entire grouping.

Again, you appear to be conflating business transactions with DBMS transactions. Depending on business requirements, it may be appropriate to ensure that each financial transaction -- whether complex or simple -- keeps the books in balance. Depending on business requirements, it may be appropriate to allow the books to go out of balance until some reconciling transaction is performed. Both approaches are used in practice and both work.

However, this is not the real issue with your A.B. approach. The real issue is that complex transactions, like that described above, need considerable duplication to be represented using the approach you presented on AccountingModeling. If you're now claiming that what you presented on AccountingModeling is incomplete, and there is in fact a header that is not shown, then that's something different. I presume, then, that you mean something like this: 

 VAR Account REAL RELATION {AccountNumber INTEGER, Name CHAR, Description CHAR, KindOfAccount CHAR} KEY {AccountNumber};
 VAR Journal REAL RELATION {JournalID INTEGER, Day Date, Description CHAR} KEY {JournalID};
 VAR JournalDetail REAL RELATION {JournalID INTEGER, AccountNumber INTEGER, Amount RATIONAL, IsDebit BOOLEAN} KEY {JournalID, AccountNumber};


 CONSTRAINT JournalDetail_References_Journal  JournalDetail {JournalID} <= Journal {JournalID};
 CONSTRAINT JournalDetail_References_Account  JournalDetail {AccountNumber} <= Account {AccountNumber};


 VAR JournalDebit VIRTUAL JournalDetail WHERE IsDebit;
 VAR JournalCredit VIRTUAL JournalDetail WHERE NOT IsDebit;


 CONSTRAINT JournalBalances  SUM(JournalDebit, Amount) = SUM(JournalCredit, Amount);
The above (in TutorialDee) minimises duplication whilst supporting simple and complex transactions. It also ensures -- via the "JournalBalances constraint" -- that the books always remain in balance.

How do you switch off the constraint if "it may be appropriate to allow the books to go out of balance until some..."? 

        CONSTRAINT JournalBalances  SUM(JournalDebit, Amount) = SUM(JournalCredit, Amount) 
          OR NOT EnsureBalance FROM TUPLE FROM Configuration;
Here's an A.B. approach illustrating the "header table": 

 acctTrans (table)
 ---------
 transID
 categ  
 timeStamp
 note


 transDetail (table)
 -----------
 transRef   // f.key to acctTrans table
 fromAcct
 toAcct
 amt
 note
 // (PK is 1st 3 columns. Surrogate key optional.)
Don't need no stinkin' balance constraints. It's the future. As far as the suspense-account-like approach issue, I'll LetTheReaderDecide. I don't want to argue that any further unless you bring in new information. -t

That's a typical approach used with "home" and some small business bookkeeping systems, which only record simple transactions. Complex transactions -- like the invoice examples above -- have to be converted into a series of simple transactions which means "note" and one account reference -- either toAcct or fromAcct -- need to be duplicated.

For example, using the approach I demonstrated above, the invoice example would look like: 

 INSERT Journal RELATION {TUPLE {JournalID 1, Day Date(2013, 6, 23), Description 'Invoice #12341'}},
 INSERT JournalDetail RELATION {
   TUPLE {JournalID 1, AccountNumber 1000, Amount 125.48, IsDebit TRUE},
   TUPLE {JournalID 1, AccountNumber 3010, Amount 10.00, IsDebit FALSE},
   TUPLE {JournalID 1, AccountNumber 3020, Amount 93.00, IsDebit FALSE},
   TUPLE {JournalID 1, AccountNumber 2010, Amount 11.24, IsDebit FALSE},
   TUPLE {JournalID 1, AccountNumber 2020, Amount 11.24, IsDebit FALSE}
 };
Using your approach (again assuming TutorialDee syntax), it would look like: 

 INSERT acctTrans RELATION {TUPLE {transID 1, categ '???', timeStamp Date(2013, 6, 23), note 'Invoice #12341'}},
 INSERT transDetail RELATION {
   TUPLE {transRef 1, fromAcct 3010, toAcct 1000, amt 10.00, note 'Invoice #12341'},
   TUPLE {transRef 1, fromAcct 3020, toAcct 1000, amt 93.00, note 'Invoice #12341'},
   TUPLE {transRef 1, fromAcct 2010, toAcct 1000, amt 11.24, note 'Invoice #12341'},
   TUPLE {transRef 1, fromAcct 2020, toAcct 1000, amt 11.24, note 'Invoice #12341'}
 };
You could say there's nothing wrong with that, and you'd be right. Indeed, it's a row shorter than the approach I demonstrated and "note" is arguably not needed in transDetail, so it could reduce to: 

 INSERT acctTrans RELATION {TUPLE {transID 1, categ '???', timeStamp Date(2013, 6, 23), note 'Invoice #12341'}},
 INSERT transDetail RELATION {
   TUPLE {transRef 1, fromAcct 3010, toAcct 1000, amt 10.00},
   TUPLE {transRef 1, fromAcct 3020, toAcct 1000, amt 93.00},
   TUPLE {transRef 1, fromAcct 2010, toAcct 1000, amt 11.24},
   TUPLE {transRef 1, fromAcct 2020, toAcct 1000, amt 11.24}
 };
That's even better. Of course, it's only that easy because as complex transactions go, the example was quite trivial -- particularly because all the credits balance against a single debit. Where your approach becomes awkward is with more complex transactions involving multiple debit and credit accounts. For example, given the following complex transaction... 

 AccountNo Debit    Credit
 1000               2500
 1020               3200
 1040      1600
 1060      1000
 1082       400
 1090       200
 2010      3200
 2020                700
...it should be self-evident how it would be recorded using the approach I demonstrated. How would you record it using your approach?

For trace-ability and easier reporting, one generally wants to know the specific amount moved between accounts. Thus, your example is a bad practice even if technically doable. You'd probably have to record the specific allocation anyhow because rounding to cents may require "shuffling pennies" and we'd want to document that shuffling. It's not unreasonable for a given query or report focusing on account 1000 to ask "Where was the 2500 allocated?" (I suggest you plug your listing with 0's to assist with any future TabMunging repairs.)

The transaction above shows all the specific amounts moved between accounts that are relevant and no more, and it is realistic, having been taken straight from a typical textbook example. It isn't "bad practice", it's typical bookkeeping practice -- it's the sort of transaction that could be generated by your accountant, bookkeeping staff, or an automated system, and I don't know what "shuffling pennies" has to do with it. Indeed it is reasonable for a given query or report focusing on account 1000 to ask "Where was the 2500 allocated?", but what your accountant or auditor will expect to see is the above transaction (assuming it's the only one in the system, of course), no more and no less. What your accountant or auditor will certainly not want to see are additional artificial allocations that exist solely to make your A.B. system work because it only supports simple transactions.

In short, your A.B. approach shown on AccountingModeling is fine for simple bookkeeping, such as personal accounting, but not adequate for enterprise accounting.

In other words you couldn't directly answer the query, but instead drag other credit accounts into the answer and make the reader pull out a calculator. If one had to do such a calculation on a larger scale, such as "all account 1000 credits for year X", it could be a bottleneck or a mess. Further, A.B. doesn't prevent having the above view both at creation and reporting.

Why would the reader pull out a calculator? The report would indicate precisely what it should, without artifice. You appear to be assuming that for every debit to a given account of a specified amount, there must be a corresponding credit to another account for the same amount. Or perhaps you're assuming that the 2500 credit must be allocated to some specific debit(s). That is not the case. In the above transaction, there is only a credit of 2500 to account 1000. There are no other amounts related to account 1000. As such, the following transaction is reasonable: 

 AccountNo Debit    Credit
 1000               2500
 1020               3200
 1040      1400
 1060      4300
How would you represent that using your A.B. approach? 

 Act De Cr
 ---------
 AAA --06
 BBB --12
 CCC 03--
 DDD 15--
 .
 A.B. Allocation:
 .
 CCC AAA 01
 DDD AAA 05
 CCC BBB 02
 DDD BBB 10
 (Zeros to reduce TabMunging)
I agree both approaches have their trade-offs, perhaps even at the user level (accountants), but that doesn't mean A.B. is summarily "bad". Some old habits may have to die, and new benefits, such as account-level precision, arrive as part of the trade-off. It reminds me of the argument that "old style" TV was better because the screen aspect ratio of all programs was consistent. We lost consistency with the advent of HD options, causing side-effects and confusion, but most realize sacrifices have to made, at least for a while, to transition to HD television. A.B. is high-definition accounting :-) -t

A.B. isn't "bad". It's adequate for home bookkeeping and the like. It's inadequate for enterprise bookkeeping. A.B. isn't "high-definition accounting" or "account-level precision", unless "high-definition accounting" means inserting artificial amounts in order to make it work for complex transactions. That would be highly questionable, annoying to the accountants and auditors, and certainly unnecessary. It definitely doesn't add any business value.

A related question to explore is what percent of all actual transactions are the "multi-split" type you illustrate versus simpler allocations.

Complex or "multi-split" transactions are typical in enterprise bookkeeping, even in very small businesses. This is particularly true when supporting multiple accounting functions -- A/R, A/P, inventory, order entry, etc. -- as they're invariably summarised as complex "multi-split" transactions in the general ledger. Simple transactions, in which a given amount is debited to one account and credited to another, are relatively rare and show up in the G/L as transfers between bank accounts, writing cheques to petty cash and the like.

To illustrate the "rounding issue", suppose we have to allocate $100.00 from account A to accounts B, C, and D. On first try, you may get something like B: $33.33, C: $33.33, and D: $33.33. However, we are one penny short since B+C+D=$99.99. One work-around is to arbitrarily (but based on a consistent rule) allocate a penny to one of the accounts to make them add up. Any allocation computation, whether explicit or implicit, will have to face this issue. One way to reduce the affects of such rounding adjustments is to store values internally at 4 or more decimal places. Final reports are then rounded to pennies. Internal monetary values at higher precision is fairly common in billing in my experience (although one tends to round down when needed on the presented bill to avoid the appearance of billing sneakiness. When in doubt, give the customer the penny to avoid drama, except in cases where the difference is significant.)

Rounding issues are not relevant here, unless the limitations of your A.B. model are forcing you to do needless allocations (e.g., divide $100 evenly across three accounts) in order to make the model work.

I dispute they are "needless", per above. It's a trade-off that provides additional value. (See also JustMakeItRight.)

For consistency, we'll make the rule that if pennies have to be added or removed to balance to group's total, then the highest accounting number(s) get the treatment first. If the account numbers are numeric, then numeric sorting is used to determine "last", else trimmed uppercase ASCII string sorting is used. Small adjustment amounts spread over large quantities of entries is preferable to large quantities into one or few.

You're introducing rules, and therefore complexity, that exist only to support a model that has numerous flaws and no demonstrated business value. Your claim of "additional value" has not been demonstrated. Do you genuinely feel you're defending something useful? If so, you need to present a more compelling justification than any you've presented so far, because it looks like you're clinging, desperately and tenuously, to a bad idea.

You are repeating prior claims and I disagreed with your assessment.

Stating that you disagree does not a compelling justification make.

It's not compelling to you because you are stubborn and set in your ways. And stop repeating summaries of your opinion all over the place. You flunk OnceAndOnlyOnce both in accounting AND your wiki writing. Shape up! The proper way to do it is to state "Claim X disputed at [link reference]."

It's not compelling to me because your "A.B." scheme demonstrates numerous flaws -- which I shall not elucidate again, out of respect for your sensitivity to duplication and replication -- and has not been adequately justified. I will readily admit that my wiki writing sometimes repeats the same points, when they're being ignored by my correspondents, but I fail to see my alleged flunking of OnceAndOnlyOnce in the bookkeeping model I presented. Would you please indicate how it fails OnceAndOnlyOnce -- say, via examples, particularly of the most common form of transactions, i.e., complex "multi-split" transactions? At the same time, would you kindly indicate how your model avoids flunking OnceAndOnlyOnce, perhaps using the same examples?

I don't have detailed realistic examples at this time. Repeated asking will not produce them faster. I suspect continuing the OnceAndOnlyOnce discussion will likely turn into a LaynesLaw mess over "repeat", whether repeating FK's is more "evil" than repeating values, and over the utility of quicker allocation tracing yet again repeatedly multiple times.

So you don't have detailed realistic examples at this time. In other words, you present a flawed approach and ask us to believe it has business value, but you can't demonstrate its business value. If you were in the reader's position, what would you think?

You haven't proven it's flawed. I already showed the business value: it can show where the $2500.00 went while you can't. Done! Suck it! Go ahead and tell a biz they shouldn't care where their shit goes. Say it! "Duh, um, your 2500 went to the uhhhh, the accounting cloud? Duuuuuh. Hey look, a pwetty butterfly!"

I listed a number of self-evident flaws above. The example transaction above shows where "the $2500.00 went" in precise and accurate bookkeeping terms. If your accountant produces the following transaction... 

 Transaction #12345
 Act Dr Cr
 ---------
 AAA --06
 BBB --12
 CCC 03--
 DDD 15--
...there is no more "where the 06 went" than the transaction shown, i.e., that 06 was credited to account AAA in transaction #12345. More "detail", if required, must be recorded explicitly and must not be automatically derived or deduced, otherwise you are constructing meaning that is not present in the original transaction. For example, you cannot assume, and therefore must not conclude, that the 06 is evenly "allocated" to both CCC and DDD. In reality, it might be that only 02 of AAA is transferred to CCC and the remaining 04 to DDD -- or it might be 01 to CCC and 05 to DDD -- but since that was not recorded, we do not know.

If you interpret the right-hand side as "to", it's tracking "where it came from". Same general thing either way. If the org wants to track at a finer detail, then they can manually enter finer details under either approach, such as splitting up the transaction themselves and giving explicit allocations. But that costs time and money. Orgs may opt to use an approximation if such detail is not available or they don't want to do extra work to enter & track such.

And why are you dictating what "must not be automatically derived"? That's NOT your decision, you are not The King, I hate to tell you. Where are you grabbing such "rules" from?

I am "dictating" what "must not be automatically derived" in a very specific case: Here. If you manufacture an allocation that is not specified, you are pretending precision where none exists. Again -- and you can't ignore this fact -- in the above example it might be that only 02 of AAA is transferred to CCC and the remaining 04 to DDD -- or it might be 01 to CCC and 05 to DDD -- but since that was not recorded, we do not know. So, you cannot pretend to know by guessing at allocation amounts that are unspecified. Doing so is not just bad bookkeeping; it borders on fraudulent. It's certainly misrepresentation.

If this is going down the same road that SimulationOfTheFuture did, then it's time to end this discussion. I'm not doing that crap again. Managers/owners should know or be informed about GiGo: if they want to track at a fine detail, then more effort (such as data entry) must be put in (spent). Otherwise, approximations would be used. Approximations/estimations are not inherently evil; they are a tool to be used or abused based on the skill and intent of the tool users. X-rays don't give a complete picture; they exclude much and "fold together" two of our 3 spacial dimensions into one. However, they are still immensely useful and have saved many lives. See also ParableOfTheBruises.

I see, so you've gone from advocating your "A.B." method as a duplicate-avoiding, balance-guaranteeing (as if that was ever a real problem) approach to bookkeeping -- in short, the opposite of an "approximations/estimations" system in terms of accuracy and precision -- and are now advocating it for "approximations/estimating." You're right, I think it's time to end this discussion before I poke more holes in the idea and you wind up claiming it's a great random number generator.

I have to admire your tenacity, though. Anyone else would long ago said, "Oh yeah, I guess it doesn't really work," and moved on to try something better. But not you -- once you've dug yourself into a hole, you try to build a mansion in it.

Hey, that's the future after global-warming makes living on the surface too unbearable. Don't knock it or else Al Gore will make you drive a Volt.

More on the subject: http://en.wikipedia.org/wiki/Double-entry_bookkeeping_system

See also AccountingModeling, BusinessTransaction

CategoryBusinessDomain

JuneThirteen

EditText of this page (last edited July 3, 2013) or FindPage with title or text search