8 December 2003
Fanel Donea ( fdonea AT yahoo DOT com)
This is under development. The HTML version of this document is converted from LaTeX. Some weird characters and the 'No References!' section are there because I haven't yet figured out how to teach latex2html to deal with BibTeX citations.
Most non-specialist people begin accounting for personal purposes. Yet most books and articles feature company accounting. And many accounting software tutorials explain little of the actual accounting involved. After reading any or both of these types of documents, the newcomer is still left with simple unanswered questions. This document tries to fill a void so that, hopefully, you won't have to sift through hundreds of pages of accounting books or launch endless Internet searches.
This is a crude list of tips regarding personal accounting, using double-entry accounting. Software references are for GnuCash under Linux, but, provided that basic accounting principles are understood, they should be valid for any software. Later, I'll convert this file to something neater, maybe a database, and I'll include screenshots for Gnucash and maybe for other software too.
Personal accounting offers you the chance of doing two things at once: you keep track of your bank accounts, expenses and learn accounting in the process.
Unless otherwise specified, the default currency is AUD.
Please note that I am not an accountant. The advice given here may or may not get you or your business in trouble. Not my fault...
I strongly recommend skipping this section (this section is here just to impress non-accountants).
The accounting equation is:
One look at this equation and you would have figured out the normal balance of each type of account in a typical account chart :-) See following sections.
This is actually nothing else but a somewhat specific conservation law, like those we have in physics.
For every transaction, the sum of the debits must always equal the sum of the credits (The Law of Accounting). See [#!smith_accp!#]: 59
One must ignore the algebraic sign when computing sums of debits/credits (this is going to be unpopular with physicists and mathematicians!).
Actually, accountants want us to refrain from thinking in terms of positive and negative quantities, debit and credit being a better choice, they say.
In close relation to the accounting equation, there are five fundamental account types.
You may want to skip this paragraph -- it's dangerous for those with practical inclinations. Apparently everything humans do with money can be completely explained with just five accounts. At least for the moment. This is actually quite surprising. We seem to need hundreds of types of clothes, shoes, vehicles, sciences, food and so on, but we can do accounting with five account types. It would be nice to know how other beings in the Universe do their accounting. If we lived in a society where borrowing money would be unheard of, then the corresponding liability term of the accounting equation would disappear and four accounts would be enough. Of course we would never have had credit cards, house rates, investments etc. Conversely, aliens might be examining us right now, wondering how on Earth our economies survive or thrive (it that is what they're doing now) on only 5 accounts. Why didn't we think of the sixth and seventh account type?
For Debit/Credit definitions see: [#!smith_accp!#]:61 and [#!eisen_acc4!#]:50,52.
The DR+ CR- next to Assets means that debits to the account increase the account's balance, while credits decrease it. Another way this is expressed is to say the normal balance of the account is debit.
Typical Account Chart (I'll produce a nicer version later)
ASSETS (A) DR+ CR- CASH SV FOREIGN_USD USD_TRAD_ACC LIABILITIES (L) DR- CR+ BRRWD MORT EQUITY (Eq) DR- CR+ OPEN_USD INCOME (I) DR- CR+ SAL EXPENSE (Ex) DR+ CR- RENT FOOD HOUSE
A note about hierarchies: as long as you use the right account type and record the correct operations, it doesn't really matter how you structure your accounts. But exploiting the possibility of hierarchic accounts certainly can make your life easier (assuming that most accounting packages should allow a way to define hierarchies). For example, SAL may actually be composed of two sub-accounts (if you work for two companies). Payments in the HOUSE account (monthly mortgage payments) can be split into two types: payment of the interest and payment of the debt itself, allowing you to compare the two (and cringe as you realise how much interest you pay, compared to the value of the loan).
Or FOOD can be split into whatever types of food you want -- very useful if you're one of those people interested in keeping track of amounts spent on eggs or bread (don't ask me why you would, it's just an example!).
Enough theory! No one understands it in the beginning anyway (I didn't! Kerr black holes are definitely easier!). Ignore the theory, try to think of examples, and then go back to theory. After a few cycles, things will be clearer.
The first column of the following table describes the real life event, in simple terms. The second column describes the action to be taken, in a sort of shorthand notation -- the accounts involved and the amounts are specified. The advantage of this notation is that it is software independent. The third column is for comments, such as GnuCash peculiarities, if any.
|Transaction Description||Accounts Involved||Comment/GNuCash Action|
|At the beginning of the accounting period, upon arrival in, say, Australia, you own an amount of foreign currency (USD 600 in notes). You add this to the foreign currency account (FOREIGN_USD).||
Eq:OPEN_USD: +600 = CR A:FOREIGN_USD: +600 = DR
|Is this OK?|
|Exchanging USD 140 into the local currency, depositing the resulting AUD amount into the savings account.||
A:FRGN_USD: - USD 140 = CR A:SV: + AUD 300 = DR
|This has to be done via an intermediary currency trading account! In Gnucash, first create this currency trading account as an asset, with Currency AUD and security USD (USD_TRAD_ACC) Then enter all the information in the special pop-up box obtained after clicking on 'Transfer' in the 'Register' window of one of the two involved accounts from above.|
|Receiving a loan of USD 300 from a friend, into a foreign currency account.||
L:BRRWD: + USD 300 = CR A:FRGN_USD: + USD 300 = DR
|Receiving AUD 1000 income into the SV bank account.||
I:SAL: +1000 = CR A:SV: +1000 = DR
|Withdrawal of AUD 100 Cash from Savings Account (e.g. from ATM or at the counter)||
A:SV: -100 = CR A:CASH: +100 = DR
|Using AUD 700 from the SV account to pay back a USD 300 debt.||
A:SV: - AUD 700 = CR L:BORROWED: - USD 300 = DR
|Again, this is done via an intermediary currency trading account in Gnucash.|
|Buying an expensive digital camera using interest-free rates.||You gave lots of details, filled in forms, signed heaven knows what, but they gave you the camera. Now you're in debt. You owe the shop the whole amount. This is a (big) liability. The other account involved is an expense.||I don't like the fact that I have to record the whole expense on a date on which I did not actually spend that amount of money.... Any other solution?|
|Paying a rate for your camera||From one of your assets (e.g. savings account) you transfer money to the camera liability account. The balance of the latter will decrease.||--|
|Transaction Description||Accounts Involved||Comment/GNuCash Action|
|Getting a AUD 50,000 loan and buying a house with it (this is actually too little money, but I don't want to change the numbers)||
You pay for an expense (house) by using a liability, as opposed to paying using an asset, such as your money. This automatically puts you in debt. The two accounts involved are a liability account and an expense account.
EXP: = debit 50,000 L:MORT = credit 50,000
In the corporate world, opening entries and opening balances are needed when a company is first established or when it first starts keeping proper records.
For personal purposes, opening entries are needed because we don't generally start counting the money and assets we own the moment we start owning them (born accountants might disagree, that is, if they ever read this!). We don't do this because: (a) we're lazy or (b) we have no idea what accounting is at the time.
The solution seems to be to use a capital account (which sounds a bit weird for an individual).
Business will record purchases of equipment as increases in their property, plant and equipment assets. They also calculate depreciations.
For individuals there is little incentive in doing that. They can (and should?) record such purchases as expenses, rather than transfers between two asset types.
For example, computers, microwave ovens, furniture are assets for a company, but for you and me they are all expenses.
Depreciation might be an issue if you bought a computer to be used for work, out of your own money, in which case you get a certain tax refund.
You would probably like to track your bank account to the last cent, just in case there is a mistake. And it is not too difficult since you get the monthly account statement. You can reconcile the account, i.e. match your statement agains the records on the computer. It's probaly wise to do it since even banks can make mistakes.
Bank account transactions are also worthwile recording exactly because if you use a double entry accounting system you can automatically keep track of many other accounts in a single move. For example, you might be using your bank account regularly to pay rent, health insurance etc. So doing one account properly also brings a few other accounts up to date automatically.
But what about the cash in hand? Most people take the practical approach of recording transactions for which they have receipts, or maybe, with a little more effort, cash transactions they still remember at the end of the day or at the end of the week.
To avoid having larger and larger amounts of cash accumulate in the cash account in the computer you simply count whatever cash you still have at a given date and use an adjusting entry (????), in which you enter the difference between what the computer says the cash amount should be and the actual amount in your pocket, from the cash account to a special expense account (e.g. unknown_expenses).
Hopefully, at the end of the month, these expenses will typically make up about 5-10 per cent of your total expenses. This makes almost everyone happy (except born accountants, of course). What happened to the missing cash is then irrelevant: you lost it, someone didn't give you the right change, or, more probably, you forgot. It's up to you to choose the level of exactness in this.
How can all these amounts be tracked?
Can this be used for computing an approval 'ratio' for the insurer? He would do this for comparison purposes, just to help with choosing an insurer. Valid for all insurers.
Apparently: to transfer between a savings account in AUD to a 'money_borrowed' account in USD we need a currency account with currency AUD and security USD
This is particularly annoying when buying multiple items with cash: to which of the products do you apply the adjustment? If you distribute it, by what rule?
There is a way to deal with that in the accounting register without having discrepancies, no matter how small: treat this rounding as an expense. Whenever they charge us 1 cent extra, a split transaction records a debit of 1 cent to an expense account 'coinage-adjustment'. If, on the other hand we get a 'discount' we enter a credit. After doing this for a while we'll also be able to tell if it's really compensating -- this is not evident. If we buy single items frequently, then this adjustment's average is at the mercy of the supermarket. They probably can't make a fortune out of it, but the question is interesting anyway..what if we discover prices are mostly like 2.53, or 5.23 etc so that we 'incidentally' have to pay 2 cents extra many times....
Banii personali ai patronului nu intra in calcul decit asa, fara detalii despre ce face cu ei. see [#!eisen_acc4!#] : 6
This document was generated using the LaTeX2HTML translator Version 2002 (1.62)
Copyright © 1993, 1994, 1995, 1996,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 1 -local_icons -font_size 7pt -no_navigation accounting.tex
The translation was initiated by Fanel Donea on 2003-12-08