* Interesting comment on it: http://groups.yahoo.com/group/extremeprogramming/message/35914 * First comment on it (by PhlIp): http://groups.yahoo.com/group/extremeprogramming/message/22972 * History: http://www.acaus.org/acc_his.html#7 ''(link corrected 12/17/02)'' * Business summary: http://www.toolkit.cch.com/text/P06_1350.asp * Humorous comparison to calculus: http://www.ncsysadmin.org/july2001/ncsa-gnucash-talk-3.html ''(broken link)'' ---- 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): * Retain an invariant. (The "double" part of the work is ensuring the invariant is always true.) The invariant is ''Owner's equity = Assets - Liabilities.'' Duh. That's easy. For each transaction, update whatever needs updating so the invariant remains true. If someone hands the owner $500 in goods or cash, then Assets go up $500, and, guess what, Owner's equity goes up $500! If the Owner borrows $100, guess what, assets goes up $100, and Liabilities also goes up $100. This is the essential Aha! of double entry bookkeeping and gives it its name. But it's actually the easy part. The hard part is... * Use only addition. Not only back in 1400 but also today, people make more mistakes in subtraction. And they didn't like erasing things or marking up the figures. Therefore only use addition. (This explained for me why the numbers keep getting larger, how come they don't subtract a few and run things down to zero again.) 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: * ''Assets(Right) + Liabilities(Left) + Equity(Left) = Assets(Left) + Liabilities(Right) + Equity(Right).'' 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 "Petty''''''Cash" 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.'' * I've never seen actual law text where its required to be doubled in data records. Some claim it exists in past debates, but never produced the text. That would be odd if OnceAndOnlyOnce was illegal. * ''That's a good point. I've never seen legal text requiring it either, and have only been instructed by accountants to do it that way or else -- with the verbal justification that it was a legal requirement. So, I did a bit of superficial digging to see if double entry is specified as a legal requirement in the US, Canada, or the UK. In short, it appears not to be. Generating reports that adhere to either the GAAP or the International Financial Reporting Standards is a legal requirement in a number of circumstances, but neither the GAAP or the IFRS appear to require double entry per se. However, it seems to me that the required reports are easiest to generate from a double entry system, related texts and documents assume a double entry system, and a double entry system is what your bookkeeper, accountant and auditor expect. Deviations from that are either going to complicate reports, complicate bookkeeping, complicate auditing, annoy & confuse your bookkeeper and/or auditor and/or accountant, or all of the above.'' -- DV * Perhaps it's just a matter of finding good conventions, utilities, or API's for converting a OnceAndOnlyOnce system into "simulated" double-entry for reports. Having duplication on the output seems like an odd justification for duplicating the internal model. Couldn't some kind of view (DB-view or interface) be created? This "bothers me" somehow. When something bothers me in such a way, often there is a simpler way to go about that has yet to be devised by me or others. Similar bothery-ness about the problem is what motivated me to come up with what I feel is a cleaner internal model in AccountingModeling. Now we just need to do the same with the output issues. --top * ''Beware of confusing "duplication" with "accuracy", "universality", and "simplicity". Please read again where I wrote: "Deviations from [the expected model] are either going to complicate reports, complicate bookkeeping, complicate auditing, annoy & confuse your bookkeeper and/or auditor and/or accountant, or all of the above."'' * That's almost like saying that one should use a hierarchical database like IMS because relational may be too new and confuse people. Change is hard, but "Assume Balance" is just a cleaner abstraction. Besides, it can be "projected" as the old-style technique for the most part. -t * ''Your "Assume Balance" may be fine for simple transactions, like recording paying for a meal, but it is not a ''generally'' cleaner abstraction. As I point out below, it is an awkward way to represent complex transactions, such as those generated by systems that present the debit and credit sides of a business transaction at different times. By the way, I don't know what your "That's almost like saying..." quip has to do with anything, other than being naively sarcastic. I recommend you confine yourself to the topic at hand, especially when you're still learning the fundamentals of a subject area.'' * (More discussion on this below.) ''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.'' * How specifically does the "assume balance" (A.B.) method under AccountingModeling violate this? * ''It doesn't, necessarily. 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. And, yes, your auditor could well want to drill right down to the tables in the database, so don't get cute and just show her a report you've produced using your model, unless you want her to spend time (and probably your money) auditing that, too. :)'' -- DV * So, outside of QwertySyndrome defense, you are saying it trades one kind duplication for another? I suppose there is some validity to that. What you propose appears to be balancing at the "batch" level rather than the transaction level. As long as the batch balances, the list can be willy nilly. I still think the AB approach is cleaner and more logical and if I ever start my planet, I'll try it first. * ''For complex transactions, your "A.B." method generates duplication where none otherwise exists. For simple transactions, your "A.B." method will work fine. I'm not sure what you mean by "the list can be willy nilly," but balancing at a batch level is a standard approach in bookkeeping systems that support batch entry, otherwise it is usually done (where possible) on a per-transaction basis. Your "A.B." method is common, too, but only for representing simple transactions, and keep in mind that it's essentially single entry.'' -- DaveVoorhis * How about a scenario? * ''Sure. A typical (simplified for illustration, e.g., no tax) example is recording an invoice, where the left-hand (debit) side will be represented by a single entry -- the invoice total applied to Accounts Receivable -- with the right-hand (credit) side represented by the invoice line items grouped/summed by product categories and applied to multiple Sales accounts, one per product category.'' * Another approach is to treat each line-item as its own transaction. In other words, if you sell 5 different kinds of widgets, then there would be 5 individual transactions rather than 5 credits and one debit (or vise versa). ** ''Yes, but then you're either (a) implementing exactly what I described above, or (b) needlessly duplicating dates, descriptions, etc., as noted above.'' ** As described elsewhere, usually there is a parent "header" record with context metadata. * However, allocating things like taxes may get sticky both philosophically and technically (see JustMakeItRight). Or maybe allocate first to a general "sales" account, and then re-allocate individual items from that. Sometimes financial accounting and internal accounting seem to purposely diverge from each other anyhow to avoid issues such as tax micro-allocation. For example, one may want to track at fractions of pennies, or do rounding to simplify things like tax micro-allocation. But the Fed rules wouldn't allow such because they are more interested in the big picture in the reports, not detailed allocations that may be sub-penny or rounded for simplicity or whatnot. I've seen this happen with things like crime statistics also: the FBI has odd reporting requirements that some don't want to mirror or use internally. Thus, two reporting systems are formed. Generally one keeps the details around and then makes special reports or views for each different kind of "customer" with their differing rules. The details may end up being used to generate A.B. semi-summed records for use in GAAP. ** ''Beware of maintaining separate but parallel bookkeeping systems. Your employer could wind up bearing the costs of having both audited.'' ** It's not illegal. The topic "Financial Accounting" is all about internal accounting. ** ''I didn't say it was illegal, only that it could wind up being audited if the auditor has reason to believe discrepancies exist between the two systems and that the discrepancies may have a bearing on the aspect of the business being audited. Anyway, that's hardly relevant. What is relevant is that (as already noted) your so-called "A.B." system is fine for simple transactions of a single amount against two accounts. Indeed, this is the approach often taken by automated bookkeeping systems for recording simple transactions. For complex transactions -- in which the two sides of the transaction may involve multiple accounts, possibly recorded at different times -- it is awkward and results in duplicated dates, descriptions, and other "transaction header" information.'' ** I'm skeptical. I'd like to study something close to an actual example. You may be prematurely allocating. Your example may be at the "log" level, as described (or attempted to describe) below. There may be no need to allocate at the level of each detail. Companies typically have a cut-off point, such as monthly, when all the data becomes "frozen". Any (user) errors found are issued as corrections at future months, subtracting out the mistake. This greatly reduces or eliminates the need to have to allocate at the detail level. -t ** ''Have you done corporate bookkeeping? Have you maintained accounting/bookkeeping systems on behalf of your clients? Have you managed the Accounting department for a large company? Have you designed, developed, deployed and maintained vertical-market ERP software? I have done all of these, so your scepticism and claim that I may be "prematurely allocating" (whatever that is) is not only naive, it's insulting. If you're unwilling to learn or have any respect for those with unquestionably more expertise than you -- as has been demonstrated not just on this page but many, many times throughout this wiki -- then I'm not going to waste time and effort creating yet more examples for you to quibble over, especially as all the information you need is on this page. I once wasted considerable time and effort producing PayrollExampleTwo for you; one such pointless experience was enough. By the way, period-end closures are utterly irrelevant to this discussion, and they neither reduce nor eliminate the need to allocate at the detail level because such detail is typically maintained both historically for audit/reporting purposes and for open periods.'' ** I don't believe the reader should "just have to accept" anecdotal evidence/claims at face value. If you are truly experienced in the field as you claim, you should be able to explain ''why'' such and such is done at a sufficiently-detailed level. If you don't wish to take the time to do that, that's fine. Just say it would take too long to explain and move on. If your existing examples are sufficient, then reference them using a name and show exactly where they show what you believe them to show. It's nothing personal; just that science respects models, not people. And I thought PayrollExampleTwoDiscussion was a good discussion (though a bit cluttered). It didn't produce a final answer, but '''asked some good questions'''. The road to truth is not necessarily short, quick, nor finished. I'm sorry, but I'm not understanding your complaint. -t ** And note I didn't advocate discarding the detail, but rather avoiding applying DEBK at too low a level. Also, different companies often do things in every different ways such that extensive accounting experience at one org does not necessarily apply fully to all. WaterbedTheory. * This does not mean end-user reports will be A.B., only that internally the semi-summed GAAP reference view is represented as A.B. I used to maintain a system that collected details from monthly copy-machine and plotter logs for client billing purposes that looked something like: Charge''''''Acct Qty ---------------- FA063 12 KY004 1 BK361 342 Etc... * This was the "raw" log. Later on the info was summarized and eventually double-entry book-keeping (DEBK) was applied. Your example of transactions happening with a time gap may be handled the same way. We don't need to worry about DEBK at that stage such that time is not an issue. They may be aggregated as needed at the end of the month or what-not. The important thing was that all summarize info be trace-able back to the details for auditing and trouble-shooting. (Rates were applied to quantities at a later stage.) -t * ''Sorry, no idea what you're on about.'' * The copiers were not hooked up to an accounting network. The logs only recorded the number of copies made and the project ID of a given copier transaction (via a user key-punch panel). The logs were periodically collected and systems further down the "path" did the necessarily "formal" accounting transactions, such as moving the copier costs from general expenses to specific projects. ''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 {A''''''ccountNumber INTEGER, Name CHAR, Description CHAR, K''''''indOfAccount CHAR} KEY {A''''''ccountNumber}; VAR J''''''ournal REAL RELATION {J''''''ournalID INTEGER, Day Date, Description CHAR} KEY {J''''''ournalID}; VAR J''''''ournalDetail REAL RELATION {J''''''ournalID INTEGER, A''''''ccountNumber INTEGER, Amount RATIONAL, I''''''sDebit BOOLEAN} KEY {J''''''ournalID, A''''''ccountNumber}; CONSTRAINT J''''''ournalDetail_References_Journal J''''''ournalDetail {J''''''ournalID} <= Journal {J''''''ournalID}; CONSTRAINT J''''''ournalDetail_References_Account J''''''ournalDetail {A''''''ccountNumber} <= Account {A''''''ccountNumber}; VAR J''''''ournalDebit VIRTUAL J''''''ournalDetail WHERE I''''''sDebit; VAR J''''''ournalCredit VIRTUAL J''''''ournalDetail WHERE NOT I''''''sDebit; CONSTRAINT J''''''ournalBalances SUM(J''''''ournalDebit, Amount) = SUM(J''''''ournalCredit, Amount); ''The above (in TutorialDee) minimises duplication whilst supporting simple and complex transactions. It also ensures -- via the "J''''''ournalBalances 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..."? * ''If it's not required, it would be turned off by not creating it in the first place. If it's required some times and not others -- and we assume there's a boolean E''''''nsureBalance flag to turn it on/off in a single row in a Configuration RelVar/table -- it could look like this:'' CONSTRAINT J''''''ournalBalances SUM(J''''''ournalDebit, Amount) = SUM(J''''''ournalCredit, Amount) OR NOT E''''''nsureBalance FROM TUPLE FROM Configuration; * That's a bit awkward. Then you have to deal with reminders or timers or balance polling to switch it back on. (Added line break to fit screens.) * ''It is a bit awkward, but it would work. However, production bookkeeping systems typically either require that the books always remain in balance (e.g., using the original unconditional constraint, above) or are allowed to go out of balance and the out-of-balance condition is then reconciled prior to financial reporting. Some systems only record transactions in batches that are distinct from the journal. Batches are allowed to be out-of-balance, but the journal can never be out-of-balance (perhaps by using, say, the unconditional constraint shown above.) and batches cannot be posted (i.e., moved) to the journal until they balance.'' 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 {J''''''ournalID 1, Day Date(2013, 6, 23), Description 'Invoice #12341'}}, INSERT J''''''ournalDetail RELATION { TUPLE {J''''''ournalID 1, A''''''ccountNumber 1000, Amount 125.48, I''''''sDebit TRUE}, TUPLE {J''''''ournalID 1, A''''''ccountNumber 3010, Amount 10.00, I''''''sDebit FALSE}, TUPLE {J''''''ournalID 1, A''''''ccountNumber 3020, Amount 93.00, I''''''sDebit FALSE}, TUPLE {J''''''ournalID 1, A''''''ccountNumber 2010, Amount 11.24, I''''''sDebit FALSE}, TUPLE {J''''''ournalID 1, A''''''ccountNumber 2020, Amount 11.24, I''''''sDebit 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...'' A''''''ccountNo 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:'' A''''''ccountNo Debit Credit 1000 2500 1020 3200 1040 1400 1060 4300 ''How would you represent that using your A.B. approach?'' * What do you mean "that's not the case"? It does happen, it's just implicit in the old way. A.B. makes it explicit, or more specifically "collapses" the allocation earlier in the process. * ''It's not the case that there is a debit amount for account 1000 in the above transaction.'' * I didn't claim there was. * ''Then what are you claiming? Again, assuming the above transaction is provided by your accountant or an automated system, how would you record it using your A.B. approach?'' * I'll present a version of the same general pattern that's easier to follow along (and doesn't introduce the dangling penny issue): 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) * ''This raises more questions than it answers. For example, how is "a version of the same thing" my transaction? I don't have accounts 'AAA', 'BBB' etc., and I don't recognise your numbers. Can you show '''my''' transaction using your A.B. approach? How is your example "easier to follow along" if it's "a version of the same thing"? Is it realistic to deliberately avoid introducing "the dangling penny issue"? Is it reasonable to defend a model that introduces "the dangling penny issue" without demonstrating a strong benefit that makes "the dangling penny issue" worth the effort? How do you justify to your auditor a (for example) debit to CCC and a credit to AAA of amount 01, given that it has no real-world basis and only exists to make your model work?'' * Sorry, I meant "same general pattern". "Same thing" was a poor word choice on my part. I apologize. I adjusted the original statement. I used letters for accounts to reduce confusion with monetary values. ** ''Why don't you use my example?'' ** I judged it too difficult for the reader to follow along what's going on. One can do the math I used in their head. I avoided the dangling penny issue in the example not because I want to hide the downside of A.B., but because it would be too many things going on at the same time for an early example. I probably wasn't clear on that aspect, and I take the blame for poor writing. ** ''Isn't that a strike against your approach that there can be a simple, reasonable, realistic transaction that is "too difficult for the reader to follow along"? A fundamental goal of all bookkeeping is that it should be simple.'' ** The concept is relatively simple, but the execution can be tedious. Fortunately there is a wonderful invention called the "computer" to assist with such grunt-work. ** ''Yes, and said "grunt-work" introduces rounding errors, apparently. Perhaps you'd like to show the algorithm for this?'' ** All limited-decimal proportion-based allocations will produce such "rounding errors". It's somewhat analogous to the microscopic world: if your granularity of view is small enough, you see quantum fluctuations. Again, if one does not want to see that level of detail, they don't have to. If you want to stick with an 1850's microscope-like view, you can. (Somebody else claimed they devised a similar algorithm in JustMakeItRight. I'm not in the mood to demonstrate such right now.) ** ''Yes, "limited-decimal proportion-based allocations" will produce rounding errors. The problem here is that you're introducing rounding errors without any justification because you're creating allocations that don't have any meaning. You haven't even shown a valid business reason to warrant an "A.B. view" in a report, let alone a stored representation. If there '''is''' some reason to want it, it can be reported from conventional bookkeeping approaches that are not as flawed as "A.B. views."'' ** Just because your sleepy-town backward biz didn't know or care about tracing doesn't mean it's not important. Per below, I'll LetTheReaderDecide on the biz need. ** ''Tracking the source of account balances is important, but conventional bookkeeping is sufficient for that. The "tracing" that "A.B. view" provides appears to be something quite different. Can you point to references in accounting literature or management practice that document the need for specifically the kind of "tracing" that your "A.B. view" provides?'' ** I don't have literature; it's personal observation, as described later. ** ''A personal observation of what? What was the business need? Please provide an illustrative example.'' * The dangling penny issue exists regardless of the technique used if one ever wants to "follow the path" of money. "What happens to transactions/funds fitting pattern X" is a common type of question in biz and accounting. If you lump at too big a granularity, then tracing "where stuff went" is difficult. Maybe accountants just got used to those kinds of questions being difficult and considered it job security to do it the hard way. That doesn't mean we shouldn't modernize and part with paper-based habits. * ''The "dangling penny issue" only exists in the context of recording transactions if you're forced to artificially distribute amounts across multiple accounts, which apparently the A.B. approach requires but conventional bookkeeping implementations do not. That appears to be a significant strike against the A.B. method. As for "where stuff went", you're not providing any better indication of that then conventional bookkeeping, but are attempting to create the illusion of better detail via artificial transactions. That's strike two. Better detail is always obtained by adding accounts or sub-accounts and recording normal transactions against them, not by creating artificial transactions.'' * If by "requires" you mean satisfy the ''minimum'' requirements of accounting, then you are correct. However, it's pretty obvious to me that A.B. makes allocation-trace queries much easier because the hardest part of allocation is already done. (Most companies like analysis.) If that part is not obvious to you, then I don't know what to say. I don't feel like illustrating why in extreme detail at this time. Maybe another day. Note that the dangling penny issue won't hurt base accounting requirements (if done right) since it adds up the same if compared at the granularity that the old approach provides. '''Semantically it can provide identical info''', and if YOU don't want to see the sub-allocation because you feel it's "artificial", you don't have to. Don't use (view) that granularity level. -t * ''I've never heard of "allocation-trace queries" (making some assumptions about what these are) that rely on artificial transactions. Bookkeeping is record-keeping. When I issue a transaction consisting of specified debits and credits, that is precisely the record that I, my accountant, and my auditor expect to see in the system. That, precisely that, and only that. If you present some other view that implies activity other than that which was entered -- e.g., some computation of allocations that creates debits and credits that I did not specify -- then you can expect your auditor and accountant to raise objections. Also, I'm not clear what value these extra debits/credits and their "allocation-trace queries" are supposed to provide -- and I've never had them requested by a user, accountant, manager, or auditor -- but if you "don't feel like illustrating why..."'' * New approaches almost always cause initial confusion. (See also QwertySyndrome.) And again, one does not have to present the the A.B. view to auditors etc. The old Flintstones view can be readily provided. As far as why you've rarely seen such requests, it could be in part that many companies keep separate books for "managerial accounting" and that such requests are done more often on that side. However, A.B. could reduce the dependence on a separate book set because some of the tracing can be moved back to the financial accounting side, killing 1.7 birds with 1 stone. * ''You've still not provided a justification for an "A.B. view". So far, your "new approach" appears to be a solution in search of a problem, so please present a business case.'' * 1) Technical OnceAndOnlyOnce, 2) Simplification/quickening of allocation tracing. 3) Less DB constraints needed * ''1) "A.B." isn't OnceAndOnlyOnce, because you're duplicating account numbers. Conventional bookkeeping records, as shown above, '''are''' OnceAndOnlyOnce. 2) You have provided no business case for needing (or even wanting) "allocation tracing". I've never seen an accountant, auditor, manager, bookkeeper, or developer do "allocation tracing" as provided by "A.B. views". That appears to be a notion you've constructed purely to justify "A.B. views", without any business rationale. 3) "Less DB constraints" is not a business case, and a very weak technical justification.'' ** The account numbers are foreign keys, not values. Introducing a finer level of granularity will result in more FK's. ** ''No it won't. Subaccounts are accounts. No additional foreign keys are required.'' ** If your company didn't need allocation tracing (or didn't know it was possible), so be it. I'll LetTheReaderDecide if their org or target audience wants such a feature. Enough of your whining already. ** ''What is the business justification for "allocation tracing"? Indeed, what is "allocation tracing"? It appears to be something you made up.'' ** I am possibly using the wrong vocabulary: I mostly observe the need from experience and don't know what the official label is. More on "the need" below. * ''As for "one does not have to present the A.B. view to auditors", it will not be you choosing to present it or not; as auditors they can ask to see it. Most companies do not keep separate books for "managerial accounting" or anything else. If they set up their books properly, they don't need to. Financial tracking at any level of detail -- which is primarily for the purpose of preparing financial statements and determining account balances -- can always be done using conventional bookkeeping. Furthermore, your "A.B. view" appears to be derivable from any conventional bookkeeping transaction, so assuming there is some reason to have an "A.B. view", why not generate it as needed in a report?'' * Any auditor can recreate such as view/result using just a DEBK view of the info. It's just a conversion/mapping. Your complaint is a non-complaint. Your last sentence seems to confirm this. '''They are semantically equivalent such that the one that has the most IT/Computation benefits wins.''' * ''Forcing an auditor to "recreate" anything means forcing the auditor to audit both the mechanism of creation and the mechanism of recreation. It is not wise to annoy auditors! As for being semantically equivalent, the two representations may be convertible but the "A.B. view" approach is seriously flawed: It requires duplicated account numbers, introduces rounding errors, creates unjustified debits/credits that do not exist in the source transactions whilst obfuscating the source transactions, and requires auditor-unfriendly reconstruction of conventional (and generally expected & generally recognised) bookkeeping views of transactions.'' * I mean the auditor has the ''option'' of doing such. They are '''not forced'''. Auditors generally use reports and generated spreadsheets, NOT raw RDBMS tables. The rest is misleading superficial sloganism on your part, the points of which have already been addressed. The only semi-valid argument is that changing of historical habit is not always easy. But since it's an implementation issue and not a presentation issue, that may not matter much: it will only affect the techies (but with added user-side benefits of quicker allocation tracing, addressed above). * ''If there are debits and credits in a bookkeeping system -- and your "A.B. view" appears to create them in order to work -- either they appear nowhere and there's no point in having them, or they appear somewhere that your auditor can see. If you auditor can see them, he or she will probably want to audit them.'' * Auditors only care about "following the rules". They don't care about budget issues and profitability. But biz owners/stewards DO CARE about that and want to know "where the money went": they want to be able to '''study the flow & allocation of resources''' in terms of inputs, flows, and destinations (outputs), not unlike software and systems analysts. You should know this from experience, but apparently don't. Early accounting systems focused on not getting sued, by satisfying the '''minimum requirements''', but new techniques allow analysis and data-mining-like techniques. Not-getting-sued is only half use. * ''I am very familiar with mechanisms to track the allocation of resources including budget issues and profitability. What I don't see is how the very specific "tracing" (your term) provided by your "A.B. view" approach is intended to help with that. Could you either demonstrate how it helps, or point to recognised accounting literature that supports the use of your particular approach?'' * I already gave you an example: "Where was the 2500 allocated?". A comparable business question may be, "Is our paper supply being used by production areas (including billable and non-billable) or administrative?" The literature question has been recently addressed in an earlier part. * ''The answer is precisely and correctly answered by, "it was allocated in transaction #xxxx", and point to the above transaction. Anything else, from a bookkeeping point of view, is incorrect and inaccurate.'' * PageAnchor: two-purposes * From a mere "bookkeeping point of view", you may perhaps be correct. But we can do MORE with the info, as already described. '''Accounting has two purposes''': 1) ensure an org is following the laws of financial reporting, 2) Help owners/managers know how money and resources are being used in the org. I will agree that A.B. does very little to improve #1. Your repeated refocusing on "what the auditor wants" seems to confirm that's the side you are considering, barring some OfficialCertifiedDoubleBlindPeerReviewedPublishedStudy that demonstrates #2. * ''You suggest that there is business benefit to the very particular type of allocation employed by the "A.B." approach, but you have provided no business case to substantiate it. How does it '''actually''' help owners/managers know how money and resources are being used? Please provide an example that makes reference to the '''very specific''' use of evenly-weighted allocations that the "A.B." approach requires. Until you show that, I can only regard the "A.B." approach as bad bookkeeping.'' * I don't have access to accountants at this time to put together a vetted example. Maybe a future project will get me such access. I've written a fair number of reports that provide roughly similar allocation tracking for specific kinds of items/transactions, but it seemed like the technique would be beneficial in a more general tool/system rather than hand-code each case to chomp overnight. My father even used to do allocation flow analysis for hospitals. I believe that if more saw how easy it was (or could be) to get such info, they'd be happy to switch. Note that most accountants focus on goal #1 in terms of training and mindset, thus, the push for change may come from other groups of an org. In the shorter term, it would probably be more practical to export the accounting detail to another "analysis system" to perform such, but future accounting systems may want to think about integrating them to avoid the data replication dance. * ''So, do I understand this correctly? You are sufficiently knowledgeable about bookkeeping to insist your "A.B." approach is superior to established representations, but you are not sufficiently knowledgeable about bookkeeping to provide an example that demonstrates how your "superior" approach is actually superior? Instead, you offer a vague anecdote and more HandWaving? How do '''you''' even know your approach is valid? Given that, is it any wonder that I'm sceptical? If I was making such vague and unsubstantiated claims for a new idea, wouldn't '''you''' be sceptical?'' * Again, I elect to LetTheReaderDecide if their org or designs could use such and will end further endeavors to "sell the idea". I don't need a damned OfficialCertifiedDoubleBlindPeerReviewedPublishedStudy to float an idea on this wiki. * ''No, obviously you don't, but you're usually the first to jump on any of us for presenting ideas related to FunctionalProgramming and the like -- demanding evidence and logical proofs -- so I find it rather ironic and hypocritical that you react so defensively when you're served exactly what you like to dish out.'' * It's when others claim "X is clearly better" that I pressure them for better evidence. I DON'T claim this is clearly better, only that it does some things better and should be considered. Based on your biz experience you don't think there's a biz need for the kind of tracability described, but I do. It's anecdotes either way such that we are at an anecdote impasse. My biz experience points me in a diff direction than you. We are stuck in a bicker-loop with no new evidence. * ''So if a strong claim is made that "X is clearly better" it should be held to higher scrutiny than if the claim is weak? Huh? It seems we're only at an anecdote impasse because all you have are anecdotes. Logical evidence, it seems, is entirely absent.'' * What is "logical evidence" ''supposed'' to look like concerning the ''utility'' of a tool? * ''I don't know, but it's what Top typically demands of us in response to our claims of preference, so I thought I'd try it.'' * I showed what the tool does. If your orgs don't have a need for that ability, then don't use it. Analogy: Here's a hair-removal tool. If you don't want to remove your hair, then don't use it; I'm not going to "logically" justify that you "need" hair removal. It may be my opinion that you are an ugly-ass werewolf and need a shave, but I cannot scientifically prove you are ugly. * It is my anecdotal experience that managers and owners "like" traceability of their money. I cannot prove they "should" like it. In capitalism we give the customer what they want, not necessarily what they "should have" such that in our primary economic model you don't "prove the customer SHOULD want X". That's not what we solve for here. Try the Soviet Union if you want to go that route. Oh, that's right, they are dead. * ''Nice rant; I like how you worked completely irrelevant politico-economic issues into it. Detailed traceability of money is fine. There are precise bookkeeping mechanisms, well-established and using subaccounts, for achieving it. The Soviet Communists (to get this back to being OffTopic) used it too, by the way, sometimes with multiple sets of books at a time.'' * You are lying or very naive claiming that economic considerations are not important. Claiming it's "irrelevant" does not make it so, even if you claim it multiple repeated times redundantly in multiple places repeatedly. And sub-accounts require extra manual work. More on this below. There seems to be an anti-economic bent by some aggressive WikiZens around here. * ''Are you claiming your quip about the Soviet Union was intended to be serious?'' 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.'' * [He'll need one to get statistically valid results with his estimations. Without it his allocations will introduce bias.] * You didn't poke any holes, you are just stuck in the old way out of habit. AB doesn't need any DB balance constraints and makes it easier to estimate allocation flow. If you don't like those benefits, tough titty. Several times you fussed about the auditor getting confused or freaking out for fuzzy reasons until it finally clicked in your thick head that the auditor does not have to ever see the A.B. numbers/view. * ''That's a curiously-biased misinterpretation of what went on above. I can only assume you're referring to my point that if the "A.B. numbers/view" are never seen -- and by that, I mean they do not partake in '''any''' view, whether derived or direct -- then they don't need to be audited. However, if they're never seen, then they serve no purpose. And if they serve no purpose, then they're not needed! If they are needed, presumably it's because they serve a purpose, and if they serve an accounting purpose, it means they -- or some derived view -- can be seen. If they can be seen, they can (and by "can", I mean "probably will") be audited.'' ** I explained to you at PageAnchor "two-purposes", accounting serves 2 purposes; the auditor is interested in one. And if A.B. was an industry standard, auditors would know its for money flow tracking estimations if they "accidentally saw it" and move on. ** ''If the second purpose has a significant influence on the first purpose -- and your "A.B." approach definitely does, as it uses an algorithm to transform the standard representation of bookkeeping transactions to an alternative representation in order to support your "second purpose" -- then auditors will certainly be interested in verifying that the algorithm works. This assumes, of course, that the "A.B." approach is actually used to represent bookkeeping transactions. That is unlikely to be the case, given that the majority of transactions are complex so there's no representational benefit to "A.B."; given that there's no apparent justification (at least, not that's given here) for needing or wanting the "estimate allocation flow" that the "A.B." approach facilitates; and given that the "estimate allocation flow" can be trivially derived -- assuming it's ever needed -- from conventional bookkeeping representations so there's no risk of auditing-related issues and no risk of rounding errors in supporting purpose #1.'' ** The auditor doesn't have to care if it's "correct" at the '''sub'''-transaction level, for that's not their concern (if by chance they even see that level). It's "internal information" as far as they are concerned. Besides, the auditor needs to verify that ANY accounting system is "correct" (at the granularity level required by law), and thus it's not a unique issue to A.B. ** ''The auditor doesn't have to care if it's '''provably''' correct, but you've already shown that your "A.B." approach introduces rounding error. Can your auditor be assured that this rounding error does not accumulate? Anyway, it's a moot point, given the objections I raised above which your reply did not address. Again, this assumes that the "A.B." approach is actually used to represent bookkeeping transactions. That is unlikely, given that the majority of transactions are complex so there's no representational benefit to "A.B."; given that there's no apparent justification (at least, not that's given here) for needing or wanting the "estimate allocation flow" that the "A.B." approach facilitates; and given that the "estimate allocation flow" can be trivially derived -- assuming it's ever needed -- from conventional bookkeeping representations so there's no risk of auditing-related issues and no risk of rounding errors.'' ** How are the "rounding errors" a worse potential problem than non-balancing, such as a flaw or hiccup related to your DB balance constraint? I've seen odd bugs in both Oracle and MS-Sql. Auditors usually have a set of summary tests and spot-sample tests to see if anything is odd. And allocation cannot be "trivially derived" if it takes too long to run for what it's used for. Often such studies would be done on volumes of info, not just one transaction. ** ''Determining whether a system is in balance or not is trivial, and modern bookkeeping systems rarely have a problem of going out-of-balance due to use of automated subsystems, batches and/or constraints that facilitate maintaining balance. Rounding errors tend to be subtle, or at least an order of magnitude less obvious than a trial balance being unbalanced.'' ** As far as "no apparent justification...for...estimating allocation flow", you've made that criticism in multiple places and I replied already. If you are not satisfied with my replies, shut the hell up already rather than repeat the complaint 20 odd times. It's fucking annoying as hell. May the OnceAndOnlyOnce gods zap your repetitious little balls off (or on if you are female). ** ''You appear to be unable to present even a simple example to show the value of your "estimating allocation flow". And why would a report designed to show "estimating allocation flow" "take too long to run for what it's used for" whilst other reports that are commonly used and based on bookkeeping records -- such as computing financial ratios -- not "take too long"? Have you done experiments on real data to demonstrate that this is a real performance problem? It must be rather difficult to generate real data to test this, given that you are unable to come up with even a simple example.'' ** I did too; you dismissed it because you are stubborn (and repetitious). *** ''All I see is a question: "Where was the 2500 allocated?" I don't see any business case -- particularly one with realistic examples -- to demonstrate that the question is meaningful, or if it is, that it requires your "A.B." approach to be used to represent bookkeeping records. In response to that question, I demonstrated that the 2500 (though I used a different number) could be allocated any number of ways, and given that the actual allocation (as if there is such a thing) is not recorded (if and when it is, it is recorded in sub-accounts) it would be inaccurate to speculate on its "allocation". Indeed, in accounting terms, it is not allocated in any more detail than precisely that shown in the transaction in which it is debited or credited.'' *** I also gave an example of figuring out where paper is going. And yes, it was not detailed and you already complained about the lack of detail there, so why complain about it again here? Does complaining about the same fucking thing over and over release endorphins for you? *** ''But your "A.B." approach doesn't help in "figuring out where the paper is going" any more than conventional bookkeeping. I am "complaining about the same fucking thing over and over" because you appear to be treating insufficient evidence as if it was a convincing argument. You should be trying to add evidence, not defend the inadequacy of your evidence.'' *** I never used the word "convincing" or similar around here. You are using the cartoon version of Demon Toppie in your head again. Your hate is distorting your judgement. *** ''I'm not sure what your use (or not) of the word "convincing" has to do with it, and I've no idea what you mean by "cartoon version of Demon Toppie in your head again" or what you think I hate. Is there some past discussion you're referring to or some context that I'm missing? I simply mean that I don't find your case for "A.B." to be convincing. To become convincing, it needs more evidence. Arguments, cases and presentations only become convincing with a preponderance of evidence. When they're not convincing, it's often because of a lack of compelling evidence. If you present weak evidence and are unwilling to provide better or more (or more compelling) evidence -- and yet staunchly maintain an apparently otherwise-undefended viewpoint -- scepticism on the reader's part will be inevitable.'' ** And financial ratios are usually not computed real-time. ** ''Why would your "estimate allocations" be any different?'' ** And no, I have not done actual experiments as far as the computation time on a large data-set. ** ''So your claim is based entirely on speculation?'' ** Yes. Again repeatedly, I DO NOT HAVE AN OfficialCertifiedDoubleBlindPeerReviewedPublishedStudy. ** ''Worse, you don't have any evidence at all.'' ** No, it's just anecdotal or based on estimated auditor and owner behavior, like much of YOUR evidence. Technically they can both represent the same info. The differences depend largely what user WetWare, including desired usage patterns. You have no OfficialCertifiedDoubleBlindPeerReviewedPublishedStudy either saying the users like or want or more often do X instead of Y. You could argue they are "used to it" and we should stick with true and tried, but progress is never made if nobody considers alternatives. I'm not proposing people switch here and now. ** ''Alternatives are fine, and indeed should be considered. Based on what's been presented so far, "A.B." is a poor alternative to conventional bookkeeping representations.'' * ''You have not presented any business case, or even an illustrative example, to demonstrate the need for an "estimate allocation flow". If it is needed, it can be trivially derived from conventional bookkeeping records. You have not demonstrated that balancing the books is such a problem that accepting all the other flaws (amply described above) of your "A.B." approach is worth it.'' * The vast majority of transactions ARE the simple type in most orgs, and for those it definitely '''reduces duplication'''. You exaggerate the frequency of the complex kind. * ''That is untrue. In a typical general ledger system, the vast majority of transactions are complex "multi-split" postings to summarise A/R, A/P, order entry, payroll, costing, and so on. Simple transactions represent bank transfers and the like, which are relatively rare.'' ** Without a real study, the ratio of transactions types will have to stay at the anecdote level of evidence. ** ''Not necessarily. Simply examine your company's books. Or any company's books, if they have an automated, database-driven bookkeeping system like Sage, SAP, etc.'' ** My current position is far outside of accounting-related projects. ** ''But surely it would take minimal effort to talk to some of your accountant colleagues over lunch or coffee and find out what kind of transactions are typical, no? You could also use the meeting to come up with some realistic "estimate allocation flow" examples, and if they're appropriately IT literate, see what they think of your "A.B." approach.'' ** They are in a different building, and I have no current biz reason to visit that building. ** Also note that "regular" accountants are generally not the ones who would care about analyzing allocation flows; they just want the "beans" to add up. The people who would care may be under "efficiency analysis", "budget planning/analysis", "business analysis", etc. ** ''I see. Then I guess "the ratio of transactions types will have to stay at the anecdote level of evidence" and we'll have to do without reasonable examples, because you seem unwilling or unable to obtain better evidence and it appears you won't take my word for it. Where does that leave us?'' ** Yes, I agree 110% that better examples would be a good thing. --top ** ''But you're not willing to make the (quite minimal, I would think) effort to create them?'' ** Sir, I do NOT currently have easy access to accountants or related experts. I'm sorry if you are intensely bothered by lack of better examples. See your doctor for possible anti-depressant or anxiety medications if you continue to find it highly irksome. ** ''I don't find it irksome. I do find it curious that you devoted so much effort on this page to defending an approach for which you had no defence.'' * Let me ask you this: other than unfamiliarity, what's the down side? * ''Nearly the entirety of the prior discussion highlights the downsides. Rather than repeat the above and risk drawing your ire for being repetitive, I suggest you re-read this page and objectively take note of both the flaws and benefits in as rational and as unbiased a manner as you can. Then summarise them here.'' * I wasn't "objective", it was your (wrong) estimations of owner and auditor behavior and desires. * ''You must have misread what I wrote, because your reply doesn't appear to have anything to do with what I wrote.'' ''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