|
Accounting Primer for Programmers?
My team will be starting development on an accounting package. We have hired an account to explain the concepts to the programmers, but he ain't a programmer so I was wondering is there a good site, resource, or book explaining accounting from a software development perspective? Something which ain't a detailed treatise, but just a nice intro from a coding view point?
Thanks in advance
Ravi
Friday, April 23, 2004
Martin Fowler's Analysis Patterns has quite a lot of stuff on accounting from a - well - I guess an analysis pattern point of view. I found it quite useful to understand some of the concepts, but you may also want something a bit more concrete to see how these things are done in practice.
http://www.furthermore.org.uk
Matt Freestone
Friday, April 23, 2004
I can't think of a single site (and I have an accounting/bookkeeping background).
Is it accounting or bookkeeping that you are after. In the old days anyone with a green visor was an accountant, but now days those green visored guys are merely bookkeepers.
What type of overview would you like?
Basic bookkeeping would be:
What debits/credits are. How double entry bookkeeping works. What the general ledger is, what a journal entry is, what debtors and creditors are. What the different account classifications are, ie income, expense, asset, liability and owners equity. What a balance sheet looks like, what a profit&loss sheet looks like. How to do a bank reconciliation
More Intermediate might include:
How these accounts roll over at the end of the year. The nitty gritty of owners equity. How MYOB and Quickbooks work.
Advance might include:
Cash Flow analysis. How to journalise share splits.
etc, that is purely on the 'how to' side of things, and soley the type of stuff a bookkeeper might do in a public accounting practice. ie this does not include anything on the management accounting side of things.
However other things you might want your programmer to know might be, depending on what your program is for:
what a bookkeeper does, how they go about taking the shopping bag full of screwed up receipts and bank statements and turns them into a reconciled set of books.
What common accounts are set up (ie repairs & maintenance, fuel etc). How the data is taken from the shopping bag and entered into the computer.
I do not know of any website, although the basic accounting course on MIT Opencourseware would probably provide good reading. Otherwise my suggestion would be:
1) Know exactly what the goal of this program is.
2)Explain this goal to an accountant/bookkeeper and let them have a good chat with your programmer, enough so that the program cna flesh out the important points and get an idea of why things are done the way that they are.
Aussie Chick
Friday, April 23, 2004
I took an accounting class at a local community college just to round out my education. You might look into that. Without some help, accounting books can be intimidating.
Matt H.
Friday, April 23, 2004
Its something that's occurred to me from time to time, every time I've had to explain credit and debit to a developer for example.
And then there's the task of explaining why you keep separate balances and not just sum the transactions.
Simon Lucy
Friday, April 23, 2004
I assume when you mention accounting, you are thinking first of bookkeeping (credits, debits, journals, accounts), then accounting built on top of that (depreciation/amortization, financial statements, audits). You are presumably also interested in where some of the odd requirements originate.
For bookkeeping, after you have done some reading, you might get a simple double-entry accounting program and use it to work through examples. Of the small-business commercial packages I know, QuickBooks and MYOB make things too easy, hiding the underlying debits and credits in most cases. Peachtree, which I find almost impossible to use, looks at the world the way an accountant does.
For financial accounting, again after some reading, you might look at a few annual reports of public companies in detail. Take a company that is in a specific business, rather than a conglomerate, and have fun looking at the footnotes. That seems to be where the bodies are usually buried. The annual reports will show the ways in which income and expenses are categorized.
If you are in the US, and you are dealing with accounting at the level of an enterprise, it may be useful to look at a few IRS forms and instructions. You'll see where some of the accounting requirements come from. Section 263A is particularly entertaining. The logic of the IRS is clear, the implementation clearly requires judgement. Depreciation and amortization is another interesting area. Also look at form 1120, the corporate tax return. This is interesting because it points out that financial accounting and tax accounting may differ, so you get to reconcile the two. This doesn't matter to your accounting package at the bookkeeping level, but may matter at the financial level, depending on what you are doing.
Dan Brown
Friday, April 23, 2004
I've worked on maintaining a lot of accounting systems. Here are the lessons those projects failed to learn;
Do NOT *EVER* do sums involving numbers using FLOATING POINT representations. Ever. If you do, you deserve to be hunted down and killed.
Normalised databases don't work in accounting. You can't, for example, print things and compute the tax rates in the report. Otherwise; You produce invoices with VAT rated at 15%. All the invoices have a column for "VAT payable" which is the line total * 0.15. Two weeks later, you run a VAT statement to send to HMC&E to say how much VAT you owe. The vat rate has been changed to 17.5%, so the amount of vat owed is the total of all sales * 0.175, right?
You have to store copies of information.
You MUST MUST MUST sort out the differences between the two roles of an accounting system. One is to store historical data, so you can see what happened. The other is to store current/pending things so you can see what the current state is. The easiest way to do this is to make transitions between tables be the responses to inputs. A letter arrives confirming an order. It therefore gets copied from Quotes into Orders. You then have a record of what was quoted for AND what was ordered. You also have an audit trail. If the customer later queries a discrepancy between their quote and their order, you at least know what the original quote was. If you just do it with one table and changing the states of the records, any changes to an order destroy the historical information.
You should have tables with current values for things in; a table which has stock counts in it is fine, but you should also have Deliveries and Sales records which get added and subtracted to that. It's not enough to rely on the count table, because you won't notice the difference between a delivery being short (which is something to have someone chase) and pilfery (which is treated differently). It's not enough to just compute the total of all deliveries - total of all sales because then you can't account for the ones they dropped down in dispatch without creating fake "sales" for them.
You could, of course, ignore all these things and produce industry standard accounting systems, but the only people who like those are dyed in the wool accountants. They get to insist that in the case of discrepancy between accounting and reality, reality has to be fixed...
Katie Lucas
Friday, April 23, 2004
Buy QuickBooks Pro for $200 and cancel your already ill-fated death-march DISASTER of a project-to-be. Trust me. You may scoff now, but this post will resound in your head 2 years from now.
I can smell a disaster a MILE AWAY, and this is it. Lack of domain expertise, AND reinventing the wheel. Breaking 2 cardinal rules in SW development.
You were warned.
Bella
Saturday, April 24, 2004
Do people actually do that?
I mean invest so much time and energy creating a piece of software for a field that they have no expertise in?
ie create a piece of accounting software because they think it would be great, without ever having spent any time in the field?
Seems crazy?
Aussie Chick
Sunday, April 25, 2004
I just found the following. I think it might be helpful to you as well:
www.sombers.com/ Accounting%20for%20NonAccountants%20by%20WHH.doc
Best of Luck to you,
Anne
Anne
Thursday, July 8, 2004
 Recent Topics
Fog Creek Home
|
